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

On 11/24/2016 07:11 AM, Jiong Wang wrote: gcc/ 2016-11-11 Jiong Wang * function.c (expand_function_end): Guard stack_protect_epilogue with ENABLE_DEFAULT_SSP_RUNTIME. * cfgexpand.c (pass_expand::execute): Likewise guard for stack_protect_prologue. * defa

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

gcc/ 2016-11-11 Jiong Wang * function.c (expand_function_end): Guard stack_protect_epilogue with ENABLE_DEFAULT_SSP_RUNTIME. * cfgexpand.c (pass_expand::execute): Likewise guard for stack_protect_prologue. * defaults.h (ENABLE_DEFAULT_SSP_RUNTIME): New ma

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

On 11/11/2016 11:41 AM, Jiong Wang wrote: On 24/10/16 16:22, Jeff Law wrote: 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. Hi Jeff, I have just send out the other patch whic

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

On 10/24/2016 10:29 AM, Jiong Wang wrote: 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

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

On Fri, 11 Nov 2016, Jiong Wang wrote: >In this new patch, I introduced a new target macro for SSP to allow one > backend GCC's default SSP runtime generation be disabled. I see no reason this needs to be a target macro rather than a hook. New target macros are discouraged and should only

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

On 24/10/16 16:22, Jeff Law wrote: 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. Hi Jeff, I have just send out the other patch which accelerates -fstack-protector on AArc

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

On 24/10/16 16:22, Jeff Law wrote: On 10/20/2016 01:46 PM, Jiong Wang wrote: 2016-10-20 19:50 GMT+01:00 Jeff Law : 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, ther

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

On 10/20/2016 01:46 PM, Jiong Wang wrote: 2016-10-20 19:50 GMT+01:00 Jeff Law : 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 sim

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

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

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

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/ 201

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

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