<html>
    <head>
      <base href="https://bugs.freedesktop.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 - Incorrect/undefined behavior from shifting an integer too far"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=87136">87136</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Incorrect/undefined behavior from shifting an integer too far
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>Mesa
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Other
          </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>medium
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Mesa core
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>mesa-dev@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>brucedawson@cygnus-software.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>While compiling Google Chrome with VC++'s /analyze (static code analysis) I
discovered a class of bugs in the mesa code base. There are three instances of
this bug where the integer '1' is shifted by an amount that ranges from zero to
47. '1' will have type 'int' and on basically every modern platform 'int' is 32
bits. Shifting an int more than 30 positions leads to undefined behavior
because the result will, necessarily be unrepresentable.

Even if we ignore the annoying spectre of undefined behavior, the behavior will
most definitely not be what is intended. On Intel processors the likely result
is going to be equivalent to shifting by shiftAmount&31 which means that 16
mask values will be repeated.

The warning is:
warning C6297: Arithmetic overflow:  32-bit value is shifted, then cast to
64-bit value.  Results might not be an expected value.

The fix is to use BITFIELD64_BIT(i) instead of (1 << I).

The locations where I have noticed this bug are:

drivers\dri\i965\brw_fs.cpp(2164):
   for (int i = 0; i < FRAG_ATTRIB_MAX; i++) {
      if (!(fp->Base.InputsRead & BITFIELD64_BIT(i)))
continue;

      if (prog->Name == 0)
         key.proj_attrib_mask |= 1 << i; // BUG

swrast\s_span.c(767):
         for (i = 0; i < FRAG_ATTRIB_MAX; i++) {
            if (span->interpMask & (1 << i)) {
               GLuint j;
               for (j = 0; j < 4; j++) {
                  span->attrStart[i][j] += leftClip * span->attrStepX[i][j];
               }
            }
         }

swrast\s_span.c(788):
         for (i = 0; i < FRAG_ATTRIB_MAX; i++) {
            if (span->arrayAttribs & (1 << i)) {
               /* shift array elements left by 'leftClip' */
               SHIFT_ARRAY(span->array->attribs[i], leftClip, n - leftClip);
            }
         }</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>