llvm-svn: 190934

llvm-svn: 190933

llvm-svn: 190932

Patch by Bradley Smith!

llvm-svn: 190931

For some reason I never got around to adding these at the same time as
the signed versions.  No idea why.

I'm not sure whether this SystemZII::BranchC* stuff is useful, or whether
it should just be replaced with an "is normal" flag.  I'll leave that
for later though.

There are some boundary conditions that can be tweaked, such as preferring
unsigned comparisons for equality with [128, 256), and "<= 255" over "< 256",
but again I'll leave those for a separate patch.

llvm-svn: 190930

llvm-svn: 190929

Patch by Bradley Smith!

llvm-svn: 190928

llvm-svn: 190927

Fix for PR16752. Second commit.

PR16752: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth methods. Methods asks target for proper type for given bit width.
2. Fix handleModeAttr according to new methods in TargetInfo.

Fixes:
1st Commit (Done): Add new methods for TargetInfo:
     getRealTypeByWidth and getIntTypeByWidth
  for ASTContext names are almost same(invokes new methods from TargetInfo):
     getIntTypeForBitwidth and getRealTypeForBitwidth

2nd Commit (Current): Fix SemaDeclAttr, handleModeAttr function.

Also test/Sema/attr-mode.c was fixed. 'XC' mode test was disabled for PPC64 machines.

llvm-svn: 190926

vtst and vtstq currently support poly8 types, but they should also work on
poly16.

llvm-svn: 190925

llvm-svn: 190924

I'll roll it back in when I have a chance to look at it in detail.

llvm-svn: 190923

For all libm __builtin_* functions that are defined, this adds the
corresponding LIBBUILTIN definitions (tagged, as necessary, with "e" instead of
"c" when the function may set errno).

Note that this changes the current definitions for lrint and fma
(unfortunately). The Linux man page documents that these don't set errno, but
the POSIX standard says that they should.

llvm-svn: 190922

advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will 
"reset" if you shutdown llvm and try to come back for seconds.  This is a subtle 
behavior change, but I'm assuming that nobody is affected by it.

llvm-svn: 190921

Prevent extra calls to ToggleFeature for Feature64Bit and FeatureCMOV if they've already been enabled. The extra call ends up clearing the bit in FeatureBits since its a 'toggle'. Can't prove that anything was broken because of this since I don't think the FeatureBits for these are used.

llvm-svn: 190920

Fix X86 subtarget to not overwrite the autodetected features by calling InitMCProcessorInfo right after detecting them. Instead add a new function that only updates the scheduling model and call that.

llvm-svn: 190919

llvm-svn: 190917

llvm-svn: 190916

LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.

C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.

llvm-svn: 190915

llvm-svn: 190914

argument list, but could be instantiated with argument list of <>.

llvm-svn: 190913

PR17142.

llvm-svn: 190912

llvm-svn: 190911

referenced, try to instantiate its definition in order to complete the type.

llvm-svn: 190910

as suggested by Jordan on IRC. Also, use the unqualified name
in Job.cpp.

And while we're here, refer to StringRef with the unqualified
name, because we have a using directive for that too.

llvm-svn: 190909

This will define _MSC_VER to 1700 by default and avoid linker errors
from /failifmismatch linker directives in the C++ standard headers.

Most people trying out the Visual Studio integration are using 2012,
since that's the only version that clang-format works with.  This way
they don't have to pass funky -Xclang -fmsc-version=1700 flags just to
link against the standard C++ runtime.

llvm-svn: 190908

The first one broke the build, and the latter one made it worse.

llvm-svn: 190907

Seems like it was intentional to export ArgStringList as
driver::ArgStringList, and e.g. examples/clang-interpreter/main.cpp
uses it this way.

However, exporting it with a typedef seems like a more common way to do it.

llvm-svn: 190906

llvm-svn: 190905

This reverts commit r190895 which reverted r190892.

llvm-svn: 190904

llvm-svn: 190903

I don't think it belongs in the header, but seems handy in the .cpp file.

llvm-svn: 190902

presense of parenthesized enumerator initializers.

llvm-svn: 190901

The /GS- flag is used to turn off run-time buffer security checks (/GS).
Since no such checks are enabled in the first place, I think we should just
ignore this flag.

llvm-svn: 190900

If address space 0 was smaller than the address space
in a constant inttoptr/ptrtoint pair, the wrong mask size
would be used.

llvm-svn: 190899

Summary:
We indicate that the object files are safe by emitting a @feat.00
absolute address symbol.  The address is presumably interpreted as a
bitfield of features that the compiler would like to enable.  Bit 0 is
documented in the PE COFF spec to opt in to "registered SEH", which is
what /safeseh enables.

LLVM's object files are safe by default because LLVM doesn't know how to
produce SEH handlers.

Reviewers: Bigcheese

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1691

llvm-svn: 190898

llvm-svn: 190897

For now it happens the argument is always the same.

llvm-svn: 190896

This reverts commit r190892.

llvm-svn: 190895

'deprected' setters either. // rdar://14989365

llvm-svn: 190894