------- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04 06:01 ------- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, Mark Mitchell <[EMAIL PROTECTED]> 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280