<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 - incorrect optimization when replacing strchr on amd64"
   href="https://bugs.llvm.org/show_bug.cgi?id=39041">39041</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>incorrect optimization when replacing strchr on amd64
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>6.0
          </td>
        </tr>

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

        <tr>
          <th>OS</th>
          <td>OpenBSD
          </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>Transformation Utilities
          </td>
        </tr>

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

        <tr>
          <th>Reporter</th>
          <td>todd.miller@sudo.ws
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Created <span class=""><a href="attachment.cgi?id=20906" name="attach_20906" title="Test program to reproduce the issue">attachment 20906</a> <a href="attachment.cgi?id=20906&action=edit" title="Test program to reproduce the issue">[details]</a></span>
Test program to reproduce the issue

We noticed unexpected behavior in code from the old BSD C shell with strchr(3).
 Internally, the shell uses arrays of shorts instead of chars for its strings
so it can use one of the upper bits to indicate the character is quoted. The C
standard says that strchr() will convert its second argument to char so this
shouldn't be a problem.

However, when the result of strchr() is used in a boolean context what we see
is that !strchr(";&\n", c) evaluates to 1 even though strchr(";&\n", c) returns
a valid pointer when c is 0x8000.  A quick look at the assembler reveals that
strchr() has been replaced by memchr() which seems reasonable since the size of
the string is known.

This can be reproduced with the attached test program on OpenBSD 6.4-beta with:

clang version 6.0.1 (tags/RELEASE_601/final)
Target: amd64-unknown-openbsd6.4
Thread model: posix
InstalledDir: /usr/local/bin

as well as macOS 10.13.6 with:

Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Here's the output of the test program:

expect 0x10d057f97 0 1
   got 0x10d057f97 1 0

On OpenBSD with clang 6.0.1 (but not on macOS with Apple LLVM version 10.0.0),
if the haystack is declared as:

    const char haystack[] = ";&\n";

the strchr() calls is not replaced with memchr() and the result is as expected.</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>