Repository navigation
C generation loses the signed underlying type of a scoped enum #296
71iq
started this conversation in
Issue Triage - Compilation
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Version
Compiler: 7.0, commit
43e10b90fc83ed2a436fb79b241be8dbf3dc6846Platform: Linux x86_64 (LP64)
Reference/compiler for generated C: GCC 13.3.0
Preset:
linux-gcc-debug, withEDG_CPFE_USE_ASAN=OFFRelevant configuration:
Code to reproduce
Compiler options:
Behavior
A scoped enum without an explicit enum-base has the fixed underlying type
int. ConvertingClassE(-1)tolongshould therefore yield-1.The reference program compiled with GCC exits with status 0. The translated program aborts on
widened == -1;widenedis instead4294967295.The backend emits a C enum:
GCC gives this generated C enum an unsigned representation. The frontend itself correctly identifies the original C++ underlying type: this check passes with the same GNU options:
The problem appears to be preserving signedness during C generation.
References: C++20 [dcl.enum]/5 and /8: https://timsong-cpp.github.io/cppwp/n4861/dcl.enum#5.
The attachment contains the full
--dump_configurationoutput and self-contained reproduction inputs.Source, generated C, results, and full configuration
Reporting acknowledgements
I acknowledge that:
LICENSE.txtfile in my.zipor.tar.gzupload. If I included aLICENSE.txtfile, any tests created using the reproducing source code will be governed by the terms of the license I provided instead.All reactions