[Bug 157] using -O{1,2,3} together with -g causes ICE (seg fault)

[via D.gnu]

https://bugzilla.gdcproject.org/show_bug.cgi?id=157

Johannes Pfau <johannespfau at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|WORKSFORME                  |---

--- Comment #3 from Johannes Pfau <johannespfau at gmail.com> ---
Two years later, the bug can be reproduced when compiling phobos with GCC-4.9:
https://semaphoreci.com/jpf91/gdc/branches/gdc-4-9/builds/82

I did some debugging and investigation and this is a rather interesting bug
(line numbers in the following refer to GCC 4.9.4):

First of all, you need a templated function which contains a nested struct.
Then you need -O to inline this function somewhere and the function must be
defined outside of the main compilation unit.

What happens is this: GCC wants to generate a DW_TAG_GNU_call_site for the
inlined function (so only happens with optimization) and calls resolve_addr. In
the code path for this, line 23441, GCC checks for DECL_EXTERNAL, this is why
the function needs to be external.

Now it gets interesting: A similar situation can be triggered by LTO, GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 . Starting with GCC 5 these
cases do no longer generate full dies - avoiding the issue. For GCC 4.9 and 4.8
the new code is backported, but guarded by if(!in_lto_p) which leads to the
interesting situation that compiling with -flto actually fixes the bug...

So what happens in the non-LTO case? We call force_decl_die which outputs
complete debug info for the function. This includes debug info for return or
parameter types (so you need to return the nested type). Ultimately this ends
up calling gen_tagged_type_die, line 19681:

  else if (TYPE_CONTEXT (type) != NULL_TREE
           && (TREE_CODE (TYPE_CONTEXT (type)) == FUNCTION_DECL))
    {
      /* If this type is local to a function that hasn't been written
         out yet, use a NULL context for now; it will be fixed up in
         decls_for_scope.  */

But unfortunately the declaration is never emitted for some reason and
decls_for_scope never fixes context!



So this explains why this bug vanished in newer releases. We may still have a
template emission bug here though:

Unfortunately dustmite produced something which can't link, but consider this:
conv.d: toChars used by toImpl used by to. to & toImpl are emitted, toChars is
not. This does not seem right.


Compile like this:
gdc -g -O2 -nostdinc -I druntime_sources -I . std/net/curl.d -c

nm curl.o
0000000000000000 W pure nothrow @nogc immutable(char)[]
conv.to!(immutable(char)[]).to!(int).to(int)
0000000000000000 W pure nothrow @nogc immutable(char)[]
conv.text!(int).text(int)
                 U pure nothrow @nogc immutable(char)[]
conv.text!(uint).text(uint)
                 U pure nothrow @nogc @safe
conv.toChars!(uint).toChars(uint).Result conv.toChars!(uint).toChars(uint)
0000000000000000 W pure nothrow @nogc @safe uint
conv.unsigned!(int).unsigned(int)
0000000000000000 W pure nothrow @nogc immutable(char)[]
conv.toImpl!(immutable(char)[], int).toImpl(int, uint)
0000000000000000 W pure nothrow @nogc immutable(char)[]
conv.toImpl!(immutable(char)[], int).toImpl(int)
0000000000000000 W pure nothrow @nogc immutable(char)[]
conv.textImpl!(immutable(char)[], int).textImpl(int)


@Iain any idea what to do about GCC 4.9 and 4.8? I could probably just amend
the GCC patches to bave like GCC 5+ and always use the lto codepath... Or maybe
this really is our fault as we're not emitting the toChars function.

-- 
You are receiving this mail because:
You are watching all bug changes.