[Bug middle-end/42952] [4.5 Regression] possible integer wrong code bug
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code Summary|possible integer wrong code |[4.5 Regression] possible |bug |integer wrong code bug Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-02-04 07:36 --- *** Bug 42953 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/42953] bad epilogue scheduling leads to stack corruption
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-04 07:36 --- *** This bug has been marked as a duplicate of 30282 *** -- 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=42953
[Bug target/42953] bad epilogue scheduling leads to stack corruption
--- Comment #2 from wilson at gcc dot gnu dot org 2010-02-04 07:34 --- Created an attachment (id=19802) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19802&action=view) Assembly code showing bad epilogue scheduling. This was generated with -O2 -fno-omit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug target/42953] bad epilogue scheduling leads to stack corruption
--- Comment #1 from wilson at gcc dot gnu dot org 2010-02-04 07:30 --- Created an attachment (id=19801) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19801&action=view) testcase for gcc mainline (rev 156310) GCC generates incorrect epilogue code for this testcase with -O2 -fno-omit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug target/42953] New: bad epilogue scheduling leads to stack corruption
The svr4 ABI requires that r1 (SP) always be valid, so it must be restored at the end of the epilogue, after the last register restore read from the stack frame. Unfortunately, in some cases, the PPC port is scheduling the epilogue set of r1 before some register restores. If you take an interrupt in between the r1 set and a register restore, and the interrupt handler uses the process stack, the interrupt handler may overwrite saved registers before they can be restored. This causes difficult to debug failures. I can reproduce the failure with -O2 -fno-omit-frame-pointer. I don't know if the problem can be triggered with other optimization options. The PPC port tries to prevent the r1 set from being moved before register restores by emitting a stack_tie instruction. This uses a BLKmode read from the stack frame, which in theory should conflict with the register reads and the set of r1. But this fails because of how reg_base_value works in alias.c. The PPC port is using a temp register r11 in the epilogue. In my testcase, r11 is set in the function body to the address of a variable in data. The code that sets reg_base_value, in init_alias_analysis in alias.c, deliberately ignores instructions in the prologue and epilogue. Thus it sees only one store to r11, and decides that r11 must hold a data variable address everywhere in the function. When we check stack reads (using r11) against the stack_tie insn (using r1), alias analysis decides that they can't conflict because r1 points to the stack and r11 points to data. Thus incorrect insn scheduling occurs. This seems to be a flaw in alias analysis. If we aren't going to count prologue/epilogue insns when computing reg_base_value, then we should not use reg_base_value when disambiguating insns in the prologue/epilogue. Unfortunately, the interface to alias is passing in only MEMs, not insns, so we can't easily tell when we have a prologue/epilogue MEM. A possible simple way to solve the problem is to use a stricter stack_tie insn. I noticed that the ARM port has one that uses (mem:BLK (scratch)). If I hack this into the rs6000 port, then this problem goes away. Testing for this is one of the first things that write_dependence_p does, so this prevents any possible reg_base_value confusion. This only fails if I get a symbol address into r11, and r11 is only set once, so it is a bit tricky to reproduce with small examples. I do have a testcase that works with gcc mainline which I will attach. -- Summary: bad epilogue scheduling leads to stack corruption Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilson at gcc dot gnu dot org GCC target triplet: powerpc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42953
[Bug c++/42472] class members not getting assigned access thru another method
--- Comment #4 from k_suresh_babu at yahoo dot com 2010-02-04 07:07 --- Subject: Re: class members not getting assigned access thru another method palo, thank you for the clarification. You can close the bug. regards, sureshbk. --- On Fri, 12/25/09, paolo dot carlini at oracle dot com wrote: > From: paolo dot carlini at oracle dot com > Subject: [Bug c++/42472] class members not getting assigned access thru > another method > To: k_suresh_b...@yahoo.com > Date: Friday, December 25, 2009, 3:50 AM > > > --- Comment #3 from paolo dot carlini at oracle dot > com 2009-12-25 09:50 --- > Yes, in C++03 (C++0x will be different), a constructor > cannot call *another > constructor*. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472
[Bug c/42952] New: possible integer wrong code bug
The program below looks to me like it should print "0".
reg...@john-home:~$ current-gcc -O small.c -o small
reg...@john-home:~$ ./small
1
reg...@john-home:~$ cat small.c
extern int printf (__const char *__restrict __format, ...);
static int g_16[1];
static int *g_135 = &g_16[0];
static int *l_15 = &g_16[0];
static void foo (void)
{
g_16[0] = 1;
*g_135 = 0;
*g_135 = *l_15;
printf("%d\n", g_16[0]);
}
int main(void)
{
foo();
return 0;
}
reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r156486-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r156486-install --program-prefix=r156486-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100204 (experimental) (GCC)
--
Summary: possible integer wrong code bug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42952
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #3 from paul dot richard dot thomas at gmail dot com 2010-02-04 05:33 --- Subject: Re: ICE segfault when reading module file Tobias, I'll give it some thought at lunchtime. Cheers Paul On Wed, Feb 3, 2010 at 9:40 PM, burnus at gcc dot gnu dot org wrote: > > > --- Comment #2 from burnus at gcc dot gnu dot org 2010-02-03 20:40 > --- > Paul, maybe you have an idea how to solve this best. > > One has two modules, (1) one defines "vs_str" and the other (2) defines > interface > module procedure len > end interface > PRIVATE :: len > (and a public interface which uses "len") > > Now in a third (3) module, one loads first module (2) and then module (1); > when > writing the .mod for (3) one writes the following symbol of module (1): > > pure function vs_str(s) result(vs) > character(len=*), intent(in) :: s > character, dimension(len(s)) :: vs > > Now when writing the expression for the upper bound of "vs" (viz. "len(s)"), > one has e->expr_type == EXPR_FUNCTION but e->symtree == NULL, which crashes. > > Note: mio_expr calls fix_mio_expr(), which tries to fix it for the intrinsic > "len", but > e->symtree = gfc_find_symtree (gfc_current_ns->sym_root, fname); > returns NULL. > > On solution I see is to create a new symtree and add it in fix_mio_expr via > gfc_get_intrinsic_sub_symbol, but somehow I think "len" should not have > disappeared at the first place. > > The crash happens in mio_symtree_ref which simply checks whether the symbol > needs to be written or whether it has been written already. For an intrinsic > fucntion, it does not matter and could thus be skipped (not checked!). For > output, mio_expr then simply writes "0" (for intrinsic function) and "len" > (for > the function name) - albeit with accessing the e->symtree. Thus, one could > also > modify "EXPR_FUNCTION:" of mio_expr to for e->symtree == NULL and (iomode == > IO_OUTPUT) but that means some code replication. > > > -- > > burnus at gcc dot gnu dot org changed: > > What |Removed |Added > > CC| |pault at gcc dot gnu dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug libstdc++/41816] libstdc++.so.6.0.14-gdb.py is not an ELF file
--- Comment #4 from dirtyepic at gentoo dot org 2010-02-04 05:02 --- would it be possible to get a configure flag specifying where to install these files, which we could then set to gdb's auto-load directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #1 from nightstrike at gmail dot com 2010-02-04 04:10 --- The logs are not updated daily, but I try to do them frequently. I thought there was date information within the logs themselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #3 from davek at gcc dot gnu dot org 2010-02-04 03:37 --- (In reply to comment #2) > Created an attachment (id=19671) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19671&action=view) [edit] > patch > > now it summons gcj-noncore dll and resolves classes which should have been > resolved. i know it's not perfect. so i need your revision. Thanks for this analysis, I think you're right, the classes provided in the noncore dll need to be present and there aren't always linker dependencies to bring them in. I'll try and figure a way to do it automatically using static dependencies. -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-04 03:37:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug middle-end/42290] strange 'warning: "ISRA.2" may be used uninitialized in this function'
--- Comment #7 from zsojka at seznam dot cz 2010-02-04 03:01 --- I can't reproduce this issue in current trunk (r156468) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42290
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-02-04 01:53 --- Subject: Bug 42901 Author: jvdelisle Date: Thu Feb 4 01:53:37 2010 New Revision: 156488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156488 Log: 2010-02-03 Jerry DeLisle PR libfortran/42901 * gfortran.dg/namelist_60.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_60.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-02-04 01:50 --- Subject: Bug 42901 Author: jvdelisle Date: Thu Feb 4 01:49:41 2010 New Revision: 156487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156487 Log: 2010-02-03 Jerry DeLisle PR libfortran/42901 * io/list_read.c (nml_get_obj_data): Add new qualifier flag, clean up code, and adjust logic to set namelist info pointer correctly for array qualifiers of derived type components. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42901
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-02-04 01:12 --- Any further word on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2010-02-04 01:08 --- No further replies, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #15 from bkoz at gcc dot gnu dot org 2010-02-04 00:16 --- markup options /** * @brief Flags access. * @return The minimum field width to generate on output operations. * * "Minimum field width" refers to the number of characters. * * " * Minimum field width * " * refers to the number of characters. * * * Minimum field width * * refers to the number of characters. * * @a Minimum field width * refers to the number of characters. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug target/42951] New: GCC pedwarns about use of static inline functions from system headers in extern inline functions
GCC 4.3 prints an unsuppressable warning about any use of a static inline
function in a non-static inline function. This includes static inline
functions in GCC's own target-specific extra_headers header files.
For example, this short file uses the ARM/NEON intrinsics functions defined in
arm_neon.h:
#include
extern inline uint8x8_t vect_add(uint8x8_t a, uint8x8_t b)
{
return vadd_u8(a, b);
}
$ arm-linux-gnueabi-gcc -mfpu=neon -c inline-test-neon.c
inline-test-neon.c: In function 'vect_add':
inline-test-neon.c:5: warning: 'vadd_u8' is static but used in inline function
'vect_add' which is not static
The example uses gnu_inline style inlining, but the same thing happens with
C99-style inlining if "extern inline" is changed to "inline".
PR 34000 fixed this problem for x86 targets (the *mmintrin.h files), but the
problem persists for other targets.
In particular, the following header files mentioned in extra_targets lines in
config.gcc still have static inline functions:
arm/arm_neon.h
arm/mmintrin.h
i386/cpuid.h
mips/loongson.h
rs6000/ppu_intrinsics.h
rs6000/si2vmx.h
rs6000/spe.h
rs6000/spu2vmx.h
sh/ushmedia.h
spu/spu_internals.h
spu/spu_mfcio.h
spu/vmx2spu.h
PR 34000's fix, of changing "static __inline void
__attribute__((__always_inline__, __artificial__))" to "extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))", should
work for the other targets as well.
Full gcc -v output:
$ arm-linux-gnueabi-gcc -v -mfpu=neon -c inline-test-neon.c
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.2-1ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.4-armel/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.4.2
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions
--with-arch=armv7-a --with-tune=cortex-a8 --with-float=softfp --with-fpu=vfp
--disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib --build=i486-linux-gnu
--host=i486-linux-gnu --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.2 (Ubuntu 4.4.2-1ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv7-a' '-mtune=cortex-a8'
'-mfloat-abi=softfp'
/usr/lib/gcc/arm-linux-gnueabi/4.4.2/cc1 -quiet -v inline-test-neon.c -quiet
-dumpbase inline-test-neon.c -mfpu=neon -march=armv7-a -mtune=cortex-a8
-mfloat-abi=softfp -auxbase inline-test-neon -version -o /tmp/ccWFWFb1.s
ignoring duplicate directory
"/usr/lib/gcc/arm-linux-gnueabi/4.4.2/../../../../arm-linux-gnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/arm-linux-gnueabi/4.4.2/include
/usr/lib/gcc/arm-linux-gnueabi/4.4.2/include-fixed
/usr/arm-linux-gnueabi/include
End of search list.
GNU C (Ubuntu 4.4.2-1ubuntu1) version 4.4.2 (arm-linux-gnueabi)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version
2.4.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: eb94b7d3ec6a4a03406c63875e22eff0
inline-test-neon.c: In function 'vect_add':
inline-test-neon.c:5: warning: 'vadd_u8' is static but used in inline function
'vect_add' which is not static
COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv7-a' '-mtune=cortex-a8'
'-mfloat-abi=softfp'
/usr/lib/gcc/arm-linux-gnueabi/4.4.2/../../../../arm-linux-gnueabi/bin/as
-march=armv7-a -mfloat-abi=softfp -mfpu=neon -meabi=5 -o inline-test-neon.o
/tmp/ccWFWFb1.s
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.4.2/:/usr/lib/gcc/arm-linux-gnueabi/4.4.2/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.4.2/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.4.2/../../../../arm-linux-gnueabi/bin/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.4.2/:/usr/lib/gcc/arm-linux-gnueabi/4.4.2/../../../../arm-linux-gnueabi/lib/
COLLECT_GCC_OPTIONS='-v' '-mfpu=neon' '-c' '-march=armv7-a' '-mtune=cortex-a8'
'-mfloat-abi=softfp'
--
Summary: GCC pedwarns about use of static inline functions from
system headers in extern inline functions
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lennox at cs dot columbia dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42951
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #14 from bkoz at gcc dot gnu dot org 2010-02-03 23:07 --- Got it Matthias, fixing, thanks for explaining what's up. How do you get these errors and validate the generated man pages? If it's a script can you attach it? Are you re-configuring doxygen? Or is this post-generation of the 'doc-man-doxygen' rule? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug libstdc++/41816] libstdc++.so.6.0.14-gdb.py is not an ELF file
--- Comment #3 from bkoz at gcc dot gnu dot org 2010-02-03 22:59 --- What's the status here? Any chance we could frame the subject as something that has conflict, instead of a statement everyone agrees with? ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #13 from davidxl at gcc dot gnu dot org 2010-02-03 22:05 --- (In reply to comment #12) > Btw, a destructor call also changes the vtbl pointer. > ctors, dtors, wrapper function calls etc are all handled. Detailed write up will be available at some point. To put it a simple way, it is done via live across analyis: if an poly object is referenced before and after a call (accesses to any field of it) both available and anticipated from a a call -- it is live across the call -- vptr field won't be modified by the call. Partially anticipated case is also handled. Once vptr is handled, vtbl access follows automatically -- at vtbls are RO. vptr assignment is treated conservatively. I implemented this thing in 4.4 line using special shadow symbols and VUSE/VDEFS. It works as expected except that SCCVN time went to hell. Simple fix to collapse varying defs in DFS walk help a lot but still slow. Need to do this using alias oracle. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/42870] [4.5 regression] __attribute__ ((dllexport)) produces broken linkage
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-02 13:41:36 |2010-02-03 22:02:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42870
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-03 22:01 --- Fixed for 4.5 with -fabi-version=4 or =0. I still want to implement a transition scheme. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #16 from jason at gcc dot gnu dot org 2010-02-03 21:59 --- . -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-03 21:59 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-02-03 21:55 --- Btw, a destructor call also changes the vtbl pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-02-03 21:55 --- (In reply to comment #9) > Ah, "Set aside the standard". Another user who wants to make up his own > semantics for a standardized language. No, no, and damn no. > Of course, things like this can be brought up to the language committee as long as it is 1) not ambiguous 2) and generally useful. (In terms of optimization related semantics (type aliasing, restrict etc), I am not sure how standard it actually is given the ambiguity here and there.) David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-03 21:54 --- Oh, I wonder anyway how you are going to implement this "vtable pointers are special" thing in the alias machinery. Good luck - and please keep LTO in mind ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/40138] [4.5 Regression] ICE with invalid va_arg
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-03 21:53 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40138
[Bug c++/40138] [4.5 Regression] ICE with invalid va_arg
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-03 21:53 --- Subject: Bug 40138 Author: jason Date: Wed Feb 3 21:53:41 2010 New Revision: 156483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156483 Log: PR c++/40138 * fold-const.c (operand_equal_p): Handle erroneous types. Added: trunk/gcc/testsuite/g++.dg/ext/builtin11.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40138
[Bug other/41523] gcc generates few graph files with syntax errors
--- Comment #3 from twlevo at gmail dot com 2010-02-03 21:52 --- Created an attachment (id=19800) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19800&action=view) the patch to graph.c as diff thanks to Eric Fisher who made this diff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41523
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-03 21:49 --- Ah, "Set aside the standard". Another user who wants to make up his own semantics for a standardized language. No, no, and damn no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-02-03 21:44 ---
(In reply to comment #7)
> It is valid to use placement new to construct a more or less derived type
> which would change the vtable pointer.
>
> Thus I think this bug is still invalid.
>
How did you reach this conclusion from reading p7 of 3.8 in the standard?
"The original object was a most derived object of type T and the new object is
a most derived object of type T"
The following is allowed:
class B {
virtual ...
};
class D : public B {
...
};
B* bp = new D ();
...
new (bp) D();
but vptr does not change.
Set aside the standard -- this optimization is useful regardless. Some of the
develpoers are so desperate that they manually do LICM of vptr and vtbl access
for vcalls in the loop. The worst case is to use a option to guard it (which I
think the default should be on).
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug ada/42554] Can't build GNAT tools
--- Comment #12 from simon at pushface dot org 2010-02-03 21:24 --- I re-ran the tests just for Ada; results at http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00265.html . Looking good - there is a problem with the ACATS tests, but I have a feeling it's some sort of race condition in the test suite (for info, not a dejagnu suite). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-03 21:24 --- It is valid to use placement new to construct a more or less derived type which would change the vtable pointer. Thus I think this bug is still invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug fortran/42950] New: gfortran testsuite failures on mingw64
As mentioned by NightStrike on IRC. The MinGW64 results are at http://mingw-w64.sf.net/gfortran.log -- I assume that they are daily updated, but I do not know for sure (the HTTP header always shows the current date/time). Failures: (1) There are several run-time failures about "g0" with "Zero width in format descriptor". Tests: gfortran.dg/complex_intrinsic_5.f90 gfortran.dg/fmt_g0_1.f08 gfortran.dg/unlimited_fmt_1.f08 (2) /dev/null test (gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90) where seemingly #if defined _WIN32 #define DEV_NULL "nul" does not work as one gets: Fortran runtime error: File '/dev/null' does not exist (3) gfortran.dg/large_real_kind_2.F90 fails at run time, but I do not know where. (4) gfortran.dg/namelist_42.f90 fails at run time. (same problem: where? For NaN I/O?) (5) gfortran.dg/nan_3.f90 fails at run time (ditto) (6) gfortran.dg/streamio_16.f90 -- also some abort() call, but I do not see what goes wrong (not hitting EOF - END=?) -- Summary: gfortran testsuite failures on mingw64 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug c++/31816] [DR 225] If a function foo is defined before declaring a template class A, overloaded version of foo defined after the class declaration will not be available within class A.
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-03 20:56 --- Thanks. Jason, I was adding [DR 225] to the Subject when I noticed *another* DR 225, PR29131. Do we want to keep both or not? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|If a function foo is defined|[DR 225] If a function foo |before declaring a template |is defined before declaring |class A, overloaded |a template class A, |version of foo defined after|overloaded version of foo |the class declaration will |defined after the class |not be available within |declaration will not be |class A. |available within class A. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31816
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-03 20:52 --- Great! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug ada/42948] Generic instantiation inside protected object bug box
--- Comment #4 from tero dot koskinen at iki dot fi 2010-02-03 20:47 --- Another Ada compiler (Janus/Ada) accepts the code and gives following output when the program is ran: [C:\work\tests\rw1]main 0 0 0 0 0 0 0 0 0 0 [C:\work\tests\rw1] Which is probably the expected outcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42948
[Bug middle-end/42949] ICE: reload_cse_simplify_operands, at postreload.c:396
--- Comment #1 from rmansfield at qnx dot com 2010-02-03 20:47 --- Created an attachment (id=19799) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19799&action=view) Preprocessed C++ source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949
[Bug middle-end/42949] New: ICE: reload_cse_simplify_operands, at postreload.c:396
ICE in reload_cse_simplify_operands, at postreload.c:396. ICE doesn't happen
with an ARM EABI configuration.
r...@zoidberg:~/gnu/gcc/trunk/arm/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.5.0 20100203 (experimental) [trunk revision 156467] (GCC)
r...@zoidberg:~/gnu/gcc/trunk/arm/gcc$ ./xgcc -B. -O1 -mfpu=vfp
-mfloat-abi=softfp ~/ice.ii
/home/ryan/ice.ii: In member function 'virtual TTT* ticu::fold(TOperator, TTT*,
TInfoSink&)':
/home/ryan/ice.ii:175:6: error: insn does not satisfy its constraints:
(insn 741 248 742 6 /home/ryan/ice.ii:68 (set (mem/c:SF (plus:SI (reg/f:SI 11
fp)
(const_int -1024 [0xfc00])) [0 %sfp+-1020 S4 A32])
(reg:SF 78 s15)) 590 {*movsf_vfp} (nil))
/home/ryan/ice.ii:175:6: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE: reload_cse_simplify_operands, at postreload.c:396
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-03 20:43 --- Subject: Bug 4926 Author: jason Date: Wed Feb 3 20:42:48 2010 New Revision: 156482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156482 Log: PR c++/4926 PR c++/38600 * mangle.c (write_unqualified_id): Split out from write_expression. (write_unqualified_name): Call it. (write_member_name): Likewise. (write_expression): Support TEMPLATE_ID_EXPR. Disambiguate operator names. Added: trunk/gcc/testsuite/g++.dg/abi/mangle35.C trunk/gcc/testsuite/g++.dg/abi/mangle37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-03 20:43 --- Subject: Bug 38600 Author: jason Date: Wed Feb 3 20:42:48 2010 New Revision: 156482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156482 Log: PR c++/4926 PR c++/38600 * mangle.c (write_unqualified_id): Split out from write_expression. (write_unqualified_name): Call it. (write_member_name): Likewise. (write_expression): Support TEMPLATE_ID_EXPR. Disambiguate operator names. Added: trunk/gcc/testsuite/g++.dg/abi/mangle35.C trunk/gcc/testsuite/g++.dg/abi/mangle37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-03 20:43 --- Subject: Bug 12909 Author: jason Date: Wed Feb 3 20:42:35 2010 New Revision: 156481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156481 Log: PR c++/12909 * mangle.c (write_type) [VECTOR_TYPE]: Change mangling. Added: trunk/gcc/testsuite/g++.dg/abi/mangle36.C Modified: trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-03 20:40 --- Paul, maybe you have an idea how to solve this best. One has two modules, (1) one defines "vs_str" and the other (2) defines interface module procedure len end interface PRIVATE :: len (and a public interface which uses "len") Now in a third (3) module, one loads first module (2) and then module (1); when writing the .mod for (3) one writes the following symbol of module (1): pure function vs_str(s) result(vs) character(len=*), intent(in) :: s character, dimension(len(s)) :: vs Now when writing the expression for the upper bound of "vs" (viz. "len(s)"), one has e->expr_type == EXPR_FUNCTION but e->symtree == NULL, which crashes. Note: mio_expr calls fix_mio_expr(), which tries to fix it for the intrinsic "len", but e->symtree = gfc_find_symtree (gfc_current_ns->sym_root, fname); returns NULL. On solution I see is to create a new symtree and add it in fix_mio_expr via gfc_get_intrinsic_sub_symbol, but somehow I think "len" should not have disappeared at the first place. The crash happens in mio_symtree_ref which simply checks whether the symbol needs to be written or whether it has been written already. For an intrinsic fucntion, it does not matter and could thus be skipped (not checked!). For output, mio_expr then simply writes "0" (for intrinsic function) and "len" (for the function name) - albeit with accessing the e->symtree. Thus, one could also modify "EXPR_FUNCTION:" of mio_expr to for e->symtree == NULL and (iomode == IO_OUTPUT) but that means some code replication. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug ada/42948] Generic instantiation inside protected object bug box
--- Comment #3 from gcc at coreland dot ath dot cx 2010-02-03 20:29 --- A GNAT Pro customer I speak to says: main.adb:20:07: instantiation error at ng.adb:6 main.adb:20:07: missing argument for parameter "_Object" in call to "Show_N" (inherited) at line 14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42948
[Bug ada/42948] Generic instantiation inside protected object bug box
--- Comment #2 from gcc at coreland dot ath dot cx 2010-02-03 20:28 --- +===GNAT BUG DETECTED==+ | 4.5.0 20090514 (experimental) (i686-pc-linux-gnu) Assert_Failure exp_ch6.adb:4603| | Error detected at ng.adb:6:7 [main.adb:20:7] | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). main.adb ng.ads ng.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42948
[Bug ada/42948] Generic instantiation inside protected object bug box
--- Comment #1 from gcc at coreland dot ath dot cx 2010-02-03 20:24 --- Created an attachment (id=19798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19798&action=view) Repro -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42948
[Bug ada/42948] New: Generic instantiation inside protected object bug box
$ gnatchop blob.adb $ gnatmake main +===GNAT BUG DETECTED==+ | 4.4.2 (i486-pc-linux-gnu) Assert_Failure exp_ch6.adb:4602| | Error detected at ng.adb:6:7 [main.adb:20:7] | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. main.adb ng.ads list may be incomplete compilation abandoned gnatmake: "main.adb" compilation error -- Summary: Generic instantiation inside protected object bug box Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at coreland dot ath dot cx GCC host triplet: i486-pc-linux-gnu, x86_64-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42948
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-02-03 19:48 --- Subject: Re: [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand > --- Comment #10 from sje at cup dot hp dot com 2010-02-03 19:31 --- > > > return XVECEXP (XEXP (x, 1), 0, 0); > > > > The return is wrong. The UNSPEC_DLTIND14R operation returns the > > address of XVECEXP (XEXP (x, 1), 0, 0). > > > Is it as simple as wrapping this in a MEM rtx? I am testing > > return gen_rtx_MEM (GET_MODE (x), XVECEXP (XEXP (x, 1), 0, 0)); > > So far, so good. That may well be the solution. The code in pa.c uses gen_const_mem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #10 from sje at cup dot hp dot com 2010-02-03 19:31 --- > > return XVECEXP (XEXP (x, 1), 0, 0); > > The return is wrong. The UNSPEC_DLTIND14R operation returns the > address of XVECEXP (XEXP (x, 1), 0, 0). Is it as simple as wrapping this in a MEM rtx? I am testing return gen_rtx_MEM (GET_MODE (x), XVECEXP (XEXP (x, 1), 0, 0)); So far, so good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable
--- Comment #4 from vmakarov at gcc dot gnu dot org 2010-02-03 19:01 --- Subject: Bug 42941 Author: vmakarov Date: Wed Feb 3 19:01:31 2010 New Revision: 156472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156472 Log: 2010-02-03 Vladimir Makarov PR rtl-optimizations/42941 * sched-deps.c (setup_insn_reg_pressure_info): Use xcalloc instead of xmalloc. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941
[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable
--- Comment #3 from vmakarov at redhat dot com 2010-02-03 18:57 --- This is a rare case when the algorithm works the same whatever values are in memory. Roughly speaking, if the value is not as expected (for example a garbage) the value is set up to what it needed. If it is one as expected we do nothing and have the same result. Valgrind warns because the data is not initialized. I'll submit a patch soon for initialization of the values. The compiler will work absolutely the same (may be a bit slower because of the initialization) but there will be no valgrind warnings which will simplify compiler debugging by valgrind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #6 from davidxl at gcc dot gnu dot org 2010-02-03 18:30 --- See discussions in http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00138.html about changing dynamic types using placement new -- it is basically not allowed -- so the optimization is valid. David -- davidxl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davidxl at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-29 22:42:58 |2010-02-03 18:30:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/40138] [4.5 Regression] ICE with invalid va_arg
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-09-09 10:00:28 |2010-02-03 17:56:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40138
[Bug target/42947] New: multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib
Configuring with following options --build=x86_64-linux --host=x86_64-linux --target=sh4-oe-linux --prefix=/scratch/oe/qemush4/cross/sh4 --exec_prefix=/scratch/oe/qemush4/cross/sh4 --bindir=/scratch/oe/qemush4/cross/sh4/bin --sbindir=/scratch/oe/qemush4/cross/sh4/bin --libexecdir=/scratch/oe/qemush4/cross/sh4/libexec --datadir=/scratch/oe/qemush4/cross/sh4/share --sysconfdir=/scratch/oe/qemush4/cross/sh4/etc --sharedstatedir=/scratch/oe/qemush4/cross/sh4/com --localstatedir=/scratch/oe/qemush4/cross/sh4/var --libdir=/scratch/oe/qemush4/cross/sh4/lib --includedir=/scratch/oe/qemush4/cross/sh4/include --oldincludedir=/scratch/oe/qemush4/cross/sh4/include --infodir=/scratch/oe/qemush4/cross/sh4/share/info --mandir=/scratch/oe/qemush4/cross/sh4/share/man --with-local-prefix=/scratch/oe/qemush4/staging/sh4-oe-linux/usr --enable-shared --disable-multilib --disable-threads --enable-languages=c --enable-target-optspace --program-prefix=sh4-oe-linux- --with-sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --with-build-sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --disable-libmudflap --disable-libgomp --disable-libssp --enable-__cxa_atexit Thread model: single gcc version 4.5.0 20100127 (experimental) (GCC) The compilation fails during libgcc build because its not able to find crti.o Reducing the problem, when -m4 is explicitly mentioned on the commandline then gcc calls collect2 with different parameters. with -m4 /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/collect2 --sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux/m4 --eh-frame-hdr -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 crt1.o crti.o /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtbegin.o -L/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc /tmp/ccwddCby.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtend.o crtn.o /scratch/oe/qemush4/cross/sh4/sh4-oe-linux/bin/ld: crt1.o: No such file: No such file or directory without -m4 COLLECT_GCC_OPTIONS='-v' '-B/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc' /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/collect2 --sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --eh-frame-hdr -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crt1.o /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crti.o /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtbegin.o -L/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc -L/scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib /tmp/cch1T65V.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtend.o /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crtn.o --sysroot is appended with 'm4' the default multilib is m4 so it should have looked under base sysroot like it did when no -m4 was used and crti.o and crtn.o are not used with absolute path if I use any other option other than -m4 say -m4-nofpu it works ok. It works ok on gcc 4.4 may be http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00432.html is related to this. -- Summary: multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: sh4-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
[Bug c++/35652] [4.3/4.4/4.5 Regression] offset warning should be given in the front-end
--- Comment #36 from jason at gcc dot gnu dot org 2010-02-03 16:29 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.3/4.4/4.5 Regression] offset warning should be given in the front-end
--- Comment #35 from jason at gcc dot gnu dot org 2010-02-03 16:28 --- Subject: Bug 35652 Author: jason Date: Wed Feb 3 16:28:07 2010 New Revision: 156469 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156469 Log: PR c++/35652 * builtins.c (c_strlen): Use EXPR_LOCATION in diagnostics. Added: trunk/gcc/testsuite/g++.dg/warn/string1.C Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug fortran/42309] Problem with a pointer array passed to a subroutine
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-03 16:21 --- Paul's patch: http://gcc.gnu.org/ml/fortran/2010-02/msg00019.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309
[Bug c/42908] gcc -O2 -Wall doesn't warn about strict aliasing
--- Comment #5 from shana at jitted dot com 2010-02-03 16:13 --- IMHO, it's not good for strict aliasing warnings on level 2 to be optional and not included in -Wall by default. As it stands right now, gcc does not warn you even if it knows your code is 1) breaking the rules, and 2) the assignments that break the rules are going to be touched by optimizations. Optimizing away an assignment because that assignment breaks a rule is always a potential danger. Now I know that the reasoning to not show those warnings by default is that it can give you false positives, but a false positive in this case is when you *are* breaking the rules, but an optimization *might* or *might not* break your code. IMHO, just because your code might not break doesn't mean the warning is not needed. A developer really needs to know he's breaking the rules here, regardless of whether things blow up or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42908
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #18 from davek at gcc dot gnu dot org 2010-02-03 16:09 --- Created an attachment (id=19797) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19797&action=view) Bugfix of -respin-1 Opps! Forgot to update the lto language hook definitions. All fixed now. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #19795|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug fortran/42945] Gcov -a fails on Fortan generated object file (infinite loop?)
--- Comment #3 from graeme dot parkin at btinternet dot com 2010-02-03 15:47 --- (In reply to comment #2) > -a is very expensive and prone to run into some endless cfg reduction, try > to avoid it. > I am actually using lcov (1.9) which uses it automatically (only by looking into lcov discovered it used -a if available). I assume lcov uses it for some analysis purpose. Not sure you can stop it and not sure what it does if I do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
[Bug fortran/42945] Gcov -a fails on Fortan generated object file (infinite loop?)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-03 15:41 --- -a is very expensive and prone to run into some endless cfg reduction, try to avoid it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-02-03 15:40 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
[Bug bootstrap/42946] New: bootstrap with --enable-checking=df (or =all) fails
r156431 cc1: warnings being treated as errors /mnt/svn/gcc-trunk/gcc/df-core.c: In function 'df_finish_pass': /mnt/svn/gcc-trunk/gcc/df-core.c:649:3: error: enum conversion in assignment is invalid in C++ The offending code is: #ifdef ENABLE_DF_CHECKING saved_flags = df->changeable_flags; #endif where operands are declared as: enum df_changeable_flags saved_flags; int changeable_flags : 8; -- Summary: bootstrap with --enable-checking=df (or =all) fails Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946
[Bug fortran/42945] Gcov -a fails on Fortan generated object file (infinite loop?)
--- Comment #1 from graeme dot parkin at btinternet dot com 2010-02-03 15:06 --- Created an attachment (id=19796) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19796&action=view) Contains all Fortran files which give this gcov -a error Note can use compile.sh to run compilation etc. Expects lcov in place but can remove and replace with gcov -a. Only run under cygwin 1.7.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
[Bug debug/42896] [4.5 Regression] Random debug generation differences, bootstrap fails
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-02-03 15:00 --- Subject: Bug 42896 Author: rguenth Date: Wed Feb 3 15:00:33 2010 New Revision: 156468 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156468 Log: 2010-02-03 Alexandre Oliva PR debug/42896 * cselib.h (struct cselib_val_struct): Add uid. Rename value to hash. (cselib_reset_table): Renamed from... (cselib_reset_table_with_next_value): ... this. (cselib_get_next_uid): Renamed from... (cselib_get_next_unknown_value): ... this. * cselib.c (next_uid): Renamed from... (next_unknown_value): ... this. (cselib_clear_table): Adjust. (cselib_reset_table): Adjust. Renamed from... (cselib_reset_table_with_next_value): ... this. (cselib_get_next_uid): Adjust. Renamed from... (cselib_get_next_unknown_value): ... this. (get_value_hash): Use hash. (cselib_hash_rtx): Likewise. (new_cselib_val): Adjust. Set and dump uid. (cselib_lookup_mem): Pass next_uid as hash. (cselib_subst_to_values): Likewise. (cselib_log_lookup): Dump uid. (cselib_lookup): Pass next_uid as hash. Adjust. (cselib_process_insn): Adjust. (cselib_init): Initialize next_uid. (cselib_finish): Adjust. (dump_cselib_table): Likewise. * dse.c (canon_address): Dump value uid. * print-rtl.c (print_rtx): Print value uid. * var-tracking.c (VARIABLE_HASH_VAL): Dropped. (dvuid): New type. (dv_uid): New function, sort of renamed from... (dv_htab_hash): ... this, reimplemented in terms of it and... (dv_uid2hash): ... this. New. (variable_htab_eq): Drop excess assertions. (tie_break_pointers): Removed. (canon_value_cmp): Compare uids. (variable_post_merge_New_vals): Print uids. (vt_add_function_parameters): Adjust. (vt_initialize): Reset table. Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c trunk/gcc/cselib.h trunk/gcc/dse.c trunk/gcc/print-rtl.c trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
[Bug fortran/42945] New: Gcov -a fails on Fortan generated object file (infinite loop?)
On trying to do code coverage on set of Fortran files. After using gfortran-4 -fprofile-arcs -ftest-coverage, running test when you try to run gcov -a on one of the Fortran files never ends (the rest are OK). The particular Fortran file contains complex allocate commands. Can simplify and then it works. The Fortran file is configure_arrays.f90 the modified one is configure_arrays.modified. -- Summary: Gcov -a fails on Fortan generated object file (infinite loop?) Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: graeme dot parkin at btinternet dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #3 from mikpe at it dot uu dot se 2010-02-03 14:51 --- gcc-4.4.3 with binutils-2.20 fails StackTrace2 and Throw_3, reverting to binutils-2.19.1 eliminated those two failures. Bootstrapping with binutils-2.19.1 but running the test suite with binutils-2.20 did not trigger the failures. Rebuilding just libjava with binutils-2.20 also did not trigger the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #17 from davek at gcc dot gnu dot org 2010-02-03 14:48 --- TO-DO: (additions invited, this is not by any means a complete list!) - Add autoconfigury to ensure binutils supports .section directive alignment syntax, and disable LTO if not. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2010-01-18 16:18:01 |2010-02-03 14:48:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #16 from davek at gcc dot gnu dot org 2010-02-03 14:46 --- Created an attachment (id=19795) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19795&action=view) Latest and updatest. Updated: - enable for mingw targets - open files in binary mode in is_elf_or_coff - bunch of commenting added. - renamed the public lto_elf_* interface functions to lto_obj_* Untested yet: about to take this for a bootstrap and test cycle. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #19636|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #30 from chrbr at gcc dot gnu dot org 2010-02-03 13:12 --- Created an attachment (id=19794) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794&action=view) patch to fix GOT access load with constant pool Patch under validation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug tree-optimization/42944] [4.5 Regression] errno misoptimization due to __attribute__ ((__const__)) on __errno_location()
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-03 13:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42944
[Bug tree-optimization/42944] [4.5 Regression] errno misoptimization due to __attribute__ ((__const__)) on __errno_location()
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-03 13:03 --- Subject: Bug 42944 Author: rguenth Date: Wed Feb 3 13:03:39 2010 New Revision: 156467 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156467 Log: 2010-02-03 Richard Guenther PR tree-optimization/42944 * tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Handle calloc. (call_may_clobber_ref_p_1): Likewise. Properly handle malloc and calloc clobbering errno. * gcc.dg/errno-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/errno-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42944
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #15 from davek at gcc dot gnu dot org 2010-02-03 12:02 --- (In reply to comment #14) > There is a portability issue in is_elf_or_coff: fopen should be called with > "rb" instead of "r". Otherwise, fread fails when a COFF file has 26 sections, > because it is interpreted as a text, and 26 means "end of file". ROFL, yes of course, good catch. I should have remembered, there was just a thread on the -patches list about adding "b" to the ELF LTO reader for the sake of mingw-based cross-compilers! > Not tried. GCC and Binutils can be built with -flto under MSYS, and they seem > to work. Thanks for the report :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/30555] GCC should know about errno
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-03 11:18 --- Being able to annotate functions that do _not_ set errno might be useful as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30555
[Bug tree-optimization/42927] [4.5 Regression] type mismatch in shift expression produces ice with -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-03 11:13 --- Subject: Bug 42927 Author: rguenth Date: Wed Feb 3 11:13:17 2010 New Revision: 156464 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156464 Log: 2010-02-03 Richard Guenther PR middle-end/42927 * tree-cfg.c (verify_gimple_assign_binary): Fix shift verification. * gcc.c-torture/compile/pr42927.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42927
[Bug tree-optimization/42927] [4.5 Regression] type mismatch in shift expression produces ice with -O3
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-03 11:13 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42927
[Bug middle-end/30555] GCC should know about errno
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-03 11:00 --- Mine. We can add annotations for __errno_location () to indicate it returns a pointer to errno. We can also add annotations for a static errno declaration to denote it is errno. pointer-analysis can then properly handle things. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-03 11:00:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30555
[Bug tree-optimization/42944] [4.5 Regression] errno misoptimization due to __attribute__ ((__const__)) on __errno_location()
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-03 10:58 --- The issue is simply that GCC thinks malloc does not set errno. Removing const from __errno_location is just papering over this issue. But that malloc sets errno is really really unfortunate. Because we have no other way than clobbering global memory. Note that C99 does not specify malloc affecting errno. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-03 10:58:09 date|| Summary|errno misoptimization due to|[4.5 Regression] errno |__attribute__ ((__const__)) |misoptimization due to |on __errno_location() |__attribute__ ((__const__)) ||on __errno_location() Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42944
[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-03 10:40 --- Vlad? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #14 from d dot g dot gorbachev at gmail dot com 2010-02-03 10:15 --- There is a portability issue in is_elf_or_coff: fopen should be called with "rb" instead of "r". Otherwise, fread fails when a COFF file has 26 sections, because it is interpreted as a text, and 26 means "end of file". (In reply to comment #13) > Are you able to run the testsuite in the configuration you're building? (i.e. > msys or cross-compile?) If so, would you paste the output from running "make > check-gcc-c RUNTESTFLAGS=lto.exp" in the top level of your build dir please? Not tried. GCC and Binutils can be built with -flto under MSYS, and they seem to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #29 from kkojima at gcc dot gnu dot org 2010-02-03 10:06 --- I think these blockages are not overkill. GOTaddr2picreg is used only at prologue and non-pic tls initial exec accesses. The former is at most once for each function and never in the minor loop. The latter case wouldn't occur so frequently and the initial exec access is loaded sequence of instructions in the first place. > We only want to avoid the CP to be inserted between those 2 instructions, > it's not necessary to have more blockages. I'm working on something that > tracks the GOT loading access during the find_barrier walk and then revert > back at the end to the latest safe place. OK on the example but the full > linux distrib rebuild and validation is still ongoing. Of course, it's OK if it passes all the usual tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #28 from chrbr at gcc dot gnu dot org 2010-02-03 08:30 --- Hello Kaj, thanks for your proposal thanks for the proposal. but I'm wondering if preventing the scheduling of the mov.l and mova instructions are not too much overkill ? (sh_reorg comes after the scheduler, but even if it didn't that should be ok to mov up instructions. (the R0 liverange between the add and load is another more general problem) Do I miss something ? We only want to avoid the CP to be inserted between those 2 instructions, it's not necessary to have more blockages. I'm working on something that tracks the GOT loading access during the find_barrier walk and then revert back at the end to the latest safe place. OK on the example but the full linux distrib rebuild and validation is still ongoing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug fortran/42936] Result of passing NULL() as actual arg doesn't inherit characteristics from the corresponding dummy arg
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-03 08:26 --- FIXED on the trunk (for 4.5.0). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42936
[Bug fortran/42936] Result of passing NULL() as actual arg doesn't inherit characteristics from the corresponding dummy arg
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-03 08:26 --- Subject: Bug 42936 Author: burnus Date: Wed Feb 3 08:26:08 2010 New Revision: 156461 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156461 Log: 2010-02-03 Tobias Burnus PR fortran/42936 * interface.c (compare_parameter): Disable rank-checking for NULL(). 2010-02-03 Tobias Burnus PR fortran/42936 * gfortran.dg/null_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/null_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42936
[Bug other/41523] gcc generates few graph files with syntax errors
--- Comment #2 from joefoxreal at gmail dot com 2010-02-03 08:19 --- The problem is reproduced on trunk, gcc version 4.5.0 20100203 (experimental). -- joefoxreal at gmail dot com changed: What|Removed |Added CC||joefoxreal at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41523
