of the target triple to stand in for the "host" triple.
Thanks to a great conversation with Richard Smith, I'm now much more
confident in how this is proceeding. In all of the places where we
currently reason about the "host" architecture or triple, what we really
want to reason about in the detected GCC installation architecture or
triple, and the ways in which that differs from the target. When we find
a GCC installation with a different triple from our target *but capable
of targeting our target* through an option such as '-m64', we want to
detect *that* case and change the paths within the GCC installation (and
libstdc++ installation) to reflect this difference.
This patch makes one function do this correctly. Subsequent commits will
hoist the logic used here into the GCCInstallation utility, and then
reuse it through the rest of the toolchains to fix the remaining places
where this is currently happening.
llvm-svn: 148852
inside of GCCInstallation to be a proper llvm::Triple. This is still
a touch ugly because we have to use it as a string in so many places,
but I think on the whole the more structured representation is better.
Comments of course welcome if this tradeoff isn't working for folks.
llvm-svn: 148843
address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.
When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).
With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.
llvm-svn: 148842
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
llvm-svn: 148839
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.
llvm-svn: 148838
when it actually has changed (and not, e.g., when we've simply attached a
deserialized macro definition). Good for ~1.5% reduction in module
file size, mostly in the identifier table.
llvm-svn: 148808
inside the innards of the Driver implementation, and only ever
implemented to return 'true' for the Darwin OSes. Instead use a more
direct query on the target triple and a comment to document why the
target matters here.
If anyone is worried about this predicate getting wider use or improper
use, I can make it a local or private predicate in the driver.
llvm-svn: 148797
The Driver has a fixed target, whether we like it or not, the
DefaultTargetTriple is not a default. This at least makes things more
honest. I'll eventually get rid of most (if not all) of
DefaultTargetTriple with this proper triple object. Bit of a WIP.
llvm-svn: 148796
This is the last piece of N3031 (decltype in weird places) - supporting
the use of decltype in a class ctor's member-initializer-list to
specify the base classes to initialize.
Reviewed by Richard Smith.
llvm-svn: 148789
Rewording the diagnostic to be more precise/correct: "default label in switch
which covers all enumeration values" and changed the switch to
-Wcovered-switch-default
llvm-svn: 148783
Changing wording to include the word "explicitly" (as in "enumeration value ...
not /explicitly/ handled by switch"), as suggested by Richard Smith.
Also, now that the diagnostic text differs between -Wswitch and -Wswitch-enum,
I've simplified the test cases a bit.
llvm-svn: 148781
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
Previously, for unqualified lookups, a positive cache hit is used as the
only non-keyword correction and a negative cache hit immediately returns
an empty TypoCorrection. With the new callback objects, this behavior
causes false negatives by not accounting for the fact that callback
objects alter the set of potential/allowed corrections. The new behavior
is to seed the set of corrections with the cached correction (for
positive hits) to estabilishing a baseline edit distance. Negative cache
hits are only stored or used when either no callback object is provided
or when it returns true for a call to ValidateCandidate with an empty
TypoCorrection (i.e. when ValidateCandidate does not seem to be doing
any checking of the TypoCorrection, such as when an instance of the base
callback class is used solely to specify the set of keywords to be accepted).
llvm-svn: 148720
Eli Friedman