https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
One minor difference between the FEs which can be seen in the gimple dump of
LU.c is that the C++ frontend doesn't transform (a < b ? a : b) to MIN_EXPR (a,
b) whereas the C frontend does perform this transformation.  This is because in
fold-const.c the transformation is guarded by:

      /* Avoid these transformations if the COND_EXPR may be used
         as an lvalue in the C++ front-end.  PR c++/19199.  */
      && (in_gimple_form
          || VECTOR_TYPE_P (type)
          || (! lang_GNU_CXX ()
              && strcmp (lang_hooks.name, "GNU Objective-C++") != 0)
          || ! maybe_lvalue_p (arg1)
          || ! maybe_lvalue_p (arg2)))

Which deliberately inhibits the transformation for C++.  Is this mentioned
lvalued-ness retention still a concern now that the FE performs delayed
folding?  By the time the transformation gets performed, the FE will have
lowered all uses of lvalue COND_EXPR to an appropriate non-lvalue COND_EXPR. 
Removing this hunk of code passes regtesting, at least.

Reply via email to