[Bug middle-end/51089] New: [4.7 Regression] internal compiler error: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51089 Bug #: 51089 Summary: [4.7 Regression] internal compiler error: verify_flow_info failed Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following testcase ICEs: MODULE xc_tfw INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE tfw_lda_eval ( ) LOGICAL :: failure REAL(KIND=dp), ALLOCATABLE, DIMENSION(:) :: s REAL(KIND=dp), DIMENSION(:, :, :), POINTER :: grho, rho IF (.NOT. failure) THEN IF ( order=2.OR.order==-2 ) THEN CALL tfw_u_2 ( rho, grho, s, error ) END IF CALL cp_a_l(0==1,cp_warning_level,routineP,16) END IF END SUBROUTINE tfw_lda_eval SUBROUTINE tfw_p_3 ( npoints ) !$omp parallel do private(ip) DO ip = 1, npoints END DO END SUBROUTINE tfw_p_3 END MODULE xc_tfw For the following specific set of compile flags gfortran -c -fopenmp -O1 -fexceptions bug.f90 bug.f90: In function ‘tfw_lda_eval’: bug.f90:16:0: error: verify_flow_info: Duplicate edge 16-17 bug.f90:16:0: internal compiler error: verify_flow_info failed Please submit a full bug report, gcc version 4.7.0 2010 (experimental) [trunk revision 181265] (GCC) COLLECT_GCC_OPTIONS='-c' '-fopenmp' '-O2' '-fexceptions' '-v' '-mtune=generic' '-march=x86-64' '-pthread'
[Bug fortran/38115] unneeded temp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Last reconfirmed|2008-11-18 20:11:32 |2011-10-27 20:11:32 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-27 07:06:22 UTC --- 4.7 still generates the temporaries. Looks like the middle end deals with this rather well for the #c0 testcase, but not #c1.
[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-21 05:43:11 UTC --- this is fixed now in trunk, I assume this can be closed.
[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-18 19:19:09 UTC --- OK.. the latest version passes here as well. Let's close as fixed
[Bug middle-end/50754] [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-18 19:22:04 UTC --- No, not quite. With the original commandline I still see a failure here for gcc version 4.7.0 20111018 (experimental) [trunk revision 180161] (GCC)
[Bug fortran/50752] New: [4.7 Regression] ICE in match_kind_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50752 Bug #: 50752 Summary: [4.7 Regression] ICE in match_kind_param Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch This one-liner leads to a segfault in 4.7: vondele@pcihopt3:/data03/vondele/bugs/ice cat bug.f90 rPos=0.0_dp vondele@pcihopt3:/data03/vondele/bugs/ice gfortran bug.f90 f951: internal compiler error: Segmentation fault 60*is_iso_c = sym-attr.is_iso_c; (gdb) bt #0 0x0056db6f in match_kind_param (is_iso_c=0x7fffd51c) at ../../gcc/gcc/fortran/primary.c:60 #1 get_kind (is_iso_c=0x7fffd51c) at ../../gcc/gcc/fortran/primary.c:103 #2 0x0056de7b in match_real_constant (result=0x7fffd660, signflag=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/primary.c:625 #3 0x0056ed6c in gfc_match_literal_constant (result=0x7fffd660, signflag=0) at ../../gcc/gcc/fortran/primary.c:1367 #4 0x0055994e in match_primary (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:149 #5 match_level_1 (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:210 #6 match_mult_operand (result=0x7fffd6c0) at ../../gcc/gcc/fortran/matchexp.c:264 #7 0x00559c3d in match_add_operand (result=0x7fffd718) at ../../gcc/gcc/fortran/matchexp.c:353 #8 0x00559f65 in match_level_2 (result=0x7fffd760) at ../../gcc/gcc/fortran/matchexp.c:477 #9 0x0055a005 in match_level_3 (result=0x7fffd7c0) at ../../gcc/gcc/fortran/matchexp.c:548 #10 0x0055a13a in match_level_4 (result=0x7fffd810) at ../../gcc/gcc/fortran/matchexp.c:596
[Bug middle-end/50754] New: [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50754 Bug #: 50754 Summary: [4.7 Regression] ICE in expand_debug_expr, at cfgexpand.c:3341 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch somewhere in the last 3 days the following regression appeared in trunk: gfortran -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -g -O3 -ffast-math -funroll-loops -ftree-vectorize -ffree-form bug.f90 vec_perm_expr 0x7fcf671e41f8 type vector_type 0x7fcf67110540 type real_type 0x7fcf670aef18 real(kind=8) DF size integer_cst 0x7fcf6709eec0 constant 64 unit size integer_cst 0x7fcf6709eee0 constant 8 align 64 symtab 0 alias set 2 canonical type 0x7fcf670aef18 precision 64 pointer_to_this pointer_type 0x7fcf670bc150 V2DF size integer_cst 0x7fcf670b1400 constant 128 unit size integer_cst 0x7fcf670b1420 constant 16 align 128 symtab 0 alias set 2 canonical type 0x7fcf67110540 nunits 2 pointer_to_this pointer_type 0x7fcf67117c78 arg 0 ssa_name 0x7fcf671d8cd0 type vector_type 0x7fcf67110540 visited var var_decl 0x7fcf671df1e0 vect_var_.27def_stmt vect_var_.27_126 = MEM[(real(kind=8)[3] *)respos + 8B]; version 126 arg 1 ssa_name 0x7fcf671d8cd0 arg 2 vector_cst 0x7fcf671cc5a0 type vector_type 0x7fcf671c1c78 type integer_type 0x7fcf670ae7e0 unsigned V2DI size integer_cst 0x7fcf670b1400 128 unit size integer_cst 0x7fcf670b1420 16 align 128 symtab 0 alias set -1 canonical type 0x7fcf671c1c78 nunits 2 constant elt0: integer_cst 0x7fcf671c6400 constant 1 elt1: integer_cst 0x7fcf670b1300 constant 0 bug.f90:9:0 bug.f90: In function ‘calcbox’: bug.f90:4:0: internal compiler error: in expand_debug_expr, at cfgexpand.c:3341 cat bug.f90 MODULE gauss_colloc INTEGER, PARAMETER :: dp=8 CONTAINS FUNCTION calcBox() RESULT(res) REAL(dp) :: cci0, cci1, cci2, delta_i, m(0:2,0:2), maxr2, r_0, sqDi REAL(dp), DIMENSION(0:2):: l, resPos r_0=0.0_dp DO i=0,2 r_0=r_0-0.5*resPos(2-i)*l(i) END DO cci0 = -((-4.0_dp * m(2,2) * r_0 * m(1,1) + m(2,2) * l(1) ** 2 + l(2) ** 2 * m(1,1) - 2.0_dp * l(1) * m(1,2) * l(2) + 4.0_dp * r_0 * m(1,2) ** 2) / (m(2,2) * m(1,1) - m(1,2) ** 2)) / 4.0_dp-maxr2 delta_i=cci1*cci1-4.0_dp*cci2*cci0 IF (delta_i0.0_dp) THEN imin=fullShift(2)+CEILING((-cci1-sqDi)/(2.0_dp*cci2)) END IF END FUNCTION END MODULE
[Bug libfortran/50673] New: very slow I/O with trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50673 Bug #: 50673 Summary: very slow I/O with trailing spaces Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following testcase (derived from CP2K, which required 20min to read a 600Mb file) is about 100x times slower with gfortran than with ifort (12.0.4) CHARACTER(LEN=40480) :: line=O 0.12456789 0.123456789 0.123456789 CHARACTER(LEN=2) :: AA REAL*8 :: vec(3) DO i=1,1 read(line,*) AA,vec ENDDO END The issue seems related to how efficient the trailing spaces are handled in both compilers. 4.7 is a bit (20%) slower than 4.3, but nothing fundamental. Profiling the code shows that most time is spent in next_char, mem_read, memcpy, eat_spaces.
[Bug libfortran/50673] very slow I/O with trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50673 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-10-09 12:04:55 UTC --- Actually, since eating the trailing spaces is the issue (seems to be implemented very generally in libfortran), the following is a practical workaround in this case: read(line(1:LEN_TRIM(line)),*) AA,vec maybe something along these lines could be done in the runtime ?
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414
Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:
What|Removed |Added
Component|fortran |tree-optimization
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-09-15 09:59:37 UTC ---
Breakpoint 2, internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s),
have %s(%s) in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
833 {
(gdb) bt
#0 internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s), have %s(%s)
in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
#1 0x0079a306 in gimple_check_failed (gs=0x75b58580,
file=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:1156
#2 0x00aa8f9f in gimple_phi_arg (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/gimple.h:3369
#3 gimple_phi_arg_imm_use_ptr (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-flow-inline.h:452
#4 vect_get_constant_vectors (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-vect-slp.c:2013
#5 0x00aab177 in vect_get_slp_defs (op0=0x75b55910, op1=0x0,
slp_node=0x16d5d70, vec_oprnds0=0x7fffd5e8, vec_oprnds1=0x0, reduc_index=2)
at ../../gcc/gcc/tree-vect-slp.c:2145
#6 0x00a983cb in vect_create_epilog_for_reduction
(vect_defs=0x16d6260, stmt=0x75b58580, ncopies=1,
reduc_code=REDUC_MAX_EXPR,
reduction_phis=0x16d66c0, reduc_index=2, double_reduc=false,
slp_node=0x16d5d70) at ../../gcc/gcc/tree-vect-loop.c:3541
#7 0x00a9cf8d in vectorizable_reduction (stmt=0x7fff0001,
gsi=0x7fffd900, vec_stmt=0x7fffd878, slp_node=0x16d5d70)
at ../../gcc/gcc/tree-vect-loop.c:4902
#8 0x00a91805 in vect_transform_stmt (stmt=0x75b58580,
gsi=0x7fffd900, strided_store=0x7fffd8ff, slp_node=0x16d5d70,
slp_node_instance=Unhandled dwarf expression opcode 0xf3
)
at ../../gcc/gcc/tree-vect-stmts.c:5218
#9 0x00aa7b40 in vect_schedule_slp_instance (node=0x16d5d70,
instance=0x16d5ed0, vectorization_factor=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2574
#10 0x00aadbc8 in vect_schedule_slp (loop_vinfo=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2604
#11 0x00aa1a5c in vect_transform_loop (loop_vinfo=0x16ff380) at
../../gcc/gcc/tree-vect-loop.c:5317
#12 0x00aae7e3 in vectorize_loops () at
../../gcc/gcc/tree-vectorizer.c:214
#13 0x00876d37 in execute_one_pass (pass=0x1498f00) at
../../gcc/gcc/passes.c:2063
[Bug tree-optimization/50415] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:03:10 UTC --- #0 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:1267 #1 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:232 #2 0x00a06d10 in find_uses_to_rename_bb (bb=0x77eae7b8, use_blocks=0x16d83c0, need_phis=0x16dfcd0) at ../../gcc/gcc/tree-ssa-loop-manip.c:302 #3 0x00a07506 in find_uses_to_rename (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:331 #4 rewrite_into_loop_closed_ssa (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:391 #5 0x0096bad4 in ldist_gen (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1134 #6 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1216 #7 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1158 #8 0x0096c895 in tree_loop_distribution () at ../../gcc/gcc/tree-loop-distribution.c:1272 #9 0x00876d37 in execute_one_pass (pass=0x1497f40) at ../../gcc/gcc/passes.c:2063 #10 0x008770a5 in execute_pass_list (pass=0x1497f40) at ../../gcc/gcc/passes.c:2118 #11 0x008770b7 in execute_pass_list (pass=0x14990e0) at ../../gcc/gcc/passes.c:2119
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug tree-optimization/50412] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:05:27 UTC --- #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x00aa5fce in vect_do_peeling_for_loop_bound (loop_vinfo=0x16e3870, ratio=0x7fffda58, cond_expr=0x0, cond_expr_stmt_list=0x0) at ../../gcc/gcc/tree-vect-loop-manip.c:1931 #3 0x00aa1c7c in vect_transform_loop (loop_vinfo=0x16e3870) at ../../gcc/gcc/tree-vect-loop.c:5161 #4 0x00aae7e3 in vectorize_loops () at ../../gcc/gcc/tree-vectorizer.c:214 #5 0x00876d37 in execute_one_pass (pass=0x1498f00) at ../../gcc/gcc/passes.c:2063
[Bug fortran/50411] gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- dup fixed *** This bug has been marked as a duplicate of bug 50343 ***
[Bug middle-end/50343] [4.7 Regression] FAIL: gfortran.dg/graphite/id-22.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50343 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #10 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- *** Bug 50411 has been marked as a duplicate of this bug. ***
[Bug fortran/50408] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:40:45 UTC --- a beauty :-) #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x005db4ce in transfer_expr (se=0x7fffd400, ts=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:2156 #3 0x005dfe31 in gfc_trans_transfer (code=0x16cf1e0) at ../../gcc/gcc/fortran/trans-io.c:2305 #4 0x005956b8 in trans_code (code=0x16cf1e0, cond=0x77fef6f0) at ../../gcc/gcc/fortran/trans.c:1397 #5 0x005dd90b in build_dt (function=0x75b4d200, code=0x16cf450) at ../../gcc/gcc/fortran/trans-io.c:1832 #6 0x005dfbfd in gfc_trans_write (code=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:1871 #7 0x005956d8 in trans_code (code=0x16cf450, cond=0x0) at ../../gcc/gcc/fortran/trans.c:1369 #8 0x005b999c in gfc_generate_function_code (ns=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-decl.c:5211 #9 0x005578c7 in translate_all_program_units () at ../../gcc/gcc/fortran/parse.c:4404 #10 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4617 #11 0x00590ac6 in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250
[Bug fortran/50406] ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50405] allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50402] ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug target/38306] [4.4/4.5/4.6/4.7 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #27 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-13 07:59:06 UTC --- (In reply to comment #25) 2) Then find the earliest optimization pass where they differ (you may even use diff to make this faster). The first point where things differ for PD2VAL is pr38306_xxx.f90.057t.cunrolli afterwards, everything seems fully different.
[Bug target/38306] [4.4/4.5/4.6/4.7 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Last reconfirmed|2011-02-20 19:01:16 |2011-09-09 19:01:16 --- Comment #24 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-09 19:06:50 UTC --- checked again current trunk, the situation remains that -O2 is much faster than -O3: gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize pr38306.f90 ; ./a.out Time for evaluation [s]:2.830 gfortran -O3 -march=native -funroll-loops -ffast-math -ftree-vectorize pr38306.f90 ; ./a.out Time for evaluation [s]:4.593 The issue is that at -O3 the subroutine PD2VAL is not vectorized, while it is at -O2.
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-02 07:27:30 UTC --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00052.html
[Bug fortran/50259] New: Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 Bug #: 50259 Summary: Internal Error at (1): gfc_resolve_expr(): Bad expression type Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following invalid code (note the continuation) MODULE cp_parser_types TYPE cp_parser_type CHARACTER(LEN=1) :: comment_character(2), CHARACTER (len=default_path_length), DIMENSION(:,:), POINTER :: initial_variables END TYPE cp_parser_type END MODULE cp_parser_types yields: Internal Error at (1): gfc_resolve_expr(): Bad expression type
[Bug middle-end/50260] New: internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Bug #: 50260 Summary: internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch this started failing in the last 48h or so, with the following stack trace Program received signal SIGSEGV, Segmentation fault. var_map_base_init (map=0x16bb070) at ../../gcc/gcc/tree-ssa-live.c:88 88if (!ann-base_var_processed) (gdb) bt #0 var_map_base_init (map=0x16bb070) at ../../gcc/gcc/tree-ssa-live.c:88 #1 0x009dd3f2 in coalesce_ssa_name () at ../../gcc/gcc/tree-ssa-coalesce.c:1397 #2 0x009909a9 in remove_ssa_form (sa=0x14adce0) at ../../gcc/gcc/tree-outof-ssa.c:909 #3 rewrite_out_of_ssa (sa=0x14adce0) at ../../gcc/gcc/tree-outof-ssa.c:1143 #4 0x0066173b in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:4152 #5 0x0088a3b7 in execute_one_pass (pass=0x149e7e0) at ../../gcc/gcc/passes.c:2063 #6 0x0088a725 in execute_pass_list (pass=0x149e7e0) at ../../gcc/gcc/passes.c:2118 #7 0x0098e01e in tree_rest_of_compilation (fndecl=0x75b49300) at ../../gcc/gcc/tree-optimize.c:420 #8 0x006812c6 in cgraph_expand_function (node=0x77e7fea0) at ../../gcc/gcc/cgraphunit.c:1797 #9 0x0068300b in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1856 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2126 #11 0x0068369a in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1310 #12 0x0083e8fd in write_global_declarations () at ../../gcc/gcc/langhooks.c:303 #13 0x0092bf22 in compile_file (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:564 #14 do_compile (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:1886 #15 toplev_main (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:1962 #16 0x763c5b7d in __libc_start_main () from /lib64/libc.so.6 #17 0x0050317d in _start () at ../sysdeps/x86_64/elf/start.S:113 testcase: MODULE cp_parser_methods INTEGER, PARAMETER :: default_string_length=80 INTEGER, PARAMETER :: default_path_length=250 TYPE ilist_type LOGICAL :: in_use END TYPE ilist_type TYPE cp_parser_type CHARACTER(LEN=default_path_length) :: ifn INTEGER:: icol,icol1,icol2 TYPE(ilist_type), POINTER :: ilist END TYPE cp_parser_type TYPE cp_error_type END TYPE cp_error_type CONTAINS FUNCTION cts(i) RESULT(res) CHARACTER(len=6) :: res END FUNCTION cts FUNCTION parser_location(parser,error) RESULT(res) TYPE(cp_parser_type), POINTER:: parser TYPE(cp_error_type), INTENT(inout) :: error CHARACTER(len=default_path_length+default_string_length) :: res LOGICAL :: failure IF (.NOT. failure) THEN res=file:'//TRIM(parser%ifn)//' line://cts(parser%icol) END IF END FUNCTION parser_location SUBROUTINE parser_get_integer(parser,at_end, error) TYPE(cp_parser_type), POINTER:: parser TYPE(cp_error_type), INTENT(inout) :: error LOGICAL :: failure, my_at_end IF (.NOT.failure) THEN IF (.NOT.parser%ilist%in_use) THEN CALL cp_assert(A// TRIM(parser_location(parser,error))) END IF END IF END SUBROUTINE parser_get_integer SUBROUTINE parser_get_string(parser,at_end,error) TYPE(cp_parser_type), POINTER:: parser LOGICAL, INTENT(out), OPTIONAL :: at_end TYPE(cp_error_type), INTENT(inout) :: error LOGICAL :: failure, my_at_end IF (.NOT.failure) THEN IF (PRESENT(at_end)) THEN CALL cp_assert(s//TRIM(parser_location(parser,error))) END IF END IF END SUBROUTINE parser_get_string END MODULE cp_parser_methods fails at gfortran -O3 bug.f90 compiles at gfortran -O2 bug.f90
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-01 16:03:29 UTC --- (In reply to comment #1) I get with 4.7.0 ([trunk revision 178394]) Internal Error at (1): gfc_is_constant_expr(): Unknown expression type (strangely, I can't reproduce the exact error message I posted earlier )
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-01 16:15:07 UTC --- (In reply to comment #2) (strangely, I can't reproduce the exact error message I posted earlier ) actually could be due to this: ==30794== Invalid read of size 8 ==30794==at 0x577F6A: resolve_fl_derived0(gfc_symbol*) (resolve.c:11575) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a350 is 0 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692) ==30794==by 0x56526C: _ZL10match_wordPKcPF5matchvEP5locus.part.3 (parse.c:70) ==30794==by 0x565A5F: decode_statement() (parse.c:283) ==30794==by 0x5670C4: next_statement() (parse.c:731) ==30794==by 0x5680E5: parse_spec(gfc_statement) (parse.c:2049) ==30794==by 0x56AC3D: gfc_parse_file() (parse.c:4242) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== ==30794== Invalid read of size 4 ==30794==at 0x57B21E: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9662) ==30794==by 0x577F7C: resolve_fl_derived0(gfc_symbol*) (resolve.c:11576) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a378 is 40 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692) ==30794==by 0x56526C: _ZL10match_wordPKcPF5matchvEP5locus.part.3 (parse.c:70) ==30794==by 0x565A5F: decode_statement() (parse.c:283) ==30794==by 0x5670C4: next_statement() (parse.c:731) ==30794==by 0x5680E5: parse_spec(gfc_statement) (parse.c:2049) ==30794==by 0x56AC3D: gfc_parse_file() (parse.c:4242) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== ==30794== Invalid read of size 8 ==30794==at 0x57B240: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9669) ==30794==by 0x577F7C: resolve_fl_derived0(gfc_symbol*) (resolve.c:11576) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a350 is 0 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692
[Bug libgomp/50175] New: data race with barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175 Bug #: 50175 Summary: data race with barrier Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch I'm using valgrind together with the drd tool to find data races in my OMPed code. However, one warning traces back to libgomp, as illustrated by the simple test program below. As instructed in the drd manual, gcc has been configured with --disable-linux-futex Note also that the warning only happens with 3 or more threads. cat test.f90 !$OMP PARALLEL !$OMP BARRIER !$OMP END PARALLEL END gfortran -fopenmp test.f90 export OMP_NUM_THREADS=3 valgrind --tool=drd ./a.out ==12681== drd, a thread error detector ==12681== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==12681== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12681== Command: ./a.out ==12681== ==12681== Conflicting store by thread 1 at 0x0618c28c size 4 ==12681==at 0x53B297D: gomp_team_barrier_wait (bar.h:66) ==12681==by 0x53B1D2E: gomp_team_end (team.c:464) ==12681==by 0x40072A: MAIN__ (in /data03/vondele/bugs/a.out) ==12681==by 0x400760: main (in /data03/vondele/bugs/a.out) ==12681== Address 0x618c28c is at offset 236 from 0x618c1a0. Allocation context: ==12681==at 0x4C29301: malloc (vg_replace_malloc.c:236) ==12681==by 0x53AD018: gomp_malloc (alloc.c:36) ==12681==by 0x53B165C: gomp_new_team (team.c:144) ==12681==by 0x53B078B: GOMP_parallel_start (parallel.c:108) ==12681==by 0x40071B: MAIN__ (in /data03/vondele/bugs/a.out) ==12681==by 0x400760: main (in /data03/vondele/bugs/a.out) ==12681== Other segment start (thread 2) ==12681==at 0x4C31759: sem_wait (drd_pthread_intercepts.c:1010) ==12681==by 0x53B265B: gomp_sem_wait (sem.c:120) ==12681==by 0x53B28DB: gomp_team_barrier_wait_end (bar.c:146) ==12681==by 0x400778: MAIN__._omp_fn.0 (in /data03/vondele/bugs/a.out) ==12681==by 0x53B159F: gomp_thread_start (team.c:115) ==12681==by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281) ==12681==by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5CF082C: clone (in /lib64/libc-2.11.2.so) ==12681== Other segment end (thread 2) ==12681==at 0x5A10EB4: __lll_lock_wait (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5A0C2A3: _L_lock_999 (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5A0C0B8: pthread_mutex_lock (in /lib64/libpthread-2.11.2.so) ==12681==by 0x4C2B7B4: pthread_mutex_lock (drd_pthread_intercepts.c:586) ==12681==by 0x53B2968: gomp_team_barrier_wait (mutex.h:44) ==12681==by 0x53B15AB: gomp_thread_start (team.c:116) ==12681==by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281) ==12681==by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5CF082C: clone (in /lib64/libc-2.11.2.so) ==12681== ==12681== ==12681== For counts of detected and suppressed errors, rerun with: -v ==12681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 31)
[Bug fortran/50129] New: ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 Bug #: 50129 Summary: ICE on where statement Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following (invalid) testcase triggers and ICE: INTEGER :: I(3) WHERE (I2) ELSEWHERE ELSEWHERE (I1) END WHERE END Error: ELSEWHERE statement at (1) follows previous unmasked ELSEWHERE f951: internal compiler error: in gfc_enforce_clean_symbol_state, at fortran/symbol.c:3426
[Bug fortran/50130] New: ICE with invalid array slice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50130 Bug #: 50130 Summary: ICE with invalid array slice Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following triggers an ICE integer, parameter :: a(10)=0 integer, parameter :: b(10)=a(1:10:0) END f951: internal compiler error: Floating point exception Please submit a full bug report,
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 10:17:54 UTC --- (In reply to comment #3) Oh, so it's a sum ... Well, the I suppose you run into the usual array-prefetching compile-time hog. Try -fno-prefetch-loop-arrays. This seems to reduce the time by 5x. On a non-LTO run, this doesn't matter, but I assume LTO makes more info available that triggers some action by that pass.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 14:40:29 UTC --- (In reply to comment #1) Joost, can you point us to a source tarball? Does the issue reproduce with simpler flags (plain -O2 or plain -O3? Esp. w/o -march=native?) CP2K sources are easy, but the to get a version that links, there are additional non-standard dependencies (blas, lapack, libint).
[Bug lto/49700] New: LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Summary: LTO compile time hog Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Using LTO a CP2K compile can take several hours and a lot of memory. I have been able to extract the following time report, but what is the best way to make a testcase ? -save-temps yielded the cp2k.sopt.ltrans29.ltrans.o file, but is anything more needed ? gfortran @/dev/shm/vondele/ccGyXn6S.args Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --with-plugin-ld=ld.gold Thread model: posix gcc version 4.7.0 20110709 (experimental) [trunk revision 176072] (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-ftime-report' '-u' 'se-linker-plugin' '-O3' '-march=native' '-funroll-loops' '-ffast-math' '-ffree-form' '-D' '__GFORTRAN' '-D' '__FFTSG' '-D' '__FFTW3' '-D' '__LIBINT' '-I' '/ext/software/64/gfortran-suite/include' '-D' '__COMPILE_ARCH=gfortran-test13' '-D' '__COMPILE_DATE=Sun Jul 10 14:22:33 CEST 2011' '-D' '__COMPILE_HOST=pcihopt3' '-D' '__COMPILE_LASTCVS=/qs_scf.F/1.527/Sat Jul 9 07:18:08 2011//' '-L/users/vondele/LAPACK/' '-L/ext/software/64/gfortran-suite/lib' '-shared-libgcc' '-dumpdir' '/data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test13/' '-dumpbase' 'cp2k.sopt.ltrans29' '-fltrans' '-o' 'cp2k.sopt.ltrans29.ltrans.o' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto1 -march=amdfam10 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpdir /data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test13/ -dumpbase cp2k.sopt.ltrans29 -auxbase-strip cp2k.sopt.ltrans29.ltrans.o -O3 -version -ftime-report -funroll-loops -ffast-math -ffree-form -fltrans @/dev/shm/vondele/ccuRF1W6 -o cp2k.sopt.ltrans29.s GNU GIMPLE (GCC) version 4.7.0 20110709 (experimental) [trunk revision 176072] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110709 (experimental) [trunk revision 176072], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.7.0 20110709 (experimental) [trunk revision 176072] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110709 (experimental) [trunk revision 176072], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1250 kB ( 0%) ggc phase parsing :5086.93 (100%) usr 9.45 (100%) sys5213.35 (100%) wall 1072513 kB (100%) ggc phase generate : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc garbage collection : 4.16 ( 0%) usr 0.02 ( 0%) sys 4.22 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple in : 0.13 ( 0%) usr 0.01 ( 0%) sys 0.16 ( 0%) wall 26100 kB ( 2%) ggc ipa lto decl in : 0.86 ( 0%) usr 0.01 ( 0%) sys 0.89 ( 0%) wall 7027 kB ( 1%) ggc ipa pure const : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 11 kB ( 0%) ggc cfg construction: 0.62 ( 0%) usr 0.00 ( 0%) sys 0.63 ( 0%) wall 3820 kB ( 0%) ggc cfg cleanup : 2.89 ( 0%) usr 0.00 ( 0%) sys 2.91 ( 0%) wall 4416 kB ( 0%) ggc CFG verifier: 49.95 ( 1%) usr 0.00 ( 0%) sys 50.28 ( 1%) wall 0 kB ( 0%) ggc trivially dead code : 0.88 ( 0%) usr 0.00 ( 0%) sys 0.90 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall 20 kB ( 0%) ggc df multiple defs: 0.34 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc df reaching defs: 60.58 ( 1%) usr 1.10 (12%) sys 62.35 ( 1%) wall 0 kB ( 0%) ggc df live regs: 13.28 ( 0%) usr 0.04 ( 0%) sys 13.56 ( 0%) wall 0 kB ( 0%) ggc df liveinitialized regs: 5.43 ( 0%) usr 0.00 ( 0%) sys 5.59 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.16 ( 0%) usr 0.01 ( 0%) sys 1.25 ( 0%) wall 0 kB ( 0%) ggc df live reg
[Bug lto/49697] New: read permission of LTO intermediate files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49697 Summary: read permission of LTO intermediate files Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch not sure if this is a bug, but LTO generates intermediate files in $TMPDIR that are readable by all -rw-r--r-- cleUTZi.ltrans17.ltrans.o instead of the usual -rw--- for other gcc files that appear in $TMPDIR
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-04 18:57:45 UTC --- patch ;-) Index: gcc/params.def === --- gcc/params.def (revision 175820) +++ gcc/params.def (working copy) @@ -845,7 +845,7 @@ DEFPARAM (PARAM_MAX_VARTRACK_EXPR_DEPTH, max-vartrack-expr-depth, Max. recursion depth for expanding var tracking expressions, - 20, 0, 0) + 12, 0, 0) /* Set minimum insn uid for non-debug insns. */
[Bug fortran/49479] New: [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 Summary: [4.6/4.7 Regression] reshape / optionals / zero sized arrays Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Currently, CP2K seems miscompiled with the 4.6 and 4.7 branches. The following testcase is likely the issue: MODULE M1 IMPLICIT NONE CONTAINS SUBROUTINE S1(data) INTEGER, DIMENSION(:), INTENT(IN), OPTIONAL :: DATA IF (PRESENT(data)) WRITE(6,*) SIZE(data) END SUBROUTINE SUBROUTINE S2(N) INTEGER :: N INTEGER, ALLOCATABLE, DIMENSION(:, :):: blki ALLOCATE(blki(3,N)) blki=0 CALL S1(RESHAPE(blki,(/3*N/))) END SUBROUTINE END MODULE USE M1 CALL S2(0) END whereas gfortran 4.5 prints correctly 0, 4.6/4.7 print nothing.
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-20 20:04:47 UTC --- the difference (I think) seems to be in the present check that has become if (data != 0B (integer(kind=4)[0:] * restrict) data-data != 0B) instead of the original if (data != 0B)
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-09 06:54:33 UTC --- two more datapoints (depth=30 is still running): max-vartrack-expr-depth=22: var-tracking emit :5459.44 (99%) usr max-vartrack-expr-depth=25: var-tracking emit :42078.07 (100%) usr these are the timings for the various -Ox '-g -O0 -fbounds-check' : 14s '-g -O1 -fbounds-check' : 2631s ' -O1 -fbounds-check' : 44s '-g -O2 -fbounds-check' : 43s from this point of view, something at -O2 seems to be very good at cleaning up these very long expressions very cheaply. Would it make sense to run that pass also at -O1 (maybe only when these long expressions are observed) ?
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-08 07:16:06 UTC --- the testcase from http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290 can be used more conveniently. It runs in 1.4s and still spends 50% of time in var-tracking emit. Using callgrind, most of the time is in emit_notes_for_changes, calling htab_traverse.
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-08 13:23:00 UTC --- (In reply to comment #3) Using -g -O2 -fbounds-check instead of -g -O1 -fbounds-check cures it, or e.g. -g -O1 -fbounds-check --param max-vartrack-expr-depth=5 speeds it up. The programming style is very weird, and combined with -fbounds-check which results in huge number of bbs doesn't help it, plus the expression chains for the debug vars really seem to be very long (and at the points where bounds checking failures are reported the relevant registers holding the expressions are reused for something else). Not so sure if I agree with your statement about my programming style ;-). sure timings explode with increasing max-vartrack-expr-depth, maybe the table below can help to pick a good default ? max-vartrack-expr-depth=2: var-tracking emit : 32.66 (33%) usr max-vartrack-expr-depth=3: var-tracking emit : 33.03 (34%) usr max-vartrack-expr-depth=4: var-tracking emit : 33.66 (34%) usr max-vartrack-expr-depth=5: var-tracking emit : 33.64 (34%) usr max-vartrack-expr-depth=6: var-tracking emit : 34.34 (35%) usr max-vartrack-expr-depth=7: var-tracking emit : 35.98 (35%) usr max-vartrack-expr-depth=8: var-tracking emit : 42.52 (37%) usr max-vartrack-expr-depth=9: var-tracking emit : 48.79 (39%) usr max-vartrack-expr-depth=10: var-tracking emit : 53.09 (42%) usr max-vartrack-expr-depth=12: var-tracking emit : 74.52 (46%) usr max-vartrack-expr-depth=14: var-tracking emit : 118.90 (63%) usr max-vartrack-expr-depth=16: var-tracking emit : 313.50 (81%) usr max-vartrack-expr-depth=18: var-tracking emit : 833.84 (91%) usr max-vartrack-expr-depth=20: var-tracking emit :2527.38 (97%) usr
[Bug middle-end/49308] New: [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308 Summary: [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The to-be-reduced-and-attached testcase segfaults today's trunk, while yesterday's one was still fine. Gdb bt leads to: Program received signal SIGSEGV, Segmentation fault. rest_of_handle_ud_dce () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dce.c:518 518 if (DF_REF_IS_ARTIFICIAL (defs-ref)) (gdb) bt #0 rest_of_handle_ud_dce () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dce.c:518 #1 0x00849ce7 in execute_one_pass (pass=0x1397bc0) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/passes.c:1863 #2 0x0084a005 in execute_pass_list (pass=0x1397bc0) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/passes.c:1917 #3 0x0084a01d in execute_pass_list (pass=0x1392f80) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/passes.c:1918 #4 0x00967058 in tree_rest_of_compilation (fndecl=0x77443900) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/tree-optimize.c:417 #5 0x00629e3f in cgraph_expand_function (node=0x77354b90) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/cgraphunit.c:1635 #6 0x0062acd9 in cgraph_optimize () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/cgraphunit.c:1694 #7 0x0062b1ad in cgraph_finalize_compilation_unit () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/cgraphunit.c:1131 #8 0x007f01af in write_global_declarations () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/langhooks.c:303 #9 0x008f49bd in toplev_main (argc=58, argv=0x7fffd418) at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/toplev.c:586 #10 0x778a1586 in __libc_start_main () from /lib64/libc.so.6 #11 0x004a1f09 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-06-07 07:12:14 UTC ---
(In reply to comment #1)
http://gcc.gnu.org/viewcvs?root=gccview=revrev=174699
then. What does:
p *defs
p *defs-ref
say?
strangely
(gdb) list
513 df_ref use = *use_rec;
514 struct df_link *defs;
515 for (defs = DF_REF_CHAIN (use); defs; defs = defs-next)
516 {
517 rtx insn;
518 if (DF_REF_IS_ARTIFICIAL (defs-ref))
519 continue;
520 insn = DF_REF_INSN (defs-ref);
521 if (!marked_insn_p (insn))
522 break;
(gdb) p *defs
No symbol defs in current context.
[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-07 07:33:29 UTC --- (In reply to comment #3) So p (*use_rec)-base.chain ? Program received signal SIGSEGV, Segmentation fault. rest_of_handle_ud_dce () at /data/vondele/gcc_bench/gcc_trunk/gcc/gcc/dce.c:518 518 if (DF_REF_IS_ARTIFICIAL (defs-ref)) (gdb) p (*use_rec)-base.chain No symbol use_rec in current context. No, looks like my gdb doesn't like the code. Is my gdb maybe a bit too old? gdb --version GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-07 07:45:53 UTC --- (In reply to comment #5) Your gdb is very old. Then rm dce.o; make CFLAGS=-g -O0 cc1 cc1plus f951 and retry. upgraded gdb instead (7.2). Now I have: (gdb) p *defs Cannot access memory at address 0xafafafafafafafaf (gdb) p *defs-ref Cannot access memory at address 0xafafafafafafafaf (gdb) p (*use_rec)-base.chain $1 = (struct df_link *) 0xafafafafafafafaf (gdb) p (*use_rec) $2 = (df_ref) 0x1638760
[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-07 08:27:13 UTC --- reduced testcase: gfortran-trunk -c -O2 -funroll-loops -g bug.f90 bug.f90: In function ‘calculate_first_density_matrix’: bug.f90:29:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 MODULE qs_initial_guess TYPE real_matrix_type INTEGER :: sparsity_id END TYPE real_matrix_type TYPE real_matrix_p_type TYPE(real_matrix_type), POINTER :: matrix END TYPE real_matrix_p_type TYPE qs_environment_type TYPE(real_matrix_p_type), DIMENSION(:), POINTER :: matrix_s END TYPE INTEGER, PARAMETER :: default_path_length=250 CONTAINS SUBROUTINE calculate_first_density_matrix() TYPE(qs_environment_type), POINTER :: qs_env CHARACTER(LEN=default_path_length) :: file_name CHARACTER(LEN=default_path_length) :: filename CHARACTER(LEN=default_path_length) :: cp_to_string LOGICAL :: id_equal DO i=1,nvec j = i - 1 IF (j/=0) filename = TRIM(file_name)//.bak-//ADJUSTL(cp_to_string(j)) END DO DO ispin=1, SIZE(qs_env%matrix_s) id_equal=(qs_env%matrix_s(ispin)%matrix%sparsity_id ==qs_env%matrix_s(1)%matrix%sparsity_id) IF(.NOT.(id_equal)) CALL cp_a_l(0==1,cp_failure_level,routineP,39) ENDDO END SUBROUTINE calculate_first_density_matrix END MODULE qs_initial_guess
[Bug middle-end/49310] New: [4.7 Regression] Compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 Summary: [4.7 Regression] Compile time hog Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Created attachment 24456 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24456 testcase The attached testcase requires a very long compile time with current trunk. this requires about 35s (+- OK) gfortran -c -O1 -g hog.f90 this requires 900s gfortran -c -O1 -g -fbounds-check hog.f90 (4.6 branch does better with only 57s in the latter case) The same testcase was discussed (and fixed) in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627 but the issue might be different this time.
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Summary|[4.7 Regression] Compile|[4.7 Regression] Compile |time hog|time hog in var-tracking ||emit --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-07 15:10:48 UTC --- The time report is pretty clear: var-tracking emit :2565.20 (97%) usr 0.08 ( 9%) sys2565.58 (97%) wall 65881 kB ( 8%) ggc TOTAL :2631.33 0.85 2632.52 788209 kB For completeness the full report is below Execution times (seconds) phase setup : 0.03 ( 0%) usr 0.01 ( 1%) sys 0.04 ( 0%) wall 261 kB ( 0%) ggc phase parsing : 1.12 ( 0%) usr 0.06 ( 7%) sys 1.18 ( 0%) wall 45507 kB ( 6%) ggc phase generate:2630.17 (100%) usr 0.78 (92%) sys2631.29 (100%) wall 742440 kB (94%) ggc phase finalize: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc garbage collection: 3.46 ( 0%) usr 0.01 ( 1%) sys 3.47 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 9747 kB ( 1%) ggc callgraph optimization: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 182 kB ( 0%) ggc ipa reference : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc cfg construction : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 140 kB ( 0%) ggc cfg cleanup : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 9 kB ( 0%) ggc CFG verifier : 0.73 ( 0%) usr 0.01 ( 1%) sys 0.81 ( 0%) wall 0 kB ( 0%) ggc trivially dead code : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.29 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall 14 kB ( 0%) ggc df multiple defs : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc df live regs : 0.76 ( 0%) usr 0.00 ( 0%) sys 0.69 ( 0%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.31 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.58 ( 0%) usr 0.01 ( 1%) sys 0.66 ( 0%) wall 8709 kB ( 1%) ggc register information : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.27 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.24 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 10901 kB ( 1%) ggc alias stmt walking: 1.28 ( 0%) usr 0.04 ( 5%) sys 1.22 ( 0%) wall 555 kB ( 0%) ggc register scan : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc parser (global) : 1.12 ( 0%) usr 0.06 ( 7%) sys 1.18 ( 0%) wall 45506 kB ( 6%) ggc inline heuristics : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 86 kB ( 0%) ggc tree gimplify : 0.46 ( 0%) usr 0.03 ( 4%) sys 0.49 ( 0%) wall 59986 kB ( 8%) ggc tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 9046 kB ( 1%) ggc tree CFG cleanup : 0.22 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall 35 kB ( 0%) ggc tree copy propagation : 0.23 ( 0%) usr 0.02 ( 2%) sys 0.21 ( 0%) wall 2267 kB ( 0%) ggc tree find ref. vars : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 5044 kB ( 1%) ggc tree PTA : 0.62 ( 0%) usr 0.05 ( 6%) sys 0.70 ( 0%) wall 1936 kB ( 0%) ggc tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 310 kB ( 0%) ggc tree SSA rewrite : 0.17 ( 0%) usr 0.02 ( 2%) sys 0.22 ( 0%) wall 21049 kB ( 3%) ggc tree SSA other: 0.05 ( 0%) usr 0.02 ( 2%) sys 0.12 ( 0%) wall 22 kB ( 0%) ggc tree SSA incremental : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 817 kB ( 0%) ggc tree operand scan : 0.17 ( 0%) usr 0.10 (12%) sys 0.23 ( 0%) wall 19454 kB ( 2%) ggc dominator optimization: 0.33 ( 0%) usr 0.00 ( 0%) sys 0.39 ( 0%) wall 5073 kB ( 1%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 2.13 ( 0%) usr 0.00 ( 0%) sys 2.13 ( 0%) wall 5999 kB ( 1%) ggc tree PHI const/copy prop
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2011.05.25 06:23:13 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-05-25 06:23:13 UTC --- This patch causes for me: gfortran-trunk -march=native test.f90 f951: error: unrecognized command line option ‘-mno-msse4.2’ in full: gfortran-trunk -v -march=native test.f90 Driving: gfortran-trunk -v -march=native test.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-trunk COLLECT_LTO_WRAPPER=/data/vondele/gcc_bench/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /data/vondele/gcc_bench/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_bench/gcc_trunk/build --enable-languages=c,c++,fortran --program-suffix=-trunk --disable-multilib --disable-bootstrap --with-gmp=/data/vondele/gcc_bench/libs/ --with-mpfr=/data/vondele/gcc_bench/libs/ --with-mpc=/data/vondele/gcc_bench/libs/ Thread model: posix gcc version 4.7.0 20110524 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-march=native' '-shared-libgcc' /data/vondele/gcc_bench/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951 test.f90 -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-msse4.2 -mno-sse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -quiet -dumpbase test.f90 -auxbase test -version -fintrinsic-modules-path /data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/finclude -o /dev/shm/vondele/ccQUXDFx.s f951: error: unrecognized command line option ‘-mno-msse4.2’ /proc/cpuinfo has: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping: 6
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-05-25 11:34:48 UTC --- (In reply to comment #9) Author: jakub Date: Wed May 25 07:12:17 2011 New Revision: 174171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174171 Log: PR target/49128 * config/i386/driver-i386.c (host_detect_local_cpu): Fix a typo. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c FYI, the same bug made it to the 4.6 branch.
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-05-25 13:08:53 UTC --- fixed
[Bug middle-end/49009] New: internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49009 Summary: internal compiler error: verify_gimple failed Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch current trunk fails with gfortran -flto -c bug.f90 bug.f90: In function ‘__min_heap_MOD_heap_pop’: bug.f90:13:0: error: invalid types in truth not logical(kind=4) logical(kind=4) D.1556_3 = !D.1555_2; bug.f90:13:0: internal compiler error: verify_gimple failed cat bug.f90 MODULE min_heap TYPE heap_t INTEGER :: n END TYPE heap_t CONTAINS SUBROUTINE heap_pop (heap, key, value, found, error) TYPE(heap_t), INTENT(INOUT) :: heap LOGICAL, INTENT(OUT) :: found, error IF (.NOT. error .AND. found) THEN IF (heap%n .GT. 1) THEN ENDIF ENDIF END SUBROUTINE heap_pop END MODULE min_heap
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #55 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-26 18:17:52 UTC --- (In reply to comment #54) (In reply to comment #53) reduced testcase for 4.7 Does not fail here - can you still reproduce it? (It might have been fixed by the patch for PR 48588. If it still occurs, I will try harder.) still fails for me with latest trunk (but notice the testcase only fails to compile at -O0 -flto). For completeness, the full -v output for me, might be gold or so related: gfortran -v -O0 -flto t.f90 Driving: gfortran -v -O0 -flto t.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --with-plugin-ld=ld.gold Thread model: posix gcc version 4.7.0 20110426 (experimental) [trunk revision 172980] (GCC) COLLECT_GCC_OPTIONS='-v' '-O0' '-flto' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951 t.f90 -quiet -dumpbase t.f90 -mtune=generic -march=x86-64 -auxbase t -O0 -version -flto -fintrinsic-modules-path /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/finclude -o /dev/shm/vondele/cc5Lcxwt.s GNU Fortran (GCC) version 4.7.0 20110426 (experimental) [trunk revision 172980] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110426 (experimental) [trunk revision 172980], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.7.0 20110426 (experimental) [trunk revision 172980] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110426 (experimental) [trunk revision 172980], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-O0' '-flto' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as --64 -o /dev/shm/vondele/ccHOHV4Q.o /dev/shm/vondele/cc5Lcxwt.s Reading specs from /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-O0' '-flto' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O0' '-flto' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/collect2 -flto --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbegin.o -L/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0 -L/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../.. /dev/shm/vondele/ccHOHV4Q.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtend.o /usr/lib/../lib64/crtn.o gfortran @/dev/shm/vondele/ccrOSrYZ.args Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --with-plugin-ld=ld.gold Thread
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #56 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-26 18:19:29 UTC --- (In reply to comment #54) (In reply to comment #53) reduced testcase for 4.7 Does not fail here - can you still reproduce it? (It might have been fixed by the patch for PR 48588. If it still occurs, I will try harder.) an as a PS, --enable-checking=release also hides the bug.
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #53 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-13 18:47:24 UTC --- reduced testcase for 4.7 MODULE M1 INTEGER, PARAMETER :: dp=8 TYPE realspace_grid_type REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r END TYPE realspace_grid_type TYPE realspace_grid_p_type TYPE(realspace_grid_type), POINTER :: rs_grid END TYPE realspace_grid_p_type TYPE realspaces_grid_p_type TYPE(realspace_grid_p_type), DIMENSION(:), POINTER :: rs END TYPE realspaces_grid_p_type END MODULE MODULE M2 USE M1 CONTAINS SUBROUTINE S1() INTEGER :: i,j TYPE(realspaces_grid_p_type), DIMENSION(:), POINTER :: rs_gauge REAL(dp), DIMENSION(:, :, :), POINTER:: y y=rs_gauge(i)%rs(j)%rs_grid%r END SUBROUTINE END MODULE USE M2 CALL S1() END gfortran -O0 -flto test.f90 In file included from :0:0: test.f90: In function ‘s1’: test.f90:17:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) y = D.2087_27-r; test.f90:17:0: internal compiler error: verify_gimple failed
[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #52 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-12 05:50:45 UTC --- (In reply to comment #51) (In reply to comment #50) The original problem in comment #0 fails (i.e. the build of CP2K) with trunk Could you try to reduce the test case? I will give it a try later this week, but this kind of LTO ICEs are difficult to reduce (starting from ~1MLOC), since it can basically not be done automatically (and the obvious testcase doesn't seem to fail anymore).
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #50 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-05 15:05:52 UTC --- The original problem in comment #0 fails (i.e. the build of CP2K) with trunk 4.7, at what I believe is essentially the same issue. Unfortunately the smaller testcase (comment #1) doesn't fail anymore. In file included from :363:0: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F: In function ‘calculate_jrho_resp’: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F:612:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) # .MEM_3879 = VDEF .MEM_3388 my_gauge = D.66078_1423-r; /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/qs_linres_current.F:612:0: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [/dev/shm/vondele/cciVnmd6.ltrans0.ltrans.o] Error 1 make[3]: Target `all' not remade because of errors. lto-wrapper: make returned 2 exit status /data03/vondele/gnu/binutils-2.21/install/bin/ld.gold: fatal error: lto-wrapper failed collect2: ld returned 1 exit status
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Keywords||wrong-code Known to work||4.5.0 Summary|matmul Segmentation Fault |[4.6/4.7 Regression] matmul |with Allocatable Array |Segmentation Fault with ||Allocatable Array Known to fail||4.6.1, 4.7.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-05 15:38:21 UTC --- so, the segfault is at run time. 4.5 is doing fine. ==14586== Invalid read of size 8 ==14586==at 0x4EC9AD1: _gfortran_matmul_r8 (matmul_r8.c:284) ==14586==by 0x400877: main (in /data03/vondele/bugs/a.out) ==14586== Address 0x0 is not stack'd, malloc'd or (recently) free'd looks like an important issue to me.
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-05 15:40:41 UTC --- somewhat reduced: program main implicit none integer, parameter :: dp = kind(0.0d0) real(kind=dp), allocatable :: a(:,:) real(kind=dp), allocatable :: b(:,:) allocate(a(3,3)) allocate(b(3,3)) a = matmul( matmul( a, b ), b ) ! Segmentation Fault end program main
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.05 15:43:17 Ever Confirmed|0 |1
[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-04 09:06:32 UTC --- (In reply to comment #2) Hi Joost, the following patch hmm triggers 276 times on CP2K, quite a few seems things that also the ME would capture. At least one is a bug in our code :-) I'll see if can figure out the affected file.
[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-04 10:50:57 UTC --- reduced testcase aborts at -O1, goes fine at -O0. Thanks for implementing the warning, without this, it would have been very difficult to find. INTEGER FUNCTION S1(m,ma,lx) INTEGER :: m,ma,lx IF (((m 0).AND.(MODULO(ABS(ma-lx),2) == 1)).OR. ((m 0).AND.(MODULO(ABS(ma-lx),2) == 0))) THEN S1=1 ELSE S1=0 ENDIF END FUNCTION INTEGER :: s1 IF (S1(1,2,1).NE.0) CALL ABORT() END
[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-04 11:49:15 UTC --- the dumped code: __var_2 = __var_1 %[fl] 2; __var_1 = ABS_EXPR *ma - *lx; if (*m 0 __var_2 == 1 || *m 0 __var_2 == 0) shows clearly what is wrong, var_2 is using var_1 before it is used.
[Bug fortran/48412] New: [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412
Summary: [4.7 Regression] CP2K miscompiled due to some Fortran
frontend pass
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@pci.uzh.ch
after the latest fix, CP2K now compiles at -O1, but is miscompiled. Manually
disabling the frontend passes like:
gfc_run_passes (gfc_namespace *ns)
{
if (0 optimize)
{
fixes the issue (and also running at -O0). The compiler was working fine before
the function optimization patch that went in a couple of days ago, so I suspect
that's the cause.
I have no other testcase than compiling CP2K and running an input like
cp2k/tests/QS/H2O.inp.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-01 06:17:51 UTC --- BTW, from this experience, it would be great to have the frontend optimizations being protected by a switch (-f(no-)frontend-optimizations or similar) which can default to true at -O1 and higher. First, this would provide an easy workaround for this kind of bugs. Second, this would make sense in combination with LTO, where in principle one could compile in the first pass with -O0, and only at link time with -Ox (this makes sense from a compile time point of view). However, for this to generate good code, the first pass should be -O0 -ffrontend-optimizations, otherwise the middle end would have no chance.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-03-31 13:25:27 UTC --- reduced: INTEGER, DIMENSION(:), POINTER :: a DO I=1,MIN(SIZE(a),SIZE(a)) ENDDO END
[Bug fortran/48352] New: [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 Summary: [4.7 Regression] segfault in fortran/frontend-passes.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following testcase started failing a couple of days ago: MODULE cp_dbcsr_types TYPE cp_dbcsr_p_type END TYPE cp_dbcsr_p_type CONTAINS SUBROUTINE ep_qs_set(ep_qs_env, dH_coeffs_ptr, dS_coeffs_ptr, error) TYPE(cp_dbcsr_p_type), DIMENSION(:), OPTIONAL, POINTER :: dH_coeffs_ptr, dS_coeffs_ptr DO i=1,MIN(SIZE(dS_coeffs_ptr),SIZE(dS_coeffs_ptr)) END DO END SUBROUTINE ep_qs_set END MODULE with the following segfault. Needs gfortran -O1. Program received signal SIGSEGV, Segmentation fault. gfc_expr_walker (e=0x18, exprfn=0x5bd5b0 cfe_expr_0, data=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:741 741 while (*e) (gdb) bt #0 gfc_expr_walker (e=0x18, exprfn=0x5bd5b0 cfe_expr_0, data=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:741 #1 0x005bdabc in gfc_code_walker (c=0x15082d0, codefn=0x5bc9a0 cfe_code, exprfn=0x5bd5b0 cfe_expr_0, data=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:1039 #2 0x005be73b in optimize_namespace (ns=0x1507ba0) at ../../gcc/gcc/fortran/frontend-passes.c:338 #3 0x005be768 in optimize_namespace (ns=0x1507ba0) at ../../gcc/gcc/fortran/frontend-passes.c:342 #4 0x005be7b3 in gfc_run_passes (ns=0x1503d40) at ../../gcc/gcc/fortran/frontend-passes.c:69 #5 0x0052aee8 in gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4368 #6 0x00564616 in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250 #7 0x0086fa5c in compile_file (argc=15, argv=0x7fffdc88) at ../../gcc/gcc/toplev.c:579 #8 do_compile (argc=15, argv=0x7fffdc88) at ../../gcc/gcc/toplev.c:1900 #9 toplev_main (argc=15, argv=0x7fffdc88) at ../../gcc/gcc/toplev.c:1963 #10 0x7661cb7d in __libc_start_main () from /lib64/libc.so.6 #11 0x004c4e49 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #23 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-21 12:53:30 UTC --- (In reply to comment #22) What is the performance with 4.3 -O2? 4.3: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.373 4.6: gfortran -O2 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.347 so, same performance. Given that vectorization only happens at -O3, it is an important optimization level for numerical codes. Nevertheless, I would propose to remove the regression tag, and instead refocus the bug on the what current trunk does at -O3 vs -O2 -ftree-vectorize as noted in comment #21 gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:2.694 gfortran -O3 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:4.536
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #19 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-20 16:17:33 UTC --- (In reply to comment #18) Hello Joost, could you please check if this is still a problem in GCC 4.6? I think it still is a minor problem, but (without -fschedule-insns) somewhat less pronounced (the old hardware is gone, this might make a difference): 4.3 branch gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns test.f90 ; ./a.out Time for evaluation [s]:3.478 gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.367 4.5 branch gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns test.f90 ; ./a.out Time for evaluation [s]:4.839 gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.524 4.6 branch gfortran -O3 -march=native -funroll-loops -ffast-math -fschedule-insns test.f90 ; ./a.out Time for evaluation [s]:4.997 gfortran -O3 -march=native -funroll-loops -ffast-math test.f90 ; ./a.out Time for evaluation [s]:4.547 FYI: -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm model name : AMD Opteron(tm) Processor 6176 SE
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #20 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-20 16:28:00 UTC --- additionally for trunk, lto/profile-use seem not to help: gfortran -O3 -march=native -funroll-loops -ffast-math -flto -fprofile-use test.f90 ; ./a.out Time for evaluation [s]:4.664 gfortran -O3 -march=native -funroll-loops -ffast-math -fprofile-use test.f90 ; ./a.out Time for evaluation [s]:4.665
[Bug target/38306] [4.4/4.5/4.6 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306 --- Comment #21 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-20 16:32:38 UTC --- ... however, the following works great: gfortran -O2 -march=native -funroll-loops -ffast-math -ftree-vectorize test.f90 ; ./a.out Time for evaluation [s]:2.700 (notice -O2 instead of -O3, -O2 is thus twice as fast as -O3)
[Bug tree-optimization/47657] New: missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657 Summary: missed vectorization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch the following is not vectorized with gfortran (4.6 / 4.5) gfortran -O3 -ffast-math -ftree-vectorizer-verbose=6 -S -march=native ( -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm ) SUBROUTINE smm_dnn_8_8_8_4_1_2_1(A,B,C) REAL(KIND=8) :: C(8,8), B(8,8), A(8,8) INTEGER ::i,j,l DO j= 1 , 8 , 2 DO l= 1 , 8 , 1 DO i= 1 , 8 , 1 C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+0)*B(l+0,j+1) ENDDO ENDDO ENDDO END SUBROUTINE while the cray ftn compiler does, yielding about twice the speed. reference asm: smm_dnn_8_8_8_4_1_2_1_: 0: 53 push %rbx 1: 48 89 7c 24 f8 mov%rdi,-0x8(%rsp) 6: 48 89 74 24 f0 mov%rsi,-0x10(%rsp) b: 48 89 54 24 e8 mov%rdx,-0x18(%rsp) 10: 31 c0 xor%eax,%eax 12: 48 89 d1mov%rdx,%rcx 15: 49 89 c0mov%rax,%r8 18: 49 89 c1mov%rax,%r9 1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 20: 66 0f 10 04 02 movupd (%rdx,%rax,1),%xmm0 25: 66 0f 10 4c 02 40 movupd 0x40(%rdx,%rax,1),%xmm1 2b: 66 0f 10 54 02 10 movupd 0x10(%rdx,%rax,1),%xmm2 31: 66 0f 10 5c 02 50 movupd 0x50(%rdx,%rax,1),%xmm3 37: 66 0f 10 64 02 20 movupd 0x20(%rdx,%rax,1),%xmm4 3d: 66 0f 10 6c 02 60 movupd 0x60(%rdx,%rax,1),%xmm5 43: 66 0f 10 74 02 30 movupd 0x30(%rdx,%rax,1),%xmm6 49: 66 0f 10 7c 02 70 movupd 0x70(%rdx,%rax,1),%xmm7 4f: 45 31 d2xor%r10d,%r10d 52: 4d 89 d3mov%r10,%r11 55: 66 66 2e 0f 1f 84 00nopw %cs:0x0(%rax,%rax,1) 5c: 00 00 00 00 60: 66 46 0f 10 44 1f 30movupd 0x30(%rdi,%r11,1),%xmm8 67: 4b 8d 1c 02 lea(%r10,%r8,1),%rbx 6b: f2 44 0f 12 4c de 40movddup 0x40(%rsi,%rbx,8),%xmm9 72: 66 45 0f 28 d1 movapd %xmm9,%xmm10 77: 66 45 0f 59 d0 mulpd %xmm8,%xmm10 7c: 66 41 0f 58 fa addpd %xmm10,%xmm7 81: f2 44 0f 12 14 de movddup (%rsi,%rbx,8),%xmm10 87: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 8c: 66 41 0f 58 f0 addpd %xmm8,%xmm6 91: 66 46 0f 10 44 1f 20movupd 0x20(%rdi,%r11,1),%xmm8 98: 66 45 0f 28 d9 movapd %xmm9,%xmm11 9d: 66 45 0f 59 d8 mulpd %xmm8,%xmm11 a2: 66 41 0f 58 eb addpd %xmm11,%xmm5 a7: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 ac: 66 41 0f 58 e0 addpd %xmm8,%xmm4 b1: 66 46 0f 10 44 1f 10movupd 0x10(%rdi,%r11,1),%xmm8 b8: 66 45 0f 28 d9 movapd %xmm9,%xmm11 bd: 66 45 0f 59 d8 mulpd %xmm8,%xmm11 c2: 66 41 0f 58 db addpd %xmm11,%xmm3 c7: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 cc: 66 41 0f 58 d0 addpd %xmm8,%xmm2 d1: 66 46 0f 10 04 1f movupd (%rdi,%r11,1),%xmm8 d7: 66 45 0f 59 c8 mulpd %xmm8,%xmm9 dc: 66 41 0f 58 c9 addpd %xmm9,%xmm1 e1: 66 45 0f 59 d0 mulpd %xmm8,%xmm10 e6: 66 41 0f 58 c2 addpd %xmm10,%xmm0 eb: 49 83 c3 40 add$0x40,%r11 ef: 49 ff c2inc%r10 f2: 49 83 fa 08 cmp$0x8,%r10 f6: 0f 8c 64 ff ff ff jl 60 smm_dnn_8_8_8_4_1_2_1_+0x60 fc: f2 0f 11 7c 01 70 movsd %xmm7,0x70(%rcx,%rax,1) 102: 66 0f 17 7c 01 78 movhpd %xmm7,0x78(%rcx,%rax,1) 108: f2 0f 11 74 02 30 movsd %xmm6,0x30(%rdx,%rax,1) 10e: 66 0f 17 74 02 38 movhpd %xmm6,0x38(%rdx,%rax,1) 114: f2 0f 11 6c 02 60 movsd %xmm5,0x60(%rdx,%rax,1) 11a: 66 0f 17 6c 02 68 movhpd %xmm5,0x68(%rdx,%rax,1) 120: f2 0f 11 64 02 20 movsd %xmm4,0x20(%rdx,%rax,1) 126: 66 0f 17 64 02 28 movhpd %xmm4,0x28(%rdx,%rax,1) 12c: f2 0f 11 5c 02 50 movsd %xmm3,0x50(%rdx,%rax,1) 132: 66 0f 17 5c 02 58 movhpd %xmm3,0x58(%rdx,%rax,1) 138: f2 0f 11 54 02 10 movsd %xmm2,0x10(%rdx,%rax,1) 13e: 66 0f 17 54 02 18 movhpd %xmm2,0x18(%rdx,%rax,1) 144: f2 0f 11 4c 02 40 movsd %xmm1,0x40(%rdx,%rax,1) 14a: 66 0f 17 4c 02 48 movhpd %xmm1,0x48(%rdx,%rax,1) 150: f2 0f 11 04 02 movsd %xmm0,(%rdx,%rax,1) 155: 66 0f 17 44 02 08 movhpd %xmm0,0x8(%rdx,%rax,1) 15b: 49 83 c0 10 add$0x10,%r8 15f: 48 83 e8 80 sub$0xff80,%rax 163: 49 ff c1inc%r9 166: 49 83 f9 04 cmp$0x4,%r9 16a: 0f 8c b0 fe ff ff
[Bug tree-optimization/47657] missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-09 11:25:42 UTC --- Created attachment 23283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23283 testcase including timing routine, last number is flop rate. the cray compiler is supposed to *not* interchange loops, as I'm using: ftn -O3,ipa0,nointerchange,vector3 testcase.f90 to compile. This gives about 5.6Gflops. Unrolling still seems to happen (there are 16 mults in the inner loop), and ftn -O3,ipa0,nointerchange,vector3,unroll0 testcase.f90 yields poor performance (2.3Gflops). Gfortran 4.5 yields 3.424Gflops : gfortran -O3 -ffast-math -funroll-loops -march=native testcase.f90
[Bug rtl-optimization/38403] unable to find a register to spill in class ‘CREG’ with -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-07 18:15:26 UTC --- seems to work with 4.5 and 4.6 now.
[Bug middle-end/47566] New: ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 Summary: ICE in vn_reference_lookup Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch current trunk fails with ICE compiling with LTO cp2k. /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto1 -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpdir /data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test24/ -dumpbase cp2k.sopt.ltrans1 -auxbase-strip cp2k.sopt.ltrans1.ltrans.o -O3 -version -ffree-form -funroll-loops -ffast-math -fuse-linker-plugin -fltrans cp2k.sopt.ltrans1.o -o cp2k.sopt.ltrans1.s -v GNU GIMPLE (GCC) version 4.6.0 20110201 (experimental) [trunk revision 169466] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110201 (experimental) [trunk revision 169466], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 4.6.0 20110201 (experimental) [trunk revision 169466] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110201 (experimental) [trunk revision 169466], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file included from :520:0: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/fft_tools.F: In function ‘fft3d_pb’: /data03/vondele/cp2k_gcc/cp2k/makefiles/../src/fft_tools.F:994:0: internal compiler error: Segmentation fault in gdb I get Program received signal SIGSEGV, Segmentation fault. 0x0079583b in vn_reference_lookup (op=0x7fffef4a4460, vuse=0x7532eb40, kind=VN_WALK, vnresult=0x0) at ../../gcc/gcc/tree-ssa-sccvn.c:1543 1543 vr1.vuse = vuse ? SSA_VAL (vuse) : NULL_TREE; (gdb) bt #0 0x0079583b in vn_reference_lookup (op=0x7fffef4a4460, vuse=0x7532eb40, kind=VN_WALK, vnresult=0x0) at ../../gcc/gcc/tree-ssa-sccvn.c:1543 #1 0x00787a0c in eliminate () at ../../gcc/gcc/tree-ssa-pre.c:4331 #2 0x0078a2a5 in execute_pre (do_fre=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:4901 #3 execute_pre (do_fre=0 '\000') at ../../gcc/gcc/tree-ssa-pre.c:4845 #4 0x0064fdb9 in execute_one_pass (pass=0x10968c0) at ../../gcc/gcc/passes.c:1561 #5 0x00650065 in execute_pass_list (pass=0x10968c0) at ../../gcc/gcc/passes.c:1616 #6 0x00650077 in execute_pass_list (pass=0x10957e0) at ../../gcc/gcc/passes.c:1617 #7 0x0071b481 in tree_rest_of_compilation (fndecl=0x75c2ff00) at ../../gcc/gcc/tree-optimize.c:422 #8 0x0085884f in cgraph_expand_function (node=0x754599a0) at ../../gcc/gcc/cgraphunit.c:1563 #9 0x0085a46a in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1622 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1882 #11 0x004b9fdf in lto_main () at ../../gcc/gcc/lto/lto.c:2457 details of gfortran -v: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --enable-gold --enable-checking=release Thread model: posix gcc version 4.6.0 20110201 (experimental) [trunk revision 169466] (GCC)
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 09:42:12 UTC --- gzipped testcase (2.7Mb) downloadable from http://www.pci.uzh.ch/vandevondele/tmp/cp2k.sopt.ltrans1.o.gz
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:04:46 UTC --- (In reply to comment #2) I think we need source code (LTO bytecode isn't really portable). oops... that's building CP2K. Let me see if I can reproduce this with this night's tarball. (gdb) call debug_tree (vuse) at that point? (gdb) call debug_tree (vuse) var_decl 0x7532eb40 .MEM type void_type 0x77e84d20 void VOID align 8 symtab 0 alias set -1 structural equality pointer_to_this pointer_type 0x77e84dc8 used static external VOID file built-in line 0 col 0 align 8
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:23:35 UTC --- (In reply to comment #4) That's indeed invalid - it should be an SSA name. This means some earlier pass messed up (or PRE itself). The bug shouldn't depend on LTO (apart from maybe requiring some cross-module inlining to trigger). The same problem doesn't happen without LTO (but otherwise compiled with the same options). I guess it needs the cross-module inlining. I'll be uploading a tgz with sources.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 12:29:36 UTC --- to reproduce from sources wget http://www.pci.uzh.ch/vandevondele/tmp/cp2k.tgz tar -xzvf cp2k.tgz cd cp2k/makefiles make -j ARCH=gfortran-test24 VERSION=sopt this assumes that you have lapack and blas installed etc. The file cp2k/arch/gfortran-test24.sopt can be changed to modify compile options (or directories for lapack/blas). With make -j ARCH=gfortran-test24 VERSION=sopt distclean a new build can be started from scratch
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 14:53:44 UTC --- (In reply to comment #7) Hm, you are using -O0 for the compile and -O3 ... for the link step? Should work in theory, but of course isn't tested thoroughly. Right :-) I'm trying to test this thoroughly... seems like a useful trick to speedup parallel builds of Fortran programs (quick -O0 build to satisfy module dependencies, massively parallel and thus hopefully fast lto without the dependencies).
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 15:52:42 UTC --- (In reply to comment #9) In file included from :425:0: /tmp/cp2k/makefiles/../src/realspace_grid_types.F: In function 'rs_pw_transfer_replicated': /tmp/cp2k/makefiles/../src/realspace_grid_types.F:816:0: error: non-trivial conversion at assignment yes, that is PR45586. Can be worked around with either release checking (which I have enable right now) or changing src/realspace_grid_types.F to use REAL(KIND=dp), DIMENSION ( :, :, : ), POINTER :: r ! the grid instead of REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r ! the grid The following fixes the ICE for me: cool.
[Bug middle-end/47566] ICE in vn_reference_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566 --- Comment #12 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-01 21:00:18 UTC --- The patch from comment #9 allows a release checking compiler to build CP2K with LTO.
[Bug middle-end/47048] misc vect.exp failures with -fgraphite-identity enabled at -O2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47048 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-02 07:42:22 UTC --- (In reply to comment #4) More specifically, the code that is now confused by the (int) cast There might be overlap with PR47341 (also casts that confuse dependency info)?
[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47522 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-31 10:16:24 UTC --- (In reply to comment #2) Target piece, if there is one. PR44183 for the vectorizer piece, if there is one. I'm almost certain that this is a dup of PR44183. As far as I can judge, the result of the calculation is indeed correct. The annoying thing is that this makes valgrind's 'out of bounds checking' kind of useless.
[Bug target/47522] [4.4/4.5/4.6 Regression] wrong code at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47522 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-31 11:17:46 UTC --- (In reply to comment #5) valgrind sucks (maybe report this to them). I think this is an unnecessary comment (all useful tools have bugs, or features we don't like). The issue has been reported as https://bugs.kde.org/show_bug.cgi?id=264936
[Bug lto/47532] New: valgrind errors while compiling with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47532 Summary: valgrind errors while compiling with -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Created attachment 23162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23162 testcase, compile under valgrind to see error ==5789== Conditional jump or move depends on uninitialised value(s) ==5789==at 0xC5E14A: longest_match (deflate.c:1140) ==5789==by 0xC5E6F1: deflate_slow (deflate.c:1595) ==5789==by 0xC5F5F0: deflate (deflate.c:790) ==5789==by 0xB931B1: lto_end_compression (lto-compress.c:195) ==5789==by 0xB90F34: lto_end_section (lto-section-out.c:148) ==5789==by 0xB9146E: lto_destroy_simple_output_block (lto-section-out.c:512) ==5789==by 0xB83FE9: output_cgraph (lto-cgraph.c:1008) ==5789==by 0xB900B5: lto_output (lto-streamer-out.c:2252) ==5789==by 0x7236E2: ipa_write_summaries_2 (passes.c:1648) ==5789==by 0x723EE5: ipa_write_summaries (passes.c:1678) ==5789==by 0x92E4A9: cgraph_optimize (cgraphunit.c:1797) ==5789==by 0x92E5C9: cgraph_finalize_compilation_unit (cgraphunit.c:1083) compile the attached testcase with valgrind --tool=memcheck --trace-children=yes gfortran -flto -c test.f90 -v details : sing built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --enable-gold --enable-checking=release Thread model: posix gcc version 4.6.0 20110128 (experimental) [trunk revision 169358] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-flto' '-mtune=generic' '-march=x86-64' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test -version -flto -fintrinsic-modules-path /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /dev/shm/vondele/ccfZ59wz.s GNU Fortran (GCC) version 4.6.0 20110128 (experimental) [trunk revision 169358] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110128 (experimental) [trunk revision 169358], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.0 20110128 (experimental) [trunk revision 169358] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110128 (experimental) [trunk revision 169358], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-c' '-flto' '-mtune=generic' '-march=x86-64' as --64 -o test.o /dev/shm/vondele/ccfZ59wz.s COMPILER_PATH=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-c' '-flto' '-mtune=generic' '-march=x86-64'
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:02:01 UTC --- (In reply to comment #4) For starters it would be nice if gfortran would even document its precise semantics for when module files are created/updated/etc. I'm sure these semantics are not identical across Fortran compilers. This is PR 42607. These semantics are definitely not identical across compilers, most compilers will always write a .mod if a module is compiled (but some generate even no .mod files or use .MOD or whatever, there is nothing in the Fortran standard that talks about .mod files). However, for me personally, not updating .mod files if they are not changed (and hence providing a way to avoid recompilation cascades) was one of the most important reasons to start using gfortran. It can make development (recompilation) tens of times faster. So, this is absolute a feature to retain in my opinion.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:14:26 UTC --- (In reply to comment #6) I think it would be useful to give an example Makefile file in the manual. Joost's solution (comment 2) seems to work fine, though I am not sure how protable to non-Unix platforms the @true is. On limitation of my example is that it assumes that there is just a single module in a file and that has the same name as the file. Would be great if this could be generalized.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:36:01 UTC --- BTW, there is one thing I would still like to add, but I have not yet tried. gfortran -fsyntax-only test.f90 will generate all .mod files 'defined' by test.f90 This seems like a great way to speedup parallel builds. Right now, make -j X often serializes at '-O3 ' because code generation is slow. Using a two stage compile test.mod: test.f90 gfortran -fsyntax-only test.f90 test.o: test.f90 test.mod gfortran -c -O3 test.f90 could speed things up for large parallel projects since the next file can be compiled (modded ?) as soon as the .mod of the previous one has been generated, there is no need to wait for the .o.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #12 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 19:31:14 UTC --- (In reply to comment #9) test.mod: test.f90 gfortran -fsyntax-only test.f90 test.o: test.f90 test.mod gfortran -c -O3 test.f90 could speed things up for large parallel projects since the next file can be compiled (modded ?) as soon as the .mod of the previous one has been generated, there is no need to wait for the .o. Actually this seems to work rather well. I have been testing this, and for CP2K on a 48 core server, I get a 2-fold speedup for a fresh build. This really seems something to consider seriously.
[Bug libfortran/47514] Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-28 13:33:41 UTC --- could be windows specific, since both testcases run fine here (x86_64-unknown-linux-gnu), with 4.3, 4.5 and 4.6
[Bug middle-end/47522] New: [4.6 Regression] wrong code at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47522 Summary: [4.6 Regression] wrong code at -O3 -ffast-math Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Created attachment 23157 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23157 testcase, run under valgrind to see error I'm seeing the following valgrind errors: valgrind ./a.out ==4899== Memcheck, a memory error detector ==4899== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==4899== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==4899== Command: ./a.out ==4899== ==4899== Invalid read of size 8 ==4899==at 0x402634: integrate_gf_npbc_ (in /data03/vondele/cp2k_gcc/cp2k/src/a.out) ==4899==by 0x4021B2: main (in /data03/vondele/cp2k_gcc/cp2k/src/a.out) ==4899== Address 0x5b4ee40 is 0 bytes after a block of size 272 alloc'd ==4899==at 0x4C26C3A: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==4899==by 0x401A54: main (in /data03/vondele/cp2k_gcc/cp2k/src/a.out) ==4899== for the testcase compiled with gfortran -O3 -ffast-math test.f90 this happens for current trunk, or more precisely: gfortran -v -O3 -ffast-math test.f90 Driving: gfortran -v -O3 -ffast-math test.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --enable-gold --enable-checking=release Thread model: posix gcc version 4.6.0 20110128 (experimental) [trunk revision 169358] (GCC) COLLECT_GCC_OPTIONS='-v' '-O3' '-ffast-math' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test -O3 -version -ffast-math -fintrinsic-modules-path /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /dev/shm/vondele/cc9gSh7M.s GNU Fortran (GCC) version 4.6.0 20110128 (experimental) [trunk revision 169358] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110128 (experimental) [trunk revision 169358], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.0 20110128 (experimental) [trunk revision 169358] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20110128 (experimental) [trunk revision 169358], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-O3' '-ffast-math' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as --64 -o /dev/shm/vondele/ccpFdwCq.o /dev/shm/vondele/cc9gSh7M.s Reading specs from /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-O3' '-ffast-math' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O3' '-ffast-math' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o -L/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0 -L/data03/vondele/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-27 13:22:49 UTC --- I actually vaguely recall why this should be a warning, and not be checked for at runtime. This is for legacy codes using real :: a(1) instead of real :: a(*). Something like SUBROUTINE S1(a) INTEGER :: a(10) a(10)=0 END SUBROUTINE SUBROUTINE S2(a) INTEGER :: a(1) CALL S1(a) END SUBROUTINE INTEGER :: a(10) CALL S2(a) END 'works just fine'...
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-27 16:52:07 UTC --- Not sure if that solves the issue, but CP2K uses these rules: %.o: %.F $(FC) -c $(FCFLAGS) $ %.mod: %.o @true with these style dependencies: ai_coulomb_test.o ai_coulomb_test.mod : ai_coulomb_test.F cp_common_uses.h cp_error_handling.mod cp_log_handling.mod physcon.mod so faking that .mod is made up to date by having an up to date .o.
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #33 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 09:47:10 UTC --- I just note that the timings reported by David and Jakub are not for the compile options I originally reported. With 4.6 (20110117) I now have gfortran -c -ftime-report -cpp -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form PR45422.F90 TOTAL : 102.15 while with the options used by David / Jakub I have timings similar to theirs. gfortran -O3 -fbounds-check -ftime-report -c PR45422.F90 TOTAL : 42.87 With 4.5 timings remain ~44s
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #35 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 10:03:02 UTC --- (In reply to comment #34) -march=native is ambiguous, please see with -v what actually is being used. This was mentioned in the initial comment: -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 The latest timings are on a newer machine (old one is gone now) which has: -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 12:12:59 UTC --- (In reply to comment #7) Reopening.. actually, I think this is a kind of error that should be caught at run-time with -fcheck=arguments (not to say bounds). I guess that's not so easy to implement, as it seem to imply that additional hidden subroutine arguments need to be passed around.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #41 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 15:03:55 UTC --- (In reply to comment #39) void *. So you get the ICE. Hum, may I suggest a --push-harder/--will-you-swallow-it option ? --enable-checking=release ?
[Bug libfortran/47375] New: getlog causes warnings with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375 Summary: getlog causes warnings with static linking Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following testcase causes the following warning when linking. If the static binary is afterwards used on 'the right system' it will also crash. It would be nice if the getlog implementation avoids this problem, some HPC systems only allow for static linking. cat test.f90 character(LEN=80) :: name CALL getlog(name) END gfortran -static test.f90 /usr/lib64/gcc/x86_64-suse-linux/4.5/libgfortran.a(getlog.o): In function `_gfortran_getlog': /usr/src/packages/BUILD/gcc-4.5.0-20100604/obj-x86_64-suse-linux/x86_64-suse-linux/libgfortran/../../../libgfortran/intrinsics/getlog.c:80: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-20 13:16:46 UTC --- I quickly tried to link a C program statically that uses getpwuid_r. It has the same problem. I guess it is unavoidable.
[Bug middle-end/47341] New: unnecessary versioning in the vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47341 Summary: unnecessary versioning in the vectorizer. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch with current trunk: cat test.f90 SUBROUTINE HARD_NN_4_4_4_5_1_2_4(C,A,B) REAL(KIND=8) :: C(4,*) REAL(KIND=8) :: B(4,*), A(4,*) INTEGER ::i,j,l l= 1 DO j= 1 , 4 , 2 DO i= 1 , 4 , 1 C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0) C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+1)*B(l+1,j+0) C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+2)*B(l+2,j+0) C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+3)*B(l+3,j+0) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+0)*B(l+0,j+1) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+1)*B(l+1,j+1) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+2)*B(l+2,j+1) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+3)*B(l+3,j+1) ENDDO ENDDO END SUBROUTINE gfortran-trunk -c -O2 -fno-unroll-loops -ftree-vectorize -ftree-vectorizer-verbose=1 -march=core2 -msse4.2 test.f90 test.f90:7: note: created 1 versioning for alias checks. test.f90:7: note: LOOP VECTORIZED. test.f90:1: note: vectorized 1 loops in function. The compiler should not need to generate various version of these loops. With the bounds info provided, nothing can alias (I think).
