was invoked from (which may not be where the executable itself is).
- This allows having e.g., /Developer/usr/bin/clang be a symlink to some other
location, while still making sure the Driver finds 'as', 'ld', etc. relative
to itself.
llvm-svn: 109989
a switch or goto somewhere in the function. Indirect gotos trigger the
jump-checker regardless, because the conditions there are slightly more
elaborate and it's too marginal a case to be worth optimizing.
Turns off the jump-checker in a lot of cases in C++. rdar://problem/7702918
llvm-svn: 109962
the magic of inline assembly. Essentially we use read and write hazards
on the set of local variables to force flushing locals to memory
immediately before any protected calls and to inhibit optimizing locals
across the setjmp->catch edge. Fixes rdar://problem/8160285
llvm-svn: 109960
This patch introduces the ClassTemplateDecl::spec_{begin,end}()
and FunctionTemplateDecl::{,partial_}spec_{begin,end}() member
functions as a public interface for iterating over the declarations'
specialisation sets.
llvm-svn: 109870
This patch reimplements the find*Specialization family of member
functions of {Class,Function}TemplateDecl in terms of a common
implementation that uses SpecEntryTraits to obtain the most recent
declaration.
llvm-svn: 109869
to the consumer until the DeclContext is fully prepared.
Before, due to recursive loading, we could be in a situation where we would try to deserialize the decls of a DeclContext which was already doing that, and bad things would happen. In the specific case I encountered, the lexical decls would
form a cycle and we would enter infinite loop territory.
llvm-svn: 109857
-Replace CurrentlyLoadingTypeOrDecl with a counting scheme (NumCurrentElementsDeserializing)
-Provide outside access to the mechanism by adding methods StartedDeserializing/FinishedDeserializing
to ExternalASTSource.
These are preparation for the next commit.
llvm-svn: 109856
The X86-64 ABI code didn't handle the case when a struct
would get classified and turn up as "NoClass INTEGER" for
example. This is perfectly possible when the first slot
is all padding (e.g. due to empty base classes). In this
situation, the first 8-byte doesn't take a register at all,
only the second 8-byte does.
This fixes this by enhancing the x86-64 abi stuff to allow
and handle this case, reverts the broken fix for PR5831,
and enhances the target independent stuff to be able to
handle an argument value in registers being accessed at an
offset from the memory value.
This is the last x86-64 calling convention related miscompile
that I'm aware of.
llvm-svn: 109848
sections on", this change uncovered a possible linker bug which resulted in the
wrong messages getting dispatched. Backing this out while we investigate...
llvm-svn: 109817
<2 x float> instead of double. This works but can't be turned
on until I teach codegen to pass <2 x float> as one XMM register
instead of two.
llvm-svn: 109790