Diagnostic for `-Wauto-import` shouldn't be a warning because it doesn't
represent a potential problem in code that should be fixed. And the
emitted fix-it is likely to trigger `-Watimport-in-framework-header`
which makes it challenging to have a warning-free codebase. But it is
still useful to see how include directives are translated into modular
imports and which module a header belongs to, that's why keep it as a remark.
Keep `-Wauto-import` for now to allow a gradual migration for codebases
using `-Wno-auto-import`, e.g., `-Weverything -Wno-auto-import`.
rdar://79594287
Differential Revision: https://reviews.llvm.org/D130138
Correct the logic used to set `ATOMIC_*_LOCK_FREE` preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for `_Atomic` types even if the underlying types are aligned to a lower
boundary by default.
For example, the `long long` and `double` types on x86 are aligned to
32-bit boundary by default. However, `_Atomic long long` and `_Atomic
double` are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.
This fixes PR #19355 by correcting the value of
`__GCC_ATOMIC_LLONG_LOCK_FREE` on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.
Reviewed By: hfinkel, efriedma
Differential Revision: https://reviews.llvm.org/D28213
The default host CPU for an i386 triple is typically at least an i586,
which has cmpxchg8b (Clang feature, "cx8"). Therefore,
`__CLANG_ATOMIC_LLONG_LOCK_FREE` is 2 on the host, but the value should
be 1 for the device.
Also, grep for `__CLANG_ATOMIC_*` instead of `__GCC_ATOMIC_*`. The CLANG
macros are always emitted, but the GCC macros are omitted for the
*-windows-msvc targets. The `__GCC_HAVE_SYNC_COMPARE_AND_SWAP` macro
always has GCC in its name, not CLANG, however.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D127465
message expressions
For an Obj-C message expression `[o m]`, the adding matcher will match
the declaration of the method `m`. This commit overloads the existing
`callee` ASTMatcher, which originally was only for C/C++ nodes but
also applies to Obj-C messages now.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129398
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
EnumDecl's promotion type is set either to the parsed type or calculated type
after completing its definition. When it's bool type and has no definition,
its promotion type is bool which is not allowed by clang.
Fixes#56560.
Differential Revision: https://reviews.llvm.org/D130210
A copy-paste error caused UB in the definition of the unsigned long long
versions of the shfl intrinsics. Reported and diagnosed by @trws.
Differential Revision: https://reviews.llvm.org/D129536
The OpenMP offloading runtine currently uses an array of linked
offloading images. One downside to this is that we cannot know the
architecture or triple associated with the given image. In this patch,
instead of embedding the image itself, we embed an offloading binary
instead. This binary is simply a binary format that wraps around the
original linked image to provide some additional metadata. This will
allow us to support offloading to multiple architecture, or performing
future JIT compilation inside of the runtime, more clearly.
Additionally, these can be placed at a special section such that the
supported architectures can be identified using objdump with the support
from D126904. This needs to be stored in a new section name
`.llvm.offloading.images` because the `.llvm.offloading` section
implicitly uses the `SHF_EXCLUDE` flag and will always be stripped.
This patch does not contain the necessary code to parse these in
libomptarget.
Depends on D127246
Reviewed By: saiislam
Differential Revision: https://reviews.llvm.org/D127304
Adds `sarif` option to the existing `-fdiagnostics-format` flag
for intended future work with SARIF diagnostics. Currently issues a warning
against the use of diagnostics in SARIF mode, then defaults to clang style for
diagnostics.
Reviewed By: cjdb, denik, aaron.ballman
Differential Revision: https://reviews.llvm.org/D129886
This patch is in preparation for enabling vectorisation with tail-folding
by default for SVE targets. Once we do that many existing tests will
break that depend upon having normal unpredicated vector loops. For
all such tests I have added the flag:
-prefer-predicate-over-epilogue=scalar-epilogue
Differential Revision: https://reviews.llvm.org/D129137
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:
<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1
The above can also be seen here. This patch is about rewording
the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Currently, clang may meet an infinite loop in a very tricky case when it
iterates the default args. This patch tries to fix this by adding a
`fixed` check.
These headers used to be guarded only on PowerPC64 Linux or FreeBSD, but
they can also be enabled for AIX OS target since it's big-endian ready.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D129461
re-land fixes an unwanted interaction with module-map modules, seen in
Greendragon testing.
This provides updates to
[class.mfct]:
Pre C++20 [class.mfct]p2:
A member function may be defined (8.4) in its class definition, in
which case it is an inline member function (7.1.2)
Post C++20 [class.mfct]p1:
If a member function is attached to the global module and is defined
in its class definition, it is inline.
and
[class.friend]:
Pre-C++20 [class.friend]p5
A function can be defined in a friend declaration of a
class . . . . Such a function is implicitly inline.
Post C++20 [class.friend]p7
Such a function is implicitly an inline function if it is attached
to the global module.
We add the output of implicit-inline to the TextNodeDumper, and amend
a couple of existing tests to account for this, plus add tests for the
cases covered above.
Differential Revision: https://reviews.llvm.org/D129045
This patch makes use of OMPIRBuilder support for codegen of taskgroup
construct in clang.
Depends on D128203
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D129992
The heuristic used to determine where the arclite libraries are to be
found was based on the path of the `clang` executable. However, in some
scenarios the `clang` executable is within a toolchain that does not
have arclite. When this happens, derive the arclite paths from the
sysroot option.
This allows Clang to correctly derive the arclite directory in, e.g.,
Swift CI, using similar logic to what the Swift driver has been doing
for several years.
Patched by Doug Gregor.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D130205
The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, but we
still would like the new driver to be able to handle this mode so we can
transition away from the old driver in the future. This patch adds the
necessary code to support creating a fatbinary for HIP code generation.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D129784
A new option -I is added for dxc mode.
It is just alias of existing cc1 -I option.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D128462
Move -lc++experimental before -lc++abi (that was forgotten in the
original patch), and mark a test as UNSUPPORTED on AIX. I contacted
the owners of the AIX bot that failed because I was unable to reproduce
the issue locally.
When F calls G calls H, G is nounwind, and G is inlined into F, then the
inlined call-site to H should be effectively nounwind so as not to lose
information during inlining.
If H itself is nounwind (which often happens when H is an intrinsic), we
no longer mark the callsite explicitly as nounwind. Previously, there
were cases where the inlined call-site of H differs from a pre-existing
call-site of H in F *only* in the explicitly added nounwind attribute,
thus preventing common subexpression elimination.
v2:
- just check CI->doesNotThrow
v3 (resubmit after revert at 344378808778c61d5599f4e0ac783ef7e6f8ed05):
- update Clang tests
Differential Revision: https://reviews.llvm.org/D129860
There is at least one Clang test (clang/test/CodeGen/arm_acle.c) which
has functions guarded by #if's that cause those functions to be compiled
only for a subset of RUN lines.
This results in a case where one RUN line has a body for the function
and another doesn't. Treat this case as a conflict for any prefixes that
the two RUN lines have in common.
This change exposed a bug where functions with '$' in the name weren't
properly recognized in ARM assembly (despite there being a test case
that was supposed to catch the problem!). This bug is fixed as well.
Differential Revision: https://reviews.llvm.org/D130089
These features require that all object files are compiled with the support. When
the feature is disabled for an object file, the merge behavior should treat the
file having a value of 0 (see D129911).
Reviewed By: xiangzhangllvm
Differential Revision: https://reviews.llvm.org/D130065
When LLVM_TOOL_LLVM_DRIVER_BUILD is On, create symlinks
to llvm instead of creating the executables. Currently
this only works for install and not
install-distribution, the work for the later will be
split up into a second patch.
Differential Revision: https://reviews.llvm.org/D127800
Specifically, making the following changes:
* Turn lambdas calculating ODR hashes into static functions.
* Move `ODRCXXRecordDifference` where it is used.
* Rename some variables and move some lines of code.
* Replace `auto` with explicit type when the deduced type is not mentioned.
* Add `const` for unmodified objects, so we can pass them to more functions.
Differential Revision: https://reviews.llvm.org/D128690
Summary: Get rid of explicit function splitting in favor of specifically designed Visitor. Move logic from a family of `evalCastKind` and `evalCastSubKind` helper functions to `SValVisitor`.
Differential Revision: https://reviews.llvm.org/D130029
Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether experimental library
features are provided in libc++. In essence, it links against the
experimental static archive provided by libc++ and defines a feature
that can be picked up by libc++ to enable experimental features.
This ensures that users don't start depending on experimental
(and hence unstable) features unknowingly.
[1]: https://discourse.llvm.org/t/rfc-a-compiler-flag-to-enable-experimental-unstable-language-and-library-features
Differential Revision: https://reviews.llvm.org/D121141
interface decls
This patch teaches getCursorPlatformAvailabilityForDecl to look for
availability attributes on the containing decls or interface decls if
the current decl doesn't have any availability attributes.
Differential Revision: https://reviews.llvm.org/D129504
This re-applies bb939931a1ad, which had been reverted by 09cebfb978de
because it broke Chromium. The issues seen by Chromium should be
addressed by 1d0f79558ca4.
Differential Revision: https://reviews.llvm.org/D128927
This reverts commit 9fb33d52b045b6cc97f2f56fe5cd23b41de86ffe.
Buildbots are showing a number of regressions that don't reproduce
locally. Needs more investigating.
This patch implements recently ratified extension Zmmul, a subextension
of M (Integer Multiplication and Division) consisting only
multiplication part of it.
Differential Revision: https://reviews.llvm.org/D103313
Reviewed By: craig.topper, jrtc27, asb
