--- Comment #7 from jv244 at cam dot ac dot uk 2009-02-13 21:00 ---
(In reply to comment #6)
Not a gcc bug so closing as invalid.
The gcc 'bug' is that -fopenmp -static should link to pthreads as
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or
error
--- Comment #13 from jv244 at cam dot ac dot uk 2009-02-11 19:25 ---
(In reply to comment #12)
/* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
make the problem with not enough registers even worse. */
As risky as this may be (for performance
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-07 15:32 ---
(In reply to comment #5)
I guess that since Richard says that it's a problem, we had better confirm
it:-)
Do we need a bugzilla field 'confirmatio ad verecundiam' ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #10 from jv244 at cam dot ac dot uk 2009-02-07 07:50 ---
(In reply to comment #9)
Confirmed with gcc 4.3. Where do we stand today?
same place:
gfortran -O3 -march=native -ffast-math -ffree-form -ftree-vectorize
gcc version 4.4.0 20090207 (experimental) (GCC)
./a.out
--- Comment #10 from jv244 at cam dot ac dot uk 2009-02-04 20:53 ---
(In reply to comment #9)
I hope to patch it soon although I have no such patch right now.
Hi Jan,
any progress on this one ? I've a core to analyze, but I'm stuck here.
Joost
--
http://gcc.gnu.org/bugzilla
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
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=39073
--- Comment #1 from jv244 at cam dot ac dot uk 2009-02-02 08:59 ---
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,fortran
--disable-multilib
--- Comment #4 from jv244 at cam dot ac dot uk 2009-02-02 09:49 ---
(In reply to comment #3)
thanks for the reduced testcase... will help :-)
Hmm, maybe this is only a gdb bug / missing feature.
just as a note, I tried gdb 6.8 and it failed as well.
--
http://gcc.gnu.org
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-02 11:09 ---
(In reply to comment #5)
The generated unwind info looks good to me, so it is likely a gdb issue.
1) how does one get this generated unwind info (I'd like to see what is
different from 4.3)?
2) Do you see a way
--- Comment #8 from jv244 at cam dot ac dot uk 2009-02-02 12:14 ---
(In reply to comment #7)
2) report this to gdb and help them fix it.
OK, I've at least been able to add a PR for this in the gdb bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=9806
--
http
Status: UNCONFIRMED
Keywords: 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
--- Comment #3 from jv244 at cam dot ac dot uk 2009-01-16 14:38 ---
(In reply to comment #2)
Also for -march=native you should really post what -fverbose-asm tells you has
been selected for -march and other option (and you should retry with those
options instead of -march=native
--- Comment #35 from jv244 at cam dot ac dot uk 2009-01-14 10:51 ---
(In reply to comment #33)
Attached a fix for this PR. I will regstrap and submit for review.
while I'll apply it to current trunk, retest CP2K, and update this PR with the
results.
Thanks,
Joost
--
http
--- Comment #36 from jv244 at cam dot ac dot uk 2009-01-14 12:08 ---
(In reply to comment #35)
(In reply to comment #33)
Attached a fix for this PR. I will regstrap and submit for review.
while I'll apply it to current trunk, retest CP2K, and update this PR with the
results
--- Comment #2 from jv244 at cam dot ac dot uk 2009-01-15 05:56 ---
looks like this always failed ?
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from jv244 at cam dot ac dot uk 2009-01-15 06:05 ---
doesn't fail in 4.4.0 and 4.3.1.
Since this refers to an 'old' version of trunk (i.e. 4.4. in full development),
I'll close this as fixed. If the problem remains with an up-to-date trunk, or
on any active release
--- Comment #29 from jv244 at cam dot ac dot uk 2009-01-13 20:33 ---
(In reply to comment #28)
the graphite branch. However I'm not able to run the test that you
reported failing:
./cp2k.sopt canonical.inp
CP2K: The specified file canonical.inp can not be opened, it does
--- Comment #32 from jv244 at cam dot ac dot uk 2009-01-14 06:49 ---
(In reply to comment #30)
Subject: Re: [graphite] several ICEs with CP2K (summary)
Thanks for the clarification, I managed to reproduce the fail. The
problem comes from the fact that we do not generate code
in
reserve_phi_args_for_new_edge
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
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-12 17:39 ---
things really have a random flavor right now. I have a bt for a segfault from
gdb, within a couple of minutes now:
[ repeats about 4000 times]
#4011 0x0049267d in gt_ggc_mx_lang_tree_node (x_p=value
--- Comment #25 from jv244 at cam dot ac dot uk 2009-01-11 12:30 ---
(In reply to comment #22)
Program received signal SIGSEGV, Segmentation fault.
__mc_moves_MOD_change_bond_length () at
/scratch/vondele/clean/cp2k/src/../src/mc_moves.F:1434
1434 atom_b(:)=0
I had
--- Comment #26 from jv244 at cam dot ac dot uk 2009-01-11 12:58 ---
(In reply to comment #25)
I'll see if I
can narrow down the problem to the single subroutine (change_bond_length)
which
I suspect is the issue. [all of this with trunk 143207]
yes, just looking
--- Comment #20 from jv244 at cam dot ac dot uk 2009-01-08 19:30 ---
(In reply to comment #19)
Could you try to run again the make
test and report the status of CP2K?
Hi Sebastian,
the testcase provide runs fine (AFAICT) with current trunk. I'll run the full
CP2K testsuite to test
--- Comment #22 from jv244 at cam dot ac dot uk 2009-01-09 05:38 ---
(In reply to comment #21)
Thanks for testing. Can you close the bug after the CP2K testsuite passes?
unfortunately, there is still one runtime segfault, I have no reduced testcase
so far, but this is the backtrace
--- Comment #23 from jv244 at cam dot ac dot uk 2009-01-09 06:16 ---
Created an attachment (id=17062)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17062action=view)
additional cp2k input
With this CP2K testcase the segfault can be reproduced. After building cp2k,
just run
--- Comment #24 from jv244 at cam dot ac dot uk 2009-01-09 06:18 ---
(In reply to comment #22)
Program received signal SIGSEGV, Segmentation fault.
__mc_moves_MOD_change_bond_length () at
/scratch/vondele/clean/cp2k/src/../src/mc_moves.F:1434
1434 atom_b(:)=0
additional
--- Comment #16 from jv244 at cam dot ac dot uk 2009-01-07 19:07 ---
I checked that current trunk (i.e. not graphite branch) still generates a
segfaulting executable with
FCFLAGS = -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree-form -fgraphite -fgraphite
org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 38431
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38760
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-07 20:49 ---
Created an attachment (id=17050)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17050action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38760
--- Comment #2 from jv244 at cam dot ac dot uk 2009-01-07 20:50 ---
FYI, it is the assignment at line 22 that 'goes wrong'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38760
--- Comment #18 from jv244 at cam dot ac dot uk 2009-01-07 20:52 ---
(In reply to comment #17)
Thanks for the update. I suspect that this is due to -floop-block.
There are two more bugs 38559 and 38499 that we're looking at for
fixing -floop-block.
yes, I was able to derive a small
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-05 16:18 ---
Created an attachment (id=17033)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17033action=view)
testcase
gfortran -O1 -fbounds-check -ftime-report PR38729.f90
to reproduce.
--
http://gcc.gnu.org/bugzilla
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38729
Status: UNCONFIRMED
Keywords: accepts-invalid
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=38733
--- Comment #5 from jv244 at cam dot ac dot uk 2009-01-04 14:58 ---
(In reply to comment #2)
If the module files cause problems, I can try to get to a source file only
reproducer
http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz can be used as a
source files only testcase
--- Comment #7 from jv244 at cam dot ac dot uk 2009-01-04 15:18 ---
(In reply to comment #6)
Does not fail for me on i686-pc-cygwin with gcc version 4.4.0 20090103
(experimental) [trunk revision 143030]. What target are you compiling for?
Using built-in specs.
Target: x86_64
--- Comment #2 from jv244 at cam dot ac dot uk 2009-01-04 14:19 ---
testcase:
http://www.pci.uzh.ch/vandevondele/tmp/PR38722.tgz
untar, and reproduce with
gfortran -v -c -O1 -cpp bug.f90
If the module files cause problems, I can try to get to a source file only
reproducer
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-04 14:10 ---
For gcc version 4.4.0 20090104 (experimental) [trunk revision 143050] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--- Comment #3 from jv244 at cam dot ac dot uk 2009-01-04 14:26 ---
The ICE only happens at -O1 and not at -O0 or -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--- Comment #15 from jv244 at cam dot ac dot uk 2009-01-05 05:55 ---
Created an attachment (id=17032)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17032action=view)
testcase without module dependencies
based on Steven's testcase
gfortran -c -O1 reduced.f90
reduced.f90
--- Comment #8 from jv244 at cam dot ac dot uk 2009-01-02 18:57 ---
(In reply to comment #7)
Subject: Re: problem with contained subprocedure.
Hello,
This appears to be the problem. In any case, I just submitted a new archive
file. I hope this one's correct
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #17 from jv244 at cam dot ac dot uk 2008-12-22 08:18 ---
reopening as of PR38582 (where rename registers takes 13 hours to do its job).
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-21 08:05 ---
(In reply to comment #2)
Without this patch, (total 3868s).
With the patch, (total 588s).
Great...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
--- 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
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
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
OtherBugsDependingO
--- Comment #36 from jv244 at cam dot ac dot uk 2008-12-20 11:30 ---
I've added
PR38582 : rename registers
PR38583 : ira
PR38584 : inline heuristic
PR38585 : compute_may_aliases
PR38586 : find_temp_slot_from_address
and turned this one in a meta bug.
--
jv244 at cam dot ac dot uk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38583
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-20 11:32 ---
affects both 4.3 and 4.4
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target
--- 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_for_params
--- 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 between 4.3 and 4.4
--- 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 #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't
--- 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 a time report out of that run
--- 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)
garbage
--- 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 limited lifetime
--- 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=16913action=view)
reduced testcase
just so we talk about the same file, I've reduced the testcase to more
managable sizes. This one
--
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 #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-math -funroll-loops -ftree
--- 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-strict-overflow
--- 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, and still compiling).
Looking
--- 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 -march=native
--- 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 array
--- 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 executable, but it is miscompiled
--- 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 revision 142738
--- 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=16881action=view) [edit]
memory measurement tool
Of course! Try the attached with just
~/bin/maxmem2
--- 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/additional
--- 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 current graphite
--- 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 the initial
: 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=16891action=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.
reduced testcase
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=16873action=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)
[gcc-4_3-branch
--- 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.
Otherwise I will have
--- 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, but can
--- 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 any better
--- 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=16881action=view) [edit]
memory measurement tool
Of course! Try the attached with just
~/bin/maxmem2
--- 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
: normal
Priority: P3
Component: middle-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=38461
--- 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=16864action=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
401 - 500 of 1178 matches
Mail list logo
