[Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum

[Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum

[klaus.doldinger64 at googlemail dot com]

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

            Bug ID: 109532
           Summary: -fshort-enums does not pick smallest underlying type
                    for scoped enum
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

In the follwoing code, the best code with 8-bit underlying for the enum-type is
only optimized for unscoped enum.
The scoped enum always produces a 16-bit enum underlying type.

Compile with: -Os -mmcu=atmega328  -fshort-enums

(note: equivalent C code (unscoped enums) produces optimal code with
-fshort-enums) 

#include <avr/io.h>
#include <stdint.h>

volatile uint8_t o;

struct FSM {
//    enum class State : uint8_t {A, B, C, D};// <2> 8bit enum
//    enum State {A, B, C, D};                // <3> 8bit enum with
-fshort-enums
    enum class State {A, B, C, D};            // <1> 16bit enum with
-fshort-enums
    static void f() __attribute__((noinline)) {
        switch(mState) {
        case State::A:
            o = 10;
            break;
        case State::B:
            o = 11;
            break;
        case State::C:
            o = 12;
            break;
        case State::D:
            o = 13;
            break;
        }
    }
private:
    inline static State mState{State::A};
};

int main() {
    while(true) {
        FSM::f();
    }
}

[Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is because a scopped enum has an underlying type of int if not supplied.

From [dcl.enum]/5:
For a scoped enumeration type, the underlying type is int if it is not
explicitly specified.

[Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> That is because a scopped enum has an underlying type of int if not supplied.
> 
> From [dcl.enum]/5:
> For a scoped enumeration type, the underlying type is int if it is not
> explicitly specified.

I should say this is from the C++ standard there.
-fshort-enums does not change the language, only ABI.

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[klaus.doldinger64 at googlemail dot com]

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

--- Comment #3 from Wilhelm M <klaus.doldinger64 at googlemail dot com> ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > That is because a scopped enum has an underlying type of int if not supplied.
> > 
> > From [dcl.enum]/5:
> > For a scoped enumeration type, the underlying type is int if it is not
> > explicitly specified.
> 
> I should say this is from the C++ standard there.
> -fshort-enums does not change the language, only ABI.

Isn't this a case where the as-if rule kicks in?

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Wilhelm M from comment #3)
> Isn't this a case where the as-if rule kicks in?

What rule is that? Scopped enums are different from unscopped ones here
specifically as defined in the C++ standard.

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[klaus.doldinger64 at googlemail dot com]

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

--- Comment #5 from Wilhelm M <klaus.doldinger64 at googlemail dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Wilhelm M from comment #3)
> > Isn't this a case where the as-if rule kicks in?
> 
> What rule is that? Scopped enums are different from unscopped ones here
> specifically as defined in the C++ standard.

Ok, I see the point as the C++ standard nails down the type to int disallowing
any as-if optimization.

So in general a scoped-enum inside a class (nested type) maybe always a bad
idea, because it prevents optimization. And when specifying the underlying
type, the -fstrict-enums can't be applied because all values of the underlying
type are possible.

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Wilhelm M from comment #5)
> So in general a scoped-enum inside a class (nested type) maybe always a bad
> idea, because it prevents optimization.

I don't know how you have drawn that conclusion or how it's related to this bug
report.

> And when specifying the underlying
> type, the -fstrict-enums can't be applied because all values of the
> underlying type are possible.

Correct, with a fixed underlying type -fstrict-enums and -fshort-enums have no
effect.

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:d8a656d5b6246457e84934bc35115c134bc38def

commit r14-932-gd8a656d5b6246457e84934bc35115c134bc38def
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Apr 27 12:02:38 2023 +0100

    doc: Describe behaviour of enums with fixed underlying type [PR109532]

    gcc/ChangeLog:

            PR c++/109532
            * doc/invoke.texi (Code Gen Options): Note that -fshort-enums
            is ignored for a fixed underlying type.
            (C++ Dialect Options): Likewise for -fstrict-enums.

    Reviewed-by: Marek Polacek <polacek@redhat.com>

[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've updated the docs to make this clear.