[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #7 from James Y Knight --- On the libc++ side, a suggestion was given that instead of making this an _error_, we could instead emit a warning if "a constexpr or constinit object is a basic_string or contains a basic_string

[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #5 from James Y Knight --- > Does using __builtin_is_constant_p on the union member not work? I've created a proof-of-concept patch for libc++ to support SSO strings during constant evaluation. It works. If everyone disagrees with

[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #4 from James Y Knight --- vector and string are different in one key way: a zero-sized vector has no accessible storage, while a zero-sized string has 1 byte of readable storage -- the NUL terminator. Because of that, I don't think

[Bug libstdc++/111351] New: constexpr std::string objects permitted to escape constant evaluation when SSO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 Bug ID: 111351 Summary: constexpr std::string objects permitted to escape constant evaluation when SSO Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/98112] Add -f[no-]direct-access-external-data & drop HAVE_LD_PIE_COPYRELOC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #8

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #12

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #37 from James Y Knight --- (In reply to qinzhao from comment #35) > I think that -Wstrict-flex-arrays will need to be cooperated with > -fstrict-flex-arrays=N, i.e, only when -fstrict-flex-arrays=N is presenting, >

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #36 from James Y Knight --- (In reply to Kees Cook from comment #34) > > Great. Adding that flag, and eliminating the -fstrict-flex-arrays=3 option > > from this proposal would be good. > > Hmm? No, -fstrict-flex-arrays=3 is still

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #33 from James Y Knight --- (In reply to qinzhao from comment #32) > there is a Bugzilla that has been filed for GCC to request the same warning > for GCC: > https://gcc.gnu.org/bugzilla//show_bug.cgi?id=94428 > >

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #31

[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #3

[Bug c++/36685] clarify/diagnose use of weak constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685 --- Comment #5 from James Y Knight --- (oops submitted commit by mistake, continuing...) Strangely, it appears that Clang and GCC both have odd behaviors currently, but somewhat opposites: - GCC appears to evaluate weak constants _only_ in

[Bug c++/36685] clarify/diagnose use of weak constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #4

[Bug libstdc++/104602] std::source_location::current uses cast from void*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602 --- Comment #4 from James Y Knight --- Yea that should work. Or even just `auto`.

[Bug libstdc++/104602] New: std::source_location::current uses cast from void*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602 Bug ID: 104602 Summary: std::source_location::current uses cast from void* Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/100038] -Warray-bound triggers false positives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #8

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #6

[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #7

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918 --- Comment #6 from James Y Knight --- I realize that my suggestion above could only solve _most_ of the problem -- e.g. the original example, where the noexcept function doesn't have a try/catch in it. In that original example, there's no

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #5

[Bug inline-asm/100953] Add memory clobbers just for reads or just for writes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100953 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #3

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #10 from James Y Knight --- Seeing as GCC is now in Stage 4 before the next release, I'd like to ping this bug. Should the priority be upgraded? I think fixing this so that GCC doesn't use 'v111__alignof__' should be considered a

[Bug c++/98804] New: GCC misparses template in pack expansion as comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98804 Bug ID: 98804 Summary: GCC misparses template in pack expansion as comparison Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #9 from James Y Knight --- Proposed patch posted for the itanium-cxx-abi: https://github.com/itanium-cxx-abi/cxx-abi/pull/115/files using the syntax: u * E And to Clang, to use that syntax: https://reviews.llvm.org/D93922 I

[Bug target/98522] New: _mm_cvttps_pi32 and _mm_cvtps_pi32 raise spurious FP exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522 Bug ID: 98522 Summary: _mm_cvttps_pi32 and _mm_cvtps_pi32 raise spurious FP exceptions Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug target/98495] New: X86 _mm_extract_pi16 incorrectly sign extends result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98495 Bug ID: 98495 Summary: X86 _mm_extract_pi16 incorrectly sign extends result Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #7 from James Y Knight --- I've created an ABI proposal against itanium abi, here: https://github.com/itanium-cxx-abi/cxx-abi/issues/112 I realized since writing my last comment here that ::= u [] # vendor extended type has been

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #6 from James Y Knight --- > c++: Change the mangling of __alignof__ [PR88115] The new mangling chosen for __alignof__(type) seems problematic, and I think this commit ought to be reverted until a new mangling scheme has been

[Bug libstdc++/97449] New: libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 Bug ID: 97449 Summary: libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b Product: gcc Version: 11.0 Status: UNCONFIRMED