Thread overview
[Bug 252] ICE when compiling with -flto
Feb 26, 2017
Richard Delorme
Feb 26, 2017
Richard Delorme
Feb 27, 2017
Iain Buclaw
Feb 28, 2017
Iain Buclaw
Jan 28, 2018
Iain Buclaw
February 26, 2017
http://bugzilla.gdcproject.org/show_bug.cgi?id=252

Richard Delorme <abulmo@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|All                         |x86_64
                 OS|All                         |Linux

-- 
You are receiving this mail because:
You are watching all bug changes.
February 26, 2017
http://bugzilla.gdcproject.org/show_bug.cgi?id=252

--- Comment #1 from Richard Delorme <abulmo@gmail.com> ---
I do not see the attached file. Here it is:

class C {
        struct S {
                int i;
                ubyte u;
        }
        S s;
}

void main(string[] arg) {
        C c = new C;
}

-- 
You are receiving this mail because:
You are watching all bug changes.
February 27, 2017
https://bugzilla.gdcproject.org/show_bug.cgi?id=252

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
> I do not see the attached file.

I seem to have forgotten to update attachments to use the https address after turning on ssl, you should be able to see it now. ;-)


> When compiling the source file attached with -flto I get an Internal Compiler error:
> $ gdc -flto ice.d
> ice.d:1:0: internal compiler error: Segmentation fault

Fixing the immediate ICE on our side is simple enough, but then I get an ICE on lto's side.

--- GDC internals note ---
I suspect this because we mark all functions as being FUNCTION_TYPE, and in doing so information that is normally associated with METHOD_TYPE is not written to LTO even though we generate it.

The reason for it always being FUNCTION_TYPE is only for compatibility with
delegates.  On x86 METHOD_TYPE has a different calling convention (thiscall).
As delegate vars can only point to methods/nested functions, and function vars
only to global/static functions, it may work to mark delegates as a pointer to
METHOD_TYPE, giving it a distinct calling convention.  This has not worked in
the past because representing nested functions as METHOD_TYPE have the
drawbacks.
- The 'this' parameter must be a pointer-to-struct - this should be fixed, as
we now swap the void* parameter with the correct frame/closure type.
- The parent context must be a record type (??? double check this, makes sense
to me though to have such a restriction in AST).

We should add some tests in place to make sure we don't keep on regressing on LTO, despite it still being very much untested.  There should be a few here and on the old bitbucket issues that can throw into the testsuite with REQUIRED_ARGS: -flto.  That is at least a starting point.

-- 
You are receiving this mail because:
You are watching all bug changes.
February 28, 2017
https://bugzilla.gdcproject.org/show_bug.cgi?id=252

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Another internals note - If we are to mark methods as DECL_VIRTUAL_P, going to have to start populating BINFO_VTABLE for all classes, otherwise class TYPE_BINFO gets GC'd, which is problematic for devirt pass in LTO.

-- 
You are receiving this mail because:
You are watching all bug changes.
January 28, 2018
https://bugzilla.gdcproject.org/show_bug.cgi?id=252

Iain Buclaw <ibuclaw@gdcproject.org> changed:

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

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
https://github.com/D-Programming-GDC/GDC/pull/578

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