[Bug libgcc/98390] New: AIX: exceptions in threads: IOT/Abort trap(coredump)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98390 Bug ID: 98390 Summary: AIX: exceptions in threads: IOT/Abort trap(coredump) Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compon

[Bug target/98390] AIX: exceptions in threads: IOT/Abort trap(coredump)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98390 --- Comment #1 from Stefan Krah --- The issue can still be reproduced with a gcc-14 snapshot. ibm-clang++ does not have this problem. The LLVM unwinder has been reworked for AIX: https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg275024

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753 --- Comment #16 from Stefan Krah --- I have encountered the same issue (gcc emits a false positive warning when free() is called conditionally) in the mpdecimal project when compiled with -flto. Worse, mpdecimal itself as well as a large test su

[Bug c/113203] New: __attribute__ ((always_inline)) fails with C99/LTO/-Og.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 Bug ID: 113203 Summary: __attribute__ ((always_inline)) fails with C99/LTO/-Og. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Prior

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #4 from Stefan Krah --- > Or, if the intention is that all calls to the function within its TU > are inlined and not the other ones, split the function into two, one > always_inline which is used from within the TU and another one wh

[Bug c/113664] New: False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 Bug ID: 113664 Summary: False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow) Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 --- Comment #2 from Stefan Krah --- Thanks for the explanation! I agree that one should not rely on -fno-strict-overflow. In this case, my project is "vendored" in CPython and they compile everything with -fno-strict-overflow, so it's out of my

[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 --- Comment #5 from Stefan Krah --- > So the diagnostic messages leave a lot to be desired but in the end > they point to a problem in your code which is a guard against a NULL 's'. Hmm, the real code is used to print floating point numbers and

[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 --- Comment #6 from Stefan Krah --- Sometimes you hear "code should be rewritten" because squashing the warnings makes it better. I disagree. I've seen many segfaults introduced in projects that rush to squash warnings. Sometimes, analyzers ju

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #8 from Stefan Krah --- As Richard wrote, C99 demands that an additional out-of-line copy of the function is generated. Whether the non-standard __attribute__ ((always_inline)) should override C99 is of course another question. For

[Bug sanitizer/119958] New: UBSAN: Replacing add with lea leads to false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119958 Bug ID: 119958 Summary: UBSAN: Replacing add with lea leads to false positive Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Com