[Bug fortran/25681] ICE with len of array of derived type

2006-04-27 Thread jv244 at cam dot ac dot uk
--- Comment #9 from jv244 at cam dot ac dot uk 2006-04-27 12:53 --- > [Adding Joost in CC list] Thanks. Any idea if it runs properly with the patch in place (have a look at the script cp2k/tools/do_regtest for setting up a testing run) ? -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug middle-end/27373] New: ICE: add_virtual_operand, at tree-ssa-operands.c:1284

2006-05-01 Thread jv244 at cam dot ac dot uk
le-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27373

[Bug fortran/25095] Disallowed intrinsic in initialization statement

2006-06-04 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2006-06-04 10:42 --- (In reply to comment #1) > .. and > each operation shall be intrinsic > Now, MODULO is found under 13.5 (Standard generic intrinsic procedures) But MODULO is not an intrinsic operation (these are defined

[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html

2006-06-12 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2006-06-12 07:18 --- (In reply to comment #0) still failing ... since it has been opened about 2.5y ago, should it be closed as wontfix ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821

[Bug target/35366] [4.4 Regression] gfortran.dg/equiv_7.f90 fails with -m64 -Os on powerpc-apple-darwin9

2008-11-11 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-11 16:08 --- just a note on the patch posted: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00407.html the fortran standard guarantees that E==TRANSFER(TRANSFER(E,D),E) if the physical representation of D and E is the same length

[Bug fortran/38065] private/public confusion with a contained function

2008-11-11 Thread jv244 at cam dot ac dot uk
--- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 14:14 --- (In reply to comment #7) > As best I can see, your reduction of the problem is not correct; in it > subroutine S1 should be private, not public. I don't think so. See your code, S1 ~ GeomMTF, which is

[Bug fortran/36928] array temporary for interleaving assignment

2008-11-14 Thread jv244 at cam dot ac dot uk
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last

[Bug fortran/36933] unneeded temporary with derived type containing an array as argument

2008-11-14 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-14 08:34 --- This could be somewhat similar, I really wonder if this needs a temp: TYPE T1 INTEGER :: a(3) END TYPE T1 TYPE(T1), POINTER :: x,y ALLOCATE(x,y) x%a=y%a END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933

[Bug fortran/38111] New: unneeded temporary

2008-11-14 Thread jv244 at cam dot ac dot uk
: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 36854 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111

[Bug fortran/38112] New: unneeded temporary

2008-11-14 Thread jv244 at cam dot ac dot uk
Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 36854 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112

[Bug fortran/38112] unneeded temporary

2008-11-14 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-14 08:50 --- that might be an even simpler case: SUBROUTINE S(a,i,j) INTEGER, POINTER, DIMENSION(:) :: a INTEGER, DIMENSION(:), ALLOCATABLE :: b INTEGER :: i,j ALLOCATE(b(10)) b(i:j)=a(i:j) END SUBROUTINE S -- http

[Bug fortran/38113] New: -Warray-temporaries output

2008-11-14 Thread jv244 at cam dot ac dot uk
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=38113

[Bug fortran/38114] New: unneeded temp

2008-11-14 Thread jv244 at cam dot ac dot uk
Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 36854 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114

[Bug fortran/38115] New: unneeded temp

2008-11-14 Thread jv244 at cam dot ac dot uk
AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 36854 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115

[Bug fortran/38115] unneeded temp

2008-11-14 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-14 09:07 --- I guess this one is similar enough to put here as well: SUBROUTINE S1(a,i,j,k,m) INTEGER :: a(3,6) write(6,*) ALL(a(1:3,m).EQ.(/i,j,k/)) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115

[Bug fortran/38114] unneeded temp

2008-11-19 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:08 --- (In reply to comment #1) > SUBROUTINE S(b,i,j) > INTEGER, DIMENSION(:) :: b > integer res(1) > INTEGER :: i,j > res = MINLOC(b(i:j)) > END SUBROUTINE S right.. the 'orginal' testcase was. A

[Bug fortran/38111] unneeded temporary

2008-11-19 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:18 --- (In reply to comment #1) > Do you know of any compilers that catch this? As you say, it is not so easy > to > fix. I believe ifort gets this right (compiled with 'ifort -S -heap-arrays 64), but this i

[Bug fortran/38181] New: calls to SIZE not optimized out of loops

2008-11-19 Thread jv244 at cam dot ac dot uk
ent: 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=38181

[Bug fortran/38181] calls to SIZE not optimized out of loops

2008-11-20 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 08:53 --- so I guess this is up to the front end to generate 'better' code for size -- jv244 at cam dot ac dot uk changed: What|Removed

[Bug fortran/38181] calls to SIZE not optimized out of loops

2008-11-20 Thread jv244 at cam dot ac dot uk
--- Comment #7 from jv244 at cam dot ac dot uk 2008-11-20 11:03 --- (In reply to comment #6) great.. thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181

[Bug fortran/38115] unneeded temp

2008-11-20 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 18:54 --- (In reply to comment #3) > duplicate of pr36935? similar enough to make this one depend on PR36935. I think the testcases here (certainly comment #1), are more difficult. -- jv244 at cam dot ac dot uk chan

[Bug fortran/38303] New: poor error message

2008-11-28 Thread jv244 at cam dot ac dot uk
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=38303

[Bug fortran/38303] poor error message

2008-11-28 Thread jv244 at cam dot ac dot uk
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303

[Bug target/38306] New: [4.4 Regression] 15% slowdown of computational kernel

2008-11-28 Thread jv244 at cam dot ac dot uk
dot org ReportedBy: jv244 at cam dot ac dot uk GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306

[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel

2008-11-28 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-28 16:01 --- Created an attachment (id=16788) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16788&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306

[Bug fortran/38312] New: poor error message

2008-11-28 Thread jv244 at cam dot ac dot uk
y: poor error message Product: gcc Version: 4.4.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=38312

[Bug fortran/38318] New: moving the allocation of temps out of loops.

2008-11-29 Thread jv244 at cam dot ac dot uk
-- Summary: moving the allocation of temps out of loops. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org Re

[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel

2008-11-30 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-30 16:17 --- (In reply to comment #2) > Due to the high density of branches in the code this is easily a code layout > and/or padding issue. Different architectures have different constraints on > their decoders a

[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel

2008-11-30 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2008-11-30 16:26 --- (In reply to comment #4) > 4.3: > -O3 -march=native -funroll-loops -ffast-math ==> 4.376 > -O3 -march=native -funroll-loops -ffast-math -fschedule-insns ==> 3.372 strangely: htt

[Bug fortran/38351] New: poor error message

2008-12-01 Thread jv244 at cam dot ac dot uk
.4.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=38351

[Bug rtl-optimization/38403] New: [4.4 Regression] unable to find a register to spill in class �CREG� with -fschedule-insns

2008-12-04 Thread jv244 at cam dot ac dot uk
FIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-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=38403

[Bug rtl-optimization/38403] [4.4 Regression] unable to find a register to spill in class �CREG� with -fschedule-insns

2008-12-04 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-04 16:10 --- Created an attachment (id=16824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16824&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403

[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures

2008-12-04 Thread jv244 at cam dot ac dot uk
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-04 16:11 --- I tried -fschedule-insns on CP2K, which lead to an ICE (now PR38403) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306

[Bug rtl-optimization/38403] [4.4 Regression] unable to find a register to spill in class �CREG� with -fschedule-insns

2008-12-04 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-04 16:16 --- Created an attachment (id=16825) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16825&action=view) shorter testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403

[Bug rtl-optimization/38403] [4.4 Regression] unable to find a register to spill in class �CREG� with -fschedule-insns

2008-12-04 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-04 16:21 --- Created an attachment (id=16826) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16826&action=view) 99 lines ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403

[Bug rtl-optimization/38403] [4.4 Regression] unable to find a register to spill in class �CREG� with -fschedule-insns

2008-12-04 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-04 17:22 --- (In reply to comment #4) > I would suggest you don't spend too much time on reducing a test case, and > just > stop using -fschedule-insns on x86*. There is a reason why it is not enabled > by defaul

[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)

2008-12-05 Thread jv244 at cam dot ac dot uk
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-05 16:25 --- Timings in 4.4 are essentially unchanged gfortran -O3 -ffast-math -march=native PR25621.f90: default loop 1.29208100 hand optimized loop 0.864053988 fun enough inverse timings with a recent

[Bug fortran/25096] Non-conforming shapes of DATA object and data

2008-12-05 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-05 16:26 --- still fails with 4.4 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

2008-12-05 Thread jv244 at cam dot ac dot uk
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-05 16:28 --- updated testcase still fails: subroutine a(p) type t integer :: t1 end type type(t) :: p p%t1 = 42 end subroutine subroutine b type u integer :: u1 end type type (u) :: q call a(q) write(6

[Bug fortran/34663] Specification expression is defined by dummy variables of different entry points

2008-12-05 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-05 16:30 --- still fails in 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34663

[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures

2008-12-06 Thread jv244 at cam dot ac dot uk
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-06 18:54 --- (In reply to comment #10) > If the code layout (see comment #2) is indeed causing the slow-down, this > problem might have been fixed along with bug 38074. No, timings are still identical: gcc version 4.4.0 20

[Bug middle-end/38431] New: [graphite] several ICEs with CP2K

2008-12-06 Thread jv244 at cam dot ac dot uk
s with CP2K Product: gcc Version: 4.4.0 Status: UNCONFIRMED 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=38431

[Bug fortran/38444] New: poor error message

2008-12-08 Thread jv244 at cam dot ac dot uk
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=38444

[Bug fortran/38444] poor error message

2008-12-08 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-08 18:39 --- (In reply to comment #1) > - gfc_error (msg, sym->name, where, gfc_basic_typename > (sym->ts.type)); > + gfc_fatal_error (msg, sym->name, where, > + gf

[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html

2008-12-08 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-08 19:34 --- | \ ' / -- (*) -- >*<

[Bug middle-end/38431] [graphite] several ICEs with CP2K

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-09 08:42 --- Tobias, you might be interested to check if your recent patch also fixed these bugs. Otherwise I should be able to give it a round of testing before the weekend. -- jv244 at cam dot ac dot uk changed

[Bug middle-end/38431] [graphite] several ICEs with CP2K

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-09 19:41 --- This is a simple testcase for one of the first segfaults, observed with current graphite branch: gfortran -c -O2 -ffree-form -fgraphite -fgraphite-identity test.f90 test.f90: In function ‘matmov’: test.f90:1: internal

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-09 20:43 --- (In reply to comment #0) similar stack trace for the segfault in harris_force_types.F: 0 0x2b3cbe554066 in realloc () from /lib64/libc.so.6 #1 0x2b3cbd66098c in __gmp_default_reallocate () from /usr/lib64

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-09 20:46 --- (In reply to comment #0) similar for fft_tools.F 0x2ad42b5a4507 in __gmpz_set () from /usr/lib64/libgmp.so.3 (gdb) bt #0 0x2ad42b5a4507 in __gmpz_set () from /usr/lib64/libgmp.so.3 #1 0x2ad42b7d2dfc in

[Bug middle-end/38461] New: [graphite] internal compiler error: verify_ssa failed

2008-12-09 Thread jv244 at cam dot ac dot uk
lebedev.F fails with: scratch/vondele/clean/cp2k/src/../src/lebedev.F: In function ‘load_sub_grid’: /scratch/vondele/clean/cp2k/src/../src/lebedev.F:156: error: definition in block 18 does not dominate use in block 16 for SSA_NAME: PARM_NOALIAS.233_1989 in statement: # VUSE pretmp.462_1908 = *lgn

[Bug middle-end/38461] [graphite] internal compiler error: verify_ssa failed

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-09 21:01 --- Created an attachment (id=16864) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16864&action=view) testcase reduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38461

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-09 21:02 --- lebedev.F on PR38461 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-09 21:04 --- similar for gamma.F #0 0x2b69b539a066 in realloc () from /lib64/libc.so.6 #1 0x2b69b44a698c in __gmp_default_reallocate () from /usr/lib64/libgmp.so.3 #2 0x2b69b44bba21 in __gmpz_realloc () from /usr

[Bug middle-end/38463] New: [graphite] double free or corruption

2008-12-09 Thread jv244 at cam dot ac dot uk
-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 38431 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #6 from jv244 at cam dot ac dot uk 2008-12-09 21:11 --- ps_wavelet_util.F is now PR38463 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38463] [graphite] double free or corruption

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-09 21:12 --- note that this trace also goes via cloog_clast_create so that might be a dup of PR38459 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463

[Bug middle-end/38463] [graphite] double free or corruption

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-09 21:18 --- Created an attachment (id=16865) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16865&action=view) testcase reduced. at least, graphite tends to fail on code that is easy to reduce. -- http://gcc.

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #6 from jv244 at cam dot ac dot uk 2008-12-09 21:22 --- same for cp_cfm_basic_linalg.F #0 0x2ad7ad43d066 in realloc () from /lib64/libc.so.6 #1 0x2ad7ac54998c in __gmp_default_reallocate () from /usr/lib64/libgmp.so.3 #2 0x2ad7ac55ea21 in __gmpz_realloc

[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create

2008-12-09 Thread jv244 at cam dot ac dot uk
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-09 21:44 --- (In reply to comment #5) > I do already know about this bug, this is id-2.f90 problem. OK, guess it is rather frequent in that case, following files trigger it as well: ps_wavelet_kernel.F ai_moment

[Bug middle-end/38474] New: slow compilation at -O0 (callgraph optimization, inline heuristics, ggc expand )

2008-12-10 Thread jv244 at cam dot ac dot uk
ddle-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=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, ggc expand )

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-10 15:25 --- Created an attachment (id=16873) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-10 16:13 --- (In reply to comment #2) > Confirmed. 4.3 is worse (I ran out of memory). > > Probably the FE presents us with sth funny. > actually, I just got a timing report from 4.3 [4.3.1 20080507 (prerelease) [gc

[Bug middle-end/38463] [graphite] double free or corruption

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-10 22:04 --- (In reply to comment #3) > Hi, I can not reproduce this Bug on FreeBSD. May be it is just not detected. > > Can you try with current graphite branch to see it was a duplicate of > Bug3845384599. > O

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-10 22:33 --- with current graphite, i see 4 files failing with -fgraphite -fgraphite-identity: lebedev.F, colvar_types.F, qs_linres_nmr_shift.F, constraint_clv.F I'm assuming that these are all incarnations of PR38461, bu

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-10 22:34 --- (In reply to comment #4) > Could you capture the memory requirements on the 4.3 branch? I watched top (for 4.3.1), but can't recall anything more than 3Gb. It's a bit boring to watch top for 45min..

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-10 Thread jv244 at cam dot ac dot uk
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-10 22:57 --- (In reply to comment #6) > Created an attachment (id=16881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16881&action=view) [edit] > memory measurement tool > > Of course! Try the attached w

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #8 from jv244 at cam dot ac dot uk 2008-12-11 08:27 --- (In reply to comment #6) > Created an attachment (id=16881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16881&action=view) [edit] > memory measurement tool > > Of course! Try the attached w

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-11 12:02 --- (In reply to comment #9) > The script only has received testing on linux systems, so if you are running > somewhere else it is likely that either the regexps do not match or that > you require different/a

[Bug middle-end/38461] [graphite] internal compiler error: verify_ssa failed

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-11 19:16 --- fixed with the current graphite branch. -- jv244 at cam dot ac dot uk changed: What|Removed |Added

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #8 from jv244 at cam dot ac dot uk 2008-12-11 19:19 --- (In reply to comment #7) > with current graphite, i see 4 files failing with -fgraphite > -fgraphite-identity: > > lebedev.F, colvar_types.F, qs_linres_nmr_shift.F, constraint_clv.F > all fixed with c

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-11 20:17 --- Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchang' goes generate an executable, but it is miscompiled and segfaults. It can be reproduced with the testcase in t

[Bug middle-end/38492] New: [grapite] segfaulting code when compiled with -fgraphite -fgraphite-identity

2008-12-11 Thread jv244 at cam dot ac dot uk
nedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 38431 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492

[Bug middle-end/38492] [grapite] segfaulting code when compiled with -fgraphite -fgraphite-identity

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-11 21:39 --- Created an attachment (id=16891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16891&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-11 Thread jv244 at cam dot ac dot uk
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-11 21:41 --- (In reply to comment #9) > Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine > -floop-interchang' goes generate an executable, but it is miscompiled and > segfaults.

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-13 Thread jv244 at cam dot ac dot uk
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-13 08:39 --- (In reply to comment #10) > (In reply to comment #9) > > Unfortunately, '-fgraphite -fgraphite-identity -floop-block > > -floop-strip-mine > > -floop-interchang' goes generate an execut

[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity

2008-12-13 Thread jv244 at cam dot ac dot uk
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-13 11:18 --- (In reply to comment #3) > Fixed. > This still fails here: gfortran -v -O2 -g -ffree-form -fgraphite -fgraphite-identity -cpp -D__FFTSG PR38492.f90 gcc version 4.4.0 20081110 (experimental) [graphite re

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #13 from jv244 at cam dot ac dot uk 2008-12-15 17:31 --- (In reply to comment #12) > Could you try with the addition of " -fno-strict-aliasing > -fno-strict-overflow"? See pr38520. The testcase in PR38492 indeed works if I use: gfortran -O2 -ffast-mat

[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-15 17:32 --- As suggest in PR38431, works fine with: gfortran -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -fgraphite -fgraphite-identity -cpp -D__FFTSG -fno-strict-overflow test.f90 -- http://gcc.gnu.org

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #14 from jv244 at cam dot ac dot uk 2008-12-15 19:06 --- (In reply to comment #13) > > (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code. OK, full code compiles & runs the test example with -fgraphite -fgraphite-identity -fno-

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-15 19:38 --- as this file is included in a project compiled normally with '-O3 -march=native -funroll-loops' the timing in that case is also important. As I'm finding out, this becomes unworkable (>6h, a

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #15 from jv244 at cam dot ac dot uk 2008-12-15 19:44 --- (In reply to comment #14) > OK, full code compiles & runs the test example with -fgraphite > -fgraphite-identity -fno-strict-overflow compiling with -g -O2 -ffast-math -funroll-loops -ftree-vectorize -ma

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-15 Thread jv244 at cam dot ac dot uk
--- Comment #17 from jv244 at cam dot ac dot uk 2008-12-16 07:51 --- (In reply to comment #16) > Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me. Thanks for the analysis. Detailed enough to have me peak in the gcc code for once. This would mean that the ar

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #18 from jv244 at cam dot ac dot uk 2008-12-16 11:58 --- (In reply to comment #17) > BTW, the -O3 compilation is still running (for 17h now). finished successfully after 23h... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #25 from jv244 at cam dot ac dot uk 2008-12-16 16:17 --- doing some more profiling, the -O0 problem is to a large extend due to compute_inline_parameters and estimate_stack_frame_size. Spending 10-30min just on estimating the stack_frame_size on something that can'

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #27 from jv244 at cam dot ac dot uk 2008-12-16 16:29 --- the slow routines at -O3 are related to compute_may_aliases, at the point I interupted the profiling, this routine had called add_virtual_operand 200M times. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #20 from jv244 at cam dot ac dot uk 2008-12-16 12:47 --- (In reply to comment #19) > Re. comment #18, I'd say "brilliant" if it wasn't such a poor performance :-) I agree... quite an achievement not to crash in such a case. > Did you manage to get

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #24 from jv244 at cam dot ac dot uk 2008-12-16 14:20 --- (In reply to comment #23) reduced testcase timings at -O0 and -O3. Tree operand scan anybody? > time gfortran -O0 -ffree-line-length-512 -c -ftime-report testcase_reduced.f90 Execution times (seconds) garb

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #21 from jv244 at cam dot ac dot uk 2008-12-16 12:48 --- (In reply to comment #16) > Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me. btw, that routine only has 3800 user variables, the rests are FE generated temporaries (which should have a limi

[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #23 from jv244 at cam dot ac dot uk 2008-12-16 14:17 --- Created an attachment (id=16913) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16913&action=view) reduced testcase just so we talk about the same file, I've reduced the testcase to more managable siz

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-16 Thread jv244 at cam dot ac dot uk
--- Comment #29 from jv244 at cam dot ac dot uk 2008-12-17 06:50 --- doing the original testcase again at -O3 has been a useful exercise i think. 13.5h is spent in rename_registers, 2h in tree operand scan, ~1h in inline heuristics, and 20min in expand. (Note that this is a 4.3 based

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-17 Thread jv244 at cam dot ac dot uk
--- Comment #31 from jv244 at cam dot ac dot uk 2008-12-17 08:36 --- (In reply to comment #30) > I think redoing this with 4.4.0 would be useful, to check if new code (like > IRA) uses this kind of non-linear algorithms. But the register renaming patch > hasn't changed b

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-17 Thread jv244 at cam dot ac dot uk
--- Comment #32 from jv244 at cam dot ac dot uk 2008-12-17 12:58 --- The 9.3Gb for 4.4 is confirmed. I attached gdb to the process at that point (after about 70min of compilation), and that is the backtrace: #0 0x00b48a9a in bucket_allocno_compare_func (v1p=0x7fffe3592d98, v2p

[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity

2008-12-18 Thread jv244 at cam dot ac dot uk
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-19 00:43 --- (In reply to comment #6) > I looked into this failure. It fails because the number of iterations cannot > be > computed (chrec_unknown) when the loop domain is translated, and is ignored by > scan_tree_fo

[Bug middle-end/38474] [4.3/4.4 Regression] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )

2008-12-20 Thread jv244 at cam dot ac dot uk
--- Comment #34 from jv244 at cam dot ac dot uk 2008-12-20 08:58 --- BTW, should I split this PR in 4 sub PRs, and make them block this one? 1) inline heuristics (4.3/4.4 Regression) 2) IRA mem explosion (4.4 Regression) 3) rename registers issue (?) 4) may_alias issue (?) This makes

[Bug middle-end/38582] New: excessive time in rename registers

2008-12-20 Thread jv244 at cam dot ac dot uk
d at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 38474 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582

[Bug rtl-optimization/38583] New: [4.4 Regression] ira memory explosion

2008-12-20 Thread jv244 at cam dot ac dot uk
-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 38474 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38583

[Bug middle-end/38584] New: [4.3/4.4 Regression] Inline heuristics

2008-12-20 Thread jv244 at cam dot ac dot uk
Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 38474 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584

[Bug middle-end/38585] New: excessive time in compute_may_aliases

2008-12-20 Thread jv244 at cam dot ac dot uk
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 OtherBugsDependingO 38474 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug middle-end/38586] New: quadratic behaviour in find_temp_slot_from_address.

2008-12-20 Thread jv244 at cam dot ac dot uk
: gcc Version: 4.4.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 OtherBugsDepen

  1   2   3   4   5   6   7   8   9   10   >