https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arthur.j.odwyer at gmail dot
com
--- Comment #11 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
@jwakely: I suggest reopening this issue, since while it does overlap with bug
111053, it has a piece (the std::copy piece) which is not part of the overlap.
You wrote:
>My reading of the standard is that it is not permitted to use std::to_address
>to convert arbitrary contiguous iterators to pointers, because the iterators
>could use exceptions to alter control flow.
We discussed this a bit more on the Slack yesterday.
My [Arthur's] position continues to be that libstdc++'s current criterion makes
no sense, because exceptions aren't the only way to alter control flow. A
contiguous iterator's `operator++` or `operator*` could touch a global
variable, terminate the program, print some output, etc etc, and still remain
noexcept.
This is never about the *order* of the iterator's side effects. It's solely
about whether the library is permitted to *elide all those effects entirely*,
by replacing all your iterator math with pointer math. Noexceptness is
irrelevant to that question: such elision is flatly forbidden pre-P3349 and
flatly permitted afterward.
I'm talking about examples like this one, where on libstdc++ the noexceptness
of `operator==` controls whether `dereferences[1]` is zero or non-zero after
the call to `std::copy`. No exceptions are ever thrown; in fact I've added
-fno-exceptions to the command line just to prove that's the case.
https://godbolt.org/z/Kz8jo9zYa
Today (pre-P3349) libstdc++ has a wrong-codegen bug: it non-conformingly leaves
`dereferences[2]` at zero when `operator==` is noexcept. Tomorrow (post-P3349)
libstdc++ will have a missed-optimization bug: it inefficiently increments
`dereferences[2]` when `operator==` is non-noexcept.
Personally I encourage libstdc++ to join libc++ in optimizing as if P3349 were
already the law of the land. You're free to say "no, we must not perform that
optimization until it is legal on paper"; but in that case, you've got a
wrong-codegen bug *today*, which (for logical consistency) you should fix. No
matter what, the correct optimization-gate here will *not* branch on the
noexceptness of `operator==` and `operator*`.
