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. 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.