Bug 91438 - [10 Regression] Profiledbootstrap broken on i586 in Ada
Summary: [10 Regression] Profiledbootstrap broken on i586 in Ada
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: 10.0
Assignee: Martin Liška
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2019-08-13 11:18 UTC by Martin Liška
Modified: 2019-08-23 11:42 UTC (History)
2 users (show)

See Also:
Host: i586-linux-gnu
Target: i586-linux-gnu
Build: i586-linux-gnu
Known to work: 9.1.1
Known to fail: 10.0
Last reconfirmed: 2019-08-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2019-08-13 11:18:59 UTC
I see following problem:

[12028s] /home/abuild/rpmbuild/BUILD/gcc-10.0.0+r274314/obj-i586-suse-linux/./prev-gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-10.0.0+r274314/obj-i586-suse-linux/./prev-gcc/ -B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/lib/ -isystem /usr/i586-suse-linux/include -isystem /usr/i586-suse-linux/sys-include    -c -fomit-frame-pointer -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE -fprofile-use  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface -Iada/libgnat -I../../gcc/ada/libgnat ../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o

[12032s] raised STORAGE_ERROR : stack overflow or erroneous memory access
[12032s] make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:140: ada/exp_ch5.o] Error 1

Where valgrind complains about:

==1530751== Invalid read of size 4
==1530751==    at 0x88F2888: lookup_page_table_entry (ggc-page.c:641)
==1530751==    by 0x88F2888: ggc_set_mark(void const*) (ggc-page.c:1531)
==1530751==    by 0x8B39D48: gt_ggc_mx_symtab_node(void*) (gtype-desc.c:1302)
==1530751==    by 0x8B39DFE: gt_ggc_mx_symtab_node(void*) (gtype-desc.c:1353)
==1530751==    by 0x852A89E: gt_ggc_mx_lang_tree_node(void*) (gtype-ada.h:287)
==1530751==    by 0x8B3728A: gt_ggc_mx_rtx_def(void*) (gtype-desc.c:717)
==1530751==    by 0x89D0F4E: gt_ggc_mx<dw_attr_struct> (vec.h:1317)
==1530751==    by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_ (gt-dwarf2out.h:274)
==1530751==    by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:269)
==1530751==    by 0x89D0FD3: gt_ggc_mx_die_struct (gt-dwarf2out.h:45)
==1530751==    by 0x89D0FD3: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23)
==1530751==    by 0x89D0FF9: gt_ggc_mx_die_struct (gt-dwarf2out.h:47)
==1530751==    by 0x89D0FF9: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23)
==1530751==    by 0x89D0F4E: gt_ggc_mx<dw_attr_struct> (vec.h:1317)
==1530751==    by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_ (gt-dwarf2out.h:274)
==1530751==    by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:269)
==1530751==    by 0x89D0FD3: gt_ggc_mx_die_struct (gt-dwarf2out.h:45)
==1530751==    by 0x89D0FD3: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23)
==1530751==    by 0x89C9B62: ggc_mx (hash-traits.h:235)
==1530751==    by 0x89C9B62: ggc_maybe_mx (hash-traits.h:242)
==1530751==    by 0x89C9B62: gt_ggc_mx<decl_die_hasher> (hash-table.h:1166)
==1530751==    by 0x89C9B62: gt_ggc_mx_hash_table_decl_die_hasher_ (gt-dwarf2out.h:395)
==1530751==    by 0x89C9B62: gt_ggc_mx_hash_table_decl_die_hasher_(void*) (gt-dwarf2out.h:390)
==1530751==    by 0x8AC4683: ggc_mark_root_tab(ggc_root_tab const*) (ggc-common.c:77)
==1530751==  Address 0x2968 is not stack'd, malloc'd or (recently) free'd
==1530751== 

raised STORAGE_ERROR : stack overflow or erroneous memory access

The regression must be couple of days old. Note that one needs PGO bootstrap and i586 target.
Comment 1 Martin Liška 2019-08-13 11:41:20 UTC
Probably r274238 is fine.
Comment 2 Martin Liška 2019-08-13 13:14:09 UTC
(In reply to Martin Liška from comment #1)
> Probably r274238 is fine.

I was wrong, the revision is also affected.
Comment 3 Martin Liška 2019-08-13 14:42:56 UTC
r273856 is fine, so probably started with my r273857.
Comment 4 H.J. Lu 2019-08-13 18:05:10 UTC
Is this related to PR 91404?
Comment 5 Martin Liška 2019-08-14 07:03:35 UTC
(In reply to H.J. Lu from comment #4)
> Is this related to PR 91404?

Maybe. The stack trace is different, so maybe a different story. I'll check it.
Comment 6 Martin Liška 2019-08-14 09:52:32 UTC
(In reply to Martin Liška from comment #5)
> (In reply to H.J. Lu from comment #4)
> > Is this related to PR 91404?
> 
> Maybe. The stack trace is different, so maybe a different story. I'll check
> it.

It's a different issue.
Comment 7 Martin Liška 2019-08-14 11:14:00 UTC
I've got it:

Program received signal SIGSEGV, Segmentation fault.
0x08a4dec7 in lookup_page_table_entry (p=0xa5a5a5a5) at ../../gcc/ggc-page.c:641
641	  return base[L1][L2];
(gdb) bt
#0  0x08a4dec7 in lookup_page_table_entry (p=0xa5a5a5a5) at ../../gcc/ggc-page.c:641
#1  0x08a4ebcb in ggc_set_mark (p=0xa5a5a5a5) at ../../gcc/ggc-page.c:1531
#2  0x08d86715 in gt_ggc_mx_symtab_node (x_p=0xb61b39f0) at gtype-desc.c:1302
#3  0x08d86ad8 in gt_ggc_mx_symtab_node (x_p=0xb6347ee8) at gtype-desc.c:1353
#4  0x085b1388 in gt_ggc_mx_lang_tree_node (x_p=0xb6172080) at ./gtype-ada.h:287
#5  0x08d8475e in gt_ggc_mx_rtx_def (x_p=0xb42e43c0) at gtype-desc.c:717
#6  0x08bd216d in gt_ggc_mx (x_r=...) at ./gt-dwarf2out.h:286
#7  0x08bde122 in gt_ggc_mx<dw_attr_struct> (v=0xb463e180) at ../../gcc/vec.h:1317
#8  0x08bd210a in gt_ggc_mx_vec_dw_attr_node_va_gc_ (x_p=0xb463e180) at ./gt-dwarf2out.h:274
#9  0x08bd19d4 in gt_ggc_mx_die_struct (x_p=0xb62dd030) at ./gt-dwarf2out.h:45
#10 0x08bd1a0c in gt_ggc_mx_die_struct (x_p=0xb44d4990) at ./gt-dwarf2out.h:47
#11 0x08bd2264 in gt_ggc_mx (x_r=...) at ./gt-dwarf2out.h:314
#12 0x08bde122 in gt_ggc_mx<dw_attr_struct> (v=0xb44e8f00) at ../../gcc/vec.h:1317
#13 0x08bd210a in gt_ggc_mx_vec_dw_attr_node_va_gc_ (x_p=0xb44e8f00) at ./gt-dwarf2out.h:274
#14 0x08bd19d4 in gt_ggc_mx_die_struct (x_p=0xb44e5cc0) at ./gt-dwarf2out.h:45
#15 0x08bd1b60 in gt_ggc_mx (x=@0xb44f5004: 0xb44e5cc0) at ./gt-dwarf2out.h:81
#16 0x08be9e0f in ggc_remove<die_struct*>::ggc_mx (p=@0xb44f5004: 0xb44e5cc0) at ../../gcc/hash-traits.h:235
#17 0x08be5796 in ggc_remove<die_struct*>::ggc_maybe_mx (p=@0xb44f5004: 0xb44e5cc0) at ../../gcc/hash-traits.h:242
#18 0x08bd527b in gt_ggc_mx<decl_die_hasher> (h=0xb795b5c0) at ../../gcc/hash-table.h:1166
#19 0x08bd24d7 in gt_ggc_mx_hash_table_decl_die_hasher_ (x_p=0xb795b5c0) at ./gt-dwarf2out.h:395
#20 0x08ce809b in ggc_mark_root_tab (rt=0xa1444e4 <gt_ggc_r_gt_dwarf2out_h+420>) at ../../gcc/ggc-common.c:77
#21 0x08ce8118 in ggc_mark_roots () at ../../gcc/ggc-common.c:94
#22 0x08a4fb36 in ggc_collect () at ../../gcc/ggc-page.c:2201
#23 0x08fd51b7 in execute_one_pass (pass=0xb1ebe60) at ../../gcc/passes.c:2565
#24 0x08fd5204 in execute_pass_list_1 (pass=0xb1ebe60) at ../../gcc/passes.c:2580
#25 0x08fd5280 in execute_pass_list (fn=0xb7a9fea0, pass=0xb1e9690) at ../../gcc/passes.c:2591
#26 0x08b1c7d1 in cgraph_node::expand (this=0xb7b33c6c) at ../../gcc/cgraphunit.c:2194
#27 0x08b1cda5 in expand_all_functions () at ../../gcc/cgraphunit.c:2332
#28 0x08b1d85e in symbol_table::compile (this=0xb794e0d0) at ../../gcc/cgraphunit.c:2688
#29 0x08b1dc6c in symbol_table::finalize_compilation_unit (this=0xb794e0d0) at ../../gcc/cgraphunit.c:2868
#30 0x0911e882 in compile_file () at ../../gcc/toplev.c:481
#31 0x0912122d in do_compile () at ../../gcc/toplev.c:2190
#32 0x09121502 in toplev::main (this=0xbffff45e, argc=38, argv=0xbffff514) at ../../gcc/toplev.c:2325
#33 0x09fa3506 in main (argc=38, argv=0xbffff514) at ../../gcc/main.c:39

The issue is that GGC marker is called for a release node. It happens because of:
(gdb) frame 3
#3  0x08d86ad8 in gt_ggc_mx_symtab_node (x_p=0xb6347ee8) at gtype-desc.c:1353
1353	            gt_ggc_m_11symtab_node ((*sub).next_nested);

where:
(gdb) p (*sub).origin
$1 = (cgraph_node *) 0x0

So we have a node that has next_nested != NULL && origin == NULL, which is wrong.
I've got a patch for it.
Comment 8 Martin Liška 2019-08-15 06:59:08 UTC
Author: marxin
Date: Thu Aug 15 06:58:36 2019
New Revision: 274504

URL: https://gcc.gnu.org/viewcvs?rev=274504&root=gcc&view=rev
Log:
Clean next_nested properly.

2019-08-15  Martin Liska  <mliska@suse.cz>

	PR ipa/91438
	* cgraph.c (cgraph_node::remove): When setting
	n->origin = NULL for all nested functions, reset
	also next_nested.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.c
Comment 9 Martin Liška 2019-08-15 06:59:22 UTC
Fixed.
Comment 10 Martin Liška 2019-08-23 11:42:51 UTC
Author: marxin
Date: Fri Aug 23 11:42:19 2019
New Revision: 274853

URL: https://gcc.gnu.org/viewcvs?rev=274853&root=gcc&view=rev
Log:
Backport r274504

2019-08-23  Martin Liska  <mliska@suse.cz>

	PR ipa/91508
	Backport from mainline
	2019-08-15  Martin Liska  <mliska@suse.cz>

	PR ipa/91438
	* cgraph.c (cgraph_node::remove): When setting
	n->origin = NULL for all nested functions, reset
	also next_nested.

Modified:
    branches/gcc-9-branch/gcc/ChangeLog
    branches/gcc-9-branch/gcc/cgraph.c