[LLVMbugs] [Bug 13376] New: Clang fails to inline function with -fcatch-undefined-behavior and libc++
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Jul 16 13:24:57 PDT 2012
http://llvm.org/bugs/show_bug.cgi?id=13376
Bug #: 13376
Summary: Clang fails to inline function with
-fcatch-undefined-behavior and libc++
Product: clang
Version: trunk
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: jonathan.sauer at gmx.de
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 8908
--> http://llvm.org/bugs/attachment.cgi?id=8908
LLVM bitcode of libstdc++ with -fcatch-undefined-behavior
The following program fails to link when compiled with clang r160268, -O3,
-fcatch-undefined-behavior and libc++ r160265:
#include <string>
static std::size_t skipToEOL(const std::string& str, std::size_t pos)
{
// This miscompiles:
while (pos < str.size() && str[pos] != '\n' && str[pos] != '\r')
++pos;
// This works (both at the same time work, too):
//const char* s = str.c_str() + pos;
//while (*s != '\0' && *s != '\r' && *s != '\n')
// ++pos, ++s;
return pos;
}
int main()
{
std::string source;
std::size_t pos = 0;
while (pos < source.size())
{
std::size_t const eol = skipToEOL(source, pos);
if (pos & 1)
source.erase(pos, skipToEOL(source, pos) - pos);
else
pos = eol;
}
}
This results in:
$ ~/LLVM/build/Release+Asserts/bin/clang++ -stdlib=libc++ -O3
-fcatch-undefined-behavior clang.cpp
Undefined symbols:
"__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEixEm",
referenced from:
__ZL9skipToEOLRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEm
in clang-OFDq2h.o
__ZL9skipToEOLRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEm
in clang-OFDq2h.o
ld: symbol(s) not found
(the undefined symbol is "std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >::operator[](unsigned
long) const")
Without -fcatch-undefined-behavior, it links correctly. When using libstdc++
that is distributed with OS X 10.6/XCode 3.2.6, it links correctly as well.
string::operator[] is defined as inline in the source; I suspect that at some
point, clang (LLVM) fails to inline it for some reason, leaving a reference to
the (non-existing) non-inlined function in the object code.
I have attached the LLVM bitcode files for both cases with libc++ plus the
-fcatch-undefined-behavior case with Apple's libstdc++ 4.2.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list