https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #16 from Andrzej Krzemienski ---
Oh, I see. The above requirement applies only to chapter Algorithms library.
Not Iterators library. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #15 from Andrzej Krzemienski ---
How come?
[algorithms.requirements], paragraph 4, bullet 5
(http://eel.is/c++draft/algorithms#requirements-4.5) says:
If an algorithm's template parameter is named BidirectionalIterator,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #14 from Jonathan Wakely ---
There is an LWG issue requesting clarification in the standard:
https://wg21.link/lwg3197
Option B is consistent with the interpretation of libstdc++ (and recent
versions of libc++). If Option A or C is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Jonathan Wakely changed:
What|Removed |Added
CC||lesley at lesleylai dot info
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #12 from Jonathan Wakely ---
Finally, with -Waggressive-loop-optimizations -Wsystem-headers -O1 it does
terminate translation:
/usr/include/c++/8/bits/stl_iterator_base_funcs.h: In function ‘int main()’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #11 from Jonathan Wakely ---
As I already said:
(In reply to Jonathan Wakely from comment #8)
> One day I hope to be able to enhance those assertions to warn at
> compile-time if the compiler can tell the assertion will fail, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #10 from Andrzej Krzemienski ---
For `std::prev()` it is UB, but by my reading of UB
(http://eel.is/c++draft/intro.defs#defns.undefined) it is legal for the
implementation to respond with "terminating a translation" "with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #9 from Jonathan Wakely ---
P.S. in C++2a std::ranges::prev does make it ill-formed to pass arguments that
don't satisfy the BidirectionalIterator concept. But std::prev doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Piotr Nycz from comment #5)
> > CLANG with its std-lib correctly (IMO) does not compile it.
>
> As explained above, GCC is already correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #6 from Jonathan Wakely ---
(In reply to Piotr Nycz from comment #5)
> CLANG with its std-lib correctly (IMO) does not compile it.
As explained above, GCC is already correct here.
> I understand this is UB - but implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Piotr Nycz changed:
What|Removed |Added
CC||piotrwn1 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #4 from Andrzej Krzemienski ---
Just to clarify, what I request for this "unconditional" check is not the
existence of all operators, but only the check for the iterator_tag (we expect
a bidirectional iterator).
That is, the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #2 from Andrzej Krzemienski ---
Sorry, you are correct. As per [res.on.functions], passing types that do not
satisfy the requirements is a UB, and therefore a well formed program. GCC is
standard-compliant in this respect.
So, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #1 from Jonathan Wakely ---
Why is it ill-formed?
By my reading it's undefined, which does mean we can reject it anyway, but I
don't see anything to make it ill-formed that would require rejecting it
unconditionally.
16 matches
Mail list logo
