Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
Before C11 there was only the DECIMAL_DIG definition. As of C11, we now
have one definition per floating point type (e.g. DBL_DECIMAL_DIG).
Change the existing code to define the new versions. To remain backward
compatible, define __DECIMAL_DIG__ as __LDBL_DECIMAL_DIG__.
Also update the tests. It seems that some of the existing test vectors
were incorrect. Change all tests for __DECIMAL_DIG__ to expect
__LDBL_DECIMAL_DIG__. Add tests for *_DECIMAL_DIG for FreeBSD/amd64, as
I happen to have such a system laying around. I've validated that the
values are in sync with <float.h>.
llvm-svn: 230207
The patch teaches the clang's driver to understand new MIPS ISA names,
pass appropriate options to the assembler, defines corresponding macros etc
http://reviews.llvm.org/D7737
llvm-svn: 230092
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
Partially revert r223927 because LLVM gained support for 128-bit integers
in r227089. Modify and keep the tests that verify the definition of the
macro __SIZEOF_INT128__ for MIPS64 BE & LE in the preprocessor.
llvm-svn: 228918
For compatibility with GCC (and because it's generally helpful information
otherwise inaccessible to the preprocessor). This appears to be canonically the
alignment of max_align_t (e.g. on i386, __BIGGEST_ALIGNMENT__ is 4 even though
vector types will be given greater alignment).
Patch mostly by Mats Petersson
llvm-svn: 228367
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.
Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.
This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.
I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.
Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.
llvm-svn: 224924
We'd let annotation tokens from '#pragma pack' and the like get inside a
function-like macro. This would lead to terror and mayhem; stop the
madness early.
This fixes PR22037.
llvm-svn: 224896
Repared support for warnings -Wkeyword-macro and -Wreserved-id-macro.
The warning -Wkeyword-macro now is not issued in patterns that are used
in configuration scripts:
#define inline
also for 'const', 'extern' and 'static'. If macro repalcement is identical
to macro name, the warning also is not issued:
#define volatile volatile
And finally if macro replacement is also a keyword identical to the replaced
one but decorated with leading/trailing underscores:
#define inline __inline
#define inline __inline__
#define inline _inline // in MSVC compatibility mode
Warning -Wreserved-id-macro is off by default, it could help catching
things like:
#undef __cplusplus
llvm-svn: 224512
As discussed on the post-commit review thread for r224012, -Wkeyword-macro fires
mostly on headers trying to set up portable defines and doesn't find much bad
stuff in practice. But [macro.names]p2 does disallow defining or undefining
keywords, override and final, and alignas, so keep the warning but move it
into -pedantic.
-Wreserved-id-macro warns on
#define __need_size_t
which is more or less public api for glibc headers. Since this warning isn't
motivated by a standard, remove it.
(See also r223114 for a previous follow-up to r224012.)
llvm-svn: 224371
We would CreateString on arbitrary garbage instead of just skipping to
the end of the builtin macro. Eventually, this would cause us to crash
because we would end up replacing the contents of a character token with
a numeric literal.
This fixes PR21825.
llvm-svn: 224238
#undef a keyword is generally harmless but used often in configuration scripts.
Also added tests that I forgot to include to commit in r223114.
llvm-svn: 224100
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
llvm-svn: 223927
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
Summary:
This resolves [[ http://llvm.org/bugs/show_bug.cgi?id=17391 | PR17391 ]].
GCC's sources were used as a guide (couldn't find much information in ARM documentation).
Reviewers: doug.gregor, asl
Reviewed By: asl
Subscribers: asl, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D6339
llvm-svn: 222741
Darwin's "-arch arm64" option implies full Cyclone CPU, for both architectural
and tuning purposes. So if neither of the explicit options have been given,
forward that on to the proper invocation.
rdar://problem/18906227
llvm-svn: 221631
This patch simplifies how default target features are set for AMD bdver2
and bdver1. In particular, method 'getDefaultFeatures' now implements a
fallthrough from case 'CK_BDVER2' to case 'CK_BDVER1'.
That is because 'bdver2' has the same features available in bdver1 plus
BMI, FMA, F16C and TBM.
This patch also adds missing checks for predefined macros in test
predefined-arch-macros.c. In the case of BTVER2, the test now also checks
for F16C, BMI and PCLMUL. In the case of BDVER3 and BDVER4, the test now
also checks for the presence of FSGSBASE.
Differential Revision: http://reviews.llvm.org/D6134
llvm-svn: 221449
We would crash because we used operator[] to access past the end of a
SmallString. This occured because our token had length zero.
Instead, form the pointer using .data() and arithmetic. This is safe
because this forms a one-past-the-end pointer and it is only used to
compare with another one-past-the-end pointer.
This fixes PR21379.
llvm-svn: 220614
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
The current VSX feature for PowerPC specifies availability of the VSX
instructions added with the 2.06 architecture version. With 2.07, the
architecture adds new instructions to both the Category:Vector and
Category:VSX instruction sets. Additionally, unaligned vector storage
operations have improved performance.
This patch adds a feature to provide access to the new instructions
and performance capabilities of Power8. For compatibility with GCC,
the feature is controlled via a new -mpower8-vector switch, and the
feature causes the __POWER8_VECTOR__ builtin define to be generated by
the preprocessor.
There is a companion patch for llvm being committed at the same time.
llvm-svn: 219502
This adds -nostdsysteminc to the %clang_cc1 expansion, which should
make it harder to accidentally write tests that depend on headers in
/usr/include. It also updates a few tests that use -isysroot <x> and a
darwin triple to omit the triple and use -isystem <x>/usr/include
instead, making them a little bit more general.
Incidentally, this fixes a test failure I'm seeing on darwin in
Modules/stddef.c, that happens because my system finds a stddef.h in
/usr/include.
llvm-svn: 219030
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
The ARM ACLE describes the values as hex constants rather than numeric
constants; follow suit. Address post-commit review comments from Jon Roelofs.
llvm-svn: 218009
Extend ARM ACLE support (Section 6.5.1) for AArch32. Define __ARM_FP if
hardware floating point support is available as per the value defined by the
ACLE.
llvm-svn: 217957
The current default abi when no environment is given is "apcs-gnu",
which is obsolete. This patch changes the default to "aapcs". "aapcs" has both
hard- and soft-float variants, so the -mhard-float, -msoft-float and
-mfloat-abi= options now all behave as expected when no environment is
specified in the triple.
While writing this I also noticed that a preprocessor test claims to be
checking darwin, but is actually checking the defaults, which are
different for darwin.
llvm-svn: 216662
a) add SKX support to Clang driver;
b) add tests for SKX target and AVX512BW, AVX512DQ, AVX512VL features into clang driver tests
Patch by Zinovy Nis <zinovy.y.nis@intel.com>
llvm-svn: 214306
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
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
arm64_be doesn't really exist; it was useful for testing while AArch64 and
ARM64 were separate, but now the only real way to refer to the system is
aarch64_be.
llvm-svn: 213747
1. Revert "Add default feature for CPUs on AArch64 target in Clang"
at r210625. Then, all enabled feature will by passed explicitly by
-target-feature in -cc1 option.
2. Get "-mfpu" deprecated.
3. Implement support of "-march". Usage is:
-march=armv8-a+[no]feature
For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is
necessary, and CPU names are not acceptable. Candidate features are
fp, neon, crc and crypto. Where conflicting feature modifiers are
specified, the right-most feature is used.
4. Implement support of "-mtune". Usage is:
-march=CPU_NAME
For instance, "-march=cortex-a57". This option will ONLY get
micro-architectural feature enabled specifying to target CPU,
like "+zcm" and "+zcz" for cyclone. Any architectural features
WON'T be modified.
5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
an alias to "-march={feature of CPU_NAME}+[no]feature" and
"-mtune=CPU_NAME" together. Where this option is used in conjunction
with -march or -mtune, those options take precedence over the
appropriate part of this option.
llvm-svn: 213353
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
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
corresponding AST context function, only restricted to basic integer
types. Use this to ensure getUIntPtrType() gives types consistent with
getIntPtrType(). Fix NVPTX backend to give signed intptr_t.
llvm-svn: 212982
Summary:
This removes the need to pass -mnan=2008 explicitly to be able to compile
the test-suite for MIPS32r6/MIPS64r6.
Differential Revision: http://reviews.llvm.org/D4433
llvm-svn: 212619
Get the predefined macro for the architecture correct.
cortex-m4: __ARM_ARCH_7EM__
cortex-m3: __ARM_ARCH_7M__
cortex-m0: __ARM_ARCH_6M__
rdar://17420090
llvm-svn: 211792
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
This improves conformance with ACLE 6.4.1. Define additional macros that
indicate support for the ARM and Thumb instruction set architecture. This
includes the following set of macros:
__ARM_ARCH
__ARM_ARCH_ISA_ARM
__ARM_ARCH_ISA_THUMB
__ARM_32BIT_STATE
These help identify the environment that the code is intended to execute on.
Adjust the handling for ACLE 6.4.2 to be more correct. We would define the
profile as a free-standing token rather than a quoted single character.
llvm-svn: 210991
For ARM target, we can use CRYPTO and CRC features if we select
cortex-a57 by '-mcpu', but for AArch64 target, it doesn't work
unless adding with '-mfpu=crypto-neon-fp-armv8'. To keep consistency
between front-end and back-end and get end-users more easier to use,
we'd better add default feature for CPUs on AArch64 target as well.
llvm-svn: 210625
Summary: The Linux Kernel is one example of a piece of software that relies on them.
Reviewers: atanasyan
Reviewed By: atanasyan
Differential Revision: http://reviews.llvm.org/D3756
llvm-svn: 210270
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
This failure mode shows up occasionally when users try to include C headers in
C++ projects or when porting from Windows. We might as well recover in the way
the user expected, thus avoiding confusing diagnostic messages at point of use.
llvm-svn: 209963
Windows on ARM uses AAPCS, but has some deviations. wchar_t remains an unsigned
short on WoA, which does not conform to AAPCS. Ensure that wchar_t is defined
accordingly.
llvm-svn: 207929
This test didn't work as intended and was ultimately disabled some years ago in
r169458.
Indeed it's not clear if the '\n' was ever passed through to the driver
correctly given that lit would insert '&& {' at the newline.
Test rewritten to use printf/xargs to insert '\n' in a more reliable manner and
to use FileCheck for verification.
llvm-svn: 206703
This reverts commit r206413.
This was proposed before, but it's not clear if this is really a good
idea:
http://reviews.llvm.org/D3034
llvm-svn: 206415
This introduces the definitions needed for the Windows on ARM target. Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment. The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.
llvm-svn: 205650
This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3283
llvm-svn: 205591
contents than the header file by the same name under the system header
search root. Surprisingly, this is required to get the test to pass on
some systems.
So, it turns out that there exist filesystems in the world which unique
the inode of all files based on their contents. This results in two
files with the same contents at different paths suddenly having the same
inode. This doesn't actually cause any problems in practice as the
contents are the same, and the path used to access the files are the
same. However, it can cause tests like this one to be more brittle
because the file manager ends up de-duplicating the file entries by
inode. We don't have any other really easy ways to observe the behavior
shift because the whole point is that the #include written in the source
code doesn't contain the information -- instead it is contained in the
header map.
If folks have other solutions they would prefer, I'm more than happy to
work on them, but this seems a reasonable way to ensure that the test in
question exercises the code it wants to exercise.
llvm-svn: 205149
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
gcc never expands macros in pragmas and MSVC always expands macros
before processing pragmas. Clang usually allows macro expansion, except
in a handful of pragmas, most of which are handled by the lexer.
Also remove PPCallbacks for pragmas that are currently handled in the
parser. Without a Parser, such as with clang -E, these callbacks would
never be called.
Fixes PR18576.
llvm-svn: 201821
This makes Clang and LLVM -Wmsvc-include clean.
I believe the correct behavior here is to avoid updating the cache when
we find the header via MSVC's search rules.
Differential Revision: http://llvm-reviews.chandlerc.com/D2733
llvm-svn: 201615
continue header lookup using the framework include as filename.
This allows us to conveniently treat
#import "Foo.h"
as an implicit module import if we can resolve "Foo/Foo.h" as such.
rdar://16042979
llvm-svn: 201419
TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).
Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSuitableAlign() so
that libc++ may take advantage of it.
llvm-svn: 201037
When a macro expansion does not result in any tokens, and the macro name
is preceded by whitespace, the whitespace should be passed to the first
token that follows the macro expansion. Similarly when a macro expansion
ends with a placemarker token, and that placemarker token is preceded by
whitespace. This worked already for top-level macro expansions, but is
now extended to also work for nested macro expansions.
Patch by Harald van Dijk!
llvm-svn: 200787
When a function-like macro definition ends with one of the macro's
parameters, and the argument is empty, any whitespace before the
parameter name in the macro definition needs to be preserved. Promoting
the existing NextTokGetsSpace to a preserved bit-field and checking it
at the end of the macro expansion allows it to be moved to the first
token following the macro expansion result.
Patch by Harald van Dijk!
llvm-svn: 200786
In x ## y, where x and y are regular tokens, whitespace between x and ##
is ignored, and whitespace between ## and y is also ignored. When either
x or y is a function argument, whitespace was preserved, but it should
not be. This patch removes the checks for whitespace before ## and
before y, and in the special case where x is an empty macro argument and
y is a regular token, actively removes whitespace before y.
One existing test is affected by that change, but as clang's output now
matches the standard's requirements and that of GCC, I've tweaked the
testcase.
Patch by Harald van Dijk!
llvm-svn: 200785
This is causing a failure in the msan buildbot that I am having trouble
reproducing. Reverting until I can figure out what went wrong.
llvm-svn: 200492
currently, for thumbv8, two predefined macros are missing:
define __THUMB_INTERWORK__ 1
define __THUMB_INTERWORK__ 1
This patch adds them for thumbv8.
llvm-svn: 199819
Previously we had bodged together some hacks mapping MachO embedded
targets (i.e. mainly ARM v6M and v7M) to the "*-*-darwin-eabi" triple.
This is incorrect in both details (they don't run Darwin and they're
not EABI in any real sense).
This commit appropriates the existing "MachO" environment for the
purpose instead.
llvm-svn: 199367
a subprocess invocation which is pretty significant on Windows. It also
likely saves a bunch of thrashing the host machine needlessly. Finally
it makes the tests much more predictable and less dependent on the host.
For example 'header_lookup1.c' was passing '-fno-ms-extensions' just to
thwart the host detection adding it into the compilation. By runnig CC1
directly we don't have to deal with such oddities.
llvm-svn: 199308
- krait processor currently modeled with the same features as A9.
- Krait processor additionally has VFP4 (fused multiply add/sub)
and hardware division features enabled.
- krait has currently the same Schedule model as A9
- krait cpu flag is not recognized by the GNU assembler yet,
it is replaced with march=armv7-a to avoid a lower march
from being used.
llvm-svn: 196618
llc waits for input on stdin, which was not provided in this test. It
was running only thanks to a quirk in the way lit concatenates
commands.
llvm-svn: 194071
After lexing a '##', we would look ahead and check to see if it was
followed by '__VA_ARGS__'. After doing so, we would then go ahead and
lex the token.
However we would fail in the case where the '##' was followed by a '#'
followed by an identifier because we would have lexed the '#' separately
from the identifier, bypassing our parameter validation logic.
Instead, lex the tokens coming after the '##' later.
This fixes PR17804.
llvm-svn: 194059
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
The C and C++ standards disallow using universal character names to
refer to some characters, such as basic ascii and control characters,
so we reject these sequences in the lexer. However, when the
preprocessor isn't being used on C or C++, it doesn't make sense to
apply these restrictions.
Notably, accepting these characters avoids issues with unicode escapes
when GHC uses the compiler as a preprocessor on haskell sources.
Fixes rdar://problem/14742289
llvm-svn: 193067
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
This partially addresses PR17435, but it doesn't actually implement the
pragma. If we implement it, we should map levels 1-4 to something like
-Wall and level 0 to something like -w.
llvm-svn: 191833
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
Previously the code would reduce a run of backslashes to a single
backslash, and now it will properly leave behind every other backslash.
llvm-svn: 191382
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
Intrinsics added shaintrin.h, which is included from x86intrin.h if __SHA__ is
enabled. SHA implies SSE2, which is needed for the __m128i type.
Also add the -msha/-mno-sha option.
llvm-svn: 190999
Before this patch, Lex() would recurse whenever the current lexer changed (e.g.
upon entry into a macro). This patch turns the recursion into a loop: the
various lex routines now don't return a token when the current lexer changes,
and at the top level Preprocessor::Lex() now loops until it finds a token.
Normally, the recursion wouldn't end up being very deep, but the recursion depth
can explode in edge cases like a bunch of consecutive macros which expand to
nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this
patch).
<rdar://problem/14569770>
llvm-svn: 190980
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
Summary:
This fixes PR17145 and avoids unknown pragma warnings.
This change does not attempt to map MSVC warning numbers to clang
warning flags. Perhaps in the future we will implement a mapping for
some common subset of Microsoft warnings, but for now we don't.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1652
llvm-svn: 190726
Enabling sse4.2 will implicitly enable popcnt unless popcnt is explicitly disabled.
Disabling sse4.2 will not disable popcnt if popcnt is explicitly enabled.
llvm-svn: 190387
Fixes PR17018. Only partial test coverage because I don't want
to try to write a test which generates a file whose name contains a newline.
llvm-svn: 189557
Apparently, gcc's -traditional-cpp behaves slightly differently in C++ mode;
specifically, it discards "//" comments. Match gcc's behavior.
<rdar://problem/14808126>
llvm-svn: 189515
We translate these into #define directives; to preserve gcc-compatible
semantics (where the expanded macro includes the backslash), we add
an extra "\\\n" to the end of the synthesized "#define".
<rdar://problem/14810220>
llvm-svn: 189511
Basically, isInMainFile considers line markers, and isWrittenInMainFile
doesn't. Distinguishing between the two is useful when dealing with
files which are preprocessed files or rewritten with -frewrite-includes
(so we don't, for example, print useless warnings).
llvm-svn: 188968
This moves the logic for handling -mfoo -mno-foo from the driver to -cc1. It
also changes -cc1 to apply the options in order, fixing pr16943.
The handling of -mno-mmx -msse is now an explicit special case.
llvm-svn: 188817
This patch adds -mmsa and -mno-msa to the options supported by
clang to enable and disable support for MSA.
When MSA is enabled, a predefined macro '__mips_msa' is defined to 1.
Patch by Daniel Sanders
llvm-svn: 188184
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
Nemanja Ivanovic