https://llvm.org/bugs/show_bug.cgi?id=30776
Bug ID: 30776
Summary: clang-cl error with -Wc++11-narrowing and enums on
code that MSVC accepts
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: froy...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compiling:
typedef enum {
MD_EXCEPTION_CODE_WIN_FLOAT_INEXACT_RESULT = 0xc000008f,
} MDExceptionCodeWin;
extern void g();
extern void h();
void
f(unsigned int code)
{
switch (code) {
case MD_EXCEPTION_CODE_WIN_FLOAT_INEXACT_RESULT:
g();
break;
default:
h();
break;
}
}
gives:
$ clang-cl -c enum-switch.cpp
enum-switch.cpp(2,3): warning: enumerator value is not representable in the
underlying type 'int' [-Wmicrosoft-enum-value]
MD_EXCEPTION_CODE_WIN_FLOAT_INEXACT_RESULT = 0xc000008f,
^
enum-switch.cpp(12,8): error: case value evaluates to -1073741681, which
cannot
be narrowed to type 'unsigned int' [-Wc++11-narrowing]
case MD_EXCEPTION_CODE_WIN_FLOAT_INEXACT_RESULT:
^
1 warning and 1 error generated.
whereas MSVC accepts the code without complaint.
I am reasonably sure this used to work, and not error, but I have not bisected
this, and may have a faulty memory in any event.
I realize that this is similar to bug 25644, and arguably the code should be
fixed (perhaps by explicitly making the enum have an underlying type of
uint32_t), but that is less straightforward in this case. The enum in question
may be in a header file that is shared between C/C++, and people may have,
shall we say, strong opinions about adding C++ goo. It's also not clear to me
whether mixing and matching different enum definitions like that would do the
right thing when calling between C and C++ functions.
Thoughts?
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
