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

2024-01-30 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-30 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-29 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-29 Thread stefan at bytereef dot org via Gcc-bugs
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 ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

2024-01-03 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-02 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-02 Thread stefan at bytereef dot org via Gcc-bugs
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

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

2024-01-02 Thread stefan at bytereef dot org via Gcc-bugs
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:

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

2020-12-19 Thread stefan at bytereef dot org via Gcc-bugs
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