[arch-dev-public] [toolchain] gcc 4.5 breakage
I noticed problem with gcc 4.5 and the GAP system (http://www.gap-system.org) first: It throws a few aliasing warnings, and the program breaks. When I used -fno-strict-aliasing, the warnings disappeared, but the breakage remained, unless I used -O0. Fixing the aliasing problems also fixed the breakage. Now I noticed the exact same issue with busybox: - Building with -Os throws lots of aliasing warnings, busybox's sed breaks - Building with -Os -fno-strict-aliasing builds without warnings, but it still breaks. - Building with -O0 works, but it isn't optimal. This will affect LOTS of other programs and these errors will not show up as errors or warnings during the build procedure.
On 05/05/10 08:23, Thomas Bächler wrote:
I noticed problem with gcc 4.5 and the GAP system (http://www.gap-system.org) first: It throws a few aliasing warnings, and the program breaks. When I used -fno-strict-aliasing, the warnings disappeared, but the breakage remained, unless I used -O0. Fixing the aliasing problems also fixed the breakage.
Now I noticed the exact same issue with busybox: - Building with -Os throws lots of aliasing warnings, busybox's sed breaks - Building with -Os -fno-strict-aliasing builds without warnings, but it still breaks. - Building with -O0 works, but it isn't optimal.
Interesting... Does fixing the aliasing fix this one too? I see no upstream bug reports that seem related so you should follow it up there. I will pull in a new gcc-4.5 snapshot next week when I do the glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I am missing...
This will affect LOTS of other programs and these errors will not show up as errors or warnings during the build procedure.
As an aside 15% of the packages in the repos have been updated since gcc made it to [core]. From the lack of bug reports, the breakage does not appear too widespread
Am 05.05.2010 02:46, schrieb Allan McRae:
Now I noticed the exact same issue with busybox: - Building with -Os throws lots of aliasing warnings, busybox's sed breaks - Building with -Os -fno-strict-aliasing builds without warnings, but it still breaks. - Building with -O0 works, but it isn't optimal.
Interesting... Does fixing the aliasing fix this one too? I see no upstream bug reports that seem related so you should follow it up there. I will pull in a new gcc-4.5 snapshot next week when I do the glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I am missing...
I can only guess. You can remove -fno-strict-aliasing from the mkinitcpio-busybox PKGBUILD and build, then count the number of warnings - there's hundreds. I opened an upstream bug report, but I was so far unable to produce a test case they can use.
Am 05.05.2010 02:46, schrieb Allan McRae:
Interesting... Does fixing the aliasing fix this one too? I see no upstream bug reports that seem related so you should follow it up there. I will pull in a new gcc-4.5 snapshot next week when I do the glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I am missing...
There is no fix in the latest 4.5 branch (or trunk) yet. http://gcc.gnu.org/PR43987 has more details. Basically, the problem is caused by -ftree-fta, which is on by default with -O1 and higher (and also -Os, which I use for busybox). The bug can be worked around with -fno-tree-fta until a fix becomes available.
Am 06.05.2010 09:44, schrieb Thomas Bächler:
Am 05.05.2010 02:46, schrieb Allan McRae:
Interesting... Does fixing the aliasing fix this one too? I see no upstream bug reports that seem related so you should follow it up there. I will pull in a new gcc-4.5 snapshot next week when I do the glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I am missing...
There is no fix in the latest 4.5 branch (or trunk) yet. http://gcc.gnu.org/PR43987 has more details.
Basically, the problem is caused by -ftree-fta, which is on by default with -O1 and higher (and also -Os, which I use for busybox). The bug can be worked around with -fno-tree-fta until a fix becomes available.
Writing is difficult - it's -free-pta and -fno-tree-pta, of course.
On 06/05/10 17:45, Thomas Bächler wrote:
Am 06.05.2010 09:44, schrieb Thomas Bächler:
Am 05.05.2010 02:46, schrieb Allan McRae:
Interesting... Does fixing the aliasing fix this one too? I see no upstream bug reports that seem related so you should follow it up there. I will pull in a new gcc-4.5 snapshot next week when I do the glibc-2.12 toolchain rebuild so hopefully that may contain a fix that I am missing...
There is no fix in the latest 4.5 branch (or trunk) yet. http://gcc.gnu.org/PR43987 has more details.
Basically, the problem is caused by -ftree-fta, which is on by default with -O1 and higher (and also -Os, which I use for busybox). The bug can be worked around with -fno-tree-fta until a fix becomes available.
Writing is difficult - it's -free-pta and -fno-tree-pta, of course.
Don't worry... the gcc guy who fixed the bug got it wrong too! :) There is a patch on gcc trunk now: http://gcc.gnu.org/viewcvs/trunk/gcc/tree-ssa-structalias.c?r1=159098&r2=159097&pathrev=159098 I expect glibc-2.12 to be released in the next few days, so I will hold off until the next gcc-4.5 snapshot is released in the hope that this fix gets backported by then. If not, it looks a simple backport, so I will adjust the patch. Allan
Am 05.05.2010 00:23, schrieb Thomas Bächler:
I noticed problem with gcc 4.5 and the GAP system (http://www.gap-system.org) first: It throws a few aliasing warnings, and the program breaks. When I used -fno-strict-aliasing, the warnings disappeared, but the breakage remained, unless I used -O0. Fixing the aliasing problems also fixed the breakage.
Now I noticed the exact same issue with busybox: - Building with -Os throws lots of aliasing warnings, busybox's sed breaks - Building with -Os -fno-strict-aliasing builds without warnings, but it still breaks. - Building with -O0 works, but it isn't optimal.
This will affect LOTS of other programs and these errors will not show up as errors or warnings during the build procedure.
I am now building busybox with -O0 again, as '-Os -fno-strict-aliasing -fno-tree-pta' seemed to work at first, but it turned out the 'sed' output from busybox was just a few unreadable characters. I tested -O0 and it fixes the problems, but the binary is way too large. Btw, why do I always get signoffs, then move it, and only then get these reports?
On Mon, 10 May 2010 12:45:09 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Btw, why do I always get signoffs, then move it, and only then get these reports?
Because too few people use testing and this bug was only revealed when using some unusual boot parameters. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 10/05/10 20:53, Pierre Schmitz wrote:
On Mon, 10 May 2010 12:45:09 +0200, Thomas Bächler<thomas@archlinux.org> wrote:
Btw, why do I always get signoffs, then move it, and only then get these reports?
Because too few people use testing and this bug was only revealed when using some unusual boot parameters.
Or... maybe because that package was moved after about 24 hours so a fair portion of [testing] users would not have upgraded yet, not even considering the mirror sync time. Then a big proportion of those who did update it in that time would be regular updaters and would not have needed to regenerate their initrd yet. Allan
Am 10.05.2010 13:18, schrieb Allan McRae:
On 10/05/10 20:53, Pierre Schmitz wrote:
On Mon, 10 May 2010 12:45:09 +0200, Thomas Bächler<thomas@archlinux.org> wrote:
Btw, why do I always get signoffs, then move it, and only then get these reports?
Because too few people use testing and this bug was only revealed when using some unusual boot parameters.
Or... maybe because that package was moved after about 24 hours so a fair portion of [testing] users would not have upgraded yet, not even considering the mirror sync time. Then a big proportion of those who did update it in that time would be regular updaters and would not have needed to regenerate their initrd yet.
Yeah, I may have been too fast here. I'll know what I need to test more thoroughly in the future, besides booting my VMs with it. In this case: echo "a.b" | sed 's|\.|_|g' should return a_b and not something cryptic. Anyway, it seems the bug I reported in gcc 4.5 is not the only one that is breaking stuff here. The fix for that one has not yet been backported to 4.5 (it is in the 4.6 branch only). Once that is backported, we need a new snapshot.
how does all this stuff affect archiso releases? can i build my final images using packages from core or do i need to wait? dieter
participants (4)
-
Allan McRae
-
Dieter Plaetinck
-
Pierre Schmitz
-
Thomas Bächler