Summary: Makes -fprofile-instr-generate and -fprofile-instr-use work
with clang-cl so that profile-guided optimization can be used.
Differential Revision: https://reviews.llvm.org/D27086
llvm-svn: 288230
specifications in this mode in C++17, since they're part of the function type,
so check and diagnose them like we would if exceptions were enabled.
Better ideas welcome.
llvm-svn: 288220
Otherwise MSVC and clang-cl will see "extern inline" after merging
redeclarations and emit it in all TUs that include Type.h and Decl.h.
Noticed by inspection, since it's always the first thing to get emitted.
llvm-svn: 288197
Refactor the Distro enum along with helper functions into a full-fledged
Distro class, inspired by llvm::Triple, and make it a public API.
The new class wraps the enum with necessary comparison operators, adding
the convenience Is*() methods and a constructor performing
the detection. The public API is needed to run the unit tests (D25869).
Differential Revision: https://reviews.llvm.org/D25949
llvm-svn: 288060
This solves PR23715 in a way that is compatible with LTO.
MSVC supports jumping to source-level labels and between inline asm
blocks, but we don't.
Also revert the old solution, r255201, which was to mark these calls as
noduplicate.
llvm-svn: 288059
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
https://reviews.llvm.org/D25932 made it so that clang always checks if
libLTO.dylib is present on disk, even if -flto is not being used. The
motivation for that change was that if a dependency happens to contain bitcode,
ld64 will try to load libLTO without -flto explicitly being enabled. However,
the change had the undesirable side effect of warning if libLTO.dylib doesn't
exist even if it isn't needed.
Change things so that -lto_library is always passes, independent of if it
exists or not. ld64 only looks at this flag if it uses LTO. If the dylib
exists, all is well. If it doesn't, and LTO is not being used, all is well too.
If ld64 does end up using LTO and the dylib does not exist, ld64 will print
something like
ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64
https://reviews.llvm.org/D26984
llvm-svn: 287685
Summary:
The new error information contains the type of error (e.g. overlap or bad file path)
and the replacement(s) that is causing the error. This enables us to resolve some errors.
For example, for insertion at the same location conflict, we need to know the
existing replacement which conflicts with the new replacement in order to calculate
the new position to be insert before/after the existing replacement (for merging).
Reviewers: klimek, bkramer
Subscribers: djasper, cfe-commits
Differential Revision: https://reviews.llvm.org/D26853
llvm-svn: 287639
with __unknown_anytype return type.
When the following code is compiled, Sema infers that the type of
__unknown_anytype is double:
extern __unknown_anytype func();
double *d = (double*)&func();
This triggers an assert in CodeGenFunction::EmitCallExprLValue because
it doesn't expect to see a call to a function with a non-reference
scalar return type.
This commit prevents the assert by making VisitUnaryAddrOf error out if
the address-of operator is applied to a call to a function with
__unknown_anytype return type.
rdar://problem/20287610
Differential revision: https://reviews.llvm.org/D26808
llvm-svn: 287410
Summary:
Compiling CUDA device code requires us to know the host toolchain,
because CUDA device-side compiles pull in e.g. host headers.
When we only supported Linux compilation, this worked because
CudaToolChain, which is responsible for device-side CUDA compilation,
inherited from the Linux toolchain. But in order to support MacOS,
CudaToolChain needs to take a HostToolChain pointer.
Because a CUDA toolchain now requires a host TC, we no longer will
create a CUDA toolchain from Driver::getToolChain -- you have to go
through CreateOffloadingDeviceToolChains. I am *pretty* sure this is
correct, and that previously any attempt to create a CUDA toolchain
through getToolChain() would eventually have resulted in us throwing
"error: unsupported use of NVPTX for host compilation".
In any case hacking getToolChain to create a CUDA+host toolchain would
be wrong, because a Driver can be reused for multiple compilations,
potentially with different host TCs, and getToolChain will cache the
result, causing us to potentially use a stale host TC.
So that's the main change in this patch.
In addition, we have to pull CudaInstallationDetector out of Generic_GCC
and into a top-level class. It's now used by the Generic_GCC and MachO
toolchains.
Reviewers: tra
Subscribers: rryan, hfinkel, sfantao
Differential Revision: https://reviews.llvm.org/D26774
llvm-svn: 287285
Re-introduce r285411.
Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.
This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).
Patch by Steve O'Brien!
Differential Revision: https://reviews.llvm.org/D26089
llvm-svn: 287275
In addition to the preprocessed sources file and reproducer script, also
point to the .crash diagnostic files on Darwin. Example:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash
When no match is found for the .crash, point the user to a directory
where those can be found. Example:
clang-4.0: note: diagnostic msg: Crash backtrace is located in
clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
rdar://problem/27286266
llvm-svn: 287262
Summary:
This changes pointers to cached tokens for default arguments in C++ from raw pointers to unique_ptrs. There was a fixme in the code where the cached tokens are created about using a smart pointer.
The change is straightforward, though I did have to track down and fix a memory corruption caused by the change. memcpy was being used to copy parameter information. This duplicated the unique_ptr, which led to the cached token buffer being deleted prematurely.
Patch by David Tarditi!
Reviewers: malcolm.parsons
Subscribers: arphaman, malcolm.parsons, cfe-commits
Differential Revision: https://reviews.llvm.org/D26435
llvm-svn: 287241
is completely irrelevant, producing (effectively) false positives, and -Wmost
is used pretty widely. We should somehow turn it back on by default when
targeting the MS ABI, however, since it indicates the program will not do as
intended in those cases.
(Or perhaps we should just treat enum bitfields as having the signedness of the
enum, even when targeting the MS ABI...)
llvm-svn: 287193
Summary:
Add a warning when assigning enums to bitfields without an explicit
unsigned underlying type. This is to prevent problems with MSVC
compatibility, since the Microsoft ABI defaults to storing enums with a
signed type, causing inconsistencies with saving to/reading from
bitfields.
Also disabled the warning in the dr0xx.cpp test which throws the error,
and added a test for the warning.
The warning can be disabled with -Wno-signed-enum-bitfield.
Patch by Sasha Bermeister!
Reviewers: rnk, aaron.ballman
Subscribers: mehdi_amini, aaron.ballman, cfe-commits, thakis, dcheng
Differential Revision: https://reviews.llvm.org/D24289
llvm-svn: 287177
Remove the check::RegionChanges::wantsRegionChangeUpdate callback as it is no
longer used (since checkPointerEscape has been added).
A patch by Krzysztof Wiśniewski!
Differential Revision: https://reviews.llvm.org/D26759
llvm-svn: 287175
This can be used to append alternative typo corrections to an existing diag.
include-fixer can use it to suggest includes to be added.
Differential Revision: https://reviews.llvm.org/D26745
llvm-svn: 287128
Both the (V)CVTDQ2PD (i32 to f64) and (V)CVTUDQ2PD (u32 to f64) conversion instructions are lossless and can be safely represented as generic __builtin_convertvector calls instead of x86 intrinsics without affecting final codegen.
This patch removes the clang builtins and their use in the headers - a future patch will deal with removing the llvm intrinsics.
This is an extension patch to D20528 which dealt with the equivalent sse/avx cases.
Differential Revision: https://reviews.llvm.org/D26686
llvm-svn: 287088
Summary:
-fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly
passed when using LTO. LTO is a special case of -fembed-bitcode which
it doesn't require embed the bitcode in a special section in the object
file but it requires linker to save that as part of the final executable.
rdar://problem/29274226
Reviewers: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26690
llvm-svn: 287084
The wave barrier represents the discardable barrier. Its main purpose is to
carry convergent attribute, thus preventing illegal CFG optimizations. All lanes
in a wave come to convergence point simultaneously with SIMT, thus no special
instruction is needed in the ISA. The barrier is discarded during code generation.
Differential Revision: https://reviews.llvm.org/D26584
llvm-svn: 287006
This patch implements all the overloads for vec_xl_be and vec_xst_be. On BE,
they behaves exactly the same with vec_xl and vec_xst, therefore they are
simply implemented by defining a matching macro. On LE, they are implemented
by defining new builtins and intrinsics. For int/float/long long/double, it
is just a load (lxvw4x/lxvd2x) or store(stxvw4x/stxvd2x). For char/char/short,
we also need some extra shuffling before or after call the builtins to get the
desired BE order. For int128, simply call vec_xl or vec_xst.
llvm-svn: 286971
Summary: The name is slightly confusing, since the constraint is not necessarily within the range unless `Assumption` is true. Split out renaming for ConstraintManager.h from D26061
Reviewers: zaks.anna, dcoughlin
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26644
llvm-svn: 286927
Adds 2 vector functions for converting from a vector of unsigned short to a
vector of float. One converts the low 4 halfwords and one converts the high
4 halfwords.
Differential Revision: https://reviews.llvm.org/D26534
llvm-svn: 286863
Make handling integer parameters more flexible:
- For the number of events argument allow to pass larger
integers than 32 bits as soon as compiler can prove that
the range fits in 32 bits. If not, the diagnostic will be given.
- Change type of the arguments specifying the sizes of
the corresponding block arguments to be size_t.
Review: https://reviews.llvm.org/D26509
llvm-svn: 286849
Add vector extract exponent/significand functions to altivec.h, as well as
functions (and related constants) to test the data class of vector float
and vector double.
Differential Revision: https://reviews.llvm.org/D26271
llvm-svn: 286830
This is part of a set of changes to allow InstCombine in the backend to optimize variable shifts without having to know about masking.
llvm-svn: 286757
Artem Dergachev