https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114266
--- Comment #3 from Daniel Lundin ---
(In reply to Joseph S. Myers from comment #2)
> The relevant constraint here is "An array of unknown size shall not be
> initialized by an empty initializer.".
Indeed! I didn't realize it was also a constra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114266
--- Comment #1 from Daniel Lundin ---
Created attachment 57643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57643&action=edit
Complete example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114266
Bug ID: 114266
Summary: No -pedantic diagnostic for zero-sized array in
compound literals
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #25 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #24)
> On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
Regardless of how one chose to read that part of the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #23 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #21)
> On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
> > First of all, it is questionable if gcc is still conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #20 from Daniel Lundin ---
Further info about the "ARM32 port bug".
In case you write code like `(uint32_t)&function_pointer` and the port happens
to use 32 bit pointers, the non-conforming cast is let through.
In case you cast to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764
--- Comment #6 from Daniel Lundin ---
Call it what you will, either way there is nothing here that's "so large that
it is unsigned". The main point is that the diagnostic message is wrong.
typeof(18446744073709551615) x = -1;
Gives a 128 bit in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #3 from Daniel Lundin ---
(In reply to Segher Boessenkool from comment #2)
> This is not a dup of 33053 (see PR33053#c5 and PR33053#c6). Reopening, and
> confirmed. There should be a read from memory: that is a side effect, it has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
--- Comment #5 from Daniel Lundin ---
The intention of DR 476 (Sebor)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476 was a
clarification leading to a volatile lvalue access being a side effect, as
opposed to an access of vola
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #9 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #8)
> "When a base standard is specified, the compiler accepts all programs
> following that standard plus those using GNU extensions that do not
> contradict it."
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #7 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Daniel Lundin from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > Try -pedantic-errors.
> >
> > Yes I already did and then the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #5 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #4)
> Try -pedantic-errors.
Yes I already did and then the error appears. But that would imply that this is
a non-standard GNU extension and not an upcoming standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
Bug ID: 108298
Summary: Wrong optimization of volatile access from gcc 11 and
beyond
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #3 from Daniel Lundin ---
(In reply to Andreas Schwab from comment #2)
> Free positioning of labels inside compound statements doesn't affect
> correctly written programs.
No but until C23, the compiler should report an error for in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #1 from Daniel Lundin ---
Created attachment 54193
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54193&action=edit
Correctly working true/false vs incorrectly free position of label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
Bug ID: 108295
Summary: Free label positions shouldn't be available outside
-std=c2x
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
20 matches
Mail list logo
