<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Missing conversion for unscoped enumeration type whose underlying type is not fixed"
   href="https://bugs.llvm.org/show_bug.cgi?id=47478">47478</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Missing conversion for unscoped enumeration type whose underlying type is not fixed
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>clang
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>10.0
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>C++
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedclangbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>cuoq@trust-in-soft.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>blitzrakete@gmail.com, dgregor@apple.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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: <a href="https://gcc.godbolt.org/z/7jrMb7">https://gcc.godbolt.org/z/7jrMb7</a>

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?</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>