On 05/16/17 21:52, Bernd Edlinger wrote:
> The calls_eh_return and ix86_static_chain_on_stack may become
> known at a later time, but after reload it should not change any more.
> To be sure, I added an assertion at ix86_static_chain, which the
> regression test did not trigger, neither with -m64 nor with -m32.
>
Oops, excuse me, actually -m32 does trigger the assert, for instance:
FAIL: gcc.target/i386/pr67770.c (internal compiler error)
FAIL: gcc.target/i386/pr67770.c (test for excess errors)
Excess errors:
/home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.target/i386/pr67770.c:25:3:
internal compiler error: in ix86_static_chain, at config/i386/i386.c:31481
0xecf71a ix86_static_chain
../../gcc-trunk/gcc/config/i386/i386.c:31481
0x7b33b2 df_get_entry_block_def_set
../../gcc-trunk/gcc/df-scan.c:3539
0x7bb0b6 df_scan_blocks()
../../gcc-trunk/gcc/df-scan.c:576
0x9bc46d do_reload
../../gcc-trunk/gcc/ira.c:5504
0x9bc46d execute
../../gcc-trunk/gcc/ira.c:5624
As it looks like ix86_static_chain_on_stack will definitely change
the frame layout, and that is probably something that should not
have happened. Without the assert it could be wrong code, right?
However, the following change would avoid the assertion:
if (fndecl == current_function_decl
&& !ix86_static_chain_on_stack)
{
gcc_assert (!reload_completed);
ix86_static_chain_on_stack = true;
}
At least in the test case above...
Thanks
Bernd.
