[Bug 252] ICE when compiling with -flto

[via D.gnu]

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

--- Comment #2 from Iain Buclaw <ibuclaw at 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.