We already have builtins that are only available in GNU mode, so this
mirrors that.

Reviewers: rsmith

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

llvm-svn: 194615

Like GCC, this re-uses the 'f' constraint and a new 'w' print-modifier:
  asm ("ldi.w %w0, 1", "=f"(result));

Unlike GCC, the 'w' print-modifer is not _required_ to produce the intended
output. This is a consequence of differences in the internal handling of
the registers in each compiler. To be source-compatible between the
compilers, users must use the 'w' print-modifier.

MSA registers (including control registers) are supported in clobber lists.

llvm-svn: 194476

Change SizeType, PtrDiffType, IntPtrType, WCharType, WIntType
to follow the XMOS llvm-gcc front end's settings.

llvm-svn: 194461

llvm-svn: 194446

substitution failure, allow a flag to be set on the Diagnostic object,
to mark it as 'causes substitution failure'.

Refactor Diagnostic.td and the tablegen to use an enum for SFINAE behavior
rather than a bunch of flags.

llvm-svn: 194444

the floating point register mode.

llvm-svn: 194426

llvm-svn: 194408

__FLT_EVAL_METHOD__ accordingly. Add test case for this and the SSE2
variances on NetBSD.

llvm-svn: 194377

This change fixes Richard's testcase for r193815.  Now we include non-explicit
submodules into the list of exports.

The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
  correct module set -- it only considers modules that are imported.

The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.

llvm-svn: 194018

llvm-svn: 193985

llvm-svn: 193850

This change makes Module::buildVisibleModulesCache() collect exported modules
recursively.

While computing a set of exports, getExportedModules() iterates over the set of
imported modules and filters it.  But it does not consider the set of exports
of those modules -- it is the responsibility of the caller to do this.

Here is a certain instance of this issue.  Module::isModuleVisible says that
CoreFoundation.CFArray submodule is not visible from Cocoa.  Why?

- Cocoa imports Foundation.
- Foundation has an export restriction: "export *".
- Foundation imports CoreFoundation.  (Just the top-level module.)
- CoreFoundation exports CoreFoundation.CFArray.

To decide which modules are visible from Cocoa, we collect all exported modules
from immediate imports in Cocoa:

> visibleModulesFro(Cocoa) = exported(Foundation) + exported(CoreData) + exported(AppKit)

To find out which modules are exported, we filter imports according to
restrictions:

> exported(Foundation) = filterByModuleMapRestrictions(imports(Foundation))

Because Foundation imports CoreFoundation (not CoreFoundation.CFArray), the
CFArray submodule is considered not exported from Foundation, and is not
visible from Cocoa (according to Module::isModuleVisible).

llvm-svn: 193815

Enables the clang driver to begin targeting specific CPUs. Introduced a
"generic" CPU which will ensure that the optional FP feature is enabled
by default when it gets to LLVM, without needing any extra arguments.
Cortex-A53 and A-57 are also introduced with tests, although backend
handling of them does not yet exist.

llvm-svn: 193740

llvm-svn: 193674

llvm-svn: 193640

at the end of handleTargetFeatures.

No intended functionality change.

llvm-svn: 193636

llvm-svn: 193622

Allow users to disable or enable CRC subtarget feature.

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

llvm-svn: 193600

  requires ! feature

The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).

llvm-svn: 193549

Although we wire up a bit for v8fp for macro setting
purposes, we don't set a macro yet. Need to ask list
about that.

Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0
llvm-svn: 193367

Change-Id: Ie07228411b68252adcd5cf80b27ccd2eb3b031d9
llvm-svn: 193366

Adds some Cortex-A53 strings where they were missing before.
Cortex-A57 is entirely new to clang.

Doesn't touch code only used by Darwin, in consequence of which
one of the A53 lines has been removed.

Change-Id: I5edb58f6eae93947334787e26a8772c736de6483
llvm-svn: 193364

These arch arguments are used for embedded targets (obviously) which need a
different calling convention to iOS.

llvm-svn: 193328

llvm-svn: 193075

Add the __ARM_ARCH_EXT_IDIV__ predefine. It is set to 1 if we have hardware divide in the mode that we are compiling in (depending on the target features), not defined if we don't. Should be compatible with the GCC conterpart. Also adding a -hwdiv option to overide the default behavior.

llvm-svn: 193074

llvm-svn: 192969

everything else in the class.

llvm-svn: 192851

The test should be expanded upon for more powerpc checking.

llvm-svn: 192849

llvm-svn: 192847

clang front end. This change will allow the __PRFCHW__ macro to be set on these
processors and hence include prfchwintrin.h in x86intrin.h header. Support for
the intrinsic itself seems to have already been added in r178041.

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

llvm-svn: 192829

methods, infer their self's type as their result type.
// rdar://15145218

llvm-svn: 192377

'default' methods in Foundation does not
infer 'instancetype' for methods' result type.
// rdar://15145218

llvm-svn: 192129

it is enabled. Also enable it on the same architectures that GCC does.

llvm-svn: 192045

The added a cmake invocation to null builds, making them a lot slower.

llvm-svn: 191784

llvm-svn: 191730

llvm-svn: 191707

Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ unconditionally.

While there, define __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD. FreeBSD's
wchar_t's don't encode characters as ISO-10646; the encoding depends on
the locale used. Because the character set used might not be a superset
of ASCII, we must define __STDC_MB_MIGHT_NEQ_WC__.

llvm-svn: 191631

- We really shouldn't compute line numbers for every file that is asked if it's
  the main file, it destroys the lazy computation.
- Invalid locations are no longer accounted to the main file, no other
  functionality change.

llvm-svn: 191535

x86 TBM instruction set. Also adding a __TBM__ macro if the TBM feature is
enabled. Otherwise there should be no functionality change to existing features.

Phabricator code review is located here: http://llvm-reviews.chandlerc.com/D1693

llvm-svn: 191326

Review: http://llvm-reviews.chandlerc.com/D1546.

I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.

From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:

  use module-id

A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.

When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option

-fmodule-name=<module-id>.

The compiler at present only applies restrictions to the module directly
being built.

llvm-svn: 191283