-
-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix 4369 boom #4401
Fix 4369 boom #4401
Conversation
@@ -1018,7 +1018,7 @@ static void optimise(compile_t* c, bool pony_specific) | |||
if (c->opt->release) { | |||
MPM = PB.buildPerModuleDefaultPipeline(OptimizationLevel::O3); | |||
} else { | |||
MPM = PB.buildO0DefaultPipeline(OptimizationLevel::O0); | |||
MPM = PB.buildPerModuleDefaultPipeline(OptimizationLevel::O1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This switches us back to "make the boom happen"
src/libponyc/codegen/genreference.c
Outdated
@@ -254,6 +254,7 @@ LLVMValueRef gen_localdecl(compile_t* c, ast_t* ast) | |||
// Store the alloca to use when we reference this local. | |||
codegen_setlocal(c, name, alloc); | |||
|
|||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commenting out the debug info in gen_localdecl removes the boom from the 4369 example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be an interesting next step to try to pare down to remove debug info for specific locals by name and see which specific local variable is breaking it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, modify the generated LLVM ir for the given program?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Joe was thinking "check the name and decide if to put" as using command line tools to link might change the situation.
armhf failure is unrelated. it is #4391. |
Working with the #4369 original example, I found that the "cause" of the issue is the debug metadata on the name "t1". Without it we are good. I'm leaving the IR out for now as I don't see anything that makes me go "o that is clearly wrong" at the IR level (but I could be missing something). I did assembly for "Good" aka no debug metadata on t1 and "Bad" aka debug metadata on t1 and the meaningful difference I can see is: good: .LBB49_1:
.LBB49_2:
.Ltmp5:
.loc 4 0 29
movq 56(%rsp), %rdi
xorl %esi, %esi
callq pony_alloc_small@PLT
movq 56(%rsp), %rdi
movq %rax, 40(%rsp) bad: .LBB49_1:
.LBB49_2:
.loc 4 0 29
movq 56(%rsp), %rdi
.Ltmp25:
.Ltmp5:
xorl %esi, %esi
callq pony_alloc_small@PLT
movq 56(%rsp), %rdi
movq %rax, 40(%rsp) |
reminder on the error we get:
Note that what is really interesting is that this is our segfault: // If there are none in this size class, get a new one.
if(chunk != NULL)
{
// Clear and use the first available slot.
uint32_t slots = chunk->slots; So chunk which is not NULL is resulting in signal SIGSEGV: invalid address (fault address: 0x0) which is just bizarro on the face of it.
|
@jemc...
|
OK I officially have 2 identical copies of assembly, one goes boom, one does not. Difference, debug or release runtime. cc @jemc |
Not sure why yet.