--- 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.
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
--- 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
--- 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
--- 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
--- 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
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
: 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
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
--- 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
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
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
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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
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
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303
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
--- 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
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
--
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
--- 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
--- 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
.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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
--- 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
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-08 19:34 ---
|
\ ' /
-- (*) --
>*<
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
-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
--- 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
--- 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
--- 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.
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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..
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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-
--- 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
--- 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
--- 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
--- 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
--- 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'
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--- 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
--- 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
--- 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
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
-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
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
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
: 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 - 100 of 1193 matches
Mail list logo