This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICE with asm "m" (stmt-expr) operand (PR middle-end/67653)
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 Jan 2016 10:24:40 +0100 (CET)
- Subject: Re: [PATCH] Fix ICE with asm "m" (stmt-expr) operand (PR middle-end/67653)
- Authentication-results: sourceware.org; auth=none
- References: <20160118231114 dot GD3017 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1601190958370 dot 31122 at t29 dot fhfr dot qr> <20160119133304 dot GN3017 at tucnak dot redhat dot com>
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.