Currently "<type> ptr <reg name>" treated as <reg name> in MS inline asm, ignoring the "<type> ptr" completely and possibly ignoring the intention of the user.
Fixed llvm to produce an error when encountering "<type> ptr <reg name>" operands.

For example: andpd xmm1,xmmword ptr xmm1 --> andpd xmm1, xmm1 
though andpd has 2 possible matching formats - andpd xmm, xmm/m128

Patch by: ziv.izhar@intel.com
Differential Revision: http://reviews.llvm.org/D14607

llvm-svn: 254607

llvm-svn: 254606

Revert "Fix for merging decls in pragma weak Calling CheckFunctionDeclaration so that 2 decls for the 'weak' are merged. Differential Revision: http://reviews.llvm.org/D13048"

This reverts commit r254143 which introduces a crash on the following input:
  f(char *);
  g(char *);
  #pragma weak f = g
  int g(char *p) {}

llvm-svn: 254605

llvm-svn: 254604

Second attempt to enable building ThreadSanitizer (and running tests) on OS X by default.

Differential Revision: http://reviews.llvm.org/D15109

llvm-svn: 254603

Previously we used sys.os.path for appending target pathes what failed
when cased dlopen to fail on the target because of the '\'.

The fix won't work for local Windows tests but dlopen don't available
on Windows anyway so the test don't make sense in that context.

llvm-svn: 254602

In mmap_large.cc, let's use MAP_ANON instead of MAP_ANONYMOUS, because MAP_ANONYMOUS is only available on OS X 10.11 and later.

Differential Revision: http://reviews.llvm.org/D15180

llvm-svn: 254601

In AddressSanitizer, we have the MaybeReexec method to detect when we're running without DYLD_INSERT_LIBRARIES (in which case interceptors don't work) and re-execute with the environment variable set. On OS X 10.11+, this is no longer necessary, but to have ThreadSanitizer supported on older versions of OS X, let's use the same method as well. This patch moves the implementation from `asan/` into `sanitizer_common/`.

Differential Revision: http://reviews.llvm.org/D15123

llvm-svn: 254600

Run without flags if we cannot load a compilation database. This matches
the behavior of clang itself when simply called with a source file.

Based on a patch by Russell Wallace.

llvm-svn: 254599

Differential Revision: http://reviews.llvm.org/D15141

llvm-svn: 254598

OpenMP 4.5 adds directive 'taskloop simd'. Patch adds parsing/sema analysis for 'taskloop simd' directive and its clauses.

llvm-svn: 254597

This CL is for discussion how to better fix bit-filed layout compatibility issue with GCC (see PR25575 for test case and more details). Current clang behavior is compatible with GCC 4.1-4.3 series but it was fixed in 4.4+. Ignoring packed attribute looks very odd and because it was also fixed in GCC 4.4+, it makes sense also fix it in clang.
Differential Revision: http://reviews.llvm.org/D14872

llvm-svn: 254596

According to x86 spec, fcomip and fucomip should be supported for Intel syntax.

Differential Revision: http://reviews.llvm.org/D15104

llvm-svn: 254595

As discussed on the ml, backend tests need to be put in llvm/test/CodeGen/X86 as fast-isel tests using IR that is as close to what is generated here as possible.

The llvm tests will (re)added in a future commit

I will update PR24580 on this new plan

llvm-svn: 254594

llvm-svn: 254593

It is not enough to simply make the destructor virtual since there is a g++ 4.7
issue (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613) that throws the
error "looser throw specifier for ... overridding ~SCEVPredicate() noexcept".

llvm-svn: 254592

Generate R_AARCH64_COPY relocations for non-GOT relocations,
which reference object symbols from shared libraries.

Differential revision: http://reviews.llvm.org/D15043

llvm-svn: 254591

    SUMMARY:
    Using enum instead of a constant to fetch PC and CAUSE registers.

llvm-svn: 254590

[TableGen] Remove an assumption about the order of encodings in the MVT::SimpleValueType enum. Instead of assuming the types are sorted by size, scan the typeset arrays to find the smallest/largest type. NFC

llvm-svn: 254589

Reviewers: clayborg, jingham, jasonmolenda.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.llvm.org/D12877

llvm-svn: 254588

Summary: This is done only when targeting HSA.

Reviewers: arsenm

Subscribers: arsenm, llvm-commits

Differential Revision: http://reviews.llvm.org/D13807

llvm-svn: 254587

This works mostly fine but breaks some stage 1 builders when compiling
compiler-rt on i386. Revert for further investigation as I can't see an
obvious cause/fix.

This reverts commit r254577.

llvm-svn: 254586

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254585

Thanks Sean Silva for catching this.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254584

This precludes some more functional changes to perform bulk imports.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254583

Thanks Sean Silva for the suggestion.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254582

There is no real reason the index has to have the concept of an
exporting Module. We should be able to have one single unique
instance of the Index, and it should be read-only after creation
for the whole ThinLTO processing.
The linker plugin should be able to process multiple modules (in
parallel or in sequence) with the same index.

The only reason the ExportingModule was present seems to be to
implement hasExportedFunctions() that is used by the Module linker
to decide what to do with the current Module.
For now I replaced it with a query to the map of Modules path to
see if this module was declared in the Index and consider that if
it is the case then it is probably exporting function.
On the long term the Linker interface needs to evolve and this
call should not be needed anymore.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254581

not enough for SPARCv7.

llvm-svn: 254580

llvm-svn: 254579

If a section symbol is not external, that COMDAT section should never
be merge with other sections in other compilation unit. Previously,
we didn't take visibility into account.

Note that COMDAT sections with non-external visibility makes sense
because they can be removed by dead-stripping.

Fixes https://llvm.org/bugs/show_bug.cgi?id=25686

llvm-svn: 254578

The new algorithm remembers the uses encountered while walking backwards
until a matching def is found. Contrary to the previous version this:
- Works without LiveIntervals being available
- Allows to increase the precision to subregisters/lanemasks
  (not used for now)

The changes in the AMDGPU tests are necessary because the R600 scheduler
is not stable with respect to the order of nodes in the ready queues.

Differential Revision: http://reviews.llvm.org/D9068

llvm-svn: 254577

llvm-svn: 254576

llvm-svn: 254575

side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.

This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.

This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:

  float f = 1e100;

are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.

llvm-svn: 254574

We don't want to generate fmuladd if there's a use of the fmul expression, but this shouldn't be an assert.

The test case is derived from the commit message for r253337:
http://reviews.llvm.org/rL253337

That commit reverted r253269:
http://reviews.llvm.org/rL253269

...but the bug exists independently of the default fp-contract setting. It just became easier to hit with that change.

PR25719:
https://llvm.org/bugs/show_bug.cgi?id=25719

Differential Revision: http://reviews.llvm.org/D15165

llvm-svn: 254573

llvm-svn: 254572

The CreatedADWARFSection flag was added in r232842, but isn't cleared
properly when resetting the streamer's state. Fix that.

llvm-svn: 254571

Differential Revision: http://reviews.llvm.org/D15167

llvm-svn: 254570

llvm-svn: 254567

llvm-svn: 254566