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.