[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> Weird, that commit only changes the names of some variables.

indeed, and I compared the .ii files to check if by some weird
coincidence one of those got mangled by some Solaris macro, but nothing
of the kind.

> A similar patch has been committed to the gcc-5 and gcc-6 branches, so we
> should be sure a similar ICE doesn't happen on the branches.

I've now done sparc-sun-solaris2.12 bootstraps on both branches, as well
as a mainline bootstrap on sparc-sun-solaris2.11 (same hardware), but
all work fine.  OTOH, a sparc-sun-solaris2.12 mainline bootstrap with
gas instead of as fails just the same.  Sometimes, small codegen or
layout differences due to differing assembler capabilities can lead to
unexpected memory corruption.

However, I've now managed to run the failing cc1plus invocation (without
-save-temps) under gdb:

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfed6c634 in strlen () from /lib/libc.so.1
(gdb) where
#0  0xfed6c634 in strlen () from /lib/libc.so.1
#1  0x009e0208 in gt_pch_note_object (obj=0xf93ffff8, 
    note_ptr_cookie=0xf93ffff8, note_ptr_fn=
    0xcfe544 <gt_pch_p_S(void*, void*, void (*)(void*, void*), void*)>)
    at /var/gcc/reghunt/trunk/gcc/ggc-common.c:285
#2  0x008c95f8 in gt_pch_nx<dw_attr_struct, va_gc> (v=<optimized out>)
    at /var/gcc/reghunt/trunk/gcc/vec.h:1130
#3  gt_pch_nx_vec_dw_attr_node_va_gc_ (x_p=0xf8238000) at gt-dwarf2out.h:948
#4  0x008c96a8 in gt_pch_nx_die_struct (x_p=<optimized out>)
    at gt-dwarf2out.h:720
#5  0x008c96d8 in gt_pch_nx_die_struct (x_p=<optimized out>)
    at gt-dwarf2out.h:722
#6  0x008c95f8 in gt_pch_nx<dw_attr_struct, va_gc> (v=<optimized out>)
    at /var/gcc/reghunt/trunk/gcc/vec.h:1130
#7  gt_pch_nx_vec_dw_attr_node_va_gc_ (x_p=0xfb73eca8) at gt-dwarf2out.h:948
#8  0x008c96a8 in gt_pch_nx_die_struct (x_p=<optimized out>)
    at gt-dwarf2out.h:720
#9  0x00699d48 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1345
#10 0x0069813c in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1042
#11 0x00699640 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1333
#12 0x0069813c in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1042
#13 0x00699628 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1332
#14 0x00698980 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1154
#15 0x006d0b70 in gt_pch_nx_cp_binding_level (x_p=0xfb42c000)
    at gt-cp-name-lookup.h:174
#16 0x00697fc0 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1538
#17 0x006985a8 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1111
#18 0x00698f48 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1227
#19 0x00699610 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1331
#20 0x00697cb0 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1496
#21 0x006d0cec in gt_pch_nx_cxx_binding (x_p=0xfb5847c8)
    at gt-cp-name-lookup.h:162
#22 0x00697fc0 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1538
#23 0x00698f30 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1226
#24 0x00699610 in gt_pch_nx_lang_tree_node (x_p=<optimized out>)
    at gt-cp-tree.h:1331
#25 0x00a5886c in gt_pch_nx<tree_node*, va_gc> (v=<optimized out>)
    at /var/gcc/reghunt/trunk/gcc/vec.h:1130
#26 gt_pch_nx_vec_tree_va_gc_ (x_p=0xfb976000) at gtype-desc.c:5174
#27 0x009e0a9c in gt_pch_save (f=0x17896c0 <_iob+64>)
    at /var/gcc/reghunt/trunk/gcc/ggc-common.c:437
#28 0x00785900 in c_common_write_pch ()
    at /var/gcc/reghunt/trunk/gcc/c-family/c-pch.c:183
#29 0x00594e5c in c_parse_final_cleanups ()
    at /var/gcc/reghunt/trunk/gcc/cp/decl2.c:4474
#30 0x00d04ae4 in compile_file () at /var/gcc/reghunt/trunk/gcc/toplev.c:467
#31 0x00d07860 in do_compile () at /var/gcc/reghunt/trunk/gcc/toplev.c:1984
#32 toplev::main (this=this@entry=0xffbfef66, argc=argc@entry=45, 
    argv=argv@entry=0xffbfefcc) at /var/gcc/reghunt/trunk/gcc/toplev.c:2118
#33 0x0141598c in main (argc=45, argv=0xffbfefcc)
    at /var/gcc/reghunt/trunk/gcc/main.c:39

Here's where strlen SEGVs:

(gdb) display/i $pc
1: x/i $pc
=> 0xfed6c634 <strlen+148>:     ld  [ %o2 ], %o1
(gdb) p/x $o2
$1 = 0xf9400000

#1  0x009e0208 in gt_pch_note_object (obj=0xf93ffff8, 
    note_ptr_cookie=0xf93ffff8, 
    note_ptr_fn=0xcfe544 <gt_pch_p_S(void*, void*, void (*)(void*, void*),
void*)>) at /var/gcc/reghunt/trunk/gcc/ggc-common.c:285
285         (*slot)->size = strlen ((const char *)obj) + 1;
(gdb) p obj
$2 = (void *) 0xf93ffff8

(gdb) p (char *)obj
$4 = 0xf93ffff8 "\001\257\257\257\257\257\257\257"<error: Cannot access memory
at address 0xf9400000>

pmap on cc1plus shows

F8800000     104K rw-----    [ anon ]
F9000000    4096K rw-----    [ anon ]
F9800000    1640K rw-----    [ anon ]

and indeed F9000000 + 4096K => F9400000, i.e.  F9400000 is unmapped!

Need to dig further why this happens.

        Rainer