--- 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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=150079
Log:
2009-07-25 Richard Guenther
PR fortran/40005
--- 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 #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=18252&action=view)
patch fixing this PR
I've checked that Richard's latest version still fixes this PR, works fine with
CP2K, and boo
--- 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 #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 origin
--- 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 ca
--- 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 #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 #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 #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:
/data03/
--- 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 #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 n
--- 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
--
h
--- 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 #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 #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 cgraph_finalize_compilat
--- 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.
--
http:/
--- 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_functi
--- 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 2n
--- 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]
(x86_64-unknown-linux-
--- 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 #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 #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 #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 #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 #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=) at ./gt-fortran-f95-lang.h:33
--- 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 ((*x).generic.type.next_vari
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 19:37 ---
This is not a new problem - our recursive GC manages to do this in some cases.
What helps sometimes is to adjust the way structures are linked to avoid too
deep recursion. Maybe the GFortran FE trees are not optimi
--- Comment #7 from jv244 at cam dot ac dot uk 2009-05-03 19:14 ---
(In reply to comment #5)
> Does it work if you increase the default stack limit? ulimit -s unlimited
trunk does indeed pass with ulimit -s and 4.4.0 as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=400
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-03 18:59 ---
(In reply to comment #4)
> Do you have any idea of what change to g2k might have caused this? Even with
> no optimization, it brings my Core 2 Quad to a complete halt. The fact that it
> is garbage handling is worrying
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 17:52 ---
Does it work if you increase the default stack limit? ulimit -s unlimited
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #4 from pault at gcc dot gnu dot org 2009-05-03 17:14 ---
(In reply to comment #3)
> with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90
> things compile file (and need some 6Gb of memory).
>
Joost,
Do you have any idea of what change to g2k might hav
--- 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
--- 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 #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
-
39 matches
Mail list logo
