[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #5 from bmerry at gmail dot com 2009-07-28 07:28 --- Thanks, I wasn't aware of that. It's slightly annoying that the behaviour is different from glibc (I use -std=c89 so that the compiler keeps me honest, since I'm working on code that has to compile on compilers that still haven't gotten around to C99), but I can live with using __va_copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #42 from jv244 at cam dot ac dot uk 2009-07-28 07:37 --- another issue I found is this: gfortran -fwhole-file test.f90 /tmp/cciOiaMB.o: In function `__m_MOD_b': test.f90:(.text+0xa): undefined reference to `c_' collect2: ld returned 1 exit status cat test.f90 SUBROUTINE c() CALL a() END SUBROUTINE c SUBROUTINE a() END SUBROUTINE a MODULE M CONTAINS SUBROUTINE b() CALL c() END SUBROUTINE END MODULE USE M CALL b() END things link fine if I swap the order of definition of the subroutines 'a' and 'c' it is similar to PR40873, but happens with just -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #2 from aph at gcc dot gnu dot org 2009-07-28 08:02 --- This is actually a regression in debuginfo: the line number info is being corrupted, somewhere after the front end. I don't know if this was caused by the gimplify unit-at-a-time patch. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libgcj |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-28 08:02:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #41 from irar at il dot ibm dot com 2009-07-28 08:12 --- That requires pattern recognition. MIN/MAX_EXPR are recognized by the first phiopt pass, so MIN/MAXLOC should be either also recognized there or in the vectorizer. (The phiopt pass transforms if clause to MIN/MAX_EXPR. The vectorizer gets COND_EXPR after if-conversion pass). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-28 08:29 ---
(In reply to comment #0)
Consider the following code:
int (*indirect_func)();
int indirect_call()
{
return indirect_func();
}
gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
indirect_call:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr3, #:lower16:indirect_func
stmfd sp!, {r4, lr}
movtr3, #:upper16:indirect_func
mov lr, pc
ldr pc, [r3, #0]
ldmfd sp!, {r4, pc}
The problem is that the instruction ldr pc, [r3, #0] is not considered a
function call by the Cortex-A8's branch predictor, as noted in DDI0344J
section
5.2.1, Return stack predictions. Thus, the return from the called function is
mispredicted resulting in a penalty of 13 cycles compared to a direct call
Rather than doing
mov lr, pc
ldr pc, [r3]
it should instead use the blx instruction as so:
ldr lr, [r3]
blx lr
which is considered a function call by the branch predictor, and has an
overhead of only one cycle compared to a direct call.
The point made is correct but there is something you've missed in your patch !
loading lr with the address of the function you want to call, destroys the
return address ,- so your code is never going to return !
Instead you want -
ldr r3,[r3]
blx r3
Or better still bx r3 but that is PR19599 :)
gcc -v:
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: ../gcc-4.4.0/configure --target=arm-none-linux-gnueabi
--prefix=/usr/local/arm --enable-threads
--with-sysroot=/usr/local/arm/arm-none-linux-gnueabi/libc
Thread model: posix
gcc version 4.4.0 (GCC)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-28 08:29:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug fortran/40881] warn for obsolescent features
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-28 08:33 --- In a similar vain: One could introduct an option to disable warning for the deleted features (such as using real-valued loops) - currently, those warnings alre always printed, hiding other warnings in all the output. By the way, in the standard, obsolescent parts appear in smaller print. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #3 from lessen42+gcc at gmail dot com 2009-07-28 08:45 --- (In reply to comment #2) The point made is correct but there is something you've missed in your patch ! loading lr with the address of the function you want to call, destroys the return address ,- so your code is never going to return ! Instead you want - ldr r3,[r3] blx r3 Or better still bx r3 but that is PR19599 :) blx sets the link register to the correct return address as a part of the instruction, and the return address of the calling function has to already have been saved before this point or the mov lr, pc would destroy it already. Though perhaps the code should just always use ip with armv5+ like on the other side of the if() since that's callee saved and the tail-optimized bx lr would be suboptimal, since that's considered a function return. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-07-28 09:04 --- Still missing in intrinsics (at least as far as grep -L bounds `grep -l gfc_array *.c` tells me): associated.c date_and_time.c dtime.c etime.c iso_c_binding.c move_alloc.c random.c stat.c unpack_generic.c Missing in m4: unpack.m4 I'll try to do those during the next two weeks or so, when I'll have no Internet connection *gasp* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #14 from burnus at gcc dot gnu dot org 2009-07-28 09:57 --- (In reply to comment #13) Still missing in intrinsics (at least as far as For those which have one-dimensional arrays, one should consider adding the checks in trans*.c as this is faster for the non -fcheck=bounds case. At least functions such as random and *time* sound to be such. (And maybe the standard allows them to be shorter.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-28 11:09 --- The tree optimizers canonicalize the loop to bb 3: # i_5 = PHI i_3(4), 0(2) # ivtmp.23_1 = PHI ivtmp.23_4(4), 10(2) f2 (); i_3 = i_5 + 1; ivtmp.23_4 = ivtmp.23_1 - 1; if (ivtmp.23_4 != 0) goto bb 4; else goto bb 5; bb 4: goto bb 3; But then IVOPTs chooses i as the induction variable again. Maybe a DCE pass before IVOPTs magically would solve the regression - or simply do not consider candidates without uses? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.0.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2009-07-28 11:09:27 date|| Summary|No loop counter reversal for|[4.3/4.4/4.5 Regression] No |simple loops anymore|loop counter reversal for ||simple loops anymore Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-28 11:22 --- After early SRA we get f$x_8 = g; D.2142_6 = f$x_8; D.2141_7 = D.2142_6 (3); which now misses a constant propagation of g into the call which is why inlining doesn't catch this opportunity. Put one in and the abstraction goes away. Puting FRE into early optimizations also would get this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug libgomp/40494] omp for loop with guided schedule fails to terminate in certain cases
--- Comment #2 from per at bitempire dot com 2009-07-28 11:23 --- Sorry, you're right - it works fine with gcc 4.3 and later. I must have accidentally linked to libgomp 4.2 which is a part of llvm-gcc. I apologize for the inconvenience. -- per at bitempire dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40494
[Bug fortran/40882] [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type
--- Comment #2 from janus at gcc dot gnu dot org 2009-07-28 11:40 --- Subject: Bug 40882 Author: janus Date: Tue Jul 28 11:40:42 2009 New Revision: 150154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150154 Log: 2009-07-28 Janus Weil ja...@gcc.gnu.org PR fortran/40882 * trans-types.c (gfc_get_ppc_type): For derived types, directly use the backend_decl, instead of calling gfc_typenode_for_spec, to avoid infinte loop. (gfc_get_derived_type): Correctly handle PPCs returning derived types, avoiding infinite recursion. 2009-07-28 Janus Weil ja...@gcc.gnu.org PR fortran/40882 * gfortran.dg/proc_ptr_comp_13.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40882
[Bug java/40888] New: gcj -C has problems with clone()
When trying to use gcj -C instead of a symlink to ecj as gcj's javac (with options appropriately changed with a script), I ran across an interesting issue building OpenJDK: gcj -C -g -d lib/hotspot-tools -fsource=1.5 -I'hotspot-tools:/home/andrew/projects/openjdk/icedtea/netx:/mnt/builder/icedtea/generated:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes' -bootclasspath \'\' -w @hotspot-tools-source-files.txt (-w added so the errors aren't lost in 12k+ warnings) hotspot-tools/com/sun/codemodel/internal/JClass.java:269: error: The constructor JNarrowedClass(JClass, ListObject) is \ undefined return new JNarrowedClass(this,Arrays.asList(clazz.clone())); ^ hotspot-tools/com/sun/tools/javac/code/Scope.java:138: error: The constructor Scope(Scope, Symbol, Object) is undefined return new Scope(this, this.owner, this.table.clone()); ^^^ hotspot-tools/com/sun/tools/javac/code/Scope.java:490: error: The constructor Scope.ErrorScope(Scope.ErrorScope, Symbol, \ Object) is undefined return new ErrorScope(this, owner, table.clone()); ^^ hotspot-tools/com/sun/tools/javac/jvm/Code.java:1608: error: Type mismatch: cannot convert from Object to Type[] state.stack = stack.clone(); There are 146 of these errors, all seem to be related to clone(). They don't occur when using gij to run ecj, either the system copy or the one used by gcj (from sourceware.org): /home/andrew/build/gcj/bin/gij -cp /home/andrew/projects/classpath/gcj/dependencies/ecj.jar org.eclipse.jdt.internal.compiler.batch.Main -g -d lib/hotspot-tools -source 1.5 -sourcepath 'hotspot-tools:/home/andrew/projects/openjdk/icedtea/netx:/mnt/builder/icedtea/generated:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes' -bootclasspath \'\' @hotspot-tools-source-files.txt ... some time later... 21808 problems (21808 warnings) Am I translating some of the arguments correctly? If I instead turn sourcepath into -fsourcepath, it fails immediately as it is unable to locate java.lang.Object. The same occurs if -bootclasspath \'\' is removed. -- Summary: gcj -C has problems with clone() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu_andrew at member dot fsf dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40888
[Bug translation/40872] String not extracted for translation
--- Comment #17 from joseph at codesourcery dot com 2009-07-28 11:55 --- Subject: Re: String not extracted for translation On Mon, 27 Jul 2009, manu at gcc dot gnu dot org wrote: --- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 --- (In reply to comment #2) I tried to look for more similar cases. But I couldn't find anything. Not that it is all that easy to search for. Neither error nor ? are particularly good search terms. :-) So I may very well have missed something. Try grep -e ' error ([^]' gcc/*.c -A 1 I am sure you can come up with smart regexp for warning, warning_at, error_at, inform and the other diagnostic functions. My approach for finding such issues has been to search for '' and look (manually) in the result for any English strings that are not full diagnostics as the *msgid operand of a diagnostic function. Care to contribute a patch for this and other cases? I also encourage people wanting such issues fixed to submit patches, and will review such patches (to any part of the compiler) if the more specific maintainers of those parts of the compiler do not review them first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-28 12:09 --- (In reply to comment #3) (In reply to comment #2) The point made is correct but there is something you've missed in your patch ! loading lr with the address of the function you want to call, destroys the return address ,- so your code is never going to return ! Instead you want - ldr r3,[r3] blx r3 Or better still bx r3 but that is PR19599 :) blx sets the link register to the correct return address as a part of the instruction, and the return address of the calling function has to already have been saved before this point or the mov lr, pc would destroy it already. Oops yes, you are right - I must have been asleep ! . I would rather split the load out as a separate insn and allow it to be scheduled separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug fortran/40882] [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-28 12:14 --- Fixed with r150154. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40882
[Bug fortran/40876] OpenMP private variable referenced in a statement function
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 12:20 --- I certainly can't reproduce any kind of segfault with this. And, it is unclear to me whether this restriction (why it is there at all, doesn't make much sense) is meant just for statement functions referenced within the omp region, or any. Say is: integer :: a, st_func st_func () = a !$omp parallel private (a) a = 1 !$omp end parallel end also supposed to be invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug debug/39706] namespaces represented incorrectly in debug_pubnames
--- Comment #3 from dodji at gcc dot gnu dot org 2009-07-28 12:39 --- Subject: Re: New: namespaces represented incorrectly in debug_pubnames Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01579.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-28 13:12 --- We have the following cgraph nodes related to daxpy: daxpy/17(-1) @0x75fc8700 called by: dgesl/3 (1.00 per call) dgesl/3 (1.00 per call) calls: dgefa/7(7) @0x75f7b100 174 time, 45 benefit 138 size, 36 benefit 20 bytes stack usage reachable body finalized inlinable called by: linpk/9 (1.00 per call) calls: daxpy/4 (1.00 per call) dscal/5 (1.00 per call) idamax/6 (1.00 per call) daxpy/4(4) @0x75f66400 125 time, 56 benefit 125 size, 47 benefit reachable body finalized inlinable called by: dgefa/7 (1.00 per call) calls: dgesl/3(3) @0x75f45f00 219 time, 52 benefit 165 size, 43 benefit 24 bytes stack usage reachable body finalized inlinable called by: linpk/9 (1.00 per call) calls: ddot/2 (1.00 per call) ddot/2 (1.00 per call) daxpy/17 (1.00 per call) daxpy/17 (1.00 per call) where daxpy/17 is the one without a body (not merged with daxpy/4), called by dgesl. The call in dgefa is inlined (as single remaining call to a then reclaimable function). Confirmed with pauls latest patch applied. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-07-28 13:12:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-28 13:28 --- Honza, unless there are any new problems, can you commit the patch? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug fortran/40848] [4.5 Regression] ICE with alternate returns
--- Comment #4 from janus at gcc dot gnu dot org 2009-07-28 13:31 --- Fixed with r150134. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848
[Bug bootstrap/40890] New: ICE in pre_edge_rev_lcm in stage 2
/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/xgcc -B/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/ -B/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/bin/ -L/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/i686-pc-mingw32/winsup/mingw -L/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/i686-pc-mingw32/winsup/w32api/lib -isystem /home/rainer/software/src/gcc-4.5.0/winsup/mingw/include -isystem /home/rainer/software/src/gcc-4.5.0/winsup/w32api/include -B/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/bin/ -B/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/lib/ -isystem /mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/include -isystem /mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/sys-include-c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../../../../../src/gcc-4.5.0/gcc -I../../../../../src/gcc-4.5.0/gcc/. -I../../../../../src/gcc-4.5.0/gcc/../include -I./../intl -I../../../../../src/gcc-4.5.0/gcc/../libcpp/include -I/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/include -I/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/include -I/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/include -I../../../../../src/gcc-4.5.0/gcc/../libdecnumber -I../../../../../src/gcc-4.5.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/include -I/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/include -DCLOOG_PPL_BACKEND ../../../../../src/gcc-4.5.0/gcc/lcm.c -o lcm.o ../../../../../src/gcc-4.5.0/gcc/lcm.c: In Funktion »pre_edge_rev_lcm«: ../../../../../src/gcc-4.5.0/gcc/lcm.c:712:1: interner Compiler-Fehler: Segmentation fault Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Fehler in der deutschen Übersetzung sind an translation-team...@lists.sourceforge.net zu melden. Gehen Sie gemäß den Hinweisen in http://gcc.gnu.org/bugs.html vor. make[3]: *** [lcm.o] Error 1 -- Summary: ICE in pre_edge_rev_lcm in stage 2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer at emrich-ebersheim dot de GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40890
[Bug fortran/40876] OpenMP private variable referenced in a statement function
--- Comment #2 from longb at cray dot com 2009-07-28 13:47 --- The text at [75:19-20] of the OpenMP 2.5 standard, May 2008, says: Variables that appear in namelist statements, in variable format expressions, and in Fortran expressions for statement function definitions, may not appear in a private clause. So the example in Comment #1 looks invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug testsuite/40891] New: [4.4 Regression] Revision 150143 failed gcc.dg/cdce[12].c
Revision 150143: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg01026.html caused: FAIL: gcc.dg/cdce1.c scan-tree-dump cdce cdce1.c:16: note: function call is shrink-wrapped into error conditions. FAIL: gcc.dg/cdce2.c scan-tree-dump cdce cdce2.c:16: note: function call is shrink-wrapped into error conditions. on Linux/ia32, Linux/ia64 and Linux/Intel64. -- Summary: [4.4 Regression] Revision 150143 failed gcc.dg/cdce[12].c Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40891
[Bug bootstrap/40337] PPLLIBS flags do not include -lm
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-28 14:04 --- You didn't say how you configured the build, but you might want to use something like: --with-host-libstdcxx='/usr/local/gcc-4.4/lib/libstdc++.a -lm' as documented at http://gcc.gnu.org/install/configure.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40337
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #5 from mans at mansr dot com 2009-07-28 14:24 --- Just to be clear, this bug report is about *all* calls through function pointers. PR19599 only mentions a failed tail-call optimisation. That the example in this bug would benefit from this optimisation is secondary. I agree about splitting the operations to allow better scheduling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug fortran/40876] OpenMP private variable referenced in a statement function
--- Comment #3 from jv244 at cam dot ac dot uk 2009-07-28 14:34 --- (In reply to comment #1) I certainly can't reproduce any kind of segfault with this. It could be that it segfaults for Bill because 'ftn' adds -static to the compiler options, but doesn't link libpthread with '-Wl,--whole-archive -lpthread -Wl,--no-whole-archive' (see PR39176). Certainly, this happened in the past on the XT5. It is something Bill could check on the Cray :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug fortran/40876] OpenMP private variable referenced in a statement function
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-28 14:43 --- (In reply to comment #1) I certainly can't reproduce any kind of segfault with this. Neither can I. Regarding both examples (comment 0 and comment 1), ifort 11.1 happily accepts both. I am not sure whether it is the correct interpretation according the standard, but http://publib.boulder.ibm.com/infocenter/lnxpcomp/v9v111/topic/com.ibm.xlf111.linux.doc/xlfopg/smpdirclauses.htm has: The following example demonstrates the proper use of a PRIVATE variable that is used to define a statement function. A commented line shows the invalid use. Since J appears in a statement function, the statement function cannot be referenced within the parallel construct for which J is PRIVATE. INTEGER :: ARR(10), J = 17 ISTFNC() = J !$OMP PARALLEL DO PRIVATE(J) DO I = 1, 10 J=I ARR(I) = J ! ARR(I) = ISTFNC() **ERROR** A reference to ISTFNC would ! make the PRIVATE(J) clause ! invalid. END DO PRINT *, ARR END However, I somehow read the standard differently such that already the PRIVATE(J) is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug libgcj/40616] libgcj version of java.io.PrintStream missing constructors
--- Comment #1 from gandalf at gcc dot gnu dot org 2009-07-28 15:08 --- Subject: Bug 40616 Author: gandalf Date: Tue Jul 28 15:08:12 2009 New Revision: 150161 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150161 Log: Fix for PR40616: missing java.io.PrintStream constructors. 2009-07-27 Andrew John Hughes ahug...@redhat.com PR libgcj/40616 * java/io/PrintStream.class: Regenerated. * java/io/PrintStream.h: Updated. * java/io/PrintStream.java: (PrintStream(File)): Ported from GNU Classpath version. (PrintStream(File, String)): Likewise. (PrintStream(String)): Likewise. (PrintStream(String, String)): Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/lib/java/io/PrintStream.class trunk/libjava/classpath/tools/classes/gnu/classpath/tools/gjdoc/ConstructorDocImpl.class trunk/libjava/java/io/PrintStream.h trunk/libjava/java/io/PrintStream.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40616
[Bug libgcj/40616] libgcj version of java.io.PrintStream missing constructors
--- Comment #2 from gnu_andrew at member dot fsf dot org 2009-07-28 15:09 --- Fixed with above commit. -- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40616
[Bug c++/40892] New: maybe_warn_cpp0x i18n problems
cp/error.c:maybe_warn_cpp0x takes a string that is an English language fragment and inserts it into a sentence for a diagnostic; the string in question is neither translated nor extracted for gcc.pot. Whole sentences should be used for diagnostics; either pass an enum to this function rather than an English fragment and have a switch statement with appropriate pedwarn calls, or pass the complete diagnostic text to this function and name the parameter appropriately so that the string is extracted for translation. -- Summary: maybe_warn_cpp0x i18n problems Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org OtherBugsDependingO 40883 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40892
[Bug testsuite/40891] [4.4 Regression] Revision 150143 failed gcc.dg/cdce[12].c
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:10 --- Subject: Bug 40891 Author: jakub Date: Tue Jul 28 16:09:58 2009 New Revision: 150163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150163 Log: PR testsuite/40891 * gcc.dg/cdce1.c: Adjust note line number. * gcc.dg/cdce2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cdce1.c trunk/gcc/testsuite/gcc.dg/cdce2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40891
[Bug testsuite/40891] [4.4 Regression] Revision 150143 failed gcc.dg/cdce[12].c
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:11 --- Subject: Bug 40891 Author: jakub Date: Tue Jul 28 16:11:21 2009 New Revision: 150164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150164 Log: PR testsuite/40891 * gcc.dg/cdce1.c: Adjust note line number. * gcc.dg/cdce2.c: Likewise. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/cdce1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/cdce2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40891
[Bug fortran/40878] !$omp collapse(m) with non-constant m should give error
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:16 --- Subject: Bug 40878 Author: jakub Date: Tue Jul 28 16:15:47 2009 New Revision: 150165 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150165 Log: PR fortran/40878 * openmp.c (gfc_match_omp_clauses): Use gfc_error_now instead of gfc_error to diagnose invalid COLLAPSE arguments. * gfortran.dg/gomp/pr40878-1.f90: New test. * gfortran.dg/gomp/pr40878-2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr40878-1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr40878-2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40878
[Bug fortran/40846] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:584
--- Comment #2 from dominiq at lps dot ens dot fr 2009-07-28 16:21 --- Could somone check if this pr has not been fixed (hidden) by some recent changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work on i686-apple-darwin9 at this revision) on i686-apple-darwin9 at revision 150154 with the latest -fwhole-file patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40846
[Bug testsuite/40891] [4.4 Regression] Revision 150143 failed gcc.dg/cdce[12].c
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:21 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40891
[Bug middle-end/40893] New: ARM and PPC truncate intermediate operations unnecessarily
Consider the following C code:
#include inttypes.h
void dct2x2dc_dconly( int16_t d[2][2] )
{
int d0 = d[0][0] + d[0][1];
int d1 = d[1][0] + d[1][1];
d[0][0] = d0 + d1;
d[0][1] = d0 - d1;
}
The following is generated with arm-none-linux-gnueabi-gcc-4.4.0 -O3
-mcpu=cortex-a8 -S
dct2x2dc_dconly:
ldrsh ip, [r0, #2]
ldrsh r3, [r0, #0]
ldrsh r1, [r0, #6]
ldrsh r2, [r0, #4]
add r3, ip, r3
add r2, r1, r2
uxthr3, r3
uxthr2, r2
rsb r1, r2, r3
add r3, r2, r3
strhr1, [r0, #2]@ movhi
strhr3, [r0, #0]@ movhi
bx lr
(with pre-armv6 targets the two uxth are replaced by asl #16, lsr #16 pairs.)
The following is generated with powerpc-unknown-linux-gnu-gcc-4.4.0 -O3
-mcpu=G4 -S
dct2x2dc_dconly:
lha 10,2(3)
lha 0,0(3)
lha 11,6(3)
lha 9,4(3)
add 0,10,0
rlwinm 0,0,0,0x
add 9,11,9
rlwinm 9,9,0,0x
subf 11,9,0
add 0,9,0
sth 11,2(3)
sth 0,0(3)
blr
The two uxth in the ARM version, and the two rlwinm in the PPC version are
completely unnecessary, as letting strh/sth truncate will give equivalent
results. x86 does not exhibit this behaviour, and removing either d0 + d1 or d0
- d1 will not cause d0 and d1 be truncated to to 16 bits on both ARM and PPC.
powerpc-unknown-linux-gnu-gcc-4.4.0 -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0/work/gcc-4.4.0/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.4.0
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.0
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.0/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.0/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-fixed-point --without-ppl --without-cloog
--disable-nls --with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp
--enable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.4.0 p1.1'
Thread model: posix
gcc version 4.4.0 (Gentoo 4.4.0 p1.1)
arm-none-linux-gnueabi-gcc-4.4.0 -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: ../gcc-4.4.0/configure --target=arm-none-linux-gnueabi
--prefix=/usr/local/arm --enable-threads
--with-sysroot=/usr/local/arm/arm-none-linux-gnueabi/libc
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: ARM and PPC truncate intermediate operations
unnecessarily
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lessen42+gcc at gmail dot com
GCC host triplet: i386-apple-darwin
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
[Bug fortran/40878] !$omp collapse(m) with non-constant m should give error
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:33 --- Subject: Bug 40878 Author: jakub Date: Tue Jul 28 16:33:08 2009 New Revision: 150167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150167 Log: PR fortran/40878 * openmp.c (gfc_match_omp_clauses): Use gfc_error_now instead of gfc_error to diagnose invalid COLLAPSE arguments. * gfortran.dg/gomp/pr40878-1.f90: New test. * gfortran.dg/gomp/pr40878-2.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr40878-1.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr40878-2.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/openmp.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40878
[Bug fortran/40878] !$omp collapse(m) with non-constant m should give error
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:34 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40878
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-07-28 16:38 --- Subject: Bug 40759 Author: hubicka Date: Tue Jul 28 16:37:50 2009 New Revision: 150168 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150168 Log: PR tree-optimization/40759 * tree-ssa-dce.c (mark_virtual_phi_result_for_renaming): Mark all uses for renaming. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dce.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug fortran/40822] [4.5 Regression] Internal compiler error when Fortran intrinsic LEN referenced before explicit declaration
--- Comment #7 from hjl at gcc dot gnu dot org 2009-07-28 16:51 --- Subject: Bug 40822 Author: hjl Date: Tue Jul 28 16:51:19 2009 New Revision: 150169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169 Log: 2009-07-28 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-07-27 Janus Weil ja...@gcc.gnu.org PR fortran/40848 * gfortran.dg/altreturn_7.f90: New. 2009-07-27 Simon Baldwin sim...@google.com PR testsuite/40829 * gcc.dg/vect/no-scevccp-noreassoc-outer-2.c: Extended array 'a' so that indexing no longer runs off array end. 2009-07-24 Janus Weil ja...@gcc.gnu.org PR fortran/40822 * gfortran.dg/char_length_16.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/altreturn_7.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/altreturn_7.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/char_length_16.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/char_length_16.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/no-scevccp-noreassoc-outer-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40822
[Bug fortran/40848] [4.5 Regression] ICE with alternate returns
--- Comment #5 from hjl at gcc dot gnu dot org 2009-07-28 16:51 --- Subject: Bug 40848 Author: hjl Date: Tue Jul 28 16:51:19 2009 New Revision: 150169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169 Log: 2009-07-28 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-07-27 Janus Weil ja...@gcc.gnu.org PR fortran/40848 * gfortran.dg/altreturn_7.f90: New. 2009-07-27 Simon Baldwin sim...@google.com PR testsuite/40829 * gcc.dg/vect/no-scevccp-noreassoc-outer-2.c: Extended array 'a' so that indexing no longer runs off array end. 2009-07-24 Janus Weil ja...@gcc.gnu.org PR fortran/40822 * gfortran.dg/char_length_16.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/altreturn_7.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/altreturn_7.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/char_length_16.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/char_length_16.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/no-scevccp-noreassoc-outer-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848
[Bug testsuite/40829] gcc.dg/vect/no-scevccp-noreassoc-outer-2.c can segv
--- Comment #2 from hjl at gcc dot gnu dot org 2009-07-28 16:51 --- Subject: Bug 40829 Author: hjl Date: Tue Jul 28 16:51:19 2009 New Revision: 150169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169 Log: 2009-07-28 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-07-27 Janus Weil ja...@gcc.gnu.org PR fortran/40848 * gfortran.dg/altreturn_7.f90: New. 2009-07-27 Simon Baldwin sim...@google.com PR testsuite/40829 * gcc.dg/vect/no-scevccp-noreassoc-outer-2.c: Extended array 'a' so that indexing no longer runs off array end. 2009-07-24 Janus Weil ja...@gcc.gnu.org PR fortran/40822 * gfortran.dg/char_length_16.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/altreturn_7.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/altreturn_7.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/char_length_16.f90 - copied unchanged from r150168, trunk/gcc/testsuite/gfortran.dg/char_length_16.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/no-scevccp-noreassoc-outer-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40829
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #7 from htl10 at users dot sourceforge dot net 2009-07-28 17:53 --- I probably have a similiar bug about length of commend line with 4.4.1 which I shall file now. -- htl10 at users dot sourceforge dot net changed: What|Removed |Added CC||htl10 at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #8 from htl10 at users dot sourceforge dot net 2009-07-28 18:06 --- I have a slightly different message on alphaev68-dec-osf5.1a with gcc 4.4.1, but possibly the same problem: (I can bootstrap 4.3.3, but no luck with 4.4.0/4.4.1): find ../../../../../gcc-4.4.1/libjava/classpath/tools/external/asm -name '*.java' -print asm.lst find ../../../../../gcc-4.4.1/libjava/classpath/tools/gnu/classpath/tools \ ../../../../../gcc-4.4.1/libjava/classpath/tools/com/sun/javadoc \ ../../../../../gcc-4.4.1/libjava/classpath/tools/com/sun/tools/doclets \ ../../../../../gcc-4.4.1/libjava/classpath/tools/com/sun/tools/javadoc \ ../../../../../gcc-4.4.1/libjava/classpath/tools/com/sun/tools/javac \ ../../../../../gcc-4.4.1/libjava/classpath/tools/com/sun/tools/javah \ ../../../../../gcc-4.4.1/libjava/classpath/tools/sun/rmi/rmic \ -path '*gnu/classpath/tools/gjdoc' -prune -o -path '*gnu/classpath/tools/doclets' -prune -o -path '*gnu/classpath/tools/taglets' -prune -o -path '*com/sun/javadoc' -prune -o -path '*com/sun/tools/doclets' -prune -o -path '*com/sun/tools/javadoc' -prune -o \ -name '*.java' -print classes.lst find: bad option -path make[4]: *** [tools.zip] Error 1 make[4]: Leaving directory `/home/htl10/tmp-build/g41-dir/alphaev68-dec-osf5.1a/libjava/classpath/tools' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/htl10/tmp-build/g41-dir/alphaev68-dec-osf5.1a/libjava/classpath' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/htl10/tmp-build/g41-dir/alphaev68-dec-osf5.1a/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/htl10/tmp-build/g41-dir' make: *** [all] Error 2 bash-2.05a# -- The 'find: bad option -path' message probably means the command was truncated, I believe. It looks pretty long to me :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug fortran/40846] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:584
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-28 18:09 --- Could somone check if this pr has not been fixed (hidden) by some recent changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work on i686-apple-darwin9 at this revision) on i686-apple-darwin9 at revision 150154 with the latest -fwhole-file patch. If you use the normal trunk without any of Paul's whole-file patches, there is no ICE. If you have the latest (approved) version of his patch, there is no ICE. Only if you have an older version of his patch, which contains the code quoted in comment 1, it will ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40846
[Bug testsuite/40704] ^M? in testsuite log leads to binary attachment
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-28 18:12 --- Shouldn't test_summary remove ^M? when sending out emails? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
[Bug bootstrap/40890] ICE in pre_edge_rev_lcm in stage 2
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-07-28 18:28 --- Doesn't reproduce, please close as invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40890
[Bug bootstrap/40894] New: [4.4 Regression] bootstrap4-lean failed crtfastmath.o comparision
make bootstrap4-lean failed with 4.4.0 and 4.4.1 with crtfastmath.o comparison. The last gcc version I can make bootstrap4-lean was 4.3.3 (and before that, 4.3.1) which was what I tried building 4.4.x with. Strangely make (which I understand do a 3 stage boostrap) doesn't have this problem, but fails further down with path length problems ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251#c8 ). objdump -Dxzs ./prev-gcc/crtfastmath.o prev-gcc-crtfastmath-dump objdump -Dxzs ./gcc/crtfastmath.o gcc-crtfastmath-dump objdump -Dxzs /usr/local/lib/gcc/alphaev68-dec-osf5.1a/4.3.3/crtfastmath.o \ gcc-4.3.3-crtfastmath-dump - # diff prev-gcc-crtfastmath-dump gcc-crtfastmath-dump 2,3c2,3 ./prev-gcc/crtfastmath.o: file format ecoff-littlealpha ./prev-gcc/crtfastmath.o --- ./gcc/crtfastmath.o: file format ecoff-littlealpha ./gcc/crtfastmath.o 73c73 0030 3100 02000204 1... --- 0030 0100 02000204 103c103 30: 31 00 00 00 call_pal0x31 --- 30: 01 00 00 00 call_pal0x1 I also 'diff gcc-crtfastmath-dump gcc-4.3.3-crtfastmath-dump' - while I don't understand alpha assembler at all, the diff against with gcc 4.3.3 is mostly versioning, and gcc 4.3.3. also have call_pal0x31. So it appears that bootstrap4-lean miscompile at the last stage? (i.e. prev-gcc/crtfastmath.o was correct, gcc/crtfastmath.o was wrong). Anybody can suggest how to take this forward? I am currently on 4.3.3, but am keen to heep the alpha port of gcc alive for as long as is feasible... -- Summary: [4.4 Regression] bootstrap4-lean failed crtfastmath.o comparision Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: htl10 at users dot sourceforge dot net GCC host triplet: alphaev68-dec-osf5.1a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #6 from dave at boost-consulting dot com 2009-07-28 18:42 --- The next step would be to verify that the penalty is eliminated when using boost::function / tr1::function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug middle-end/40830] gcc.dg/vect/vect-pre-interact.c doesn't work on Linux/ia32
--- Comment #4 from hjl dot tools at gmail dot com 2009-07-28 18:58 --- It still fails on Linux/ia64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40830
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38 --- One step at a time, Dave ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug testsuite/40704] ^M? in testsuite log leads to binary attachment
--- Comment #3 from ubizjak at gmail dot com 2009-07-28 20:01 --- What about using ^ and $ throughout the testsuite instead of inventing regular expressions involving \n and \r in all possible combinations (i.e. (\n|\r\n|\r) ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
[Bug c++/40895] New: ICE in tsubst, at cp/pt.c:9687 with variadic templates
With G++ 4.3.3 and 4.4.0 from Ubuntu Jaunty, I get:
ice.cpp: In instantiation of âs0â:
ice.cpp:19: instantiated from here
ice.cpp:14: internal compiler error: in tsubst, at cp/pt.c:9687
from this test program:
int foo(int x, ...);
templateint x
int bar()
{
return 0;
}
templateint u
struct s
{
templatetypename... _T
static inline void
f(typeof(foo(bar_T()...)) a)
{
}
};
s0 g;
--
Summary: ICE in tsubst, at cp/pt.c:9687 with variadic templates
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luca dot barbieri at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40895
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-28 20:14 --- When I move e-inline_failed = CIF_OK in cgraph_mark_inline_edge() until after call to cgraph_clone_inlined_nodes(), the endless recursion goes away. However, I now get an assert in cgraph_estimate_size_after_inlining because the calculated size overflows... thus I'm looking at where the sizes grow so grossly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #9 from htl10 at users dot sourceforge dot net 2009-07-28 20:30 --- Sorry for the noise - the 'find: bad option -path' error message of mine is genuine - gcc 4.4 (classpath) requires GNU findutils syntax which doesn't work with DEC/Tru64 find. Am filing a separate bug now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug c++/40895] [C++0x] ICE in tsubst, at cp/pt.c:9687 with variadic templates
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-28 20:36 --- Already fixed in 4.4.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.4.0 Known to work||4.4.1 4.5.0 Resolution||WORKSFORME Summary|ICE in tsubst, at |[C++0x] ICE in tsubst, at |cp/pt.c:9687 with variadic |cp/pt.c:9687 with variadic |templates |templates Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40895
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #10 from htl10 at users dot sourceforge dot net 2009-07-28 20:42 --- The 'find bad option' problem was already reported for solaris as bug 38715 . just FYI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 ---
Ha, please disregard the previous message, obviously I had to make a
fool out of myself before realizing that loops in the inlining plan
are the bug, not how we handle them.
The reason there are such loops is that ipa-cp has made a portion of
the graph effectively dead but strongly connected via single uses
which ipa-inline handles specially and wants to inline them whenever
it seems possible. But it sis not check for loops.
So, I belive the patch below fixes this issue and I am going to
bootstrap it overnight. Honza, can you please confirm this is indeed
a correct fix? Thanks.
2009-07-28 Martin Jambor mjam...@suse.cz
* ipa-inline.c (cgraph_decide_inlining): Watch out for dead single
use inlining loops.
* testsuite/gcc.c-torture/compile/pr40570.c: New test.
Index: icln/gcc/ipa-inline.c
===
--- icln.orig/gcc/ipa-inline.c
+++ icln/gcc/ipa-inline.c
@@ -1227,6 +1227,7 @@ cgraph_decide_inlining (void)
!node-needed
node-local.inlinable
node-callers-inline_failed
+ node-callers-caller-global.inlined_to != node
!gimple_call_cannot_inline_p (node-callers-call_stmt)
!DECL_EXTERNAL (node-decl)
!DECL_COMDAT (node-decl))
Index: icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
===
--- /dev/null
+++ icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
@@ -0,0 +1,19 @@
+static int foo(int i);
+
+static int bar(int i) { foo(i); }
+
+static int foo(int i)
+{
+ int j;
+ if (j)
+FOO(j);
+ return bar(i);
+}
+
+int baz()
+{
+ foo(0);
+ if (baz())
+return 1;
+ return 0;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40896] New: cprop-registers optimization produces invalid code as of r148601
I currently am keeping the Haiku operating system up to date with GCC 4.4 and trunk, with plans of eventually getting the code for our GCC port committed into GCC's repository. I was keeping up to date by doing builds periodically based on 4.4 snapshots, and assumed all would be well when 4.4.1 rolled around. However, I noticed on some Haiku revisions with later 4.4 builds, Haiku's Tracker could be easily crashed, as well as some icons were missing. Via binary searches, I narrowed down problematic revisions such as r31471 and r31829 in Haiku's repository. Looking at backtraces for these crashes provides nothing that makes any sense (and the nature of the changes didn't remotely set off any alarms), so I decided to do a debug build of the Tracker. This built fine and worked as expected. I then tried an -O1 build, and the Tracker was broken again. Via binary search through the -O1 optimizations, I found that -fcprop-registers was the problem. If I passed -fno-cprop-registers, the Tracker would build as expected. So, this led me to find out where things went awry. Keep in mind that I tested the Tracker code in GCC 2.95.3, GCC 4.3.3, GCC 4.4.0, and the current trunk, up to revision 149615. I seriously doubt the quality of the Haiku code is to blame in this case, but I have been known to be wrong from time to time. I did a binary search on the 4.4 branch, and noticed the change in gcc/tree-ssa-operands.c in revision 148601 was the root of the problem. I can build Haiku's Tracker just fine up through 148600. Not so with 148601. I know you appreciate test code, but I don't know how easy that will be to achieve. I admit I'm not familiar with the Tracker code or know a good way to reduce it down to a test case. I can always try if need be though. I also know Haiku isn't a supported port as of now, but we have to start somewhere. I'm hoping this report can at least help out in some way in case this issue is creeping up on other targets. :) For reference this was a non-Graphite all static cross-compile from Linux, but the issue also crept up when I did a full-on Graphite build of GCC. I admit I still need to try a native build again from Haiku, but I suspect the same issue will arise. Like I said, only GCC 4.4 branch revision 148601 and up seem affected, and only when the cprop-registers optimization is used. Also, here are the dependencies versions used while building: GMP 4.3.1 MPFR 2.4.1 PPL 0.10.2 ClooG-PPL 0.15.4 (Like I said though, I didn't do many test builds with Graphite due to the volume of builds I had to do during my binary searches.) Lastly the only things we ever really disable in our GCC builds of Haiku are strict-aliasing and tree-vrp optimizations if those matter. When configuring GCC, we disable shared, nls, and multilib, and enable languages c, c++. Thanks a lot for any possible insight! -- Summary: cprop-registers optimization produces invalid code as of r148601 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joe dot prostko+gcc at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i586-pc-haiku http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40896
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 --- I can confirm that if we schedule pass_ccp right after pass_sra_early, g gets inlined. Moreover, if we schedule one more pass_forwprop right afterwards, even the testcase for PR 3713, comment #12 gets optimized as it should :-) So, like with PR 3713, we either have to schedule ccp or add some specific pattern matching to the inlining preparation phase. I guess that people will find running one more ccp and fwprop unacceptable and so some pattern matching will have to be done anyway for the other PR (and we already do some awkward stuff like that for indirect member pointer calls). Perhaps we can match both, this one would be very easy. (Or is scheduling the two extra passes an option?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug target/40191] fails to build a cross-compiler in-tree
--- Comment #3 from rmh at gcc dot gnu dot org 2009-07-28 22:11 --- ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
[Bug middle-end/40893] ARM and PPC truncate intermediate operations unnecessarily
--- Comment #1 from lessen42+gcc at gmail dot com 2009-07-28 22:27 --- More specifically, on x86_64 the following is generated with gcc-4.4 -O3 -march=core2 -S _dct2x2dc_dconly: movswl 2(%rdi),%edx pushq %rbp addw(%rdi), %dx movswl 6(%rdi),%eax movq%rsp, %rbp addw4(%rdi), %ax leal(%rax,%rdx), %ecx subw%ax, %dx movw%cx, (%rdi) movw%dx, 2(%rdi) leave ret So it seems that the optimizer realizes that you don't need registers larger than 16-bits, which allows memory operands on x86, which is optimal for this case. However, other architectures follow this too literally, wasting instructions to truncate intermediate results to 16 bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893
[Bug c++/40897] New: g++ error on valid syntax (call of templated object method via this pointer)
The following code fails to compile: std::tr1::shared_ptrconst sbuild::chroot_facet_session psess; psess = this-chroot-get_facetsbuild::chroot_facet_session(); However, this code compiles without error: std::tr1::shared_ptrconst sbuild::chroot_facet_session psess; psess = chroot-get_facetsbuild::chroot_facet_session(); The only difference is the deletion of the this pointer. chroot is a member of the class this method is a part of, and get_facet is a templated member function of the chroot class. I will attach preprocessed source for g++-4.3.3, 4.4.1 and 4.5.0 (recent SVN). All three versions fail to compile this valid code. The output of g++ -v -save-temps for all three compiler versions follows: g++ -v -save-temps -DHAVE_CONFIG_H -I. -I.. -I../sbuild-I.. -I/usr/include/uuid-DTESTDATADIR='./testdata' -I../bin -pthread -pedantic -Wall -Wcast-align -Wwrite-strings -Wswitch-default -Wcast-qual -Wunused-variable -Wredundant-decls -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual -fstrict-aliasing -g -O2 -MT sbuild-chroot.o -MD -MP -MF .deps/sbuild-chroot.Tpo -c -o sbuild-chroot.i sbuild-chroot.cc Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.3/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 --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.3 (Debian 4.3.3-14) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../sbuild' '-I..' '-I/usr/include/uuid' '-DTESTDATADIR=./testdata' '-I../bin' '-pthread' '-pedantic' '-Wall' '-Wcast-align' '-Wwrite-strings' '-Wswitch-default' '-Wcast-qual' '-Wunused-variable' '-Wredundant-decls' '-Wctor-dtor-privacy' '-Wnon-virtual-dtor' '-Wreorder' '-Wold-style-cast' '-Woverloaded-virtual' '-fstrict-aliasing' '-g' '-O2' '-MT' 'sbuild-chroot.o' '-MD' '-MP' '-MF' '.deps/sbuild-chroot.Tpo' '-c' '-o' 'sbuild-chroot.i' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.3/cc1plus -E -quiet -v -I. -I.. -I../sbuild -I.. -I/usr/include/uuid -I../bin -MD sbuild-chroot.d -MF .deps/sbuild-chroot.Tpo -MP -MT sbuild-chroot.o -D_GNU_SOURCE -D_REENTRANT -DHAVE_CONFIG_H -DTESTDATADIR=./testdata sbuild-chroot.cc -mtune=generic -pedantic -Wall -Wcast-align -Wwrite-strings -Wswitch-default -Wcast-qual -Wunused-variable -Wredundant-decls -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual -fstrict-aliasing -fworking-directory -O2 -fpch-preprocess -o sbuild-chroot.ii ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../x86_64-linux-gnu/include ignoring nonexistent directory /usr/include/x86_64-linux-gnu ignoring duplicate directory .. #include ... search starts here: #include ... search starts here: . .. ../sbuild /usr/include/uuid ../bin /usr/include/c++/4.3 /usr/include/c++/4.3/x86_64-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include /usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../sbuild' '-I..' '-I/usr/include/uuid' '-DTESTDATADIR=./testdata' '-I../bin' '-pthread' '-pedantic' '-Wall' '-Wcast-align' '-Wwrite-strings' '-Wswitch-default' '-Wcast-qual' '-Wunused-variable' '-Wredundant-decls' '-Wctor-dtor-privacy' '-Wnon-virtual-dtor' '-Wreorder' '-Wold-style-cast' '-Woverloaded-virtual' '-fstrict-aliasing' '-g' '-O2' '-MT' 'sbuild-chroot.o' '-MD' '-MP' '-MF' '.deps/sbuild-chroot.Tpo' '-c' '-o' 'sbuild-chroot.i' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.3.3/cc1plus -fpreprocessed sbuild-chroot.ii -quiet -dumpbase sbuild-chroot.cc -mtune=generic -auxbase-strip sbuild-chroot.i -g -O2 -pedantic -Wall -Wcast-align -Wwrite-strings -Wswitch-default -Wcast-qual -Wunused-variable -Wredundant-decls -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual -version -fstrict-aliasing -o sbuild-chroot.s GNU C++ (Debian 4.3.3-14) version 4.3.3 (x86_64-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=100 --param
[Bug middle-end/21953] [4.3/4.4/4.5 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
--- Comment #12 from htl10 at users dot sourceforge dot net 2009-07-28 22:49 --- Still broken with 4.3.1, with alphaev68-dec-osf5.1a - http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02507.html Am about to submit the testsuite result for 4.3.3 and 4.4.1, and I think the result is similiar. -- htl10 at users dot sourceforge dot net changed: What|Removed |Added CC||htl10 at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-28 22:51 --- Does: psess = this-chroot-template get_facetsbuild::chroot_facet_session(); make it work? Is the class where you use this a template? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #2 from rleigh at debian dot org 2009-07-28 23:00 --- Yes, the class for the this pointer is a template: template class T class test_chroot_base : public TestFixture Adding template as you suggest psess = this-chroot-template get_facetsbuild::chroot_facet_session(); does allow the source to compile. I'm trying to attach the preprocessed source, but bugzilla is giving me internal errors during the upload. I can mail them to you directly if needed. Regards, Roger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #3 from rleigh at debian dot org 2009-07-28 23:02 --- Created an attachment (id=18262) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18262action=view) Preprocessed source for g++-4.3.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #4 from rleigh at debian dot org 2009-07-28 23:02 --- Created an attachment (id=18263) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18263action=view) Preprocessed source for g++-4.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-28 23:03 --- If it is getting you an internal error, then it is usually it is because the attachments are too big. As for the other issue, there is a C++ defect report about this case, which consider this as dependent but a member as non dependent and all confusing happens with namelookup and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #6 from rleigh at debian dot org 2009-07-28 23:03 --- Created an attachment (id=18264) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18264action=view) Preprocessed source for g++-4.5.0 (svn 149777) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)
--- Comment #7 from rleigh at debian dot org 2009-07-28 23:15 --- Ah, so it's a defect in the actual C++ standard rather than GCC? I was somewhat confused because while this fails: psess = this-chroot-get_facetsbuild::chroot_facet_session(); splitting it into its component parts always succeeds: sbuild::chroot::ptr tmp(this-chroot); psess = tmp-template get_facetsbuild::chroot_facet_session(); and I thought that they would be identical in behaviour. But replacing this with a different pointer of the same always fails. test_chroot_baseT *self(this); psess = self-chroot-template get_facetsbuild::chroot_facet_session(); (just in case this was treated specially for some reason). Regards, Roger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-29 01:29 --- Introduced in revision 147980 (SRA). -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz GCC build triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) GCC host triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) GCC target triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) Summary|FAIL: |[4.5 Regression] FAIL: |g++.dg/torture/pr34099.C - |g++.dg/torture/pr34099.C - |O1 (internal compiler |O1 (internal compiler |error) at -O1 and above |error) at -O1 and above http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug target/40577] ICE on valid code: in extract_insn
--- Comment #4 from mckelvey at maskull dot com 2009-07-29 01:47 --- (In reply to comment #3) Created an attachment (id=18254) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18254action=view) [edit] patch to fix the failure This patch fixes the failure on x86_64 - alpha crosscompiler. Since gcc30 of compile farm fame apparently lost its bluesmoke, can someone bootstrap and regression test it on alpha? I bootstrapped and it runs my code with no errors. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40577
[Bug tree-optimization/40896] cprop-registers optimization produces invalid code as of r148601
--- Comment #1 from spop at gcc dot gnu dot org 2009-07-29 04:11 --- Hi, From what I read this has nothing to do with Graphite. Could you please reduce the bug using ideas from: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction I am using to compile everything with a working compiler, and then I am compiling file by file with the problematic compiler: compiling one file at a time until I manage to reproduce the miscompiled behavior. From there you still need to figure out which function is miscompiled, and then to show what is the difference with respect to the working compiler. The fact that you already know two close by revisions of GCC one that miscompiles and the other that does not should be of big help already to reduce your testcase. If you fail to reduce the bug, nobody is going to look at this bug report. Once you have a valid testcase that shows the miscompile, please reopen this bug report. With a testcase in hand, half the job to fix your problem is done. Thanks again for your work, Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40896
[Bug fortran/40853] I/O: Namelist read error
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-07-29 04:40 --- Created an attachment (id=18265) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18265action=view) A simple patch to resolve the problem This patch solves the original test case. It does require modification of test suite cases namelist_40.f90 and namelist_47.f90. With the patch, those two test cases have a slightly modified error output. Additional testing is always appreciated. I will prepare a submittal for approval tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853
