https://bugs.llvm.org/show_bug.cgi?id=47478
Bug ID: 47478
Summary: Missing conversion for unscoped enumeration type whose
underlying type is not fixed
Product: clang
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: c...@trust-in-soft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The bug report refers to the phrase “an unscoped enumeration type whose
underlying type is not fixed can be converted to the first type from the
following list able to hold their entire value range: int, …” in conv.prom in
C++ standards after 2011.
In the code that follows, GCC chooses as the underlying integer type for the
representation of “enum e” the type unsigned int, and so does Clang. Consider
the function f:
enum e { e1, e2 } e;
long long x, y, z;
char *p;
void f(void) {
e = (enum e) 4294967295;
x = (long long) e;
y = e > e1;
z = &p[e] - p;
}
Compiler Explorer link: https://gcc.godbolt.org/z/7jrMb7
With this choice or representation for “enum e”, the consensus interpretation
for the phrase from conv.prom is that f should set x to 4294967295 and y to 0,
strange as this may seem.
GCC sets z to -1, and this seems correct according to the same phrase. However,
Clang sets z to 4294967295. Is this voluntary, or was the implication of the
phrase from conv.prom overlooked in this case?
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
