public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum
@ 2023-04-17 5:08 klaus.doldinger64 at googlemail dot com
2023-04-17 5:16 ` [Bug rtl-optimization/109532] " pinskia at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: klaus.doldinger64 at googlemail dot com @ 2023-04-17 5:08 UTC (permalink / raw)
To: gcc-bugs
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();
}
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
@ 2023-04-17 5:16 ` pinskia at gcc dot gnu.org
2023-04-17 5:16 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-04-17 5:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug rtl-optimization/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
2023-04-17 5:16 ` [Bug rtl-optimization/109532] " pinskia at gcc dot gnu.org
@ 2023-04-17 5:16 ` pinskia at gcc dot gnu.org
2023-04-17 5:24 ` [Bug c++/109532] " klaus.doldinger64 at googlemail dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-04-17 5:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
2023-04-17 5:16 ` [Bug rtl-optimization/109532] " pinskia at gcc dot gnu.org
2023-04-17 5:16 ` pinskia at gcc dot gnu.org
@ 2023-04-17 5:24 ` klaus.doldinger64 at googlemail dot com
2023-04-17 5:30 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: klaus.doldinger64 at googlemail dot com @ 2023-04-17 5:24 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
` (2 preceding siblings ...)
2023-04-17 5:24 ` [Bug c++/109532] " klaus.doldinger64 at googlemail dot com
@ 2023-04-17 5:30 ` pinskia at gcc dot gnu.org
2023-04-17 5:37 ` klaus.doldinger64 at googlemail dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-04-17 5:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
` (3 preceding siblings ...)
2023-04-17 5:30 ` pinskia at gcc dot gnu.org
@ 2023-04-17 5:37 ` klaus.doldinger64 at googlemail dot com
2023-04-18 8:15 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: klaus.doldinger64 at googlemail dot com @ 2023-04-17 5:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
` (4 preceding siblings ...)
2023-04-17 5:37 ` klaus.doldinger64 at googlemail dot com
@ 2023-04-18 8:15 ` redi at gcc dot gnu.org
2023-05-17 13:03 ` cvs-commit at gcc dot gnu.org
2023-05-17 13:52 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-04-18 8:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
` (5 preceding siblings ...)
2023-04-18 8:15 ` redi at gcc dot gnu.org
@ 2023-05-17 13:03 ` cvs-commit at gcc dot gnu.org
2023-05-17 13:52 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-17 13:03 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
` (6 preceding siblings ...)
2023-05-17 13:03 ` cvs-commit at gcc dot gnu.org
@ 2023-05-17 13:52 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-17 13:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-05-17 13:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-17 5:08 [Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum klaus.doldinger64 at googlemail dot com
2023-04-17 5:16 ` [Bug rtl-optimization/109532] " pinskia at gcc dot gnu.org
2023-04-17 5:16 ` pinskia at gcc dot gnu.org
2023-04-17 5:24 ` [Bug c++/109532] " klaus.doldinger64 at googlemail dot com
2023-04-17 5:30 ` pinskia at gcc dot gnu.org
2023-04-17 5:37 ` klaus.doldinger64 at googlemail dot com
2023-04-18 8:15 ` redi at gcc dot gnu.org
2023-05-17 13:03 ` cvs-commit at gcc dot gnu.org
2023-05-17 13:52 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).