[Bug c/108295] New: Free label positions shouldn't be available outside -std=c2x

[Bug c/108295] New: Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

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.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #1 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
Created attachment 54193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54193&action=edit
Correctly working true/false vs incorrectly free position of label

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
Free positioning of labels inside compound statements doesn't affect correctly
written programs.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #3 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-01-05
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Try -pedantic-errors.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #5 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
(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/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #7 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
"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

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[daniel.lundin.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #9 from Daniel Lundin <daniel.lundin.mail at gmail dot com> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
By conflicting means rejection of correct code. Like for an example the use of
the ident non reserved unix, etc.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Daniel Lundin from comment #9)
> 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.

In such understanding all extensions would contradict the standard, extensions
are when some otherwise invalid source is given a meaning, which is this case
too.
Even in C++ we often enable features of a newer standard in older ones as long
as they don't conflict with valid syntax, just with pedantic warnings/errors. 
It is possible
if the new feature has a new syntax which is invalid in the old standard, so
e.g. structured bindings can be accepted in older standards with pedantic
warnings/errors just fine because in older standards it was always invalid
syntax.  Compare that to features where say the behavior of some construct
changes with a newer standard version, that one obviously can't be treated that
way.
And -pedantic/-pedantic-errors are the options to request pedantic warnings or
errors.

[Bug c/108295] Free label positions shouldn't be available outside -std=c2x

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> By conflicting means rejection of correct code. Like for an example the use
> of the ident non reserved unix, etc.

The documentation even mentions that. You only read the snippet of what I
copied rather than reading the whole thing.