* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
@ 2009-05-02 12:22 ` jv244 at cam dot ac dot uk
2009-05-02 12:43 ` jv244 at cam dot ac dot uk
` (37 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-02 12:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
----------------------------------------------------------------------------
Known to fail| |4.4.0 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
2009-05-02 12:22 ` [Bug fortran/40005] " jv244 at cam dot ac dot uk
@ 2009-05-02 12:43 ` jv244 at cam dot ac dot uk
2009-05-02 13:44 ` jv244 at cam dot ac dot uk
` (36 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-02 12:43 UTC (permalink / raw)
To: gcc-bugs
------- 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 4.5.0 |4.3.3 4.4.0 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
2009-05-02 12:22 ` [Bug fortran/40005] " jv244 at cam dot ac dot uk
2009-05-02 12:43 ` jv244 at cam dot ac dot uk
@ 2009-05-02 13:44 ` jv244 at cam dot ac dot uk
2009-05-03 17:15 ` pault at gcc dot gnu dot org
` (35 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-02 13:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:44 -------
with gfortran -c -O0 --param ggc-min-heapsize=3200000 CP2K_2009-05-01.f90
things compile file (and need some 6Gb of memory).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (2 preceding siblings ...)
2009-05-02 13:44 ` jv244 at cam dot ac dot uk
@ 2009-05-03 17:15 ` pault at gcc dot gnu dot org
2009-05-03 17:52 ` rguenth at gcc dot gnu dot org
` (34 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pault at gcc dot gnu dot org @ 2009-05-03 17:15 UTC (permalink / raw)
To: gcc-bugs
------- 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=3200000 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 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 and maybe indicates that it may be something
other than the fortran frontend.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (3 preceding siblings ...)
2009-05-03 17:15 ` pault at gcc dot gnu dot org
@ 2009-05-03 17:52 ` rguenth at gcc dot gnu dot org
2009-05-03 18:59 ` jv244 at cam dot ac dot uk
` (33 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-05-03 17:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (4 preceding siblings ...)
2009-05-03 17:52 ` rguenth at gcc dot gnu dot org
@ 2009-05-03 18:59 ` jv244 at cam dot ac dot uk
2009-05-03 19:14 ` jv244 at cam dot ac dot uk
` (32 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-03 18:59 UTC (permalink / raw)
To: gcc-bugs
------- 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 and maybe indicates that it may be something
> other than the fortran frontend.
No idea what change in CP2K could have triggered this. I have been using a
similar test based on CP2K_2007_06, and that thus not seem to trigger this
error. I think it is a front-end issue, as it definitely still has not yet
finished writing the .mod files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (5 preceding siblings ...)
2009-05-03 18:59 ` jv244 at cam dot ac dot uk
@ 2009-05-03 19:14 ` jv244 at cam dot ac dot uk
2009-05-03 19:37 ` rguenth at gcc dot gnu dot org
` (31 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-03 19:14 UTC (permalink / raw)
To: gcc-bugs
------- 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=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (6 preceding siblings ...)
2009-05-03 19:14 ` jv244 at cam dot ac dot uk
@ 2009-05-03 19:37 ` rguenth at gcc dot gnu dot org
2009-05-04 4:39 ` jv244 at cam dot ac dot uk
` (30 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-05-03 19:37 UTC (permalink / raw)
To: gcc-bugs
------- 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 optimized for that?
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).
What type do we have so many variants of?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (7 preceding siblings ...)
2009-05-03 19:37 ` rguenth at gcc dot gnu dot org
@ 2009-05-04 4:39 ` jv244 at cam dot ac dot uk
2009-05-04 7:12 ` jv244 at cam dot ac dot uk
` (29 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-04 4:39 UTC (permalink / raw)
To: gcc-bugs
------- 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_variant);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (8 preceding siblings ...)
2009-05-04 4:39 ` jv244 at cam dot ac dot uk
@ 2009-05-04 7:12 ` jv244 at cam dot ac dot uk
2009-05-04 7:49 ` jv244 at cam dot ac dot uk
` (28 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-04 7:12 UTC (permalink / raw)
To: gcc-bugs
------- 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 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174700 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174701 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174702 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174703 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174704 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:337
#174705 0x000000000052884d in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:213
#174706 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:315
#174707 0x0000000000528831 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:211
#174708 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:315
#174709 0x00000000005283d9 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:314
#174710 0x00000000005283d9 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:314
#174711 0x0000000000528041 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:457
#174712 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:315
#174713 0x0000000000528519 in gt_ggc_mx_lang_tree_node (x_p=<value optimized
out>) at ./gt-fortran-f95-lang.h:291
#174714 0x00000000006f6955 in gt_ggc_mx_cgraph_node (x_p=<value optimized out>)
at gtype-desc.c:228
#174715 0x00000000006f6a76 in gt_ggc_m_P11cgraph_node4htab (x_p=<value
optimized out>) at gtype-desc.c:2142
#174716 0x00000000006c0bce in ggc_mark_roots () at
/data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107
#174717 0x0000000000572108 in ggc_collect () at
/data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941
#174718 0x0000000000543253 in gfc_generate_function_code (ns=0x3603e890) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4140
#174719 0x00000000005298eb in gfc_generate_module_code (ns=<value optimized
out>)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1322
#174720 0x00000000004f6404 in gfc_parse_file () at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3865
#174721 0x0000000000526bbd in gfc_be_parse_file (set_yydebug=<value optimized
out>)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236
#174722 0x00000000007f39b4 in toplev_main (argc=13, argv=0x7fff5db02a88) at
/data03/vondele/gcc_trunk/gcc/gcc/toplev.c:977
#174723 0x00007f9454765436 in __libc_start_main () from /lib64/libc.so.6
#174724 0x0000000000499679 in _start ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (9 preceding siblings ...)
2009-05-04 7:12 ` jv244 at cam dot ac dot uk
@ 2009-05-04 7:49 ` jv244 at cam dot ac dot uk
2009-05-05 20:45 ` pinskia at gcc dot gnu dot org
` (27 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-04 7:49 UTC (permalink / raw)
To: gcc-bugs
------- 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 = 0,
readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0,
nowarning_flag = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0,
deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, type =
0x0}, values = 0x7f94536c6780, size = 0x7f9453fada80,
size_unit = 0x7f9453e43cc0, attributes = 0x0, uid = 769447, precision = 0,
mode = BLKmode, string_flag = 0, no_force_blk_flag = 0,
needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0,
restrict_flag = 0, contains_placeholder_bits = 0,
lang_flag_0 = 0, lang_flag_1 = 1, lang_flag_2 = 0, lang_flag_3 = 0,
lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
user_align = 0, align = 64, alias_set = -1, pointer_to = 0x0, reference_to =
0x0, symtab = {address = 0, pointer = 0x0, die = 0x0},
name = 0x7f9452151150, minval = 0x0, maxval = 0x0, next_variant =
0x7f941d7c60c0, main_variant = 0x7f9453d66e40, binfo = 0x0,
context = 0x0, canonical = 0x7f9453d66e40, lang_specific = 0x7f941d7c7600}
but the following fails:
(gdb) call debug_tree((*x).generic.type.next_variant)
Cannot access memory at address 0x7fff5d302f78
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (10 preceding siblings ...)
2009-05-04 7:49 ` jv244 at cam dot ac dot uk
@ 2009-05-05 20:45 ` pinskia at gcc dot gnu dot org
2009-05-05 20:48 ` pinskia at gcc dot gnu dot org
` (26 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-05-05 20:45 UTC (permalink / raw)
To: gcc-bugs
------- 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 0x7fff5d302f78
That is because gdb uses the same stack as the program when doing a call so of
course that will fail :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (11 preceding siblings ...)
2009-05-05 20:45 ` pinskia at gcc dot gnu dot org
@ 2009-05-05 20:48 ` pinskia at gcc dot gnu dot org
2009-05-06 4:37 ` jv244 at cam dot ac dot uk
` (25 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-05-05 20:48 UTC (permalink / raw)
To: gcc-bugs
------- 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 blocks not the
subblocks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (12 preceding siblings ...)
2009-05-05 20:48 ` pinskia at gcc dot gnu dot org
@ 2009-05-06 4:37 ` jv244 at cam dot ac dot uk
2009-05-07 14:32 ` jv244 at cam dot ac dot uk
` (24 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-06 4:37 UTC (permalink / raw)
To: gcc-bugs
------- 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 chaining through the sibling blocks not the
> subblocks.
yes, please, see the link in the first comment of the PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (13 preceding siblings ...)
2009-05-06 4:37 ` jv244 at cam dot ac dot uk
@ 2009-05-07 14:32 ` jv244 at cam dot ac dot uk
2009-05-09 14:57 ` jv244 at cam dot ac dot uk
` (23 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-07 14:32 UTC (permalink / raw)
To: gcc-bugs
------- 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 compilation :-)
--
jv244 at cam dot ac dot uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (14 preceding siblings ...)
2009-05-07 14:32 ` jv244 at cam dot ac dot uk
@ 2009-05-09 14:57 ` jv244 at cam dot ac dot uk
2009-05-29 3:00 ` pinskia at gcc dot gnu dot org
` (22 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-05-09 14:57 UTC (permalink / raw)
To: gcc-bugs
------- 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-gnu)
compiled by GNU C version 4.5.0 20090509 (experimental) [trunk revision
147317], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==27399== Stack overflow in thread 1: can't grow stack to 0x7FE801FF8
==27399== Can't extend stack to 0x7FE801700 during signal delivery for thread
1:
==27399== no stack segment
==27399==
==27399== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==27399== Access not within mapped region at address 0x7FE801700
==27399== at 0x529DC8: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:46)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (15 preceding siblings ...)
2009-05-09 14:57 ` jv244 at cam dot ac dot uk
@ 2009-05-29 3:00 ` pinskia at gcc dot gnu dot org
2009-06-20 17:37 ` jv244 at cam dot ac dot uk
` (21 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-05-29 3:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (16 preceding siblings ...)
2009-05-29 3:00 ` pinskia at gcc dot gnu dot org
@ 2009-06-20 17:37 ` jv244 at cam dot ac dot uk
2009-07-21 7:54 ` jv244 at cam dot ac dot uk
` (20 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-06-20 17:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (17 preceding siblings ...)
2009-06-20 17:37 ` jv244 at cam dot ac dot uk
@ 2009-07-21 7:54 ` jv244 at cam dot ac dot uk
2009-07-24 11:56 ` rguenth at gcc dot gnu dot org
` (19 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-21 7:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (18 preceding siblings ...)
2009-07-21 7:54 ` jv244 at cam dot ac dot uk
@ 2009-07-24 11:56 ` rguenth at gcc dot gnu dot org
2009-07-24 12:28 ` jv244 at cam dot ac dot uk
` (18 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 11:56 UTC (permalink / raw)
To: gcc-bugs
------- 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 2nd argument.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-07-24 11:56:05
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (19 preceding siblings ...)
2009-07-24 11:56 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 12:28 ` jv244 at cam dot ac dot uk
2009-07-24 15:33 ` rguenth at gcc dot gnu dot org
` (17 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 12:28 UTC (permalink / raw)
To: gcc-bugs
------- 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 should have true as their 2nd argument.
>
Richard,
I tried this change, and now it segfaults later, I guess past the frontend.
#174670 0x0000000000530d51 in gt_ggc_mx_lang_tree_node (
x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:461
#174671 0x0000000000531127 in gt_ggc_mx_lang_tree_node (
x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:320
#174672 0x0000000000531259 in gt_ggc_mx_lang_tree_node (
x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:295
#174673 0x00000000006fb2d5 in gt_ggc_mx_cgraph_node (x_p=<value optimized out>)
at gtype-desc.c:264
#174674 0x00000000006fb43e in gt_ggc_m_P11cgraph_node4htab (
x_p=<value optimized out>) at gtype-desc.c:2207
#174675 0x00000000006c396f in ggc_mark_roots ()
---Type <return> to continue, or q <return> to quit---
at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:137
#174676 0x000000000057e636 in ggc_collect ()
at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1944
#174677 0x0000000000756de5 in execute_todo (flags=19)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1057
#174678 0x0000000000757083 in execute_one_pass (pass=0x11c9640)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1309
#174679 0x0000000000757255 in execute_pass_list (pass=0x11c9640)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1335
#174680 0x000000000084adb9 in tree_lowering_passes (fn=<value optimized out>)
at /data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:345
#174681 0x00000000009ae512 in cgraph_lower_function (node=0x7f2d97042600)
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:501
#174682 0x00000000009aed7b in cgraph_analyze_function (node=0x7f2d97042600)
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:814
#174683 0x00000000009b14e6 in cgraph_analyze_functions ()
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:953
#174684 0x00000000009b1840 in cgraph_finalize_compilation_unit ()
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1039
#174685 0x000000000071c44d in write_global_declarations ()
at /data03/vondele/gcc_trunk/gcc/gcc/langhooks.c:314
#174686 0x00000000007fa0db in toplev_main (argc=13, argv=0x7fff001a91b8)
at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:1039
---Type <return> to continue, or q <return> to quit---
#174687 0x00007f2df6e0e436 in __libc_start_main () from /lib64/libc.so.6
#174688 0x000000000049b2f9 in _start ()
Just for reference:
Index: trans-decl.c
===================================================================
--- trans-decl.c (revision 149846)
+++ trans-decl.c (working copy)
@@ -2023,7 +2023,7 @@
current_function_decl = NULL_TREE;
- cgraph_finalize_function (thunk_fndecl, false);
+ cgraph_finalize_function (thunk_fndecl, true);
/* We share the symbols in the formal argument list with other entry
points and the master function. Clear them so that they are
@@ -4104,7 +4104,7 @@
/* Output the GENERIC tree. */
dump_function (TDI_original, ftn_main);
- cgraph_finalize_function (ftn_main, false);
+ cgraph_finalize_function (ftn_main, true);
if (old_context)
{
@@ -4375,7 +4375,7 @@
added to our parent's nested function list. */
(void) cgraph_node (fndecl);
else
- cgraph_finalize_function (fndecl, false);
+ cgraph_finalize_function (fndecl, true);
gfc_trans_use_stmts (ns);
gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (20 preceding siblings ...)
2009-07-24 12:28 ` jv244 at cam dot ac dot uk
@ 2009-07-24 15:33 ` rguenth at gcc dot gnu dot org
2009-07-24 15:43 ` jv244 at cam dot ac dot uk
` (16 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 15:33 UTC (permalink / raw)
To: gcc-bugs
------- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (21 preceding siblings ...)
2009-07-24 15:33 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 15:43 ` jv244 at cam dot ac dot uk
2009-07-24 15:46 ` rguenth at gcc dot gnu dot org
` (15 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 15:43 UTC (permalink / raw)
To: gcc-bugs
------- 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_compilation_unit?
>
cgraph_finalize_compilation_unit is reached first. After a continue gcc_collect
is reached quickly, and an additional cont leads to the segfault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (22 preceding siblings ...)
2009-07-24 15:43 ` jv244 at cam dot ac dot uk
@ 2009-07-24 15:46 ` rguenth at gcc dot gnu dot org
2009-07-24 15:54 ` rguenth at gcc dot gnu dot org
` (14 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 15:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (23 preceding siblings ...)
2009-07-24 15:46 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 15:54 ` rguenth at gcc dot gnu dot org
2009-07-24 16:04 ` jv244 at cam dot ac dot uk
` (13 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 15:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
===================================================================
--- gcc/fortran/trans-types.c.orig 2009-07-24 17:54:08.000000000 +0200
+++ gcc/fortran/trans-types.c 2009-07-24 17:53:51.000000000 +0200
@@ -1602,7 +1602,7 @@ gfc_get_array_type_bounds (tree etype, i
int n;
base_type = gfc_get_array_descriptor_base (dimen);
- fat_type = build_variant_type_copy (base_type);
+ fat_type = build_distinct_type_copy (base_type);
tmp = TYPE_NAME (etype);
if (tmp && TREE_CODE (tmp) == TYPE_DECL)
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (24 preceding siblings ...)
2009-07-24 15:54 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 16:04 ` jv244 at cam dot ac dot uk
2009-07-24 16:05 ` jv244 at cam dot ac dot uk
` (12 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 16:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (25 preceding siblings ...)
2009-07-24 16:04 ` jv244 at cam dot ac dot uk
@ 2009-07-24 16:05 ` jv244 at cam dot ac dot uk
2009-07-24 16:13 ` rguenth at gcc dot gnu dot org
` (11 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 16:05 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
------- 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 get:
gfortran -c CP2K_2009-05-01.f90
CP2K_2009-05-01.f90: In function ‘debug_ewald_multipole_low’:
CP2K_2009-05-01.f90:632848:0: error: non-trivial conversion at assignment
struct array2_integer(kind=4)
struct array2_integer(kind=4)
list = neighbor_kind_pair->list;
CP2K_2009-05-01.f90:632848:0: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (26 preceding siblings ...)
2009-07-24 16:05 ` jv244 at cam dot ac dot uk
@ 2009-07-24 16:13 ` rguenth at gcc dot gnu dot org
2009-07-24 16:48 ` jv244 at cam dot ac dot uk
` (10 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 16:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (27 preceding siblings ...)
2009-07-24 16:13 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 16:48 ` jv244 at cam dot ac dot uk
2009-07-24 16:51 ` rguenth at gcc dot gnu dot org
` (9 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 16:48 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
------- 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/vondele/clean/cp2k/src/../src/util.F: In function ‘sort_cm’:
/data03/vondele/clean/cp2k/src/../src/util.F:204:0: internal compiler error: in
splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (28 preceding siblings ...)
2009-07-24 16:48 ` jv244 at cam dot ac dot uk
@ 2009-07-24 16:51 ` rguenth at gcc dot gnu dot org
2009-07-24 16:57 ` jv244 at cam dot ac dot uk
` (8 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 16:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (29 preceding siblings ...)
2009-07-24 16:51 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 16:57 ` jv244 at cam dot ac dot uk
2009-07-24 17:00 ` jv244 at cam dot ac dot uk
` (7 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 16:57 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
------- 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 ‘str_search’:
bug.f90:32:0: internal compiler error: in splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
> cat bug.f90
MODULE string_utilities
CONTAINS
SUBROUTINE xstring(string,ia,ib)
CHARACTER(LEN=*), INTENT(IN) :: string
INTEGER, INTENT(OUT) :: ia, ib
ia = 1
ib = LEN_TRIM(string)
IF (ib>0) THEN
DO WHILE (string(ia:ia)==' ')
ia = ia + 1
END DO
END IF
END SUBROUTINE xstring
FUNCTION str_comp(str1,str2) RESULT (equal)
CHARACTER(LEN=*), INTENT(IN) :: str1, str2
LOGICAL :: equal
INTEGER :: i1, i2, j1, j2
i1 = 0
i2 = 0
j1 = 0
j2 = 0
CALL xstring(str1,i1,i2)
CALL xstring(str2,j1,j2)
equal = (str1(i1:i2)==str2(j1:j2))
END FUNCTION str_comp
FUNCTION str_search(str1,n,str2) RESULT (pos)
CHARACTER(LEN=*), INTENT(IN) :: str1( : )
INTEGER, INTENT(IN) :: n
CHARACTER(LEN=*), INTENT(IN) :: str2
INTEGER :: pos
INTEGER :: i
pos = 0
DO i = 1, n
IF (str_comp(str1(i),str2)) THEN
pos = i
EXIT
END IF
END DO
END FUNCTION str_search
END MODULE string_utilities
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (30 preceding siblings ...)
2009-07-24 16:57 ` jv244 at cam dot ac dot uk
@ 2009-07-24 17:00 ` jv244 at cam dot ac dot uk
2009-07-24 17:14 ` rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 17:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
===================================================================
--- trans-types.c (revision 149846)
+++ trans-types.c (working copy)
@@ -1602,7 +1602,8 @@
int n;
base_type = gfc_get_array_descriptor_base (dimen);
- fat_type = build_variant_type_copy (base_type);
+ fat_type = build_distinct_type_copy (base_type);
+ TYPE_CANONICAL (fat_type) = base_type;
tmp = TYPE_NAME (etype);
if (tmp && TREE_CODE (tmp) == TYPE_DECL)
Index: trans-decl.c
===================================================================
--- trans-decl.c (revision 149846)
+++ trans-decl.c (working copy)
@@ -2023,7 +2023,7 @@
current_function_decl = NULL_TREE;
- cgraph_finalize_function (thunk_fndecl, false);
+ cgraph_finalize_function (thunk_fndecl, true);
/* We share the symbols in the formal argument list with other entry
points and the master function. Clear them so that they are
@@ -4104,7 +4104,7 @@
/* Output the GENERIC tree. */
dump_function (TDI_original, ftn_main);
- cgraph_finalize_function (ftn_main, false);
+ cgraph_finalize_function (ftn_main, true);
if (old_context)
{
@@ -4375,7 +4375,7 @@
added to our parent's nested function list. */
(void) cgraph_node (fndecl);
else
- cgraph_finalize_function (fndecl, false);
+ cgraph_finalize_function (fndecl, true);
gfc_trans_use_stmts (ns);
gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (31 preceding siblings ...)
2009-07-24 17:00 ` jv244 at cam dot ac dot uk
@ 2009-07-24 17:14 ` rguenth at gcc dot gnu dot org
2009-07-24 17:31 ` jv244 at cam dot ac dot uk
` (5 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 17:14 UTC (permalink / raw)
To: gcc-bugs
------- 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 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?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (32 preceding siblings ...)
2009-07-24 17:14 ` rguenth at gcc dot gnu dot org
@ 2009-07-24 17:31 ` jv244 at cam dot ac dot uk
2009-07-24 19:14 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-24 17:31 UTC (permalink / raw)
To: gcc-bugs
------- 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 still compiles fine, and a couple of different CP2K builds
also pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (33 preceding siblings ...)
2009-07-24 17:31 ` jv244 at cam dot ac dot uk
@ 2009-07-24 19:14 ` rguenth at gcc dot gnu dot org
2009-07-25 11:03 ` jv244 at cam dot ac dot uk
` (3 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-24 19:14 UTC (permalink / raw)
To: gcc-bugs
------- 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.000000000 +0200
+++ gcc/fortran/trans-types.c 2009-07-24 21:13:05.000000000 +0200
@@ -1602,7 +1602,9 @@ gfc_get_array_type_bounds (tree etype, i
int n;
base_type = gfc_get_array_descriptor_base (dimen);
- fat_type = build_variant_type_copy (base_type);
+ fat_type = build_distinct_type_copy (base_type);
+ TYPE_CANONICAL (fat_type) = base_type;
+ TYPE_STUB_DECL (fat_type) = TYPE_STUB_DECL (base_type);
tmp = TYPE_NAME (etype);
if (tmp && TREE_CODE (tmp) == TYPE_DECL)
I think that is the right thing to do (together with the GC patch). So
if it passes bootstrap & testing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (34 preceding siblings ...)
2009-07-24 19:14 ` rguenth at gcc dot gnu dot org
@ 2009-07-25 11:03 ` jv244 at cam dot ac dot uk
2009-07-25 11:12 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-07-25 11:03 UTC (permalink / raw)
To: gcc-bugs
------- 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 bootstraps (but I can't run make check because of missing dejagnu
here).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (35 preceding siblings ...)
2009-07-25 11:03 ` jv244 at cam dot ac dot uk
@ 2009-07-25 11:12 ` rguenth at gcc dot gnu dot org
2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-25 11:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-07-24 11:56:05 |2009-07-25 11:11:52
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (36 preceding siblings ...)
2009-07-25 11:12 ` rguenth at gcc dot gnu dot org
@ 2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-25 13:45 UTC (permalink / raw)
To: gcc-bugs
------- 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 <rguenther@suse.de>
PR fortran/40005
* trans-types.c (gfc_get_array_type_bounds): Use
build_distinct_type_copy with a proper TYPE_CANONICAL and
re-use the type-decl of the original type.
* trans-decl.c (build_entry_thunks): Signal cgraph we may not
garbage collect.
(create_main_function): Likewise.
(gfc_generate_function_code): Likewise.
* trans-expr.c (gfc_trans_subcomponent_assign): Do not use
fold_convert on record types.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-types.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
2009-05-02 12:14 [Bug fortran/40005] New: segfault in gt_ggc_mx_lang_tree_node jv244 at cam dot ac dot uk
` (37 preceding siblings ...)
2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
@ 2009-07-25 13:45 ` rguenth at gcc dot gnu dot org
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-25 13:45 UTC (permalink / raw)
To: gcc-bugs
------- 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|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
^ permalink raw reply [flat|nested] 40+ messages in thread