[Bug c/114266] No -pedantic diagnostic for zero-sized array in compound literals
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 constraint (C23 6.7.10). That probably means that a diagnostic warning should always be given and not just in -pedantic mode.
[Bug c/114266] No -pedantic diagnostic for zero-sized array in compound literals
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=edit Complete example
[Bug c/114266] New: No -pedantic diagnostic for zero-sized array in compound literals
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.lundin.mail at gmail dot com
Target Milestone: ---
(int[]){}; produces no diagnostics with -std=c23 -pedantic.
Empty initalizer lists are OK under -std=c23 and -std=gnu so that's not the
problem. gcc correctly gives a diagnostic for that in -std=c17 -pedantic mode.
Zero-sized arrays should however give a diagnostic in -std=cxx -pedantic mode.
Prior to C23 this was not really a problem as we would get a diagnostic for the
empty initializer list. But now this non-conforming C compiles cleanly even
with -pedantic set.
A diagnostic similar to the one given in clang would be good:
warning: zero size arrays are an extension [-Wzero-length-array]
As I understand it, gcc did have -Wzero-length-array in the past but removed
it? See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428. The options
-Wstrict-flex-arrays -fstrict-flex-arrays seem to have no effect (and my
example isn't a flexible array member but a compound literal).
[Bug middle-end/108036] [11/12/13/14 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Daniel Lundin changed: What|Removed |Added CC||daniel.lundin.mail at gmail dot co ||m --- Comment #8 from Daniel Lundin --- I don't believe char past_end[0] is valid C, because it is an invalid array declaration. Unlike [] or [*] that declares an array of incomplete type. Since it is a function parameter, it will of course later get adjusted to a pointer to the first element. But it still has to be a valid declaration to begin with. Similarly, char arr[][] is invalid because it remains an incomplete type after adjustment (see C17 6.7.6.4 §4). gcc does allow [0] as an extension since that was commonly used for purposes of implementing the "struct hack" back in the days before flexible array members were standardized. The conclusion ought to be that gcc should let [0] through if compiled in -std=gnu23 mode but not in -std=c23 and/or -pedantic.
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 Daniel Lundin changed: What|Removed |Added CC||daniel.lundin.mail at gmail dot co ||m --- Comment #6 from Daniel Lundin --- (In reply to jos...@codesourcery.com from comment #5) > The straw poll at the June meeting said to keep calling it C23 (votes > 4/12/2 for/against/abstain on the question of changing the informal name > to C24). Of course the actual standard will be ISO/IEC 9899:2024 (but > __STDC_VERSION__ will remain as 202311L, consistent with the informal name > rather than the publication date, in the absence of a technical DIS > comment requesting a change of version number being accepted, and > accepting any technical DIS comments would delay the standard by requiring > an FDIS). Please keep in mind that -std=c2x uses a placeholder value of 202000L for __STDC_VERSION__, whereas WG14 has decided that 202311L should be used for the final version. Worth considering when -std=c23 goes live.
[Bug c/69960] "initializer element is not constant"
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, fact remains that this part of the standard has not changed since C89 but still gcc behaves wildly different depending on version. This makes it impossible to port strictly conforming programs between different gcc versions, because then you'll either get a diagnostic that you (arguably) shouldn't be getting, or you will not get a diagnostic where you (arguably) should be expecting one. This makes gcc a hazard in my case. My choices are to forbid newer versions or to port to a different compiler. In case -pedantic would still result in a diagnostic past version 8 then that would make gcc behave consistently across versions and that would solve the problem. As was already mentioned previously in this thread, before this change was implemented with that remark ignored. Additionally there is bug #2 where (uint32_t)_pointer does not give a diagnostic in case the pointer is 32 bit, which is non-conforming behavior for constant expressions. I should perhaps open a separate bug report about that since I'm not sure if it's related to this one.
[Bug c/69960] "initializer element is not constant"
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 conforming after the change > > discussed here and implemented as per gcc 8.0. Yes "an implementation may > > accept other forms of constant expressions" but that doesn't mean that a > > compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the > > definition > > of an integer constant expression. So this ought to explicitly be a compiler > > extension and we ought to have a way to reliably compile strictly conforming > > programs with gcc without constraint violations silently getting ignored. > > "integer constant expression" does not mean the same thing as "constant > expression of integer type". Yes, who said otherwise? Rather, this is the problem. Please check out the link I gave for the full reasoning including quotes. https://stackoverflow.com/questions/68252570/why-are-const-qualified-variables-accepted-as-initializers-on-gcc Specifically (C17 6.6): "An integer constant expression shall have integer type and shall only have operands that are integer constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, _Alignof expressions, and floating constants that are the immediate operands of casts." In this code static const int y = 1; static int x = y; y is not an integer constant expression, nor is it an integer constant in the meaning that ISO 9899 defines it. Therefore an initializer was given which is not a constant expression. Therefore this is a constraint violation of C17 6.7.9/4 and a diagnostic must be issued. Therefore gcc is not conforming because of the "bug fix" carried out above. "an implementation may accept other forms of constant expressions" does not mean that an implementation can throw out any constraints it pleases out the window. Also the text "however, they are not an integer constant expression" added in C23 must have been added for a reason, such as misbehaving compilers.
[Bug c/69960] "initializer element is not constant"
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)_pointer` and the port happens to use 32 bit pointers, the non-conforming cast is let through. In case you cast to an integer type of different size in relation to the pointer size (non-portable cast), you first get a warning about that: "warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]", followed by the diagnostic "error: initializer element is not computable at load time". https://godbolt.org/z/xjYvd41qe Correct compiler behavior here is to always give a diagnostic for (uint32_t)_handler not being an acceptable arithmetic constant expression. If that's the same "implementation may accept other forms of constant expressions" bug as originally discussed here or a different bug, I don't know.
[Bug c/69960] "initializer element is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960 Daniel Lundin changed: What|Removed |Added CC||daniel.lundin.mail at gmail dot co ||m --- Comment #19 from Daniel Lundin --- This ought to be discussed again. "clang allows it" is not an argument. First of all, it is questionable if gcc is still conforming after the change discussed here and implemented as per gcc 8.0. Yes "an implementation may accept other forms of constant expressions" but that doesn't mean that a compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the definition of an integer constant expression. So this ought to explicitly be a compiler extension and we ought to have a way to reliably compile strictly conforming programs with gcc without constraint violations silently getting ignored. So if this feature is desired as an extension (I'm sure it is), then the old diagnostic message should still be there when compiling as -std=c17 -pedantic. See detailed discussion and relevant ISO 9899 quotes here: https://stackoverflow.com/questions/68252570/why-are-const-qualified-variables-accepted-as-initializers-on-gcc On top of that mess, I just found out that gcc behaves inconsistently in regards of constant expressions between compiler ports. All gcc ports reject an initializer such as (uint32_t)_pointer as they ought, except gcc for ARM32 which silently allows this even under strict mode. This as per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108875 which I think is NOT a bug, since the definition of an arithmetic constant expression (6.6) always had "Cast operators in an arithmetic constant expression shall only convert arithmetic types to arithmetic types". A function/object pointer is not an arithmetic type. A normative "shall" was violated. A conforming compiler must issue a diagnostic. If the C standard by design blocks meaningful use of some constant expressions inside initializer lists (I would agree that it does, the linked bug report above is a very valid use-case in embedded systems), then gcc has the option to make an extension and only warn in -pedantic mode. Bug again, this route was not taken there either. Standard compliance was just silently abandoned in the ARM32 port. Therefore the current state of affairs is: gcc <8.0 (IMO compliant) behaves differently from gcc >=8.0 which in turn behaves differently from gcc ARM32 any version. Three different gcc behaviors for a language feature which has NOT changed at all between C90 to C17. All of this has to be revisited for the C23 constexpr/"named constants" implementation, so it would be great if we at the same time can separate non-standard extensions from -pedantic mode. Notably C23 does not allow casts from non-arithemtic types inside arithmetic constant expressions either. Also note that C23 changed the wording slightly from C17: "An implementation may accept other forms of constant expressions; however, they are not an integer constant expression." I don't know why but likely because of some implemented DR.
[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant
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 integer type with the value -1. If it was "so large that it is unsigned" then this would have resulted in an unsigned type with an unsigned value. The diagnostic message is plain wrong and misleading.
[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764 Daniel Lundin changed: What|Removed |Added CC||daniel.lundin.mail at gmail dot co ||m --- Comment #3 from Daniel Lundin --- This is a bug as in the wrong text is displayed in the diagnostic message. gcc picks `__int128` and it is not an unsigned type. Decimal integer constants use the the quoted list in 6.4.4.1: `int` then `long` then `long long`. Therefore this normative text (from C99 to C23) applies: "If all of the types in the list for the constant are signed, the extended integer type shall be signed." gcc behaves just like required too, since `__int128` ought to be one of the extended integer types and it is signed. I would guess this message is some remain from C90 where extended integer types didn't exist. Compiling with -std=c90 adds an additional warning "warning: this decimal constant is unsigned only in ISO C90". It would appear that this is the correct warning that should always be displayed. Seems to be a minor bug that occurred during the switch (gcc 5.0.0) from gnu90 to gnu11 as default option.
[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond
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 > to be executed in the real machine as in the abstract machine. This is however very much related to DR476 which is now implemented as per C23. So conformance to DR476 should be on the C23 TODO-list.
[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension
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 volatile objects. Changes from the DR were included in C23. The C23 n3054 draft now says "An access to an object through the use of an lvalue of volatile-qualified type is a volatile access. A volatile access to an object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects-..." This ought to result in stricter optimizing behavior from gcc, not the other way around. As reported in bug 108298 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298), gcc 11 and beyond rather seems to optimize more aggressively, which it didn't up to version 10.4.
[Bug c/108295] Free label positions shouldn't be available outside -std=c2x
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." > > Wrong again. > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/C-Dialect-Options.html#index- > std-1 In this case the GNU extension does contradict the ISO 9899:2018 standard. A conforming compiler is required to issue a diagnostic (as per 5.1.1.3) upon spotting a violation of the syntax in 6.8.1.
[Bug c/108295] Free label positions shouldn't be available outside -std=c2x
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 error appears. But that would imply that this > > is a non-standard GNU extension and not an upcoming standard C23 feature, > > which still doesn't seem correct. > > > > If the intention was to add this as a GNU extension until formal release of > > C23, then the use of such GNU extensions will behave inconsistently between > > gcc <10.4 and gcc >11.0 when using the same compiler options. And I don't > > think that's documented anywhere either. > > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Mixed-Labels-and-Declarations. > html#Mixed-Labels-and-Declarations > > Compared to > https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/Mixed-Declarations.html#Mixed- > Declarations > > Is definitely documented. Fair enough but GNU C mode is -std=gnu17 (the default setting), not -std=c17.
[Bug c/108295] Free label positions shouldn't be available outside -std=c2x
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 C23 feature, which still doesn't seem correct. If the intention was to add this as a GNU extension until formal release of C23, then the use of such GNU extensions will behave inconsistently between gcc <10.4 and gcc >11.0 when using the same compiler options. And I don't think that's documented anywhere either.
[Bug c/108298] New: Wrong optimization of volatile access from gcc 11 and beyond
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 Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.lundin.mail at gmail dot com Target Milestone: --- Created attachment 54194 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54194=edit Example to reproduce incorrect optimizations Before gcc 11.0.0, the attached example compiled under -O3 would result in the whole function getting optimized into a single load instruction when volatile was not used. Adding a volatile access would lead to instructions for fetching the value from the stack getting generated. This appears to be conforming behavior, references ISO/IEC 9899:2018 5.1.2.3, particularly §2, §4 and §6. I believe gcc 10.4 or older behaves correctly. After gcc 11.0.0, the function is optimized regardless of if volatile is used or not. See attached example. With FREE_TO_OPTIMIZE defined, I would expect the compiler to optimize the code under -O3. Without it, I would expect the compiler to generate a read instruction since this is a "side effect". For convenience, here is also an online compiler example for x86-64 Linux https://godbolt.org/z/4qez1P746
[Bug c/108295] Free label positions shouldn't be available outside -std=c2x
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 incorrect syntax when
they aren't. For example when declaring a variable inside a case statement
without using {} compound statements.
[Bug c/108295] Free label positions shouldn't be available outside -std=c2x
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=edit Correctly working true/false vs incorrectly free position of label
[Bug c/108295] New: Free label positions shouldn't be available outside -std=c2x
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 Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.lundin.mail at gmail dot com Target Milestone: --- The new C23 features introduced in gcc 11.0.0 appears to be inconsistently deactivated when picking some other version than -std=c2x. The new C23 feature "Free positioning of labels inside compound statements" appears to be active even with -std=c17 or the default gnu17 is picked. Unlike other C23 features introduced in the same version 11 release, which are correctly activated when using -std=c2x or otherwise inactivated. For example gcc treats true/false as bool when activating -std=c2x but treats them as int when older C versions are used. Free positioning of labels should behave just in the same manner. See attached example.
