|Posted by Iain Buclaw||PermalinkReply|
--- Comment #2 from Iain Buclaw <email@example.com> ---
> 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
- 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.