https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #4 from Daniel Santos <daniel.santos at pobox dot com> --- Created attachment 42147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42147&action=edit incomplete patch set with test (In reply to Jakub Jelinek from comment #3) > Of course there is none. Which is why e.g. pro_epilogue_adjust_stack has > code to handle the case when Pmode is not SImode and offset is not > x86_64_immediate_operand. So whatever generated this insn also needs to > test for sp + offset not being a valid address and load the offset into some > hard register first and use sp + that_reg. pro_and_epilogue pass is after > reload, so we can't wait for RA to handle it for us. Thanks for the help here Jakub. Being new to gcc (and obviously the x86 backend), I'm learning about issues that weren't "on my radar", so sorry for dragging you guys through some of this as well. This came about because I moved the stack realignment boundary from the start of the function's frame to after the GP reg saves so that we could use aligned MOVs for SSE regs. Prior to this, we just used the frame pointer with possibly unaligned MOVs and that offset was never very large. The bad operand is being generated when ix86_emit_save_sse_regs_using_mov calls choose_baseaddr. I wouldn't at all mind using the frame pointer with possibly unaligned MOVs for a case like this, but I'm not sure what the best solution is. This would mean that the realignment boundary ix86_frame::stack_realign_offset could represent two different locations, either after reg_save_offset or at stack_pointer_offset. This would require adding an alternative calculation to the if (stack_realign_fp) else block in ix86_compute_frame_layout (basically, readd the old way it was calculated), and -ms2sysv-xlogues might have to either be disabled or modified since it uses choose_baseaddr to init rax/rsi prior to calling the stub. The alternative that I can see is to modify choose_baseaddr so that it can init and utilize an auxiliary register (like r11). In this case, I'm thinking that it might make sense to do something global to track what regs are available rather than passing 'style' everywhere to know rather or not r11 is live and also track auxiliary register(s) such as this so we can init it once and then use it several times. I know we're approaching the end of stage1, so don't want to shake things up too much now. Please let me know what you think. I might post this to the list for opinions too. I'm attaching what I have of the fix for this -- it solves the problem that was posted, but it's still broken when we call a sysv function from an ms function. Thanks
