This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 20 Jan 2018 13:33:29 +0000
- Subject: [Bug c++/83949] internal compiler error: Segmentation fault (only with -g)
- Auto-submitted: auto-generated
- References: <bug-83949-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83949
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As the preprocessed source comes from some early 5.x version (not even current
one, and 5.x is not maintained anymore anyway), can't check current trunk.
What I see in 5.x is that:
#3 0x0000000001132085 in ggc_internal_cleared_alloc (s=18446744072616236162)
at ../../gcc/ggc.h:149
#4 0x00000000011321ac in ggc_alloc_string (
contents=0x7ff8a5f06020
"joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost::mpl::joint_iter<boost"...,
length=-1093315455) at ../../gcc/stringpool.c:108
#5 0x000000000085d25a in pp_ggc_formatted_text (pp=0x32b2540
<scratch_pretty_printer>) at ../../gcc/cp/error.c:2761
#6 0x0000000000859f36 in decl_as_string (decl=<type_decl 0x7fffd8bcbbe0
joint_iter>, flags=6148) at ../../gcc/cp/error.c:2814
#7 0x0000000000859ece in decl_as_dwarf_string (decl=<type_decl 0x7fffd8bcbbe0
joint_iter>, flags=6148) at ../../gcc/cp/error.c:2802
#8 0x000000000070ca78 in cxx_dwarf_name (t=<type_decl 0x7fffd8bcbbe0
joint_iter>, verbosity=2) at ../../gcc/cp/cp-lang.c:135
#9 0x0000000000bb1a47 in type_tag (type=0x7fffd8bce888) at
../../gcc/dwarf2out.c:17449
#10 0x0000000000bbc7dc in gen_struct_or_union_type_die (type=<record_type
0x7fffd8bce888 joint_iter>,
context_die=<dw_die_ref 0x7fffefa5c0a0 DW_TAG_namespace
<parent=0x7fffefa5c050 DW_TAG_namespace>>, usage=DINFO_USAGE_DIR_USE)
at ../../gcc/dwarf2out.c:20014
where decl_as_string for some instantiation needs almost 3GB long string and
ggc_strdup only supports strings < 2GB, as ggc_alloc_string has int length
argument and tree_string has int length field.
Supporting >= 2GB and < 4GB or even >= 4GB STRING_CSTs would be hard, making
ggc_strdup work for >= 2GB coudl mean just:
--- gcc/stringpool.c.jj 2018-01-03 10:19:55.544534019 +0100
+++ gcc/stringpool.c 2018-01-20 14:28:54.452768825 +0100
@@ -70,15 +70,16 @@ alloc_node (cpp_hash_table *table ATTRIB
const char *
ggc_alloc_string (const char *contents, int length MEM_STAT_DECL)
{
+ size_t len = length;
if (length == -1)
- length = strlen (contents);
+ len = strlen (contents);
- if (!length)
+ if (!len)
return "";
- char *result = (char *) ggc_alloc_atomic (length + 1);
- memcpy (result, contents, length);
- result[length] = '\0';
+ char *result = (char *) ggc_alloc_atomic (len + 1);
+ memcpy (result, contents, len);
+ result[len] = '\0';
return (const char *) result;
}
But, even if it doesn't crash with this, I doubt it would actually produce any
useful debug info, except for MIPS we emit 32-bit DWARF and so .debug_str
offsets need to fit into 4GB for the whole shared library or binary. If you
have 3GB long just a single string, I doubt you can fit the rest into 1GB.
Perhaps don't abuse templates that much?