On Tue, 19 Jan 2016, Jakub Jelinek wrote: > On Tue, Jan 19, 2016 at 10:00:00AM +0100, Richard Biener wrote: > > On Tue, 19 Jan 2016, Jakub Jelinek wrote: > > > Here is an attempt to fix ICE on statement expression in "m" asm input > > > operand. The problem is that gimplify_asm_expr attempts to mark it > > > addressable, but that can be just too late, a temporary the > > > stmt-expression > > > gimplifies to might not be addressable and may be used already in the > > > gimplified code. Normally the C/C++ FEs attempt to mark the operand > > > addressable already, but in case of statement expression the temporaries > > > might not exist yet. > > > The patch turns also the PR29119 testcase into invalid test, but you've > > > already said in that PR it should be invalid and I agree with that. > > > > Hmm, but can't we detect this in the FE? > > 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. > > > 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. Erroring on a non-lvalue in the FE will likely break too much legacy code but I guess that might be a better choice than using a memory temporary (just in case we are faced with some fancy lock stuff). Richard.