[Bug tree-optimization/48497] gfortran.dg/graphite/vect-pr40979.f90 FAILs without -march=pentium4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48497 --- Comment #1 from Allan McRae allan at archlinux dot org 2011-04-11 06:12:28 UTC --- I see the same failure with -march=i686 on i686-pc-linux-gnu with gcc-4.6.0. Using -march=pentium4 makes this pass.
[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48547 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #17 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 06:26:43 UTC --- -fpack-struct changes the ABI so you really can't use this option unless you compile everything with it.
[Bug rtl-optimization/48549] New: [4.6/4.7 Regression] Combiner ICE with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48549
Summary: [4.6/4.7 Regression] Combiner ICE with -g
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
void
foo (void *from, void *to)
{
long offset = reinterpret_cast long(to) - reinterpret_cast long(from);
if (offset != static_cast int(offset))
*(int *) 0xC0DE = 0;
reinterpret_cast int *(from)[1] = offset;
}
struct A
{
A () : a () {}
A (void *x) : a (x) {}
void *bar () { return a; }
void *a;
};
struct C;
struct D;
struct E : public A
{
C m1 (int);
D m2 ();
E () {}
E (A x) : A (x) {}
};
struct C : public E
{
C () {}
C (void *x) : E (x) {}
};
struct D : public E
{
D (void *x) : E (x) {}
};
C
E::m1 (int x)
{
return (reinterpret_cast char *(bar ()) + x);
}
D
E::m2 ()
{
return reinterpret_cast char *(bar ());
}
struct B
{
E a;
unsigned b : 16;
unsigned c : 1;
};
void
baz (B *x)
{
for (unsigned i = 0; i 64; i++)
{
D d = x[i].a.m2 ();
C c = x[i].a.m1 (x[i].c);
foo (d.bar (), c.bar ());
}
}
ICEs with -g -O2 on x86_64-linux, starting with 172109/172110.
[Bug bootstrap/48520] make install for cross-compile silently clobbers target-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48520
--- Comment #2 from tim.vanholder at anubex dot com 2011-04-11 06:56:27 UTC ---
Fair enough.
However, this was the _only_ (noticeable) breakage resulting from this
configuration.
If that's really all there is I don't see why this couldn't/shouldn't simply be
handled by the makefile rule.
Also, I don't really understand why it's ok for make install to silently
ignore errors during the creation of the (hard links to the) binaries in the
installation tree. That seems to be a rather fundamental aspect of make
install.
If there are more (hidden) breakages resulting from this, maybe this
program-prefix should not be 'target-' rule should be enforced by configure
(as far as I can tell, it's not mentioned anywhere in the source tree).
In fact, gcc/configure currently includes
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n $target_alias
test $program_prefix$program_suffix$program_transform_name = \
NONENONEs,x,x,
program_prefix=${target_alias}-
so it even explictly sets the program prefix to the target_alias (if one is
given), meaning that even if I had not explicitly given
--program-prefix=mingw32-, configure would have set that up for me
automatically (provided I also left off the --program-suffix, which for a
cross-compiler would not be entirely needed either).
So I guess the only issue is when both prefix suffix are set to the standard
ones used during installation, which should be handled perfectly well by
adjusting gcc/Makefile.am to only do the rm+ln if GCC_INSTALL_NAME does not
match the canon_target-gcc-version construct.
[Bug target/47908] attribute((optimize(2))) causes ICE in m68k_sched_issue_rate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47908 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-04-11 07:36:17 UTC --- I have fully tested patches to fix this for 4.4.5, 4.5.2, and 4.6.0 (presumably that one will also work for 4.7 but I haven't checked), but I've avoided posting them because the FSF hasn't yet confirmed that my copyright assignment is in place. (They've had the papers for ages.) I just pinged them again. Meanwhile you can just comment out any offending attribute((optimize(...))).
[Bug c++/48534] [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48534 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-04-11 07:40:56 UTC --- I would like to add that the silent-death behaviour seems to be an unfortunate behaviour of my Cygwin environment. In non-Cygwin environments that program provokes a compiler segmentation fault, thus the problem is real, but the description of the observable behaviour possibly misleading.
[Bug lto/48548] recent svn version gcc (4.6? 4.7?) compile failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.04.11 07:42:50 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-11 07:42:50 UTC --- Please see http://gcc.gnu.org/bugs/ for the information needed in a bug report. You haven't said what your system is or how you configured gcc.
[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48547 --- Comment #18 from Jim Michaels jmichae3 at yahoo dot com 2011-04-11 07:48:08 UTC --- I will admit I have not tried this with any VC++ compiler newer than VC++ 6.0, which is circa windows NT/98 era. things have changed a lot since then. I know this works in Borland C++ 5.5.1 free edition and VC++ 6.0 (very old). But the STL was upgraded since then and TR1 came out. So things maybe don't work like they used to on any compiler? maybe no more static linking on any compiler? You are right, I was just reading about why you can't (and shouldn't) statically link libstdc++ in a blog... It was kind of disappointing. I really wanted to make monolithic executables for the main reason that you can't put 32-bit and 64-bit libstdc++ DLL's and gcc runtime DLL's (shared libraries) and executables in the same directory! and the installer I use (NSIS) won't run your programs properly (because the shortcuts are lame) if your executables and all your files aren't all in the same directory. and you can't just add them to the path either because that's broken. it sounds to me from your post that it would be a lot of extra work for the compiler builders, making 2 sets of binaries for the cases of -fpack-struct and not -fpack-struct. If this could be accomplished and even have statically linked libstdc++ (at least the latter) I think a lot of people would be very happy, and for the former, a lot of compiler users would be a lot less disgruntled with g++. so... why is -fpack-struct even there? is it for gcc only and not for g++? because it works fine for ANSI C. just not any lib with dependent upon iostream (like iterator - gaah!). by the way, in the header files of the C++ files where I see the structures defined for win32, I *don't* remember ever seeing see #pragma pack(). but yes, it is in VC++. I just put a link to #pragma pack() on my web site for new compiler users. I've been writing programs in C for about 20 years and I have not learned about this until now. never heard about it. nobody talks about it.
[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48547 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-11 07:56:16 UTC --- (In reply to comment #18) it sounds to me from your post that it would be a lot of extra work for the compiler builders, making 2 sets of binaries for the cases of -fpack-struct and not -fpack-struct. If this could be accomplished and even have statically linked libstdc++ (at least the latter) I think a lot of people would be very happy, and for the former, a lot of compiler users would be a lot less disgruntled with g++. I think you overestimate the number of people who care about this issue. so... why is -fpack-struct even there? is it for gcc only and not for g++? because it works fine for ANSI C. just not any lib with dependent upon iostream (like iterator - gaah!). It works ok for some C++ code, but not if you include the standard library headers. by the way, in the header files of the C++ files where I see the structures defined for win32, I *don't* remember ever seeing see #pragma pack(). but yes, it is in VC++. I just put a link to #pragma pack() on my web site for new compiler users. I've been writing programs in C for about 20 years and I have not learned about this until now. never heard about it. nobody talks about it. It's documented in the manual: http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
[Bug lto/48548] recent svn version gcc (4.6? 4.7?) compile failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548 --- Comment #2 from kuh3h3 at gmail dot com 2011-04-11 09:02:27 UTC --- my system is ubuntu natty. build env is source ccompiled version. cloog-ppl-0.15.11(ppl legacy), cloog.git(isl),gmp-5.0.1,libelf-0.8.13, mpfr-3.0.1,mpc-svn, ppl.git, [/media/sdc2/gcc-build/gcc-trunk]$ LANG=C svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 172239 Node Kind: directory Schedule: normal Last Changed Author: ebotcazou Last Changed Rev: 172239 Last Changed Date: 2011-04-10 19:31:14 +0900 (Sun, 10 Apr 2011) first isl build configure option: ./configure --prefix=/media/sdc2/gcc-4.5.1 --with-gmp=/media/sdc2/gcc-4.5.1 --with-mpfr=/media/sdc2/gcc-4.5.1 --with-mpc=/media/sdc2/gcc-4.5.1 --program-suffix=-46 --with-ppl=/media/sdc2/gcc-4.5.1 --with-cloog=/media/sdc2/gcc-4.5.1 --disable-multilib -with-stage1-ldflags=-Wl,-rpath,/me dia/sdc2/gcc-4.5.1/lib -with-boot-ldflags=-Wl,-rpath,/media/sdc2/gcc-4.5.1/lib --without-included-gettext --enable-checking=release --disable-c loog-version-check --with-libelf=/media/sdc2/gcc-4.5.1 --enable-lto --enable-werror=no --enable-cloog-backend=isl second ppl-legacy build configure option: ./configure --prefix=/media/sdc2/gcc-4.5.1 --with-gmp=/media/sdc2/gcc-4.5.1 --with-mpfr=/media/sdc2/gcc-4.5.1 --with-mpc=/media/sdc2/gcc-4.5.1 --program-suffix=-46 --with-ppl=/media/sdc2/gcc-4.5.1 --with-cloog=/media/sdc2/gcc-4.5.1 --disable-multilib -with-stage1-ldflags=-Wl,-rpath,/me dia/sdc2/gcc-4.5.1/lib -with-boot-ldflags=-Wl,-rpath,/media/sdc2/gcc-4.5.1/lib --without-included-gettext --enable-checking=release --disable-c loog-version-check --with-libelf=/media/sdc2/gcc-4.5.1 --enable-lto --enable-werror=no --enable-cloog-backend=ppl-legacy
[Bug middle-end/47976] [4.5/4.6/4.7 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976 --- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-11 09:03:55 UTC --- Patch posted here and waiting for feedback. http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00540.html
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #51 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-11 09:09:37 UTC --- (In reply to comment #50) The original problem in comment #0 fails (i.e. the build of CP2K) with trunk 4.7, at what I believe is essentially the same issue. Unfortunately the smaller testcase (comment #1) doesn't fail anymore. /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F: In function ‘calculate_jrho_resp’: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F:612:0: error: non-trivial conversion at assignment Could you try to reduce the test case?
[Bug lto/48548] recent svn version gcc (4.6? 4.7?) compile failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548 --- Comment #3 from kuh3h3 at gmail dot com 2011-04-11 09:13:51 UTC --- ^_^[/media/sdc2/gcc-build/gcc-trunk]$ ls -al /media/sdc2/gcc-4.5.1/include/cloog* 합계 152 drwxr-xr-x 4 gagemel gagemel 4096 4월 11 11:03 . drwxr-xr-x 6 gagemel gagemel 4096 4월 11 12:37 .. -rw-r--r-- 1 gagemel gagemel 7056 4월 11 11:03 block.h -rw-r--r-- 1 gagemel gagemel 3248 4월 11 11:03 clast.h -rw-r--r-- 1 gagemel gagemel 2217 4월 11 11:03 cloog-config.h -rw-r--r-- 1 gagemel gagemel 5070 4월 11 11:03 cloog.h -rw-r--r-- 1 gagemel gagemel 6637 4월 11 08:46 constraints.h -rw-r--r-- 1 gagemel gagemel 6994 4월 11 11:03 domain.h -rw-r--r-- 1 gagemel gagemel 506 4월 11 08:46 input.h -rw-r--r-- 1 gagemel gagemel 5662 4월 11 08:46 int.h drwxr-xr-x 2 gagemel gagemel 4096 4월 11 08:46 isl -rw-r--r-- 1 gagemel gagemel 7140 4월 11 11:03 loop.h drwxr-xr-x 2 gagemel gagemel 4096 4월 11 08:46 matrix -rw-r--r-- 1 gagemel gagemel 2229 4월 11 08:46 matrix.h -rw-r--r-- 1 gagemel gagemel 7411 4월 11 11:03 names.h -rw-r--r-- 1 gagemel gagemel 6909 4월 11 11:03 options.h -rw-r--r-- 1 gagemel gagemel 2473 4월 11 11:03 polylib_backend.h -rw-r--r-- 1 gagemel gagemel 15186 4월 11 11:03 ppl_backend.h -rw-r--r-- 1 gagemel gagemel 3160 4월 11 11:03 pprint.h -rw-r--r-- 1 gagemel gagemel 7213 4월 11 11:03 program.h -rw-r--r-- 1 gagemel gagemel 772 4월 11 08:46 state.h -rw-r--r-- 1 gagemel gagemel 4718 4월 11 11:03 statement.h -rw-r--r-- 1 gagemel gagemel 721 4월 11 08:46 stride.h -rw-r--r-- 1 gagemel gagemel 1543 4월 11 08:46 union_domain.h -rw-r--r-- 1 gagemel gagemel 3257 4월 11 11:03 version.h ^_^[/media/sdc2/gcc-build/gcc-trunk]$ ls -al /media/sdc2/gcc-4.5.1/include/cloog*/isl 합계 24 drwxr-xr-x 2 gagemel gagemel 4096 4월 11 08:46 . drwxr-xr-x 4 gagemel gagemel 4096 4월 11 11:03 .. -rw-r--r-- 1 gagemel gagemel 186 4월 11 08:46 backend.h -rw-r--r-- 1 gagemel gagemel 350 4월 11 08:46 cloog.h -rw-r--r-- 1 gagemel gagemel 596 4월 11 08:46 constraintset.h -rw-r--r-- 1 gagemel gagemel 700 4월 11 08:46 domain.h ^_^[/media/sdc2/gcc-build/gcc-trunk]$ ls -al /media/sdc2/gcc-4.5.1/lib/*cloog* -rw-r--r-- 1 gagemel gagemel 190844 4월 11 08:46 /media/sdc2/gcc-4.5.1/lib/libcloog-isl.a -rwxr-xr-x 1 gagemel gagemel 1051 4월 11 08:46 /media/sdc2/gcc-4.5.1/lib/libcloog-isl.la lrwxrwxrwx 1 gagemel gagemel 21 4월 11 08:46 /media/sdc2/gcc-4.5.1/lib/libcloog-isl.so - libcloog-isl.so.1.0.2 lrwxrwxrwx 1 gagemel gagemel 21 4월 11 08:46 /media/sdc2/gcc-4.5.1/lib/libcloog-isl.so.1 - libcloog-isl.so.1.0.2 -rwxr-xr-x 1 gagemel gagemel 148806 4월 11 08:46 /media/sdc2/gcc-4.5.1/lib/libcloog-isl.so.1.0.2 -rw-r--r-- 1 gagemel gagemel 478660 4월 11 11:03 /media/sdc2/gcc-4.5.1/lib/libcloog.a -rwxr-xr-x 1 gagemel gagemel 1269 4월 11 11:03 /media/sdc2/gcc-4.5.1/lib/libcloog.la lrwxrwxrwx 1 gagemel gagemel 17 4월 11 11:03 /media/sdc2/gcc-4.5.1/lib/libcloog.so - libcloog.so.0.0.0 lrwxrwxrwx 1 gagemel gagemel 17 4월 11 11:03 /media/sdc2/gcc-4.5.1/lib/libcloog.so.0 - libcloog.so.0.0.0 -rwxr-xr-x 1 gagemel gagemel 391663 4월 11 11:03 /media/sdc2/gcc-4.5.1/lib/libcloog.so.0.0.0 ^_^[/media/sdc2/gcc-build/gcc-trunk]$ ls -al /media/sdc2/gcc-4.5.1/lib/*ppl* -rw-r--r-- 1 gagemel gagemel 26942652 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl.a -rwxr-xr-x 1 gagemel gagemel 1149 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl.la lrwxrwxrwx 1 gagemel gagemel 16 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl.so - libppl.so.10.0.0 lrwxrwxrwx 1 gagemel gagemel 16 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl.so.10 - libppl.so.10.0.0 -rwxr-xr-x 1 gagemel gagemel 13291014 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl.so.10.0.0 lrwxrwxrwx 1 gagemel gagemel 15 12월 5 02:35 /media/sdc2/gcc-4.5.1/lib/libppl.so.7 - libppl.so.7.1.0 -rwxr-xr-x 1 gagemel gagemel 7702856 12월 5 02:35 /media/sdc2/gcc-4.5.1/lib/libppl.so.7.1.0 -rw-r--r-- 1 gagemel gagemel 72109206 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl_c.a -rwxr-xr-x 1 gagemel gagemel 1260 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl_c.la lrwxrwxrwx 1 gagemel gagemel 17 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl_c.so - libppl_c.so.4.0.0 lrwxrwxrwx 1 gagemel gagemel 17 12월 5 02:35 /media/sdc2/gcc-4.5.1/lib/libppl_c.so.2 - libppl_c.so.2.1.0 -rwxr-xr-x 1 gagemel gagemel 23202626 12월 5 02:35 /media/sdc2/gcc-4.5.1/lib/libppl_c.so.2.1.0 lrwxrwxrwx 1 gagemel gagemel 17 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl_c.so.4 - libppl_c.so.4.0.0 -rwxr-xr-x 1 gagemel gagemel 36396437 4월 11 11:00 /media/sdc2/gcc-4.5.1/lib/libppl_c.so.4.0.0 /media/sdc2/gcc-4.5.1/lib/ppl: 합계 36284 drwxr-xr-x 2 gagemel gagemel 4096 4월 11 11:01 . drwxr-xr-x 8 gagemel gagemel 4096 4월 11 12:38 .. -rwxr-xr-x 1 gagemel gagemel 1235 4월 11 11:01 libppl_java.la -rwxr-xr-x 1 gagemel gagemel 37019115 4월 11 11:01 libppl_java.so -rw-r--r-- 1 gagemel gagemel74624 4월 11 11:01 ppl_java.jar ^_^[/media/sdc2/gcc-build/gcc-trunk]$ ls -al
[Bug lto/48548] recent svn version gcc (4.6? 4.7?) compile failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-11 09:17:30 UTC --- Thanks. Why is this Component=lto and Version=lto ?
[Bug other/48550] New: configure script help doesn't describe -enable-languages option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48550 Summary: configure script help doesn't describe -enable-languages option Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: aponomare...@ispras.ru Hi, My options to configure the GCC are usually the following: $ ./configure --prefix=/usr --enable-languages=c,c++ So, the --enable-languages option exists and works properly. But the help message of the configure script doesn't contain the description for the -enable-languages option at all: $ ./configure --help|grep enable-languages gives an empty output.
[Bug lto/48548] recent svn version gcc (4.6? 4.7?) compile failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548 --- Comment #5 from kuh3h3 at gmail dot com 2011-04-11 09:23:35 UTC --- sorry i didn`t know where this error go to. where i say this cloog related error to? not lto?
[Bug c++/48551] New: Following source code crashes the c++ compiler on coldfire platform.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551 Summary: Following source code crashes the c++ compiler on coldfire platform. Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: miro.kropa...@gmail.com m68k-atari-mint-g++ -v -fomit-frame-pointer -mcpu=5475 -g -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi -I. -c Splash.ii Using built-in specs. COLLECT_GCC=m68k-atari-mint-g++ COLLECT_LTO_WRAPPER=/home/mikro/gnu-tools/libexec/gcc/m68k-atari-mint/4.5.2/lto-wrapper Target: m68k-atari-mint Configured with: ../gcc-4.5.2/configure --target=m68k-atari-mint --prefix=/home/mikro/gnu-tools --enable-languages=c,c++ --disable-nls --disable-libstdcxx-pch 'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' Thread model: single gcc version 4.5.2 (MiNT 20110206) (GCC) COLLECT_GCC_OPTIONS='-v' '-fomit-frame-pointer' '-mcpu=5475' '-g' '-O2' '-DHAVE_CONFIG_H' '-I..' '-I./../goo' '-I./../fofi' '-I.' '-c' /home/mikro/gnu-tools/libexec/gcc/m68k-atari-mint/4.5.2/cc1plus -fpreprocessed Splash.ii -quiet -dumpbase Splash.ii -mcpu=5475 -auxbase Splash -g -O2 -version -fomit-frame-pointer -o /tmp/ccEwEpj3.s GNU C++ (GCC) version 4.5.2 (MiNT 20110206) (m68k-atari-mint) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.2 (MiNT 20110206) (m68k-atari-mint) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 7c132bafa38d6cea47b5bd54ad75cb89 Splash.cc: In member function 'void Splash::flattenCurve(SplashCoord, SplashCoord, SplashCoord, SplashCoord, SplashCoord, SplashCoord, SplashCoord, SplashCoord, SplashCoord*, SplashCoord, SplashPath*)': Splash.cc:1380:1: error: unrecognizable insn: (insn 385 384 20 2 Splash.cc:1320 (set (reg:DF 16 %fp0) (mem/c/i:DF (plus:SI (reg/f:SI 15 %sp) (reg:SI 0 %d0)) [3 x0+0 S8 A32])) -1 (nil)) Splash.cc:1380:1: internal compiler error: in extract_insn, at recog.c:2103 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It's true m68k-atari-mint is not officially supported but I believe this is common coldfire problem. For example, if I replace -mcpu=5475 with -m68020-60, it works like a charm.
[Bug c++/48551] Following source code crashes the c++ compiler on coldfire platform.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551 --- Comment #1 from Miro Kropacek miro.kropacek at gmail dot com 2011-04-11 09:48:18 UTC --- Created attachment 23953 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23953 Test case
[Bug c/48546] lto-wrapper returned 1 exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48546 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.04.11 09:50:43 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-11 09:50:43 UTC --- There is not enough information in this bugreport. Please also consider updating GCC to 4.6.0, the LTO support in 4.5.x is still very experimental and at least partial linking will not work reliably.
[Bug c/48545] dereferencing does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48545 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-11 09:55:45 UTC --- As Dimitry says.
[Bug other/48550] configure script help doesn't describe -enable-languages option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48550 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-04-11 10:00:11 UTC --- $ ./configure --help=recursive | grep enable-languages --enable-languages=LIST specify which front-ends to build
[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48549 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug other/48550] configure script help doesn't describe -enable-languages option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48550 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-11 10:03:29 UTC --- Note also that GCC configurys main documentation is in install.texi.
[Bug fortran/48543] Collapse identical strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2011-04-11 10:04:50 UTC --- For string constants, I agree, though I doubt whether it's worth the bother. For string variables, I think this would be a mistake. Review the long and sordid history of COW implementations of the C++ std::string type for arguments why.
[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48090 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-04-11 10:24:09 UTC --- (In reply to comment #10) (In reply to comment #9) I confirm that backporting r159644 and r159683 make things work. From comment 8, I guess that the bug is still there and that one can still hit it sooner or later, right ? (btw, amazing job) It probably papers over it as you guessed. This bug lacks proper analysis. The problem is latent in all versions of the compiler and is to do with the pattern *arm_negdi2 and has nothing to do with the afore mentioned revisions. Will submit this after a round of testing. Index: gcc/config/arm/arm.md === --- gcc/config/arm/arm.md(revision 172252) +++ gcc/config/arm/arm.md(working copy) @@ -3554,7 +3554,7 @@ ;; The constraints here are to prevent a *partial* overlap (where %Q0 == %R1). ;; The first alternative allows the common case of a *full* overlap. (define_insn *arm_negdi2 - [(set (match_operand:DI 0 s_register_operand =r,r) + [(set (match_operand:DI 0 s_register_operand =r,r) (neg:DI (match_operand:DI 1 s_register_operand 0,r))) (clobber (reg:CC CC_REGNUM))] TARGET_ARM
[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48549 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.11 10:28:32 CC||ebotcazou at gcc dot ||gnu.org Version|4.6.0 |4.6.1 Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-11 10:28:32 UTC --- Confirmed.
[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|bootstrap |lto AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-11 10:52:00 UTC --- Looking into it.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #80 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-11 11:00:05 UTC --- Hi, in the resolution files, the swap functions are already undefined 5382 3d06433b UNDEF __assert_fail 5400 3d06433b UNDEF _ZN15Elf_Ehdr_Traits4swapI13little_endian10Elf32_Ehdr12serializableIS_EEEvRT1_RT0_ 5447 3d06433b UNDEF _ZN15Elf_Ehdr_Traits4swapI10big_endian10Elf64_Ehdr12serializableIS_EEEvRT1_RT0_ 5455 3d06433b UNDEF _ZN15Elf_Ehdr_Traits4swapI13little_endian10Elf64_Ehdr12serializableIS_EEEvRT1_RT0_ 5459 3d06433b UNDEF _ZN15Elf_Ehdr_Traits4swapI10big_endian10Elf32_Ehdr12serializableIS_EEEvRT1_RT0_ I currently have problems to get past firewall to my mozilla build, but this seems like another instance of problem with COMDATs - i.e. host_elfhack including some header that makes use of those functions in something that is inlined and consistently optimized out in normal compilation but due to comdat issues it stays stuck in the LTO output. According to cgraph dump it is used by
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #81 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-11 11:13:32 UTC --- Sorry, firefox concluded I want to save changes when I didn't ;) The problem is function Elf_Ehdr::serialize(std::basic_ofstreamchar, std::char_traitschar , char, char) What I see is that this function is defined several times in the unmerged cgraph (i.e. it is comdat inline coming from different .o files) and _some_ of the definitions calls swap function that is not defined, while other definitions calls swap function that is defined. In your build the one that calls undefined swap wins resulting in final link error. I am not sure if this is GCC bug or elfhack, but I would guess for elfhack actually. This is whole bit tricky since the COMDAT hack comes into game here: GCC is not telling linker in the LTO symtab about COMDATs for inline functions when their address is not taken since they should be defined in every unit that needs them. It is not the case here. I think either SWAP should be keyed in one of the units that it is apparently not: swap/622(-1) @0x7f4d15d34000 (asm: _ZN18Elf_RelHack_Traits4swapI10big_endian9Elf32_Rel12serializableIS_EEEvRT1_RT0_) analyzed 19 time, 16 benefit 31 size, 8 benefit externally_visible finalized inlinable called by: serialize/623 (0.65 per call) serialize/623 (0.25 per call) calls: __builtin_constant_p/466 (1.00 per call) __builtin_constant_p/466 (1.00 per call) References: Refering this function: (other defs looks like) swap/825(-1) @0x7f4d15d466e0 (asm: _ZN15Elf_Ehdr_Traits4swapI10big_endian10Elf32_Ehdr12serializableIS_EEEvRT1_RT0_) undef called by: serialize/595 (0.25 per call) (can throw external) calls: References: Refering this function: Or this is some source level bug. I.e. one unit just forward declaring the function while other defining it as comdat inline that is probably violation of one declaration rule. Would be possible for you to look into preprocessed source files of elfhack and see what units define the serialize function and among those how the swap defintions look like? We probably could make lto-symtab to not give up on seeing Undef resolution from linker in these cases, but I would rather avoid pilling up hacks around this COMDAT mess. Honza
[Bug c/48552] New: ICE with void type expressions in asm inputs/outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48552
Summary: ICE with void type expressions in asm inputs/outputs
Product: gcc
Version: 4.6.0
URL: https://bugzilla.redhat.com/show_bug.cgi?id=693986
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
struct S;
void
f1 (void *x)
{
__asm volatile ( : : r (*x));
}
void
f2 (void *x)
{
__asm volatile ( : =r (*x));
}
void
f3 (void *x)
{
__asm volatile ( : : m (*x));
}
void
f4 (void *x)
{
__asm volatile ( : =m (*x));
}
void
f5 (void *x)
{
__asm volatile ( : : g (*x));
}
void
f6 (void *x)
{
__asm volatile ( : =g (*x));
}
void
f7 (struct S *x)
{
__asm volatile ( : : r (*x));
}
void
f8 (struct S *x)
{
__asm volatile ( : =r (*x));
}
void
f9 (void *x)
{
__asm ( : : r (*x));
}
void
f10 (void *x)
{
__asm ( : =r (*x));
}
void
f11 (void *x)
{
__asm ( : : m (*x));
}
void
f12 (void *x)
{
__asm ( : =m (*x));
}
void
f13 (void *x)
{
__asm ( : : g (*x));
}
void
f14 (void *x)
{
__asm ( : =g (*x));
}
void
f15 (struct S *x)
{
__asm ( : : r (*x));
}
void
f16 (struct S *x)
{
__asm ( : =r (*x));
}
ICEs back to 3.2-ish gcc at least, correctly errors out with C++.
[Bug testsuite/21164] libjava tests uses absolute paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21164 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-04/msg00746.htm ||l CC||ro at gcc dot gnu.org Component|libgcj |testsuite AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-04-11 12:16:38 UTC --- This isn't specific to libjava. Mine, patch posted.
[Bug c/48552] ICE with void type expressions in asm inputs/outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48552 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-11 12:28:31 UTC --- Created attachment 23954 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23954 gcc46-pr48552.patch Untested fix.
[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c/48517] [4.6/4.7 Regression] ICE in build_unary_op, at c-typeck.c:3786
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48517 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-11 13:02:03 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=160312
[Bug go/48553] New: fmt FAILs on 32-bit Solaris 2 with stack overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48553 Summary: fmt FAILs on 32-bit Solaris 2 with stack overflow Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* While investigating libgo failures, I noticed that the fmt tests fails only for 32-bit and if compiled without optimization. The failure is like this: === RUN fmt_test.TestScanInts Segmentation Fault With truss, I see 23987/2:Incurred fault #6, FLTBOUNDS %pc = 0x080676B8 23987/2: siginfo: SIGSEGV SEGV_MAPERR addr=0xCDF10FFC 23987/2:Received signal #11, SIGSEGV [caught] 23987/2: siginfo: SIGSEGV SEGV_MAPERR addr=0xCDF10FFC which is exactly the lower bound of the thread stack: CDF0 64K rwx--[ anon ] CDF110001016K rwx-R[ stack tid=2 ] CE01 64K rw---[ anon ] This matches the very deep nesting seen in gdb (ca. 4000 frames). The test passes with -m64 (default thread stack size of 2 MB instead of 1 MB for 32-bit) and with -O2. Perhaps the nesting should be reduced to accomodate platforms without split stack support?
[Bug go/48122] crypto/aes test fails on 32-bit Solaris 11/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48122
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-04-11 13:15:45 UTC ---
I noticed that this error only happens in a modifed tree with the libgo
multilib check patch
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00247.html
Investigation showed that _testmain.go differs between the two trees:
--- ./_testmain.go 2011-04-09 20:39:58.824574614 +0200
+++
/var/gcc/gcc-4.7.0-20110408/11-gcc-gas/i386-pc-solaris2.11/libgo/crypto-aes-check/_testmain.go
2011-04-09 20:38:06.328947345 +0200
@@ -14,8 +14,8 @@
{aes.TestExpandKey, aes.TestExpandKey},
{aes.TestEncryptBlock, aes.TestEncryptBlock},
{aes.TestDecryptBlock, aes.TestDecryptBlock},
- {aes.TestCipherEncrypt, aes.TestCipherEncrypt},
{aes.TestCipherDecrypt, aes.TestCipherDecrypt},
+ {aes.TestCipherEncrypt, aes.TestCipherEncrypt},
}
var benchmarks = []testing.InternalBenchmark{ //
}
It turns out that this was caused by passing $GOCFLAGS in CHECK (GC),
which was meant to pass the multilib flags, but isn't necessary since
those are included in $GOC.
But unfortunately the default (-g -O2) changes the outcome of this and a
couple of others tests. I don't think the tests should be so fragile.
Rainer
[Bug c/48517] [4.6/4.7 Regression] ICE in build_unary_op, at c-typeck.c:3786
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48517 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-11 13:24:23 UTC --- Created attachment 23955 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23955 gcc46-pr48517.patch Untested fix.
[Bug c/48554] New: Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 Summary: Regression for coldfire platform Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: miro.kropa...@gmail.com Created attachment 23956 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23956 Test case I wanted to test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551 against 4.6.0 so I decided to compile new gcc toolchain. It crashed for coldfire by libc compilation: /home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/xgcc -B/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/ -B/home/mikro/gnu-tools/bin/ -B/home/mikro/gnu-tools/lib/ -isystem /home/mikro/gnu-tools/include -isystem /home/mikro/gnu-tools/sys-include -Wall -mcpu=5475 -O2 -fomit-frame-pointer -nostdinc -I../stdio -I.. -I../include -I../mintlib -I../stdlib -I/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/include -I/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/include-fixed -DHAVE_CONFIG_H -D_LIBC -D_REENTRANT -save-temps -v -c ./printf_fp.i Reading specs from /home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/specs COLLECT_GCC=/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/xgcc COLLECT_LTO_WRAPPER=/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/lto-wrapper Target: m68k-atari-mint Configured with: ../gcc-4.6.0/configure --target=m68k-atari-mint --prefix=/home/mikro/gnu-tools --enable-languages=c,c++ --disable-nls --disable-libstdcxx-pch 'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' Thread model: single gcc version 4.6.0 (MiNT 20110206) (GCC) COLLECT_GCC_OPTIONS='-B' '/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/' '-B' '/home/mikro/gnu-tools/bin/' '-B' '/home/mikro/gnu-tools/lib/' '-isystem' '/home/mikro/gnu-tools/include' '-isystem' '/home/mikro/gnu-tools/sys-include' '-Wall' '-mcpu=5475' '-O2' '-fomit-frame-pointer' '-nostdinc' '-I' '../stdio' '-I' '..' '-I' '../include' '-I' '../mintlib' '-I' '../stdlib' '-I' '/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/include' '-I' '/home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/include-fixed' '-D' 'HAVE_CONFIG_H' '-D' '_LIBC' '-D' '_REENTRANT' '-save-temps' '-v' '-c' /home/mikro/atari/gnu/gcc-4.6.0-cross/gcc/cc1 -fpreprocessed ./printf_fp.i -quiet -dumpbase printf_fp.i -mcpu=5475 -auxbase printf_fp -O2 -Wall -version -fomit-frame-pointer -o printf_fp.s GNU C (GCC) version 4.6.0 (MiNT 20110206) (m68k-atari-mint) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.6.0 (MiNT 20110206) (m68k-atari-mint) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3a2c4fbef45b8f57f847c54f7ff100d7 ../stdio/printf_fp.c: In function '__printf_fp': ../stdio/printf_fp.c:575:17: warning: variable 'used_limbs' set but not used [-Wunused-but-set-variable] ../stdio/printf_fp.c:1038:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/48546] lto-wrapper returned 1 exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48546 --- Comment #2 from rootkit85 at yahoo dot it rootkit85 at yahoo dot it 2011-04-11 13:48:52 UTC --- I'll try when Linaro will switch to 4.6 then
[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48195 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-11 14:26:00 UTC --- Author: jamborm Date: Mon Apr 11 14:25:55 2011 New Revision: 172256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172256 Log: 2011-04-11 Martin Jambor mjam...@suse.cz PR tree-optimization/48195 * ipa-cp.c (ipcp_driver): Call ipa_check_create_node_params and ipa_check_create_edge_args. (ipcp_generate_summary): Do not call ipa_check_create_node_params and ipa_check_create_edge_args. * ipa-inline.c (inline_generate_summary): Do not call ipa_check_create_node_params and ipa_check_create_edge_args. * ipa-prop.c (ipa_analyze_node): Call ipa_check_create_node_params and ipa_check_create_edge_args. * testsuite/gcc.dg/ipa/pr48195.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr48195.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48195 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-11 14:27:35 UTC --- Fixed on trunk, bootstrap and testing on the 4.6 branch in progress.
[Bug translation/48555] New: [fr] gibberish warning (déréférencement du pointeur type-punned brisera les strictes d'aliases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48555 Summary: [fr] gibberish warning (déréférencement du pointeur type-punned brisera les strictes d'aliases) Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: lecotegougdelafo...@free.fr The following warning : dereferencing type-punned pointer will break strict-aliasing rules is translated in French by déréférencement du pointeur type-punned brisera les strictes d'aliases, which has absolutely no meaning. I would suggest something like : le déréférencement d'un pointeur [type-punned ??] brisera les règles d'alias[ing] strictes — I don't know how to translate type-punned, aliasing might be about as ok as alias.
[Bug translation/48555] [fr] gibberish warning (déréférencement du pointeur type-punned brisera les strictes d'aliases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48555 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-11 14:59:10 UTC --- the same translation is used for the might break strict aliasing rules warning, the translations should distinguish between will break and might break
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #82 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-04-11 15:08:28 UTC --- (In reply to comment #81) The problem is function Elf_Ehdr::serialize(std::basic_ofstreamchar, std::char_traitschar , char, char) ... Would be possible for you to look into preprocessed source files of elfhack and see what units define the serialize function and among those how the swap defintions look like? I think it would be best if you take a look at the source files yourself once your firewall problem is solved, because there are actually only two of them (elfxx.h and elf.cpp). The instantiation takes place in elfxx.h:431 and elf.cpp:142. BTW when I use -frepo to compile host_elf.o the link error goes away. And if I recompile host_elf.o without -frepo, but leave the host_elf.rpo file, this is what happens: collect: recompiling /var/tmp/mozilla-central/build/unix/elfhack/elf.cpp collect: relinking collect2: '_ZN15Elf_Ehdr_Traits4swapI10big_endian10Elf64_Ehdr12serializableIS_EEEvRT1_RT0_' was assigned to 'host_elf.rpo', but was not defined during recompilation, or vice versa and then the link error from above follows.
[Bug gcov-profile/48463] gcov generating bad function coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48463
--- Comment #2 from Christian Feist lieutenantfeist at hotmail dot de
2011-04-11 15:30:19 UTC ---
Thank you for your reply.
Using GCC 4.6 (and with it the newest version of GCOV), does generate a
slightly different output, but it doesn't show any improvement in terms of
function coverage. I'm still getting multiple destructors, which seem to differ
from one another (though I don't see 'D1' here):
function _ZN6ClassAD0Ev called 0 returned 0% blocks executed 0%
function _ZN6ClassAD2Ev called 1 returned 100% blocks executed 80%
1:9:ClassA::~ClassA()
-: 10:{
1: 11:std::cout Bey, ClassA! std::endl;
call0 returned 100%
call1 returned 100%
1: 12:}
call0 never executed
call1 never executed
branch 2 taken 0% (fallthrough)
branch 3 taken 100%
call4 never executed
I'm not sure what all this stuff about branches is that I have going on here,
but I don't have an in my destructor, so I assume it is code generated by GCC
in the generated destructors that are showing up in the coverage. It might be
useful to know that these exist in the background, but this info is confusing
and useless when analyzing ones own code coverage.
On a side note: These also show up when generating documents with lcov.
My course of action was the same as before, also leaving the source files
unaltered.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #34 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-11 15:50:51 UTC --- Author: burnus Date: Mon Apr 11 15:50:47 2011 New Revision: 172262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172262 Log: 2011-04-11 Tobias Burnus bur...@net-b.de PR fortran/18918 * simplify.c (simplify_bound_dim): Exit for ucobound's last dimension unless -fcoarray=single. * trans-array (gfc_conv_descriptor_size_1): Renamed from gfc_conv_descriptor_size, made static, has now from_dim and to_dim arguments. (gfc_conv_descriptor_size): Call gfc_conv_descriptor_size. (gfc_conv_descriptor_cosize): New function. * trans-array.h (gfc_conv_descriptor_cosize): New prototype. * trans-intrinsic.c (conv_intrinsic_cobound): Add input_location and handle last codim of ucobound for when -fcoarray is not single. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-intrinsic.c
[Bug bootstrap/48556] New: Gcc 4.6.0 bootstrap fails with in-tree GMP/MPFR/MPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48556 Summary: Gcc 4.6.0 bootstrap fails with in-tree GMP/MPFR/MPC Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: f...@earthlink.net I'm trying to build gcc 4.6.0 on OpenSuSE 11.2 x86_64 with latest MPC, MPFR, GMP built in-tree (vers 0.9, 3.0.1, 5.0.1). I've always used in-tree builds in the past as they are the least troublesome. Configuring with: ../gcc-4.6.0/configure --prefix=/usr/local \ --libdir=/usr/local/lib64 --program-suffix=-4.6 \ --with-arch=corei7 --enable-languages=c,c++,fortran --enable-gold \ --enable-checking=release --with-system-zlib --enable-linux-futex \ --without-system-libunwind --with-ppl-lib=/usr/lib64 \ --with-ppl-include=/usr/include --with-cloog-lib=/usr/lib64 \ --with-cloog-include=/usr/include --enable-lto I get several errors such as: [...]/gcc/gcc-build-4.6.0/./mpc/src/.libs/libmpc.a(pow.o): In function mpc_pow_exact': [...]/gcc/gcc-build-4.6.0/mpc/src/../../../gcc-4.6.0/mpc/src/pow.c:123: undefined reference to `mpfr_get_z_2exp' Evidently this is caused by MPC picking up the older incompatible system version of MPFR? Shouldn't this be taken care of by the in-tree config somehow? I tried to get around this by installing the latest versions of mpc/mpfr/gmp/ppl/cloog that are available from the SuSE gcc-devel repository. I believe these are 0.8.2, 3.0.0, 5.0.1, 0.11-15, 0.15.10. However, this did not appear to solve the issue. Further removing the --with-ppl-* and --with-cloog-* configure flags resulted in a successful bootstrap. Perhaps these flags are making their way into the in-tree builds of mpc/mpfr/gmp somehow?
[Bug translation/48555] [fr] gibberish warning (déréférencement du pointeur type-punned brisera les strictes d'aliases)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48555 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 16:40:49 UTC --- The translation itself is handled by the translation team which is separate from GCC.
[Bug c/48545] dereferencing does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48545 --- Comment #3 from Gerald Lutter gerald at itzgrund dot net 2011-04-11 16:42:16 UTC --- Hi Dmitry, sorry for referring to you as a team :-) but I still think that dereferencing should not be ignored like it is done for *output: output: 0x22cd24 validoutput: 0x22cd24 *output: 0x22cd24 *validoutput: 0x40200c (*output)[0]: 12 (*output)[1]: 32 (*output)[2]: 64 (*validoutput)[0]: 7 (*validoutput)[1]: 8 (*validoutput)[2]: 9 In my opinion it is not possible that the printf(output: %p\n, output); gives the same result as printf(*output: %p\n, *output); Best regards, Gerald
[Bug target/48554] Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|blocker |normal
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2011-04-11
17:11:37 UTC ---
The new big IRA patch just triggered a latent reload bug.
The code in question is in function reload_as_needed
/* If this was an ASM, make sure that all the reload insns
we have generated are valid. If not, give an error
and delete them. */
if (asm_noperands (PATTERN (insn)) = 0)
for (p = NEXT_INSN (prev); p != next; p = NEXT_INSN (p))
if (p != insn INSN_P (p)
GET_CODE (PATTERN (p)) != USE
(recog_memoized (p) 0
|| (extract_insn (p), ! constrain_operands (1
{
error_for_asm (insn,
%asm% operand requires
impossible reload);
delete_insn (p);
}
}
A previous insn P has a spilled pseudo and that results in the error generation
because spilled pseudos are changed by memory later.
I guess the above code is wrong if a previous insn has a spilled pseudo.
The bug did not occur before the big IRA patch because the pseudo in question
happened not to be spilled. I should mention that it is more profitable to
spill the pseudo and the new IRA makes the right decision (which results in
live range shrinkage and decreasing register pressure).
I could make a patch (preventing the error generation if there are spilled
pseudos in insn P) but I think that reload maintainers would do that different
(e.g. moving the check after changing spilled pseudos by memory) or make a
better patch.
[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48549 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-11 17:25:40 UTC --- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00738.html
[Bug target/11772] Incorrect code generated with -mrtd and long long (most builtins)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11772 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-11 17:44:08 UTC --- Author: ktietz Date: Mon Apr 11 17:44:04 2011 New Revision: 172268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172268 Log: 2011-04-11 Kai Tietz kti...@redhat.com PR target/9601 PR target/11772 * config/i386/i386-protos.h (ix86_get_callcvt): New prototype. * config/i386/i386.c (ix86_handle_cconv_attribute): Adjust comment. (ix86_is_msabi_thiscall): Removed. (ix86_is_type_thiscall): Likewise. (ix86_get_callcvt): New function. (ix86_comp_type_attributes): Simplify check. (ix86_function_regparm): Use ix86_get_callcvt for calling convention attribute checks. (ix86_return_pops_args): Likewise. (ix86_static_chain): Likewise. (x86_this_parameter): Likewise. (x86_output_mi_thunk): Likewise. (ix86_function_type_abi): Optimize check for types without attributes. * config/i386/i386.h (IX86_CALLCVT_CDECL, IX86_CALLCVT_STDCALL, IX86_CALLCVT_FASTCALL, IX86_CALLCVT_THISCALL, IX86_CALLCVT_REGPARM, IX86_CALLCVT_SSEREGPARM): New macros to represent calling convention by flag-values. (IX86_BASE_CALLCVT): Helper macro. * config/i386/netware.c (i386_nlm_maybe_mangle_decl_assembler_name): Use ix86_get_callcvt for calling convention attribute checks and avoid symbol-decoration for stdcall in TARGET_RTD case. * config/i386/winnt.c (i386_pe_maybe_mangle_decl_assembler_name): Likewise. (gen_stdcall_or_fastcall_suffix): Adjust ident and use DECL_ORIGIN for declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/netware.c trunk/gcc/config/i386/winnt.c
[Bug target/9601] -mrtd switch/stdcall attribute raises warnings for __buitltin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-11 17:44:08 UTC --- Author: ktietz Date: Mon Apr 11 17:44:04 2011 New Revision: 172268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172268 Log: 2011-04-11 Kai Tietz kti...@redhat.com PR target/9601 PR target/11772 * config/i386/i386-protos.h (ix86_get_callcvt): New prototype. * config/i386/i386.c (ix86_handle_cconv_attribute): Adjust comment. (ix86_is_msabi_thiscall): Removed. (ix86_is_type_thiscall): Likewise. (ix86_get_callcvt): New function. (ix86_comp_type_attributes): Simplify check. (ix86_function_regparm): Use ix86_get_callcvt for calling convention attribute checks. (ix86_return_pops_args): Likewise. (ix86_static_chain): Likewise. (x86_this_parameter): Likewise. (x86_output_mi_thunk): Likewise. (ix86_function_type_abi): Optimize check for types without attributes. * config/i386/i386.h (IX86_CALLCVT_CDECL, IX86_CALLCVT_STDCALL, IX86_CALLCVT_FASTCALL, IX86_CALLCVT_THISCALL, IX86_CALLCVT_REGPARM, IX86_CALLCVT_SSEREGPARM): New macros to represent calling convention by flag-values. (IX86_BASE_CALLCVT): Helper macro. * config/i386/netware.c (i386_nlm_maybe_mangle_decl_assembler_name): Use ix86_get_callcvt for calling convention attribute checks and avoid symbol-decoration for stdcall in TARGET_RTD case. * config/i386/winnt.c (i386_pe_maybe_mangle_decl_assembler_name): Likewise. (gen_stdcall_or_fastcall_suffix): Adjust ident and use DECL_ORIGIN for declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/netware.c trunk/gcc/config/i386/winnt.c
[Bug target/11772] Incorrect code generated with -mrtd and long long (most builtins)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11772 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-11 17:48:47 UTC --- Fixed.
[Bug target/9601] -mrtd switch/stdcall attribute raises warnings for __buitltin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-11 17:50:08 UTC --- Fixed.
[Bug c++/48557] New: [C++0x][SFINAE] Hard errors with void as operand of binary built-in operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48557
Summary: [C++0x][SFINAE] Hard errors with void as operand of
binary built-in operators
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
Build: 4.7.0 20110409 (experimental)
The following program is well-formed, but should be well-formed according to
SFINAE rules:
//-
templateclass T
struct add_rval_ref
{
typedef T type;
};
template
struct add_rval_refvoid
{
typedef void type;
};
templateclass T
typename add_rval_refT::type create();
templateclass T, class U,
class = decltype(createT() + createU())
char f(int);
templateclass, class
char (f(...))[2];
static_assert(sizeof(fvoid, int(0)) != 1, Error); // (a)
//-
The error message at (a) is:
error: void value not ignored as it ought to be
The same problem has been confirmed to exist for the following binary
operators:
+,-,*,/,%,,,==,!=,,=,,=,,^,|,,||
It does *not* occur for the corresponding compounds assignments, like +=,
though
[Bug c++/48551] Following source code crashes the c++ compiler on coldfire platform.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-04-11 18:14:04 UTC --- Also ICE gcc-4.6-20110408 targeting m68k-linux when invoked with -mcpu=5475, ICE disappears if -mcpu=5475 is removed.
[Bug target/48551] Following source code crashes the c++ compiler on coldfire platform.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||m68k-linux Component|c++ |target Severity|blocker |normal
[Bug target/48554] Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-04-11 18:19:42 UTC --- Also ICEs gcc-4.6-20110408 targeting m68k-linux when invoked with -mcpu=5475, the ICE disappears if -mcpu=5475 is omitted.
[Bug middle-end/48558] New: -Warray-bounds fails o detect the out of bound array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48558 Summary: -Warray-bounds fails o detect the out of bound array access Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com bfd/elf32-i386.c in binutils has case BFD_RELOC_386_IRELATIVE: TRACE (BFD_RELOC_386_IRELATIVE); return elf_howto_table[R_386_IRELATIVE]; It should be: return elf_howto_table[R_386_IRELATIVE - R_386_tls_offset]; GCC fails to detect it.
[Bug libstdc++/48559] New: parallel-mode vs C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48559 Summary: parallel-mode vs C++0x Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: paolo.carl...@oracle.com A number of parallel algorithms assumes CopyConstructible and/or CopyAssignable, whereas in the new standard only MoveConstructible and/or MoveAssignable are required (eminent case, std::sort). Indeed, at the moment we have to run the following in normal-mode: random_shuffle/moveable.cc:24:#undef _GLIBCXX_PARALLEL nth_element/moveable.cc:27:#undef _GLIBCXX_PARALLEL partial_sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL partial_sort/moveable.cc:27:#undef _GLIBCXX_PARALLEL partition/moveable.cc:27:#undef _GLIBCXX_PARALLEL stable_sort/moveable2.cc:26:#undef _GLIBCXX_PARALLEL stable_sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL stable_sort/moveable.cc:26:#undef _GLIBCXX_PARALLEL sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL sort/moveable.cc:27:#undef _GLIBCXX_PARALLEL for_each/1.cc:24:#undef _GLIBCXX_PARALLEL (see also next_permutation/moveable.cc and prev_permutation/moveable.cc about std::lexicographical_compare) We have to fix this. An option would be conditionalizing the parallel versions on std::is_copy_constructible and/or std::is_copy_assignable being true. But those traits are not available yet. We could conservatively use for now the trivial version, which maybe is too conservative, however. Much more elegant would be tweaking the algorithms themselves to not use copies, just moves, as the serial versions do. I have no idea whether this is feasible, for at least *some* of the algorithms...
[Bug libstdc++/48559] parallel-mode vs C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||singler at kit dot edu --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-11 18:30:42 UTC --- Johannes, what do you think?
[Bug libstdc++/48541] std::function(std::_Function_base) should use std::addressof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48541 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-11 18:32:12 UTC --- Thanks Jon.
[Bug libstdc++/48365] Non-constant references in std::valarray::operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-11 18:33:53 UTC --- Gaby, any comments on this? Thanks in advance.
[Bug target/21738] MIPS libsupc++ built with small data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.11 18:38:57 CC||pinskia at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 18:38:57 UTC --- Confirmed.
[Bug middle-end/48558] -Warray-bounds fails to detect the out of bound array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48558
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-04-11 18:40:07
UTC ---
A testcase:
[hjl@gnu-6 bfd]$ cat x.c
enum bfd_reloc_code_real {
BFD_RELOC_386_IRELATIVE
};
typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
typedef const struct reloc_howto_struct reloc_howto_type;
struct reloc_howto_struct
{
unsigned int type;
};
enum elf_i386_reloc_type {
R_386_IRELATIVE = 42,
};
static reloc_howto_type elf_howto_table[]=
{
{
(unsigned) R_386_IRELATIVE
}
};
reloc_howto_type *
elf_i386_reloc_type_lookup (bfd_reloc_code_real_type code)
{
switch (code)
{
case BFD_RELOC_386_IRELATIVE:
return elf_howto_table[R_386_IRELATIVE];
default:
break;
}
return 0;
}
[hjl@gnu-6 bfd]$ /usr/gcc-4.7.0-x32/bin/gcc -O3 -S -Wall x.c -Warray-bounds
[hjl@gnu-6 bfd]$
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #83 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-04-11 18:44:07 UTC --- I am not sure if this is GCC bug or elfhack, but I would guess for elfhack actually. I guess you're right, because when I move the swap definitions: template class endian, typename R, typename T inline void Elf_Ehdr_Traits::swap(T t, R r) ... from elf.cpp to elfxx.h (where they actually belong) the link error vanishes.
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-04-11 18:44:59 UTC --- There is typo in a loop condition resulting in taking hard registers of LIM_REG_CLASS which happens a garbage for VAX. I'll send a patch soon.
[Bug middle-end/30996] Performance problem with structure assignment on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30996 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 18:45:33 UTC --- It works for me on the trunk and on 4.3.3.
[Bug c/48545] dereferencing does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48545
--- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com
2011-04-11 18:45:50 UTC ---
*output and output have different types, but numberically they are equal.
That's how C works.
More fun:
extern int printf(const char *, ...);
char str[4] = abc;
int main(void)
{
int (*f)(const char *, ...) = printf;
int (*g)(const char *, ...) = printf;
char (*p)[4] = str;
char *q = str;
(*f)(%p %p %p %p %p %p\n, printf, printf, f, *f, g, *g);
f(%p %p %p %p %p %c\n, str, str, p, *p, q, *q);
return 0;
}
It prints:
0x80482d8 0x80482d8 0x80482d8 0x80482d8 0x80482d8 0x80482d8
0x8049624 0x8049624 0x8049624 0x8049624 0x8049624 a
[Bug target/46453] MIPS backend is not using special instructions for __builtin_bswap32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46453 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|mips-elf|mips*-*-* Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011.04.11 18:52:12 CC||pinskia at gcc dot gnu.org Host|i686| Ever Confirmed|0 |1 Build|../configure| |--disable-libssp| |--prefix=/usr/local | |--target=mips-elf | --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 18:52:12 UTC --- Confirmed, I ran into this too and produced a similar patch. I also did a patch for * Unaligned loads: part too.
[Bug middle-end/48558] -Warray-bounds fails to detect the out of bound array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48558
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-04-11 19:09:54
UTC ---
A simple change from
return elf_howto_table[R_386_IRELATIVE];
to
return elf_howto_table[R_386_IRELATIVE];
makes GCC to warn:
[hjl@gnu-6 bfd]$ cat x.c
enum bfd_reloc_code_real {
BFD_RELOC_386_IRELATIVE
};
typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
typedef const struct reloc_howto_struct reloc_howto_type;
struct reloc_howto_struct
{
unsigned int type;
};
enum elf_i386_reloc_type {
R_386_IRELATIVE = 42,
};
static reloc_howto_type elf_howto_table[]=
{
{
(unsigned) R_386_IRELATIVE
}
};
reloc_howto_type
elf_i386_reloc_type_lookup (bfd_reloc_code_real_type code)
{
switch (code)
{
case BFD_RELOC_386_IRELATIVE:
return elf_howto_table[R_386_IRELATIVE];
default:
break;
}
return elf_howto_table[0];
}
[hjl@gnu-6 bfd]$ /usr/gcc-4.7.0-x32/bin/gcc -O3 -S -Wall x.c -Warray-bounds
x.c: In function ‘elf_i386_reloc_type_lookup’:
x.c:25:29: warning: array subscript is above array bounds [-Warray-bounds]
[hjl@gnu-6 bfd]$
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org 2011-04-11 19:23:17 UTC --- Author: vmakarov Date: Mon Apr 11 19:23:13 2011 New Revision: 172274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172274 Log: 2011-04-11 Vladimir Makarov vmaka...@redhat.com PR middle-end/48464 * ira.c (setup_pressure_classes): Fix typo in loop condition. (setup_allocno_and_important_classes): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug middle-end/48560] New: [4.6/4.7 Regression] -Warray-bounds fails to detect the out of bound array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48560
Summary: [4.6/4.7 Regression] -Warray-bounds fails to detect
the out of bound array access
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 bfd]$ cat b.c
char
foo1 (int i)
{
static char s[] = foo;
switch (i)
{
case 30:
return s[30];
}
return s[i];
}
[hjl@gnu-6 bfd]$ /usr/gcc-4.5/bin/gcc -O3 -S -Wall b.c
b.c: In function ‘foo1’:
b.c:8:13: warning: array subscript is above array bounds
[hjl@gnu-6 bfd]$ /usr/gcc-4.6/bin/gcc -O3 -S -Wall b.c
[hjl@gnu-6 bfd]$
[Bug target/21738] MIPS libsupc++ built with small data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738 --- Comment #2 from Jonathan Larmour jifl-bugzilla at jifvik dot org 2011-04-11 19:59:07 UTC --- I had forgotten I had submitted this :-). Some work has been done by Richard Sandiford to address this, and there is now a -mno-extern-sdata option. I think this bug now can be about actually deploying this option where relevant in config/mips/t-* Presumably by adding something like: MULTILIB_EXTRA_OPTS = G mno-extern-sdata in the relevant t-* files. But it might be good if someone could confirm. Jifl
[Bug middle-end/45274] __restrict__ type qualifier does not work on pointers to bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|powerpc64-unknown-linux-gnu | |, mips64-elf| --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 20:13:25 UTC --- (In reply to comment #1) I don't think this has anything to do with restrict and all with lowering bitfield accesses only during expansion, and at RTL level the bitfield operations being too big for combiner to optimize them. No this is unrelated to the combiner not be able to optimize the bitfield accesses. Rather it is related to how store and loads happen on bitfields. We don't try to keep track of individual bits for a change in the store.
[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2011-02/msg00196.htm |atches/2011-04/msg00802.htm |l |l --- Comment #51 from Janne Blomqvist jb at gcc dot gnu.org 2011-04-11 20:23:43 UTC --- Updated patch which hopefully fixed alpha-osf bootstrap failure: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00802.html
[Bug c/48561] New: internal compiler error: in change_address_1, at emit-rtl.c:1954
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48561 Summary: internal compiler error: in change_address_1, at emit-rtl.c:1954 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: brian.da...@eclipseoptions.com NOTE: changing the typedef of ITERATOR_TYPE from uint32_t to uint16_t on line 903 of the preprocessed source will allow the program to compile successfully. $ uname -a Linux bdavis-desktop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64 GNU/Linux $ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/bin/gcc-4.4 -DLINUX -DLINUX64 -D_POSIX_PTHREAD_SEMANTICS -fPIC -D_REENTRANT -DLINUX64 -D_GNU_SOURCE -MMD -g -O2 -pthread -std=gnu99 -march=native -m64 -ffast-math -mieee-fp -Wall -Wstrict-prototypes fail.c testArrayQueueMRU.c: In function ‘main’: testArrayQueueMRU.c:190: internal compiler error: in change_address_1, at emit-rtl.c:1954 Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/42661] Documented -mmad option not accepted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42661 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.11 20:57:21 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 20:57:21 UTC --- Confirmed.
[Bug c++/48035] [4.4/4.5 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added CC||tschwinge at gcc dot ||gnu.org --- Comment #7 from Thomas Schwinge tschwinge at gcc dot gnu.org 2011-04-11 21:23:27 UTC --- FWIW, I'm confirming both the bug and the fix in a 4.5-based tree.
[Bug c++/48562] New: Prematurely destroys initializer_list array when using new-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Summary: Prematurely destroys initializer_list array when using
new-expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
The C++0x spec requires that GCC destroys the backing-up array at delete p,
but GCC appears to destroy it immediately after the first declaration (as
checked by using a class type that has a side-effecting destructor).
auto *p= new initializer_listint{1, 2, 3};
{ auto q(*p); }
delete p;
[Bug c++/48457] [C++0x] GCC does not recognize function rvalue reference expressions as lvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48457 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:00:16 UTC --- Author: jason Date: Mon Apr 11 22:00:06 2011 New Revision: 172282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172282 Log: PR c++/48457, Core 1238 * call.c (reference_binding): Allow rvalue reference to bind to function lvalue. * tree.c (lvalue_kind): Functions are always lvalues. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-func.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/is_convertible/value.cc
[Bug c++/48534] [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48534 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:00:39 UTC --- Author: jason Date: Mon Apr 11 22:00:31 2011 New Revision: 172284 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172284 Log: PR c++/48534 * cvt.c (ocp_convert): Use build_nop to convert to underlying type of scoped enum. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48535] [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:00:48 UTC --- Author: jason Date: Mon Apr 11 22:00:42 2011 New Revision: 172285 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172285 Log: PR c++/48535 * semantics.c (finish_compound_literal): Take complain parm. (build_lambda_object): Adjust. * cp-tree.h: Adjust. * call.c (convert_like_real): Adjust. * decl.c (check_initializer): Adjust. * parser.c (cp_parser_postfix_expression): Adjust. (cp_parser_functional_cast): Adjust. * pt.c (tsubst_copy_and_build): Adjust. * typeck2.c (process_init_constructor_record): Adjust. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck2.c
[Bug c++/48535] [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:01:10 UTC --- Author: jason Date: Mon Apr 11 22:01:04 2011 New Revision: 172287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172287 Log: PR c++/48535 * decl.c (cp_complete_array_type_or_error): New. * semantics.c (finish_compound_literal): Use it. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48535] [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:01:01 UTC --- Author: jason Date: Mon Apr 11 22:00:53 2011 New Revision: 172286 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172286 Log: PR c++/48535 * semantics.c (finish_compound_literal): Handle references. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/48523] [C++0x] lambda cannot capture 'this' in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48523 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-11 22:00:27 UTC --- Author: jason Date: Mon Apr 11 22:00:20 2011 New Revision: 172283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172283 Log: PR c++/48523 * tree.c (maybe_dummy_object): Use build_x_indirect_ref rather than cp_build_indirect_ref. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 --- Comment #5 from Jan-Benedict Glaw jbg...@lug-owl.de 2011-04-11 22:04:12 UTC --- (In reply to comment #4) URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172274 Log: 2011-04-11 Vladimir Makarov vmaka...@redhat.com PR middle-end/48464 * ira.c (setup_pressure_classes): Fix typo in loop condition. (setup_allocno_and_important_classes): Ditto. I updated to r172276 = 850ff64c7c083, but gcc still ICEs at the same line of code. So there must be another root cause. However, at least one bug fixed, good work :)
[Bug c/48563] New: EOF not at EOL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48563
Summary: EOF not at EOL
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k...@unstable.nl
Created attachment 23957
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23957
musl's openat file as destributed in sabotage
I tried to bootstrap sabotage[0] on i686, and when gcc(not sure what stage, but
i believe stage0, so my own compiler (gcc (GCC) 4.5.2 20110127 (prerelease))),
however when dealing with musl libc's openat function, gcc blew up and
reported:
---
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:0: Warning: end of file not at end of a line; newline inserted
{standard input}:22: Error: bad register name `%'
make: *** [src/fcntl/openat.o] Error 1
---
sorry i can't give you a lot of info on this, but the file was openat.c.
[0]: https://github.com/chneukirchen/sabotage
[Bug middle-end/48563] EOF not at EOL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48563 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-04-11 22:07:45 UTC --- Can you provide the output of gcc -v? Can you attach the preprocessed source and the exact command line which gcc is involved with?
[Bug middle-end/48563] EOF not at EOL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48563 --- Comment #2 from keks at unstable dot nl 2011-04-11 22:27:45 UTC --- that is the problem, it was during a bootstrap procedure and I'm not sure which gcc was used. from reading the buildscript it believe it was the new one though: % /tmp/sabotage/root/bin/gcc -v Reading specs from /tmp/sabotage/root/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ./configure --prefix=/ --disable-multilib --disable-nls Thread model: posix gcc version 3.4.6 hope this helps.
[Bug c++/48523] [C++0x] lambda cannot capture 'this' in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48523 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:20:23 UTC --- Author: jason Date: Tue Apr 12 00:20:18 2011 New Revision: 172293 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172293 Log: PR c++/48523 * tree.c (maybe_dummy_object): Use build_x_indirect_ref rather than cp_build_indirect_ref. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this4.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/tree.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48534] [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48534 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:20:36 UTC --- Author: jason Date: Tue Apr 12 00:20:32 2011 New Revision: 172294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172294 Log: PR c++/48534 * cvt.c (ocp_convert): Use build_nop to convert to underlying type of scoped enum. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/enum10.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/cvt.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c/48564] New: good hello welell some.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48564 Summary: good hello welell some. Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: xiaoyua...@yeah.net enhanced lfind stack
[Bug c++/48534] [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48534 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:29:12 UTC --- Fixed for 4.6.1/4.7
[Bug c++/48535] [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:29:41 UTC --- Fixed for 4.7.
[Bug c++/48535] [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/48457] [C++0x] GCC does not recognize function rvalue reference expressions as lvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48457 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:30:50 UTC --- Fixed for 4.7.
[Bug c++/48523] [C++0x] lambda cannot capture 'this' in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48523 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-04-12 00:32:18 UTC --- Fixed for 4.6.1.
