Broken GCC versions: 4.8.2 and 4.9.0

Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Thomas Petazzoni]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[James Cloos]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[James Cloos]

>>>>> "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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Matias A. Fonzo]

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.. :-)

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

RE: Broken GCC versions: 4.8.2 and 4.9.0

[Stephen Thomas]

[-- 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 --]

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Natanael Copa]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Thorsten Glaser]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[James Cloos]

>>>>> "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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Anthony G. Basile]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Natanael Copa]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

[-- 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")

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Rich Felker]

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

Re: Broken GCC versions: 4.8.2 and 4.9.0

[Szabolcs Nagy]

* 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