Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bobogu at atlas dot cz
Target Milestone: ---
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bobogu at atlas dot cz
Target Milestone: ---
Created attachment 44558
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44558&action=edit
preprocessed TU
According to the standard, there is no assignment operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016
--- Comment #2 from bobogu at atlas dot cz ---
Do I understand it correctly that this will get optimized into one statement
saying
bar = std::optional(10);
If so, is there something that could prevent such optimizations in order to
check if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016
--- Comment #4 from bobogu at atlas dot cz ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to bobogu from comment #2)
> When you assign an int to optional it is equivalent to constructing a
> temporary optional and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016
--- Comment #7 from bobogu at atlas dot cz ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to bobogu from comment #4)
> All implementations define the assignment operator as defaulted, and so the
> compiler makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016
--- Comment #9 from bobogu at atlas dot cz ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to bobogu from comment #7)
> > All right, I'm sorry then... I just thought that as this is undocumented, it
> > could
