| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Missed in rL302418
Differential Revision: https://reviews.llvm.org/D32770
llvm-svn: 302445
|
|
|
|
|
|
|
| |
This is necessary to be able to build a libc++ module from preprocessed source
(due to the submodule std.new).
llvm-svn: 302312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The whitespace should come from the argument name in the macro
expansion, rather than from the token passed to the macro (same as it
does when not pasting).
Added a new test case for the change in behavior to stringize_space.c.
FileCheck'ized macro_paste_commaext.c, tweaked the test case, and
added a comment; no behavioral change to this test.
Differential Revision: https://reviews.llvm.org/D30427
llvm-svn: 302195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preprocessing a module.
These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.
Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).
llvm-svn: 302098
|
|
|
|
| |
llvm-svn: 302079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us with a problem:
there is no way to represent the expansion of a #include that imports a module
in the -E output for such languages. (We don't want to just leave it as a
#include because that requires the consumer of the preprocessed source to have
the same file system layout and include paths as the creator.)
This patch adds a new pragma:
#pragma clang module import MODULE.NAME.HERE
that imports a module, and changes -E and -frewrite-includes to use it when
rewriting a #include that maps to a module import. We don't make any attempt
to use a native language syntax import if one exists, to get more consistent
output. (If in the future, @import and #include have different semantics in
some way, the pragma will track the #include semantics.)
llvm-svn: 301725
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic in #pragma diagnostic
This matches the warning group that's specified for the unknown warning options
that are passed-in as command line arguments.
rdar://29526025
llvm-svn: 301647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
size_t is usually defined as unsigned long, but on 64-bit platforms,
stdint.h currently defines SIZE_MAX using "ull" (unsigned long long).
Although this is the same width, it doesn't necessarily have the same
alignment or calling convention. It also triggers printf warnings when
using the format flag "%zu" to print SIZE_MAX.
This changes SIZE_MAX to reuse the compiler-provided __SIZE_MAX__, and
provides similar fixes for the other integers:
- INTPTR_MIN
- INTPTR_MAX
- UINTPTR_MAX
- PTRDIFF_MIN
- PTRDIFF_MAX
- INTMAX_MIN
- INTMAX_MAX
- UINTMAX_MAX
- INTMAX_C()
- UINTMAX_C()
... and fixes the typedefs for intptr_t and uintptr_t to use
__INTPTR_TYPE__ and __UINTPTR_TYPE__ instead of int32_t, effectively
reverting r89224, r89226, and r89237 (r89221 already having been
effectively reverted).
We can probably also kill __INTPTR_WIDTH__, __INTMAX_WIDTH__, and
__UINTMAX_WIDTH__ in a follow-up, but I was hesitant to delete all the
per-target CHECK lines in this commit since those might serve their own
purpose.
rdar://problem/11811377
llvm-svn: 301593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a file search involves a header map, suppress
-Wnonportable-include-path. It's firing lots of false positives for
framework authors internally, and it's not trivial to fix.
Consider a framework called "Foo" with a main (installed) framework header
"Foo/Foo.h". It's atypical for "Foo.h" to actually live inside a
directory called "Foo" in the source repository. Instead, the
build system generates a header map while building the framework.
If Foo.h lives at the top-level of the source repository (common), and
the git repo is called ssh://some.url/foo.git, then the header map will
have something like:
Foo/Foo.h -> /Users/myname/code/foo/Foo.h
where "/Users/myname/code/foo" is the clone of ssh://some.url/foo.git.
After #import <Foo/Foo.h>, the current implementation of
-Wnonportable-include-path will falsely assume that Foo.h was found in a
nonportable way, because of the name of the git clone (.../foo/Foo.h).
However, that directory name was not involved in the header search at
all.
This commit adds an extra parameter to Preprocessor::LookupFile and
HeaderSearch::LookupFile to track if the search used a header map,
making it easy to suppress the warning. Longer term, once we find a way
to avoid the false positive, we should turn the warning back on.
rdar://problem/28863903
llvm-svn: 301592
|
|
|
|
|
|
|
|
|
| |
Darwin doesn't support C11 threads.h. Define `__STDC_NO_THREADS__` so
that users can check for it.
rdar://problem/18461003
llvm-svn: 301508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Libc++ currently implements the `ATOMIC_<TYPE>_LOCK_FREE` macros using the `__GCC_ATOMIC_<TYPE>_LOCK_FREE` macros. However these are not available when MSVC compatibility is enabled even though C11 `_Atomic` is. This prevents libc++ from correctly implementing `ATOMIC_<TYPE>_LOCK_FREE`.
This patch adds an alternative spelling `__CLANG_ATOMIC_<TYPE>_LOCK_FREE` that is enabled with `-fms-compatibility`.
Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk
Reviewed By: rsmith
Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff
Differential Revision: https://reviews.llvm.org/D32265
llvm-svn: 300914
|
|
|
|
|
|
|
| |
This macro is defined for arm-none-eabi as of r266625, but it should also be
defined for eabihf and aarch64.
llvm-svn: 300549
|
|
|
|
|
|
|
|
|
| |
with disabling it as well as disabling all vsx specific features when
turning off altivec.
Fixes PR32663.
llvm-svn: 300395
|
|
|
|
|
|
|
|
|
|
| |
Intel disabled the feature on some haswell and broadwell processors:
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/core-m-processor-family-spec-update.pdf
the -mrtm option will still work normally.
llvm-svn: 298956
|
|
|
|
|
|
| |
Adjust and add a test for the 32-bit side.
llvm-svn: 298778
|
|
|
|
| |
llvm-svn: 298770
|
|
|
|
|
|
| |
well.
llvm-svn: 298769
|
|
|
|
|
|
|
|
| |
This typically is only for a new enough linker (bfd >= 2.16.2 or gold), but
our ppc suppport post-dates this and it should work on all linux platforms. It
is guaranteed to work on all elfv2 platforms.
llvm-svn: 298765
|
|
|
|
|
|
| |
than the default of 8 in clang, fix and update tests accordingly.
llvm-svn: 298761
|
|
|
|
|
|
|
| |
The le triple didn't exist until power8, so use that as a default (this
also matches what gcc does).
llvm-svn: 298759
|
|
|
|
|
|
| |
available by default on those cpus and configurations.
llvm-svn: 298307
|
|
|
|
| |
llvm-svn: 298299
|
|
|
|
| |
llvm-svn: 298006
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Broadcom Vulcan is now Cavium ThunderX2T99.
LLVM Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32113
Corresponding LLVM change: https://reviews.llvm.org/rL297190
Changes to clang to support the change.
Patch by Joel Jones
llvm-svn: 297227
|
|
|
|
| |
llvm-svn: 297098
|
|
|
|
|
|
| |
across archs.
llvm-svn: 296256
|
|
|
|
| |
llvm-svn: 295786
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Historically, NetBSD, FreeBSD and OpenBSD have defined the macro ABICALLS in
the preprocessor when -mabicalls is in effect.
Mainline GCC later defined __mips_abicalls when -mabicalls is in effect.
This patch teaches the preprocessor to define these macros when appropriate.
NetBSD does not require the ABICALLS macro.
This resolves PR/31694.
Thanks to Sean Bruno for highlighting this issue!
Reviewers: slthakur, seanbruno
Reviewed By: seanbruno
Subscribers: joerg, brad, emaste, seanbruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D29032
llvm-svn: 295728
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rengolin, t.p.northover
Reviewed By: t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: https://reviews.llvm.org/D30100
llvm-svn: 295647
|
|
|
|
|
|
| |
platforms to match what other compilers produce.
llvm-svn: 295156
|
|
|
|
|
|
|
|
|
|
|
| |
This is a followup change to add v7ve support to clang for gcc
compatibility. Please see r294661.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29773
llvm-svn: 294662
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
|
|
|
|
| |
llvm-svn: 294534
|
|
|
|
|
|
| |
__PREFETCHWT1__ define to match gcc.
llvm-svn: 294424
|
|
|
|
| |
llvm-svn: 294423
|
|
|
|
| |
llvm-svn: 294419
|
|
|
|
|
|
|
|
| |
match gcc.
In the future, we should also add a clwb intrinsic to the backend, a frontend builtin, and an instrinsic header file.
llvm-svn: 294416
|
|
|
|
|
|
| |
__CLFLUSHOPT__ define to match gcc.
llvm-svn: 294411
|
|
|
|
|
|
|
| |
This reverts commit SVN r294148. Seems that it was mistaken, and GCC
does still define `__unix` and `unix` when in GNU mode.
llvm-svn: 294332
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC 7 will predefine two new macros on s390x:
- __ARCH__ indicates the ISA architecture level
- __VX__ indicates that the vector facility is available
This adds those macros to clang as well to ensure continued
compatibility with GCC.
llvm-svn: 294197
|
|
|
|
|
|
|
|
| |
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
|
|
|
|
|
|
|
|
|
|
| |
be defined for non Objective-C code as well
rdar://29794915
Differential Revision: https://reviews.llvm.org/D28349
llvm-svn: 292617
|
|
|
|
|
|
| |
Thanks Dimitry Andric for the report and fix!
llvm-svn: 292032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compilation.
Summary:
CUDA lets users share structs between the host and device, so for that
and other reasons, primitive types such as ptrdiff_t should be the same
on both sides of the compilation.
Our code to do this wasn't entirely successful. In particular, we did a
bunch of work during the NVPTXTargetInfo constructor, only to override
it in the NVPTX{32,64}TargetInfo constructors. It worked well enough on
Linux and Mac, but Windows is LLP64, which is different enough to break
it.
This patch removes the NVPTX{32,64}TargetInfo classes entirely and fixes
the bug described above.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28322
llvm-svn: 291135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
|
|
|
|
|
|
|
| |
FPv5 is in Cortex-M7 and the 64-bit CPUs when running in 32-bit mode. The name
is from the Cortex-M7 TRM.
llvm-svn: 290268
|
|
|
|
| |
llvm-svn: 289614
|
|
|
|
|
|
|
|
|
|
|
| |
It should already be handled but a typo in the LANGSTANDARD() definition
was introduced in r147220.
Patch by Alexander Richardson, test case by me.
Differential Revision:https://reviews.llvm.org/D27427
llvm-svn: 288793
|
|
|
|
|
|
|
| |
Run clang -cc1 -E instead of -S, in an attempt to make this test work
cross-platform.
llvm-svn: 287292
|