* Broken GCC versions: 4.8.2 and 4.9.0 @ 2014-05-11 1:05 Rich Felker 2014-05-11 16:10 ` Thomas Petazzoni 0 siblings, 1 reply; 18+ messages in thread From: Rich Felker @ 2014-05-11 1:05 UTC (permalink / raw) To: musl It's come to my attention that GCC versions 4.8.2 and 4.9.0 are performing invalid optimizations that result in a broken musl libc.a/libc.so. It's not clear yet whether there's a good workaround, or whether we should attempt to work around the problem, so for now, please just be aware that these versions of GCC cannot be used to compile musl. Using them to compile programs against musl should not be a problem. I'll post more details later. The short version is that it's making incorrect assumptions about the reachability of global variables that have a local weak definition and an external strong one. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 1:05 Broken GCC versions: 4.8.2 and 4.9.0 Rich Felker @ 2014-05-11 16:10 ` Thomas Petazzoni 2014-05-11 16:19 ` Rich Felker 0 siblings, 1 reply; 18+ messages in thread From: Thomas Petazzoni @ 2014-05-11 16:10 UTC (permalink / raw) To: musl; +Cc: dalias Dear Rich Felker, On Sat, 10 May 2014 21:05:03 -0400, Rich Felker wrote: > It's come to my attention that GCC versions 4.8.2 and 4.9.0 are > performing invalid optimizations that result in a broken musl > libc.a/libc.so. It's not clear yet whether there's a good workaround, > or whether we should attempt to work around the problem, so for now, > please just be aware that these versions of GCC cannot be used to > compile musl. Using them to compile programs against musl should not > be a problem. I'll post more details later. The short version is that > it's making incorrect assumptions about the reachability of global > variables that have a local weak definition and an external strong > one. Hum, interesting. I've recently tested gcc 4.8.2 + musl on ARM, and gcc 4.9.0 + musl on i386, and I could boot a minimal musl+Busybox system under Qemu perfectly fine. Maybe the problem you refer to only affects certain parts of libc.a/libc.so? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 16:10 ` Thomas Petazzoni @ 2014-05-11 16:19 ` Rich Felker 2014-05-11 18:46 ` James Cloos ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Rich Felker @ 2014-05-11 16:19 UTC (permalink / raw) To: Thomas Petazzoni; +Cc: musl On Sun, May 11, 2014 at 06:10:20PM +0200, Thomas Petazzoni wrote: > Dear Rich Felker, > > On Sat, 10 May 2014 21:05:03 -0400, Rich Felker wrote: > > > It's come to my attention that GCC versions 4.8.2 and 4.9.0 are > > performing invalid optimizations that result in a broken musl > > libc.a/libc.so. It's not clear yet whether there's a good workaround, > > or whether we should attempt to work around the problem, so for now, > > please just be aware that these versions of GCC cannot be used to > > compile musl. Using them to compile programs against musl should not > > be a problem. I'll post more details later. The short version is that > > it's making incorrect assumptions about the reachability of global > > variables that have a local weak definition and an external strong > > one. > > Hum, interesting. I've recently tested gcc 4.8.2 + musl on ARM, and gcc > 4.9.0 + musl on i386, and I could boot a minimal musl+Busybox system > under Qemu perfectly fine. Maybe the problem you refer to only affects > certain parts of libc.a/libc.so? I've filed the bug report which you can see here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 Something like the following command should confirm whether your build is affected: nm src/stdio/fflush.o | grep stdout For broken gcc versions, there is no output. For non-broken ones, you should see something like: 00000000 V __stdout_used Note that fflush(0) is just one place where the behavior may be affected by the invalid optimization. There are at least several others, though at a glance the others are more likely to be affected only with heavy inlining (but in principle, they "should" be affected even without inlining as long as inter-procedural optimizations are performed). Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 16:19 ` Rich Felker @ 2014-05-11 18:46 ` James Cloos 2014-05-11 19:03 ` Rich Felker 2014-05-11 20:20 ` Matias A. Fonzo 2014-05-15 4:45 ` Rich Felker 2 siblings, 1 reply; 18+ messages in thread From: James Cloos @ 2014-05-11 18:46 UTC (permalink / raw) To: Rich Felker; +Cc: Thomas Petazzoni, musl What does the wrong assembly of your test code look like? The assembly I get looks reasonable, in that it always references foo: The O3 version is: .file "test.c" .text .p2align 5,,31 .globl bar .type bar, @function bar: .LFB0: .cfi_startproc movl foo(%rip), %edx xorl %eax, %eax testl %edx, %edx setne %al ret .cfi_endproc .LFE0: .size bar, .-bar .section .rodata .align 4 .type dummy, @object .size dummy, 4 dummy: .zero 4 .weak foo .set foo,dummy .ident "GCC: (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) 4.8.2" .section .note.GNU-stack,"",@progbits Every version tests foo(%rip) and gets the result into %rax. The ia32, arm32 and arm64 assembly looks right, too. Perhaps distribution patches affect this? -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 18:46 ` James Cloos @ 2014-05-11 19:03 ` Rich Felker 2014-05-11 20:08 ` James Cloos 0 siblings, 1 reply; 18+ messages in thread From: Rich Felker @ 2014-05-11 19:03 UTC (permalink / raw) To: James Cloos; +Cc: Thomas Petazzoni, musl On Sun, May 11, 2014 at 02:46:51PM -0400, James Cloos wrote: > What does the wrong assembly of your test code look like? xorl %eax,%eax ; ret > The assembly I get looks reasonable, in that it always references foo: > > The O3 version is: > > .file "test.c" > .text > .p2align 5,,31 > .globl bar > .type bar, @function > bar: > ..LFB0: > .cfi_startproc > movl foo(%rip), %edx > xorl %eax, %eax > testl %edx, %edx > setne %al > ret > .cfi_endproc > ..LFE0: > .size bar, .-bar > .section .rodata > .align 4 > .type dummy, @object > .size dummy, 4 > dummy: > .zero 4 > .weak foo > .set foo,dummy > .ident "GCC: (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) 4.8.2" > .section .note.GNU-stack,"",@progbits > > Every version tests foo(%rip) and gets the result into %rax. > > The ia32, arm32 and arm64 assembly looks right, too. > > Perhaps distribution patches affect this? I've tested it on gcc.godbolt.org and others have tested with local gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). I wonder if the broken GCC is using isl/cloog (some third-party optimization library they hacked into gcc that's used only if it's available). That could explain it, especially since people who are building their own toolchains against musl do not seem to be experiencing the problem. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 19:03 ` Rich Felker @ 2014-05-11 20:08 ` James Cloos 2014-05-11 21:20 ` Rich Felker 2014-05-12 12:13 ` Rich Felker 0 siblings, 2 replies; 18+ messages in thread From: James Cloos @ 2014-05-11 20:08 UTC (permalink / raw) To: Rich Felker; +Cc: Thomas Petazzoni, musl >>>>> "RF" == Rich Felker <dalias@libc.org> writes: RF> I've tested it on gcc.godbolt.org and others have tested with local RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). I just tried debian-sid's 4.9. That does show the bug. As does their gcc-snapshot version (a 4.10 pre). Perhaps the distro(s) which have the bug with 4.8.2 backported the commit where the bug first occurs? RF> I wonder if the broken GCC is using isl/cloog I use the graphite optimizer on my Gentoo box (which generated the assembly I quoted). The graphite code is only used when one or more of -floop-interchange -floop-strip-mine -floop-block are specified. Testing with those options doesn't change the results. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 20:08 ` James Cloos @ 2014-05-11 21:20 ` Rich Felker 2014-05-12 1:23 ` Stephen Thomas 2014-05-12 9:28 ` Natanael Copa 2014-05-12 12:13 ` Rich Felker 1 sibling, 2 replies; 18+ messages in thread From: Rich Felker @ 2014-05-11 21:20 UTC (permalink / raw) To: James Cloos; +Cc: Thomas Petazzoni, musl On Sun, May 11, 2014 at 04:08:37PM -0400, James Cloos wrote: > >>>>> "RF" == Rich Felker <dalias@libc.org> writes: > > RF> I've tested it on gcc.godbolt.org and others have tested with local > RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). > > I just tried debian-sid's 4.9. That does show the bug. As does their > gcc-snapshot version (a 4.10 pre). > > Perhaps the distro(s) which have the bug with 4.8.2 backported the commit > where the bug first occurs? Sounds plausible. Maybe that will help find the offending commit. > RF> I wonder if the broken GCC is using isl/cloog > > I use the graphite optimizer on my Gentoo box (which generated the > assembly I quoted). The graphite code is only used when one or more > of -floop-interchange -floop-strip-mine -floop-block are specified. > > Testing with those options doesn't change the results. OK, ruled that out then. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 21:20 ` Rich Felker @ 2014-05-12 1:23 ` Stephen Thomas 2014-05-12 9:28 ` Natanael Copa 1 sibling, 0 replies; 18+ messages in thread From: Stephen Thomas @ 2014-05-12 1:23 UTC (permalink / raw) To: musl, James Cloos; +Cc: Thomas Petazzoni [-- Attachment #1: Type: text/plain, Size: 1334 bytes --] > On Sun, May 11, 2014 at 04:08:37PM -0400, James Cloos wrote: > > >>>>> "RF" == Rich Felker <dalias@libc.org> writes: > > > > RF> I've tested it on gcc.godbolt.org and others have tested with local > > RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). > > > > I just tried debian-sid's 4.9. That does show the bug. As does their > > gcc-snapshot version (a 4.10 pre). > > > > Perhaps the distro(s) which have the bug with 4.8.2 backported the commit > > where the bug first occurs? > > Sounds plausible. Maybe that will help find the offending commit. > > > RF> I wonder if the broken GCC is using isl/cloog > > > > I use the graphite optimizer on my Gentoo box (which generated the > > assembly I quoted). The graphite code is only used when one or more > > of -floop-interchange -floop-strip-mine -floop-block are specified. > > > > Testing with those options doesn't change the results. > > OK, ruled that out then. FWIW, I *think* noticed that this problem only appeared in buildroot, without enabling c++ in the languages. Actually, when I decided to evaluate the C++ changes and therefore enabled C++ in buildroot (I am not sure what it does in addition to --enable-languages=c,c++). I cannot be certain and I have not had the time to retest this. Cheers Thomo [-- Attachment #2: Type: text/html, Size: 1813 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 21:20 ` Rich Felker 2014-05-12 1:23 ` Stephen Thomas @ 2014-05-12 9:28 ` Natanael Copa 2014-05-12 14:30 ` Anthony G. Basile 1 sibling, 1 reply; 18+ messages in thread From: Natanael Copa @ 2014-05-12 9:28 UTC (permalink / raw) To: musl; +Cc: dalias, James Cloos, Thomas Petazzoni On Sun, 11 May 2014 17:20:30 -0400 Rich Felker <dalias@libc.org> wrote: > On Sun, May 11, 2014 at 04:08:37PM -0400, James Cloos wrote: > > >>>>> "RF" == Rich Felker <dalias@libc.org> writes: > > > > RF> I've tested it on gcc.godbolt.org and others have tested with local > > RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). > > > > I just tried debian-sid's 4.9. That does show the bug. As does their > > gcc-snapshot version (a 4.10 pre). > > > > Perhaps the distro(s) which have the bug with 4.8.2 backported the commit > > where the bug first occurs? > > Sounds plausible. Maybe that will help find the offending commit. I have tried to reproduce the issue on Alpine Linux without success. We have gcc-4.8.2 with lots of patches from gentoo and with a hardened default (default enabled). I have tried run with GCC_SPECS=vanilla (should disable the hardened part) and without the -Os without any difference. It would be interesting to know what patches was used on the affected gcc-4.8.2 systems. > > RF> I wonder if the broken GCC is using isl/cloog > > > > I use the graphite optimizer on my Gentoo box (which generated the > > assembly I quoted). The graphite code is only used when one or more > > of -floop-interchange -floop-strip-mine -floop-block are specified. > > > > Testing with those options doesn't change the results. > > OK, ruled that out then. We also have a patch[1] that will dlopen libcloog-isl.so.4 instead of link to it directly for upgrade purposes. I have tried to build musl with and without libcloog-isl.so.4 installed without it making any difference. > > Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-12 9:28 ` Natanael Copa @ 2014-05-12 14:30 ` Anthony G. Basile 2014-05-14 7:49 ` Natanael Copa 0 siblings, 1 reply; 18+ messages in thread From: Anthony G. Basile @ 2014-05-12 14:30 UTC (permalink / raw) To: musl On 05/12/14 05:28, Natanael Copa wrote: > On Sun, 11 May 2014 17:20:30 -0400 > Rich Felker <dalias@libc.org> wrote: > >> On Sun, May 11, 2014 at 04:08:37PM -0400, James Cloos wrote: >>>>>>>> "RF" == Rich Felker <dalias@libc.org> writes: >>> >>> RF> I've tested it on gcc.godbolt.org and others have tested with local >>> RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). >>> >>> I just tried debian-sid's 4.9. That does show the bug. As does their >>> gcc-snapshot version (a 4.10 pre). >>> >>> Perhaps the distro(s) which have the bug with 4.8.2 backported the commit >>> where the bug first occurs? >> >> Sounds plausible. Maybe that will help find the offending commit. > > I have tried to reproduce the issue on Alpine Linux without success. We > have gcc-4.8.2 with lots of patches from gentoo and with a hardened > default (default enabled). All the gentoo+musl stages on the gentoo tree are built with 4.7.3 so I can't speak to this issue. > > I have tried run with GCC_SPECS=vanilla (should disable the hardened > part) and without the -Os without any difference. > > It would be interesting to know what patches was used on the affected > gcc-4.8.2 systems. What gcc gentoo patches are you using? Even vanilla gentoo has some. > >>> RF> I wonder if the broken GCC is using isl/cloog >>> >>> I use the graphite optimizer on my Gentoo box (which generated the >>> assembly I quoted). The graphite code is only used when one or more >>> of -floop-interchange -floop-strip-mine -floop-block are specified. >>> >>> Testing with those options doesn't change the results. >> >> OK, ruled that out then. > > We also have a patch[1] that will dlopen libcloog-isl.so.4 instead of > link to it directly for upgrade purposes. I have tried to build musl > with and without libcloog-isl.so.4 installed without it making any > difference. > > >> >> Rich -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-12 14:30 ` Anthony G. Basile @ 2014-05-14 7:49 ` Natanael Copa 0 siblings, 0 replies; 18+ messages in thread From: Natanael Copa @ 2014-05-14 7:49 UTC (permalink / raw) To: musl; +Cc: basile On Mon, 12 May 2014 10:30:55 -0400 "Anthony G. Basile" <basile@opensource.dyc.edu> wrote: > What gcc gentoo patches are you using? Even vanilla gentoo has some. Listed here: http://git.alpinelinux.org/cgit/aports/tree/main/gcc -nc ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 20:08 ` James Cloos 2014-05-11 21:20 ` Rich Felker @ 2014-05-12 12:13 ` Rich Felker 2014-05-12 13:49 ` Thorsten Glaser 2014-05-12 13:56 ` James Cloos 1 sibling, 2 replies; 18+ messages in thread From: Rich Felker @ 2014-05-12 12:13 UTC (permalink / raw) To: James Cloos; +Cc: Thomas Petazzoni, musl On Sun, May 11, 2014 at 04:08:37PM -0400, James Cloos wrote: > >>>>> "RF" == Rich Felker <dalias@libc.org> writes: > > RF> I've tested it on gcc.godbolt.org and others have tested with local > RF> gcc 4.8.2 and 4.9.0, probably distro-provided (I didn't ask). > > I just tried debian-sid's 4.9. That does show the bug. As does their > gcc-snapshot version (a 4.10 pre). > > Perhaps the distro(s) which have the bug with 4.8.2 backported the commit > where the bug first occurs? Indeed, I think all the systems tested have been Debian-based (Debian or Ubuntu) and a quick check shows that their gcc-4.8 package, despite calling itself 4.8.2, is actually sync'd with the upstream 4.8 svn branch... There's a giant patch gcc-4.8-4.8.2/debian/patches/svn-updates.diff in the debian diff for the package, which contains everything between 4.8.2 release and the svn head. This is where the bug can probably be found. In short, Debian/Ubuntu's "gcc-4.8" package is essentially gcc 4.9.0. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-12 12:13 ` Rich Felker @ 2014-05-12 13:49 ` Thorsten Glaser 2014-05-12 13:56 ` James Cloos 1 sibling, 0 replies; 18+ messages in thread From: Thorsten Glaser @ 2014-05-12 13:49 UTC (permalink / raw) To: musl Rich Felker <dalias <at> libc.org> writes: > or Ubuntu) and a quick check shows that their gcc-4.8 package, despite > calling itself 4.8.2, is actually sync'd with the upstream 4.8 svn > branch... There's a giant patch > gcc-4.8-4.8.2/debian/patches/svn-updates.diff in the debian diff for > the package, which contains everything between 4.8.2 release and the > svn head. This is where the bug can probably be found. I think, not the head of trunk, but the tip of the 4.8 branch… > In short, Debian/Ubuntu's "gcc-4.8" package is essentially gcc 4.9.0. … which means, it’s not essentially 4.9.0, but essentially 4.8.3 instead. This means that 4.8.3 will introduce this error in vanilla GCC, unless it stems from a(nother) distro patch (local or 4.9-backport). This is all AIUI from my work as Debian/m68k porter. bye, //mirabilos ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-12 12:13 ` Rich Felker 2014-05-12 13:49 ` Thorsten Glaser @ 2014-05-12 13:56 ` James Cloos 1 sibling, 0 replies; 18+ messages in thread From: James Cloos @ 2014-05-12 13:56 UTC (permalink / raw) To: Rich Felker; +Cc: Thomas Petazzoni, musl >>>>> "RF" == Rich Felker <dalias@libc.org> writes: RF> In short, Debian/Ubuntu's "gcc-4.8" package is essentially gcc 4.9.0. As I wrote, deb's gcc-4.8 works fine. Only their gcc-4.9 and gcc-snapshot packages fail. On amd64 sid anyway. With: .ident "GCC: (Debian 4.8.2-21) 4.8.2" -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 16:19 ` Rich Felker 2014-05-11 18:46 ` James Cloos @ 2014-05-11 20:20 ` Matias A. Fonzo 2014-05-15 4:45 ` Rich Felker 2 siblings, 0 replies; 18+ messages in thread From: Matias A. Fonzo @ 2014-05-11 20:20 UTC (permalink / raw) To: musl Hi dalias, On 2014-05-11 13:19, Rich Felker wrote: > On Sun, May 11, 2014 at 06:10:20PM +0200, Thomas Petazzoni wrote: >> >> On Sat, 10 May 2014 21:05:03 -0400, Rich Felker wrote: >> >> > It's come to my attention that GCC versions 4.8.2 and 4.9.0 are >> > performing invalid optimizations that result in a broken musl >> > libc.a/libc.so. It's not clear yet whether there's a good workaround, >> > or whether we should attempt to work around the problem, so for now, >> > please just be aware that these versions of GCC cannot be used to >> > compile musl. Using them to compile programs against musl should not >> > be a problem. I'll post more details later. The short version is that >> > it's making incorrect assumptions about the reachability of global >> > variables that have a local weak definition and an external strong >> > one. >> >> Hum, interesting. I've recently tested gcc 4.8.2 + musl on ARM, and >> gcc >> 4.9.0 + musl on i386, and I could boot a minimal musl+Busybox system >> under Qemu perfectly fine. Maybe the problem you refer to only affects >> certain parts of libc.a/libc.so? > > I've filed the bug report which you can see here: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 > > Something like the following command should confirm whether your build > is affected: > > nm src/stdio/fflush.o | grep stdout > > For broken gcc versions, there is no output. For non-broken ones, you > should see something like: > > 00000000 V __stdout_used I can confirm that I'm getting in Dragora (binutils 2.23.2, GCC 4.8.2 + musl 1.1.0): 0000000000000000 V __stdout_used I was getting scared.. :-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-11 16:19 ` Rich Felker 2014-05-11 18:46 ` James Cloos 2014-05-11 20:20 ` Matias A. Fonzo @ 2014-05-15 4:45 ` Rich Felker 2014-05-19 0:47 ` Rich Felker 2 siblings, 1 reply; 18+ messages in thread From: Rich Felker @ 2014-05-15 4:45 UTC (permalink / raw) To: Thomas Petazzoni; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 3545 bytes --] On Sun, May 11, 2014 at 12:19:43PM -0400, Rich Felker wrote: > On Sun, May 11, 2014 at 06:10:20PM +0200, Thomas Petazzoni wrote: > > Dear Rich Felker, > > > > On Sat, 10 May 2014 21:05:03 -0400, Rich Felker wrote: > > > > > It's come to my attention that GCC versions 4.8.2 and 4.9.0 are > > > performing invalid optimizations that result in a broken musl > > > libc.a/libc.so. It's not clear yet whether there's a good workaround, > > > or whether we should attempt to work around the problem, so for now, > > > please just be aware that these versions of GCC cannot be used to > > > compile musl. Using them to compile programs against musl should not > > > be a problem. I'll post more details later. The short version is that > > > it's making incorrect assumptions about the reachability of global > > > variables that have a local weak definition and an external strong > > > one. > > > > Hum, interesting. I've recently tested gcc 4.8.2 + musl on ARM, and gcc > > 4.9.0 + musl on i386, and I could boot a minimal musl+Busybox system > > under Qemu perfectly fine. Maybe the problem you refer to only affects > > certain parts of libc.a/libc.so? > > I've filed the bug report which you can see here: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 > > Something like the following command should confirm whether your build > is affected: > > nm src/stdio/fflush.o | grep stdout > > For broken gcc versions, there is no output. For non-broken ones, you > should see something like: > > 00000000 V __stdout_used > > Note that fflush(0) is just one place where the behavior may be > affected by the invalid optimization. There are at least several > others, though at a glance the others are more likely to be affected > only with heavy inlining (but in principle, they "should" be affected > even without inlining as long as inter-procedural optimizations are > performed). Attached is a proposed patch to _detect_ this issue (not work around it) and reject the broken compiler. It does not hard-code an assumption that certain versions are broken, but tests the behavior with the seleted CFLAGS to see if the bug is present. I've considered multiple possible workarounds, but all of them have drawbacks: 1. Making the dummies non-static. This pollutes the symbol table and precludes -Wl,--gc-sections from being able to remove them when building libc.so unless visibility magic is also used. 2. Adding __attribute__((__used__)) to the static dummies. This works, and it's semantically correct that they should be considered "used" and not optimized out, but the problem actually isn't gcc optimizing them out; rather it's correctly keeping them around, but wrongly constant-folding them in expressions. So it's just "by chance" (a side effect of the bug) that adding this makes the problem go away. Also, adding it would require extra macro ugliness to account for the fact that we don't want to require the compiler to support __attribute__((__used__)). 3. Automatically adding -fno-toplevel-reorder to CFLAGS to suppress the optimizations when the bug is detected. This works now, but it's possible that it might not work for a future buggy gcc version. (It also produces a less-optimized libc.) Requiring the user to manually add this option if they want to try using a buggy compiler allows us to test and make sure the bug actually went away with the option added. Hopefully we can get the GCC folks to take this regression seriously and get it fixed before they release any more broken releases... Rich [-- Attachment #2: detect_gcc_4.9.0_bug.diff --] [-- Type: text/plain, Size: 1914 bytes --] diff --git a/configure b/configure index 5d95672..26f60a7 100755 --- a/configure +++ b/configure @@ -125,6 +125,7 @@ debug=no warnings=no shared=yes static=yes +wrapper=auto for arg ; do case "$arg" in @@ -199,27 +200,35 @@ exit 1 fi # -# Only build musl-gcc wrapper if toolchain does not already target musl +# Need to know if the compiler is gcc to decide whether to build the +# musl-gcc wrapper, and for critical bug detection in some gcc versions. # -if test -z "$wrapper" ; then printf "checking whether compiler is gcc... " if fnmatch '*gcc\ version*' "$($CC -v 2>&1)" ; then -echo yes +cc_is_gcc=yes +else +cc_is_gcc=no +fi +echo "$cc_is_gcc" + +# +# Only build musl-gcc wrapper if toolchain does not already target musl +# +if test "$wrapper" = auto ; then printf "checking whether to build musl-gcc wrapper... " +if test "$cc_is_gcc" = yes ; then wrapper=yes while read line ; do case "$line" in */ld-musl-*) wrapper=no ;; esac done <<EOF $($CC -dumpspecs) EOF -echo $wrapper else -echo no +wrapper=no fi +echo "$wrapper" fi - - # # Find the target architecture # @@ -484,6 +493,27 @@ printf "no\n" fail "$0: error: unsupported long double type" fi +# +# Check for known bug in GCC 4.9.0 that results in a broken libc. +# +if test "$cc_is_gcc" = yes ; then +printf "checking for gcc constant folding bug with weak aliases... " +echo 'static int x = 0;' > "$tmpc" +echo 'extern int y __attribute__((__weak__, __alias__("x")));' >> "$tmpc" +echo 'extern int should_appear;' >> "$tmpc" +echo 'int foo() { return y ? should_appear : 0; }' >> "$tmpc" +case "$($CC $CFLAGS_C99FSE -I./arch/$ARCH -I./include \ + $CPPFLAGS $CFLAGS_AUTO $CFLAGS -S -o - "$tmpc" 2>/dev/null)" in +*should_appear*) +printf "no\n" +;; +*) +printf "yes\n" +fail "$0: error: broken compiler; try CFLAGS=-fno-toplevel-reorder" +;; +esac +fi + printf "creating config.mak... " cmdline=$(quote "$0") ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-15 4:45 ` Rich Felker @ 2014-05-19 0:47 ` Rich Felker 2014-05-19 11:47 ` Szabolcs Nagy 0 siblings, 1 reply; 18+ messages in thread From: Rich Felker @ 2014-05-19 0:47 UTC (permalink / raw) To: Thomas Petazzoni; +Cc: musl On Thu, May 15, 2014 at 12:45:51AM -0400, Rich Felker wrote: > Attached is a proposed patch to _detect_ this issue (not work around > it) and reject the broken compiler. It does not hard-code an > assumption that certain versions are broken, but tests the behavior > with the seleted CFLAGS to see if the bug is present. No comments on this? Does it work for anyone who's experienced the problem? I'd like to commit and do a release or two if there are no problems with the patch. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Broken GCC versions: 4.8.2 and 4.9.0 2014-05-19 0:47 ` Rich Felker @ 2014-05-19 11:47 ` Szabolcs Nagy 0 siblings, 0 replies; 18+ messages in thread From: Szabolcs Nagy @ 2014-05-19 11:47 UTC (permalink / raw) To: musl; +Cc: Thomas Petazzoni * Rich Felker <dalias@libc.org> [2014-05-18 20:47:09 -0400]: > On Thu, May 15, 2014 at 12:45:51AM -0400, Rich Felker wrote: > > Attached is a proposed patch to _detect_ this issue (not work around > > it) and reject the broken compiler. It does not hard-code an > > assumption that certain versions are broken, but tests the behavior > > with the seleted CFLAGS to see if the bug is present. > > No comments on this? Does it work for anyone who's experienced the > problem? I'd like to commit and do a release or two if there are no > problems with the patch. works here to detect the broken gcc 4.9.0 in debian sid ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-05-19 11:47 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-11 1:05 Broken GCC versions: 4.8.2 and 4.9.0 Rich Felker 2014-05-11 16:10 ` Thomas Petazzoni 2014-05-11 16:19 ` Rich Felker 2014-05-11 18:46 ` James Cloos 2014-05-11 19:03 ` Rich Felker 2014-05-11 20:08 ` James Cloos 2014-05-11 21:20 ` Rich Felker 2014-05-12 1:23 ` Stephen Thomas 2014-05-12 9:28 ` Natanael Copa 2014-05-12 14:30 ` Anthony G. Basile 2014-05-14 7:49 ` Natanael Copa 2014-05-12 12:13 ` Rich Felker 2014-05-12 13:49 ` Thorsten Glaser 2014-05-12 13:56 ` James Cloos 2014-05-11 20:20 ` Matias A. Fonzo 2014-05-15 4:45 ` Rich Felker 2014-05-19 0:47 ` Rich Felker 2014-05-19 11:47 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).