Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
February 26, 2017 [Bug 252] ICE when compiling with -flto | ||||
---|---|---|---|---|
| ||||
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 [Bug 252] ICE when compiling with -flto | ||||
---|---|---|---|---|
| ||||
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 [Bug 252] ICE when compiling with -flto | ||||
---|---|---|---|---|
| ||||
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 [Bug 252] ICE when compiling with -flto | ||||
---|---|---|---|---|
| ||||
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 [Bug 252] ICE when compiling with -flto | ||||
---|---|---|---|---|
| ||||
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. |
Copyright © 1999-2021 by the D Language Foundation