Clang would treat the digits in an "11m" input constraint separately as
if it was handling constraint 1 twice instead of constraint 11.

llvm-svn: 225606

Input constraints like "0" and "[foo]" should be treated the same when
it comes to their corresponding output constraint.

This fixes PR21850.

llvm-svn: 225605

llvm-svn: 225603

llvm-svn: 225600

Don't permit '+&m' to make it to CodeGen, it's invalid.

llvm-svn: 225586

Add additional constraint checking for target specific behaviour for inline
assembly constraints.  We would previously silently let all arguments through
for these constraints.  In cases where the constraints were violated, we could
end up failing to select instructions and triggering assertions or worse,
silently ignoring instructions.

llvm-svn: 225244

Name might be empty again after we removed the '%' prefix
and Name[0] would assert.

Found on code like
register int foo asm("%" MACRO);
where MACRO was supposed to be defined in a header file that was not found.

llvm-svn: 215834

char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.

The value of __INTx_TYPE__ now matches GCC.

llvm-svn: 214119

constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.

llvm-svn: 213301

underlaying types.

llvm-svn: 213063

llvm-svn: 212987

This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.

llvm-svn: 212386

Add predefined stdint macros that match the given patterns:

U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}

http://reviews.llvm.org/D4141

Author: binji
llvm-svn: 211657

llvm-svn: 208280

This follows the LLVM change to canonicalise the Windows target triple
spellings.  Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment.  This is a
mechanical change to convert the triple use to reflect that change.

llvm-svn: 204978

This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.

To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.

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

llvm-svn: 199250

llvm-svn: 197592

An empty string for an ASM input constraint is invalid, and will crash
during clang CodeGen.  Change TargetInfo::validateInputConstraint to
reject an empty string.

<rdar://problem/15552191>

llvm-svn: 197362

llvm-svn: 197268

address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.

Patch by Michele Scandale!

llvm-svn: 190684

llvm-svn: 190390

languages, as well as specifying errno is not set by the math functions. Make the
clang front-end set those appropriately when the OpenCL language option is set.

Patch by Erik Schnetter!

llvm-svn: 190296

-- For TargetInfo::getRealTypeByWidth also added support for IEEEQuad float type.

llvm-svn: 190294

     getRealTypeByWidth and getIntTypeByWidth
  for ASTContext names are almost same(invokes new methods from TargetInfo):
     getIntTypeForBitwidth and getRealTypeForBitwidth.

As first commit for PR16752 fix: '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 virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.

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

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

llvm-svn: 190044

No functionality change.

llvm-svn: 185261

Allow targets to define minimum alignment for global variables

This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols.  The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction.  This instruction
provides PC-relative addressing, but only to *even* addresses.  For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2.  [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ]  GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).

To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting.  Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.

This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall.  Thanks to all reviewers!

Patch by Richard Sandiford.

llvm-svn: 181210

llvm-svn: 179806

Fixes PR15759.

llvm-svn: 179756

Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

llvm-svn: 174768

llvm-svn: 173514

uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

llvm-svn: 168674

llvm-svn: 166924

created.

llvm-svn: 165943

AVX).  Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size.  Thus, very large vectors will be over-aligned with no 
benefit.  Target owners should set this target max.

llvm-svn: 160209

type for rewriter project will be BoolTy.
// rdar://11231426. 

llvm-svn: 154861

llvm-svn: 147137

This is equal to alignof(std::max_align_t) on the platform and equal to the
alignment provided by malloc. (Platform owners please double-check your
platform's value.)

llvm-svn: 146762

In x86_64, when calling an Objective-C method that returns a _Complex long double, make sure to use the objc_msgSend_fp2ret function which ensures that the return value will be {0, 0} if the receiver is nil.

llvm-svn: 143350

Lack of half FP was a regression compared to llvm-gcc.

llvm-svn: 142016