> Ok if it passes testing.
Thanks, it did so I installed the fix yesterday but further testing then
revealed an oversight: the following assertion in ix86_adjust_stack_and_probe
gcc_assert (cfun->machine->fs.cfa_reg != stack_pointer_rtx);
will now evidently trigger (simple testcase attached).
On 11/11/2015 01:31 PM, Eric Botcazou wrote:
Yes, it probably should, thanks for spotting it, revised patch attached.
PR target/67265
* ira.c (ira_setup_eliminable_regset): Do not necessarily create the
frame pointer for stack checking if non-call exceptions aren't us
> This piece of code along doesn't tell me exactly why the frame pointer
> is needed. I was looking for an explicit use, but I now guess that if
> you have multiple adjusts of the [stack] pointer you can't easily undo
> them in the error case (the function behaves as-if using alloca). Is
> that it?
On 11/11/2015 12:38 PM, Eric Botcazou wrote:
this is an ICE on an asm statement requiring a lot of registers, when compiled
in 32-bit mode on x86/Linux with -O -fstack-check -fPIC:
pr67265.c:10:3: error: 'asm' operand has impossible constraints
The issue is that, since stack checking defines ST
Hi,
this is an ICE on an asm statement requiring a lot of registers, when compiled
in 32-bit mode on x86/Linux with -O -fstack-check -fPIC:
pr67265.c:10:3: error: 'asm' operand has impossible constraints
The issue is that, since stack checking defines STACK_CHECK_MOVING_SP on this
platform, th
