[Bug tree-optimization/27109] Simplify a - 10 150 into a 160 when range of a is known (in VRP or somewhere else)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-28 12:03 --- Confirmed. compare_values needs to be teached to look at value ranges for operands and decide on overflow there - but only for substitute and fold as earlier we can have invalid intermediate value ranges. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-28 12:03:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
[Bug tree-optimization/25145] missed VRP opportunity
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-12-28 12:14 --- The testcase in comment #1 is fixed by comparison canonicalization of i = j - 1 to i j. Of course it fails again if we use a temporary for j - 1 like in the testcases in other comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
[Bug tree-optimization/30317] New: VRP cannot extract a range from (unsigned int) i + 0x0ffffffff 4
fold and VRP interact badly if we have a range test like if (i 0 i =5) ... as we fold that to if ((unsigned int) i + 0x0 4) ... for which VRP fails to extract a range for i. If we write the range test so that fold doesn't see it, VRP is happy: if (i 0) if (i = 5) ... -- Summary: VRP cannot extract a range from (unsigned int) i + 0x0 4 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
[Bug tree-optimization/30318] New: VRP does not create ANIT_RANGEs on overflow
VRP should, if overfow is defined, create anti-ranges if plus or minus
cause wrapping.
void test2 (unsigned int i)
{
if (i = 0x0fffa)
{
return;
}
if (i == 0x0)
{
return;
}
{
unsigned int v = i + 2;
{
if (v != 0)
{
if (v != 0x0)
{
link_error ();
}
}
}
}
}
we should be able to optimize this. So [UINT_MAX-4, UINT_MAX-1] + 2
is ~[1, UINT_MAX-1].
(I have a patch)
--
Summary: VRP does not create ANIT_RANGEs on overflow
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #5 from gin at mo dot msk dot ru 2006-12-28 13:32 --- Subject: Re: -B$(build_tooldir)/bin/ It actually broke build of gcc (version 3.0.3) at least on one class of systems, i386-pc-sco3.2v5, as follows. Had on that system gnu binutils installed with PREFIX. Had gcc configured with to install with the same PREFIX. Configured it --without-included-gettext --prefix=PREFIX --with-as=PREFIX/bin/gas --enable-multilib --disable-static --enable-shared (Native `as' was broken in many ways, so GNU one was indeed strongly preferred. OTOH, not specifying `--with-ld', so that native is used `ld', was essential: one from binutils, at least as of 2.11.2, would output elf binaries that system dynamic linker would not link.) make bootstrap would fail as follows. stage1/xgcc -Bstage1/ -BPREFIX/i586-pc-sco3.2v5.0.4/bin/ -DIN_GCC-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -o gengenrtl \ gengenrtl.o ` case obstack.o in ?*) echo obstack.o ;; esac ` ` case alloca.o in ?*) echo alloca.o ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` ` case in ?*) echo ;; esac ` PREFIX/i586-pc-sco3.2v5.0.4/bin/ld: unrecognized option '-YP,/usr/ccs/lib:/lib:/usr/lib' PREFIX/i586-pc-sco3.2v5.0.4/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status gmake[2]: *** [gengenrtl] Error 1 The `-YP' exists in native `ld', but not in GNU one. That is, gcc correctly configured itself to use to `ld' options for native one. It is exactly `-B$(build_tooldir)/bin/' that expands to `-BPREFIX/i586-pc-sco3.2v5.0.4/bin/' so that gcc finds and invokes GNU `ld' instead of native one. Moving `PREFIX/i586-pc-sco3.2v5.0.4/bin/' directory works around that. If the bug was not already reopened, would do that now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug middle-end/26374] Compile failure on long double
--- Comment #10 from dwmw2 at infradead dot org 2006-12-28 14:32 --- Any progress on this? -- dwmw2 at infradead dot org changed: What|Removed |Added CC||dwmw2 at infradead dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[Bug middle-end/26374] Compile failure on long double
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-28 14:48 --- (In reply to comment #10) Any progress on this? There are two way of fixing this as far as I can see: teach real.c about how to fold IBM 128bit long double format use MPFR instead I would use the latter if I got any time but I don't have any time to do either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-28 14:55 ---
No, I still say you are incorrect.
Can you give the output of the original confgure which should show you which
ld/as GCC is going to use?
By default the toplevel configure looks into PREFIX/${TARGET} for ld/as. If
you want a different one, then use --with-ld/--with-as.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #12 from rob1weld at aol dot com 2006-12-28 15:45 --- (In reply to comment #11) Fix checked in. I'm not an expert with Java but am trying to compile gcc 4_2 branch (CVS) and I have the same problem as is described in this bug report. The fixes mentioned in this report _seem_ to have been applied but am getting a 'similar' error message: Here is the part of the make where it fails: /bin/sh ./libtool --mode=compile /cygdrive/c/gcc-4_2-branch-build/gcc/gcj -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c -o gnu-java-awt-peer-swing.lo @gnu-java-awt-peer-swing.list /cygdrive/c/gcc-4_2-branch-build/gcc/gcj -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/ cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecate d -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-java-awt-peer-swing.list -o gnu-java-awt-peer-swing.o gnu/java/awt/peer/swing/SwingFramePeer.java: In class 'gnu.java.awt.peer.swing.SwingFramePeer': gnu/java/awt/peer/swing/SwingFramePeer.java: In method 'gnu.java.awt.peer.swing.SwingFramePeer.setBounds(int,int,int,int)': gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: verification failed at PC=6: didn't see expected constant make[3]: *** [gnu-java-awt-peer-swing.lo] Error 1 make[3]: Target `all-am' not remade because of errors. make[3]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava' I'll leave any 'fixing' to someone more expert at java (so I don't break gcc somewhere else :( ). I tried changing to above to simply use system's gcj: gcj -c -o gnu-java-awt-peer-swing.lo @gnu-java-awt-peer-swing.list This is the message I got: gnu/java/awt/peer/swing/SwingFramePeer.java: In class 'gnu.java.awt.peer.swing.SwingFramePeer': gnu/java/awt/peer/swing/SwingFramePeer.java: In method 'gnu.java.awt.peer.swing.SwingFramePeer.setBounds(int,int,int,int)': gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: verification failed at PC=6: didn't see expected constant gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: class 'java.awt.peer.WindowPeer' has no method named 'setBounds' matching signature '()V' gnu/java/awt/peer/swing/SwingFramePeer.java:119: confused by earlier errors, bailing out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug tree-optimization/30317] VRP cannot extract a range from (unsigned int) i + 0x0ffffffff 4
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 16:03 --- I think the range folding should late in compiling after VRP2 happens. This will also help out code that is written like: if (i 0) if (i = 5) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
[Bug tree-optimization/30316] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-28 17:43 --- Can you rerun the command line that ICEs and add -save-temps and then attach the .i file? The .cpp file you provided does not ICE for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
[Bug fortran/30034] pure subroutine requires intent for procedure argument
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-28 18:41 --- Subject: Bug 30034 Author: pault Date: Thu Dec 28 18:41:25 2006 New Revision: 120244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120244 Log: 2006-12-28 Paul Thomas [EMAIL PROTECTED] PR fortran/30034 * resolve.c (resolve_formal_arglist): Exclude the test for pointers and procedures for subroutine arguments as well as functions. PR fortran/30237 * intrinsic.c (remove_nullargs): Do not pass up arguments with a label. If the actual has a label and the formal has a type then emit an error. 2006-12-28 Paul Thomas [EMAIL PROTECTED] PR fortran/30034 * gfortran.dg/pure_formal_proc_1.f90: New test. PR fortran/30237 * gfortran.dg/intrinsic_actual_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_3.f90 trunk/gcc/testsuite/gfortran.dg/pure_formal_proc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30034
[Bug fortran/30237] Alternate return arguments in intrinsic subroutine calls are ignored
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-28 18:41 --- Subject: Bug 30237 Author: pault Date: Thu Dec 28 18:41:25 2006 New Revision: 120244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120244 Log: 2006-12-28 Paul Thomas [EMAIL PROTECTED] PR fortran/30034 * resolve.c (resolve_formal_arglist): Exclude the test for pointers and procedures for subroutine arguments as well as functions. PR fortran/30237 * intrinsic.c (remove_nullargs): Do not pass up arguments with a label. If the actual has a label and the formal has a type then emit an error. 2006-12-28 Paul Thomas [EMAIL PROTECTED] PR fortran/30034 * gfortran.dg/pure_formal_proc_1.f90: New test. PR fortran/30237 * gfortran.dg/intrinsic_actual_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_3.f90 trunk/gcc/testsuite/gfortran.dg/pure_formal_proc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30237
[Bug preprocessor/30001] out-of-bounds access when processing empty file
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 18:45 --- Subject: Bug 30001 Author: tromey Date: Thu Dec 28 18:45:48 2006 New Revision: 120245 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120245 Log: PR preprocessor/30001: * charset.c (_cpp_convert_input): Check that to.len is greater than zero. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
[Bug preprocessor/30001] out-of-bounds access when processing empty file
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 18:47 --- I checked in the fix. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-28 19:11 --- This isn't really a gcc bug per se, so I am closing it. If someone wants to implement one or all of these on a branch, that is still fine. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug preprocessor/14460] --enable-c-mbchar will not work
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 19:12 --- This option no longer exists and 3.3 is no longer maintained. So, I am closing this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14460
[Bug fortran/30319] New: internal error in gfc_resolve_expr() for character parameter
U:\vrao\fortrantype gfort_bug_returns.f90 module amod character (len=1), parameter :: aa = z, bb(1) = (/aa/) end module amod U:\vrao\fortrangfortran -v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20061021 (experimental) U:\vrao\fortrangfortran -c gfort_bug_returns.f90 In file gfort_bug_returns.f90:3 end module amod 1 Internal Error at (1): gfc_resolve_expr(): Bad expression type -- Summary: internal error in gfc_resolve_expr() for character parameter Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug fortran/30319] internal error in gfc_resolve_expr() for character parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 19:19 --- Confirmed, even as of today. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-12-28 19:19:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-28 19:35 --- Created an attachment (id=12845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12845action=view) preliminary patch needs proper testing / splitting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
[Bug fortran/30319] internal error in gfc_resolve_expr() for character parameter
--- Comment #2 from kargl at gcc dot gnu dot org 2006-12-28 19:37 --- The following appears to work, so Vivek if you have a critical need to get an application compiled. You can split the line. module amod ! The following is a work around. character (len=1), parameter :: aa = z character (len=1), parameter :: bb(1) = (/ aa /) end module amod -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30319
[Bug fortran/30320] New: program crash for SUM applied to zero-size array
U:\vrao\fortrangfortran -v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20061021 (experimental) U:\vrao\fortrantype xzero_size_array.f90 program xzero implicit none integer :: ii(1,0) ii = 1 print*,sum(ii,dim=1) =,sum(ii,dim=1) end program xzero U:\vrao\fortrangfortran xzero_size_array.f90 U:\vrao\fortrana.exe program crashes (Windows pop-up: a.exe has encountered a problem and needs to close) -- Summary: program crash for SUM applied to zero-size array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30320
[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-28 20:32 --- Doesn't seem to work. gcc.c-torture/execute/vrp-5.c fails because [5, +INF] + [5, +INF] is combined to [10, +INF-1] (and 5 + +INF-5 is zero anyways). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
[Bug fortran/30321] New: program crash for SUM applied to zero-size array
U:\vrao\fortrangfortran -v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20061021 (experimental) U:\vrao\fortrantype xzero_size_array.f90 program xzero implicit none integer :: ii(1,0) ii = 1 print*,sum(ii,dim=1) =,sum(ii,dim=1) end program xzero U:\vrao\fortrangfortran xzero_size_array.f90 U:\vrao\fortrana.exe program crashes (Windows pop-up: a.exe has encountered a problem and needs to close) -- Summary: program crash for SUM applied to zero-size array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug fortran/30321] program crash for SUM applied to zero-size array
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-28 21:20 --- Confirmed, the crash is within the library: $ gfortran -g xzero_size_array.f90 $ gdb ./a.out GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) r Starting program: /home/ig25/Krempel/a.out Failed to read a valid object file image from memory. Program received signal SIGSEGV, Segmentation fault. 0xb7f57b70 in *_gfortran_sum_i4 (retarray=0xbfbe19c0, array=0xbfbe1998, pdim=0x8048974) at ../../../../gcc/trunk/libgfortran/generated/sum_i4.c:125 125 *dest = 0; (gdb) p dest $1 = (GFC_INTEGER_4 *) 0x0 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-28 21:20:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-12-28 21:22 --- This is deep regression country; in the time I have to devote to this, I couldn't work it out. Unassigning myself (for now). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tkoenig at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-28 21:39 --- Additional data points: Reading/writing unformatted sequential doesn't work with g77 (fails with an error message on open), and it fails with ifort 8 for records longer than 2**18 bytes (ifort's default buffer size). Because of the complications with record markers, this might be much easier to implement for stream access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug tree-optimization/30316] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
--- Comment #3 from deji_aking at yahoo dot ca 2006-12-28 22:07 --- I'm sorry, it seems I'd posted the .cpp of a different code other than the one that ICEd(signal.cc). However, the .cpp of signal.cc doesn't ICE for me too. In any case I've done as you requested and put signal.ii on ftp://czar.eas.yorku.ca/pub/signal.ii Moreover, I noticed the ICE when just compiling the code is different from the ICE when compiling with '-save-temps' Without -save-temps [EMAIL PROTECTED] tests]$ g++ -DHAVE_CONFIG_H -DBIRNET_LOG_DOMAIN='signal' -DPARANOID -DG_DISABLE_CONST_RETURNS -I. -I. -I../.. -I../.. -I../.. -I. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -D_BIRNET_SOURCE_EXTENSIONS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g -DG_ENABLE_DEBUG -Wdeprecated -Wno-cast-qual -ftracer -finline-functions -fno-keep-static-consts -fmessage-length=80 -MT signal.o -MD -MP -MF .deps/signal.Tpo -c -o signal.o signal.cc ./birnetsignalslot.hh: In function Birnet::Signals::Slot3R0, A1, A2, A3, void Birnet::Signals::slot(Class, R0 (Class::*)(A1, A2, A3)) [with Class = unnamed::Connection3, R0 = void, A1 = int, A2 = Birnet::String, A3 = float]: ./birnetsignalslot.hh:126: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. With -save-temps [EMAIL PROTECTED] tests]$ g++ -DHAVE_CONFIG_H -DBIRNET_LOG_DOMAIN='signal' -DPARANOID -DG_DISABLE_CONST_RETURNS -I. -I. -I../.. -I../.. -I../.. -I. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -D_BIRNET_SOURCE_EXTENSIONS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g -DG_ENABLE_DEBUG -Wdeprecated -Wno-cast-qual -ftracer -finline-functions -fno-keep-static-consts -fmessage-length=80 -MT signal.o -MD -MP -MF .deps/signal.Tpo -c -o signal.o signal.cc -save-temps g++: warning: -pipe ignored because -save-temps specified ./birnetsignalslot.hh: In function Birnet::Signals::Slot4R0, A1, A2, A3, A4, void Birnet::Signals::slot(Class, R0 (Class::*)(A1, A2, A3, A4)) [with Class = unnamed::Connection3, R0 = Birnet::String, A1 = unnamed::Emitter3, A2 = int, A3 = Birnet::String, A4 = float]: ./birnetsignalslot.hh:40126: internal compiler error: in referenced_var_lookup, at tree-dfa.c:615 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] tests]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
[Bug tree-optimization/30316] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-28 22:16 --- I can reproduce it this time and now I am reducing the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-12-28 23:11 --- I will work at it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-16 21:34:27 |2006-12-28 23:11:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug middle-end/30322] New: fold folds -i-1+i+1 to ~i+i+1
int bar(int i)
{
return -i-1+i+1;
}
optimizes to
;; Function bar (bar)
Analyzing Edge Insertions.
bar (i)
{
bb 2:
return i + 1 + ~i;
}
(instead of return 0; which we catch at rtl level later)
Either i+1 needs to be folded to -~i, we need to re-associate earlier
or something needs to do tree-combining and recognize that ~i and -(i+1)
is the same.
This happens in tramp3d as loop exit condition and shows up as
if (d.22083 != (int) ((unsigned int) d + 1 + (unsigned int) D.902833 +
(unsigned int) ~d)) goto L3; else goto L6;
instead of just
if (d.22083 != D.902833) goto L3; else goto L6;
[I think most of these interesting foldings should be deferred]
--
Summary: fold folds -i-1+i+1 to ~i+i+1
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug middle-end/30322] ((-i-1) + i) +1) is turned into ~i + (i+1) and never into 0 on the tree level
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 23:42 ---
[I think most of these interesting foldings should be deferred]
This is not an interesting fold anyways, unlike say the range generator.
Also this is really a reassociate issue.
if we wrote the function like:
int bar(int i)
{
return -i-1+1+i;
}
We get the correct result as we get:
((~i) + 1) + i
which gets folded into:
-i + i
which then gets folded into:
0
needs to do tree-combining
Won't help because this still needs a reassociate.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|fold folds -i-1+i+1 to |((-i-1) + i) +1) is turned
|~i+i+1 |into ~i + (i+1) and never
||into 0 on the tree level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug tree-optimization/30316] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-28 23:50 --- *** This bug has been marked as a duplicate of 29585 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-28 23:50 --- *** Bug 30316 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug c/30323] New: shared clauses for const variables are illigal
Compiling the following code with gcc -fopenmp -O -Wall
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i 20; i++)
A[i] = x;}
}
foo.c: In function 'foo':
foo.c:8: error: 'x' is predetermied 'shared' for 'shared'
--
Summary: shared clauses for const variables are illigal
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba at et dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug c/30324] New: shared clauses for const variables are illigal
Compiling the following code with gcc -fopenmp -O -Wall
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i 20; i++)
A[i] = x;}
}
foo.c: In function 'foo':
foo.c:8: error: 'x' is predetermied 'shared' for 'shared'
--
Summary: shared clauses for const variables are illigal
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba at et dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30324
[Bug c/30325] New: shared clauses for const variables are illigal
Compiling the following code with gcc -fopenmp -O -Wall
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i 20; i++)
A[i] = x;}
}
foo.c: In function 'foo':
foo.c:8: error: 'x' is predetermied 'shared' for 'shared'
--
Summary: shared clauses for const variables are illigal
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba at et dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30325
[Bug c/30324] shared clauses for const variables are illigal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 --- *** This bug has been marked as a duplicate of 30323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30324
[Bug c/30323] shared clauses for const variables are illigal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 --- *** Bug 30324 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug c/30325] shared clauses for const variables are illigal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 --- *** This bug has been marked as a duplicate of 30323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30325
[Bug c/30323] shared clauses for const variables are illigal
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 --- *** Bug 30325 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug c/30323] shared clauses for const variables are illigal
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-29 01:49 ---
Real testcase:
void foo()
{
int A[20];
const int x = 3;
int i;
#pragma omp parallel for shared(x)
for(i = 0; i 20; i++)
A[i] = x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug c/30326] New: shared clauses for const variables are illigal
Compiling the following code with gcc -fopenmp -O -Wall
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i 20; i++)
A[i] = x;}
}
foo.c: In function 'foo':
foo.c:8: error: 'x' is predetermied 'shared' for 'shared'
--
Summary: shared clauses for const variables are illigal
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba at et dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30326
[Bug c/30323] shared clauses for const variables are illigal
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-29 01:56 --- 2.8.1.1 Sharing Attribute Rules for Variables Referenced in a Construct line 7 on page 64: Variables with const-qualified type having nomutable member are shared. Variables with predetermined sharing attributes may not be listed in data-sharing attribute clauses, with the following exceptions: The loop iteration variable in the for-loop of a for or parallel for construct may be listed in a private or lastprivate clause. So this is invalid and the error message is correct as the const variable has a predetermined sharing attributes and you are trying to list it in a data sharing attribute cause. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug c/30326] shared clauses for const variables are illigal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:57 --- *** This bug has been marked as a duplicate of 30323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30326
[Bug c/30323] shared clauses for const variables are illigal
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-29 01:57 --- *** Bug 30326 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-29 02:54 --- I am testing a patch for this. It pedwarns on '#foo' in an expression, and also when #assert or #unassert is used. It also warns about these when -Wdeprecated is given. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug preprocessor/28165] _Pragma GCC system_header broken
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-29 03:28 --- This happens because destringize_and_run calls cpp_push_buffer. The new buffer has a non-null 'prev'; do_pragma_system_header checks for prev==NULL to determine whether the directive is in the primary source file. I'm testing a patch for this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-29 03:28:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
[Bug preprocessor/28165] _Pragma GCC system_header broken
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 04:29 --- I think this will also occur for _Pragma(once) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
[Bug pch/9471] #pragma system_header vs. precompiled headers
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-29 04:30 --- I think this same problem will occur with #include_next and #pragma once. cpp doesn't currently seem to differentiate between the PCH case and other kinds of preprocessing. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9471
[Bug middle-end/30311] [4.3 regression] revision 120211 failed to compile perlbench
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-12-29 04:36 --- A similar error that may be related was posted here: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01713.html The testcase in my post was from a gcc bootstrap. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug libgomp/29986] testsuite failures
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 --- I think the first step is to report it to sun so they track it and hopefully one day fix their toolchain. Does anyone have a support contract who can file a report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug libgomp/29987] libgomp.c++/ctor-9.C failure
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 --- I think the first step is to report it to sun so they track it and hopefully one day fix their toolchain. Does anyone have a support contract who can file a report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug target/30040] -mtune=native is wrong for Core 2 Duo and Core Duo
--- Comment #9 from hjl at gcc dot gnu dot org 2006-12-29 06:09 --- Subject: Bug 30040 Author: hjl Date: Fri Dec 29 06:09:06 2006 New Revision: 120256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120256 Log: 2006-12-28 H.J. Lu [EMAIL PROTECTED] Backport from mainline: 2006-12-02 H.J. Lu [EMAIL PROTECTED] PR target/30040 * config/i386/driver-i386.c: Include coretypes.h and tm.h. (host_detect_local_cpu): Check -mtune= vs. -march=. Rewrite processor detection. * config/i386/i386.h (CC1_CPU_SPEC): Add -mtune=native for -march=native if there is no -mtune=*. * config/i386/x-i386 (driver-i386.o): Also depend on $(TM_H) coretypes.h. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/driver-i386.c branches/gcc-4_2-branch/gcc/config/i386/i386.h branches/gcc-4_2-branch/gcc/config/i386/x-i386 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug boehm-gc/30327] New: The make script periodically thinks my 7450 is an 8540
The system is a Dual 800 MHz PowerPC G4 (7450) (QuickSilver) running under Darwin 8.8.0. The command sequence is as follows: cd gcc mkdir build cd build ../configure make make.log Periodically, the following appears: ../../gcc/config/rs6000/altivec.md:xxx: warning operand 3 missing mode? I am assuming that the rs6000 has the same altivec as the 74xx series. Periodically, the following also apppears: Links are now set up to build a native compiler for powerpc-apple-darwin8.8.0. Also, there were the following automatons: Automaton `ppc7450fp' 36 NDFA states, 75 NDFA arcs 36 DFA states, 75 DFA arcs 36 minimal DFA states, 75 minimal DFA arcs 462 all insns 5 insn equivalence classes 0 locked states 76 transition comb vector els, 180 trans table els: use simple vect 180 min delay table els, compression factor 1 Automaton `ppc8540_retire' 162 NDFA states,876 NDFA arcs 162 DFA states, 876 DFA arcs 81 minimal DFA states, 438 minimal DFA arcs 462 all insns 8 insn equivalence classes 0 locked states 509 transition comb vector els, 648 trans table els: use simple vect 648 min delay table els, compression factor 2 After several hours, the following appeared: mkdir ppc64 later to be followed by: checking whether c compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile use '--host'. See 'config.log' for more details. make[1]: *** [configure-target-boehm-gc] error 1 make: *** [all] Error 2 ~/gcc/build/powerpc-apple-darwin8.8.0/ppc64/boehm-gc/configure.log is as follows: configure:2346: checking whether the C compiler works configure:2352: ./a.out ../../../../boehm-gc/configure: line 1: ./a.out: Bad CPU type in executable configure:2355: $? = 126 configure:2364: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. which appears to indicate that an attempt was made to run an 8540 compiled program on a 7450. This happened twice. -- Summary: The make script periodically thinks my 7450 is an 8540 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trog24 at comcast dot net GCC build triplet: powerpc-apple-darwin8.8.0 GCC host triplet: powerpc-apple-darwin8.8.0 GCC target triplet: powerpc-apple-darwin8.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30327
[Bug boehm-gc/30327] The make script periodically thinks my 7450 is an 8540
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 06:23 --- Since you don't have a G5, you should do --disable-multilib. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30327
[Bug c++/30328] New: bit-field: unassemblable assembly code
gcc produces unassemblable assembly code.
//testcase:
struct S
{
signed int a:17;
} x;
typedef typeof (x.a) foo;
template class T
T* inc(T* p) { return p+1; }
int main ()
{
foo x[2] = { 1,2 };
int y[2] = { 1,2 };
*inc(x);
*inc(y);
return 0;
}
result
$ g++ -S bug.cpp
$ g++ -c bug.s
bug.s: Assembler messages:
bug.s:18: Error: symbol `__Z3incIiEPT_S1_' is already defined
gcc version: 4.2 20061212
--
Summary: bit-field: unassemblable assembly code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
[Bug c/30329] New: Gcc Linker problem
If i have a shared lib with some name like FTPobex with funtion name
Func1()
{
printf(First function);
}
And i have my local function
void main()
{
Func1();/i call this function here using shared lib
}
//local function
Func1()
{
printf(First function);
}
Here,Func1() is a local function for this program .My program is not giving any
linker error on this when i compiled it using GCC.There are 2 definitions of
same function then also it works..Amazaing...?
Then i remove my local Func1() function then it goes to shaerd lib
funciotn and access that...Quite strange ? TRy it.
Hope GCC developers will look on it.
[EMAIL PROTECTED]
--
Summary: Gcc Linker problem
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shantibhushan dot sale at gmail dot com
GCC build triplet: GCC
GCC host triplet: Linux
GCC target triplet: Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30329
[Bug preprocessor/21521] -finput-charset -save-temps converts characters twice
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 07:43 --- I looked at this a bit tonight. It is straightforward to remove -finput-charset from the second invocation of cc1 (needed several places -- gcc.c but also the c++ and objc lang-specs). I think this approach fails if -combine is used; this is easily fixed if it is ok to assume that .i files are encoded in the internal charset. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21521
[Bug c/30329] Gcc Linker problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 07:44 --- This problem if it is a real issue, is not a GCC issue at all, GCC does not do dynamic loading or even the static linking. The problem here is you don't understand elf semantics. since we know that Func1 is local to the TU and you are not compiling with -fPIC/-fPIE/-fpie/-fpic, then we call directly Func1 in main instead of going through a PLT. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30329
[Bug preprocessor/14438] Potential need for buffer overflow checks in _cpp_lex_direct
--- Comment #25 from tromey at gcc dot gnu dot org 2006-12-29 07:58 --- FWIW I've been looking at this area for PR 29966. I don't see how overflow checking could be added to _cpp_lex_direct. However I did end up adding an assertion to _cpp_lex_token, to try to expose a hidden assumption: if (pfile-cur_token pfile-cur_run-base || pfile-cur_token = pfile-cur_run-limit) abort (); I also looked at the other assignments to cur_token and (aside from the one fixed in my forthcoming patch) they all look ok. So, I think this PR can be closed. Please reopen if you think I've done this in error. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14438
