[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Alan Modra amodra at gmail dot com 2011-11-07 08:07:10 UTC --- fixed
[Bug target/47487] ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47487 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Alan Modra amodra at gmail dot com 2011-11-07 08:07:47 UTC --- fixed
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-07 08:11:34 UTC --- (In reply to comment #16) Created attachment 25730 [details] Possible patch which pushes the vtab to the toplevel At least that approach fails for the following file (of PSBLAS 3's configure), which yields an internal compiler error: in cgraph_analyze_functions, at cgraphunit.c:1193 which is at fprintf (cgraph_dump_file, \nReclaiming functions:); for (node = cgraph_nodes; node != first_analyzed; node = next) { ... gcc_assert (node-analyzed == node-local.finalized); program xtt type foo integer :: i end type foo type, extends(foo) :: new_foo integer :: j end type new_foo class(foo), allocatable :: fooab type(new_foo) :: nfv integer :: info allocate(fooab, source=nfv, stat=info) end program xtt
[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2011-11-07 08:24:54 UTC --- (In reply to comment #4) (In reply to comment #3) FWIW gcc-4.2.1 (Apple local) fails and clang passes the test (although clang's asm at version 2.9 is a bit long-winded c.f. GCC's ... but that's quite an old version). or not properly restoring the UNSPEC during reload (it's its duty, not IRAs). I'll check this too. Thanks Richi, this seems to be the problem - it appears that the reload legitimizer does not consider that the item might be 'undefined' (in the mach-o, local-to-the-file sense) - and, therefore, there was no mechanism to recreate the necessary indirection. so, this is a fix - which bootstraps and regtests: I'd very much like an opinion as to whether it's the _right_ fix ... this is an area with which I am not familiar and therefore could have missed some other guard that's needed. It's clearly a very infrequent (perhaps even non-existent) occurrence outside the particular asm test-case (which makes me wonder still if combine came to the right decision to remove the refs in the first place). Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 181027) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -6185,7 +6185,21 @@ rs6000_legitimize_reload_address (rtx x, enum mach #if TARGET_MACHO if (flag_pic) { - rtx offset = machopic_gen_offset (x); + rtx offset; + + /* Reload might present us with a case where there is a reference to +an undefined entity. */ + if (!machopic_symbol_defined_p (x) !MACHO_DYNAMIC_NO_PIC_P) + { + offset = gen_rtx_SYMBOL_REF (Pmode, + machopic_indirection_name (x, + false)); + SYMBOL_REF_DATA (offset) = SYMBOL_REF_DATA (x); + machopic_define_symbol (gen_const_mem (Pmode,offset)); + x = offset; + } + + offset = machopic_gen_offset (x); x = gen_rtx_LO_SUM (GET_MODE (x), gen_rtx_PLUS (Pmode, pic_offset_table_rtx, gen_rtx_HIGH (Pmode, offset)), offset);
[Bug rtl-optimization/47698] CMOV accessing volatile memory with read side effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698 --- Comment #6 from Kirill Yukhin kyukhin at gcc dot gnu.org 2011-11-07 08:42:00 UTC --- Author: kyukhin Date: Mon Nov 7 08:41:55 2011 New Revision: 181075 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181075 Log: gcc/ PR rtl-optimization/47698 * ifconv.c (noce_operand_ok): prevent CMOV generation for volatile mem. gcc/testsuite/ PR rtl-optimization/47698 * gcc.target/i386/47698.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/47698.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug target/50962] Additional opportunity for AGU stall avoidance optimization for Atom processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50962 --- Comment #4 from Kirill Yukhin kyukhin at gcc dot gnu.org 2011-11-07 08:47:18 UTC --- Author: kyukhin Date: Mon Nov 7 08:47:15 2011 New Revision: 181077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181077 Log: gcc/ PR target/50962 * config/i386/i386-protos.h (ix86_use_lea_for_mov): New. * config/i386/i386.c (ix86_use_lea_for_mov): Likewise. * config/i386/i386.md (movsi_internal): Emit lea if profitable. (movdi_internal_rex64): Likewise. Modified: trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Depends on||47344 Resolution||DUPLICATE --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 09:13:10 UTC --- 4.6 requires 2GB at -O2, so yes. But, linking from 47344 to here instead. *** This bug has been marked as a duplicate of bug 47344 ***
[Bug middle-end/47344] [4.4/4.5/4.6/4.7 Regression][meta-bug] GCC gets slower and uses more memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47344 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||34983 CC||mariobon...@ubuntu-it.org --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 09:13:10 UTC --- *** Bug 34983 has been marked as a duplicate of this bug. ***
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | Known to fail||4.6.0 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 09:14:08 UTC --- Didn't meant to mark it as dup.
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-11-07 09:23:30 UTC --- The situation now is even more confused. Most of the std algos have iterators as arguments. Visibility seems not to propagate there.. below is my extensive test compile as c++ -O0 -shared -fPIC -fvisibility=hidden -o bha.so testICF.cpp nm bha.so | c++filt and look at the mixture of t and T for instance ad7f t void std::__adjust_heap__gnu_cxx::__normal_iteratorC**, std::vectorC*, std::allocatorC* , long, C*(__gnu_cxx::__normal_iteratorC**, std::vectorC*, std::allocatorC* , long, long, C*) afea T void std::__iter_swaptrue::iter_swap__gnu_cxx::__normal_iteratorC**, std::vectorC*, std::allocatorC* , __gnu_cxx::__normal_iteratorC**, std::vectorC*, std::allocatorC* etc cat testICF.cpp #includevector #includealgorithm #includecmath struct A { A(float q=0): v(q){} float v; bool operator(A const a) const { return va.v;} }; struct B { B(float q=0): v(q){} bool operator(B const a) const { return va.v;} float v; }; struct C { C(double q=0): v(q){} bool operator(C const a) const { return va.v;} double v; }; float cosq(A const a) { return cos(a.v); } float cosq(B const a) { return cos(a.v); } templatetypename T int game(std::vectorT const a, std::vectorT b) { typedef typename std::vectorT::const_iterator Iter; for (Iter i=a.begin(); i!=a.end(); ++i) { if ( (*i).v0.) b.push_back((*i).v+1); } std::sort(b.begin(),b.end()); return b.size(); } templatetypename T int gamep(std::vectorT* const a, std::vectorT* b) { typedef typename std::vectorT*::const_iterator Iter; for (Iter i=a.begin(); i!=a.end(); ++i) { if ( (*i)-v0.) b.push_back((*i)); } std::sort(b.begin(),b.end()); return b.size(); } namespace data /* __attribute__((visibility(default))) */ { std::vectorA a; std::vectorB b; std::vectorC c; std::vectorA* ap; std::vectorB* bp; std::vectorC* cp; } #includeiostream int __attribute__((visibility(default))) go() { using namespace data; int ret=0; try { ret+=game(a,a); ret+=game(b,b); ret+=game(c,c); ret+=gamep(ap,ap); ret+=gamep(bp,bp); ret+=gamep(cp,cp); } catch (std::exception ce) { std::cout ce.what() std::endl; } return ret; }
[Bug tree-optimization/51000] [4.7 Regression] ICE: in vect_get_store_cost, at tree-vect-stmts.c:923 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51000 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.7.0
[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 09:28:17 UTC --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) FWIW gcc-4.2.1 (Apple local) fails and clang passes the test (although clang's asm at version 2.9 is a bit long-winded c.f. GCC's ... but that's quite an old version). or not properly restoring the UNSPEC during reload (it's its duty, not IRAs). I'll check this too. Thanks Richi, this seems to be the problem - it appears that the reload legitimizer does not consider that the item might be 'undefined' (in the mach-o, local-to-the-file sense) - and, therefore, there was no mechanism to recreate the necessary indirection. so, this is a fix - which bootstraps and regtests: I'd very much like an opinion as to whether it's the _right_ fix ... this is an area with which I am not familiar and therefore could have missed some other guard that's needed. It's clearly a very infrequent (perhaps even non-existent) occurrence outside the particular asm test-case (which makes me wonder still if combine came to the right decision to remove the refs in the first place). Combine also asks the target whether the result is valid, so yes. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 181027) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -6185,7 +6185,21 @@ rs6000_legitimize_reload_address (rtx x, enum mach #if TARGET_MACHO if (flag_pic) { - rtx offset = machopic_gen_offset (x); + rtx offset; + + /* Reload might present us with a case where there is a reference to +an undefined entity. */ + if (!machopic_symbol_defined_p (x) !MACHO_DYNAMIC_NO_PIC_P) + { + offset = gen_rtx_SYMBOL_REF (Pmode, + machopic_indirection_name (x, + false)); + SYMBOL_REF_DATA (offset) = SYMBOL_REF_DATA (x); + machopic_define_symbol (gen_const_mem (Pmode,offset)); + x = offset; + } + + offset = machopic_gen_offset (x); x = gen_rtx_LO_SUM (GET_MODE (x), gen_rtx_PLUS (Pmode, pic_offset_table_rtx, gen_rtx_HIGH (Pmode, offset)), offset); I suppose you should post this to gcc-patches@.
[Bug c++/51004] New: ICE in lower_stmt at gimple-low.c:428
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51004 Bug #: 51004 Summary: ICE in lower_stmt at gimple-low.c:428 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kenn...@gmail.com Test case: === #include boost/python/object_core.hpp struct CCC { int x; }; typedef boost::python::object S; int extract(S obj) { return 0; } void init_from_tuples_impl(S tpl) { new CCC{extract(tpl)}; } void tuples() { init_from_tuples_impl; } === It should compile with no error. Instead, the compiler fails with error message: $ g++ -std=c++0x -c 2.cpp `pkg-config --cflags python3` 2.cpp: In function ‘void init_from_tuples_impl(S)’: 2.cpp:23:1: internal compiler error: in lower_stmt, at gimple-low.c:428 Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions. (It should be possible to remove the dependency on Boost.Python, but I haven't have time to do so yet). gcc config: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.6.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --disable-multilib --disable-libssp --disable-libstdcxx-pch --enable-checking=release Thread model: posix gcc version 4.6.2 (GCC)
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 --- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-11-07 09:38:08 UTC --- Reduced test actually it is enough to add s::foo(v); in the main after s::foo(a); to get 0e34 t void s::fooA(A) 0e3a T void s::foos::vectorA (s::vectorA) 0e2a t s::vectorA::vector()
[Bug tree-optimization/51005] New: -ftree-tail-merge slows down compilation of 20001226-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51005 Bug #: 51005 Summary: -ftree-tail-merge slows down compilation of 20001226-1.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: vr...@gcc.gnu.org Reported by David Miller in http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02780.html: ... My check-gcc runs are completely dominated by the time it takes to test compile.exp=20001226-1.c [...] Unfortunately, at -O2 this testcase causes exponential cost problems which are beyond my skills to fix. Specifically, tail_merge_optimize() applies it's clusters and iterate_fix_dominators() hits the worst case O(n) complexity of et_splay for a CFG structured like this. :-/ %38 of the compilation time is spent in et_splay(). ...
[Bug bootstrap/51006] New: bootstrap fails on NetBSD 5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51006 Bug #: 51006 Summary: bootstrap fails on NetBSD 5.1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: r...@gcc.gnu.org Host: x86_64-unknown-netbsd5.1 Target: x86_64-unknown-netbsd5.1 Build: x86_64-unknown-netbsd5.1 enable-execute-stack.c:74:1: error: static declaration of 'getpagesize' follows non-static declaration In file included from enable-execute-stack.c:26:0: /usr/include/unistd.h:248:3: note: previous declaration of 'getpagesize' was here enable-execute-stack.c:33:13: warning: 'check_enabling' declared 'static' but never defined [-Wunused-function] gmake[2]: *** [enable-execute-stack.o] Error 1 gmake[2]: Leaving directory `/home/jwakely/build/x86_64-unknown-netbsd5.1/libgcc'
[Bug bootstrap/51006] bootstrap fails on NetBSD 5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51006 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 09:46:47 UTC --- Created attachment 25732 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25732 use system getpagesize on netbsd testing this now
[Bug tree-optimization/51005] -ftree-tail-merge slows down compilation of 20001226-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51005 --- Comment #1 from vries at gcc dot gnu.org 2011-11-07 09:53:15 UTC --- -ftree-tail-merge optimises about half of the basic blocks away: ... $ egrep -c '^bb.*:' 20001226-1.c.091t.crited 16385 $ egrep -c '^bb.*:' 20001226-1.c.092t.pre 8195 ... but it does so with a slowdown of factor 3.5: ... $ time gcc src/gcc/testsuite/gcc.c-torture/compile/20001226-1.c -S -O2 -fno-tree-tail-merge real0m34.691s user0m34.350s sys0m0.220s $ time gcc src/gcc/testsuite/gcc.c-torture/compile/20001226-1.c -S -O2 -ftree-tail-merge real2m7.072s user2m6.220s sys0m0.190s ...
[Bug bootstrap/51006] bootstrap fails on NetBSD 5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51006 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 09:54:01 UTC --- bootstrap completes successfully with that patch the manual page says getpagesize first appeared in 4.2BSD so I can't imagine it's absent on any NetBSD version
[Bug middle-end/50823] [4.7 Regression] ICE in inline_small_functions, at ipa-inline.c:1407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50823 Yukhin Kirill kirill.yukhin at intel dot com changed: What|Removed |Added CC||kirill.yukhin at intel dot ||com --- Comment #10 from Yukhin Kirill kirill.yukhin at intel dot com 2011-11-07 09:59:07 UTC --- Spec2000/176.gcc fails on peak with '-flto' option (actually this was mentioned in #50868). Here is the output: gcc -static -flto -O3 -funroll-loops -ffast-math -DSPEC_CPU2000_LP64 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o real.o dbxout.o sdbout.o dwarfout.o xcoffout.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o regclass.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o insn-attrtab.o m88k.o getpwd.o convert.o bc-emit.o bc-optab.o obstack.o -lm -o cc1 ... lto1: internal compiler error: in inline_small_functions, at ipa-inline.c:1413 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: gcc returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status specmake: *** [cc1] Error 1
[Bug tree-optimization/51005] -ftree-tail-merge slows down compilation of 20001226-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51005 --- Comment #2 from vries at gcc dot gnu.org 2011-11-07 10:05:03 UTC --- Created attachment 25733 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25733 possible patch This patch brings the computation time back down: ... $ time gcc src/gcc/testsuite/gcc.c-torture/compile/20001226-1.c -S -O2 -ftree-tail-merge real0m35.600s user0m35.210s sys0m0.270s ... The patch delegates the updating of the vops to TODO_update_ssa_only_virtuals. That way, the dominators don't need to be updated after every replacement, just after every iteration.
[Bug tree-optimization/51005] -ftree-tail-merge slows down compilation of 20001226-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51005 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-07 AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-11-07 10:49:23 UTC --- Just hit the same problem today: ... /tmp/ccNz0HZT.ltrans29.ltrans.o:ccNz0HZT.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.98063: error: undefined reference to '.L3709' /tmp/ccNz0HZT.ltrans29.ltrans.o:ccNz0HZT.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.98063: error: undefined reference to '.L3710' /tmp/ccNz0HZT.ltrans29.ltrans.o:ccNz0HZT.ltrans29.o:function _ZZN2js9InterpretEP9JSContextPNS_10StackFrameENS_10InterpModeEE15normalJumpTable.98063: error: undefined reference to '.L3711' ...
[Bug target/51007] New: Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Bug #: 51007 Summary: Quadmath I/O doesn't work on MinGW Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org Target: i586-pc-mingw32 The following test program works fine with current trunk on i686 and x86_64-linux: #include quadmath.h #include stdio.h int main (void) { char buf[100]; quadmath_snprintf (buf, sizeof buf, %.60Qg, (__float128) 3.14); puts (buf); } It outputs 3.140124344978758017532527446746826171875. When compiled and run on MinGW, it gives an incorrect output (on my test system, 1.9163987915738935076000483121420225908698150840344985584492e-4932). I confirmed with both a native MinGW build (i586-pc-mingw32) and a cross-compiler for i586-pc-mingw32, running on x86_64-apple-darwin11, and running the result under either Wine or a real Windows. The cross-compiler is configured as such: ../../gcc/trunk/configure --target=i586-pc-mingw32 --disable-werror --enable-languages=c,fortran
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-07 Ever Confirmed|0 |1
[Bug tree-optimization/51005] -ftree-tail-merge slows down compilation of 20001226-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51005 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 11:00:39 UTC --- Note that PRE already performs TODO_update_ssa_only_virtuals (well, of course only if something marked the VOP for renaming which happens whenever it inserts a load somewhere). So it might indeed be not too bad to do this (given the amount of code we can delete ...)
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #19 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-11-07 11:00:47 UTC --- Dear Tobias, I have been keeping out of this for the time being because I want to get some of the final OOP array issues out of the way. I figured that, as a regression, it could wait for a little while :-( Possible patch which pushes the vtab to the toplevel This looks like a perfectly good way to do this. At least that approach fails for the following file (of PSBLAS 3's configure), which yields an internal compiler error: in cgraph_analyze_functions, at cgraphunit.c:1193 which is at fprintf (cgraph_dump_file, \nReclaiming functions:); for (node = cgraph_nodes; node != first_analyzed; node = next) { ... gcc_assert (node-analyzed == node-local.finalized); program xtt type foo integer :: i end type foo type, extends(foo) :: new_foo integer :: j end type new_foo class(foo), allocatable :: fooab type(new_foo) :: nfv integer :: info allocate(fooab, source=nfv, stat=info) end program xtt That it should fail on this is utterly bizarre. I presume that it is the allocate statement that wipes it out? Paul
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-11-07 11:03:32 UTC --- I don't know if it's related, or two different bugs, but hexadecimal printing has the correct mantissa with a wrong exponent. See below the same testcase compile on my mac (native compiler) and cross-compiled to mingw: $ cat v.c #include quadmath.h #include stdio.h int main (void) { char buf[100]; quadmath_snprintf (buf, sizeof buf, %.60Qa, (__float128) 3.14); puts (buf); } $ gcc-4.6 v.c -lquadmath ./a.out 0x1.91eb851eb851f000p+1 $ ./cross/bin/i586-pc-mingw32-gcc v.c -static -lquadmath $ /opt/wine/bin/wine ./a.exe 0x1.91eb851eb851f000p-5318
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 11:07:34 UTC --- Hm, with a cross I cannot reproduce the IL you posted (on trunk head, that is). Is hppa2.0w-hp-hpux11.11 a host-wide-int 32bit host? (no idea how I can force HWI 32bit here :/) Can you attach -fdump-tree-vrp-details dumps for trunk head?
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-11-07 11:29:39 UTC --- The bug is not in the I/O routine, it can be reproduce by this simple self-contained testcase (which doesn't need libquadmath). #include stdint.h typedef union { __float128 value; struct { #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ unsigned negative:1; unsigned exponent:15; uint64_t mant_high:48; uint64_t mant_low:64; #else uint64_t mant_low:64; uint64_t mant_high:48; unsigned exponent:15; unsigned negative:1; #endif } ieee; } ieee854_float128; int main (void) { ieee854_float128 d; d.value = (__float128) 3.14; __builtin_printf (%u\n, (unsigned) d.ieee.exponent); } On darwin, this program consistently outputs 16384. When cross-compiled to mingw, and run on Windows XP, it consistently outputs 6448. When the same executable is run under Wine on darwin, it outputs inconsistent, wrong values (the last few invocations here show: 4755, 12947, 21139).
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-11-07 11:39:12 UTC --- Going further: I tried to compare the trees generated by the simple function below: #include stdint.h typedef union { __float128 value; struct { #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ unsigned negative:1; unsigned exponent:15; uint64_t mant_high:48; uint64_t mant_low:64; #else uint64_t mant_low:64; uint64_t mant_high:48; unsigned exponent:15; unsigned negative:1; #endif } ieee; } ieee854_float128; unsigned foo (__float128 x) { ieee854_float128 d; d.value = x; return d.ieee.exponent; } AFAICT, both the original and the optimized tree for darwin and mingw are identical. The assembly code generated for a common arch (-march=core2 -O0) differs: * on mingw * _foo: pushl %ebp movl%esp, %ebp subl$40, %esp movdqa 8(%ebp), %xmm0 movdqa %xmm0, -40(%ebp) movzwl -24(%ebp), %eax andw$32767, %ax movzwl %ax, %eax leave ret * on darwin * _foo: pushq%rbp movq%rsp, %rbp movdqa%xmm0, -32(%rbp) movdqa-32(%rbp), %xmm0 movdqa%xmm0, -16(%rbp) movzwl-2(%rbp), %eax andw$32767, %ax movzwl%ax, %eax popq%rbp ret Now, my assembly skills are pretty close to nil, so I can't figure out if the differences are meaningful, and what they mean. I only hope that I got it close enough that someone can, from here, understand where this code generation come from and how to fix it.
[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added Target||i686-*-* x86_64-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2011-11-07 CC||belyshev at depni dot ||sinp.msu.ru Ever Confirmed|0 |1 Summary|ICE: compiling libgfortran |[4.7 Regression] ICE in |for i686-w64-mingw32|scan_tree_for_params_right_ ||scev, at ||graphite-sese-to-poly.c:633 ||compiling libgfortran with ||-floop-interchange -m32 Severity|critical|normal --- Comment #3 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-11-07 11:43:48 UTC --- Reduced testcase, fails on mainline with -O2 -floop-interchange -m32: void spread_i1 (int *rptr, int *sptr, int ncopies, int *extent, int rdelta, int m) { int *dest; int n; while (m--) { dest = rptr; for (n = 0; n ncopies; n ++) { *dest = *sptr; dest += rdelta; } if (extent [n]) if (n) rptr ++; } }
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2011-11-07 12:00:49 UTC --- The issue is caused by bitfield layout. For mingw targets the -mms-bitfields option is for 4.7 active by default. So the mixture of different sized types in union is leading to this behavior. You can see that result becomes ok, if you are specifying to union/struct the attribute gcc_struct. Cheers, Kai
[Bug regression/50999] [4.7 Regression]: g++.dg/lto/20081109 execute -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50999 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 12:02:36 UTC --- Created attachment 25734 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25734 proposed patch Hm, on x86_64 the EH table is not empty (look at g++.dg/lto/20081109_1.C, the usual symtom is that the LTOed unit for that file does not contain info to unwind from the throw - can you confirm that?). The key is that lto_init_eh() has to be called for that unit - previously we saved flag_exceptions but now we only save explicit -fexceptions (thus, you can verify if explicitly adding that option to the compile command line fixes the issue). Does the attached patch help? It tries to start to address the (yet unsolved) issue of preserving lang-dependent options.
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2011-11-07 12:19:09 UTC --- Suggested patch for this issue ChangeLog * quadmath-imp.h (ieee854_float128): Adjust for ms-bitfield layout. Index: quadmath-imp.h === --- quadmath-imp.h (revision 180840) +++ quadmath-imp.h (working copy) @@ -48,6 +48,11 @@ __float128 value; struct +#ifdef __MINGW32__ + /* On mingw targets ms-bitfields option is active by default. + Therefore enforce gnu-bitfield style. */ + __attribute__ ((gcc_struct)) +#endif { #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ unsigned negative:1; @@ -89,6 +94,10 @@ } words32; struct +#ifdef __MINGW32__ + /* Make sure we are using gnu-style bitfield handling. */ + __attribute__ ((gcc_struct)) +#endif { #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ unsigned negative:1;
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||patch CC||jakub at redhat dot com --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-11-07 12:42:26 UTC --- (In reply to comment #4) So the mixture of different sized types in union is leading to this behavior. You can see that result becomes ok, if you are specifying to union/struct the attribute gcc_struct. Indeed, I confirm that your patch fixes the issue (and the original Fortran testcase reported on comp.lang.fortran now works fine). Both Tobias and Jakub (Cc'ed) are libquadmath maintainers and can approve it.
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #7 from dave.anglin at bell dot net 2011-11-07 12:48:30 UTC --- On 7-Nov-11, at 6:07 AM, rguenth at gcc dot gnu.org wrote: Is hppa2.0w-hp-hpux11.11 a host-wide-int 32bit host? (no idea how I can force HWI 32bit here :/) No, it's 64 bits. -- John David Anglindave.ang...@bell.net
[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-11-07 12:51:01 UTC --- Fails since the fix for bug 50067, r178028: 2011-08-24 Richard Guenther rguent...@suse.de PR tree-optimization/50067 * tree-data-ref.c (dr_analyze_indices): Do not add an access function for a MEM_REF base that has no evolution in the loop nest or that is not analyzable. ...
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-07 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1
[Bug c++/51004] ICE in lower_stmt at gimple-low.c:428
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51004 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-11-07 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-07 13:05:17 UTC --- Even if you can't reduce the testcase (maybe via 'delta'? See: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction) please attach anyway the preprocessed *.ii, per http://gcc.gnu.org/bugs/
[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 13:07:53 UTC --- Looks like a genuine graphite bug though 718 switch (TREE_CODE (e)) 719 { 720 case POLYNOMIAL_CHREC: 721 scan_tree_for_params_right_scev (s, CHREC_RIGHT (e), 722CHREC_VARIABLE (e), c); (gdb) call debug_generic_expr (e) {0B, +, (sizetype) pretmp.6_31}_2 632 | a [i * p] = ... */ 633 gcc_assert (TREE_CODE (e) == INTEGER_CST); where e here is CHREC_RIGHT (e). Looks like sth assumes this form of a SCEV does not happen. #(Data Ref: # bb: 4 # stmt: *dest_35 = D.2240_13; # ref: *dest_35; # base_object: *rptr_1; # Access function 0: {0B, +, (sizetype) pretmp.6_31}_2 #) Note that data-ref analysis fails with failed: evolution of base is not affine but graphite still forces access functions to be generated.
[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2011-11-07 13:37:16 UTC --- still not right .. generates wrong code for the first two accesses (missing the indirect load).
[Bug libstdc++/51008] New: GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 Bug #: 51008 Summary: GTHR - extend interface with __gthread_recursive_mutex_destroy Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: andv...@gmail.com This is not a direct libstdc++ bug, but an interface issue of gthreads. I haven't found a similar bug report except for #46455. The issue appears because in libstdc++-v3/include/ext/concurrence.h in d-tor of __recursive_mutex class, when a custom GTHR implementation is used (We have to provide one for a legacy non-POSIX OS). According to SVN, the problem still exists in branch 4.6 and trunk. I can propose two solutions: 1. Add __gthread_recursive_mutex_destroy and get rid of _S_destroy template hacks. 2. Add a new macro __GTHREAD_RECURSIVE_MUTEX_DESTROY_FUNCTION. If the macro is defined by GTHR implementation then __mutex d-tor shall call it instead of _S_destroy hacks. It shall be also a good solution for Win32 and other custom destructors. IMO, the first one is the most correct. The second is suitable to maintain backward compatibility and is the least risky. I can provide a patch for the second approach, if needed.
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #1 from Andrey Galkin andvgal at gmail dot com 2011-11-07 13:52:36 UTC --- * The problem is in incompatible types when __gthread_mutex_destroy is called instead of __gthread_recursive_mutex_destroy (missing in the default interface) in __recursive_mutex::_S_destroy.
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 14:02:52 UTC --- The best solution is to add that function to the gthr API, but stage1 is about to end, so we might not have time to do it (the reason for the _S_destroy hack in the first place was lack of time to fix it properly, see PR 46455 comment 19) Is it possible to extend the _S_destroy hack to handle your case? N.B. this is not a libstdc++ bug, gthreads is not part of libstdc++ (or we'd have just changed it to fix PR 45455)
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 14:04:09 UTC --- P.S. this is very unlikely to get fixed on the 4.6 branch, but there might be time to get it done for 4.7
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 14:24:43 UTC --- Created attachment 25735 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25735 use __GTHREAD_RECURSIVE_MUTEX_DESTROY_FUNCTION if defined here's a proof of concept, that would allow your private gthr to define the macro and work. we could then gradually transition Win32 and other gthr impls to use that and remove the sfinae hacks
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #5 from Andrey Galkin andvgal at gmail dot com 2011-11-07 14:28:56 UTC --- Created attachment 25736 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25736 PR51008 workaround, fits GCC 4.6.2
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 Andrey Galkin andvgal at gmail dot com changed: What|Removed |Added Severity|major |minor --- Comment #6 from Andrey Galkin andvgal at gmail dot com 2011-11-07 14:29:16 UTC --- Actually, I'm quite OK applying my custom patch (attached) during toolchain build, but it could be useful for others. Changing importance to minor.
[Bug libfortran/45723] opening /dev/null for appending writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45723 --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-07 14:32:56 UTC --- Author: jb Date: Mon Nov 7 14:32:50 2011 New Revision: 181085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181085 Log: Revert previous fix for PR 45723. libgfortran ChangeLog: 2011-11-07 Janne Blomqvist j...@gcc.gnu.org PR libfortran/45723 * io/open.c (new_unit): Don't check file size before attempting seek. testsuite ChangeLog: 2011-11-07 Janne Blomqvist j...@gcc.gnu.org PR libfortran/45723 * gfortran.dg/open_dev_null.F90: Remove testcase. Removed: trunk/gcc/testsuite/gfortran.dg/open_dev_null.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c
[Bug libfortran/45723] opening /dev/null for appending writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45723 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-07 14:35:57 UTC --- For the motivations behind this revert, see http://gcc.gnu.org/ml/fortran/2011-10/msg00289.html For the short version: Note that seeking on /dev/null still works at least on Linux.
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #9 from dave.anglin at bell dot net 2011-11-07 14:44:52 UTC --- Created attachment 25738 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25738 arith-rand-ll.c.124t.vrp2
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #8 from dave.anglin at bell dot net 2011-11-07 14:44:50 UTC --- On 11/7/2011 6:07 AM, rguenth at gcc dot gnu.org wrote: Can you attach -fdump-tree-vrp-details dumps for trunk head? Attached.
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #43 from David Edelsohn dje at gcc dot gnu.org 2011-11-07 15:04:30 UTC --- Jonathan, Your patch works, but Rainer still has not checked in his original patch fixing gthr headers, AFAIK. Thanks, David
[Bug other/42980] GCC parallel make install failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #17 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-07 15:07:09 UTC --- I now get this when bootstrapping today's trunk and then make -j4 install: /usr/bin/install: cannot create regular file `/home/janne/src/gfortran/trunk/install/bin/gcc-ar': No such file or directory make[2]: *** [install-gcc-ar] Error 1 As a result, my install/bin directory is empty. Running make install fixes the problem, suggesting a race somewhere. Perhaps due to Rainer's recent move of configury logic to libgcc? My configure line: nice ../$SRCDIR/configure --enable-checking \ --prefix=/home/janne/src/gfortran/$GCCDIR/install --enable-languages=fortran \ --enable-maintainer-mode \ --enable-__cxa_atexit \ --disable-bootstrap \ --enable-threads=posix \ --disable-multilib Target host: x86_64-unknown-linux-gnu
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 15:12:26 UTC --- Great, thanks - we can leave it open for now until it's fully resolved. As I said in comment 28, we might need to adjust the libstdc++ testsuite now that some new threading features are enabled
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-07 15:09:54 UTC --- Weird. My cross configured with /space/rguenther/src/svn/trunk/configure --enable-languages=c,c++,fortran --disable-nls --target=hppa2.0w-hp-hpux11.11 does not reproduce this. I'm using ./cc1 -O2 on arith-rand-ll.c, and I'm getting arith-rand-ll.c: In function 'main': arith-rand-ll.c:59:4: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ... not sure if that's related. From your dump file: x_118: [0, +INF] EQUIVALENCES: { x_5 D.2243_12 } (2 elements) xx_56: VARYING D.2297_58: [-32768, 32767] xx_56 = (short int) x_118; Folding statement: D.2297_58 = (int) xx_56; Folded into: D.2297_58 = (int) x_118; should be reproducible with extern void abort (void); long long unsigned int x = 1 (sizeof (short int) * 8); int main() { if (x = 0) { short int xx = (short int)x; if (xx != 0) abort (); } return 0; } but that works for me ... does this fail for you? Looking at the above it _appears_ that x is signed!? The reported value-range should be x_5: VARYING which it is indeed when compiling with my cross ... Is, by any chance, the middle-end sizetype == long long unsigned int? And for some weird reason those are mapped together?
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-07 15:29:52 UTC --- (In reply to comment #5) ChangeLog * quadmath-imp.h (ieee854_float128): Adjust for ms-bitfield layout. +#ifdef __MINGW32__ + /* On mingw targets ms-bitfields option is active by default. + Therefore enforce gnu-bitfield style. */ + __attribute__ ((gcc_struct)) +#endif The patch looks fine to me - except that I would put an the before ms-bitfields option.
[Bug middle-end/51009] New: [4.7 Regression] ICE in verify_gimple_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51009 Bug #: 51009 Summary: [4.7 Regression] ICE in verify_gimple_stmt Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: reich...@gcc.gnu.org The following code snippet triggers an ICE on trunk: === struct A { ~A(); }; struct B { A a; B(const A = A()); }; struct C { B b1, b2; }; C c = {}; === bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)': bug.cc:17:9: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4188 Please submit a full bug report, [etc.]
[Bug middle-end/51009] [4.7 Regression] ICE in verify_gimple_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51009 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/50822] [4.7 regression] Solaris/SPARC bootstrap failure with Sun as: invalid assembler for ios_init.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50822 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-11-07 15:47:08 UTC --- Hi, the problem seems to be due to fact that C++ FE output extern aliases. This is not quite documented and they was simply removed by the old alias pair handling code (I believe by accident rather than by design), while the new code confuses them with weakrefs and attempts to output into final assembly. I think those aliases might potentially be useful for alias analysis and == folding - i.e. they provide knowledge that those two variables/functions must be equivalent. So instead of convincing C++ FE to not output them it seems better to make cgraph code to deal with them well. For 4.8 we may start using the alias walkers in the alias analysis and folding to actually make use of this. I think it only imply need to ignore them when the functions are being output. I am testing the attached patch that ought to solve the issue. Index: cgraphunit.c === --- cgraphunit.c(revision 181033) +++ cgraphunit.c(working copy) @@ -2101,13 +2101,15 @@ output_weakrefs (void) struct varpool_node *vnode; for (node = cgraph_nodes; node; node = node-next) if (node-alias DECL_EXTERNAL (node-decl) - !TREE_ASM_WRITTEN (node-decl)) + !TREE_ASM_WRITTEN (node-decl) +lookup_attribute (weakref, DECL_ATTRIBUTES (node-decl))) assemble_alias (node-decl, node-thunk.alias ? DECL_ASSEMBLER_NAME (node-thunk.alias) : get_alias_symbol (node-decl)); for (vnode = varpool_nodes; vnode; vnode = vnode-next) if (vnode-alias DECL_EXTERNAL (vnode-decl) - !TREE_ASM_WRITTEN (vnode-decl)) + !TREE_ASM_WRITTEN (vnode-decl) +lookup_attribute (weakref, DECL_ATTRIBUTES (vnode-decl))) assemble_alias (vnode-decl, vnode-alias_of ? DECL_ASSEMBLER_NAME (vnode-alias_of) : get_alias_symbol (vnode-decl));
[Bug middle-end/42636] warning: ‘line[0]’ may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42636 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED CC||belyshev at depni dot ||sinp.msu.ru Known to work||4.2.0, 4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail||4.3.0, 4.4.0, 4.5.0 --- Comment #2 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-11-07 15:50:14 UTC --- Fixed by commit r158835 in 4.6.0: 2010-04-28 Xinliang David Li davi...@google.com PR c/42643 * tree-ssa-uninit.c (can_skip_redundant_opnd): New function. ... Bad diagnostics in comment #1 is a separate issue.
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-07 15:59:10 UTC --- Author: jakub Date: Mon Nov 7 15:59:07 2011 New Revision: 181089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181089 Log: PR tree-optimization/50789 * tree-vect-stmts.c (process_use): Add force argument, avoid exist_non_indexing_operands_for_use_p check if true. (vect_mark_stmts_to_be_vectorized): Adjust callers. Handle STMT_VINFO_GATHER_P. (gen_perm_mask): New function. (perm_mask_for_reverse): Use it. (reverse_vec_element): Rename to... (permute_vec_elements): ... this. Add Y and MASK_VEC arguments, generalize for any permutations. (vectorizable_load): Adjust caller. Handle STMT_VINFO_GATHER_P. * target.def (TARGET_VECTORIZE_BUILTIN_GATHER): New hook. * doc/tm.texi.in (TARGET_VECTORIZE_BUILTIN_GATHER): Document it. * doc/tm.texi: Regenerate. * tree-data-ref.c (initialize_data_dependence_relation, compute_self_dependence): No longer static. * tree-data-ref.h (initialize_data_dependence_relation, compute_self_dependence): New prototypes. * tree-vect-data-refs.c (vect_check_gather): New function. (vect_analyze_data_refs): Detect possible gather load data refs. * tree-vectorizer.h (struct _stmt_vec_info): Add gather_p field. (STMT_VINFO_GATHER_P): Define. (vect_check_gather): New prototype. * config/i386/i386-builtin-types.def: Add types for alternate gather builtins. * config/i386/sse.md (AVXMODE48P_DI): Remove. (VEC_GATHER_MODE): Rename mode_attr to... (VEC_GATHER_IDXSI): ... this. (VEC_GATHER_IDXDI, VEC_GATHER_SRCDI): New mode_attrs. (avx2_gathersimode, *avx2_gathersimode): Use VEC_GATHER_IDXSI instead of VEC_GATHER_MODE. (avx2_gatherdimode): Use VEC_GATHER_IDXDI instead of AVXMODE48P_DI and VEC_GATHER_SRCDI instead of VEC_GATHER_MODE on src and mask operands. (*avx2_gatherdimode): Likewise. Use VEC_GATHER_MODE iterator instead of AVXMODE48P_DI. (avx2_gatherdimode256, *avx2_gatherdimode256): Removed. * config/i386/i386.c (enum ix86_builtins): Add IX86_BUILTIN_GATHERALTSIV4DF, IX86_BUILTIN_GATHERALTDIV8SF, IX86_BUILTIN_GATHERALTSIV4DI and IX86_BUILTIN_GATHERALTDIV8SI. (ix86_init_mmx_sse_builtins): Create those builtins. (ix86_expand_builtin): Handle those builtins and adjust expansions of other gather builtins. (ix86_vectorize_builtin_gather): New function. (TARGET_VECTORIZE_BUILTIN_GATHER): Define. * gcc.target/i386/avx2-gather-1.c: New test. * gcc.target/i386/avx2-gather-2.c: New test. * gcc.target/i386/avx2-gather-3.c: New test. * gcc.target/i386/avx2-gather-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx2-gather-1.c trunk/gcc/testsuite/gcc.target/i386/avx2-gather-2.c trunk/gcc/testsuite/gcc.target/i386/avx2-gather-3.c trunk/gcc/testsuite/gcc.target/i386/avx2-gather-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-builtin-types.def trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug c++/16166] -Weffc++ finer granularity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 16:10:10 UTC --- Reviewing these warnings w.r.t the much improved third edition... (In reply to comment #1) # Item 11: Define a copy constructor and an assignment operator for classes with dynamically allocated memory. Replaced by Item 14: Think carefully about copying behavior in resource-managing classes - the advice is less specific, but more useful. I'm not sure how to turn it into a warning though! # Item 12: Prefer initialization to assignment in constructors. Replaced by Item 4: Make sure that objects are initialized before they're used, and G++ misinterprets the original item anyway and warns about *any* member without a mem-initializer, which is very annoying: there's no point initializing a std::string, it has a perfectly safe default constructor. My -Wmeminit patch for PR 2972 should replace the current warning for this item, as it only warns about members left uninitialized by the constructor. # Item 14: Make destructors virtual in base classes. Adjusted to Item 7: Declare destructors virtual in polymorphic base classes, the warning is still relevant (but -Wdelete-non-virtual-dtor is more useful IMHO) # Item 15: Have operator= return a reference to *this. Renumbered to Item 10. Still relevant. # Item 23: Don't try to return a reference when you must return an object. Renumbered to Item 21. Still relevant. # Item 6: Distinguish between prefix and postfix forms of increment and decrement operators. # Item 7: Never overload , ||, or ,. These are from More Effective C++ which only has one edition.
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #11 from dave.anglin at bell dot net 2011-11-07 16:11:55 UTC --- On 11/7/2011 10:09 AM, rguenth at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #10 from Richard Guentherrguenth at gcc dot gnu.org 2011-11-07 15:09:54 UTC --- Weird. My cross configured with /space/rguenther/src/svn/trunk/configure --enable-languages=c,c++,fortran --disable-nls --target=hppa2.0w-hp-hpux11.11 does not reproduce this. I'm using ./cc1 -O2 on arith-rand-ll.c, and I'm getting arith-rand-ll.c: In function 'main': arith-rand-ll.c:59:4: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ... I see the same if I remove the -w option from the test. not sure if that's related. From your dump file: x_118: [0, +INF] EQUIVALENCES: { x_5 D.2243_12 } (2 elements) xx_56: VARYING D.2297_58: [-32768, 32767] xx_56 = (short int) x_118; Folding statement: D.2297_58 = (int) xx_56; Folded into: D.2297_58 = (int) x_118; should be reproducible with extern void abort (void); long long unsigned int x = 1 (sizeof (short int) * 8); int main() { if (x= 0) { short int xx = (short int)x; if (xx != 0) abort (); } return 0; } but that works for me ... does this fail for you? Looking at the above The above test doesn't fail. I've attached the detail vrp dumps as they don't seem to match what you described below. it _appears_ that x is signed!? The reported value-range should be x_5: VARYING which it is indeed when compiling with my cross ... Is, by any chance, the middle-end sizetype == long long unsigned int? And for some weird reason those are mapped together? Looking at the hwi issue, I see that need_64bit_hwint is not defined for this target, or for the 32-bit hppa-linux target. Test fails on both. However, it doesn't fail on hppa64-hp-hpux11.11 where need_64bit_hwint is defined (long is 64 bits). Suspect a cross from hppa64-hp-hpux11.11 would work.
[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50802 --- Comment #12 from dave.anglin at bell dot net 2011-11-07 16:11:56 UTC --- Created attachment 25740 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25740 xxx.c.124t.vrp2
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #20 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-07 16:17:34 UTC --- (In reply to comment #18) (In reply to comment #16) Created attachment 25730 [details] Possible patch which pushes the vtab to the toplevel The reason for the failure is clear: For the derived type/class, the function __copy_xtt_Foo is created. The created function is in the scope of the derived type - which is declared in program xtt. If one now places the vtab at the top level, the copy function is hidden in another function as nested function. Hence, one also needs to create the function at top level; I wonder whether this can be already done at decl time in gfc_find_derived_vtab.
[Bug target/50963] TLS incompatible with -mcmodel=large PIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50963 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-11-07 16:24:28 UTC --- The problem is in (call:DI (mem:QI (symbol_ref:DI (__tls_get_addr)) [0 S1 A8]), the symbol_ref does not satisfy constant_call_address_operand predicate. Unfortunately, these are specified sequences, so all we can do is to declare large PIC code model incompatible with GNU TLS dialect.
[Bug c++/38928] infinite loop on error message in C++ only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38928 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | Known to fail|| --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-07 16:25:00 UTC --- The infinite loop is gone in 4.5.x and current branches.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #21 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-07 16:27:24 UTC --- (In reply to comment #20) The reason for the failure is clear: For the derived type/class, the function __copy_xtt_Foo is created. The created function is in the scope of the derived type - which is declared in program xtt. If one now places the vtab at the top level, the copy function is hidden in another function as nested function. Hence, one also needs to create the function at top level; I wonder whether this can be already done at decl time in gfc_find_derived_vtab. Post script: I was wondering whether it is possible to move the vtab to the top level as one might get in trouble with other member functions; however, as gfortran told me, a method (type-bound procedure) must be a module procedure or an external procedure with an explicit interface. Hence, all methods are already visible at the toplevel. Thus, it only affects _copy which /can/ be moved to the toplevel.
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-07 16:27:49 UTC --- So, fixed long time ago.
[Bug middle-end/51010] New: [4.7 Regression] bad diagnostics: #'ssa_name' not supported by pp_c_expression#]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51010 Bug #: 51010 Summary: [4.7 Regression] bad diagnostics: #'ssa_name' not supported by pp_c_expression#]' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: belys...@depni.sinp.msu.ru CC: rgue...@gcc.gnu.org Compiling this with -O1 -Wall will cause weird output: int f (int j) { int a [10]; return a [j]; } $ ./cc1 -quiet -O1 -Wall bug.c #'ssa_name' not supported by pp_c_expression#]'bug.c: In function 'f': bug.c:4:3: warning: is used uninitialized in this function [-Wuninitialized] $ Caused by r154918 (but was latent until the fix for pr50040, r177667): 2009-12-02 Richard Guenther rguent...@suse.de PR middle-end/42088 * tree.c (free_lang_data): Disable if not using LTO. Reverting r154918 helps: bug.c: In function 'f': bug.c:4:3: warning: 'a[j_1(D)]' is used uninitialized in this function [-Wuninitialized]
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #45 from Rainer Orth ro at gcc dot gnu.org 2011-11-07 16:34:37 UTC --- Author: ro Date: Mon Nov 7 16:34:31 2011 New Revision: 181095 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181095 Log: Return gthr-posix.h to libgcc (PR bootstrap/50982) libgcc: PR bootstrap/50982 * config/gthr-posix.h: Move ... * gthr-posix.h: ... here. * config/gthr-lynx.h: Reflect this. * config/gthr-vxworks.h: Likewise. * config/rs6000/gthr-aix.h: Likewise. * configure.ac (target_thread_file): Likewise. * configure: Regenerate. libstdc++-v3: PR bootstrap/50982 * include/Makefile.am (${host_builddir}/gthr-posix.h): Reflect gthr-posix.h move. * include/Makefile.in: Regenerate. Added: trunk/libgcc/gthr-posix.h - copied, changed from r181094, trunk/libgcc/config/gthr-posix.h Removed: trunk/libgcc/config/gthr-posix.h Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/gthr-lynx.h trunk/libgcc/config/gthr-vxworks.h trunk/libgcc/config/rs6000/gthr-aix.h trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in
[Bug c++/51004] ICE in lower_stmt at gimple-low.c:428
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51004 --- Comment #2 from kennytm at gmail dot com 2011-11-07 16:36:37 UTC --- Created attachment 25741 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25741 The processed file that triggers the bug. Reduced test case: = struct CCC { int x; }; struct S { ~S() {} }; void init_from_tuples_impl(S* tpl) { new CCC{ (S(*tpl), 0) }; } = $ g++ -c 2.cpp 2.cpp: In function ‘void init_from_tuples_impl(S*)’: 2.cpp:13:9: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] 2.cpp:14:1: internal compiler error: in lower_stmt, at gimple-low.c:428 Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions. = The .ii file is the same, attached for completeness.
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #46 from Rainer Orth ro at gcc dot gnu.org 2011-11-07 16:43:35 UTC --- David, I had been waiting to see if the remaining AIX gthread issues were releated to my patch. Since that's not the case and my own testing had completed successfully, I've now checked in my patch. Rainer
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-07 16:45:36 UTC --- --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-07 15:12:26 UTC --- Great, thanks - we can leave it open for now until it's fully resolved. As I said in comment 28, we might need to adjust the libstdc++ testsuite now that some new threading features are enabled I had long meant to fix the many copies of hardcoded lists of targets supporting pthreads, but haven't yet gotten around to it. Rainer
[Bug c++/51004] ICE in lower_stmt at gimple-low.c:428
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51004 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.7.0 Resolution||WORKSFORME Known to fail||4.6.2 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-07 17:34:01 UTC --- Thanks. Mainline works fine and doesn't look like a regression.
[Bug c++/33255] A warning for unused typedefs?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255 --- Comment #28 from Jason Merrill jason at gcc dot gnu.org 2011-11-07 17:51:28 UTC --- Author: jason Date: Mon Nov 7 17:51:24 2011 New Revision: 181100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181100 Log: PR c++/33255 * decl.c (save_function_data): Clear local_typedefs. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-11-07 17:51:43 UTC --- Author: jason Date: Mon Nov 7 17:51:40 2011 New Revision: 181102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181102 Log: PR c++/35688 * decl2.c (constrain_visibility): Return void. Add tmpl parm which gives the constraint priority over an attribute. (constrain_visibility_for_template, determine_visibility): Adjust. * pt.c (instantiate_class_template_1): Call determine_visibility. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/template8.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/50822] [4.7 regression] Solaris/SPARC bootstrap failure with Sun as: invalid assembler for ios_init.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50822 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-07 17:54:00 UTC --- I am testing the attached patch that ought to solve the issue. A sparc-sun-solaris2.11 bootstrap with Sun as is now into stage3, so this looks quite good so far. I'll let you know if the bootstrap reveals any unforseen problems. Thanks a lot. Rainer
[Bug target/49313] Inefficient libgcc implementations for avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49313 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-11-07 18:08:40 UTC --- Author: gjl Date: Mon Nov 7 18:08:35 2011 New Revision: 181104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181104 Log: PR target/49313 * config/avr/lib1funcs.S (__divmodhi4, __divmodsi4): Tweak speed. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S
[Bug fortran/50919] [OOP] Don't use vtable for NON_OVERRIDABLE TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919 --- Comment #5 from janus at gcc dot gnu.org 2011-11-07 18:41:16 UTC --- Author: janus Date: Mon Nov 7 18:41:12 2011 New Revision: 181107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181107 Log: 2011-11-07 Janus Weil ja...@gcc.gnu.org PR fortran/50919 * class.c (add_proc_comp): Don't add non-overridable procedures to the vtable. * resolve.c (resolve_typebound_function,resolve_typebound_subroutine): Don't generate a dynamic _vptr call for non-overridable procedures. 2011-11-07 Janus Weil ja...@gcc.gnu.org PR fortran/50919 * gfortran.dg/typebound_call_21.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_21.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50919] [OOP] Don't use vtable for NON_OVERRIDABLE TBP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-11-07 18:46:27 UTC --- Fixed with r181107 (including both parts of the patch in comment 2). Closing.
[Bug target/20634] code fails to compile/code generation issue with -funit-at-a-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added Status|NEW |RESOLVED CC||belyshev at depni dot ||sinp.msu.ru Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 Known to fail|| --- Comment #6 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-11-07 19:13:57 UTC --- Fixed in gcc 4.5 by r151348: 2009-09-02 Vladimir Makarov vmaka...@redhat.com * doc/invoke.texi (-fsched-pressure): Document it. (-fsched-reg-pressure-heuristic): Remove it. ...
[Bug other/51011] New: FAIL: gcc.dg/atomic-generic.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011 Bug #: 51011 Summary: FAIL: gcc.dg/atomic-generic.c (test for excess errors) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-generic.c-w /test/gnu/gcc/gcc/gc c/testsuite/gcc.dg/atomic-generic-aux.c -lm -o ./atomic-generic.exe (timeo ut = 300) /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_compare_exchange (first referenced in /var/tmp//cc8Tx8dY.o) (data) __atomic_load (first referenced in /var/tmp//cc8Tx8dY.o) (data) __atomic_store (first referenced in /var/tmp//cc8Tx8dY.o) (data) __atomic_exchange (first referenced in /var/tmp//cc8Tx8dY.o) (data) collect2: error: ld returned 1 exit status Similar fails: FAIL: gcc.dg/atomic-lockfree.c (test for excess errors) Excess errors: /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_is_lock_free (first referenced in /var/tmp//ccmFyrgX.o) (data) Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-noinline.c-w -fno-inline-atomics /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-noinline-aux.c -lm -o ./atomic -noinline.exe(timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_exchange_1 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_load_2 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_compare_exchange_2 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_store_1 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_fetch_add_1 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_fetch_add_2 (first referenced in /var/tmp//ccCRwwDz.o) (data) __atomic_is_lock_free (first referenced in /var/tmp//ccCRwwDz.o) (data)
[Bug fortran/48426] [patch] Quad precision promotion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 --- Comment #15 from Andreas Kloeckner inform at tiker dot net 2011-11-07 19:25:32 UTC --- Zydrunas and I have successfully completed the copyright assignment process, and we're ready to move forward with this patch.
[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011 Andrew Macleod amacleod at redhat dot com changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #1 from Andrew Macleod amacleod at redhat dot com 2011-11-07 19:27:36 UTC --- Is dejagnu on hpux limited somehow? atomic-generic.c for instance has the line: /* { dg-additional-sources atomic-generic-aux.c } */ which on all the targets I have tried it on cause atomic-generic-aux.c to be compiled at the same time as atomic-generic.c, and it supplies those functions... is there a reason that doesn't happen on hpux?
[Bug target/51007] [4.7 Regression] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|Quadmath I/O doesn't work |[4.7 Regression] Quadmath |on MinGW|I/O doesn't work on MinGW
[Bug c/22065] -fdump-tree-original causes static function to emitted with the same name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22065 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added Status|NEW |RESOLVED CC||belyshev at depni dot ||sinp.msu.ru Resolution||FIXED Known to fail|| --- Comment #10 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-11-07 19:31:45 UTC --- Fixed at some point between 4.2 and 4.3.
[Bug tree-optimization/51012] New: [4.7 Regression] ICE: in fold_convert_loc, at fold-const.c:1897 with -fno-early-inlining and passing incompatible function ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51012 Bug #: 51012 Summary: [4.7 Regression] ICE: in fold_convert_loc, at fold-const.c:1897 with -fno-early-inlining and passing incompatible function ptr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: rgue...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25742 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25742 reduced testcase This is very similiar to PR50890, actually the testcase was reduced from testsuite/gcc.dg/torture/pr50890.c Compiler output: $ gcc -O2 -fno-early-inlining testcase.c testcase.c: In function 'foo': testcase.c:9:3: internal compiler error: in fold_convert_loc, at fold-const.c:1897 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x122c488 /mnt/svn/gcc-trunk/gcc/fold-const.c, line=1894, function=0x122b500 fold_convert_loc) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x007a602b in fold_convert_loc (loc=0, type=0x755915e8, arg=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/fold-const.c:1893 #2 0x00a09879 in declare_return_variable (fn=0x756a1200) at /mnt/svn/gcc-trunk/gcc/tree-inline.c:2909 #3 expand_call_inline (fn=0x756a1200) at /mnt/svn/gcc-trunk/gcc/tree-inline.c:3927 #4 gimple_expand_calls_inline (fn=0x756a1200) at /mnt/svn/gcc-trunk/gcc/tree-inline.c:4058 #5 optimize_inline_calls (fn=0x756a1200) at /mnt/svn/gcc-trunk/gcc/tree-inline.c:4218 #6 0x01103cab in inline_transform (node=0x75588900) at /mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:369 #7 0x008d4531 in execute_one_ipa_transform_pass () at /mnt/svn/gcc-trunk/gcc/passes.c:1912 #8 execute_all_ipa_transforms () at /mnt/svn/gcc-trunk/gcc/passes.c:1947 #9 0x00a29aa5 in tree_rest_of_compilation (fndecl=0x756a1200) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:413 #10 0x0068d13a in cgraph_expand_function (node=0x75588900) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1819 #11 0x0068f0bc in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1886 #12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2197 #13 0x0068f5ba in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327 #14 0x0057575b in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9940 #15 0x009c8984 in compile_file (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:581 #16 do_compile (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1930 #17 toplev_main (argc=14, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2006 #18 0x76178d2d in __libc_start_main () from /lib64/libc.so.6 #19 0x00559339 in _start () Tested revisions: r181026 - crash r178498 - crash 4.6 r180325 - OK
[Bug fortran/48426] [patch] Quad precision promotion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 --- Comment #16 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-11-07 19:49:39 UTC --- On Mon, Nov 07, 2011 at 07:25:32PM +, inform at tiker dot net wrote: --- Comment #15 from Andreas Kloeckner inform at tiker dot net 2011-11-07 19:25:32 UTC --- Zydrunas and I have successfully completed the copyright assignment process, and we're ready to move forward with this patch. Andreas, that's good news. If you are unaware of the submission policies, here's a short list: 1) Use 'svn diff somefile.diff' to create the patch. The diff format should be unidiff (if possible). 2) Write ChangeLog entries. The ones you may need to worry about are gcc/fortran/ChangeLog, gcc/libgfortran/ChangeLog, and gcc/testsuite/gfortran.dg/ChangeLog. The ChangeLog entries should be separate from the diff. 3) Send the diff, ChangeLog entries, and a description of why and what you have done and how you tested the change to fortran@ and gcc-patc...@gcc.gnu.org.
[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011 --- Comment #2 from dave.anglin at bell dot net 2011-11-07 20:03:43 UTC --- On 11/7/2011 2:27 PM, amacleod at redhat dot com wrote: Is dejagnu on hpux limited somehow That's not the problem. The problem is the atomic functions are not being typed correctly: /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_compare_exchange (first referenced in /var/tmp//cc8Tx8dY.o) (data) The linker is looking for a data symbol.
[Bug libstdc++/51013] New: complex::{imag,real}() should maintain lvalue-returning extension in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013 Bug #: 51013 Summary: complex::{imag,real}() should maintain lvalue-returning extension in C++11 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jyass...@gcc.gnu.org In C++98, libstdc++ has an extension to return T from complexT::real() and ::imag() (introduced in r75680). Paolo removed this extension for C++11 in r135878 citing http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387. However, the point of DR387 was to increase the amount of access complex provides to its internals, not to remove existing extensions providing such access. Removing this extension affects code that passes references to the real or imaginary parts of a complex number to other routines. While such code can generally be rewritten in a straightforward way, it seems like an unnecessary hurdle that should be avoided given all the other changes needed for C++11 compatibility. The DR387-provided reinterpret_cast way of getting access to the addresses would work if we were migrating to C++11 atomically, but that's impossible in a large codebase. I believe the reinterpret_cast produces undefined behavior in C++98 because of the aliasing violation, so we can't use it in code that needs to be correct in both versions of the language. So I think the extension should be reinstated.
[Bug libstdc++/51013] complex::{imag,real}() should maintain lvalue-returning extension in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51013 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|paolo at gcc dot gnu.org|gdr at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-07 21:09:26 UTC --- I did *not* *remove* anything, simply, for C++11, real() and imag() are exactly *per the letter* of the Standard, that is (similarly for the specializations): constexpr _Tp real() const { return _M_real; } constexpr _Tp imag() const { return _M_imag; } and I don't see why we should do something different. But, if Gaby thinks, everything considered, that we want something different, I'm not going to object to patches to that effect (from a technical point of view, note the functions are now constexpr, thus you can't simply have two overloads anymore)
[Bug c/50997] ARM: No warnings for unreachable code for ARM cross compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50997 --- Comment #3 from Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com 2011-11-07 21:11:13 UTC --- Ok, answer to myself. I found the patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00169.html I think the patch is very unfortunate, if I knew I should have objected. It's much better to keep warnings for -O0 level only. I'm thinking of suggesting a patch to restore this warning. /Fredrik
[Bug tree-optimization/51014] New: [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51014 Bug #: 51014 Summary: [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25743 reduced testcase Compiler output: $ gcc -O2 -g -funroll-loops testcase.C testcase.C: In function 'void foo(int)': testcase.C:20:1: internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2283 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x1419378 /mnt/svn/gcc-trunk/gcc/loop-unroll.c, line=2283, function=0x1419c90 apply_opt_in_copies) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x00a19220 in apply_opt_in_copies (opt_info=0x1bcbf30, n_copies=7, unrolling=true, rewrite_original_loop=true) at /mnt/svn/gcc-trunk/gcc/loop-unroll.c:2282 #2 0x00a1b07d in unroll_loop_runtime_iterations (flags=-177191872) at /mnt/svn/gcc-trunk/gcc/loop-unroll.c:1139 #3 unroll_and_peel_loops (flags=-177191872) at /mnt/svn/gcc-trunk/gcc/loop-unroll.c:187 #4 0x00a0aa97 in rtl_unroll_and_peel_loops () at /mnt/svn/gcc-trunk/gcc/loop-init.c:329 #5 0x00a5dfd8 in execute_one_pass (pass=0x196f640) at /mnt/svn/gcc-trunk/gcc/passes.c:2064 #6 0x00a5e345 in execute_pass_list (pass=0x196f640) at /mnt/svn/gcc-trunk/gcc/passes.c:2119 #7 0x00a5e357 in execute_pass_list (pass=0x196f820) at /mnt/svn/gcc-trunk/gcc/passes.c:2120 #8 0x00a5e357 in execute_pass_list (pass=0x196fc00) at /mnt/svn/gcc-trunk/gcc/passes.c:2120 #9 0x00bb334e in tree_rest_of_compilation (fndecl=0x756ebe00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:420 #10 0x00816f8a in cgraph_expand_function (node=0x75587c60) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1819 #11 0x00818f0c in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1886 #12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2197 #13 0x0081940a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327 #14 0x0064022b in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:4046 #15 0x00b521f4 in compile_file (argc=16, argv=0x7fffdab8) at /mnt/svn/gcc-trunk/gcc/toplev.c:581 #16 do_compile (argc=16, argv=0x7fffdab8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1930 #17 toplev_main (argc=16, argv=0x7fffdab8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2006 #18 0x76178d2d in __libc_start_main () from /lib64/libc.so.6 #19 0x00569a99 in _start () Tested revisions: r181102 - crash r181026 - crash r180540 - OK
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-11-07 21:17:28 UTC --- Created attachment 25744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25744 patch for 4.6 I think I'm not going to apply this to release branches, as it's a pretty significant change in behavior, but here's a patch against 4.6 if people want to apply it locally.
[Bug c++/35688] template visibility not overridden by template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2011-11-07 21:17:48 UTC --- Fixed for 4.7.
[Bug regression/50999] [4.7 Regression]: g++.dg/lto/20081109 execute -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50999 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-11-07 21:24:59 UTC --- (In reply to comment #2) Created attachment 25734 [details] proposed patch Hm, on x86_64 the EH table is not empty (look at g++.dg/lto/20081109_1.C, the usual symtom is that the LTOed unit for that file does not contain info to unwind from the throw - can you confirm that?). The key is that lto_init_eh() has to be called for that unit - previously we saved flag_exceptions but now we only save explicit -fexceptions (thus, you can verify if explicitly adding that option to the compile command line fixes the issue). Does the attached patch help? It tries to start to address the (yet unsolved) issue of preserving lang-dependent options. I'll throw this patch to a test session - but I thought you mentioned you have access to powerpc-linux, wouldn't it be more productive for you to debug there?
[Bug c/51015] New: ice in vect_determine_vectorization_factor with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51015 Bug #: 51015 Summary: ice in vect_determine_vectorization_factor with -O3 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 25745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25745 C source code I just tried to compile the package e2fsprogs-1.42-0.5 on latest trunk snapshot 2005 on an AMD x86_64 box. The compiler said pass1.c:543:6: internal compiler error: in vect_determine_vectorization_factor, at tree-vect-loop.c:348 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.