[Bug libstdc++/112477] Assignment of value-initialized iterators differs from value-initialization

[dave.martin at giref dot ulaval.ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477

Dave Martin  changed:

   What|Removed |Added

 CC||dave.martin at giref dot 
ulaval.ca

--- Comment #3 from Dave Martin  ---
I have a very similar issue using operator= (https://godbolt.org/z/cj7Gbn1e8)

#define _GLIBCXX_DEBUG
#include 

int main()
{ 
  using S = std::set;

  S set {1};
  auto it = set.begin();
  it = S::const_iterator();

  auto it2 = it; 

  return 0;
}

Results in 

  Error: attempt to copy-construct an iterator from a singular iterator.

I am also confused as to why this shouldn't "just work".

[Bug libstdc++/112477] Assignment of value-initialized iterators differs from value-initialization

[dave.martin at giref dot ulaval.ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477

--- Comment #5 from Dave Martin  ---
(In reply to Jonathan Wakely from comment #4)
> Because in C++11 any use of a singular iterator, even copying it, was
> undefined behaviour. The debug mode checks have not been properly updated to
> reflect the relaxed preconditions in more recent standards.

I'm a little confused by your response. I recently found this change in our
test suite when we updated our compilers. Our code works fine in gcc 12.3 but
returns the copy-construct error in 13.2 (as shown in the godbolt example),
both using C++17.

Are you saying the debug mode of gcc 13.2 has not been properly updated to
reflect the changes in C++17?

Because, from my understanding, gcc 13.2 added a check that restrains the
preconditions. 

In other words, you seem to be saying that 13.2 was not updated to relax the
preconditions, but the behaviour I am seeing is that 13.2 added a restraint on
the preconditions.

I think the change comes from this commit:
https://github.com/gcc-mirror/gcc/commit/01b1afdc35c13cbff5cd3d37f9319285ab84b157