--- Comment #36 from jv244 at cam dot ac dot uk 2009-07-25 11:03 ---
Created an attachment (id=18252)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18252action=view)
patch fixing this PR
I've checked that Richard's latest version still fixes this PR, works fine with
CP2K, and
--- Comment #37 from rguenth at gcc dot gnu dot org 2009-07-25 11:11
---
I'm running bootstrap and regtests now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-07-25 13:45
---
Subject: Bug 40005
Author: rguenth
Date: Sat Jul 25 13:44:57 2009
New Revision: 150079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150079
Log:
2009-07-25 Richard Guenther rguent...@suse.de
PR
--- Comment #39 from rguenth at gcc dot gnu dot org 2009-07-25 13:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-24 11:56
---
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their
--- Comment #21 from jv244 at cam dot ac dot uk 2009-07-24 12:27 ---
(In reply to comment #20)
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-24 15:32
---
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before cgraph_finalize_compilation_unit?
Thanks.
--
--- Comment #23 from jv244 at cam dot ac dot uk 2009-07-24 15:43 ---
(In reply to comment #22)
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-24 15:46
---
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-24 15:54
---
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
Index: gcc/fortran/trans-types.c
--- Comment #26 from jv244 at cam dot ac dot uk 2009-07-24 16:04 ---
(In reply to comment #24)
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
Well, there are two bugs. The first one is gone with your
'cgraph_finalize_function (ftn_main, true)' change
--
--- Comment #27 from jv244 at cam dot ac dot uk 2009-07-24 16:05 ---
(In reply to comment #25)
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
this fixes the segfault, but I now
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-07-24 16:12
---
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #29 from jv244 at cam dot ac dot uk 2009-07-24 16:48 ---
(In reply to comment #28)
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
Yep... goes fine now
arghh... further testing on standard sources (-g?) reveals:
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-07-24 16:51
---
Hmm, that looks unrelated ...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #31 from jv244 at cam dot ac dot uk 2009-07-24 16:56 ---
(In reply to comment #30)
Hmm, that looks unrelated ...?
doesn't seem to happen on a clean trunk ( a few days more recent ). This is a
reduced testcase for this failure:
gfortran -g bug.f90
bug.f90: In function
--- Comment #32 from jv244 at cam dot ac dot uk 2009-07-24 17:00 ---
(In reply to comment #31)
doesn't seem to happen on a clean trunk ( a few days more recent )
it is definitely caused by the current patch (i.e. reverting it fixes the
issue):
Index: trans-types.c
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-07-24 17:14
---
Yeah, it's caused by the change. We don't generate a real proper copy (we
don't copy the fields so their context is wrong). Previously only a single
debug-info copy was emitted via using TYPE_MAIN_VARIANT.
We
--- Comment #34 from jv244 at cam dot ac dot uk 2009-07-24 17:31 ---
(In reply to comment #33)
We can work around this by also doing
TYPE_MAIN_VARIANT (fat_type) = base_type;
though that's a bit hairy ... (does it still solve your oroginal problem
then?)
yes, the original
--- Comment #35 from rguenth at gcc dot gnu dot org 2009-07-24 19:14
---
Ok, less hacky is the following.
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c.orig 2009-07-24 21:13:28.0 +0200
--- Comment #19 from jv244 at cam dot ac dot uk 2009-07-21 07:54 ---
still fails with gcc version 4.5.0 20090721 (experimental) [trunk revision
149846] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #18 from jv244 at cam dot ac dot uk 2009-06-20 17:37 ---
*** Bug 38814 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-05-29 03:00
---
Yes I am going to be still looking into this. I just had other things to do
first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #16 from jv244 at cam dot ac dot uk 2009-05-09 14:57 ---
tried once running under valgrind, but that doesn't give more info, no errors
till the point of the stack overflow:
GNU Fortran (GCC) version 4.5.0 20090509 (experimental) [trunk revision 147317]
--- Comment #15 from jv244 at cam dot ac dot uk 2009-05-07 14:32 ---
(In reply to comment #13)
Is there a self contained (one file) source that I could use?
have you had a chance to look into the issue / is there anything I can help
with ? I'd like to get this ready for -fwhole-file
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-05-05 20:45
---
(In reply to comment #11)
I have a gdb session open, but I'm rather clueless. I have this:
but the following fails:
(gdb) call debug_tree((*x).generic.type.next_variant)
Cannot access memory at address
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-05-05 20:47
---
Is there a self contained (one file) source that I could use? Gfortran is known
to emit a lot of blocks inside blocks and I wonder if this is the cause. And
the GC is only setup to do chaining through the sibling
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-06 04:36 ---
(In reply to comment #13)
Is there a self contained (one file) source that I could use? Gfortran is
known
to emit a lot of blocks inside blocks and I wonder if this is the cause. And
the GC is only setup to do
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 ---
This is the outermost stack trace to the segfault (with default 8M stack),
shows the depth of the recursion, and the location:
#174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized
out) at
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-04 04:39 ---
(In reply to comment #8)
Thus, the question is what are we recursing on here? type.next_variant
if my sources are matching yours (look at gt-fortran-f95-lang.h:337).
gt_ggc_m_9tree_node
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-02 12:22 ---
not specific to 4.5, also fails with
gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-02 12:43 ---
also 4.3.3. fails
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail|4.4.0
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:44 ---
with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90
things compile file (and need some 6Gb of memory).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
34 matches
Mail list logo
