https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #18 from Jonathan Wakely ---
See http://cplusplus.github.io/LWG/lwg-active.html#submit_issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #17 from Peter Kasting ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Peter Kasting from comment #14)
> > And you are right, it's possible to reimplement concepts around "is this
> > even legal to pass to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #16 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> The reason to avoid &*ptr is because it's undefined behaviour on a
> past-the-end iterator, not because it might be ill-formed for some template
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #14 from Peter Kasting ---
(In reply to Jonathan Wakely from comment #13)
> As I said in comment 7, LWG considered this case and it was pointed out that
> the problem described can only occur if a type defines iterator_concept =
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #13 from Jonathan Wakely ---
It looks like libc++ did it for this reason:
[libc++] Fix a hard error in `contiguous_iterator`.
Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #12 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #10)
> When Jose reported this issue in Chromium I pushed back on fixing on our
> side because I thought libstdc++ had the same issue. But this is a distinct
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #11 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #8)
> There's currently no simple and blessed route for consumers to convert
> raw-or-fancy-pointer input types to raw pointers.
I disagree, std::to_address does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #10 from Peter Kasting ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Created attachment 56905 [details]
> > testcase which shows libc++ and libstdc++ difference
> >
> > with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 56905 [details]
> testcase which shows libc++ and libstdc++ difference
>
> with libstdc++, both GCC and clang reject this.
> with libc++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Peter Kasting changed:
What|Removed |Added
CC||pkasting at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Jonathan Wakely changed:
What|Removed |Added
URL||oh my
--- Comment #7 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #5 from Andrew Pinski ---
Created attachment 56905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56905=edit
testcase which shows libc++ and libstdc++ difference
with libstdc++, both GCC and clang reject this.
with libc++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #4 from Andrew Pinski ---
>This case fails in Clang with the expected outcome (it fails to resolve to a
>valid call).
No it fails the same way if you use libstdc++ from GCC.
It fails that way if you use libc++ from the LLVM
15 matches
Mail list logo
