[PATCH] Fix ICE with asm "m" (stmt-expr) operand (PR middle-end/67653)

[Jakub Jelinek]

On Wed, Jan 20, 2016 at 10:24:40AM +0100, Richard Biener wrote:
> > We could diagnose a statement expression in "m", but not sure if that is all
> > that can get wrong, or if all statement expressions are problematic.
> 
> I thought about either requiring an lvalue here or at least diagnosing
> that a non-lvalue might end up using a memory temporary.

Requiring an lvalue sounds wrong, "m" input can be validly e.g. const object that
can't be assigned to.  Furthermore, I'm really afraid changing that would break
too much stuff.
We had until GCC 4.7 a warning:
              warning (0, "use of memory input without lvalue in "
                       "asm operand %d is deprecated", i + noutputs);
but 1) it wasn't anywhere near frontend, it was during expansion
2) it wasn't really checking lvalue, but whether the operand is a MEM or not
> 
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > 
> > > What happens if we just do _not_ mark the memory input addressable?
> > > Shouldn't IRA/LRA in the end satisfy the constraint by spilling
> > > a non-memory input and using the spill slot?
> > 
> > Well, if you want to make broken testcases work, it is always possible
> > to call say prepare_gimple_addressable, but I'd think it is preferrable
> > to tell people that what they do is really going to do something different
> > from what they expect (that the operand, while being a memory input, will
> > be some temporary containing a copy of the value rather than than the
> > variable itself.
> 
> Sure, I'm just thinking that diagnosing sth at gimplification time
> feels wrong ... after all we can make it unexpected but valid GIMPLE.

We already do diagnose tons of other cases for inline asm at
gimplification time.  I can replace the error with a warning followed by
copying it to addressable memory, that seems to be what the older gccs were
doing during expansion after issuing above mentioned warning.

	Jakub