[llvm-bugs] [Bug 30776] New: clang-cl error with -Wc++11-narrowing and enums on code that MSVC accepts

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: froydnj at gmail.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161024/0e929597/attachment.html>