https://bugzilla.gdcproject.org/show_bug.cgi?id=252
--- Comment #2 from Iain Buclaw <ibuc...@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.
