http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Marc Glisse <marc.glisse at normalesup dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marc.glisse at normalesup
| |dot org
--- Comment #1 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-18
06:18:57 UTC ---
(In reply to comment #0)
> b) An even more convincing argument is that when adding the compiler argument
>
> --no-elide-constructors
>
> the original code becomes accepted as well, thus the outcome indeed depends on
> copy-elision taking place or not. The semantics of the noexcept operator
> (5.3.7) are described by "potentially evaluated functions calls" and 3.2 p3
> says in a note that "A constructor selected to copy or move an object of class
> type is odr-used even if the call is actually elided by the implementation",
> so
> this observable behaviour seems to be non-conforming.
It seems you are right, because the standard gives an unusual definition of
"potentially evaluated". In English an elided function call is not potentially
evaluated as the code for it isn't even generated.
It looks like the standard may require noexcept to be computed as if there were
no elisions, but that is a code pessimization that may not be necessary (or it
may be, so we can better rely on noexcept not subtly changing when the
circumstances are just different enough that the compiler won't elide a copy).
I wonder if saving flag_elide_constructors and setting it to false in
cp_parser_unary_expression before calling cp_parser_expression, and restoring
it afterwards (like many other flags get saved, set and restored) would be
enough, or if the elision is sometimes done later.
