[Bug c++/114309] Undesirable warning with [[unlikely]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309 --- Comment #11 from M Welinder --- > Anyway, in GCC's testcase we have: > > 9 if (a == 123) > 10 [[likely]] c = 5; // { dg-warning "both" } > 11 else > 12 [[likely]] b = 77; > Here we have two possible paths, and

[Bug c++/114309] Undesirable warning with [[unlikely]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309 --- Comment #1 from M Welinder --- Created attachment 57672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57672=edit Preprocessed source code

[Bug c++/114309] New: Undesirable warning with [[unlikely]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309 Bug ID: 114309 Summary: Undesirable warning with [[unlikely]] Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/113811] New: std::rotate does 64-bit signed division

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811 Bug ID: 113811 Summary: std::rotate does 64-bit signed division Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #48 from M Welinder --- It's your (1). gcc is changing a program that can rely on errno not being changed to one where the C library can change it. (The current C library or any future library that the resulting binary may be

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #46 from M Welinder --- Should "-std=c99" imply turning off these optimizations? Creating calls to, say, strlen is incompatible with the C99 standard and perhaps better limited to "-std=gnu-something" or an opt-in f-flag.

[Bug c/112614] New: Compile-time float-to-_Decimal64 fails for -NAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112614 Bug ID: 112614 Summary: Compile-time float-to-_Decimal64 fails for -NAN Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 --- Comment #11 from M Welinder --- >/home/jwakely/gcc/14/include/c++/14.0.0/compare:160:5: note: declared here > 160 | operator<=>(partial_ordering, __cmp_cat::__not_literal_zero auto) > = delete; > | ^~~~ I don't think we

[Bug libstdc++/112569] New: libstdc++-v3/include/ranges:1456: missing check for self-assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112569 Bug ID: 112569 Summary: libstdc++-v3/include/ranges:1456: missing check for self-assignment Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725 M Welinder changed: What|Removed |Added CC||terra at gnome dot org --- Comment #10

[Bug c++/109909] New: vector: Writing 8 bytes into 1 allocated byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109909 Bug ID: 109909 Summary: vector: Writing 8 bytes into 1 allocated byte Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/109536] New: Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 Bug ID: 109536 Summary: Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/109517] New: Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 Bug ID: 109517 Summary: Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal

[Bug preprocessor/108108] "gcc -MM" fails to list all dependencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108 --- Comment #4 from M Welinder --- > Since it was not read again, the file is not considered included ... It must have been read -- how else could gcc decide it was the same? # strace -f gcc -MM c.c 2>&1 >Makefile | grep 'open.*\.h' | grep

[Bug other/108108] New: "gcc -MM" fails to list all dependencies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108 Bug ID: 108108 Summary: "gcc -MM" fails to list all dependencies Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug preprocessor/52566] #include with #pragma once and files' contents is the same

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 --- Comment #5 from M Welinder --- >From 108101: Note also: # gcc -MM c.c c.o: c.c a.h No b.h present! I.e., Makefiles built with this will not pick up changes to the second file.

[Bug preprocessor/108101] "#pragma once" causes other files not be included

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108101 --- Comment #3 from M Welinder --- Note also: # gcc -MM c.c c.o: c.c a.h No b.h present!

[Bug preprocessor/108101] New: "#pragma once" causes other files not be included

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108101 Bug ID: 108101 Summary: "#pragma once" causes other files not be included Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/105960] Crash in 32-bit mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 --- Comment #4 from M Welinder --- And added to the link lines too, btw.

[Bug target/105960] Crash in 32-bit mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 M Welinder changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug c/105960] New: Crash in 32-bit mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 Bug ID: 105960 Summary: Crash in 32-bit mode Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee:

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084 --- Comment #9 from M Welinder --- I went back and looked at the proposal's revision history. TLDR: this just adds to the confusion. r3 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r3.html): * I read it as allowing "using

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084 --- Comment #7 from M Welinder --- Maybe kick it up to the C++ people? Note, that if the code is not allowed then a type alias is no longer as powerful as the original type. I really doubt that was intended.

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084 --- Comment #6 from M Welinder --- elaborated-enum-specifier can be a elaborated-type-specifier. It is in the "enum Hog H;" case. But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using enum Hog;" case, See

[Bug c++/103084] Accepts invalid using enum declaration with an invalid elaborated-type-specifier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084 --- Comment #3 from M Welinder --- I actually think gcc is right there. http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier There are requirements for elaborated-type-specifier, but none for elaborated-enum-specifier. It's a

[Bug c++/103087] New: "using enum" possibly incorrectly accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087 Bug ID: 103087 Summary: "using enum" possibly incorrectly accepted Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/103081] [ICE] with "using enum"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 --- Comment #4 from M Welinder --- That version of clang does not do "using enum" at all. clang 13 accepts this code, but it has other issues with "using enum".

[Bug c++/103081] New: [ICE] with "using enum"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Bug ID: 103081 Summary: [ICE] with "using enum" Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 --- Comment #2 from M Welinder --- IMHO, nullptr_t would not be an improvement here. We would still have the combination of: (1) Correct usage causing a warning (2) The warning hinting at using the incorrect nullptr instead. (3) po>> bool

[Bug libstdc++/100903] New: Bogus "zero as null pointer constant" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 Bug ID: 100903 Summary: Bogus "zero as null pointer constant" warning Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/99876] New: std::filesystem::absolute is inefficient

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 Bug ID: 99876 Summary: std::filesystem::absolute is inefficient Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: