[Bug c++/116746] New: Explicit specializations of static variable templates are incorrectly given external linkage

2024-09-16 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116746 Bug ID: 116746 Summary: Explicit specializations of static variable templates are incorrectly given external linkage Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug c++/115658] char16_t and char32_t aliasing is conserative

2024-06-28 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658 --- Comment #3 from Tom Honermann --- In retrospect, I think I misunderstood Andrew's motivation for filing this issue. There is a difference of behavior between gcc and clang with regard to aliasing of `char16_t` and `char32_t` with respect to

[Bug c++/115658] char16_t and char32_t aliasing is conserative

2024-06-26 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #2

[Bug c/111884] [13/14 Regression] unsigned char no longer aliases anything under -std=c2x

2023-10-19 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884 --- Comment #4 from Tom Honermann --- (In reply to Marek Polacek from comment #3) > Thanks, I can test Thank you. That change looks right. My apologies for introducing the regression.

[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored

2022-08-17 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #3 from Tom Honermann --- I believe this issue can be resolved as fixed via commit 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release.

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

2022-08-09 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 --- Comment #3 from Tom Honermann --- I believe this issue can be resolved as fixed via commit 053876cdbe8057210e6f4da4eec2df58f92ccd4c for the gcc 13 release.

[Bug preprocessor/106426] UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

2022-08-08 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 --- Comment #1 from Tom Honermann --- A patch for this issue was submitted to the gcc-patches mailing list with the patch series available at https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599240.html.

[Bug c++/106426] New: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode

2022-07-24 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426 Bug ID: 106426 Summary: UTF-8 character literals do not have unsigned type in the preprocessor in -fchar8_t mode Product: gcc Version: 9.0 Status: UNCONFIRMED

[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored

2022-07-23 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #1 from Tom Honermann --- A patch for this issue was submitted to the gcc-patches mailing list and is available at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html.

[Bug c++/106423] New: -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored

2022-07-23 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 Bug ID: 106423 Summary: -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: no

[Bug c++/71136] [concepts] Spurious 'converting overloaded function is ambiguous' error.

2021-11-11 Thread tom at honermann dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136 --- Comment #3 from Tom Honermann --- (In reply to Andrew Pinski from comment #2) > Hmm, clang and MSVC also reject the code in comment #1 (the one without the > bool) for the same reason as GCC. Interesting. Perhaps this is a common compiler bu