| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(#158134)
|
|
|
|
While working on vector deleting destructors support
([GH19772](https://github.com/llvm/llvm-project/issues/19772)), I
noticed that MSVC produces different code in scalar deleting destructor
body depending on whether class defined its own operator delete. In
MSABI deleting destructors accept an additional implicit flag parameter
allowing some sort of flexibility. The mismatch I noticed is that
whenever a global operator delete is called, i.e. `::delete`, in the
code produced by MSVC the implicit flag argument has a value that makes
the 3rd bit set, i.e. "5" for scalar deleting destructors "7" for vector
deleting destructors.
Prior to this patch, clang handled `::delete` via calling global
operator delete direct after the destructor call and not calling class
operator delete in scalar deleting destructor body by passing "0" as
implicit flag argument value. This is fine until there is an attempt to
link binaries compiled with clang with binaries compiled with MSVC. The
problem is that in binaries produced by MSVC the callsite of the
destructor won't call global operator delete because it is assumed that
the destructor will do that and a destructor body generated by clang
will never do.
This patch removes call to global operator delete from the callsite and
add additional check of the 3rd bit of the implicit parameter inside of
scalar deleting destructor body.
---------
Co-authored-by: Tom Honermann <tom@honermann.net>
|
|
Per OpenMP 6.0 specification, section 7.9.9
Argument keywords, page 291, L17
Semantics, page 292, L15-16
The behavior of 'private' should be described in the same manner as that
of 'firstprivate'
15 ... If implicit-behavior is firstprivate, 16 the attribute is a
data-sharing attribute of firstprivate.
Relevant OpenMP 6.0 issues
defaultmap clause new implicit-behavior 'private' should be documented
https://github.com/OpenMP/spec/issues/4571
Issue 4571: Add missing sentence about private to defaultmap
https://github.com/OpenMP/spec/pull/4577
Testing:
Updated 'defaultmap' error message and codegen LIT tests to verify
behavior of 'private' in OpenMP 6.0.
|
|
These are defined in the user range until standard versions of them get
adopted into dwarf, which is expected in DWARF6.
Some of these amount to reservations currently as no code to use them is
included. It would be very helpful to get them committed to avoid
conflicts necessitating encoding changes while we are in the process of
upstreaming.
---------
Co-authored-by: Juan Martinez Fernandez <juamarti@amd.com>
Co-authored-by: Emma Pilkington <Emma.Pilkington@amd.com>
|
|
First of two patches split from original defaultmap PR:
https://github.com/llvm/llvm-project/pull/157767
Per OpenMP 6.0 specification, section 7.9.9
Argument keywords, page 291, L17
Additional information, page 291, L24-25
24 The value alloc may also be specified as implicit-behavior with
identical meaning to the value 25 storage.
Testing:
Updated 'defaultmap' error message and codegen LIT tests to verify
behavior in OpenMP 6.0.
|
|
Reverts llvm/llvm-project#157463
The PR breaks buildbots with old ROCm versions, so revert it and reapply
when buildbots are updated.
|
|
Remove definitions, test uses, and documentation of the macros, which were
deprecated in November 2024 with PR #112849 / #115507.
Where required, the wavefront size should instead be queried via means provided
by the HIP runtime: the (non-constexpr) `warpSize` variable in device code, or
`hipGetDeviceProperties` in host code.
This change passed AMD-internal testing.
Implements SWDEV-522062.
|
|
Support for Variable Category in Default Clause.
---------
Co-authored-by: Sunil Kuravinakop <kuravina@pe31.hpc.amslabs.hpecorp.net>
|
|
Cygwin should support calling convention attributes `__cdecl`,
`__stdcall`, `__thiscall`, and `__fastcall`, even though they have no
effect in x86_64, as done in MinGW.
Originally reported in
https://cygwin.com/pipermail/cygwin/2025-September/258782.html
---------
Co-authored-by: Jeremy Drake <github@jdrake.com>
|
|
In
https://github.com/llvm/llvm-project/commit/45ca613c135ea7b5fbc63bff003f20bf20f62081,
whether to mangle names based on calling conventions according to
Microsoft conventions was refactored to a bool in the TargetInfo. Cygwin
targets also require this mangling, but were missed, presumably due to
lack of test coverage of these targets. This commit enables the name
mangling for Cygwin, and also enables test coverage of this mangling on
Cygwin targets.
|
|
This is a re-land of #152537 now that #157841 is merged.
|
|
Technically, SPIR-V should use addrspace(4) for generic pointers.
We already set the default AS in TargetInfo to 4, but that's not enough
for all cases. Also set the program address space to 4 to fix the
remaining cases. AMD already does this for their SPIR-V target, do it
for Intel's SPIR-V target.
I need this for OpenMP offloading to SPIR-V. There are a couple of
places I need to change in the OMP FE to check the program AS, I'll do
that in a follow-up PR.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
|
|
Reverts llvm/llvm-project#152537
Broke the build in some cases. Need to investigate more for a proper
solution.
|
|
(#152252)
Following https://github.com/llvm/llvm-project/pull/152251
We can now loosen the requirement of `-fcf-protection=return` from
Zicfiss to Zimop
|
|
This is the first PR to implement the semantics proposal:
https://github.com/llvm/wg-hlsl/blob/main/proposals/0031-semantics.md
This PR focuses on the changes required to handle user semantics, but
tried to be almost NFC.
What changes is the error messages as the semantics case is not kept
when reporting error messages.
You might notice the SV_GroupIndex semantic is not properly validated as
are others. This is an existing behavior that we'll need to fix, but
wanted to keep this separated from this rewrite to stay as-close as an
NFC as possible.
The next PR will add support on the different kinds of I/O we can have
using semantics (input, inout param, structs).
|
|
OMPCanonicalLoopNestTransformationDirective (#155848)
This is preparatory work for the implementation of `#pragma omp fuse` in
https://github.com/llvm/llvm-project/pull/139293
Not all OpenMP loop transformations makes sense to make them inherit
from `OMPLoopBasedDirective`, in particular in OpenMP 6.0 'fuse' (to be
implemented later) is a transformation of a canonical loop sequence.
This change renames class `OMPLoopTransformationDirective` to
`OMPCanonicalLoopNestTransformationDirective` so we can reclaim that
name in a later change.
|
|
Fixes what is presumably a typo in a comment in `builtinIsSupported`.
Co-authored-by: hstk30-hw <hanwei62@huawei.com>
|
|
The 256-bit maximum vector register size control was removed from AVX10
whitepaper, ref: https://cdrdv2.intel.com/v1/dl/getContent/784343
We have warned these options in LLVM21 through #132542. This patch
removes underlying implementations in LLVM22.
|
|
This implements support for [named
loops](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm) for
C2y.
When parsing a `LabelStmt`, we create the `LabeDecl` early before we parse
the substatement; this label is then passed down to `ParseWhileStatement()`
and friends, which then store it in the loop’s (or switch statement’s) `Scope`;
when we encounter a `break/continue` statement, we perform a lookup for
the label (and error if it doesn’t exist), and then walk the scope stack and
check if there is a scope whose preceding label is the target label, which
identifies the jump target.
The feature is only supported in C2y mode, though a cc1-only option
exists for testing (`-fnamed-loops`), which is mostly intended to try
and make sure that we don’t have to refactor this entire implementation
when/if we start supporting it in C++.
---------
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
|
|
|
|
(#154618)
In 29992cfd628ed5b968ccb73b17ed0521382ba317 (#145967) support was added
for "trap reasons" on traps emitted in UBSan in trapping mode (e.g.
`-fsanitize-trap=undefined`). This improved the debugging experience by
attaching the reason for trapping as a string on the debug info on trap
instructions. Consumers such as LLDB can display this trap reason string
when the trap is reached.
A limitation of that patch is that the trap reason string is hard-coded
for each `SanitizerKind` even though the compiler actually has much more
information about the trap available at compile time that could be shown
to the user.
This patch is an incremental step in fixing that. It consists of two
main steps.
**1. Introduce infrastructure for building trap reason strings**
To make it convenient to construct trap reason strings this patch
re-uses Clang's powerful diagnostic infrastructure to provide a
convenient API for constructing trap reason strings. This is achieved
by:
* Introducing a new `Trap` diagnostic kind to represent trap diagnostics
in TableGen files.
* Adding a new `Trap` diagnostic component. While this part probably
isn't technically necessary it seemed like I should follow the existing
convention used by the diagnostic system.
* Adding `DiagnosticTrapKinds.td` to describe the different trap
reasons.
* Add the `TrapReasonBuilder` and `TrapReason` classes to provide an
interface for constructing trap reason strings and the trap category.
Note this API while similar to `DiagnosticBuilder` has different
semantics which are described in the code comments. In particular the
behavior when the destructor is called is very different.
* Adding `CodeGenModule::BuildTrapReason()` as a convenient constructor
for the `TrapReasonBuilder`.
This use of the diagnostic system is a little unusual in that the
emitted trap diagnostics aren't actually consumed by normal diagnostic
consumers (e.g. the console). Instead the `TrapReasonBuilder` is just
used to format a string, so in effect the builder is somewhat analagous
to "printf". However, re-using the diagnostics system in this way brings
a several benefits:
* The powerful diagnostic templating languge (e.g. `%select`) can be
used.
* Formatting Clang data types (e.g. `Type`, `Expr`, etc.) just work
out-of-the-box.
* Describing trap reasons in tablegen files opens the door for
translation to different languages in the future.
* The `TrapReasonBuilder` API is very similar to `DiagnosticBuilder`
which makes it easy to use by anyone already familiar with Clang's
diagnostic system.
While UBSan is the first consumer of this new infrastructure the intent
is to use this to overhaul how trap reasons are implemented in the
`-fbounds-safety` implementation (currently exists downstream).
**2. Apply the new infrastructure to UBSan checks for arithmetic
overflow**
To demonstrate using `TrapReasonBuilder` this patch applies it to UBSan
traps for arithmetic overflow. The intention is that we would
iteratively switch to using the `TrapReasonBuilder` for all UBSan traps
where it makes sense in future patches.
Previously for code like
```
int test(int a, int b) { return a + b; }
```
The trap reason string looked like
```
Undefined Behavior Sanitizer: Integer addition overflowed
```
now the trap message looks like:
```
Undefined Behavior Sanitizer: signed integer addition overflow in 'a + b'
```
This string is much more specific because
* It explains if signed or unsigned overflow occurred
* It actually shows the expression that overflowed
One possible downside of this approach is it may blow up Debug info size
because now there can be many more distinct trap reason strings. To
allow users to avoid this a new driver/cc1 flag
`-fsanitize-debug-trap-reasons=` has been added which can either be
`none` (disable trap reasons entirely), `basic` (use the per
`SanitizerKind` hard coded strings), and `detailed` (use the new
expressive trap reasons implemented in this patch). The default is
`detailed` to give the best out-of-the-box debugging experience. The
existing `-fsanitize-debug-trap-reasons` and
`-fno-sanitize-debug-trap-reasons` have been kept for compatibility and
are aliases of the new flag with `detailed` and `none` arguments passed
respectively.
rdar://158612755
|
|
Factoring in flang, just have a single fillAMDGPUFeatureMap
function doing it all as an external interface and returing
an error.
|
|
If a wavefrontsize32 or wavefrontsize64 is the only possible value
insert it into feature list by default and use that value as an
indication that another wavefront size is not legal.
|
|
Use the generic AS as the default AS for Intel-flavored SPIR-V.
Nobody is using the `spirv64-intel` triple right now as far as I know,
I'm planning to use it for OpenMP offload and we will definitely need
generic AS as default there.
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
|
|
|
|
Static analysis flagged the columns - 1 code, it was correct but the
assumption was not obvious. I document the assumption w/ assertions.
While digging through related code I found getColumnNumber that looks
wrong at first inspection and adding parentheses makes it clearer.
|
|
Due to it results in more losses than gains.
|
|
Support the following BCD format conversion builtins for PowerPC.
- `__builtin_bcdcopysign` – Conversion that returns the decimal value of
the first parameter combined with the sign code of the second parameter.
`
- `__builtin_bcdsetsign` – Conversion that sets the sign code of the
input parameter in packed decimal format.
> Note: This built-in function is valid only when all following
conditions are met:
> -qarch is set to utilize POWER9 technology.
> The bcd.h file is included.
## Prototypes
```c
vector unsigned char __builtin_bcdcopysign(vector unsigned char, vector unsigned char);
vector unsigned char __builtin_bcdsetsign(vector unsigned char, unsigned char);
```
## Usage Details
`__builtin_bcdsetsign`: Returns the packed decimal value of the first
parameter combined with the sign code.
The sign code is set according to the following rules:
- If the packed decimal value of the first parameter is positive, the
following rules apply:
- If the second parameter is 0, the sign code is set to 0xC.
- If the second parameter is 1, the sign code is set to 0xF.
- If the packed decimal value of the first parameter is negative, the
sign code is set to 0xD.
> notes:
> The second parameter can only be 0 or 1.
> You can determine whether a packed decimal value is positive or
negative as follows:
> - Packed decimal values with sign codes **0xA, 0xC, 0xE, or 0xF** are
interpreted as positive.
> - Packed decimal values with sign codes **0xB or 0xD** are interpreted
as negative.
---------
Co-authored-by: Aditi-Medhane <aditi.medhane@ibm.com>
|
|
This option is confusingly named. What it actually controls is whether,
under the default of `-ffloat16-excess-precision=standard`, it is
beneficial for performance to perform calculations on float (without
intermediate rounding) or not. For `-ffloat16-excess-precision=none` the
LLVM `half` type will always be used, and all backends are expected to
legalize it correctly.
|
|
Currently, `__attribute__((target("lasx")))` does not automatically
enable LSX support, causing Clang to fail with `-mno-lsx`. Since
LASX depends on LSX, enabling LASX should implicitly enable LSX to
avoid clang error.
Fixes #149512.
Depends on #153541
|
|
There should not be both `n8` and `n16:8`. This is a single list of
legal integers. Additionally, this should use the standard order in
increasing size `n8:16`.
|
|
(#152028)
Fix https://github.com/llvm/llvm-project/issues/151080
|
|
AMDGCN flavoured SPIRV should math AMDGPU TI as much as possible, and
the va_list difference was spurious.
|
|
2f497ec3a0056f15727ee6008211aeb2c4a8f455 updated the backend's rules for
when lock-free atomics are available, but we never made a corresponding
change to the frontend. Fix it to be consistent. This only affects
targets older than v7.
|
|
|
|
Handles clang::DiagnosticsEngine and clang::DiagnosticIDs.
For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to
convenience method `DiagnosticIDs::create()`.
Part of cleanup https://github.com/llvm/llvm-project/issues/151026
|
|
llvm::vfs::FileSystem. (#151407)
This switches to `makeIntrusiveRefCnt<FileSystem>` where creating a new
object, and to passing/returning by `IntrusiveRefCntPtr<FileSystem>`
instead of `FileSystem*` or `FileSystem&`, when dealing with existing
objects.
Part of cleanup #151026.
|
|
Also alphebetize feature list, add `-mgc` and `-mno-gc` flags, and add
some missing feature tests.
Reland of #151107.
https://github.com/llvm/llvm-project/pull/150201#discussion_r2237982637
|
|
(#151268)
Reverts llvm/llvm-project#151107
|
|
See suggestion here:
https://github.com/llvm/llvm-project/pull/150201#discussion_r2237982637
|
|
This patch removes getVirtualFile because it has been deprecated for
more than 10 months since:
commit b1aea98cfa357e23f4bb52232da5f41781f23bff
Author: Jan Svoboda <jan_svoboda@apple.com>
Date: Wed Sep 25 10:36:44 2024 -0700
I'm not aware of any downstream use AFAICT.
|
|
(#148141)
Fixes: SWDEV-541399
|
|
Depending on the particular version of the AArch32 architecture,
load/store exclusive operations might be available for various subset of
8, 16, 32, and 64-bit quantities. Sema knew nothing about this and was
accepting all four sizes, leading to a compiler crash at isel time if
you used a size not available on the target architecture.
Now the Sema checking stage emits a more sensible diagnostic, pointing
at the location in the code.
In order to allow Sema to query the set of supported sizes, I've moved
the enum of LDREX_x sizes out of its Arm-specific header into
`TargetInfo.h`.
Also, in order to allow the diagnostic to specify the correct list of
supported sizes, I've filled it with `%select{}`. (The alternative was
to make separate error messages for each different list of sizes.)
|
|
Tests if the runtime type of the function pointer matches the static
type. If this returns false, calling the function pointer will trap.
Uses `@llvm.wasm.ref.test.func` added in #147486.
Also adds a "gc" wasm feature to gate the use of the ref.test
instruction.
|
|
Reverts llvm/llvm-project#147959
|
|
report_fatal_error is not a good way to report diagnostics to the users, so this switches to using actual diagnostic reporting mechanisms instead.
Fixes #147187
|
|
FMV priority is the returned value of a polymorphic function. On RISC-V
and X86 targets a 32-bit value is enough. On AArch64 we currently need
64 bits and we will soon exceed that. APInt seems to be a suitable
replacement for uint64_t, presumably with minimal compile time overhead.
It allows bit manipulation, comparison and variable bit width.
|
|
The target triple x86_64-uefi must be assumed to have Microsft ABI by
default.
Fixes: https://github.com/llvm/llvm-project/issues/150113
|
|
Adding Loongarch64 to OpenBSD parts
|
