Re: How is the definition of stack canary on MIPS arch?
On Tue, Aug 31, 2010 at 09:12:57AM -0700, David Daney wrote: On 08/30/2010 08:36 PM, Adam Jiang wrote: On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote: On 08/30/2010 09:46 AM, Richard Henderson wrote: On 08/30/2010 03:45 AM, Adam Jiang wrote: When I read the source in Linux kerne, it was said that stack canary for implementing stack protector is defined as an offset to %gs on x86 architecture. How about stack canary defined on MIPS? It's not implemented for MIPS. For the Linux kernel, the MIPS stack canary would be a constant offset (that depends on PAGE_SIZE) from register $28. David Daney Thanks, David and Richard. Is there code, doc or anything on this topic I can refer to? Is it defined in gcc internally or in kernel source itself? Would you please redirect me to the right place? I am unaware of any documents. The MIPS Linux kernel ABI is not really documented anywhere, one learns it by studying and hacking on the source code. 32-bit kernels use a variant of the o32 ABI, 64-bit kernels use a variant of n64. Both dedicate register $28 as a pointer to the thread area of which the stack is a part. The form any stack canary for the MIPS Linux kernel will be determined by whomever implements it. I have done some research by googling. Here are what I've gotten. http://www.trl.ibm.com/projects/security/ssp/main.html http://www.trl.ibm.com/projects/security/ssp/ http://lxr.linux.no/linux+v2.6.35/arch/x86/include/asm/stackprotector.h However, it seems there is no documents about how this is done on MIPS. Do I miss something? At RTH said, It's not implemented for MIPS., so there was really nothing to miss. I found this. http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02164.html However, my toolchain which I downloaded from CodeSourcery complained -fstack-protector was not supported when I tried this out. So, my question is what's the meaning by It's not implemented for MIPS. Linaro added stack protector in Linux kernel about two month ago. This patch has been pulled into a new release. Does this mean there is only one step left on Linux Kernel side to get support SSP on MIPS? /Adam David Daney
Re: on how to compile gcc-4.6 correctly?
On 09/05/2010 08:17 PM, Dennis wrote:
Hi, all,
I'm using gentoo distribution (including gmp/mpfr/mpc) that could compile
gcc-4.5.0, 4.5.1, and many snapshots correctly, including the recent one
gcc-4.5-20100902,
but when I tried to compile gcc-4.6, any snapshot version, even recent
gcc-4.6-20100904,
it always failed, the recent one failure compiling is:
../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokdeclarator':
../../gcc-4.6-20100904/gcc/c-decl.c:5533: warning: format not a string literal
and no format arguments
../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokparms':
../../gcc-4.6-20100904/gcc/c-decl.c:6194: warning: format not a string literal
and no format arguments
../../gcc-4.6-20100904/gcc/c-decl.c:7025:64: error: macro
ggc_alloc_cleared_lang_type passed 1 arguments, but takes just 0
../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_struct':
../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: 'ggc_alloc_cleared_lang_type'
undeclared (first use in this function)
../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: (Each undeclared identifier is
reported only once
../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: for each function it appears
in.)
../../gcc-4.6-20100904/gcc/c-decl.c:7308:62: error: macro
ggc_alloc_cleared_lang_type passed 1 arguments, but takes just 0
../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_enum':
../../gcc-4.6-20100904/gcc/c-decl.c:7308: error: 'ggc_alloc_cleared_lang_type'
undeclared (first use in this function)
make: *** [c-decl.o] Error 1
I don't know what happened with that? When I search the
'ggc_alloc_cleared_lang_type' macro,
it really doesn't exist in the gcc-4.6-20100904 source, nor under /usr/include,
so what is
that macro real dependency? the prerequisites page seems not help me,
http://gcc.gnu.org/install/prerequisites.html
Who have successfully build gcc-4.6 please help me, or have any clue, I have
searched that ggc_alloc_cleared_lang_type
through google, but didn't find out any meaningful results,
please make sure have my email address on cc-list that I can receive your
email, because I didn't subscribe such
high volume mailing list,
Thank you very much,
--
Dennis, from Singapore
hm... an obvious question would be if you have your toolchain correct?
(but you probably do..(I used this to build
4.6.0..:http://cross-lfs.org/view/svn/x86_64-64/))
in your case I see something with lang... maybe your CFLAGS are set
wrong to the wrong machine?! over here my CFLAGS look like this:
CFLAGS=-m64 -mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
-fstack-protector -w CXXFLAGS=${CFLAGS} MAKEOPTS={-j3}
keep in mind this is for a intel iMac... your system could be diff..
Justin P. Mattock
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard.
Re: on how to compile gcc-4.6 correctly?
--- On Mon, 6/9/10, Justin P. Mattock justinmatt...@gmail.com wrote:
From: Justin P. Mattock justinmatt...@gmail.com
Subject: Re: on how to compile gcc-4.6 correctly?
To: Dennis crq...@fedoraproject.org
Cc: gcc@gcc.gnu.org, crq...@ymail.com
Date: Monday, 6 September, 2010, 9:18 AM
On 09/05/2010 08:17 PM, Dennis
[...]
hm... an obvious question would be if you have your
toolchain correct?
Yes, I think the binutils/gmp/mpfr/mpc all dependencies are correct, otherwise
why I can compile all gcc-4.5.x version correctly?
On the same system, gcc-4.5.x (4.5.0 and 4.5.1 and 4.5-20100902/... multiple
snapshots) all can compile correctly, I install them into separate directories,
and have verified those compilers can compile many source packages correctly;
(but you probably do..(I used this to build
4.6.0..:http://cross-lfs.org/view/svn/x86_64-64/))
but this still didn't explain what's the ggc_alloc_cleared_lang_type macro?
all through gcc source it's only used by gcc/c-decl.c file, but it has no
definition under gcc source header files, nor under /usr/include;
in your case I see something with lang... maybe your CFLAGS
are set
wrong to the wrong machine?! over here my CFLAGS look like
this:
CFLAGS=-m64 -mtune=core2 -march=core2 -O2 -pipe
-fomit-frame-pointer
-fstack-protector -w CXXFLAGS=${CFLAGS}
MAKEOPTS={-j3}
I didn't use any special CFLAGS, when I try to compile gcc-4.5.x or this
gcc-4.6 snapshot, I just use ../gcc-4.6-20100905/configure
--with-arch-64=athlon64 --with-arch-32=i386, I tried to get a multilib
compiler that could generate default athlon64 optimized code for 64bit and i386
code for 32bit;
The same --with-arch-64=athlon64 --with-arch-32=i386 works well during
compiling gcc-4.5.x but why not work on gcc-4.6 ???
keep in mind this is for a intel iMac... your system could
be diff..
Justin P. Mattock
Thanks a lot~
Re: on how to compile gcc-4.6 correctly?
On Mon, Sep 6, 2010 at 2:54 AM, Cheng Rk crq...@ymail.com wrote:
--- On Mon, 6/9/10, Justin P. Mattock justinmatt...@gmail.com wrote:
From: Justin P. Mattock justinmatt...@gmail.com
Subject: Re: on how to compile gcc-4.6 correctly?
To: Dennis crq...@fedoraproject.org
Cc: gcc@gcc.gnu.org, crq...@ymail.com
Date: Monday, 6 September, 2010, 9:18 AM
On 09/05/2010 08:17 PM, Dennis
[...]
hm... an obvious question would be if you have your
toolchain correct?
Yes, I think the binutils/gmp/mpfr/mpc all dependencies are correct,
otherwise why I can compile all gcc-4.5.x version correctly?
On the same system, gcc-4.5.x (4.5.0 and 4.5.1 and 4.5-20100902/... multiple
snapshots) all can compile correctly, I install them into separate
directories, and have verified those compilers can compile many source
packages correctly;
(but you probably do..(I used this to build
4.6.0..:http://cross-lfs.org/view/svn/x86_64-64/))
but this still didn't explain what's the ggc_alloc_cleared_lang_type macro?
all through gcc source it's only used by gcc/c-decl.c file, but it has no
definition under gcc source header files, nor under /usr/include;
in your case I see something with lang... maybe your CFLAGS
are set
wrong to the wrong machine?! over here my CFLAGS look like
this:
CFLAGS=-m64 -mtune=core2 -march=core2 -O2 -pipe
-fomit-frame-pointer
-fstack-protector -w CXXFLAGS=${CFLAGS}
MAKEOPTS={-j3}
I didn't use any special CFLAGS, when I try to compile gcc-4.5.x or this
gcc-4.6 snapshot, I just use ../gcc-4.6-20100905/configure
--with-arch-64=athlon64 --with-arch-32=i386, I tried to get a multilib
compiler that could generate default athlon64 optimized code for 64bit and
i386 code for 32bit;
The same --with-arch-64=athlon64 --with-arch-32=i386 works well during
compiling gcc-4.5.x but why not work on gcc-4.6 ???
keep in mind this is for a intel iMac... your system could
be diff..
Justin P. Mattock
Thanks a lot~
ah... if gcc 4.5.0 builds right, but 4.6.0 does not then everything is
good(toolchain).. sounds like your going to have to file a bug with
gcc since 4.6.0 is so new..
(keep in mind it's late here so I might have left a few things out..).
--
Justin P. Mattock
Re: structures param_structures in gengtype
2010/9/6 Basile Starynkevitch bas...@starynkevitch.net: On Mon, 6 Sep 2010 06:36:48 +0300 Laurynas Biveinis laurynas.bivei...@gmail.com wrote: 2010/9/2 Basile Starynkevitch bas...@starynkevitch.net: Hello Laurynas, Diego all the list. A precise question about gengtype (the current trunk one) I have the impression that every member of the 'param_structs' variable in gengtype.c (viewed as a linked list of types linked thru their next field) is also a member of the 'structures' variable in gengtype.c Could you confirm that impression? That's my recollection too. Thanks for the prompt reply. Do you have a more precise understanding of how does that happen? I was not fully able to understand that. What routines are adding to both lists? Based on the reading of the source (I cannot run gengtype here): first the structs are created and put to the 'structures' list. This should be done by find_structure or similar. Then, iff GTY param option is encountered, a new struct type variable is created with kind = TYPE_PARAM_STRUCT and stru = already existing struct and that is put to 'param_structs'. Look at find_param_struct and its callers. -- Laurynas
Re: Question about Doloop
Hi,
Doloop optimization fails to be applied on the following inner loop
when compiling for PowerPC (GCC -r162294) due to:
Doloop: number of iterations too costly to compute.
strength reduction is performed in ivopts, introducing new variable:
for (p = inptr; p something; p += 3)
...
So the number of iterations is (something - p) / 3, which doloop considers
too costly to compute.
Zdenek
I do not understand why as the number of iterations is max_cols and I
appreciate an explanation.
Thanks,
Revital
11 while (--max_rows = 0)
12 {
13 inptr = *inbuf++;
14 outp = outbuf[0][rows];
15 rows++;
16
17 for (y = 0; y max_cols; y++)
18 {
19 k = ((int) (inptr[0]));
20 inptr += 3;
21
22 outp[y] = (unsigned char) ((inarr[k]) 16);
23 }
24 }
From Doloop dump:
Analyzing operand (reg/f:DI 246 [ D.2082 ]) of insn (insn 118 116 119 5
test1.c:17 (set (reg:CC 272)
(compare:CC (reg/v/f:DI 199 [ inptr ])
(reg/f:DI 246 [ D.2082 ]))) 535 {*cmpdi_internal1}
(expr_list:REG_DEAD (reg/f:DI 246 [ D.2082 ])
(nil)))
invariant (reg/f:DI 246 [ D.2082 ]) (in DI)
Loop 2 is simple:
simple exit 5 - 6
number of iterations: (mult:DI (plus:DI (minus:DI (reg/f:DI 246
[ D.2082 ])
(reg/v/f:DI 199 [ inptr ]))
(const_int -3 [0xfffd]))
(const_int -6148914691236517205 [0xaaab]))
upper bound: -1
Doloop: number of iterations too costly to compute.
(See attached file: test1.c)
gcc
i want a a gcc
Re: on how to compile gcc-4.6 correctly?
6.9.2010 6:17, Dennis kirjoitti: I'm using gentoo distribution (including gmp/mpfr/mpc) that could compile gcc-4.5.0, 4.5.1, and many snapshots correctly, including the recent one gcc-4.5-20100902, but when I tried to compile gcc-4.6, any snapshot version, even recent gcc-4.6-20100904, it always failed, the recent one failure compiling is: ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokdeclarator': ../../gcc-4.6-20100904/gcc/c-decl.c:5533: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'grokparms': ../../gcc-4.6-20100904/gcc/c-decl.c:6194: warning: format not a string literal and no format arguments ../../gcc-4.6-20100904/gcc/c-decl.c:7025:64: error: macro ggc_alloc_cleared_lang_type passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_struct': ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: (Each undeclared identifier is reported only once ../../gcc-4.6-20100904/gcc/c-decl.c:7025: error: for each function it appears in.) ../../gcc-4.6-20100904/gcc/c-decl.c:7308:62: error: macro ggc_alloc_cleared_lang_type passed 1 arguments, but takes just 0 ../../gcc-4.6-20100904/gcc/c-decl.c: In function 'finish_enum': ../../gcc-4.6-20100904/gcc/c-decl.c:7308: error: 'ggc_alloc_cleared_lang_type' undeclared (first use in this function) make: *** [c-decl.o] Error 1 I don't know what happened with that? When I search the 'ggc_alloc_cleared_lang_type' macro, it really doesn't exist in the gcc-4.6-20100904 source, nor under /usr/include, so what is that macro real dependency? Who have successfully build gcc-4.6 please help me, or have any clue, I have searched that ggc_alloc_cleared_lang_type through google, but didn't find out any meaningful results, This seems to be defined in a header generated during the build into the $BUILD/gcc : [r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u *)(ggc_internal_cleared_alloc_stat (sizeof (union lang_type_u) MEM_STAT_INFO))) On CentOS 5.5/ia32 the build seemed to succeed for the 'x86_64-linux-gnu' target, using gcc-4.1.2 as the host and build compiler. Must check the Fedora 13/x86_64 host with its gcc-4.4.4 too but I wouldn't expect any change with it... So maybe the Gentoo distro has some problem...
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead?
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Mon, Sep 6, 2010 at 6:19 PM, NightStrike nightstr...@gmail.com wrote: On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead? make -k check
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/6/2010 9:21 AM, Richard Guenther wrote: On Mon, Sep 6, 2010 at 6:19 PM, NightStrikenightstr...@gmail.com wrote: On Mon, Sep 6, 2010 at 5:21 AM, Richard Guentherrguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead? make -k check make check-c++ runs both g++ and libstdc++-v3 testsuites. -- Tim Prince
permissions to resolve bugs
Apologies for the trivial question - I haven't worked on GCC for a while. I fixed PR libobjc/19850. I guess I'm supposed to resolve the bug now but I don't seem to have the permissions to do it in bugzilla (my email is nicola.p...@meta-innovation.com). Can that be enabled ? :-) Apologies it this is not the right place to ask. Thanks
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther richard.guent...@gmail.com wrote: On Mon, Sep 6, 2010 at 6:19 PM, NightStrike nightstr...@gmail.com wrote: On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead? make -k check Ugh. And I thought I was golden :) This apparently requires autogen to do something about fixincludes/check.tpl. I have no idea what that is or what that means I'll report back. Any insight you can provide is greatly appreciated.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 09/06/2010 06:18 PM, NightStrike wrote: On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther richard.guent...@gmail.com wrote: On Mon, Sep 6, 2010 at 6:19 PM, NightStrike nightstr...@gmail.com wrote: On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead? make -k check Ugh. And I thought I was golden :) This apparently requires autogen to do something about fixincludes/check.tpl. I have no idea what that is or what that means Just ignore the fixincludes test results. Andrew.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley a...@redhat.com wrote: On 09/06/2010 06:18 PM, NightStrike wrote: On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther richard.guent...@gmail.com wrote: On Mon, Sep 6, 2010 at 6:19 PM, NightStrike nightstr...@gmail.com wrote: On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote: On Mon, 6 Sep 2010, Tobias Burnus wrote: Gerald Pfeifer wrote: Do you have a pointer to testresults you'd like us to use for reference? From our release criteria, for secondary platforms we have: • The compiler bootstraps successfully, and the C++ runtime library builds. • The DejaGNU testsuite has been run, and a substantial majority of the tests pass. See for instance: http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html There are no libstdc++ results in that. Richard. This is true. I always run make check-gcc. What should I be doing instead? make -k check Ugh. And I thought I was golden :) This apparently requires autogen to do something about fixincludes/check.tpl. I have no idea what that is or what that means Just ignore the fixincludes test results. Andrew. Thanks! Life just got easier again :) Running it with -j5. Hopefully cygwin doesn't barf on that.. I know cygwin used to have issues with -j.
Re: permissions to resolve bugs
On Mon, Sep 6, 2010 at 9:50 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: Apologies for the trivial question - I haven't worked on GCC for a while. I fixed PR libobjc/19850. I guess I'm supposed to resolve the bug now but I don't seem to have the permissions to do it in bugzilla (my email is nicola.p...@meta-innovation.com). Can that be enabled ? :-) You should be able to use your @gcc.gnu.org account which has full permissions to close bugs. Just use the forgot password on your @gcc.gnu.org account. If that does not work, is the email that your @gcc account is being forward to correct. Use ssh gcc.gnu.org email emailaddr...@emailmachine to set it up correctly. Thanks, Andrew Pinski PS I noticed you forgot to send the patches to gcc-patc...@. Even patches which are committed and written by maintainers should be sent there.
Re: permissions to resolve bugs
You should be able to use your @gcc.gnu.org account which has full permissions to close bugs. Just use the forgot password on your @gcc.gnu.org account. If that does not work, is the email that your @gcc account is being forward to correct. Use ssh gcc.gnu.org email emailaddr...@emailmachine to set it up correctly. Ah! That worked like a charm. Thanks a lot! :-) PS I noticed you forgot to send the patches to gcc-patc...@. Even patches which are committed and written by maintainers should be sent there. Ok - will do - I didn't know that. It sounds like a good idea. :-) I'll post them right now. Thanks
gcc bugzilla upgrade
I was working on a gcc bugzilla project upgrade under Daniel Berlin's guidance but have not been able to contact him in a long while. Can anyone give me a current address for him or another dev's name who I can work with? Thanks. Regards, -Tom Thomas M. Browder, Jr. Niceville, Florida USA
GCC on FreeBSD/ia64: No rule to make target .../libgcc/crtfastmath.o
Anton reports that GCC fails to build on FreeBSD/ia64. Any ideas on what to try? I assume it's just a small change that caused this regression (this used to work some releases ago). gmake[4]: Entering directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[4]: *** No rule to make target `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop. gmake[4]: *** Waiting for unfinished jobs gmake[4]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[3]: *** [gcc-extra-parts] Error 2 gmake[3]: *** Waiting for unfinished jobs gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Interestingly, i386/* does not show any changes on the i386 side that look like adjustments along these lines. Is this something ia64-specific? Any pointers, suggestions? I'm sure Anton will be happy to test any patches that one of us may come up with. Gerald
Re: GCC on FreeBSD/ia64: No rule to make target .../libgcc/crtfastmath.o
On Mon, Sep 6, 2010 at 4:30 PM, Gerald Pfeifer ger...@pfeifer.com wrote: Anton reports that GCC fails to build on FreeBSD/ia64. Any ideas on what to try? I assume it's just a small change that caused this regression (this used to work some releases ago). gmake[4]: Entering directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[4]: *** No rule to make target `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop. gmake[4]: *** Waiting for unfinished jobs gmake[4]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[3]: *** [gcc-extra-parts] Error 2 gmake[3]: *** Waiting for unfinished jobs gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgcc' gmake[2]: *** [all-stage1-target-libgcc] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Interestingly, i386/* does not show any changes on the i386 side that look like adjustments along these lines. Is this something ia64-specific? Any pointers, suggestions? I'm sure Anton will be happy to test any patches that one of us may come up with. Gerald You need to include config/ia64/t-ia64 in libgcc. -- H.J.
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-06 06:33 ---
In G++ 4.6+ you can do:
int i;
unsigned j;
template class T
void
bar (const T t)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wtype-limits
if (t 0)
#pragma GCC diagnostic pop
{
i++;
}
}
void foo (void)
{
bar (i);
bar (j);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #5 from noloader at gmail dot com 2010-09-06 06:45 ---
(In reply to comment #4)
In G++ 4.6+ you can do:
int i;
unsigned j;
template class T
void
bar (const T t)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wtype-limits
if (t 0)
#pragma GCC diagnostic pop
{
i++;
}
}
void foo (void)
{
bar (i);
bar (j);
}
Thanks Jakub.
All those #pragmas look like MS code. I thought Stallman hated those things (I
seem to recall #pragma once being the source of a lot of in-house bickering).
Did he get over ruled by committee?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug c++/45553] Warning Suppression: C++ Templates, Unsigned, and comparison of unsigned expression 0 is always false
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-06 06:48 --- I thought Stallman hated those things The reason why Stallman hated them is that they did not work with macros and that changed with C99 adding support of _Pragma which can be used in macros now. So his argument against Pragma went away when that come in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45553
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #2 from marc dot glisse at normalesup dot org 2010-09-06 07:12 --- (In reply to comment #1) __is_iterator can be useful anyway, Of course, they should use the same helper classes but they can coexist, although the 2 current uses of is_iterator would disappear. I was personally in favor of having is_iterator in the standard... Anyway, are you sure that, given the current wording in C++0x, such iterator_traits is strictly conforming? Howard seems to think so. The first paragraph of [iterator.traits] is good, the second one not so good (but it could be argued that the definition is provided for exposition, that it doesn't have to be copied verbatim to every implementation). It doesn't seem less conforming than what is used for next/prev. But then in some sense it is an extension, as it lets not strictly conforming code work (but doesn't break any conforming code). Which is why I am asking about an opinion on a possible enhancement, not calling it a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #38 from krebbel at gcc dot gnu dot org 2010-09-06 07:49 --- (In reply to comment #33) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00375.html Thanks for fixing it. And sorry for not testing it thoroughly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug testsuite/45543] [4.6 Regression] New test failures
--- Comment #1 from ubizjak at gmail dot com 2010-09-06 08:23 --- I have a patch for i386 failure. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-06 08:23:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45543
[Bug rtl-optimization/44919] ICE on ia64 with -O3 at sel-sched.c:4672
--- Comment #8 from amonakov at gcc dot gnu dot org 2010-09-06 08:57 --- Subject: Bug 44919 Author: amonakov Date: Mon Sep 6 08:56:43 2010 New Revision: 163904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163904 Log: PR rtl-optimization/44919 * sel-sched.c (move_cond_jump): Remove assert, check that the several blocks case can only happen with mutually exclusive insns instead. Rewrite the movement code to support moving through several basic blocks. * g++.dg/opt/pr44919.C: New. Added: trunk/gcc/testsuite/g++.dg/opt/pr44919.C Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44919
[Bug rtl-optimization/44919] ICE on ia64 with -O3 at sel-sched.c:4672
--- Comment #9 from amonakov at gcc dot gnu dot org 2010-09-06 09:00 --- (In reply to comment #7) Any progress with the copyright assignment? The copyright assignment is renewed, and I have committed the patch to the current development branch on Andrey's behalf. It will be committed to release branches in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44919
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-06 09:42 --- (In reply to comment #2) It doesn't seem less conforming than what is used for next/prev. Well, I think we are comparing two changes of very different impact and size. In the case of next / prev we have two functions, completely new in C++0x, getting a bit of constraining in the return type, no additional defaulted template parameters, only constraining in the return type: I would argue tha, in general, the way we are living the post-concepts era, this is more or less something the user looking inside headers of C++ library implementations is going to find in *many* more places than those where the Standard explicitly talks about does not participate to overload resolution. I can also add that this very thing makes me a little nervous, but I didn't raise the issue explicitly anywhere, thus... Anyway, in the other case, we are talking about changing a fundamental building block of the library. Certainly we would do that only in C++0x mode, agreed, still we are diverging more from C++03 in an area where the Standard is *not* diverging at all: as far as I can see, either we could use a defaulted template parameter with the enable_if on __is_iterator for the default; or we could create a small hierarchy, without enable_if. This is not something I would deliver for C++03 too, after so many years with a straightforward implementation, definitely not. Do you have in mind a simpler way to implement the smart iterator_traits? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug testsuite/45543] [4.6 Regression] New test failures
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-06 09:48 --- Subject: Bug 45543 Author: jakub Date: Mon Sep 6 09:48:10 2010 New Revision: 163907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163907 Log: PR testsuite/45543 * g++.dg/debug/dwarf2/typedef1.C: Expect just one DW_TAG_enumeration_type DIE. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45543
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #6 from pacho at condmat1 dot ciencias dot uniovi dot es 2010-09-06 10:45 --- This is what I get with gcc-4.5.1: root 651 0.0 0.1 13080 1780 tty1 S+ 19:18 0:00 usr/libexec/gcc/i686-pc-linux-gnu/4.5.1/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=pentium-m --param l1-cache-size=32 --param l1-cache-line-size=64 - --param l2-cache-size=2048 -mtune=generic -quiet -dumpbase - - -- -auxbase-strip /dev/null -o /tmp/cc3udN3F.s Then, looks like: 1. It's still using -mtune=generic 2. It now uses -march=pentium-m instead of presscott :-/ 3. It doesn't seem to detect sse3 Thanks for your help :-) -- pacho at condmat1 dot ciencias dot uniovi dot es changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug bootstrap/45554] New: gmp in nonstandard-location results in '-lgmpxx: not found'
For me, gmp and ppl are both in non-standard and different locations given via --with-gmp/--with-ppl to gcc's configure 'make bootstrap' results in suncc -g -DIN_GCC-DHAVE_CONFIG_H -Wl,-R/pf/m/m222086/xas/solaris10/gcc/libe lf-latest/lib -Wl,-R/pf/m/m222086/xas/solaris10/gcc/cloog-ppl-latest/lib -Wl,-R/ pf/m/m222086/xas/solaris10/gcc/ppl-latest/lib -Wl,-R/pf/m/m222086/xas/solaris10/ gcc/mpc-latest/lib -Wl,-R/pf/m/m222086/xas/solaris10/gcc/mpfr-latest/lib -Wl,-R/ pf/m/m222086/xas/solaris10/gcc/gmp-latest/lib -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-i nfo.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c -objc-common.o c-dump.o c-pch.o c-parser.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ dummy-checksum.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/pf/m/m222086/xas/solaris10/gcc/ppl-latest/lib -lppl_c -lppl -lgmpxx -L/pf/m/m222086/xas/solaris10/gcc/gmp-latest/lib -L/pf/m/m222086/xas/solaris10/gcc/mpfr-latest/lib -L/pf/m/m222086/xas/solaris10/gcc/mpc-latest/lib -lmpc -lmpfr -lgmp -L../zlib -lz -L/pf/m/m222086/xas/solaris10/gcc/libelf-latest/lib -lelf ld: fatal: library -lgmpxx: not found The reason is obvious: The configure-script just appends '-lgmpxx' to @ppllibs@ without any gmp library search path. For those of you who stumbled over this bug report by utilizing your favourite search engine: A quick fix is to give --with-ppl=ppl_dir -Lgmp_dir/lib to configure. BTW: On systems with a shared libppl, libgmpxx is not needed as it is pulled in via DT_NEEDED. -- Summary: gmp in nonstandard-location results in '-lgmpxx: not found' Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nicolai dot stange at zmaw dot de GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45554
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #4 from marc dot glisse at normalesup dot org 2010-09-06 11:01 --- (In reply to comment #3) Well, I think we are comparing two changes of very different impact and size. You are right. I would argue tha, in general, the way we are living the post-concepts era, this is more or less something the user looking inside headers of C++ library implementations is going to find in *many* more places than those where the Standard explicitly talks about does not participate to overload resolution. I can also add that this very thing makes me a little nervous, but I didn't raise the issue explicitly anywhere, thus... I completely agree here. After the removal of concepts, the library is in need of more concept-related work in the standard, it shouldn't be up to the implementers. Anyway, in the other case, we are talking about changing a fundamental building block of the library. Certainly we would do that only in C++0x mode, agreed, still we are diverging more from C++03 in an area where the Standard is *not* diverging at all: as far as I can see, either we could use a defaulted template parameter with the enable_if on __is_iterator for the default; or we could create a small hierarchy, without enable_if. This is not something I would deliver for C++03 too, after so many years with a straightforward implementation, definitely not. Ok. It seemed safe enough to me (especially since some other implementations do it), so I thought I should ask. Do you have in mind a simpler way to implement the smart iterator_traits? No, I was going with the small hierarchy (ie keep the partial specializations for pointers, and have the generic implementation derive from helperIter, has_iterator_categoryIter::value where helper is empty by default and has a partial specialization for T,true that contains 5 typedefs). It looked like the safest option. Feel free to close the bug if you think it is a bad idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-06 11:06 --- Ok, I reproduced a failure (but none of the kind reported here) and have a fix for that issue. Maybe it fixes this bug too, which I still can't reproduce. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-04 12:05:15 |2010-09-06 11:06:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-06 11:42 --- Nice that we agree on many points. Anyway, my plan would be (I cannot resist ;) preparing a small prototype, using the hierarchy, attach it here, and wait for Jon' opinion. Then we can make the final decision... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug testsuite/45543] [4.6 Regression] New test failures
--- Comment #3 from ubizjak at gmail dot com 2010-09-06 12:02 --- i386 failure is a real PR22152 regression, masked by wrong scan regexp. I'll reopen PR22152. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45543
[Bug target/22152] Poor loop optimization when using mmx builtins
--- Comment #11 from ubizjak at gmail dot com 2010-09-06 12:05 --- Reopened due to 4.6 regression, see [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00529.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-09-06 12:15 --- Subject: Bug 45534 Author: rguenth Date: Mon Sep 6 12:14:02 2010 New Revision: 163913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163913 Log: 2010-09-06 Richard Guenther rguent...@suse.de PR tree-optimization/45534 * tree-ssa-address.c (create_mem_ref_raw): Add verify parameter. (create_mem_ref): Do verify the created TARGET_MEM_REF is valid on the target. (maybe_fold_tmr): Do not verify the created TARGET_MEM_REF is valid on the target. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-address.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #6 from marc dot glisse at normalesup dot org 2010-09-06 12:21 --- (In reply to comment #5) preparing a small prototype, using the hierarchy, attach it here Just to make sure, does that mean you are writing the prototype, or do you want me to? (my employer started the assignment papers in 2009, but the FSF hasn't had time yet) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-06 12:32 --- Me, me ;) But, to be clear, your help here and elsewhere would be more than welcome. If there is something I can do about the paperwork, just let me know! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-09-06 13:17 --- Created an attachment (id=21709) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21709action=view) retain redefinition of MAIN_STACK_BOUNDARY as required -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #21647|0 |1 is obsolete|| Attachment #21681|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c++/45555] New: Add warnings for changes to code with option -fipa-sra
The -fipa-sra option may result in object code changes. Users should be notified of such changes so they can make source code changes. -- Summary: Add warnings for changes to code with option -fipa-sra Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #12 from burnus at gcc dot gnu dot org 2010-09-06 13:35 --- DONE: - POPPAR, POPCNT [and LEADZ/TAILZ already in GCC 4.4] - IALL, IANY, IPARITY TODO (cf. comment 2) a) F2008's bit intrinsics: DSHIFTL, DSHIFTR, SHIFTA, SHIFTL, SHIFTR, MASKL, MASKR, BGE, BGT, BLE, BLT, MERGE_BITS c) HPF only: ILEN(I) Cf. http://wotug.org/parallel/standards/hpf/, HPF 2.0, Section 7.6 d) IBCHNG(POS, I) Industrial Real-Time Fortran Standard (ISO 7846:1985; withdrawn) and common vendor extension -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug bootstrap/45556] New: Add PPL and CLooG-PPL source to gcc source tree for build
As of now, gcc builds with gmp, mpfr, and mpc source directories placed in the gcc tree by the user. Adding the other two main prerequisites into the tree for full gcc features would be a win for users. The inter-dependence of the configuration options between the latter two and gmp, mpfr, and mpc makes it difficult for a user to build all successfully without trial and error. An explicitly versioned set of the five sources known to work for a given version of gcc to be downloaded with a helper script (like the one by Andrew Haley: download_prerequisites.sh) would be very helpful and ease debugging and help for all. -- Summary: Add PPL and CLooG-PPL source to gcc source tree for build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45556
[Bug lto/45557] New: Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
cc1plus segfaults on the attached testcase with -flto -O1 -finline-small-functions -fpartial-inlining. $ g++-4.6 -v -flto -O1 -finline-small-functions -fpartial-inlining TC.cpp Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/xman/gcc-4.6-20100828/configure --program-suffix=-4.6 --enable-lto --enable-version-specific-runtime-libs Thread model: posix gcc version 4.6.0 20100828 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-flto' '-O1' '-finline-small-functions' '-fpartial-inlining' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -quiet -v -D_GNU_SOURCE TC.cpp -quiet -dumpbase TC.cpp -mtune=generic -march=x86-64 -auxbase TC -O1 -version -flto -finline-small-functions -fpartial-inlining -o /tmp/ccRma3YY.s GNU C++ (GCC) version 4.6.0 20100828 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100828 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++ /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.6.0 20100828 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100828 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 2c7dd1386f3abb6f2873be5b63c94737 TC.cpp: In function f3(): TC.cpp:5:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Segfault with -flto -O1 -finline-small-functions - fpartial-inlining Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexey at feldgendler dot ru GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
[Bug lto/45557] Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
--- Comment #1 from alexey at feldgendler dot ru 2010-09-06 13:48 --- Created an attachment (id=21710) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21710action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
[Bug lto/45557] Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
--- Comment #2 from alexey at feldgendler dot ru 2010-09-06 13:49 --- Created an attachment (id=21711) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21711action=view) Incomplete assembly file cc1plus manages to write before segfaulting -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
[Bug lto/45557] Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
--- Comment #3 from alexey at feldgendler dot ru 2010-09-06 13:51 --- $ gdb --args /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -v -D_GNU_SOURCE TC.cpp -dumpbase TC.cpp -mtune=generic -march=x86-64 -auxbase TC -O1 -version -flto -finline-small-functions -fpartial-inlining GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus...done. (gdb) r Starting program: /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -v -D_GNU_SOURCE TC.cpp -dumpbase TC.cpp -mtune=generic -march=x86-64 -auxbase TC -O1 -version -flto -finline-small-functions -fpartial-inlining GNU C++ (GCC) version 4.6.0 20100828 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100828 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++ /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/c++/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.6.0 20100828 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20100828 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 options passed: -v -D_GNU_SOURCE TC.cpp -mtune=generic -march=x86-64 -O1 -flto -finline-small-functions -fpartial-inlining options enabled: -falign-loops -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon -fcprop-registers -fdefer-pop -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types -fexceptions -fforward-propagate -ffunction-cse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -finline -finline-functions-called-once -finline-small-functions -fipa-profile -fipa-pure-const -fipa-reference -fira-share-save-slots -fira-share-spill-slots -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants -fomit-frame-pointer -fpartial-inlining -fpeephole -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-volatile-bitfields -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-sra -ftree-ter -ftree-vect-loop-version -funit-at-a-time -funwind-tables -fvar-tracking -fvar-tracking-assignments -fvect-cost-model -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387 -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-sse4 -mpush-args -mred-zone -msse -msse2 -mtls-direct-seg-refs Compiler executable checksum: 2c7dd1386f3abb6f2873be5b63c94737 int f3() Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program ipa-profile inline pure-const static-varAssembling functions: f3() Program received signal SIGSEGV, Segmentation fault. prepare_use_sites_for (update_flags=2048) at /home/xman/gcc-4.6-20100828/gcc/tree-into-ssa.c:2588 2588 edge e = gimple_phi_arg_edge (stmt, ix); (gdb) bt #0 prepare_use_sites_for (update_flags=2048) at /home/xman/gcc-4.6-20100828/gcc/tree-into-ssa.c:2588 #1 prepare_names_to_update (update_flags=2048) at /home/xman/gcc-4.6-20100828/gcc/tree-into-ssa.c:2657 #2 update_ssa (update_flags=2048) at /home/xman/gcc-4.6-20100828/gcc/tree-into-ssa.c:3291 #3
[Bug tree-optimization/44937] [4.6 Regression] IPA-split causes crash due to null pointer deref
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-09-06 13:53 --- *** Bug 45557 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||alexey at feldgendler dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44937
[Bug lto/45557] Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-06 13:53 --- Seems to be fixed by 2010-09-02 Richard Guenther rguent...@suse.de PR tree-optimization/44937 PR tree-optimization/45412 * ipa-split.c (split_function): Properly remove PHI nodes. *** This bug has been marked as a duplicate of 44937 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2010-09-06 13:57 --- (In reply to comment #44) Created an attachment (id=21709) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21709action=view) [edit] retain redefinition of MAIN_STACK_BOUNDARY as required Testsuite results for the PR36502v9.patch are shown in http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00537.html. The compiler ICEs shown for gfortran.dg/backspace_1.f, gfortran.dg/record_marker_2.f, gfortran.dg/graphite/pr42393-1.f90 libgomp.fortran/appendix-a/a.16.1.f90, libgomp.fortran/omp_atomic2.f90, libgomp.graphite/force-parallel-3.c, libgomp.graphite/force-parallel-9.c and 25_algorithms/heap/moveable.cc shouldn't be due to my patch as the identical patch (except for test cases corrections) was tested in http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00168.html and didn't show them. While I don't see these in other reported i386-apple-darwin10 testresults, those aren't using --enable-checking=yes. I will rebuild gcc trunk without PR36502v9.patch, reconfirm those ICEs and file PRs against them separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug lto/45557] Segfault with -flto -O1 -finline-small-functions -fpartial-inlining
--- Comment #5 from alexey at feldgendler dot ru 2010-09-06 14:03 --- Indeed, the patch fixes this bug for me. Thanks! -- alexey at feldgendler dot ru changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #46 from dominiq at lps dot ens dot fr 2010-09-06 14:04 --- gfortran.dg/backspace_1.f, gfortran.dg/record_marker_2.f, ... They are pr45534 and probably fixed at revision 163913 (testing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-09-06 14:12 --- I tried compiling the testcase from comment #8 and it did not fail for me either on i686-linux ox x86_64-linux. Can you please check that it still fails for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-06 14:52 --- Created an attachment (id=21712) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21712action=view) New draft patch New draft patch. New: Documentation added; REAL_KINDS and REAL_KINDS(1) works now. TODO - The test case in the file, i.e. REAL(REAL_KINDS(1)) fails with Error: Constant expression required - Include attachment 21126 as test case -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #21122|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #39 from hjl at gcc dot gnu dot org 2010-09-06 14:54 --- Subject: Bug 45524 Author: hjl Date: Mon Sep 6 14:52:54 2010 New Revision: 163921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163921 Log: Don't set enable_decimal_float to dpd if DFP is disabled. config/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * dfp.m4: Don't set enable_decimal_float to dpd if DFP is disabled. Set default_decimal_float. gcc/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure.ac (enable_decimal_float): Set to $default_decimal_float. * configure: Regenerated. libdecnumber/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure.ac (enable_decimal_float): Set to $default_decimal_float. * configure: Regenerated. libgcc/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure: Regenerated. Modified: trunk/config/ChangeLog trunk/config/dfp.m4 trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/libdecnumber/ChangeLog trunk/libdecnumber/configure trunk/libdecnumber/configure.ac trunk/libgcc/ChangeLog trunk/libgcc/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug c++/45558] New: typedef of typename fails to equal its underlying type
The code snippet below fails to compile:
=~=
template typename S, typename T
struct C
{
template typename U
struct B
{
template typename W
struct E
{
explicit E(const W x) : w(x) {}
const W w;
};
};
};
struct F;
template typename X
struct D
{
D() {}
};
const DF g;
template typename S, typename T
struct A
{
template typename U
struct B : CS, T::template BU
{
typedef typename CS, T::template BU V;
static const Dtypename V::template EDF a;
};
};
template typename S, typename T
template typename U
const Dtypename CS, T::template BU::template EDF
AS, T::BU::a = typename CS, T::template BU::template EDF (g);
=~=
With the error message:
test-620095.cc:38:16: erreur: conflicting declaration const Dtypename CS,
T::BU::EDF AS, T::BU::a
test-620095.cc:31:52: erreur: AS, T::BU::a has a previous declaration as
const Dtypename CS, T::BU::EDF AS, T::BU::a
test-620095.cc:38:16: erreur: declaration of const Dtypename CS,
T::BU::EDF AS, T::BU::a outside of class is not definition
[-fpermissive]
Fixing PR c++/45200 should fix this bug.
--
Summary: typedef of typename fails to equal its underlying type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org
BugsThisDependsOn: 45200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45558
[Bug c++/45558] typedef of typename fails to equal its underlying type
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-06 14:59:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45558
[Bug c++/45558] typedef of typename fails to equal its underlying type
--- Comment #1 from dodji at gcc dot gnu dot org 2010-09-06 15:00 --- This was forwarded here from https://bugzilla.redhat.com/show_bug.cgi?id=620095 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45558
[Bug target/45483] gcc-4.4.3: probably wrong optimization options chosen by -march=native
--- Comment #7 from hjl dot tools at gmail dot com 2010-09-06 15:08 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00469.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg00469.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-06 15:08:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45483
[Bug c/45559] New: [4.4 regression] wrong conversion from unsigned int/long to float
With the following program:
#include stdio.h
int
main()
{
unsigned int t = 254733465;
float f;
f = (float) t;
printf (t=%u f=%.0f\n, t, f);
}
I get with gcc 4.3 the expected result:
t=254733465 f=254733472
but with gcc 4.4.5:
t=254733465 f=482062944
which is clearly wrong.
Note: this was obtained on smetana.debian.org with
gcc 4.4.5 20100824 (prerelease) (Debian 4.4.4-11)
Note 2: this bug makes GMP-ECM fail:
https://buildd.debian.org/fetch.cgi?pkg=gmp-ecmarch=sparcver=6.3-2stamp=1281775571file=logas=raw
--
Summary: [4.4 regression] wrong conversion from unsigned int/long
to float
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug fortran/45560] New: debugging: Add EXPR pretty printer (gfc_debug_expr)
Richard wrote in IRC:
fortran needs a pretty-printer
gfc_show_expr is annoying as it doesn't flush and you have to manually set
dumpfile
to stdout
Untested draft patch:
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (revision 163921)
+++ dump-parse-tree.c (working copy)
@@ -48,6 +48,17 @@
static void show_code_node (int, gfc_code *);
static void show_namespace (gfc_namespace *ns);
+/* Allow dumping of an expression in the debugger. */
+void gfc_debug_expr (gfc_expr *);
+void
gfc_debug_expr (gfc_expr *e)
+{
+ FILE *tmp = dumpfile;
+ dumpfile = stdout;
+ show_expr (e)
+ fputc ('\n', dumpfile);
+ dumpfile = tmp;
+}
/* Do indentation for a specific level. */
--
Summary: debugging: Add EXPR pretty printer (gfc_debug_expr)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
--- Comment #4 from doko at ubuntu dot com 2010-09-06 15:56 --- I can confirm this with 20100902 from the 4.5 branch. the profiled bootstrap did work with the 4.5.1 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
[Bug libobjc/19850] libobjc leaks threads on posix
--- Comment #3 from nicola at gcc dot gnu dot org 2010-09-06 15:57 --- Subject: Bug 19850 Author: nicola Date: Mon Sep 6 15:57:44 2010 New Revision: 163923 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163923 Log: PR libobjc/19850 * gthr-posix.h (__gthread_objc_thread_detach): Use _objc_thread_attribs when detaching a thread. * gthr-posix95.h (__gthread_objc_thread_detach): Same change. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug libobjc/19850] libobjc leaks threads on posix
--- Comment #4 from nicola dot pero at meta-innovation dot com 2010-09-06 15:58 --- I fixed this bug in trunk (will be GCC 4.6.0). -- nicola dot pero at meta-innovation dot com changed: What|Removed |Added CC||nicola dot pero at meta- ||innovation dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug preprocessor/45561] New: [4.4 Regression]: gcc.dg/cpp/pragma-float-const-decimal64-1.c gcc.dg/nodfp-1.c
With revision 163809 these test passed. From revision 163818 and on, the tests have failed as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/cpp/cpp.exp ... FAIL: gcc.dg/cpp/pragma-float-const-decimal64-1.c (test for warnings, line 4) ... Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/dg.exp ... ... FAIL: gcc.dg/nodfp-1.c reject decimal float (test for errors, line 4) FAIL: gcc.dg/nodfp-1.c reject decimal float (test for errors, line 5) FAIL: gcc.dg/nodfp-1.c reject decimal float (test for errors, line 6) Looks like it's some mixup of /no/dpd somewhere... It looks like the dfp.m4 patch is wrong, enabling dfp half-way, such that the parser and preprocessor doesn't see that it's not supported, but the target still isn't dfp as far as the test-suite is concerned (and it shouldn't): Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ dfprt16050. c-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newl ib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/ cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./new lib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o dfprt16050.exe(timeout = 300) dfprt16050.c:2:2: error: unable to emulate 'DD' compiler exited with status 1 output is: dfprt16050.c:2:2: error: unable to emulate 'DD' Author of suspect patch in the revision range CC:ed. -- Summary: [4.4 Regression]: gcc.dg/cpp/pragma-float-const- decimal64-1.c gcc.dg/nodfp-1.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45561
[Bug other/45561] [4.6 Regression]: gcc.dg/cpp/pragma-float-const-decimal64-1.c gcc.dg/nodfp-1.c
--- Comment #1 from hp at gcc dot gnu dot org 2010-09-06 16:08 --- Correct title, possibly component, milestone. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|preprocessor|other Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-06 16:08:27 date|| Summary|[4.4 Regression]: |[4.6 Regression]: |gcc.dg/cpp/pragma-float-|gcc.dg/cpp/pragma-float- |const-decimal64-1.c |const-decimal64-1.c |gcc.dg/nodfp-1.c|gcc.dg/nodfp-1.c Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45561
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-06 16:20 --- Subject: Re: [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table Unfortunately, even with your patch the mips-sgi-irix6.5 Ada bootstrap is still broken. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel
--- Comment #16 from uweigand at gcc dot gnu dot org 2010-09-06 16:57 --- (In reply to comment #15) Ulrih, I've just wanted to post the following when I found that you already posted analogous conclusion. I should have been on CC to see your comment right away. The problem is really fundamental. Code for merge_assigned_reloads ignores inheritance (and dependencies between reloads because of inheritance) at all. Here is my post wanted to add. I just noticed that even in the complete absence of reload inheritance, the allocate_reload_reg routine performs free_for_value_p checks, and therefore implicitly takes reload ordering into account. This seems to imply that even if we'd do merge_assigned_reloads only if no inheritance has taken place, we'd still have a problem. Does anybody have any idea how much merge_assigned_reloads actually contributes to performance on i386, in particular now that we have a bit more post-reload optimizers that potentially clear up duplicate code of the type generated by unmerged reloads? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-06 17:08 --- Created an attachment (id=21713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21713action=view) Draft patch, tested x86_64-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug other/45561] [4.6 Regression]: gcc.dg/cpp/pragma-float-const-decimal64-1.c gcc.dg/nodfp-1.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-06 17:10 --- *** This bug has been marked as a duplicate of 45524 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45561
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #40 from hjl dot tools at gmail dot com 2010-09-06 17:10 --- *** Bug 45561 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
--- Comment #1 from mikpe at it dot uu dot se 2010-09-06 17:15 --- Dupe of PR44631? -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #41 from hjl dot tools at gmail dot com 2010-09-06 17:18 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- Comment #9 from marc dot glisse at normalesup dot org 2010-09-06 17:48 --- (In reply to comment #8) Draft patch, tested x86_64-linux Nice. Just to confirm, that's indeed what I had in mind, except that I was going to rename __is_iterator_helper to __has_iterator_category and move ||is_pointer from the helper to __is_iterator (and then use __has_iterator_category for __iterator_traits). But it is equivalent. Now to the hardest part: deciding whether to apply it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug target/22152] Poor loop optimization when using mmx builtins
--- Comment #12 from uros at gcc dot gnu dot org 2010-09-06 17:51 --- Subject: Bug 22152 Author: uros Date: Mon Sep 6 17:51:12 2010 New Revision: 163926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163926 Log: PR target/22152 * config/i386/mmx.md (*movmode_internal_rex64, *movmode_internal_avx, *movmode_internal, *movv2sf_internal_rex64_avx, *movv2sf_internal_rex64, *movv2sf_internal_avx, *movv2sf_internal): Split out !y-!y alternative. [ Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug target/22152] Poor loop optimization when using mmx builtins
--- Comment #13 from uros at gcc dot gnu dot org 2010-09-06 17:55 --- Subject: Bug 22152 Author: uros Date: Mon Sep 6 17:54:46 2010 New Revision: 163927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163927 Log: PR target/22152 * gcc.target/i386/pr22152.c (add3): Change count to unsigned int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr22152.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-06 17:55 --- More failures: use iso_fortran_env integer :: i print *, shape(real_kinds(1)) ! should be rejected (scalar) i = real_kinds(1) ! ICE end Thus, the FE has problems if one takes a REF of an EXPR_ARRAY, i.e. the shape does not get updated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #15 from iains at gcc dot gnu dot org 2010-09-06 18:07 --- (In reply to comment #14) Subject: Bug 45534 New Revision: 163913 2010-09-06 Richard Guenther rguent...@suse.de PR tree-optimization/45534 * tree-ssa-address.c (create_mem_ref_raw): Add verify parameter. (create_mem_ref): Do verify the created TARGET_MEM_REF is valid on the target. (maybe_fold_tmr): Do not verify the created TARGET_MEM_REF is valid on the target. fixed on i686-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug target/22152] Poor loop optimization when using mmx builtins
--- Comment #14 from ubizjak at gmail dot com 2010-09-06 18:13 --- Fixed again. -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-06 18:17 --- Subject: Bug 45560 Author: burnus Date: Mon Sep 6 18:16:50 2010 New Revision: 163928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163928 Log: 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/45560 * dump-parse-tree.c (gfc_debug_expr): New function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-06 18:17 --- FIXED for 4.6. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-06 18:25 --- Created an attachment (id=21714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21714action=view) Patch to address IPA-CP parameter removal issues This patch makes IPA-CP to refrain from modifying a function when it sees a any type attributes. It fixes the test case. I do not expect it to cause any problems elsewhere but I have not yet bootstrapped or tested it (I have just scheduled both for tonight). As far as I understand it there is already a test in our testsuite that fails (with the patch from comment #7 applied) and so I am not going to add an extra one. I think it's best to check this in separately and I will submit it for approval tomorrow if there are no unforeseen problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
--- Comment #16 from dominiq at lps dot ens dot fr 2010-09-06 18:27 --- New Revision: 163913 fixed on i686-darwin9. also on x86_64-apple-darwin10.4 configured with --enable-checking=release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug libobjc/19850] libobjc leaks threads on posix
--- Comment #5 from nicola at gcc dot gnu dot org 2010-09-06 18:30 --- Fixed in trunk. Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-09-06 18:40 --- Still present for x86_64-unknown-gnu-linux with -m32 at r163927 when tested on x86_64 Fedora 10 using the new gcc/gcc/testsuite/gcc.dg/torture/stackalign/alloca-5.c test case only from gcc-pr45234-2.patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #17 from burnus at gcc dot gnu dot org 2010-09-06 18:43 --- (In reply to comment #16) This patch makes IPA-CP to refrain from modifying a function when it sees a any type attributes. In a way that's unfortunate: Both fn attr and argument removal are optimization options. As far as I understand it there is already a test in our testsuite that fails (with the patch from comment #7 applied) and so I am not going to add an extra one. OK. I think it's best to check this in separately and I will submit it for approval tomorrow if there are no unforeseen problems. I will also submit my patch - for committal after yours is in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation
--- Comment #11 from dodji at gcc dot gnu dot org 2010-09-06 18:44 --- Subject: Bug 45200 Author: dodji Date: Mon Sep 6 18:44:23 2010 New Revision: 163929 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163929 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef34.C trunk/gcc/testsuite/g++.dg/template/typedef35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45558] typedef of typename fails to equal its underlying type
--- Comment #2 from dodji at gcc dot gnu dot org 2010-09-06 18:44 --- Subject: Bug 45558 Author: dodji Date: Mon Sep 6 18:44:23 2010 New Revision: 163929 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163929 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef34.C trunk/gcc/testsuite/g++.dg/template/typedef35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45558
[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589
--- Comment #9 from dodji at gcc dot gnu dot org 2010-09-06 18:44 --- Subject: Bug 45293 Author: dodji Date: Mon Sep 6 18:44:23 2010 New Revision: 163929 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163929 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef34.C trunk/gcc/testsuite/g++.dg/template/typedef35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation
--- Comment #12 from dodji at gcc dot gnu dot org 2010-09-06 18:50 --- Subject: Bug 45200 Author: dodji Date: Mon Sep 6 18:49:46 2010 New Revision: 163930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163930 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef34.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef35.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/tree.c branches/gcc-4_5-branch/gcc/cp/typeck.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589
--- Comment #10 from dodji at gcc dot gnu dot org 2010-09-06 18:50 --- Subject: Bug 45293 Author: dodji Date: Mon Sep 6 18:49:46 2010 New Revision: 163930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163930 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef34.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef35.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/tree.c branches/gcc-4_5-branch/gcc/cp/typeck.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
[Bug c++/45558] typedef of typename fails to equal its underlying type
--- Comment #3 from dodji at gcc dot gnu dot org 2010-09-06 18:50 --- Subject: Bug 45558 Author: dodji Date: Mon Sep 6 18:49:46 2010 New Revision: 163930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163930 Log: Patch PR c++/45200 Fix PR c++/45200, c++/45293, c++/45558 gcc/cp/Changelog: PR c++/45200 PR c++/45293 PR c++/45558 * tree.c (strip_typedefs): Strip typedefs from the context of TYPENAME_TYPEs. gcc/testsuite/ChangeLog: PR c++/45200 PR c++/45293 PR c++/45558 * g++.dg/template/typedef34.C: New test. * g++.dg/template/typedef35.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef34.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/typedef35.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/tree.c branches/gcc-4_5-branch/gcc/cp/typeck.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45558
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #3 from burnus at gcc dot gnu dot org 2010-09-06 18:52 --- Subject: Bug 45560 Author: burnus Date: Mon Sep 6 18:51:48 2010 New Revision: 163931 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163931 Log: 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/45560 * dump-parse-tree.c (gfc_debug_expr): Use stderr instead of stdout. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug c++/45562] New: [4.6 Regression] ICE: SIGSEGV in cp_build_unary_op (typeck.c:5083) with -std=gnu++0x -fipa-cp-clone -fcompare-debug
Command line: $ gcc -std=gnu++0x -O -fno-inline -fipa-cp -fipa-cp-clone -fcompare-debug testcase.C Related valgrind output: $ valgrind -q --trace-children=yes /mnt/svn/gcc-trunk/binary-163921-lto-fortran-checking-yes-rtl-df/bin/gcc -std=gnu++0x -O1 -fno-inline -fipa-cp -fipa-cp-clone -fcompare-debug testcase.C ==29279== Invalid read of size 8 ==29279==at 0x5D244C: cp_build_unary_op (typeck.c:5083) ==29279==by 0x4E0E81: build_new_method_call (call.c:6461) ==29279==by 0x53C33D: tsubst_copy_and_build (pt.c:12572) ==29279==by 0x52D1B8: tsubst_expr (pt.c:12054) ==29279==by 0x533C43: tsubst (pt.c:10696) ==29279==by 0x5961E0: dump_function_decl (error.c:315) ==29279==by 0x5968F8: decl_as_string (error.c:2372) ==29279==by 0x612CA9: cxx_printable_name_internal (tree.c:1440) ==29279==by 0xAA375D: dump_enumerated_decls (tree-ssa-live.c:1268) ==29279==by 0xA406F8: execute_cleanup_cfg_post_optimizing (tree-optimize.c:214) ==29279==by 0x8FD47E: execute_one_pass (passes.c:1569) ==29279==by 0x8FD724: execute_pass_list (passes.c:1624) ==29279== Address 0x20 is not stack'd, malloc'd or (recently) free'd ==29279== gcc: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r163921 - crash r163636 - crash r161659 - OK r161170 - OK 4.5 r163761 - OK -- Summary: [4.6 Regression] ICE: SIGSEGV in cp_build_unary_op (typeck.c:5083) with -std=gnu++0x -fipa-cp-clone - fcompare-debug Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45562
[Bug c++/45562] [4.6 Regression] ICE: SIGSEGV in cp_build_unary_op (typeck.c:5083) with -std=gnu++0x -fipa-cp-clone -fcompare-debug
--- Comment #1 from zsojka at seznam dot cz 2010-09-06 19:38 --- Created an attachment (id=21715) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21715action=view) reduced testcase (from libstdc++-v3/testsuite/21_strings/basic_string/range_access.cc) $ gcc -std=gnu++0x -O -fno-inline -fipa-cp -fipa-cp-clone -fcompare-debug pr45562.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45562
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-09-06 19:44 --- Subject: Bug 34145 Author: tkoenig Date: Mon Sep 6 19:43:58 2010 New Revision: 163932 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163932 Log: 2010-09-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/34145 * trans-expr.c (gfc_conv_substring): If start and end of the string reference are equal, set the length to one. 2010-09-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/34145 * gfortran.dg/char_length_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-09-06 19:44 --- Fixed on trunk, closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
