[Bug tree-optimization/109290] warning: array subscript -50 is outside array bounds of ‘struct kobject[36028797018963967]’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109290 lavr at ncbi dot nlm.nih.gov changed: What|Removed |Added CC||lavr at ncbi dot

[Bug middle-end/104069] Wuse-after-free=2 -O0 false positive "may be used"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 lavr at ncbi dot nlm.nih.gov changed: What|Removed |Added CC||lavr at ncbi dot

[Bug libstdc++/108561] std::endl causes a flush on a bad stream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 --- Comment #3 from lavr at ncbi dot nlm.nih.gov --- Also, the standard seems to mention that flush() is an "unformatted output function", meaning it is supposed to build and check a sentry object (which in case of a bad stream, would fail, so

[Bug libstdc++/108561] std::endl causes a flush on a bad stream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Indeed, it does not. But the reason the endl manipulator is there, is to flush _after_ '\n'. If the stream has gone bad in between, it is the gray area, but for the output device (the stream

[Bug libstdc++/108561] New: std::endl causes a flush on a bad stream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561 Bug ID: 108561 Summary: std::endl causes a flush on a bad stream Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/107465] New: Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 Bug ID: 107465 Summary: Bogus warning: promoted bitwise complement of an unsigned value is always nonzero Product: gcc Version: 11.3.0 Status: UNCONFIRMED

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293 --- Comment #10 from lavr at ncbi dot nlm.nih.gov --- > In your code, `>record.data[0]` is not a well-aligned access It is well-aligned, its offset gets printed out by the very test code, and it's 2. > because `struct attribute` is defined as

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293 --- Comment #8 from lavr at ncbi dot nlm.nih.gov --- Consider the following code: struct record { unsigned char len; unsigned short data[5]; } __attribute__((packed)); struct attribute { unsigned char code; struct record

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96293 --- Comment #7 from lavr at ncbi dot nlm.nih.gov --- The problem with the aligned(4) attribute is that if this structure appears as a member of an outer packed structure, it may not be "enclosed" properly without a gap. The warnings are

[Bug middle-end/106092] Bogus -Wfree-nonheap-object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106092 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Created attachment 53201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53201=edit preprocessed source Attached! It's rather big

[Bug c++/106092] New: Bogus -Wfree-nonheap-object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106092 Bug ID: 106092 Summary: Bogus -Wfree-nonheap-object Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug tree-optimization/103835] bogus sprintf warnings due to missing strlen propagation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835 --- Comment #4 from lavr at ncbi dot nlm.nih.gov --- Thank you for investigating this! Like I said, it's better NOT to emit any warnings if some machinery in the compiler is not perfect enough to recognize the danger correctly (as it used to be

[Bug tree-optimization/103835] Bogus sprintf warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Irrespective of whether atoi() is known, printing an "int" (or two) will never produce this many characters... This, however, also seems to have triggered some weird logic that took the

[Bug c/103835] New: Bogus sprintf warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835 Bug ID: 103835 Summary: Bogus sprintf warnings Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee:

[Bug c/100403] Bogus "function may return address of local variable" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] Indeed for the segmented data address space. But in most systems it's linear, and the warning is then architecture

[Bug middle-end/100401] Bogus -Wformat-overflow for a trailing zero-length array of a union

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > GCC warnings are designed to "report constructions that are not inherently > erroneous but that are risky or suggest there may have been an error." Certainly, but the [0] size trailing

[Bug c/100403] New: Bogus "function may return address of local variable" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 Bug ID: 100403 Summary: Bogus "function may return address of local variable" warning Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/100401] New: Bogus -Wformat-overflow warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 Bug ID: 100401 Summary: Bogus -Wformat-overflow warning Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/100395] New: Bogus -Wstringop-overflow warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 Bug ID: 100395 Summary: Bogus -Wstringop-overflow warning Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c