[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269 --- Comment #6 from sshannin at gmail dot com --- Thanks to you both for your analysis. As I said, I wasn't sure if it was an issue, so I'm certainly willing to accept that it's not. The one point I wanted to emphasize though just to make sure we're talking about the same thing is that it seems to odd to me that we're instantiating any form of comparison function for type T. We're comparing optional to nullopt_t, so it would seem that it shouldn't matter whether T itself is even comparable. More specifically, header defines operator<=>(const optional &x, nullopt_t), with the very simple body of bool(x) <=> false, as expected (circa line 1050, gated by #ifdef __cpp_lib_three_way_comparsion). This is why the non-flip case works, it hits the spaceship overload for (optional, null_opt_t). But there is no such operator in the other direction: (null_opt_t, optional). So we end up hitting optional's plain templated operator==() at ~line 1120, which of course ultimately instantiates the T's (broken/weird) operator. I guess to rephrase, should there also be a specialized spaceship overload for the (nullopt_t, optional) direction to complement the (optional, nullopt) one?
[Bug c++/98980] New: Very slow compilation with -Wduplicated-branches and ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98980 Bug ID: 98980 Summary: Very slow compilation with -Wduplicated-branches and ubsan Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Target Milestone: --- Created attachment 50136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50136&action=edit the code I have attached a heavily reduced example which encounters excessively slow compilation. I was not able to remove the stringstream include without the degenerate behavior disappearing, unfortunately; I hope that's ok. It seems to be mostly exponential in the number of operator<< invocations, with a couple interesting behaviors - s/long/int/g on the code allows it to compile almost instantly - removing any of the longs being streamed seems to halve the time, but so does replacing the variable with a literal - removing any of the string literals also halves the time. Compiled with flags: /toolchain14/bin/g++ -std=c++2a -Wduplicated-branches -c -fsanitize=undefined -o dup.o dup.cpp /toolchain14/bin/g++ -v Using built-in specs. COLLECT_GCC=/toolchain14/bin/g++ COLLECT_LTO_WRAPPER=/toolchain14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc_9_1_0/configure --prefix=/toolchain14 --enable-languages=c,c++,fortran --enable-lto --disable-plugin --program-suffix=-9.1.0 --disable-multilib Thread model: posix gcc version 9.1.0 (GCC)
[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #7 from sshannin at gmail dot com ---
Comment on attachment 37541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541
preprocessed source
> #include
> #include
> #include
>typedef std::unique_ptr inner_value_t;
>typedef std::map inner_data_t;
>
>typedef std::map data_t;
>
>
>data_t foo() {
>return data_t{};
>}
>
>int main(int argc, char **argv)
>{
>
>data_t d;
>d = foo();
>return 0;
>}
[Bug c/118194] New: spurious warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194
Bug ID: 118194
Summary: spurious warning with -Wmaybe-uninitialized
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
There are a number of other open bug reports about this warning, but none of
them seemed quite the same. This is different in that:
- doesn't rely on C++ constructs such as lambdas
- occurs at all optimization levels -O0 through -O3
- very simple path with no control flow
#include
#include
void *foo(int sz) {
void *p = malloc(sz);
mlock(p, sz);
return p;
}
The above minimal example triggers a maybe-uninitialized warning:
: In function 'foo':
:6:5: warning: 'p' may be used uninitialized [-Wmaybe-uninitialized]
6 | mlock(p, sz);
| ^~~~
In file included from :2:
/usr/include/x86_64-linux-gnu/sys/mman.h:103:12: note: by argument 1 of type
'const void *' to 'mlock' declared here
103 | extern int mlock (const void *__addr, size_t __len) __THROW;
|^
It looks like this was introduced starting in 11.1 and is present up through
trunk.
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 --- Comment #3 from sshannin at gmail dot com --- > The wording is also quite confusing - it should probably say 'dereferencing 'p' would access uninitialized memory'. Oh, indeed. I can certainly confirm that's how I interpreted it when filing this bug. I didn't even realize until your reply just now that it was talking about the (assumed) deref instead of p itself.
