[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #61 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-21 06:20:29 UTC --- On Linux/x86, I got FAIL: gfortran.dg/coarray_lock_3.f90 -O (test for errors, line 72) On x86_64-apple-darwin10 too. The following reduced code does not give the expected error: subroutine lock_test2 use iso_fortran_env implicit none type t end type t type(t) :: x type(lock_type), save :: lock[*],lock2(2)[*] lock(lock) lock(lock2(1)) lock(lock[1]) ! { dg-error must be a scalar coarray of type LOCK_TYPE } ! -- no error end subroutine lock_test2
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #10 from chrbr at gcc dot gnu.org 2011-06-21 06:42:08 UTC --- Author: chrbr Date: Tue Jun 21 06:42:05 2011 New Revision: 175239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175239 Log: PR middle-end/49139 fix always_inline diagnostics Added: trunk/gcc/testsuite/gcc.dg/fail_always_inline.c Modified: trunk/gcc/cgraphunit.c trunk/gcc/ipa-inline-transform.c trunk/gcc/testsuite/g++.dg/ipa/devirt-7.C trunk/gcc/testsuite/gcc.dg/20051201-1.c trunk/gcc/testsuite/gcc.dg/always_inline.c trunk/gcc/testsuite/gcc.dg/always_inline2.c trunk/gcc/testsuite/gcc.dg/always_inline3.c trunk/gcc/testsuite/gcc.dg/debug/pr41264-1.c trunk/gcc/testsuite/gcc.dg/inline-22.c trunk/gcc/testsuite/gcc.dg/lto/20090218-1_0.c trunk/gcc/testsuite/gcc.dg/lto/20090218-1_1.c trunk/gcc/testsuite/gcc.dg/torture/pta-structcopy-1.c trunk/gcc/testsuite/gcc.dg/uninit-pred-5_a.c trunk/gcc/testsuite/gcc.dg/uninit-pred-5_b.c trunk/gcc/tree-inline.c
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #11 from chrbr at gcc dot gnu.org 2011-06-21 06:43:28 UTC --- Author: chrbr Date: Tue Jun 21 06:43:26 2011 New Revision: 175240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175240 Log: PR middle-end/49139 fix always_inline diagnostics Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #12 from chrbr at gcc dot gnu.org 2011-06-21 06:45:09 UTC --- Author: chrbr Date: Tue Jun 21 06:45:05 2011 New Revision: 175241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175241 Log: PR middle-end/49139 PR other/43564 make sure the inline function is inlined Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug other/43564] ICE on code with optimize attribute and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43564 --- Comment #10 from chrbr at gcc dot gnu.org 2011-06-21 06:45:09 UTC --- Author: chrbr Date: Tue Jun 21 06:45:05 2011 New Revision: 175241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175241 Log: PR middle-end/49139 PR other/43564 make sure the inline function is inlined Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #13 from chrbr at gcc dot gnu.org 2011-06-21 06:48:50 UTC --- Author: chrbr Date: Tue Jun 21 06:48:45 2011 New Revision: 175242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175242 Log: PR middle-end/49139 fix always_inline diagnostics Added: trunk/gcc/testsuite/gcc.dg/fail_always_inline2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/inline_1.c trunk/gcc/testsuite/gcc.dg/inline_2.c trunk/gcc/testsuite/gcc.dg/inline_3.c trunk/gcc/testsuite/gcc.dg/inline_4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr40087.c
[Bug c++/49482] New: [regression][4.6.1-RC-20110620][C++0x] unused parameter warning on lambda in function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49482 Summary: [regression][4.6.1-RC-20110620][C++0x] unused parameter warning on lambda in function template Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gintensub...@gmail.com testsuite (bug.cc): templateclass T void f() { []( bool b ){ return b; }; } int main() { fint(); } message: bug.cc: In static member function 'static bool f() [with T = int]::lambda(bool) ::_FUN(bool)': bug.cc:3:4: instantiated from 'f() [with T = int]::lambda(bool)' bug.cc:3:3: instantiated from 'void f() [with T = int]' bug.cc:8:10: instantiated from here bug.cc:3:14: warning: parameter 'b' set but not used [-Wunused-but-set-parameter ] version: gcc-4.6.1-RC-20110620 note: gcc-4.6-20110527 doesn't raise such a warning.
[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-06-21 07:33:15 UTC --- I am testing this patch: Index: tree-vect-loop.c === --- tree-vect-loop.c(revision 175238) +++ tree-vect-loop.c(working copy) @@ -4591,6 +4591,29 @@ vectorizable_reduction (gimple stmt, gim return false; } + /* In case of widenning multiplication by a constant, we update the type + of the constant to be the type of the other operand. We check that the + constant fits the type in the pattern recognition pass. */ + if (code == DOT_PROD_EXPR + !types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1]))) +{ + if (TREE_CODE (ops[0]) == INTEGER_CST) +ops[0] = build_int_cst_wide (TREE_TYPE (ops[1]), +TREE_INT_CST_LOW (ops[0]), +TREE_INT_CST_HIGH (ops[0])); + else if (TREE_CODE (ops[1]) == INTEGER_CST) +ops[1] = build_int_cst_wide (TREE_TYPE (ops[0]), +TREE_INT_CST_LOW (ops[1]), +TREE_INT_CST_HIGH (ops[1])); + else +{ + if (vect_print_dump_info (REPORT_DETAILS)) +fprintf (vect_dump, invalid types in dot-prod); + + return false; +} +} + if (!vec_stmt) /* transformation not required. */ { if (!vect_model_reduction_cost (stmt_info, epilog_reduc_code, ncopies))
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #62 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 07:34:52 UTC --- (In reply to comment #61) FAIL: gfortran.dg/coarray_lock_3.f90 -O (test for errors, line 72) The following reduced code does not give the expected error: lock(lock[1]) ! { dg-error must be a scalar coarray of type LOCK_TYPE } ! Thanks for the report. There are three bugs: a) The code is valid and there should be no dg-error. Seemingly, I forget to apply the update patch for that file. b) The wording of the error message is wrong. As the error message correctly states, lock[1] is *not* a coarray - but no coarray is required. Being coindexed or being the component of a coarray is also sufficient. c) LOCK(a%lock) in the following example is valid, but it is rejected: use iso_fortran_env implicit none type t type(lock_type) :: lock end type t type t2 type(lock_type), allocatable :: lock(:)[:] end type t2 type(t) :: a[*] type(t2) :: b allocate(b%lock(1)[*]) LOCK(a%lock)! FAILS LOCK(a[1]%lock) LOCK(b%lock(1)) LOCK(b%lock(1)[1]) end
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 07:51:34 UTC --- --- gcc/simplify-rtx.c.jj2011-06-08 08:53:15.0 +0200 +++ gcc/simplify-rtx.c2011-06-21 09:46:27.0 +0200 @@ -686,13 +686,13 @@ simplify_unary_operation_1 (enum rtx_cod return simplify_gen_binary (MINUS, mode, temp, XEXP (op, 1)); } - /* (neg (mult A B)) becomes (mult (neg A) B). + /* (neg (mult A B)) becomes (mult A (neg B)). This works even for floating-point values. */ if (GET_CODE (op) == MULT !HONOR_SIGN_DEPENDENT_ROUNDING (mode)) { - temp = simplify_gen_unary (NEG, mode, XEXP (op, 0), mode); - return simplify_gen_binary (MULT, mode, temp, XEXP (op, 1)); + temp = simplify_gen_unary (NEG, mode, XEXP (op, 1), mode); + return simplify_gen_binary (MULT, mode, XEXP (op, 0), temp); } /* NEG commutes with ASHIFT since it is multiplication. Only do stops the moving of the operands around, with this it keeps being called with the same operands again and again, but still an endless recursion. Eric, any preferences where to prevent this from happening?
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-21 08:31:22 UTC --- --- gcc/simplify-rtx.c.jj2011-06-08 08:53:15.0 +0200 +++ gcc/simplify-rtx.c2011-06-21 09:46:27.0 +0200 @@ -686,13 +686,13 @@ simplify_unary_operation_1 (enum rtx_cod return simplify_gen_binary (MINUS, mode, temp, XEXP (op, 1)); } - /* (neg (mult A B)) becomes (mult (neg A) B). + /* (neg (mult A B)) becomes (mult A (neg B)). This works even for floating-point values. */ if (GET_CODE (op) == MULT !HONOR_SIGN_DEPENDENT_ROUNDING (mode)) { - temp = simplify_gen_unary (NEG, mode, XEXP (op, 0), mode); - return simplify_gen_binary (MULT, mode, temp, XEXP (op, 1)); + temp = simplify_gen_unary (NEG, mode, XEXP (op, 1), mode); + return simplify_gen_binary (MULT, mode, XEXP (op, 0), temp); } /* NEG commutes with ASHIFT since it is multiplication. Only do stops the moving of the operands around, with this it keeps being called with the same operands again and again, but still an endless recursion. Eric, any preferences where to prevent this from happening? ISTM that pursuing in the above way, according to swap_commutative_operands_p, is a sensible approach, so I'd remove the simplify_binary_operation_1 bits.
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 08:58:31 UTC --- (In reply to comment #3) I think gfortran's convention is - and also TR 29113 requires - that the addr_expr is not NULL if the variable is allocated - even if it is zero sized. The TR 29113 draft (Interop ML version) has (5.2.3 CFI_cdesc_t) ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1854.pdf void * base addr; If the object is an unallocated allocatable or a pointer that is disassociated, the value is NULL. If the object has zero size, the value is not NULL but is otherwise processor-dependent. Otherwise [...] And trans.c has for gfc_call_malloc: /* Call malloc to allocate size bytes of memory, with special conditions: + if size == 0, return a malloced area of size 1, If one looks at RESHAPE in the library: http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/reshape_generic.c;hb=HEAD one sees: 86 if (ret-data == NULL) 87 { 88 rs = 1; 89 for (n = 0; n rdim; n++) 90 { 91 rex = shape_data[n]; 93 GFC_DIMENSION_SET(ret-dim[n],0,rex - 1,rs); 95 rs *= rex; 96 } 98 ret-data = internal_malloc_size ( rs * size ); Thus, if shape_data[n] == 0 -- which is here the case --, rs == 0 and thus one calls malloc with zero size. POSIX states: If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. Hence, the rs*size should be replaced by MAX(1, rs*size). I think other intrinsics will have the same problem.
[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443 --- Comment #4 from irar at gcc dot gnu.org 2011-06-21 09:01:29 UTC --- Author: irar Date: Tue Jun 21 09:01:23 2011 New Revision: 175246 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175246 Log: PR testsuite/49443 * gcc.dg/vect/vect-peel-3.c: Expect to fail on vect_no_align targets. * gcc.dg/vect/vect-peel-4.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-peel-3.c trunk/gcc/testsuite/gcc.dg/vect/vect-peel-4.c
[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-06-21 09:02:39 UTC --- Fixed.
[Bug tree-optimization/49483] New: unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 Summary: unable to vectorize code equivalent to scalbnf Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch I'm trying to write simplified versions of trigonometric and trascendental functions that gcc can auto-vectorize. at the moment I'm blocked with the vectorization of scalbnf I'm using code equivalent to the one in glibc sysdeps/ieee754/flt-32/s_scalbnf.c and math/math_private.h which in my c++ version reads cat vldexpf.cc inline float i2f(int x) { union { float f; int i; } tmp; tmp.i=x; return tmp.f; } inline float vect_ldexpf(float x, int n) { n =(n+0x7f)23; return x * i2f(n); } float __attribute__ ((aligned(16))) a[1024]; float __attribute__ ((aligned(16))) b[1024]; float __attribute__ ((aligned(16))) c[1024]; void tV() { for (int i=0; i!=1024; ++i) { float z = a[i]; int n = b[i]; c[i] = vect_ldexpf(z,n); } } compiling it produces c++ -Ofast -c vldexpf.cc -msse4.2 -ftree-vectorizer-verbose=7 vldexpf.cc:16: note: vect_model_load_cost: aligned. vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 1, outside_cost = 0. vldexpf.cc:16: note: vect_model_load_cost: aligned. vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 2, outside_cost = 0. vldexpf.cc:16: note: vect_model_store_cost: aligned. vldexpf.cc:16: note: vect_get_data_access_cost: inside_cost = 3, outside_cost = 0. vldexpf.cc:16: note: vect_model_load_cost: aligned. vldexpf.cc:16: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 . vldexpf.cc:16: note: vect_model_load_cost: aligned. vldexpf.cc:16: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 . vldexpf.cc:16: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 1 . vldexpf.cc:16: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 1 . vldexpf.cc:16: note: not vectorized: relevant stmt not supported: D.2243_14 = VIEW_CONVERT_EXPRfloat(n_13); vldexpf.cc:15: note: vectorized 0 loops in function. I'm using c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.7.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto --with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden' Thread model: posix gcc version 4.7.0 20110528 (experimental) (GCC)
[Bug gcov-profile/49484] New: gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 Summary: gcov crash if two(or more) forks happen at the same time Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: cobe...@gmail.com gcov crashes the application if the application forks in multiple threads at the same time. #0 0x003612430265 in raise () from /lib64/libc.so.6 #1 0x003612431d10 in abort () from /lib64/libc.so.6 #2 0x0085e2ae in __gcov_open () #3 0x0085e559 in gcov_exit () #4 0x0085ef7f in __gcov_flush () #5 0x0085f019 in __gcov_fork () #0 0x0085effc in __gcov_merge_add () #1 0x0085ef1a in gcov_exit () #2 0x0085ef7f in __gcov_flush () #3 0x0085f019 in __gcov_fork () gcov (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) uname -a Linux hostname 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se, ||rguenth at gcc dot gnu.org --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 09:04:00 UTC --- It's triggered by the big MEM-REF merge in r161655: Author: rguenth Date: Thu Jul 1 08:49:19 2010 New Revision: 161655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161655 Log: 2010-07-01 Richard Guenther rguent...@suse.de PR middle-end/42834 PR middle-end/44468 * doc/gimple.texi (is_gimple_mem_ref_addr): Document. * doc/generic.texi (References to storage): Document MEM_REF. * tree-pretty-print.c (dump_generic_node): Handle MEM_REF. ...
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 09:24:20 UTC --- gcc-4.1.2 is no longer supported upstream. Please try again with gcc-4.3.5 or newer, preferably gcc-4.6.0 or 4.5.3. Or report this to Red Hat who delivered your 4.1.2-based compiler.
[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.21 09:26:57 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 09:26:57 UTC --- We at the moment only handle sign-changes, but obviously we in principle can handle all VIEW_CONVERT_EXPRs. I'm testing the following, which works for your testcase. Index: gcc/tree-vect-stmts.c === --- gcc/tree-vect-stmts.c (revision 175205) +++ gcc/tree-vect-stmts.c (working copy) @@ -2089,6 +2089,9 @@ vectorizable_assignment (gimple stmt, gi else return false; + if (code == VIEW_CONVERT_EXPR) +op = TREE_OPERAND (op, 0); + if (!vect_is_simple_use_1 (op, loop_vinfo, bb_vinfo, def_stmt, def, dt[0], vectype_in)) { @@ -2099,7 +2102,8 @@ vectorizable_assignment (gimple stmt, gi /* We can handle NOP_EXPR conversions that do not change the number of elements or the vector size. */ - if (CONVERT_EXPR_CODE_P (code) + if ((CONVERT_EXPR_CODE_P (code) + || code == VIEW_CONVERT_EXPR) (!vectype_in || TYPE_VECTOR_SUBPARTS (vectype_in) != nunits || (GET_MODE_SIZE (TYPE_MODE (vectype)) @@ -2134,7 +2138,8 @@ vectorizable_assignment (gimple stmt, gi /* Arguments are ready. create the new vector stmt. */ FOR_EACH_VEC_ELT (tree, vec_oprnds, i, vop) { -if (CONVERT_EXPR_CODE_P (code)) +if (CONVERT_EXPR_CODE_P (code) +|| code == VIEW_CONVERT_EXPR) vop = build1 (VIEW_CONVERT_EXPR, vectype, vop); new_stmt = gimple_build_assign (vec_dest, vop); new_temp = make_ssa_name (vec_dest, new_stmt);
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-21 09:30:32 UTC --- Actually, thinking about it: RESHAPE(allocatable_array, shape) is *not* allocatable. trans-expr.c has: 147 if (!sym-attr.pointer !sym-attr.allocatable 148sym-as sym-as-type == AS_ASSUMED_SHAPE 149(gfc_option.allow_std GFC_STD_F2008) != 0) One probably needs to check the actual argument, i.e. gfc_expr_attr(actual) with allocatable or pointer attribute - or type being C_PTR (including C_NULL_PTR). For the latter: expr-ts.type == BT_DERIVED expr-ts.u.derived expr-ts.u.derived-attr.is_iso_c ??? (some check for ISOCBINDING_PTR)
[Bug target/49480] internal compiler error: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49480 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2011.06.21 09:36:34 Component|c++ |target Ever Confirmed|0 |1 Known to fail||4.1.2, 4.3.5, 4.4.5, 4.5.2, ||4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 09:36:34 UTC --- Confirmed. The code has undefined behavior at runtime.
[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 09:39:47 UTC --- (In reply to comment #2) I am testing this patch: Index: tree-vect-loop.c === --- tree-vect-loop.c(revision 175238) +++ tree-vect-loop.c(working copy) @@ -4591,6 +4591,29 @@ vectorizable_reduction (gimple stmt, gim return false; } + /* In case of widenning multiplication by a constant, we update the type + of the constant to be the type of the other operand. We check that the + constant fits the type in the pattern recognition pass. */ + if (code == DOT_PROD_EXPR + !types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1]))) +{ + if (TREE_CODE (ops[0]) == INTEGER_CST) +ops[0] = build_int_cst_wide (TREE_TYPE (ops[1]), +TREE_INT_CST_LOW (ops[0]), +TREE_INT_CST_HIGH (ops[0])); + else if (TREE_CODE (ops[1]) == INTEGER_CST) +ops[1] = build_int_cst_wide (TREE_TYPE (ops[0]), +TREE_INT_CST_LOW (ops[1]), +TREE_INT_CST_HIGH (ops[1])); + else +{ + if (vect_print_dump_info (REPORT_DETAILS)) +fprintf (vect_dump, invalid types in dot-prod); + + return false; +} +} Please instead simply do if (code == DOT_PROD_EXPR !types_compatible_p (TREE_TYPE (ops[0]), TREE_TYPE (ops[1]))) { if (TREE_CODE (ops[0]) == INTEGER_CST) ops[0] = fold_convert (TREE_TYPE (ops[1]), ops[0]); else if (TREE_CODE (ops[1]) == INTEEGER_CST) ops[1] = fold_convert (TREE_TYPE (ops[0]), ops[1]); + else +{ + if (vect_print_dump_info (REPORT_DETAILS)) +fprintf (vect_dump, invalid types in dot-prod); + + return false; } } Thanks. + if (!vec_stmt) /* transformation not required. */ { if (!vect_model_reduction_cost (stmt_info, epilog_reduc_code, ncopies))
[Bug rtl-optimization/49477] Should have user/debugger-oriented fine-tuning of optimizations available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.21 09:48:59 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 09:48:59 UTC --- Confirmed. We should 1) disable unneeded optimization at -O0 (we do a lot of folding) 2) look at -O1 (it's basically untuned for the last years), make it the intended reasonable optimization with good compile-time and debugging experience again. For -O1 my idea was to simply _only_ do early optimizations, thus drop any IPA optimizations from it and not execute pass_all_optimizations. In addition to that from early optimizations disable pass_sra_early, pass_early_ipa_sra and pass_convert_switch. Eventually insert a DSE pass early (not really sure). It'll of course change fundamentally what code we emit for -O1, but at least we have strong CSE/DCE passes and early inlining that is able to remove C++ abstraction. Patch that will arrive there half-way (eventually needs fixing so we still handle some special builtins): Index: gcc/tree-optimize.c === --- gcc/tree-optimize.c (revision 175205) +++ gcc/tree-optimize.c (working copy) @@ -53,7 +53,7 @@ along with GCC; see the file COPYING3. static bool gate_all_optimizations (void) { - return (optimize = 1 + return (optimize 1 /* Don't bother doing anything if the program has errors. We have to pass down the queue if we already went into SSA */ (!seen_error () || gimple_in_ssa_p (cfun)));
[Bug rtl-optimization/49474] [4.7 Regression] GCC 4.7-20110618 fails to bootstrap on stage 2: gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|bootstrap |rtl-optimization Target Milestone|--- |4.7.0 Summary|GCC 4.7-20110618 fails to |[4.7 Regression] GCC |bootstrap on stage 2: |4.7-20110618 fails to |gcc/fortran/resolve.c:5360: |bootstrap on stage 2: |1: internal compiler error: |gcc/fortran/resolve.c:5360: |vector VEC(edge,base) index |1: internal compiler error: |domain error, in|vector VEC(edge,base) index |find_implicit_sets at |domain error, in |cprop.c:1346|find_implicit_sets at ||cprop.c:1346
[Bug middle-end/49478] ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-06-21 10:03:05 UTC --- OK. Thanks, Ira
[Bug bootstrap/49072] Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 Franck Z franck.z.bugzilla at orange dot fr changed: What|Removed |Added CC||franck.z.bugzilla at orange ||dot fr --- Comment #5 from Franck Z franck.z.bugzilla at orange dot fr 2011-06-21 10:31:45 UTC --- (In reply to comment #4) During my first attempts to compile gcc, I also encountered problem with in-tree compilation of GMP/MPFR/MPC, up to the point that I used the compiled (but not up-to-date) version provided with the Cygwin distribution. It took then place with the trunk. Amont the weird things I observed stood out: - a file gmpxx.h could be found and stopped compilation (with or without --enable-xx flag in gcc's configure script) - the architecture recognized by gmp's configure script was different when this script was launched by me (pentium4--something from what I recall...) or by gcc's makefile. When with gcc's makefile, gmp opted for a cross-compilation for i686-pc-cygwin to none-pc-cygwin - although my gcc build was native. About the architecture point, I can't tell much. But about the gmpxx.h file, I suspect that it is a mostly silent bug and that a file /usr/local/include/gmpxx.h provided by Cygwin is used if present. Apparently, gmp's scripts create a gmp.h file when configure is run, but the gmpxx.h wrapper is copied only when a command make install is issued, so that gcc multi-stage compilation process may not have it, and this as soon as mpfr (or mpc, I can't remember) needs to link to gmp. The failure telling that gmpxx.h was missing occured during a configure script in mpfr (or mpc, again). When the unavailability of gmpxx.h was by-passed by a local installation of gmp from Cygwin, I also got a division by zero error or such later in the build process. I'm trying to confirm it with 4.6.0 release. I've added a choke me line at the beginning of /usr/local/include/gmpxx.h. Right now, the gcc make command is running (it's entered configuring stage 1 in ./gmp). It may take time before I can get an answer. Hope this piece of information is useful. :-) I can't propose a patch for this if it confirms, for want of skills in makefiles as big as gcc's.
[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46350 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-21 10:40:41 UTC --- Try to remove the cast to System.Interrupt_Management.Interrupt_ID in the call.
[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-06-21 10:42:01 UTC --- great! unfortunately gcc-4.7-20110528 $ patch -p0 vect.patch patching file gcc/tree-vect-stmts.c Hunk #1 FAILED at 2089. Hunk #2 FAILED at 2099. Hunk #3 FAILED at 2134. 3 out of 3 hunks FAILED -- saving rejects to file gcc/tree-vect-stmts.c.rej so I edit gcc/tree-vect-stmts.c by hand and worked! vldexpf.cc:16: note: LOOP VECTORIZED. hope it will make it for 4.6.1 :-) I'm will wait that it gets in a snapshot to update all my machines to a new version. v. On 21 Jun, 2011, at 11:26 AM, rguenth at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.21 09:26:57 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 09:26:57 UTC --- We at the moment only handle sign-changes, but obviously we in principle can handle all VIEW_CONVERT_EXPRs. I'm testing the following, which works for your testcase. Index: gcc/tree-vect-stmts.c === --- gcc/tree-vect-stmts.c (revision 175205) +++ gcc/tree-vect-stmts.c (working copy) @@ -2089,6 +2089,9 @@ vectorizable_assignment (gimple stmt, gi else return false; + if (code == VIEW_CONVERT_EXPR) +op = TREE_OPERAND (op, 0); + if (!vect_is_simple_use_1 (op, loop_vinfo, bb_vinfo, def_stmt, def, dt[0], vectype_in)) { @@ -2099,7 +2102,8 @@ vectorizable_assignment (gimple stmt, gi /* We can handle NOP_EXPR conversions that do not change the number of elements or the vector size. */ - if (CONVERT_EXPR_CODE_P (code) + if ((CONVERT_EXPR_CODE_P (code) + || code == VIEW_CONVERT_EXPR) (!vectype_in || TYPE_VECTOR_SUBPARTS (vectype_in) != nunits || (GET_MODE_SIZE (TYPE_MODE (vectype)) @@ -2134,7 +2138,8 @@ vectorizable_assignment (gimple stmt, gi /* Arguments are ready. create the new vector stmt. */ FOR_EACH_VEC_ELT (tree, vec_oprnds, i, vop) { -if (CONVERT_EXPR_CODE_P (code)) +if (CONVERT_EXPR_CODE_P (code) +|| code == VIEW_CONVERT_EXPR) vop = build1 (VIEW_CONVERT_EXPR, vectype, vop); new_stmt = gimple_build_assign (vec_dest, vop); new_temp = make_ssa_name (vec_dest, new_stmt); -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 10:45:20 UTC --- Of course it was. The branch merge allows s to be allocated in registers so we expand from MEM[(T * {ref-all})s + 1B] = x_2(D); and we run into the movmisalign_optab code in expand_assignment which is supported for DImode with the commandline args. But we probably shouldn't try the movmisalign path when the destination is a CONCAT. So something like the following might work (fixes the testcase, otehrwise completely untested) Index: expr.c === --- expr.c (revision 175138) +++ expr.c (working copy) @@ -4122,6 +4122,12 @@ expand_assignment (tree to, tree from, b rtx result; enum machine_mode mode; int align, icode; + enum machine_mode mode1; + HOST_WIDE_INT bitsize, bitpos; + tree offset; + int unsignedp; + int volatilep = 0; + tree tem; /* Don't crash if the lhs of the assignment was erroneous. */ if (TREE_CODE (to) == ERROR_MARK) @@ -4134,9 +4140,18 @@ expand_assignment (tree to, tree from, b if (operand_equal_p (to, from, 0)) return; + tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, +unsignedp, volatilep, true); + + /* If we are going to use store_bit_field and extract_bit_field, + make sure to_rtx will be safe for multiple use. */ + + to_rtx = expand_normal (tem); + mode = TYPE_MODE (TREE_TYPE (to)); - if ((TREE_CODE (to) == MEM_REF - || TREE_CODE (to) == TARGET_MEM_REF) + if (MEM_P (to_rtx) + (TREE_CODE (to) == MEM_REF + || TREE_CODE (to) == TARGET_MEM_REF) mode != BLKmode ((align = MAX (TYPE_ALIGN (TREE_TYPE (to)), get_object_alignment (to, BIGGEST_ALIGNMENT))) @@ -4150,39 +4165,7 @@ expand_assignment (tree to, tree from, b reg = expand_expr (from, NULL_RTX, VOIDmode, EXPAND_NORMAL); reg = force_not_mem (reg); - if (TREE_CODE (to) == MEM_REF) - { - addr_space_t as - = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 1; - tree base = TREE_OPERAND (to, 0); - address_mode = targetm.addr_space.address_mode (as); - op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL); - op0 = convert_memory_address_addr_space (address_mode, op0, as); - if (!integer_zerop (TREE_OPERAND (to, 1))) - { - rtx off - = immed_double_int_const (mem_ref_offset (to), address_mode); - op0 = simplify_gen_binary (PLUS, address_mode, op0, off); - } - op0 = memory_address_addr_space (mode, op0, as); - mem = gen_rtx_MEM (mode, op0); - set_mem_attributes (mem, to, 0); - set_mem_addr_space (mem, as); - } - else if (TREE_CODE (to) == TARGET_MEM_REF) - { - addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (to)); - struct mem_address addr; - - get_address_description (to, addr); - op0 = addr_for_mem_ref (addr, as, true); - op0 = memory_address_addr_space (mode, op0, as); - mem = gen_rtx_MEM (mode, op0); - set_mem_attributes (mem, to, 0); - set_mem_addr_space (mem, as); - } - else - gcc_unreachable (); + mem = to_rtx; if (TREE_THIS_VOLATILE (to)) MEM_VOLATILE_P (mem) = 1; @@ -4211,21 +4194,7 @@ expand_assignment (tree to, tree from, b TREE_CODE (TREE_OPERAND (to, 0)) == ADDR_EXPR) || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE) { - enum machine_mode mode1; - HOST_WIDE_INT bitsize, bitpos; - tree offset; - int unsignedp; - int volatilep = 0; - tree tem; - push_temp_slots (); - tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, -unsignedp, volatilep, true); - - /* If we are going to use store_bit_field and extract_bit_field, -make sure to_rtx will be safe for multiple use. */ - - to_rtx = expand_normal (tem); /* If the bitfield is volatile, we want to access it in the field's mode, not the computed mode.
[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2011-06-21 10:50:14 UTC --- On Tue, 21 Jun 2011, vincenzo.innocente at cern dot ch wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-06-21 10:42:01 UTC --- great! unfortunately gcc-4.7-20110528 $ patch -p0 vect.patch patching file gcc/tree-vect-stmts.c Hunk #1 FAILED at 2089. Hunk #2 FAILED at 2099. Hunk #3 FAILED at 2134. 3 out of 3 hunks FAILED -- saving rejects to file gcc/tree-vect-stmts.c.rej so I edit gcc/tree-vect-stmts.c by hand and worked! vldexpf.cc:16: note: LOOP VECTORIZED. hope it will make it for 4.6.1 :-) Unlikely unless it is a regression ;) It'll make 4.7.0 though if testing succeeds. Richard.
[Bug bootstrap/49072] Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 10:51:55 UTC --- (In reply to comment #5) Apparently, gmp's scripts create a gmp.h file when configure is run, but the gmpxx.h wrapper is copied only when a command make install is issued, so that gcc multi-stage compilation process may not have it, and this as soon as mpfr (or mpc, I can't remember) needs to link to gmp. The failure telling that gmpxx.h was missing occured during a configure script in mpfr (or mpc, again). gmpxx.h is part of the GMP source distribution, it's not generated Hope this piece of information is useful. :-) Not really, if you don't say which versions of GCC and GMP/MFPR/MPC you're using, and your exact configure command, then it's not reproducable or verifiable. It also seems to be completely unrelated to this bug report, which is about segfaults (almost certainly due to faulty hardware) not incorrectly-detected system properties during configuration.
[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 11:02:42 UTC --- Author: rguenth Date: Tue Jun 21 11:02:38 2011 New Revision: 175252 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175252 Log: 2011-06-21 Richard Guenther rguent...@suse.de PR tree-optimization/49483 * tree-vect-stmts.c (vectorizable_assignment): Also handle VIEW_CONVERT_EXPR conversions. * gcc.dg/vect/vect-120.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-120.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/49483] unable to vectorize code equivalent to scalbnf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49483 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 11:03:45 UTC --- Fixed for 4.7.
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 11:24:39 UTC --- I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as my HW is armv5te I can't catch any neon-related runtime regressions. Does anyone else want to do the bootstrap+regtest on more modern HW?
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2011-06-21 11:40:18 UTC --- On Tue, 21 Jun 2011, mikpe at it dot uu.se wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-06-21 11:24:39 UTC --- I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as my HW is armv5te I can't catch any neon-related runtime regressions. Does anyone else want to do the bootstrap+regtest on more modern HW? The patch probably breaks the movmisalign path
[Bug tree-optimization/49478] ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 --- Comment #5 from irar at gcc dot gnu.org 2011-06-21 11:58:36 UTC --- Author: irar Date: Tue Jun 21 11:58:33 2011 New Revision: 175255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175255 Log: PR tree-optimization/49478 * tree-vect-loop.c (vectorizable_reduction): Handle DOT_PROD_EXPR with constant operand. Added: trunk/gcc/testsuite/gcc.dg/vect/pr49478.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-21 12:09:30 UTC --- The question now is what's a clean fix for this issue, rather than hardcoding the result? I've now checked this with native and GNU iconv: feff.utf-8 is the input sequence from iconv_init: od -x feff.utf-8 000 bbef 0abf At first everything seemed to work with both tools, except that I need byte swapping with native iconv, but not with GNU iconv: /usr/bin/iconv -f UTF-8 -t UCS-2 feff.utf-8 | od -x 000 feff 000a /vol/gnu/bin/iconv -f UTF-8 -t UCS-2 feff.utf-8 | od -x 000 fffe 0a00 But when I removed the newline from the input file, results differ: od -x feff.utf-8-nonl 000 bbef 00bf /usr/bin/iconv -f UTF-8 -t UCS-2 feff.utf-8-nonl | od -x 000 feff feff /vol/gnu/bin/iconv -f UTF-8 -t UCS-2 feff.utf-8-nonl | od -x 000 fffe As result, I've simply added a padding NUL byte to the input sequence. This let the iconv succeed and my arraycopy testcase and both md5test and shatest pass. I'm running a full rebuild and check of libjava for good measure. Rainer
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #12 from janus at gcc dot gnu.org 2011-06-21 12:12:58 UTC --- Author: janus Date: Tue Jun 21 12:12:51 2011 New Revision: 175257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175257 Log: 2011-06-21 Janus Weil ja...@gcc.gnu.org PR fortran/49112 * class.c (gfc_find_derived_vtab): Make vtab and default initialization symbols SAVE_IMPLICIT. 2011-06-21 Janus Weil ja...@gcc.gnu.org PR fortran/49112 * gfortran.dg/class_44.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_44.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/49478] ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-06-21 12:14:09 UTC --- Fixed.
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #13 from janus at gcc dot gnu.org 2011-06-21 12:20:33 UTC --- Author: janus Date: Tue Jun 21 12:20:28 2011 New Revision: 175259 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175259 Log: 2011-06-21 Janus Weil ja...@gcc.gnu.org PR fortran/49112 * class.c (gfc_find_derived_vtab): Make vtab and default initialization symbols SAVE_IMPLICIT. 2011-06-21 Janus Weil ja...@gcc.gnu.org PR fortran/49112 * gfortran.dg/class_44.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_44.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/class.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #14 from janus at gcc dot gnu.org 2011-06-21 12:26:44 UTC --- The duplicate save regression is fixed on trunk and 4.6. Remaining problems: 1) The structure constructor regression in comment #6. 2) The ICE in comment #7.
[Bug c++/49485] New: Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 Summary: Performance problem with C++ code Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ism...@namtrac.org Created attachment 24570 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24570 Testcase Attached testcase when compiled with gcc 4.3.4; g++ -O3 -ffast-math -o reduced_dlasr_gcc43 reduced_dlasr.cpp time ./reduced_dlasr_gcc43 ./reduced_dlasr_gcc43 0.15s user 0.00s system 94% cpu 0.168 total When compiled with gcc 4.6; g++ -O3 -ffast-math -o reduced_dlasr_gcc46 reduced_dlasr.cpp time ./reduced_dlasr_gcc46 ./reduced_dlasr_gcc46 0.20s user 0.00s system 99% cpu 0.209 total gcc versions: gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) gcc version 4.6.0 20110607 [gcc-4_6-branch revision 174741] (SUSE Linux)
[Bug c++/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #1 from İsmail cartman Dönmez ismail at namtrac dot org 2011-06-21 12:37:49 UTC --- Test machine has Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz CPU with 8GB of RAM.
[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49442 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 12:43:04 UTC --- Created attachment 24571 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24571 gcc47-builtins.patch Prerequisite patch for __builtin_assume_aligned patch. These are just random things I've noticed when working on that patch.
[Bug target/49423] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-06-21 12:48:36 UTC --- Possibly, yes. I plan to submit a fix for PR49094 this week, please try after that.
[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49442 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 12:50:11 UTC --- Created attachment 24572 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24572 gcc47-assume-aligned.patch Current version of the __builtin_assume_aligned support. On top of the previous patch. Still unfinished areas: 1) vectorizer/data-refs unfortunately ignores the computed alignment, should use get_pointer_alignment/get_object_alignment. 2) it would be nice if the builtin was special cased in the C/C++ FEs and acted like template typename T T __builtin_assume_aligned (T, size_t, ...); (for pointer types only) instead of void *__builtin_assume_aligned (const void *, size_t, ...); 3) testcases need to be added.
[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49442 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 12:50:47 UTC --- Of course something like #c4 is highly desirable independently on this.
[Bug bootstrap/49486] New: [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49486 Summary: [4.7 Regression] Bootstrap failure Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 1752553 gave ../../../src-trunk/libgcc/config/libbid/bid64_mul.c:56:1: internal compiler error: in update_ssa, at tree-into-ssa.c:3245 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [bid64_mul.o] Error 1 ../../../src-trunk/libgcc/config/libbid/bid64_div.c: In function '__bid64_div': ../../../src-trunk/libgcc/config/libbid/bid64_div.c:80:1: internal compiler error: in update_ssa, at tree-into-ssa.c:3245 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [bid64_div.o] Error 1 Revision 175251 is OK.
[Bug bootstrap/49486] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49486 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-21 13:00:54 UTC --- Fixed with rev.175256.
[Bug target/45885] ICE in arm_dbx_register_number, at config/arm/arm.c:22071
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45885 --- Comment #5 from Ryan Mansfield rmansfield at qnx dot com 2011-06-21 13:03:18 UTC --- (In reply to comment #4) (In reply to comment #0) $ ./xgcc -B. -c -O3 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -g ~/ice.i What happens if you do a -mcpu=cortex-a8 ? The ICE doesn't happen if -mcpu=cortex-a8 is specified. I no longer reproduce the ICE on trunk, only the 4.6 branch now. The ICE no longer happens with rev 171649 + 171713 applied.
[Bug c++/49418] openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 13:32:06 UTC --- The problem seems to be that x has T const type before instantiation, but int (without const) after instantiation. The spot where the const is lost is: type = type_decays_to (type); TREE_TYPE (r) = type; cp_apply_type_quals_to_decl (cp_type_quals (type), r); Does C++ really mandate stripping the toplevel qualifiers from the PARM_DECLs here? It isn't stripped from VAR_DECLs. OpenMP 2.5/OpenMP 3.0 says that const qualified parameters and variables are predetermined shared. While it hopefully changes in some way in OpenMP 3.1 (though, the current 3.1 draft wording is likely to change, as it is backwards incompatible with default(none)), for older standards the presence/lack of const makes a big difference.
[Bug c++/49418] openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 13:34:35 UTC --- Perhaps the top-level quals from the older type could be used, if the standard doesn't disallow it? Like, if T const arg is instantiated with T int or const int, it would be int const arg, while if it is T arg instantiated with int or const int, it would be int arg.
[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46350 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 13:38:12 UTC --- Try to remove the cast to System.Interrupt_Management.Interrupt_ID in the call. It fixes the compile error. Testing in progress... Dave
[Bug c++/49418] openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 13:41:19 UTC --- template typename T void f (int const x) { #pragma omp parallel default(none) int y = x; } template typename T void g (int const x) { #pragma omp parallel default(none) shared(x) int y = x; } void h () { fint (0); gint (0); } fails the same way, while after removing template typename T and int the toplevel qualifier stays and it works as expected. If the current C++ FE behavior is mandated by the standard, i.e. toplevel qualifiers must be always dropped from function arguments when in templates and not otherwise, OpenMP C++ support could just ignore TREE_READONLY on PARM_DECLs in templates or something, but it looks very weird to me.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01596.htm ||l Last reconfirmed||2011.06.21 13:58:15 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #15 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 13:58:15 UTC --- Patch posted.
[Bug target/46551] Generate complex addressing mode CMP instruction in x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46551 Dan Gohman dgohman at gmail dot com changed: What|Removed |Added CC||dgohman at gmail dot com --- Comment #2 from Dan Gohman dgohman at gmail dot com 2011-06-21 14:26:23 UTC --- Something has noticed that in the else block, a is equal to the value loaded from vm-cell[vm-index[0] - 2], so it is replacing the use of a and CSE'ing it with the loaded value. That's what causes the loaded value to have multiple uses, which presumably is why GCC subsequently declines to fold the addresssing into the compare.
[Bug c++/49418] openmp default(none) in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.21 14:35:35 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 14:35:35 UTC --- This is a bug, an unintended consequence of the change to type_decays_to.
[Bug c/49487] New: Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Summary: Internal compiler error in AVR code Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: gand...@winds.org CC: eric.wedding...@atmel.com Host: x86_64-unknown-linux-gnu Target: avr-unknown-none Build: x86_64-unknown-linux-gnu Compiling the following function triggers an internal compiler error in (at least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620: unsigned int test(unsigned int *ptr, unsigned int len) { unsigned int sum=0, *p=ptr; while(p ptr+len) sum += ({ unsigned int _x=(*p++); (_x 8) | (_x 8); }); if(__builtin_expect(len 1, 0)) sum += *p; return ~sum; } Compiler command and resulting output: avr-gcc -O3 -Wall -mmcu=atmega644 -c -o test3.o test3.c test3.c: In function 'test': test3.c:12:1: error: could not split insn (insn 40 38 41 (parallel [ (set (reg:HI 20 r20 [92]) (rotate:HI (reg/v:HI 20 r20 [orig:67 _x ] [67]) (const_int 8 [0x8]))) (clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28) (const_int 1 [0x1])) [4 %sfp+1 S1 A8])) ]) test3.c:6 64 {*rotbhi} (nil)) test3.c:12:1: internal compiler error: in final_scan_insn, at final.c:2724 This was compiled using a cross-compiler on an x86_64 system as outlined below: Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-bootstrap --disable-libssp Thread model: single gcc version 4.7.0 20110620 (experimental) (GCC)
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #14 from Steve Ellcey sje at cup dot hp.com 2011-06-21 15:21:44 UTC --- The bootstrap and testing of this patch on IA64 looks good. There were no regressions and it seems to have fixed all the test cases that started breaking on IA64 with the patch to PR 44194. Unfortunately, this patch does not seem to fix PR 49454, the PA bootstrap failure, which also broke at the same time. Perhaps there are some other places where mark_addressable needs to be called?
[Bug c++/49488] New: [C++0x] Use 'final' for devirtualization purposes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488 Summary: [C++0x] Use 'final' for devirtualization purposes Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: paolo.carl...@oracle.com This is an internal reminder for this issue, which I already briefly discussed with Jason in private email and also @ Google GCC Gathering a few days ago, where the issue has been classified by the knowledgeable attendees largely as a c++ front-end one. Link to Vincenzo' message on the gcc mailing list raising explicitly the issue for the first time: http://gcc.gnu.org/ml/gcc/2011-05/msg00319.html
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Component|c |target --- Comment #1 from Eric Weddington eric.weddington at atmel dot com 2011-06-21 15:27:41 UTC --- (In reply to comment #0) Compiling the following function triggers an internal compiler error in (at least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620: Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5? I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled successfully for -O[0123s]. snip This was compiled using a cross-compiler on an x86_64 system as outlined below: Could you try using a 32-bit host?
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 --- Comment #2 from Steve Ellcey sje at cup dot hp.com 2011-06-21 15:48:14 UTC --- I built an hppa2.0w-hp-hpux11.11 compiler with --disable-bootstrap and then ran the test suite to see if I could get a smaller test case. The tests are still running but there are many failures with -O1 and higher levels of optimization. One small example is gcc.c-torture/execute/2717-1.c, which fails during execution at -O1, -O2, -O3, -Os. Here are some other tests that fail at -O1: FAIL: gcc.c-torture/execute/2706-1.c execution, -O1 FAIL: gcc.c-torture/execute/2706-2.c execution, -O1 FAIL: gcc.c-torture/execute/2706-5.c execution, -O1 FAIL: gcc.c-torture/execute/2717-5.c execution, -O1 FAIL: gcc.c-torture/execute/2003-1.c execution, -O1 FAIL: gcc.c-torture/execute/20020215-1.c execution, -O1
[Bug middle-end/49489] New: [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49489 Summary: [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: ja...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: x86_64-linux __builtin_clrsb is broken on x86_64 (and other targets where it is only supported by a library call in DImode).
[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49489 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.21 15:56:01 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug c++/36848] const/nonconst virtual function ambiguity deserves a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36848 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 15:56:26 UTC --- You probably want the -Woverloaded-virtual warning, present for many years. Additionally, G++ 4.7 implements C++0x explicit override control, so you can change your derived classes like so: class A_noconst : public A { public: void sayhi() override { /* ... */ } void saybye() override { /* ... */ } }; class A_const : public A { public: void sayhi() const override { /* ... */ } void saybye() const override { /* ... */ } }; This causes the compiler to reject the program: final.cc:9:8: error: 'void A_noconst::sayhi()' marked override, but does not override final.cc:16:8: error: 'void A_const::saybye() const' marked override, but does not override
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #2 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-21 15:57:50 UTC --- Confirmed for current SVN trunk (r175263). I cannot reproduce it on GCC 4.3.4.
[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17920 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 16:00:11 UTC --- G++ 4.7 supports C++0x explicit override control, so the example can be changed to: struct A { virtual void foo() const; }; struct B : public A { void foo() override; }; And you get: final.cc:2:28: error: 'void B::foo()' marked override, but does not override
[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 16:03:43 UTC --- *cough* PR 46043 *cough*
[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.21 16:10:35 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-21 16:10:35 UTC --- Indeed, Honza suggested that final could be also a c++03 attribute (no idea if he knows about that older PR...)
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 16:12:42 UTC --- G++ 4.7 implements C++0x explicit override control so you can add 'override' class B : public A { B( int y ); ~B(); int f( int x ) override; }; and you'll get an error if it doesn't actually override a virtual function from a base class. It's not *quite* what you want, but you could use it to check whether B::f overrides a virtual (and so you want to add 'virtual' to it) without checking the declaration of A::f
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.21 16:15:37 Ever Confirmed|0 |1
[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-21 16:16:22 UTC --- Last I checked G++ supported 'final' with -std=c++98 -pedantic-errors, I don't know if that's been fixed yet. It's definitely useful to support it in c++98 mode, I don't care whether it's via an attribute or a virt-specifier
[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49489 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 16:26:03 UTC --- Author: jakub Date: Tue Jun 21 16:25:57 2011 New Revision: 175265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175265 Log: PR middle-end/49489 * builtins.c (expand_builtin_unop): Call expand_unop with 0 as unsignedp argument instead of 1 for clrsb_optab. (fold_builtin_bitop): Fix masking for width HOST_BITS_PER_WIDE_INT and 2 * HOST_BITS_PER_WIDE_INT. Optimize BUILT_IN_CLRSB*. (fold_builtin_1): Call fold_builtin_binop for BUILT_IN_CLRSB*. * optabs.c (widen_leading): Call widen_operand and expand_unop with 0 as unsignedp argument instead of 1 for clrsb_optab. (expand_unop): Subtract difference of mode sizes also for clrsb_optab. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/optabs.c
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 --- Comment #3 from Steve Ellcey sje at cup dot hp.com 2011-06-21 16:26:44 UTC --- I should have mentioned in comment #2 that the build and test I did included the proposed patch in comment #11 pf PR 49429.
[Bug libgomp/49490] New: suboptimal load balancing in loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49490 Summary: suboptimal load balancing in loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: dennis.jesper...@nasa.gov Created attachment 24573 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24573 test code to show how a compiler/runtime splits an OpenMP loop The OpenMP runtime library produces a correct but suboptimal load balance in parallel loops. For example, a loop of length 33 with 8 OpenMP threads will give the threads work of lengths 5, 5, 5, 5, 5, 5, 3, 0 respectively. This is logically correct, but imagine a dual-socket 4 core + 4 core configuration; then the left socket has 20 units of work while the right socket has 13 units of work. This could put undue pressure on the left cache(s) and/or memory connection. It would be better to spread out the work as much as possible, so in the example in question the threads would get work of lengths 5, 4, 4, 4, 4, 4, 4, 4. It should be fairly easy to modify libgomp/iter.c to produce the better load balancing (at least I think that's where the modification would go). The attached Fortran code will show the load balance; the Portland Group and Intel products give the desired even balance.
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #16 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 17:10:02 UTC --- Author: ro Date: Tue Jun 21 17:09:57 2011 New Revision: 175266 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175266 Log: PR libgcj/49314 * gnu/gcj/convert/natIconv.cc (iconv_init): Pad in[] with NUL byte. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/gcj/convert/natIconv.cc
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Rainer Orth ro at gcc dot gnu.org 2011-06-21 17:12:26 UTC --- Fixed for 4.7.0.
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 --- Comment #3 from gandalf at winds dot org 2011-06-21 17:17:20 UTC --- (In reply to comment #1) (In reply to comment #0) Compiling the following function triggers an internal compiler error in (at least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620: Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5? I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled successfully for -O[0123s]. snip This was compiled using a cross-compiler on an x86_64 system as outlined below: Could you try using a 32-bit host? Sorry about being vague on the previous GCC versions--I didn't think it mattered that much. I very well could have been using patches from Atmel back then (it was a while ago). I cannot reproduce the problem today on vanilla GCC 4.3.5 and 4.4.6. However I am able to reproduce the problem on 4.5.3 right now too (on a 64-bit host).
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-21 17:23:27 UTC --- I should have mentioned in comment #2 that the build and test I did included the proposed patch in comment #11 pf PR 49429. I assumed so. Richard's comments regarding the patch indicated that it was unlikely to fix all the problems on hppa (a callee copies target). Dave
[Bug middle-end/49491] New: Superflouos move because of unnecessary spill for 2-operand insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49491 Summary: Superflouos move because of unnecessary spill for 2-operand insn. Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization, ra Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr This is an optimization flaw I observe in current 4.7 trunk (r175201) and also in upcoming 4.6.1. This is the C source: unsigned int shift1 (unsigned char x, unsigned char y) { return (x|y) 3; } The machine (AVR) just has 2-operand instructions. It occurs for AVR but presumably is not target-specific and so I chose middle-end as component because reload generates insn 27. Function shift1 gets x in r24, y in r22 and has to return the result in r24 (LSB) and r25 (MSB). The code produced is: shift1: or r22,r24 ; 7iorqi3/1[length = 1] mov r24,r22 ; 27*movqi/1[length = 1] lsr r24 ; 24*lshrqi3/5[length = 3] lsr r24 lsr r24 ldi r25,lo8(0) ; 25*movqi/1[length = 1] ret ; 30return[length = 1] Instead of a simple or r24,r22 there is or r22,r24 mov r24,r22 There is nothing I can see in avr BE that forces this move; iorqi3 insn is commutative and no insn involved needs an (early) clobber. Without the shift, code is as expected: unsigned int or1 (unsigned char x, unsigned char y) { return x|y; } or1: or r24,r22 ; 23iorqi3/1[length = 1] ldi r25,lo8(0) ; 24*movqi/1[length = 1] ret ; 28return[length = 1] === Command line: avr-gcc shr.c -Os -dp -S -v === Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/lto-wrapper Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++ --with-dwarf2 Thread model: single gcc version 4.7.0 20110620 (experimental) (GCC) COLLECT_GCC_OPTIONS='-Os' '-dp' '-S' '-v' /local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/cc1 -quiet -v shr.c -quiet -dumpbase shr.c -dp -auxbase shr -Os -version -o shr.s GNU C (GCC) version 4.7.0 20110620 (experimental) (avr) compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 17:30:57 UTC --- Author: gjl Date: Tue Jun 21 17:30:54 2011 New Revision: 175269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175269 Log: PR target/33049 * config/avr/avr.md (extzv): New expander. (*extzv): New insn. (*extzv.qihi1, *extzv.qihi2): New insn-and-split. * config/avr/constraints.md (C04): New constraint. * doc/md.texi (Machine Constraints): Document it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/constraints.md trunk/gcc/doc/md.texi
[Bug middle-end/49492] New: FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49492 Summary: FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 175263 gave FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O0 FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O1 FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O2 FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -Os Revision 175259 is OK.
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 17:36:35 UTC --- Closing as resolved+fixed according to applied patch.
[Bug middle-end/49492] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49492 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-21 17:39:20 UTC --- This was just fixed. *** This bug has been marked as a duplicate of bug 49489 ***
[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49489 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-21 17:39:20 UTC --- *** Bug 49492 has been marked as a duplicate of this bug. ***
[Bug middle-end/49489] [4.7 Regression] gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49489 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-21 17:46:45 UTC --- Fixed.
[Bug target/29560] [avr] Poor optimization for byte shifts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-21 18:24:44 UTC --- Closing this PR as invalid. As Andy already explained, for shift offsets 7 and 15 there has to be a defined result because int for avr-gcc is 16 bits, and this is actually *not* a byte shift. With alternative code that tested for these offsets at runtime, jumped around and loaded 0 if appropriate, you were not better of than with the current code -- in the contrary. Note that gcc deflates you function calls to just one instruction in main. So maybe what you really want here is to make these functions static inline so that you do no more see the code in the functions. Presumably you always call this functions with compile time constants. If you really need to quench out the last tick and call with non-constants, you could invent inline assembler with an instruction sequence that is similar to (1 (R24 7)), perhaps together with __builtin_constant_p magic: LDI R24, 1 SBRC R24, 1 LDI R24, 4 SBRC R24, 0 LSL R24 SBRC R24, 2 SWAP R24 Note that with -mint8, int is 8 bits. That is still present as option, but no more supported and perhaps non-functional. -- Just for reference; here is a source without external #include: #define PORTC (*((unsigned char volatile*) 53)) void setpin(unsigned char pin, unsigned char val) { if (val == 1) PORTC |= (1pin); else PORTC = ~(1pin); } void setpin1(unsigned char pin, unsigned char val) { const unsigned char one = 1; if (val == 1) PORTC |= (one(pin)); else PORTC = ~(onepin); } int main(void) { setpin(3, 1); setpin1(3, 1); return 0; }
[Bug tree-optimization/49493] New: ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49493 Summary: ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta 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 24574 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24574 reduced testcase Maybe the same as PR41378 Compiler output: $ gcc -O -fipa-pta testcase.c testcase.c:3:1: internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 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=0x11fb598 /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c, line=2637, function=0x11fbe40 insert_vi_for_tree) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00a6ab1b in insert_vi_for_tree (t=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:2637 #2 0x00a6ab32 in associate_varinfo_to_alias_1 (node=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:6694 #3 0x00b314b0 in varpool_for_node_and_aliases (node=0x75901138, callback=0xa6ab20 associate_varinfo_to_alias_1, data=0x18bf820, include_overwritable=1 '\001') at /mnt/svn/gcc-trunk/gcc/varpool.c:757 #4 0x00b3153b in varpool_for_node_and_aliases (node=0x759010d0, callback=0xa6ab20 associate_varinfo_to_alias_1, data=0x18bf820, include_overwritable=1 '\001') at /mnt/svn/gcc-trunk/gcc/varpool.c:765 #5 0x00a77f3c in ipa_pta_execute () at /mnt/svn/gcc-trunk/gcc/tree-ssa-structalias.c:6734 #6 0x0086352e in execute_one_pass (pass=0x16c34c0) at /mnt/svn/gcc-trunk/gcc/passes.c:2023 #7 0x00863c9a in execute_ipa_pass_list (pass=0x16c34c0) at /mnt/svn/gcc-trunk/gcc/passes.c:2390 #8 0x00616cf9 in ipa_passes () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2034 #9 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2069 #10 0x00616eea in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1292 #11 0x004fe6f8 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9844 #12 0x0094e3e4 in compile_file (argc=14, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:587 #13 do_compile (argc=14, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1924 #14 toplev_main (argc=14, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1996 #15 0x76414d2d in __libc_start_main () from /lib64/libc.so.6 #16 0x004e2835 in _start () Tested revisions: r175265 - crash
[Bug c++/49418] [4.6/4.7 regression] G++ discards cv-quals from template parameter types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2 Summary|openmp default(none) in |[4.6/4.7 regression] G++ |template function |discards cv-quals from ||template parameter types --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 18:58:53 UTC --- Changing the summary to reflect the underlying issue.
[Bug c++/49418] [4.6/4.7 regression] G++ discards cv-quals from template parameter types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 19:05:28 UTC --- Author: jason Date: Tue Jun 21 19:05:25 2011 New Revision: 175271 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175271 Log: PR c++/49418 * call.c (cxx_type_promotes_to): Don't strip cv-quals. * semantics.c (lambda_return_type): Strip them here. Added: trunk/gcc/testsuite/g++.dg/template/param3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49418] [4.6 regression] G++ discards cv-quals from template parameter types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49418 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 regression] G++|[4.6 regression] G++ |discards cv-quals from |discards cv-quals from |template parameter types|template parameter types --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 19:07:21 UTC --- Fixed on trunk.
[Bug tree-optimization/49494] New: ICE: in remap_predicate at ipa-inline-analysis.c:1876 with -findirect-inlining -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49494 Summary: ICE: in remap_predicate at ipa-inline-analysis.c:1876 with -findirect-inlining -finline-small-functions 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 24575 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24575 reduced testcase (the same as gfortran.dg/pr49179.f90) Compiler output: $ gcc -O -findirect-inlining -fno-guess-branch-probability -finline-functions -finline-small-functions testcase.f90 testcase.f90:8:0: internal compiler error: vector VEC(int,base) index domain error, in remap_predicate at ipa-inline-analysis.c:1876 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r175265 - crash
[Bug c++/49495] New: -O3 causes error message edge points to wrong declaration:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49495 Summary: -O3 causes error message edge points to wrong declaration: 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 24576 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24576 C++ source code I just tried to compile the icedtea6-1.10.2 package with the latest trunk snapshot 20110618 on an AMD x86_64 box. The compiler said /home/dcb/rpmbuild/BUILD/icedtea6-1.10.2/openjdk/hotspot/src/share/vm/adlc/formssel.cpp:4089:1: error: edge points to wrong declaration: function_decl 0x7ff30ed2d500 _ZN9MatchNodeC2ER8ArchDescRS_i.constprop.30 type method_type 0x7ff30f6f4498 ... Preprocessed source code attached. Flag -O3 required. It compiles fine with -O2.
[Bug fortran/49430] ICE with allocatable length character in interface block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49430 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2011-06-21 19:40:25 UTC --- The same error occurs for the test case in PR 49112 comment 7: module datetime_mod implicit none private type :: DateTime contains procedure :: getFormattedString end type contains function getTimeString(dt, FMT) result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: dt integer, optional, intent(IN) :: FMT string = dt%getFormattedString(2, FMT) end function function getFormattedString(this, FILTER, FMT) result(string) character(:), allocatable :: string class(DateTime), intent(IN) :: this integer, optional, intent(IN) :: FILTER, FMT end function end module c7.f90: In function ‘gettimestring’: c7.f90:18:0: internal compiler error: tree check: expected tree that contains ‘typed’ structure, have ‘’ in fold_convert_loc, at fold-const.c:1859
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.1 Resolution||FIXED --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-21 19:48:22 UTC --- Closing as fixed per: http://gcc.gnu.org/ml/gcc/2011-06/msg00296.html
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target Milestone|4.6.1 |--- --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-21 19:52:28 UTC --- On behalf of Toon Moene (see http://gcc.gnu.org/ml/gcc/2011-06/msg00296.html ) closing as fixed.
[Bug c++/49482] [4.6/4.7 regression][C++0x] unused parameter warning on lambda in function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49482 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.21 19:59:12 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|[regression][4.6.1-RC-20110 |[4.6/4.7 regression][C++0x] |620][C++0x] unused |unused parameter warning on |parameter warning on lambda |lambda in function template |in function template| Ever Confirmed|0 |1
[Bug c++/49482] [4.6/4.7 regression][C++0x] unused parameter warning on lambda in function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49482 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-21 19:59:52 UTC --- This is a minor regression relative to 4.6.0 with a trivial fix I'm testing now.
[Bug tree-optimization/49496] New: [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49496 Summary: [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize 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: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24577 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24577 reduced testcase This still happens after fixing PR49352 Compiler output: $ gcc -O -ftree-vectorize -fcompare-debug testcase.c gcc: error: testcase.c: -fcompare-debug failure (length) Generated code differs a lot with/without -g. Tested revisions: r175265 - fail 4.6 r175269 - OK