This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w.
I believe these have been picked up by the Zce effort using different
encodings. I don't think it makes sense to keep them in bitmanip. It
will eventually cause a conflict if/when Zce is implemented in llvm.
Differential Revision: https://reviews.llvm.org/D110871
A followup to D110201.
For example, we'd set OptimizationRemarkMissed's Regex to '.*' when
encountering -Rpass. Normally this doesn't actually affect remarks we
emit because in clang::ProcessWarningOptions() we'll separately look at
all -R arguments and turn on/off corresponding diagnostic groups.
However, this is reproducible with -round-trip-args.
Reviewed By: JamesNagurne
Differential Revision: https://reviews.llvm.org/D110673
When clang crashes, it writes a standalone source file and shell script
to reproduce the crash.
The Driver used to set `Mode = CPPMode` in generateCompilationDiagnostics()
to force preprocessing mode. This has the side effect of making
IsCLMode() return false, which in turn meant Clang::AddClangCLArgs()
didn't get called when creating the standalone source file, which meant
the stand-alone file was preprocessed with the gcc driver's defaults
In particular, exceptions default to on with the gcc driver, but to
off with the cl driver. The .sh script did use the original command
line, so in the reproducer for a clang-cl crash, the standalone source
file could contain exception-using code after preprocessing that the
compiler invocation in the shell script would then complain about.
This patch removes the `Mode = CPPMode;` line and instead additionally
checks for `CCGenDiagnostics` in most places that check `CCCIsCPP().
This also matches the strategy Clang::ConstructJob() uses to add
-frewrite-includes for creating the standalone source file for a crash
report.
Fixes PR52007.
Differential Revision: https://reviews.llvm.org/D110783
Call Driver::getFinalPhase() instead of duplicating it.
https://reviews.llvm.org/D65993 added the duplication, then
02e35832c3 maded it more obviously a copy of getFinalPhase().
The only difference is that getCompilationPhases() used to use
LastPhase / IfsMerge where getFinalPhase() used Link. Adapt
getFinalPhase() to return IfsMerge when needed.
No intentional behavior change.
Differential Revision: https://reviews.llvm.org/D110770
When a user specifies an out-of-range index for vec_insert, we
just produce IR that has undefined behaviour even though the
documentation states that modulo arithmetic is used. This patch
just truncates the value to a valid index.
This patch aims to address the comment of a previous review:
https://reviews.llvm.org/D109237#inline-1040678
The original problem was the following:
`T` is substituted by `clang::Type`
Expected<T *> import(T *From) {
auto ToOrErr = Importer.Import(From);
// ^^^^^^^^^^^^^^^^^^^^^
if (!ToOrErr)
return ToOrErr.takeError();
return cast_or_null<T>(*ToOrErr);
// ^^^^^^^^^^^^^^^^^^^^^^^^^
}
`Importer.Import()` operates on `const Type *`, thus returns `const Type *`.
Later, at the return statement, we will try to construct an `Expected<Type*>`
from a `const Type *`, which failed with a miserable error message.
In all other cases `importer.Import()` results in a non-const version,
so everything works out just fine, but for `clang::type`s, we should
really return a const version.
So, in case of `T` is a subclass of `clang::Type`, it will return a
`Exprected<const T*>` instead.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D109269
There is a special situation with templates in local classes,
as can be seen in this example with generic lambdas in function scope:
```
template<class T1> void foo() {
(void)[]<class T2>() {
struct S {
void bar() { (void)[]<class T3>(T2) {}; }
};
};
};
template void foo<int>();
```
As a consequence of the resolution of DR1484, bar is instantiated during the
substitution of foo, and in this context we would substitute the lambda within
it with it's own parameters "injected" (turned into arguments).
This can't be properly dealt with for at least a couple of reasons:
* The 'TemplateTypeParm' type itself can only deal with canonical replacement
types, which the injected arguments are not.
* If T3 were constrained in the example above, our (non-conforming) eager
substitution of type constraints would just leave that parameter dangling.
Instead of substituting with injected parameters, this patch just leaves those
inner levels unreplaced.
Since injected arguments appear to be unused within the users of
`getTemplateInstantiationArgs`, this patch just removes that support there and
leaves a couple of asserts in place.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110727
This patch adds OpenMP assumption attributes to call sites in applicable
regions. Currently this applies the caller's assumption attributes to
any calls contained within it. So, if a call occurs inside an OpenMP
assumes region to a function outside that region, we will assume that
call respects the assumptions. This is primarily useful for inline
assembly calls used heavily in the OpenMP GPU device runtime, which
allows us to then make judgements about what the ASM will do.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D110655
This patch makes sure that the builtins __builtin_ppc_load8r and
__ builtin_ppc_store8r are only available for Power 7 and up.
Currently the builtins seem to produce incorrect code if used for
Power 6 or before.
Reviewed By: nemanjai, #powerpc
Differential Revision: https://reviews.llvm.org/D110653
clang-cl maps /wdNNNN to -Wno-flags for a few warnings that map
cleanly from cl.exe concepts to clang concepts.
This patch adds support for the same numbers to
`#pragma warning(disable : NNNN)`. It also lets
`#pragma warning(push)` and `#pragma warning(pop)` have an effect,
since these are used together with `warning(disable)`.
The optional numeric argument to `warning(push)` is ignored,
as are the other non-`disable` `pragma warning()` arguments.
(Supporting `error` would be easy, but we also don't support
`/we`, and those should probably be added together.)
The motivating example is that a bunch of code (including in LLVM)
uses this idiom to locally disable warnings about calls to deprecated
functions in Windows-only code, and 4996 maps nicely to
-Wno-deprecated-declarations:
#pragma warning(push)
#pragma warning(disable: 4996)
f();
#pragma warning(pop)
Implementation-wise:
- Move `/wd` flag handling from Options.td to actual Driver-level code
- Extract the function mapping cl.exe IDs to warning groups to the
new file clang/lib/Basic/CLWarnings.cpp
- Create a diag::Group enum so that CLWarnings.cpp can refer to
existing groups by ID (and give DllexportExplicitInstantiationDecl
a named group), and add a function to map a diag::Group to the
spelling of it's associated commandline flag
- Call that new function from PragmaWarningHandler
Differential Revision: https://reviews.llvm.org/D110668
This patch is in a series of patches to provide builtins for compatibility with
the XL compiler. This patch implements the software divide builtin as
wrappers for a floating point divide. XL provided these builtins because it
didn't produce software estimates by default at `-Ofast`. When compiled
with `-Ofast` these builtins will produce the software estimate for divide.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D106959
Group them together with the vload_half and vstore_half decls for
simplicity.
Reviewed By: svenvh
Differential Revision: https://reviews.llvm.org/D110636
With xlc and xlC pragma align(packed) will pack bitfields the same way
as pragma align(bit_packed). xlclang, xlclang++ and clang will
pack bitfields the same way as pragma pack(1). Issue a warning when
source code using pragma align(packed) is used to alert the user it
may not be compatable with xlc/xlC.
Differential Revision: https://reviews.llvm.org/D107506
The instruction has similar semantics to vbpermq but for doublewords.
It was added in Power9 and the ABI documents the builtin.
Differential revision: https://reviews.llvm.org/D107899
Since XLC only ever shipped on PowerPC AIX and Linux, it is not reasonable to
provide the compatibility macros on any target other than those two. This patch
restricts those macros to AIX/Linux.
Differential revision: https://reviews.llvm.org/D110213
With -fpreserve-vec3-type enabled, a cast was not created when
converting from a non-vec3 type to a vec3 type, even though a
conversion to vec3 was performed. This resulted in creation of
invalid store instructions.
Differential Revision: https://reviews.llvm.org/D108470
On AIX, we relied on LTO to merge the csects for profiling data/counter
sections.
AIX binder now get the namedcsect support to support the merging,
so now we can enable PGO without LTO with the new binder.
Reviewed By: Whitney
Differential Revision: https://reviews.llvm.org/D110671
To avoid using the AST when emitting diagnostics, split the "dontcall"
attribute into "dontcall-warn" and "dontcall-error", and also add the
frontend attribute value as the LLVM attribute value. This gives us all
the information to report diagnostics we need from within the IR (aside
from access to the original source).
One downside is we directly use LLVM's demangler rather than using the
existing Clang diagnostic pretty printing of symbols.
Previous revisions didn't properly declare the new dependencies.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
To avoid using the AST when emitting diagnostics, split the "dontcall"
attribute into "dontcall-warn" and "dontcall-error", and also add the
frontend attribute value as the LLVM attribute value. This gives us all
the information to report diagnostics we need from within the IR (aside
from access to the original source).
One downside is we directly use LLVM's demangler rather than using the
existing Clang diagnostic pretty printing of symbols.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
(This is a recommit of 3d6f49a569 that should no longer break validation since
bd379915de).
It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.
Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.
Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.
After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite
Differential Revision: https://reviews.llvm.org/D109967
This allows clang to work on Linux distributions like Debian where
<CUDA-PATH>/include may be a symlink to /usr/include. We only need
`cuda_wrappers` to be present before the standard C++ library headers.
The CUDA SDK headers themselves do not need to be found that early.
This addresses https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995122
mentioned in post-commit comments on D108247
Differential Revision: https://reviews.llvm.org/D110596
(This relands 59337263ab and makes sure comma operator
diagnostics are suppressed in a SFINAE context.)
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
This patch is in a series of patches to provide builtins for
compatability with the XL compiler. This patch adds builtins for compare
exponent and test data class operations on floating point values.
Reviewed By: #powerpc, lei
Differential Revision: https://reviews.llvm.org/D109437
No idea how my local machine missed this, but I saw no warning for it,
it seems to have been lost in some level of translating this back for
upstreaming.
Require it to be always_inline, to more closely match how _FORITFY_SOURCE
behaves.
This avoids generation of `.inline` suffixed functions - these should always be
inlined.
After significant problems in our downstream with the previous
implementation, the SYCL standard has opted to make using macros/etc to
change kernel-naming-lambdas in any way UB (even passively). As a
result, we are able to just emit the itanium mangling.
However, this DOES require a little work in the CXXABI, as the microsoft
and itanium mangler use different numbering schemes for lambdas. This
patch adds a pair of mangling contexts that use the normal 'itanium'
mangling strategy to fill in the "DeviceManglingNumber" used previously
by CUDA.
Differential Revision: https://reviews.llvm.org/D110281
C++17 permits using 'typename' or 'class' for a template template
parameter, but the error message in the parser only refers to 'class'.
This patch, in C++17 or newer modes, adds "or 'template'" to the
diagnostic.
It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.
Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.
Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.
After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite
Differential Revision: https://reviews.llvm.org/D109967
This patch adds the following built-ins:
__builtin_vsx_build_pair
__builtin_mma_build_acc
Reviewed By: #powerpc, nemanjai, lei
Differential Revision: https://reviews.llvm.org/D107647
These values allow, for example, `--target=aarch64` and
`--target=aarch64-linux-gnu` to detect `aarch64-linux-android`. This is
confusing. Users should specify `--target=aarch64-linux-android` to get Android GCC
installation.
Reverts D53463.
Reviewed By: nickdesaulniers, danalbert
Differential Revision: https://reviews.llvm.org/D110379
This patch adds a new preprocessor extension ``#pragma clang final``
which enables warning on undefinition and re-definition of macros.
The intent of this warning is to extend beyond ``-Wmacro-redefined`` to
warn against any and all alterations to macros that are marked `final`.
This warning is part of the ``-Wpedantic-macros`` diagnostics group.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D108567
HIP currently uses -mlink-builtin-bitcode to link all bitcode libraries, which
changes the linkage of functions to be internal once they are linked in. This
works for common bitcode libraries since these functions are not intended
to be exposed for external callers.
However, the functions in the sanitizer bitcode library is intended to be
called by instructions generated by the sanitizer pass. If their linkage is
changed to internal, their parameters may be altered by optimizations before
the sanitizer pass, which renders them unusable by the sanitizer pass.
To fix this issue, HIP toolchain links the sanitizer bitcode library with
-mlink-bitcode-file, which does not change the linkage.
A struct BitCodeLibraryInfo is introduced in ToolChain as a generic
approach to pass the bitcode library information between ToolChain and Tool.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D110304
This patch adds a new RTL function for worksharing. Currently we use
`__kmpc_for_static_init` for both the `distribute` and `parallel`
portion of the loop clause. This patch replaces the `distribute` portion
with a new runtime call `__kmpc_distribute_static_init`. Currently this
will be used exactly the same way, but will make it easier in the future
to fine-tune the distribute and parallel portion of the loop.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D110429
We used to put the canonical spelling of flags after alias processing
on that line. For clang-cl in particular, that meant that we put flags
on that line that the clang-cl driver doesn't even accept, and the
"Driver args:" line wasn't usable.
Differential Revision: https://reviews.llvm.org/D110458
Balázs Kéri