[Patch] Don't expand targetm.stack_protect_fail if it's NULL_TREE

[Jiong Wang]

2016-10-20 19:50 GMT+01:00 Jeff Law <law@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.wang@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.

  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?

  Thanks.