precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140981 91177308-0d34-0410-b5e6-96231b3b80d8
support both a fragile and non-fragile ABI, and it can be selected at
runtime. That driver option also works on Darwin (although obviously
the code is not necessarily usable if the system runtime is fragile)
so just do that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140973 91177308-0d34-0410-b5e6-96231b3b80d8
otherwise these tests would fail on hosts that happen to default
to that, since that affects whether default synthesis can happen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140970 91177308-0d34-0410-b5e6-96231b3b80d8
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140957 91177308-0d34-0410-b5e6-96231b3b80d8
the pointer, being sure to do so before running cleanups
associated with that full-expression. rdar://10042689
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140945 91177308-0d34-0410-b5e6-96231b3b80d8
Make the suffixes optional everywhere, and just make sure they have the
right value. The suffixes aren't the interesting part of this test
anyways.
Sorry for the churn as I let the bots try out various patterns.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140927 91177308-0d34-0410-b5e6-96231b3b80d8
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140926 91177308-0d34-0410-b5e6-96231b3b80d8
left a FIXME to go track down more distros and see if 'lib' is ever the
64-bit half.
This should hopefully appease the build bots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140915 91177308-0d34-0410-b5e6-96231b3b80d8
calls, or calls to audited functions without an explicit
return attribute, to be casted without a bridge cast.
Tie this mechanism in with the existing exceptions to
the cast restrictions. State those restrictions more
correctly and generalize.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140912 91177308-0d34-0410-b5e6-96231b3b80d8
to take a FunctionDecl* instead of an llvm::StringRef. Eventually
we might push more logic in there, like using slightly different
conventions for C++ methods.
Also, fix a bug where 'copy' and 'create' were being caught in
non-camel-cased strings. We want copyFoo and CopyFoo and XCopy
but not Xcopy or xcopy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140911 91177308-0d34-0410-b5e6-96231b3b80d8
This patch may do what it describes, it may not. It's hard to tell as
its completely unclear what this is supposed to do. There are also no
test cases. More importantly, this seems to have broken lots of linker
invocations on multilib Linux systems.
The manual pages for 'ld' on Linux mention translating a '=' at the
beginning of the path into a *configure time* sysroot prefix (this is,
I believe, distinct from the --sysroot flag which 'ld' also can
support). I tested this with a normal binutils 'ld', a binutils 'ld'
with the sysroot flag enabled, and gold with the sysroot flag enabled,
and all of them try to open the path '=/lib/../lib32', No translation
occurs.
I think at the very least inserting an '=' needs to be conditioned on
some indication that it is supported and desired. I'm also curious to
see what toolchain and whan environment cause it to actually make
a difference.
I'm going to add a test case for basic sanity of Linux 'ld' invocations
from Clang in a follow-up commit that would have caught this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140908 91177308-0d34-0410-b5e6-96231b3b80d8
This time the warning found an actual bug, we don't want to handle
force_align_arg_pointer differently than __force_align_arg_pointer__.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140877 91177308-0d34-0410-b5e6-96231b3b80d8
CoreFoundation object-transfer properties audited, and add a #pragma
to cause them to be automatically applied to functions in a particular
span of code. This has to be implemented largely in the preprocessor
because of the requirement that the region be entirely contained in
a single file; that's hard to impose from the parser without registering
for a ton of callbacks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140846 91177308-0d34-0410-b5e6-96231b3b80d8