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
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
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
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
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:
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
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
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
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
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
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++
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
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
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:
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
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
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
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
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
19 matches
Mail list logo