[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #20 from jv244 at cam dot ac dot uk 2010-09-10 06:36 --- Tobias, many thanks for working on this... I mentioned this before in the PR, but it would be very good if some line number testcases were added to the regression tests. Both for performance measurements and debugging, this is essential info, and it is too remarkable good lineno info could 'disappear' from a released (4.5) compiler just like that. If there would be some semi-automatic way of checking the lineno quality (such as e.g. in the original dump line numbers should always increase??), I'd be happy to give it a try on CP2K. Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #42 from jv244 at cam dot ac dot uk 2010-09-10 09:58 --- (In reply to comment #40) Please give it a look, and file bugs related to missing or broken customizations in the new Bugzilla product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla FYI, I can't login to the new bugzilla because my current password is 5 chars, which seemingly is less than the minimum for the new bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug fortran/45595] New: segfault on omp collapse
this test case (with an invalid collapse): SUBROUTINE init_input_type() INTEGER :: k,l(3),u(3) !$omp parallel do shared(l,u) collapse(3) DO k = l(3),u(3) ENDDO END SUBROUTINE leads to an ice with current trunk as: #0 gfc_resolve_omp_directive (code=0x1437880, ns=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/openmp.c:1519 #1 0x0051f74c in resolve_code (code=0x1437880, ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:9126 #2 0x0052063a in resolve_codes (ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:13339 #3 0x0052074c in gfc_resolve (ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:13366 #4 0x00513cd7 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4194 #5 0x0054ce7d in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:242 #6 0x0085fa4d in toplev_main (argc=20, argv=0x7fff13674938) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:972 #7 0x7ffdb4e7d436 in __libc_start_main () from /lib64/libc.so.6 #8 0x004aa599 in _start () -- Summary: segfault on omp collapse Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug fortran/45597] New: [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
gfortran -c -fopenmp bug.f90 bug.f90: In function rs_pw_transfer_distributed: bug.f90:6:0: internal compiler error: in gfc_trans_cycle, at fortran/trans-stmt.c:4320 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 SUBROUTINE rs_pw_transfer_distributed() INTEGER, ALLOCATABLE, DIMENSION(:, :):: bounds !$omp parallel do default(none), !$omp shared(bounds,my_rs_rank) DO i = 0, N IF (ub_send(1) .LT.bounds(my_rs_rank,1)) CYCLE END DO END SUBROUTINE rs_pw_transfer_distributed -- Summary: [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug fortran/25096] Non-conforming shapes of DATA object and data
--- Comment #4 from jv244 at cam dot ac dot uk 2010-09-08 18:22 --- (In reply to comment #3) just a question. why is this illegal ? it is R528 in the section on the data statement of the F2003 standard that suggests this has to be a scalar-structure-component. Not so obvious why, if you ask me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25096
[Bug fortran/45576] New: [4.6 Regression] ICE on character stuff
this started failing with today's trunk SUBROUTINE get_r_val() INTEGER, PARAMETER :: default_string_length=128 CHARACTER(len=default_string_length) :: c_val LOGICAL :: check check = c_val(LEN_TRIM(c_val):LEN_TRIM(c_val))==] END SUBROUTINE get_r_val -- Summary: [4.6 Regression] ICE on character stuff Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45576
[Bug fortran/45576] [4.6 Regression] ICE on character stuff
-- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||tkoenig at netcologne dot de Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45576
[Bug lto/45586] New: ICE non-trivial conversion at assignment
I'm trying to do an lto build of CP2K, but this fails with: /data03/vondele/clean/cp2k/makefiles/../src/qs_linres_current.F: In function calculate_jrho_resp: /data03/vondele/clean/cp2k/makefiles/../src/qs_linres_current.F:614:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) # .MEM_3681 = VDEF .MEM_3286 my_rho = D.13693_938-r; /data03/vondele/clean/cp2k/makefiles/../src/qs_linres_current.F:614:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) # .MEM_3682 = VDEF .MEM_3681 my_current = D.13701_946-r; /data03/vondele/clean/cp2k/makefiles/../src/qs_linres_current.F:614:0: error: non-trivial conversion at assignment struct array3_real(kind=8) struct array3_real(kind=8) # .MEM_3750 = VDEF .MEM_3287 my_gauge = D.14057_1326-r; /data03/vondele/clean/cp2k/makefiles/../src/qs_linres_current.F:614:0: internal compiler error: verify_stmts failed Please submit a full bug report. Not sure how to get a testcase for this one It appears to be for example this pointer assignment my_gauge=rs_gauge(1)%rs(igrid_level)%rs_grid%r where REAL(dp), DIMENSION(:, :, :), POINTER:: my_gauge and r is: TYPE realspace_grid_type REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r ! the grid END TYPE realspace_grid_type -- Summary: ICE non-trivial conversion at assignment Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
[Bug lto/45586] ICE non-trivial conversion at assignment
--- Comment #1 from jv244 at cam dot ac dot uk 2010-09-07 19:28 --- Simple testcase (gfortran -flto test.f90): MODULE M1 INTEGER, PARAMETER :: dp=8 TYPE realspace_grid_type REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r END TYPE realspace_grid_type END MODULE MODULE M2 USE m1 CONTAINS SUBROUTINE S1(x) TYPE(realspace_grid_type), POINTER :: x REAL(dp), DIMENSION(:, :, :), POINTER:: y y=x%r y=0 END SUBROUTINE END MODULE USE M2 TYPE(realspace_grid_type), POINTER :: x ALLOCATE(x) ALLOCATE(x%r(10,10,10)) CALL S1(x) write(6,*) x%r END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
[Bug lto/45586] [4.6 Regression] ICE non-trivial conversion at assignment
--- Comment #2 from jv244 at cam dot ac dot uk 2010-09-07 19:30 --- Actually works with 4.5 but fails with trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE non-trivial conversion |[4.6 Regression] ICE non- |at assignment |trivial conversion at ||assignment Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #16 from jv244 at cam dot ac dot uk 2010-08-29 06:38 --- adjust summary according to the last timings -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2010-08-29 05:31:37 |2010-08-29 06:38:26 date|| Summary|[4.6 Regression] compile|[4.6 Regression] compile |time increases 5x. |time increases 3x. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #18 from jv244 at cam dot ac dot uk 2010-08-29 15:07 --- FYI, these are the 4.5 branch timings: Execution times (seconds) garbage collection: 0.47 ( 1%) usr 0.00 ( 0%) sys 0.47 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.05 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 5996 kB ( 1%) ggc callgraph optimization: 0.21 ( 0%) usr 0.02 ( 1%) sys 0.26 ( 0%) wall 606 kB ( 0%) ggc ipa cp: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 1381 kB ( 0%) ggc ipa reference : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.06 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.39 ( 1%) usr 0.00 ( 0%) sys 0.51 ( 1%) wall 2459 kB ( 0%) ggc trivially dead code : 0.34 ( 1%) usr 0.00 ( 0%) sys 0.30 ( 1%) wall 0 kB ( 0%) ggc df multiple defs : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.33 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall 0 kB ( 0%) ggc df live regs : 2.08 ( 4%) usr 0.01 ( 1%) sys 2.19 ( 4%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.98 ( 2%) usr 0.00 ( 0%) sys 0.92 ( 2%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.24 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.93 ( 2%) usr 0.00 ( 0%) sys 1.04 ( 2%) wall 5756 kB ( 1%) ggc register information : 0.51 ( 1%) usr 0.01 ( 1%) sys 0.39 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 0.78 ( 1%) usr 0.01 ( 1%) sys 0.91 ( 2%) wall 22384 kB ( 3%) ggc alias stmt walking: 0.50 ( 1%) usr 0.03 ( 2%) sys 0.38 ( 1%) wall 5563 kB ( 1%) ggc register scan : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc parser: 0.82 ( 2%) usr 0.13 ( 9%) sys 0.94 ( 2%) wall 55603 kB ( 6%) ggc inline heuristics : 0.20 ( 0%) usr 0.01 ( 1%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.38 ( 1%) usr 0.03 ( 2%) sys 0.40 ( 1%) wall 46588 kB ( 5%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.04 ( 0%) usr 0.02 ( 1%) sys 0.05 ( 0%) wall 11964 kB ( 1%) ggc tree CFG cleanup : 0.47 ( 1%) usr 0.00 ( 0%) sys 0.79 ( 1%) wall 1829 kB ( 0%) ggc tree VRP : 1.46 ( 3%) usr 0.05 ( 4%) sys 1.27 ( 2%) wall 56376 kB ( 6%) ggc tree copy propagation : 0.09 ( 0%) usr 0.02 ( 1%) sys 0.22 ( 0%) wall 746 kB ( 0%) ggc tree find ref. vars : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.07 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.30 ( 1%) usr 0.00 ( 0%) sys 0.33 ( 1%) wall 3836 kB ( 0%) ggc tree PHI insertion: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.24 ( 0%) usr 0.01 ( 1%) sys 0.29 ( 1%) wall 13860 kB ( 2%) ggc tree SSA other: 0.13 ( 0%) usr 0.02 ( 1%) sys 0.11 ( 0%) wall 418 kB ( 0%) ggc tree SSA incremental : 0.89 ( 2%) usr 0.06 ( 4%) sys 0.97 ( 2%) wall 6811 kB ( 1%) ggc tree operand scan : 0.34 ( 1%) usr 0.23 (17%) sys 0.59 ( 1%) wall 44776 kB ( 5%) ggc dominator optimization: 0.29 ( 1%) usr 0.01 ( 1%) sys 0.35 ( 1%) wall 5152 kB ( 1%) ggc tree CCP : 0.51 ( 1%) usr 0.02 ( 1%) sys 0.43 ( 1%) wall 4620 kB ( 1%) ggc tree PHI const/copy prop: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 106 kB ( 0%) ggc tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 2019 kB ( 0%) ggc tree reassociation: 0.12 ( 0%) usr 0.01 ( 1%) sys 0.12 ( 0%) wall 2946 kB ( 0%) ggc tree PRE : 0.92 ( 2%) usr 0.00 ( 0%) sys 0.95 ( 2%) wall 7315 kB ( 1%) ggc tree FRE : 0.45 ( 1%) usr 0.04 ( 3%) sys 0.35 ( 1%) wall 5518 kB ( 1%) ggc tree code sinking : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1400 kB ( 0%) ggc tree linearize phis : 0.02 ( 0%) usr 0.01 ( 1%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.18 ( 0%) usr 0.02 ( 1%) sys 0.16 ( 0%) wall 10006 kB ( 1%) ggc tree conservative DCE : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.13 ( 0%) wall 576 kB ( 0%) ggc tree aggressive DCE : 0.28 ( 1%) usr 0.01 ( 1%) sys 0.37 ( 1%) wall 8853 kB ( 1%) ggc tree buildin call DCE : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 132 kB ( 0%) ggc PHI merge : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 37 kB ( 0%) ggc tree loop bounds : 0.22 ( 0
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #11 from jv244 at cam dot ac dot uk 2010-08-29 05:09 --- After David's patch (thanks!), the testcase requires 240s, that's still a 5x slowdown. I paste the new timing profile below, and reopen the bug. There is no obvious candidate for the slowdown. gfortran -c -ftime-report -cpp -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form test.f90 Execution times (seconds) garbage collection: 12.55 ( 5%) usr 0.03 ( 2%) sys 12.57 ( 5%) wall 0 kB ( 0%) ggc callgraph construction: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 5736 kB ( 0%) ggc callgraph optimization: 0.40 ( 0%) usr 0.02 ( 1%) sys 0.41 ( 0%) wall 725 kB ( 0%) ggc ipa cp: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 1347 kB ( 0%) ggc ipa function splitting: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.07 ( 0%) usr 0.01 ( 1%) sys 0.15 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 2.28 ( 1%) usr 0.00 ( 0%) sys 2.35 ( 1%) wall 4726 kB ( 0%) ggc CFG verifier : 5.54 ( 2%) usr 0.03 ( 2%) sys 5.73 ( 2%) wall 0 kB ( 0%) ggc trivially dead code : 0.67 ( 0%) usr 0.00 ( 0%) sys 0.65 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.28 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 2.00 ( 1%) usr 0.00 ( 0%) sys 2.12 ( 1%) wall 0 kB ( 0%) ggc df live regs : 9.80 ( 4%) usr 0.01 ( 1%) sys 10.18 ( 4%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.62 ( 1%) usr 0.00 ( 0%) sys 3.08 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.22 ( 0%) usr 0.00 ( 0%) sys 1.26 ( 1%) wall 0 kB ( 0%) ggc df live reg subwords : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.27 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.67 ( 2%) usr 0.00 ( 0%) sys 4.44 ( 2%) wall 8317 kB ( 0%) ggc register information : 2.10 ( 1%) usr 0.00 ( 0%) sys 1.97 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 1.73 ( 1%) usr 0.00 ( 0%) sys 1.87 ( 1%) wall 47018 kB ( 3%) ggc alias stmt walking: 0.61 ( 0%) usr 0.07 ( 4%) sys 0.61 ( 0%) wall 6938 kB ( 0%) ggc register scan : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.32 ( 0%) wall 202 kB ( 0%) ggc rebuild jump labels : 0.72 ( 0%) usr 0.00 ( 0%) sys 0.67 ( 0%) wall 0 kB ( 0%) ggc parser: 0.90 ( 0%) usr 0.09 ( 5%) sys 0.99 ( 0%) wall 55368 kB ( 3%) ggc inline heuristics : 0.17 ( 0%) usr 0.01 ( 1%) sys 0.26 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.51 ( 0%) usr 0.01 ( 1%) sys 0.57 ( 0%) wall 48405 kB ( 3%) ggc tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.02 ( 0%) usr 0.01 ( 1%) sys 0.03 ( 0%) wall 11974 kB ( 1%) ggc tree CFG cleanup : 1.30 ( 1%) usr 0.02 ( 1%) sys 1.21 ( 0%) wall 3530 kB ( 0%) ggc tree VRP : 2.50 ( 1%) usr 0.03 ( 2%) sys 2.44 ( 1%) wall 67364 kB ( 4%) ggc tree copy propagation : 0.16 ( 0%) usr 0.05 ( 3%) sys 0.15 ( 0%) wall 1384 kB ( 0%) ggc tree find ref. vars : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.05 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.34 ( 0%) usr 0.00 ( 0%) sys 0.33 ( 0%) wall 5198 kB ( 0%) ggc tree PHI insertion: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.39 ( 0%) usr 0.00 ( 0%) sys 0.35 ( 0%) wall 14011 kB ( 1%) ggc tree SSA other: 0.10 ( 0%) usr 0.04 ( 2%) sys 0.10 ( 0%) wall 432 kB ( 0%) ggc tree SSA incremental : 1.18 ( 0%) usr 0.14 ( 8%) sys 1.44 ( 1%) wall 7441 kB ( 0%) ggc tree operand scan : 0.47 ( 0%) usr 0.33 (19%) sys 0.78 ( 0%) wall 58289 kB ( 3%) ggc dominator optimization: 0.52 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 8527 kB ( 0%) ggc tree SRA : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 1.05 ( 0%) usr 0.05 ( 3%) sys 1.28 ( 1%) wall 4845 kB ( 0%) ggc tree PHI const/copy prop: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 106 kB ( 0%) ggc tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 2014 kB ( 0%) ggc tree reassociation: 0.27 ( 0%) usr 0.03 ( 2%) sys 0.27 ( 0%) wall 6030 kB ( 0%) ggc tree PRE : 0.85 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 7164 kB ( 0%) ggc tree FRE : 0.47 ( 0%) usr 0.02 ( 1%) sys 0.56 ( 0%) wall 5411 kB ( 0%) ggc tree code sinking : 0.11 ( 0%) usr
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #13 from jv244 at cam dot ac dot uk 2010-08-29 05:20 --- (In reply to comment #12) Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. The comparison is actually against the branches, not releases. However, I'm rebuilding gcc and will report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #15 from jv244 at cam dot ac dot uk 2010-08-29 05:31 --- Similar times (a bit faster) with release checking: Execution times (seconds) garbage collection: 1.17 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.04 ( 0%) usr 0.01 ( 1%) sys 0.04 ( 0%) wall 5670 kB ( 0%) ggc callgraph optimization: 0.32 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 599 kB ( 0%) ggc ipa cp: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 1345 kB ( 0%) ggc ipa function splitting: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.11 ( 0%) usr 0.02 ( 1%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 2.67 ( 2%) usr 0.02 ( 1%) sys 2.59 ( 2%) wall 4726 kB ( 0%) ggc trivially dead code : 0.74 ( 0%) usr 0.00 ( 0%) sys 0.72 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.48 ( 0%) usr 0.01 ( 1%) sys 0.35 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 1.73 ( 1%) usr 0.00 ( 0%) sys 2.12 ( 1%) wall 0 kB ( 0%) ggc df live regs : 10.78 ( 7%) usr 0.01 ( 1%) sys 11.16 ( 7%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.60 ( 2%) usr 0.00 ( 0%) sys 3.87 ( 2%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.52 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall 0 kB ( 0%) ggc df live reg subwords : 0.33 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 5.27 ( 3%) usr 0.00 ( 0%) sys 5.42 ( 3%) wall 7568 kB ( 0%) ggc register information : 2.24 ( 1%) usr 0.00 ( 0%) sys 2.19 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 2.33 ( 1%) usr 0.00 ( 0%) sys 2.30 ( 1%) wall 47018 kB ( 3%) ggc alias stmt walking: 0.48 ( 0%) usr 0.05 ( 3%) sys 0.44 ( 0%) wall 6938 kB ( 0%) ggc register scan : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall 394 kB ( 0%) ggc rebuild jump labels : 0.73 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 0 kB ( 0%) ggc parser: 0.85 ( 1%) usr 0.13 ( 7%) sys 0.98 ( 1%) wall 55365 kB ( 3%) ggc inline heuristics : 0.24 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.40 ( 0%) usr 0.06 ( 3%) sys 0.47 ( 0%) wall 48405 kB ( 3%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.03 ( 0%) usr 0.02 ( 1%) sys 0.08 ( 0%) wall 11971 kB ( 1%) ggc tree CFG cleanup : 1.02 ( 1%) usr 0.03 ( 2%) sys 1.14 ( 1%) wall 3522 kB ( 0%) ggc tree VRP : 2.25 ( 1%) usr 0.05 ( 3%) sys 2.18 ( 1%) wall 67051 kB ( 4%) ggc tree copy propagation : 0.24 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 1384 kB ( 0%) ggc tree find ref. vars : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.36 ( 0%) usr 0.00 ( 0%) sys 0.26 ( 0%) wall 5193 kB ( 0%) ggc tree PHI insertion: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.40 ( 0%) usr 0.02 ( 1%) sys 0.53 ( 0%) wall 14011 kB ( 1%) ggc tree SSA other: 0.09 ( 0%) usr 0.01 ( 1%) sys 0.13 ( 0%) wall 428 kB ( 0%) ggc tree SSA incremental : 1.40 ( 1%) usr 0.09 ( 5%) sys 1.50 ( 1%) wall 7431 kB ( 0%) ggc tree operand scan : 0.45 ( 0%) usr 0.33 (18%) sys 0.82 ( 0%) wall 58289 kB ( 3%) ggc dominator optimization: 0.41 ( 0%) usr 0.04 ( 2%) sys 0.60 ( 0%) wall 8526 kB ( 0%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 1.05 ( 1%) usr 0.02 ( 1%) sys 1.16 ( 1%) wall 4845 kB ( 0%) ggc tree PHI const/copy prop: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 88 kB ( 0%) ggc tree split crit edges : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 2014 kB ( 0%) ggc tree reassociation: 0.25 ( 0%) usr 0.05 ( 3%) sys 0.23 ( 0%) wall 6023 kB ( 0%) ggc tree PRE : 0.81 ( 0%) usr 0.00 ( 0%) sys 0.82 ( 0%) wall 7164 kB ( 0%) ggc tree FRE : 0.43 ( 0%) usr 0.03 ( 2%) sys 0.51 ( 0%) wall 5410 kB ( 0%) ggc tree code sinking : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1311 kB ( 0%) ggc tree linearize phis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.33 ( 0%) usr 0.00 ( 0%) sys 0.30 ( 0%) wall 11812 kB ( 1%) ggc tree phiprop : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 575 kB ( 0%) ggc tree aggressive DCE
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-27 11:45 --- (In reply to comment #3) this connection with bounds-checking makes it sound familiar. I had a similar bug open (and fixed) as PR43627 with a comment from you http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627#c11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] New: [4.6 Regression] compile time increases 8x.
%) wall 60529 kB ( 3%) ggc if-conversion : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall 2520 kB ( 0%) ggc regmove : 0.88 ( 0%) usr 0.00 ( 0%) sys 0.90 ( 0%) wall 0 kB ( 0%) ggc mode switching: 0.01 ( 0%) usr 0.01 ( 1%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc integrated RA : 16.20 ( 4%) usr 0.04 ( 2%) sys 16.28 ( 4%) wall 44292 kB ( 2%) ggc reload: 7.72 ( 2%) usr 0.02 ( 1%) sys 7.47 ( 2%) wall 10065 kB ( 1%) ggc reload CSE regs : 4.83 ( 1%) usr 0.00 ( 0%) sys 4.84 ( 1%) wall 36964 kB ( 2%) ggc load CSE after reload : 0.50 ( 0%) usr 0.00 ( 0%) sys 0.52 ( 0%) wall 449 kB ( 0%) ggc zee : 0.36 ( 0%) usr 0.00 ( 0%) sys 0.45 ( 0%) wall 45 kB ( 0%) ggc thread pro- epilogue: 0.15 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 3988 kB ( 0%) ggc if-conversion 2 : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 1056 kB ( 0%) ggc combine stack adjustments: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall 0 kB ( 0%) ggc peephole 2: 0.58 ( 0%) usr 0.00 ( 0%) sys 0.55 ( 0%) wall 2995 kB ( 0%) ggc rename registers : 1.45 ( 0%) usr 0.00 ( 0%) sys 1.22 ( 0%) wall 2741 kB ( 0%) ggc hard reg cprop: 1.27 ( 0%) usr 0.00 ( 0%) sys 1.26 ( 0%) wall 15 kB ( 0%) ggc scheduling 2 : 6.64 ( 2%) usr 0.06 ( 3%) sys 6.71 ( 2%) wall 1284 kB ( 0%) ggc machine dep reorg : 0.89 ( 0%) usr 0.00 ( 0%) sys 0.75 ( 0%) wall 77 kB ( 0%) ggc reorder blocks: 0.90 ( 0%) usr 0.00 ( 0%) sys 0.76 ( 0%) wall 4788 kB ( 0%) ggc final : 2.13 ( 0%) usr 0.12 ( 6%) sys 2.29 ( 1%) wall 9656 kB ( 1%) ggc symout: 0.71 ( 0%) usr 0.11 ( 5%) sys 0.82 ( 0%) wall 58849 kB ( 3%) ggc variable tracking : 3.12 ( 1%) usr 0.00 ( 0%) sys 3.06 ( 1%) wall 62059 kB ( 3%) ggc var-tracking dataflow : 4.46 ( 1%) usr 0.01 ( 1%) sys 4.47 ( 1%) wall 0 kB ( 0%) ggc var-tracking emit : 3.78 ( 1%) usr 0.01 ( 1%) sys 3.84 ( 1%) wall 19142 kB ( 1%) ggc TOTAL : 434.63 2.00 436.64 1780330 kB gfortran -v reports: /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -cpp=/tmp/cceEHMzK.f90 -quiet -v test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase test.f90 -auxbase test -g -O3 -version -ftime-report -fbounds-check -ffast-math -funroll-loops -ftree-vectorize -ffree-form -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccQ56z0k.s -- Summary: [4.6 Regression] compile time increases 8x. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #1 from jv244 at cam dot ac dot uk 2010-08-26 18:34 --- Created an attachment (id=21573) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21573action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #10 from jv244 at cam dot ac dot uk 2010-08-20 08:57 --- (In reply to comment #9) (In reply to comment #8) Error: Dummy 'x' at (1) cannot have an initializer Do you have a suggestion? Error: Dummy argument 'x' at (1) cannot have the save attribute which is implied by initialization. ?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] intent(out) and pointer = null()
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-19 09:22 --- (In reply to comment #1) module ptrmod contains subroutine lengthX(x, i) implicit none real, pointer, intent(out) :: x(:)=null() you can't initialize a dummy argument, since initialization implies save. Just put 'NULLIFY(x)' in the body of the subroutine. Intents for pointers is fine, but not Fortran95 (2003/2008?) integer :: i allocate(x(i)) x=i end subroutine end module program main use ptrmod implicit none real, pointer :: x(:) integer :: i do i=1,5 call lengthX(x, i) print *, size(x), x enddo if(associated(x)) deallocate(x) x=null() end program -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug middle-end/45172] [4.6 Regression] internal compiler error: verify_flow_info failed
--- Comment #5 from jv244 at cam dot ac dot uk 2010-08-19 14:24 --- (In reply to comment #4) Not sure what exactly Fortran needs -fexceptions for currently, one reason could be pthread_cancel, but at least with OpenMP pthread_cancel isn't going to do very nice things anyway. We have a mixed MPI/OMP parallel Fortran code, -fexceptions is being added automagically by the openmpi compiler driver (mpif90). This might be to allow mixed C++/C/Fortran codes to work (but I couldn't quite find docs about this on the openmpi webpage). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|4.5.2 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-13 10:11 --- (In reply to comment #3) Might be related to pr41359 (whose patch was not committed). I think it is unrelated, since this used to work in 4.3, while pr41359 never worked AFAICT. Nevertheless, would be nice to commit the patch in pr41359, maybe there is a lucky side-effect. I think there is are no line-number tests in gfortran's testsuite. Would be a good thing to establish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #7 from jv244 at cam dot ac dot uk 2010-08-13 18:20 --- (In reply to comment #6) With or without the other patch, the gimple code has: isn't the gimple output showing linenumbers even in the case where the .original dump is missing them ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug middle-end/45242] New: [4.6 Regression] ICE in trunc_int_for_mode, at explow.c:57
Recent regression with trunk revision 163037 cat bug.f90 SUBROUTINE dbcsr_sort_indices(n,row_i, col_i) INTEGER, DIMENSION(1:n), INTENT(INOUT) :: row_i, col_i row_i(:) = ISHFT(row_i(:), 16) + col_i END SUBROUTINE dbcsr_sort_indices gfortran -c -O3 bug.f90 bug.f90: In function dbcsr_sort_indices: bug.f90:4:0: internal compiler error: in trunc_int_for_mode, at explow.c:57 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.6 Regression] ICE in trunc_int_for_mode, at explow.c:57 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45242
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-05 11:13 --- confirmed with 4.5/4.6, works with 4.3/4.4. Compiling with -fdump-tree-all-lineno and looking into tx_f90_pointers.f90.003t.original shows that most of the lineno info has disappeared in 4.5. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2010-08-05 11:13:14 date|| Summary|Gfortran 4.5.0 emits wrong |[4.5/4.6 Regression] |linenumbers |Gfortran 4.5.0 emits wrong ||linenumbers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug middle-end/45172] New: [4.6 Regression] internal compiler error: verify_flow_info failed
recent trunk (4.6.0 20100803 (experimental) [trunk revision 162839]) fails with: gfortran -c -fopenmp -O1 -fexceptions bug.f90 bug.f90: In function dbcsr_mult_m_e_e: bug.f90:1:0: error: verify_flow_info: Duplicate edge 28-29 bug.f90:1:0: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 SUBROUTINE dbcsr_mult_m_e_e ( ) LOGICAL, PARAMETER :: use_combined_types = .FALSE. INTEGER, ALLOCATABLE, DIMENSION(:, :) :: right_index_sr INTEGER, ALLOCATABLE, DIMENSION(:, :, :) :: my_sizes INTEGER, ALLOCATABLE, DIMENSION(:, :, :, :) :: all_sizes ALLOCATE (all_sizes(4, LBOUND(my_sizes,2):UBOUND(my_sizes,2), LBOUND(my_sizes,3):UBOUND(my_sizes,3), 0:numnodes-1)) IF (use_combined_types) THEN CALL mp_waitall (right_index_sr) ENDIF DO ki = 0, min_nimages-1 !$omp parallel default (none) !$omp reduction (+: flop_single, t_all, t_dgemm) !$omp end parallel ENDDO checksum = dbcsr_checksum (product_matrix, error) END SUBROUTINE dbcsr_mult_m_e_e older gcc (gcc-4_5-branch revision 162409) is fine. -- Summary: [4.6 Regression] internal compiler error: verify_flow_info failed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #61 from jv244 at cam dot ac dot uk 2010-07-24 08:24 --- (In reply to comment #60) it seems possible to retain only the first 60498 lines of all.f90 (till the end of module fft_tools), and add END to get a much smaller testcase... I've started a delta reduction, I believe it is feasible, but could take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #62 from jv244 at cam dot ac dot uk 2010-07-24 11:10 --- a testcase... cat bug.f90 SUBROUTINE fft_3d ( fft_type, fft_in_place, fsign, scale, n, zin, zout ) CALL fftsg3d ( fft_in_place, fsign, scale, n, zin, zout ) END SUBROUTINE fft_3d SUBROUTINE fft_1dm ( fft_type, fsign, trans, n, m, zin, zout, scale ) END SUBROUTINE fft_1dm SUBROUTINE fftsg3d ( fft_in_place, fsign, scale, n, zin, zout ) INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 ) CALL mltfftsg ( 'N', 'T', zin, nx, ny*nz, xf, ny*nz, nx, nx, ny*nz, fsign, 1.0_dp ) END SUBROUTINE fftsg3d SUBROUTINE mltfftsg ( transa, transb, a, ldax, lday, b, ldbx, ldby, n, m, isign, scale ) END SUBROUTINE mltfftsg MODULE fft_tools CONTAINS SUBROUTINE fft3d_s ( fsign, n, zin, zout, scale, status, debug ) CALL fft_3d ( fft_type, fft_in_place, sign, norm, n, zin, zoptr ) END SUBROUTINE fft3d_s SUBROUTINE fft3d_ps ( fsign, n, cin, gin, gs_group, rs_group, yzp, nyzray, bo, scale, status, debug ) CALL fft_1dm ( fft_type, sign, .TRUE., n(3), mx1*my1, pbuf, qbuf, norm ) END SUBROUTINE fft3d_ps END MODULE fft_tools END links with: gfortran-trunk -fno-whole-file bug.f90 fails with: gfortran-trunk -fwhole-file bug.f90 some of the argument mismatches are a result of the reduction, but not all of them, so I guess that is key. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #63 from jv244 at cam dot ac dot uk 2010-07-24 11:14 --- even better testcase... no mismatching arguments: SUBROUTINE fft_3d ( ) CALL fftsg3d () END SUBROUTINE fft_3d SUBROUTINE fft_1dm ( ) END SUBROUTINE fft_1dm SUBROUTINE fftsg3d ( ) CALL mltfftsg ( ) END SUBROUTINE fftsg3d SUBROUTINE mltfftsg ( ) END SUBROUTINE mltfftsg MODULE fft_tools CONTAINS SUBROUTINE fft3d_s ( ) CALL fft_3d ( ) END SUBROUTINE fft3d_s SUBROUTINE fft3d_ps ( ) CALL fft_1dm ( ) END SUBROUTINE fft3d_ps END MODULE fft_tools END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/32817] MODULE functions are not inlined
--- Comment #10 from jv244 at cam dot ac dot uk 2010-07-24 17:58 --- with -fwhole-file being the default this testcase http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817#c5 gets properly inlined at -O2. Yeah! I think this can be closed, but probably one would like to add a testcase to the testsuite -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #20 from jv244 at cam dot ac dot uk 2010-07-24 18:12 --- is this now fixed, all test cases seem to be passing ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #17 from jv244 at cam dot ac dot uk 2010-07-24 18:15 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873#c1 still fails with current trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2010-05-03 10:53:20 |2010-07-24 18:15:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #59 from jv244 at cam dot ac dot uk 2010-07-23 22:15 --- I'm trying a recent trunk (162490), and I'm still observing that -fwhole-file causing linking errors. I have no easy testcase, the way to reproduce is: download http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz compile and link (takes several minutes about 2Gb RAM) in CP2K_gcc_2007_06/src as: gfortran -fwhole-file -O0 all.f90 -llapack -lblas this leads to undefined references to: /tmp/ccSrltD0.o: In function `__fft_tools_MOD_fft3d_pb': all.f90:(.text+0xb1c61): undefined reference to `fft_1dm_' all.f90:(.text+0xb2824): undefined reference to `fft_1dm_' all.f90:(.text+0xb33f7): undefined reference to `fft_1dm_' all.f90:(.text+0xb4227): undefined reference to `fft_1dm_' all.f90:(.text+0xb4dea): undefined reference to `fft_1dm_' /tmp/ccSrltD0.o:all.f90:(.text+0xb5984): more undefined references to `fft_1dm_' follow /tmp/ccSrltD0.o: In function `mltfftsg_': all.f90:(.text+0xdbb41a): undefined reference to `ctrig_' all.f90:(.text+0xdbb895): undefined reference to `fftpre_' all.f90:(.text+0xdbb95b): undefined reference to `fftstp_' all.f90:(.text+0xdbbd14): undefined reference to `fftstp_' all.f90:(.text+0xdbbe5c): undefined reference to `fftrot_' all.f90:(.text+0xdbbf64): undefined reference to `fftstp_' but goes fine without the '-fwhole-file'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #60 from jv244 at cam dot ac dot uk 2010-07-23 22:55 --- (In reply to comment #59) I have no easy testcase it seems possible to retain only the first 60498 lines of all.f90 (till the end of module fft_tools), and add END to get a much smaller testcase... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #6 from jv244 at cam dot ac dot uk 2010-07-08 06:24 --- I have also tried to run the testcase with export OMP_WAIT_POLICY=active export GOMP_SPINCOUNT=infinity which I would assume to keep the threads alive, and so there would be no need to create these new threads (the number of active threads is never more than 8), and still this strange binding persists. Jakub, is there any practical way to avoid recreating these threads ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #8 from jv244 at cam dot ac dot uk 2010-07-08 08:55 --- (In reply to comment #7) Yes, it would be possible to keep other threads around, the question is how many and how long, at which point start to destroy them. I can test what other implementations are doing, but I suspect that for the non-nested case, OMP_NUM_THREADS will be created and never destroyed. At least for HPC applications this seems to make sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] New: unexpected thread binding for openmp
if I use thread binding in the following way: export OMP_NUM_THREADS=8 export GOMP_CPU_AFFINITY=0 1 2 3 4 5 6 7 for code that has three parallel regions: !$omp parallel default(private) shared(bindings,n_thread) !$omp end parallel !$omp parallel default(private) shared(bindings,n_thread) num_threads(2) !$omp end parallel !$omp parallel default(private) shared(bindings,n_thread) !$omp end parallel I get the following: ./a.out Entering first parallel region all threads bindings are 0 1 2 3 4 5 6 7 Entering second parallel region using two threads bindings are 0 1 Entering third parallel region using all threads bindings are 0 1 0 1 2 3 4 5 so it the last parallel section 2 times 2 threads bind to the same CPU (this is also what is effectively happing looking at the CPU usage in top). this seems to be happening for gcc 4.3 - 4.6 The testcase will be attached. -- Summary: unexpected thread binding for openmp Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #1 from jv244 at cam dot ac dot uk 2010-07-06 08:03 --- Created an attachment (id=21099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21099action=view) testcase part 1 C code to report thread binding -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #2 from jv244 at cam dot ac dot uk 2010-07-06 08:05 --- Created an attachment (id=21100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21100action=view) fortran testcase build run testcase as : gfortran -fopenmp test.f90 get_affinity.c export OMP_NUM_THREADS=8 export GOMP_CPU_AFFINITY=0 1 2 3 4 5 6 7 ./a.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #4 from jv244 at cam dot ac dot uk 2010-07-06 10:01 --- (In reply to comment #3) That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs upon thread creation, and the first two threads are never recreated in this case. Currently there is no tracking on how many threads bind to which CPU etc. We'd need to track that in some data structure and choose CPU with lowest number of assigned threads or something. oops... this really is a surprise, is there a way that these 6 threads are not destroyed entering the parallel region that asks for 2 threads. That should fix the problem. Other compilers do the expected thing, for example intel: ifort -openmp test.f90 get_affinity.o export OMP_NUM_THREADS=8 export KMP_AFFINITY=proclist=[0,1,2,3,4,5,6,7] ./a.out OMP: Warning #63: KMP_AFFINITY: proclist specified, setting affinity type to explicit. Entering first parallel region all threads bindings are 0 1 2 3 4 5 6 7 Entering second parallel region using two threads bindings are 0 1 Entering third parallel region using all threads bindings are 0 1 2 3 4 5 6 7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #5 from jv244 at cam dot ac dot uk 2010-07-06 11:32 --- I also checked the pgi and cray compilers, they all lead to iforts thread binding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug bootstrap/44721] [4.6 regression] Failed to bootstrap
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-30 07:14 --- similar error compiling CP2K with rev 161570, (rev 161517 was still OK). /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:850:0: error: unrecognizable insn: (insn 6975 398 6976 13 /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:712 (set (reg:DI 1 dx) (mem/c/i:SI (plus:DI (reg/f:DI 7 sp) (const_int 4656 [0x1230])) [2 lmax_0+0 S4 A128])) -1 (nil)) /data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:850:0: internal compiler error: in extract_insn, at recog.c:2127 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44721
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #20 from jv244 at cam dot ac dot uk 2010-06-25 09:28 --- (In reply to comment #18) That part comes from the questionable testcase, which does a_sp = matrix%local_data_sp before the loop unconditionally, eventhough matrix%local_data_sp is uninitialized unless use_sp is .true. thanks for looking into the bug report. Actually the testcase can be turned in 'unquestionable' by adding a 'NULLIFY(a%local_data_sp)' in the main program. At that point the pointer assignment (a_sp = matrix%local_data_sp) makes a_sp defined, but valgrind still yields an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug fortran/44622] [4.6 Regression] ICE in gfc_typenode_for_spec
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-24 22:04 --- can reproduce this anymore, closing as fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
[Bug fortran/44622] New: [4.6 Regression] ICE in gfc_typenode_for_spec
current trunk fails to compile trunk CP2K. This seems due to something
introduced between today and something like 10 days ago. I have tried to reduce
a testcase, but it remains ~1000 lines, with many module dependencies. Best
seems to checkout a current version of CP2K and compile.
Breakpoint 1, fancy_abort (file=0xded168
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c, line=994,
function=0xded7f0 gfc_typenode_for_spec) at
/data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:793
793 {
(gdb) bt
#0 fancy_abort (file=0xded168
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c, line=994,
function=0xded7f0 gfc_typenode_for_spec) at
/data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:793
#1 0x00594014 in gfc_typenode_for_spec (spec=0x1582540)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:994
#2 0x005947a9 in gfc_sym_type (sym=0x1582520) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1769
#3 0x0059443c in gfc_get_function_type (sym=0x1582520)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:2399
#4 0x00563195 in build_function_decl (sym=0x1582520) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:1613
#5 0x0056421f in gfc_create_function_decl (ns=0x15d45b0)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:2165
#6 0x0054a128 in gfc_generate_module_code (ns=0x145df20) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1375
#7 0x0051109c in gfc_parse_file () at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4382
#8 0x0054755d in gfc_be_parse_file (set_yydebug=value optimized out)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236
#9 0x0084d94e in toplev_main (argc=23, argv=0x7fff337fcae8) at
/data03/vondele/gcc_trunk/gcc/gcc/toplev.c:985
#10 0x7fcad0914436 in __libc_start_main () from /lib64/libc.so.6
#11 0x004a97c9 in _start ()
--
Summary: [4.6 Regression] ICE in gfc_typenode_for_spec
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
[Bug middle-end/44496] [4.6 Regression] ICE: segfault: bitmap_elt_clear_from
--- Comment #2 from jv244 at cam dot ac dot uk 2010-06-22 05:46 --- this has disappeared for current trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #9 from jv244 at cam dot ac dot uk 2010-06-21 15:49 --- (In reply to comment #7) I cannot reproduce the factor of 10 results, however. Here this still is the case (so might depend on the precise architecture): /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase test.f90 -auxbase test -O3 -version -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccXsKXnD.s ./a.out 0.10800600 1.0520660 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug libgomp/44536] New: OMP: missing error with default(none)
the following should give an error message like: fortcom: Error: test.f90, line 5: Since the OpenMP DEFAULT(NONE) clause applies, the PRIVATE, SHARED, REDUCTION, FIRSTPRIVATE, or LASTPRIVATE attribute must be explicitly specified for every variable. [A] J=A(I) ^ compilation aborted for test.f90 (code 1) gfortran -c -fopenmp test.f90 cat test.f90 SUBROUTINE S1(a,i,j) INTEGER, DIMENSION(:), INTENT(IN) :: a INTEGER :: i,j !$OMP PARALLEL DEFAULT(NONE) SHARED(I,J) J=A(I) !$OMP END PARALLEL END SUBROUTINE -- Summary: OMP: missing error with default(none) Product: gcc Version: 4.4.5 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44536
[Bug middle-end/44496] ICE: segfault: bitmap_elt_clear_from
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-10 19:12 --- Created an attachment (id=20886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20886action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
[Bug middle-end/44496] New: ICE: segfault: bitmap_elt_clear_from
: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
[Bug middle-end/44496] [4.6 Regression] ICE: segfault: bitmap_elt_clear_from
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to work||4.5.1 Summary|ICE: segfault: |[4.6 Regression] ICE: |bitmap_elt_clear_from |segfault: ||bitmap_elt_clear_from Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #56 from jv244 at cam dot ac dot uk 2010-05-26 13:13 --- (In reply to comment #55) Subject: Bug 40011 Author: pault Date: Wed May 26 05:11:04 2010 New Revision: 159852 I'm still having linking problems with -fwhole-file on the single source file version of CP2K. Will try to get to a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/38474] [Meta] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #47 from jv244 at cam dot ac dot uk 2010-05-23 06:31 --- all dependencies are fixed, and so is this bug. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #8 from jv244 at cam dot ac dot uk 2010-05-22 14:09 --- (In reply to comment #7) 4.5.1, using '-O2 -funswitch-loops' obviously '-O2 -funswitch-loops -fbounds-check' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug fortran/44155] gfortran segmentation fault using iso_c_binding
--- Comment #1 from jv244 at cam dot ac dot uk 2010-05-16 06:57 --- reduced testcase: module mod_tetgen use iso_c_binding type tetgenio double precision, pointer :: pointlist(:,:) integer :: numberoffacets = 0 end type tetgenio contains subroutine tetgenf( in, out ) type(tetgenio), target, intent(in):: in type(tetgenio), target, intent(inout) :: out call tetcall(inhandle, outhandle, c_loc(in%pointlist), out%numberoffacets) end subroutine tetgenf end module mod_tetgen #0 0x0056f9eb in gfc_conv_procedure_call (se=0x7fff0f31c1a0, sym=0x13f0400, arg=0x13f3f10, expr=0x13f44b0, append_args=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:2545 #1 0x005702ba in gfc_conv_function_expr (se=0x7fff0f31c1a0, expr=0x13f44b0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:3792 #2 0x0056a798 in gfc_conv_expr_reference (se=0x13f40f0, expr=0x13f0400) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:4582 #3 0x0056ed56 in gfc_conv_procedure_call (se=0x7fff0f31c830, sym=0x13f38e0, arg=0x13f3850, expr=0x0, append_args=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-expr.c:2858 #4 0x0058b9f3 in gfc_trans_call (code=0x13f4990, dependency_check=0 '\0', mask=0x0, count1=0x0, invert=0 '\0') at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-stmt.c:378 #5 0x0054864f in trans_code (code=0x13f4990, cond=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1144 #6 0x005624c7 in gfc_generate_function_code (ns=0x13f2740) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4456 #7 0x00547c3a in gfc_generate_module_code (ns=0x13e5530) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1392 #8 0x0050d45c in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4303 #9 0x00544f7d in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:239 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.4 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-16 06:58:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44155
[Bug tree-optimization/29212] ICE with -fipa-pta
--- Comment #13 from jv244 at cam dot ac dot uk 2010-05-03 07:46 --- these might be fixed in current trunk as a result of the fixes to PR43879 -- jv244 at cam dot ac dot uk changed: What|Removed |Added BugsThisDependsOn||43879 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #53 from jv244 at cam dot ac dot uk 2010-05-03 10:57 --- testcase in comment #40 now works. Comment #42 still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug tree-optimization/43879] -fipa-pta causes various miscompilations
--- Comment #17 from jv244 at cam dot ac dot uk 2010-04-30 15:26 --- in this case the Fortran bits depend on PR40011 -- jv244 at cam dot ac dot uk changed: What|Removed |Added BugsThisDependsOn||40011 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
[Bug fortran/42958] Weird temporary array allocation
--- Comment #20 from jv244 at cam dot ac dot uk 2010-04-28 15:20 --- (In reply to comment #18) If that's all acceptable I will work on this soon. FYI, this would fix PR38318 and PR21046 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/38111] unneeded temporary
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-27 18:07 --- still fails with current trunk. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #11 from jv244 at cam dot ac dot uk 2010-04-27 18:25 --- the original loop gets now (4.6.0) vectorized, and gets the same performance as the 'hand optimized loop' (which does not get vectorized): ./a.out default loop 0.880055003 hand optimized loop 0.860053987 it is still not quite as fast as the ifort code: ifort -fno-inline -O3 -xT -static t.f90 ~/a.out default loop 0.4440280 hand optimized loop 0.9640600 ifort's asm looks good: # -- Begin s31_ # mark_begin; .align16,0x90 .globl s31_ s31_: # parameter 1: %rdi # parameter 2: %rsi # parameter 3: %rdx # parameter 4: %rcx ..B2.1: # Preds ..B2.0 ..___tag_value_s31_.10: #3.12 xorps %xmm1, %xmm1 #9.2 movaps%xmm1, %xmm0 #9.2 xorl %eax, %eax#9.2 # LOE rax rdx rbx rbp rsi rdi r12 r13 r14 r15 xmm0 xmm1 ..B2.2: # Preds ..B2.2 ..B2.1 movaps(%rdi,%rax,8), %xmm2 #10.8 movaps16(%rdi,%rax,8), %xmm3#10.8 movaps32(%rdi,%rax,8), %xmm4#10.8 movaps48(%rdi,%rax,8), %xmm5#10.8 mulpd (%rsi,%rax,8), %xmm2 #10.12 mulpd 16(%rsi,%rax,8), %xmm3#10.12 mulpd 32(%rsi,%rax,8), %xmm4#10.12 mulpd 48(%rsi,%rax,8), %xmm5#10.12 addpd %xmm2, %xmm0 #10.4 addq $8, %rax #9.2 cmpq $1024, %rax #9.2 addpd %xmm3, %xmm1 #10.4 addpd %xmm4, %xmm0 #10.4 addpd %xmm5, %xmm1 #10.4 jb..B2.2# Prob 82% #9.2 # LOE rax rdx rbx rbp rsi rdi r12 r13 r14 r15 xmm0 xmm1 ..B2.3: # Preds ..B2.2 addpd %xmm1, %xmm0 #9.2 haddpd%xmm0, %xmm0 #9.2 movsd %xmm0, (%rdx) #10.4 ret #12.1 .align16,0x90 ..___tag_value_s31_.11: # while gcc has more complicated-looking asm .globl s31_ .type s31_, @function s31_: .LFB0: movl(%rcx), %r9d movq$0, (%rdx) testl %r9d, %r9d jle .L9 movl%r9d, %r8d shrl%r8d cmpl$4, %r9d leal(%r8,%r8), %r10d jbe .L15 testl %r10d, %r10d je .L15 xorl%eax, %eax xorl%ecx, %ecx xorpd %xmm1, %xmm1 .p2align 4,,10 .p2align 3 .L12: movsd (%rsi,%rax), %xmm2 movsd (%rdi,%rax), %xmm3 movhpd 8(%rsi,%rax), %xmm2 movhpd 8(%rdi,%rax), %xmm3 movapd %xmm2, %xmm0 incl%ecx mulpd %xmm3, %xmm0 addq$16, %rax addpd %xmm0, %xmm1 cmpl%ecx, %r8d ja .L12 haddpd %xmm1, %xmm1 leal1(%r10), %eax cmpl%r9d, %r10d je .L13 .L11: movslq %eax, %rcx subl%eax, %r9d leaq-8(,%rcx,8), %rcx xorl%eax, %eax addq%rcx, %rdi addq%rcx, %rsi leaq8(,%r9,8), %rcx .p2align 4,,10 .p2align 3 .L14: movsd (%rsi), %xmm0 addq$8, %rax mulsd (%rdi), %xmm0 addq$8, %rsi addq$8, %rdi addsd %xmm0, %xmm1 cmpq%rcx, %rax jne .L14 .L13: movsd %xmm1, (%rdx) .L9: rep ret .L15: xorpd %xmm1, %xmm1 movl$1, %eax jmp .L11 .LFE0: .size s31_, .-s31_ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-26 11:06 --- I have been trying to reduce more, but this is the smallest so far, seems like it needs the derived types, the 2D arrays, the pointers. I've reduced this with 4.5.1, using '-O2 -funswitch-loops' MODULE M1 IMPLICIT NONE TYPE cp_fm_type REAL(KIND=4), DIMENSION(:,:), POINTER :: local_data_sp REAL(KIND=8), DIMENSION(:,:), POINTER :: local_data END TYPE CONTAINS SUBROUTINE cp_fm_upper_to_full(matrix,nrow_global,ncol_global,use_sp) TYPE(cp_fm_type), POINTER :: matrix INTEGER, INTENT(IN) :: ncol_global, nrow_global INTEGER :: irow_global, icol_global LOGICAL :: use_sp REAL(KIND = 4), DIMENSION(:,:), POINTER :: a_sp REAL(KIND = 8), DIMENSION(:,:), POINTER :: a a = matrix%local_data a_sp = matrix%local_data_sp DO irow_global=1,nrow_global DO icol_global=irow_global+1,ncol_global IF(use_sp) THEN a_sp(icol_global,irow_global)=a_sp(irow_global,icol_global) ELSE a(icol_global,irow_global)=a(irow_global,icol_global) ENDIF ENDDO ENDDO END SUBROUTINE cp_fm_upper_to_full END MODULE M1 USE M1 TYPE(cp_fm_type), POINTER :: a INTEGER, PARAMETER :: N=17 ALLOCATE(a) ALLOCATE(a%local_data(N,N)) a%local_data=0 CALL cp_fm_upper_to_full(a,N,N,.FALSE.) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-24 12:25 --- This was also ported back to 4.5.1, causing a regression there. This is against the policy of 'open for regression and documentation fixes'. It was also never approved for the branch only trunk. 2010-04-16 Steven G. Kargl ka...@gcc.gnu.org PR fortran/30073 * trans-array.c (gfc_trans_array_bound_check): Eliminate a redundant block of code. Set name to the variable associated with the descriptor. Just for completeness, this testcase again emphasizes that this is an ICE on valid code. MODULE fft_tools IMPLICIT NONE INTEGER, PARAMETER :: sp=4, dp=8 INTEGER, PARAMETER :: lp = dp CONTAINS SUBROUTINE sparse_alltoall ( rs, rq, rcount, rreq, group ) COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rs COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rq INTEGER, DIMENSION(:) :: rcount,rreq INTEGER :: group, pos IF ( rcount(pos) /= 0 ) THEN rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos) END IF END SUBROUTINE sparse_alltoall END MODULE fft_tools -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||rguenther at suse dot de Keywords|ice-on-invalid-code |ice-on-valid-code Known to fail|4.6.0 |4.5.1 4.6.0 Summary|[4.6 Regression] tree check:|[4.5/4.6 Regression] tree |expected tree that contains |check: expected tree that |�decl minimal� |contains �decl minimal� |structure, have |structure, have |�indirect_ref� in |�indirect_ref� in |gfc_trans_array_bound_check |gfc_trans_array_bound_check Target Milestone|4.6.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #14 from jv244 at cam dot ac dot uk 2010-04-24 17:58 --- (In reply to comment #13) For even more completeness, the code in comment #12 is still invalid. do you mind to clarify ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #16 from jv244 at cam dot ac dot uk 2010-04-24 18:12 --- (In reply to comment #15) pos is undefined. Ah, we're at that level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43866] New: wrong code with -O3 -fbounds-check
compiling the testcase below with gfortran -O3 -fbounds-check yields under 'valgrind --tool=memcheck ./a.out' ==23130== ==23130== Conditional jump or move depends on uninitialised value(s) ==23130==at 0x4008BD: __m1_MOD_cp_fm_upper_to_full (in /data03/vondele/bugs/ttt/a.out) ==23130==by 0x400FD7: MAIN__ (in /data03/vondele/bugs/ttt/a.out) ==23130==by 0x401059: main (fmain.c:21) ==23130== ==23130== ERROR SUMMARY: 16 errors from 1 contexts (suppressed: 3 from 1) the valgrind error is absent if '-O2 -fbounds-check' is being employed. This happens with trunk as well as older versions. Testcase: MODULE M1 INTEGER, PARAMETER :: sp=4, dp=8 TYPE cp_fm_type REAL(KIND=sp), DIMENSION(:,:), POINTER :: local_data_sp REAL(KIND=dp), DIMENSION(:,:), POINTER :: local_data INTEGER :: nrow_global,ncol_global LOGICAL :: use_sp END TYPE CONTAINS SUBROUTINE cp_fm_upper_to_full(matrix,work) TYPE(cp_fm_type), POINTER :: matrix,work INTEGER :: irow_global, ncol_global, nrow_global REAL(KIND = dp), DIMENSION(:,:), POINTER :: a REAL(KIND = sp), DIMENSION(:,:), POINTER :: a_sp nrow_global=matrix%nrow_global ncol_global=matrix%ncol_global a = matrix%local_data a_sp = matrix%local_data_sp DO irow_global=1,nrow_global DO icol_global=irow_global+1,ncol_global IF(matrix%use_sp) THEN a_sp(icol_global,irow_global)=a_sp(irow_global,icol_global) ELSE a(icol_global,irow_global)=a(irow_global,icol_global) ENDIF ENDDO ENDDO END SUBROUTINE cp_fm_upper_to_full END MODULE M1 USE M1 TYPE(cp_fm_type), POINTER :: a,b INTEGER :: N N=17 ALLOCATE(a,b) ALLOCATE(a%local_data(N,N),b%local_data(N,N)) a%nrow_global=N a%ncol_global=N b%nrow_global=N b%ncol_global=N a%use_sp=.FALSE. b%use_sp=.FALSE. a%local_data=0 CALL cp_fm_upper_to_full(a,b) END -- Summary: wrong code with -O3 -fbounds-check Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] wrong code with -fbounds-check -funswitch-loops
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-23 09:21 --- The error also appears with: gfortran -fbounds-check -O1 -funswitch-loops test.f90 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Summary|wrong code with -O3 - |wrong code with -fbounds- |fbounds-check |check -funswitch-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] wrong code with -fbounds-check -funswitch-loops
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-23 09:25 --- reduced testcase: IMPLICIT NONE INTEGER, PARAMETER :: sp=4, dp=8 TYPE cp_fm_type REAL(KIND=sp), DIMENSION(:,:), POINTER :: local_data_sp REAL(KIND=dp), DIMENSION(:,:), POINTER :: local_data INTEGER :: nrow_global,ncol_global LOGICAL :: use_sp END TYPE TYPE(cp_fm_type), POINTER :: amat INTEGER :: N INTEGER :: irow_global, ncol_global, nrow_global, icol_global REAL(KIND = dp), DIMENSION(:,:), POINTER :: a REAL(KIND = sp), DIMENSION(:,:), POINTER :: a_sp N=17 ALLOCATE(amat) ALLOCATE(amat%local_data(N,N)) amat%nrow_global=N amat%ncol_global=N amat%use_sp=.FALSE. amat%local_data=0 nrow_global=amat%nrow_global ncol_global=amat%ncol_global a = amat%local_data a_sp = amat%local_data_sp DO irow_global=1,nrow_global DO icol_global=irow_global+1,ncol_global IF(amat%use_sp) THEN a_sp(icol_global,irow_global)=a_sp(irow_global,icol_global) ELSE a(icol_global,irow_global)=a(irow_global,icol_global) ENDIF ENDDO ENDDO END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] wrong code with -fbounds-check -funswitch-loops
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-23 10:30 --- It looks like in the .optimized dump these: a_sp$offset = amat-local_data_sp.offset; a_sp$dim$1$stride = amat-local_data_sp.dim[1].stride; a_sp$dim$1$ubound = amat-local_data_sp.dim[1].ubound; a_sp$dim$1$lbound = amat-local_data_sp.dim[1].lbound; are indeed accessing fields of local_data_sp even though it never got allocated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] wrong code with -fbounds-check -funswitch-loops
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-23 13:32 --- (In reply to comment #4) Hm, I can't reproduce this. I see, the reduced testcase (comment #2) indeed doesn't fail with trunk anymore, but the original does (but only at -O3 -fbounds-check). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #6 from jv244 at cam dot ac dot uk 2010-04-23 17:29 --- both testcases work with 4.1.2. I've also checked various versions of valgrind, which all report consistent results. Also 4.5 only fails on the original testcase. for reference, -v gives: gcc-4.5/bin/gfortran-4.5 -O3 -fbounds-check -g -static -v t.f90 Driving: gcc-4.5/bin/gfortran-4.5 -O3 -fbounds-check -g -static -v t.f90 -lgfortran -lm Using built-in specs. COLLECT_GCC=gcc-4.5/bin/gfortran-4.5 COLLECT_LTO_WRAPPER=/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /lustre/ESPFS/scratch/pci/vondele/gcc-4.5/gcc-4.5.0/configure --prefix=/home/pci/vondele/gcc-4.5 --enable-languages=c,c++,fortran --program-suffix=-4.5 --disable-multilib --with-gmp=/home/pci/vondele/gcc-4.5 --with-mpfr=/home/pci/vondele/gcc-4.5 --with-mpc=/home/pci/vondele/gcc-4.5 Thread model: posix gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-O3' '-fbounds-check' '-g' '-static' '-v' '-mtune=generic' '-march=x86-64' /panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 t.f90 -quiet -dumpbase t.f90 -mtune=generic -march=x86-64 -auxbase t -g -O3 -version -fbounds-check -fintrinsic-modules-path /panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/cc4wFHAz.s GNU Fortran (GCC) version 4.5.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0, GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.5.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0, GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-O3' '-fbounds-check' '-g' '-static' '-v' '-mtune=generic' '-march=x86-64' as -V -Qy --64 -o /tmp/ccvIH9et.o /tmp/cc4wFHAz.s GNU assembler version 2.16.91.0.5 (x86_64-suse-linux) using BFD version 2.16.91.0.5 20051219 (SUSE Linux) COMPILER_PATH=/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../libexec/gcc/ LIBRARY_PATH=/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/:/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-O3' '-fbounds-check' '-g' '-static' '-v' '-mtune=generic' '-march=x86-64' /panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 -m elf_x86_64 -static /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbeginT.o -L/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0 -L/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc -L/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. /tmp/ccvIH9et.o -lgfortran -lm --start-group -lgcc -lgcc_eh -lc --end-group /panfs/panfs0.ften.es.hpcn.uzh.ch/es/home/pci/vondele/gcc-4.5/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtend.o /usr/lib/../lib64/crtn.o -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.3.1 4.4.0 4.6.0 |4.3.1 4.4.0 4.5.0 4.6.0 Known to work||4.1.2 Summary|wrong code with -fbounds- |[4.3/4.4/4.5/4.6 Regression] |check -funswitch-loops |wrong code with -fbounds- ||check -funswitch-loops Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug fortran/40994] ICE with BIND(C)
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-23 20:17 --- as per comment #4, and reconfirmed for trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-23 20:17:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
[Bug middle-end/43836] New: ice with -fexceptions and -fopenmp
The following causes an ICE: cat bug.f90 MODULE dbcsr_work_operations TYPE dbcsr_type END TYPE dbcsr_type TYPE dbcsr_obj TYPE(dbcsr_type) :: m END TYPE dbcsr_obj CONTAINS SUBROUTINE dbcsr_finalize(matrix) TYPE(dbcsr_obj), INTENT(INOUT) :: matrix !$omp single !$omp parallel num_threads(1) CALL dbcsr_merge_data (matrix%m, sort_data ) !$omp end parallel !$omp end single END SUBROUTINE dbcsr_finalize END MODULE dbcsr_work_operations gfortran -v -c -O0 -fopenmp -fexceptions bug.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_4_4_branch/gcc/configure --prefix=/data03/vondele/gcc_4_4_branch/build --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O0' '-fopenmp' '-fexceptions' '-mtune=generic' '-pthread' /data03/vondele/gcc_4_4_branch/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.4/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -O0 -version -fopenmp -fexceptions -fintrinsic-modules-path /data03/vondele/gcc_4_4_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.4/finclude -o /tmp/ccff06dK.s GNU Fortran (GCC) version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 bug.f90: In function dbcsr_finalize: bug.f90:12: internal compiler error: Segmentation fault -- Summary: ice with -fexceptions and -fopenmp Product: gcc Version: 4.4.4 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug middle-end/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-21 15:30 --- 4.3.1 ([gcc-4_3-branch revision 135036]) does not fail, so marking as regression. 4.5.0 works as well with 4.4.4 I have this backtrace: (gdb) bt #0 bitmap_element_allocate (head=0x10284c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/bitmap.c:206 #1 0x004d076c in bitmap_set_bit (head=0x10284c0, bit=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/bitmap.c:638 #2 0x009ba0b0 in compute_dominance_frontiers (frontiers=0x1028440) at /data03/vondele/gcc_4_4_branch/gcc/gcc/cfganal.c:1278 #3 0x006d5849 in rewrite_into_ssa () at /data03/vondele/gcc_4_4_branch/gcc/gcc/tree-into-ssa.c:2256 #4 0x006171db in execute_one_pass (pass=0xf795c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:1277 #5 0x00617415 in execute_pass_list (pass=0xf795c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:1326 #6 0x00617735 in execute_ipa_pass_list (pass=0xf79800) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:890 #7 0x00805301 in cgraph_optimize () at /data03/vondele/gcc_4_4_branch/gcc/gcc/cgraphunit.c:1237 #8 0x00490d6a in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/fortran/f95-lang.c:240 #9 0x006a7fb4 in toplev_main (argc=value optimized out, argv=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/toplev.c:970 #10 0x7f91de717436 in __libc_start_main () from /lib64/libc.so.6 #11 0x004061a9 in _start () -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.4.4 Known to work||4.3.1 4.5.0 Summary|ice with -fexceptions and - |[4.4 Regression] ice with - |fopenmp |fexceptions and -fopenmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug fortran/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-21 17:53 --- (In reply to comment #2) See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up at PR 43837 beats the speed of light... thanks. A very practical question. Is Fortran code compiled with -fexceptions necessarily miscompiled, or will it behave properly. The reason I'm asking (and found the bug) is that openmpi adds -fexceptions by default via the mpif90 script at compilation time. -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug fortran/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-20 17:53 --- yawn valid testcase here ftp://ftp.berlios.de/pub/cp2k/cp2k.tar.gz -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] New: [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
A recent regression on CP2K for gcc version 4.6.0 20100419 (experimental) [trunk revision 158504] (GCC) with the attached testcase and 'gfortran -c -fbounds-check': 1075.f90: In function sparse_alltoall: 1075.f90:544:0: internal compiler error: tree check: expected tree that contains decl minimal structure, have indirect_ref in gfc_trans_array_bound_check, at fortran/trans-array.c:2339 Please submit a full bug report, reduced testcase to be attached. -- Summary: [4.6 Regression] tree check: expected tree that contains decl minimal structure, have indirect_ref in gfc_trans_array_bound_check Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-19 07:52 --- small enough for pasting: cat bug.f90 MODULE fft_tools INTEGER, PARAMETER :: sp=4, dp=8 INTEGER, PARAMETER :: lp = dp CONTAINS SUBROUTINE sparse_alltoall ( rs, scount, sreq, rq, rcount, rreq, group ) COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rs COMPLEX(KIND=lp), DIMENSION(:, :), POINTER:: rq IF ( rcount(pos) /= 0 ) THEN rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos) END IF END SUBROUTINE sparse_alltoall END MODULE fft_tools -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-19 09:23 --- Dominique, you should ask for 'bugzilla confirmation rights' which will allow to touch the 'Confirm' fields etc... -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.6.0 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-19 09:23:45 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug middle-end/43793] [4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-19 11:56 --- (In reply to comment #6) If you have svn write access you have full bugzilla rights if you use a bugzilla account with your @gcc.gnu.org address. Indeed I don't have svn write access and I am not planning to ask for it in a near future. Is there other ways to 'bugzilla confirmation rights'? Nor do I have svn write access (afaik), but I can confirm/close/etc bugs. I think this was something tobias burnus enabled? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
[Bug fortran/41359] Wrong line numbers for debugging/profiling
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-11 18:02 --- looks like we have a patch... -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359
[Bug fortran/41359] Wrong line numbers for debugging/profiling
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-10 19:04 --- still present in 4.6. The issue seems to be missing location info for the nested if [if (a0) ], the missing info in the original dump appears as a incorrect line:7 in the gimple. It is specific to the 'else if' form, on a single line. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.3.4 4.4.1 4.5.0 |4.3.4 4.4.1 4.5.0 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359
[Bug tree-optimization/43627] New: [4.5 Regression] slow compilation
The to-be-attached file compiles very slowly with 4.5: 4.3 ([gcc-4_3-branch revision 135036]): 37s 4.4 ([gcc-4_4-branch revision 150482]): 30s 4.5 ([trunk revision 157940]):6m35s gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -c hog.f90 -- Summary: [4.5 Regression] slow compilation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-02 08:16 --- Created an attachment (id=20287) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20287action=view) testcase reproduce with gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -c hog.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-02 08:27 --- And a timing report as well (notice the machine is not fully idle). The major consumer is tree canonical. Execution times (seconds) garbage collection: 7.71 ( 2%) usr 0.07 ( 4%) sys 14.12 ( 2%) wall 0 kB ( 0%) ggc callgraph construction: 0.18 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall 6675 kB ( 1%) ggc callgraph optimization: 0.61 ( 0%) usr 0.03 ( 2%) sys 0.61 ( 0%) wall 1655 kB ( 0%) ggc ipa cp: 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 539 kB ( 0%) ggc ipa reference : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.17 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc ipa SRA : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.78 ( 0%) usr 0.01 ( 1%) sys 1.27 ( 0%) wall 3661 kB ( 0%) ggc CFG verifier : 2.10 ( 1%) usr 0.00 ( 0%) sys 3.40 ( 1%) wall 0 kB ( 0%) ggc trivially dead code : 0.38 ( 0%) usr 0.00 ( 0%) sys 0.40 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.59 ( 0%) usr 0.00 ( 0%) sys 0.92 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.86 ( 0%) usr 0.00 ( 0%) sys 1.83 ( 0%) wall 0 kB ( 0%) ggc df live regs : 4.92 ( 1%) usr 0.01 ( 1%) sys 8.23 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 1.48 ( 0%) usr 0.01 ( 1%) sys 3.37 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.71 ( 0%) usr 0.00 ( 0%) sys 1.39 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.15 ( 1%) usr 0.01 ( 1%) sys 7.47 ( 1%) wall 9314 kB ( 1%) ggc register information : 1.29 ( 0%) usr 0.01 ( 1%) sys 3.00 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.64 ( 0%) usr 0.00 ( 0%) sys 0.74 ( 0%) wall 21770 kB ( 3%) ggc alias stmt walking: 1.94 ( 1%) usr 0.06 ( 4%) sys 3.50 ( 1%) wall 0 kB ( 0%) ggc register scan : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.26 ( 0%) wall 0 kB ( 0%) ggc parser: 1.27 ( 0%) usr 0.12 ( 7%) sys 1.50 ( 0%) wall 42200 kB ( 5%) ggc inline heuristics : 0.43 ( 0%) usr 0.02 ( 1%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.69 ( 0%) usr 0.03 ( 2%) sys 0.79 ( 0%) wall 52375 kB ( 6%) ggc tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 9418 kB ( 1%) ggc tree CFG cleanup : 0.49 ( 0%) usr 0.00 ( 0%) sys 0.80 ( 0%) wall 418 kB ( 0%) ggc tree VRP : 2.08 ( 1%) usr 0.05 ( 3%) sys 3.67 ( 1%) wall 54923 kB ( 7%) ggc tree copy propagation : 0.37 ( 0%) usr 0.00 ( 0%) sys 0.59 ( 0%) wall 237 kB ( 0%) ggc tree find ref. vars : 0.07 ( 0%) usr 0.02 ( 1%) sys 0.09 ( 0%) wall 3774 kB ( 0%) ggc tree PTA : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 425 kB ( 0%) ggc tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 315 kB ( 0%) ggc tree SSA rewrite : 0.44 ( 0%) usr 0.03 ( 2%) sys 0.80 ( 0%) wall 20682 kB ( 3%) ggc tree SSA other: 0.22 ( 0%) usr 0.02 ( 1%) sys 0.23 ( 0%) wall 434 kB ( 0%) ggc tree SSA incremental : 0.62 ( 0%) usr 0.04 ( 2%) sys 0.91 ( 0%) wall 438 kB ( 0%) ggc tree operand scan : 0.27 ( 0%) usr 0.14 ( 8%) sys 0.53 ( 0%) wall 21791 kB ( 3%) ggc dominator optimization: 0.42 ( 0%) usr 0.00 ( 0%) sys 0.72 ( 0%) wall 4190 kB ( 1%) ggc tree CCP : 0.56 ( 0%) usr 0.01 ( 1%) sys 0.70 ( 0%) wall 3081 kB ( 0%) ggc tree PHI const/copy prop: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 22 kB ( 0%) ggc tree split crit edges : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 3268 kB ( 0%) ggc tree reassociation: 0.17 ( 0%) usr 0.00 ( 0%) sys 0.36 ( 0%) wall 161 kB ( 0%) ggc tree PRE : 6.54 ( 2%) usr 0.02 ( 1%) sys 11.71 ( 2%) wall 25200 kB ( 3%) ggc tree FRE : 0.76 ( 0%) usr 0.03 ( 2%) sys 1.15 ( 0%) wall 8100 kB ( 1%) ggc tree code sinking : 0.23 ( 0%) usr 0.04 ( 2%) sys 0.44 ( 0%) wall 12275 kB ( 2%) ggc tree linearize phis : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.19 ( 0%) usr 0.01 ( 1%) sys 0.25 ( 0%) wall 9572 kB ( 1%) ggc tree phiprop : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.19 ( 0%) usr 0.02 ( 1%) sys 0.51 ( 0%) wall 17 kB ( 0%) ggc tree aggressive DCE : 0.49 ( 0%) usr 0.01 ( 1%) sys 0.74 ( 0
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 09:26 --- (In reply to comment #3) This tells me you are comparing apples and cows: Extra diagnostic checks enabled; compiler may run slowly. Could you try again with a compiler configured with --enable=checking=release? I'll do now... for reference, 4.4 has: gfortran -ftime-report -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native hog.f90 Execution times (seconds) garbage collection: 0.15 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.33 ( 1%) usr 0.03 ( 4%) sys 0.33 ( 1%) wall 9447 kB ( 2%) ggc callgraph optimization: 0.46 ( 2%) usr 0.01 ( 1%) sys 0.50 ( 2%) wall 239 kB ( 0%) ggc ipa cp: 0.22 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 0 kB ( 0%) ggc ipa reference : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 914 kB ( 0%) ggc trivially dead code : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc df live regs : 0.22 ( 1%) usr 0.00 ( 0%) sys 0.18 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.17 ( 1%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 3443 kB ( 1%) ggc register information : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.14 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 6273 kB ( 1%) ggc register scan : 0.04 ( 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.01 ( 0%) wall 0 kB ( 0%) ggc parser: 1.27 ( 5%) usr 0.12 (16%) sys 1.31 ( 5%) wall 50936 kB ( 9%) ggc inline heuristics : 0.13 ( 1%) usr 0.05 ( 6%) sys 0.25 ( 1%) wall 0 kB ( 0%) ggc tree gimplify : 0.44 ( 2%) usr 0.04 ( 5%) sys 0.54 ( 2%) wall 61550 kB (11%) ggc tree eh : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 9734 kB ( 2%) ggc tree CFG cleanup : 0.28 ( 1%) usr 0.00 ( 0%) sys 0.18 ( 1%) wall 668 kB ( 0%) ggc tree VRP : 1.21 ( 5%) usr 0.03 ( 4%) sys 1.26 ( 5%) wall 42193 kB ( 8%) ggc tree copy propagation : 0.21 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 315 kB ( 0%) ggc tree find ref. vars : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 8937 kB ( 2%) ggc tree PTA : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 758 kB ( 0%) ggc tree alias analysis : 0.12 ( 0%) usr 0.05 ( 6%) sys 0.12 ( 0%) wall 77 kB ( 0%) ggc tree call clobbering : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 18 kB ( 0%) ggc tree flow sensitive alias: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 121 kB ( 0%) ggc tree flow insensitive alias: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree memory partitioning: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 21 kB ( 0%) ggc tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 201 kB ( 0%) ggc tree SSA rewrite : 0.17 ( 1%) usr 0.01 ( 1%) sys 0.13 ( 1%) wall 19668 kB ( 4%) ggc tree SSA other: 0.11 ( 0%) usr 0.03 ( 4%) sys 0.18 ( 1%) wall 360 kB ( 0%) ggc tree SSA incremental : 0.24 ( 1%) usr 0.02 ( 3%) sys 0.25 ( 1%) wall 40 kB ( 0%) ggc tree operand scan : 0.36 ( 1%) usr 0.15 (19%) sys 0.58 ( 2%) wall 27070 kB ( 5%) ggc dominator optimization: 0.26 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 2270 kB ( 0%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.33 ( 1%) usr 0.01 ( 1%) sys 0.24 ( 1%) wall 4060 kB ( 1%) ggc tree reassociation: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 124 kB ( 0%) ggc tree PRE : 5.18 (21%) usr 0.05 ( 6%) sys 5.07 (20%) wall 87699 kB (16%) ggc tree FRE : 0.51 ( 2%) usr 0.00 ( 0%) sys 0.55 ( 2%) wall 7664 kB ( 1%) ggc tree code sinking : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 75 kB ( 0%) ggc tree linearize phis : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.11 ( 0%) usr 0.02 ( 3%) sys 0.11 ( 0%) wall 11274 kB ( 2%) ggc tree phiprop : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-02 09:47 --- (In reply to comment #3) cows with cows now (i.e. --enable-checking=release), on an idle machine. Execution times (seconds) garbage collection: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.11 ( 0%) usr 0.01 ( 1%) sys 0.12 ( 0%) wall 5939 kB ( 1%) ggc callgraph optimization: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 184 kB ( 0%) ggc ipa cp: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 539 kB ( 0%) ggc ipa reference : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.67 ( 0%) usr 0.00 ( 0%) sys 0.83 ( 0%) wall 3661 kB ( 1%) ggc trivially dead code : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.35 ( 0%) usr 0.00 ( 0%) sys 0.36 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.69 ( 0%) usr 0.00 ( 0%) sys 0.65 ( 0%) wall 0 kB ( 0%) ggc df live regs : 3.08 ( 1%) usr 0.00 ( 0%) sys 3.07 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 1.17 ( 0%) usr 0.00 ( 0%) sys 1.07 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.53 ( 0%) usr 0.00 ( 0%) sys 0.35 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 2.50 ( 1%) usr 0.00 ( 0%) sys 2.73 ( 1%) wall 9314 kB ( 1%) ggc register information : 1.05 ( 0%) usr 0.00 ( 0%) sys 0.84 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.58 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 21770 kB ( 3%) ggc alias stmt walking: 1.29 ( 0%) usr 0.04 ( 4%) sys 1.36 ( 0%) wall 0 kB ( 0%) ggc register scan : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 0 kB ( 0%) ggc parser: 1.15 ( 0%) usr 0.12 (11%) sys 1.26 ( 0%) wall 42200 kB ( 6%) ggc inline heuristics : 0.24 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.43 ( 0%) usr 0.05 ( 4%) sys 0.47 ( 0%) wall 52375 kB ( 8%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 9418 kB ( 1%) ggc tree CFG cleanup : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.46 ( 0%) wall 418 kB ( 0%) ggc tree VRP : 1.57 ( 1%) usr 0.06 ( 5%) sys 1.60 ( 1%) wall 54731 kB ( 8%) ggc tree copy propagation : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.29 ( 0%) wall 237 kB ( 0%) ggc tree find ref. vars : 0.03 ( 0%) usr 0.01 ( 1%) sys 0.10 ( 0%) wall 3774 kB ( 1%) ggc tree PTA : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 423 kB ( 0%) ggc tree PHI insertion: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 315 kB ( 0%) ggc tree SSA rewrite : 0.24 ( 0%) usr 0.02 ( 2%) sys 0.19 ( 0%) wall 20682 kB ( 3%) ggc tree SSA other: 0.10 ( 0%) usr 0.04 ( 4%) sys 0.19 ( 0%) wall 434 kB ( 0%) ggc tree SSA incremental : 0.56 ( 0%) usr 0.02 ( 2%) sys 0.66 ( 0%) wall 438 kB ( 0%) ggc tree operand scan : 0.21 ( 0%) usr 0.20 (18%) sys 0.42 ( 0%) wall 21791 kB ( 3%) ggc dominator optimization: 0.35 ( 0%) usr 0.01 ( 1%) sys 0.36 ( 0%) wall 4189 kB ( 1%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.49 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 3081 kB ( 0%) ggc tree PHI const/copy prop: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 22 kB ( 0%) ggc tree split crit edges : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 3265 kB ( 0%) ggc tree reassociation: 0.12 ( 0%) usr 0.01 ( 1%) sys 0.11 ( 0%) wall 161 kB ( 0%) ggc tree PRE : 4.88 ( 2%) usr 0.00 ( 0%) sys 4.89 ( 2%) wall 25200 kB ( 4%) ggc tree FRE : 0.65 ( 0%) usr 0.02 ( 2%) sys 0.67 ( 0%) wall 8099 kB ( 1%) ggc tree code sinking : 0.16 ( 0%) usr 0.05 ( 4%) sys 0.17 ( 0%) wall 12275 kB ( 2%) ggc tree linearize phis : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 9572 kB ( 1%) ggc tree phiprop : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.21 ( 0%) usr 0.03 ( 3%) sys 0.15 ( 0%) wall 17 kB ( 0%) ggc tree aggressive DCE : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 2998 kB ( 0%) ggc tree DSE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-02 12:28 --- (In reply to comment #6) What's your native arch? I can't reproduce this on a core i?86. -v output: /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 hog.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase hog.f90 -auxbase hog -g -O3 -version -fbounds-check -ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccA2YvFn.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-02 14:07 --- Created an attachment (id=20290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290action=view) smaller testcase (needs 3s, 80% in tree canonical iv) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)
--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-02 14:17 --- (In reply to comment #9) Created an attachment (id=20290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290action=view) [edit] smaller testcase (needs 3s, 80% in tree canonical iv) from valgrind, I see some 1300 cals to get_val_for / fold_binary_loc, for the small testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug bootstrap/43615] New: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
My usual routine to build gcc-trunk started failing yesterday (or the day before)? The configure has remained unchanged (notice --disable-multilib --disable-bootstrap): /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/ The error seems to be: -fvisibility=hidden -DHIDE_EXPORTS /data/vondele/gcc_bench/gcc_trunk/obj/./gcc/xgcc -B/data/vondele/gcc_bench/gcc_trunk/obj/./gcc/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/bin/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/lib/ -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/include -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/. -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../include -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:354:0, from /usr/include/stdio.h:28, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/tsystem.h:87, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/32/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-multi] Error 2 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj' make: *** [all] Error 2 -- Summary: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-01 07:06 --- svn versions: last known good: 157842 first known bad: 157896 CCing a RM -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Summary|bootstrap fails:|[4.5 Regression] bootstrap |/usr/include/gnu/stubs.h:7:2|fails: |7: fatal error: gnu/stubs- |/usr/include/gnu/stubs.h:7:2 |32.h: No such file or |7: fatal error: gnu/stubs- |directory |32.h: No such file or ||directory Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-01 12:41 --- Created an attachment (id=20273) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20273action=view) log of the build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #6 from jv244 at cam dot ac dot uk 2010-04-01 12:42 --- (In reply to comment #4) The bug reporter explicitly specified --disable-multilib, yet gcc-4.5 apparently now tries to build libgcc with -m32. right... you've been faster. I've added the logs of the build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug fortran/42607] add information about how to compile a module
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 05:29 --- (In reply to comment #2) I think .mod files are not obvious; the standard does not say anything about them, though (almost?) all compilers use them. On the other hand, few people seem to have problems with .mod files. the current Cray compiler (from cce) does not have modules, the mod info ends up in the .o files. one thing that could be documented about the gfortran mod files is that they are left untouched if possible. We use that in our makefile to avoid recompilation cascades. This is actually an important feature for developers, since it makes gfortran much faster for development than many of the other compilers. Furthermore, the fact that left-over mod files from older/newer gfortran compilers leads to user-visible error messages could also be worth documenting (At least state that even though .o, .a and .so files might be 'ABI-compatible' over several versions of the compiler, .mod files a specific to even a minor version of the compiler). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607
[Bug fortran/43591] internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #2 from jv244 at cam dot ac dot uk 2010-03-30 17:58 --- confirmed. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-30 17:58:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43592] New: Unexpected INTERFACE statement in INTERFACE block at (1)
cat small.f90 interface assignment (=) interface pseudo_scalar pure function double_tensor2odd (x, t2) result (xt2) gfortran small.f90 small.f90:2.25: interface pseudo_scalar 1 Error: Unexpected INTERFACE statement in INTERFACE block at (1) f951: 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. -- Summary: Unexpected INTERFACE statement in INTERFACE block at (1) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43592
