On 10/20/2016 01:46 PM, Jiong Wang wrote:
2016-10-20 19:50 GMT+01:00 Jeff Law <l...@redhat.com>:
On 10/20/2016 09:28 AM, Jiong Wang wrote:
The current code suppose targetm.stack_protect_fail always generate
something.
But in case one target start to generate NULL_TREE, there will be ICE.
This
patch adds a simple sanity check to only call expand if it's not NULL_TREE.
OK for trunk?
gcc/
2016-10-20 Jiong Wang <jiong.w...@arm.com>
* function.c (stack_protect_epilogue): Only expands
targetm.stack_protect_fail if it's not NULL_TREE.
Is there some reason we don't want to issue an error here and stop compilation?
I'm not at all comfortable silently ignoring failure to generate stack
protector code.
jeff
Hi Jeff,
That's because I am doing some work where I will borrow
stack-protector's analysis infrastructure but for those
stack-protector standard rtl insn, they just need to be expanded into
empty, for example stack_protect_set/test just need to be expanded
into NOTE_INSN_DELETED. The same for targetm.stack_protect_fail ()
which I want to simply return NULL_TREE. but it's not an error.
Right. But your change could mask backend problems. Specifically if
their expander for stack_protect_fail did fail and returned NULL_TREE.
That would cause it to silently ignore stack protector failures, which
seems inadvisable.
Is there another way you can re-use the analysis code without resorting
to something like this?
This do seems affect other targets (x86, rs6000) if NULL_TREE should
never be returned for them. Currently I can see all of them use the
either default_external_stack_protect_fail or
default_hidden_stack_protect_fail, both of which are "return
build_call_expr (..", so I should also assert the the return value of
build_call_expr?
Asserting couldn't hurt. I'd much rather have the compiler issue an
error, ICE or somesuch than silently not generate a call to the stack
protector fail routine.
jeff
