On 03/12/2016 04:10 AM, Richard Biener wrote:
On March 12, 2016 10:29:40 AM GMT+01:00, Jakub Jelinek <ja...@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
