https://bugs.llvm.org/show_bug.cgi?id=39041
Bug ID: 39041
Summary: incorrect optimization when replacing strchr on amd64
Product: libraries
Version: 6.0
Hardware: PC
OS: OpenBSD
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Created attachment 20906
--> https://bugs.llvm.org/attachment.cgi?id=20906&action=edit
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.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
