[PATCH] PR69195, Reload confused by invalid reg equivs

[Jeff Law]

On 03/12/2016 04:10 AM, Richard Biener wrote:
> On March 12, 2016 10:29:40 AM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Sat, Mar 12, 2016 at 07:37:25PM +1030, Alan Modra wrote:
>>>> I believe Alan's point is DSE deleted the assignment to x which
>> can't be
>>>> right as long as we've left in goto *&x.
>>>>
>>>> The goto *&x should be a use of x and thus should have kept the
>> assignment
>>>> live.
>>>
>>> Right, I wasn't trying to say that ira.c:indirect_jump_optimize is
>>> OK.  It needs the patch I posted or perhaps even better a test of
>>> DF_REF_INSN_INFO rather than !DF_REF_IS_ARTIFICIAL (simply because
>> the
>>> flag test is reading another field, and we need to read
>>> DF_REF_INSN_INFO anyway).
>>
>> Ok, that was my point.  BTW, DSE isn't the only one that deletes x = 0;
>> cddce deletes it too.  -fno-tree-dse -fno-tree-dce preserves it till
>> expansion.
>
> GIMPLE_GOTO doesn't have VOPs and I don't think that we'd want VUSEs on all gotos. But just having them on indirect gotos would be inconsistent.
>
> I believe the code is undefined anyway and out of scope of a reasonable QOI.
Undefined?  Most likely.  But we still have to do something sensible. 
As Jakub noted, a user could create the problematic code just as easily 
as DCE/DSE, so IRA probably needs to be tolerant of this situation.

So it seems like you're suggesting we leave DCE/DSE alone (declaring 
this usage undefined) and fix IRA to be tolerant, right?


> Using alloca to create/jump to code on the stack should work (we might transform that into a decl though).
Given that executable stacks are a huge security hole, I'd be willing to 
go out on a limb and declare that undefined as well.  It's not as clear 
cut, but that's the argument I'd make.

And yes, I realize that goes in opposition to what GCC has allowed for 
20+ years.  I still think it'd be the right thing to do.

jeff