This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gcc-bugzilla at gcc dot gnu dot org
- Date: 04 Mar 2005 03:00:00 -0300
- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <oroee1xj5d.fsf@livre.redhat.lsd.ic.unicamp.br><4227BB7E.9040407@codesourcery.com>
On Mar 3, 2005, Mark Mitchell <mark@codesourcery.com> wrote:
> Alexandre Oliva wrote:
> \
>> I went ahead and verified that I didn't break bit-field lvalues in
>> conditional expressions (my first attempt did), but I was surprised to
>> find out that the calls to h() pass. I understand why they do (we
>> create a temporary and bind to that), but I'm not sure this is correct
>> behavior. Opinions?
>> + // Hmm... I don't think these should be accepted. The conditional
>> + // expressions are lvalues for sure, and 8.5.3/5 exempts lvalues
>> + // that are bit-fields, but not lvalues that are conditional
>> + // expressions involving bit-fields.
>> + h (b ? x.i : x.j);
>> + h (b ? x.i : x.k);
>> + h (b ? x.j : x.k);
> That's legal because "h" takes a "const &", which permits the compiler
> to create a temporary.
Yeah, it permits, but only in certain circumstances that AFAICT aren't
met. This expression AFAICT is an lvalue that isn't a bit-field, so
it has to bind directly, per the first bullet in 8.5.3/5. Since it
meets the conditions of this first bullet, it doesn't get to use the
`otherwise' portion of that paragraph, that creates a temporary. Or
am I misreading anything?
> And, I think these kinds of transformations (if necessary) should be
> done in a langhook during gimplification, not at COND_EXPR-creation
> time. We really want the C++ front-end's data structures to be an
> accurate mirror of the input program for as long as possible.
Err... But in what sense does my patch change that? See, what I'm
doing is hoisting the indirect_refs that are inserted by
stabilize_reference out of the cond_expr. They weren't in the
original code. There's no dereferencing going on unless the whole
expression undergoes lvalue-to-rvalue decay, so I'd argue that the
transformation I'm proposing actually matches even more accurately the
meaning of the original source code.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}