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

Jiong Wang wong.kwongyuan.tools@gmail.com
Thu Oct 20 19:47:00 GMT 2016

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


More information about the Gcc-patches mailing list