<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:richard-llvm@metafoo.co.uk" title="Richard Smith <richard-llvm@metafoo.co.uk>"> <span class="fn">Richard Smith</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - semantics for array subscripting with an enum value outside the range of representable values under -fno-strict-enums differ from GCC"
href="https://bugs.llvm.org/show_bug.cgi?id=47478">bug 47478</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>RESOLVED
</td>
<td>REOPENED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>INVALID
</td>
<td>---
</td>
</tr>
<tr>
<td style="text-align:right;">Summary</td>
<td>Missing conversion for unscoped enumeration type whose underlying type is not fixed
</td>
<td>semantics for array subscripting with an enum value outside the range of representable values under -fno-strict-enums differ from GCC
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - semantics for array subscripting with an enum value outside the range of representable values under -fno-strict-enums differ from GCC"
href="https://bugs.llvm.org/show_bug.cgi?id=47478#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - semantics for array subscripting with an enum value outside the range of representable values under -fno-strict-enums differ from GCC"
href="https://bugs.llvm.org/show_bug.cgi?id=47478">bug 47478</a>
from <span class="vcard"><a class="email" href="mailto:richard-llvm@metafoo.co.uk" title="Richard Smith <richard-llvm@metafoo.co.uk>"> <span class="fn">Richard Smith</span></a>
</span></b>
<pre>Reopening and retitling to reflect that this bug report concerns only the
behavior of -fno-strict-enums.
Yes, it looks like Clang gives this flag somewhat different semantics from GCC.
Using __underlying_type(enum e), we can see that both Clang and GCC give the
enum an underlying type of 'unsigned int', not 'signed int'. So the value of
'x' is certainly 4294967295 and not -1. So far so good; both compilers agree.
In y, the usual arithmetic conversions are applied, and we promote the enum to
'signed int' and then to 'long long'. So this is '-1LL > 0LL', which evaluates
to 'false'. Again, both compilers agree.
In z, p[e] is equivalent to *(p + e), and p + e is specified as "the sum of the
operands". No conversions are applied, not even integral promotions, so e is
(presumably) treated as its underlying type. So the result is 4294967295 and
not -1.
So I think this is prima facie a GCC bug; I would imagine it's incorrectly
performing integral promotions on an unscoped enumeration subscript in an array
subscripting expression. But I think this is likely to also be unobservable
outside of -fno-strict-enums mode, which puts an appeal to the standard on
shaky ground.</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>