With opaque pointers, it should no longer be necessary to protect
against recursion when converting Clang types to LLVM types, as
recursion can only be introduced via pointer types.
Differential Revision: https://reviews.llvm.org/D152999
s390x looks through pointers when determining the "externally
visible vector ABI". For that reason, the test shows different
behavior just on that platform.
Adjust the test in the reverse direction of what I originall did:
Make sure that the type behind the pointer is always queried, by
dereferencing the pointer.
When the diagnosed function/variable is a template specialization, the source range covers the specialization arguments.
e.g.
```
warning: unused function 'func<int>' [-Wunused-function]
template <> int func<int> () {}
^~~~~~~~~
```
This comes in line with the printed text in the warning message. In the above case, `func<int>`
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152707
When modules are disabled, there's no loaded module for these import
decls to point at. This results in crashes when there are modulemap
files but no -fmodules flag (this configuration is used for layering
check violations).
This patch makes sure import declarations are introduced only when
modules are enabled, which makes this case similar to textual headers
(no import decls are created for #include of textual headers from a
modulemap).
Differential Revision: https://reviews.llvm.org/D152274
The script build-for-llvm-top.sh and LLVM's ModuleInfo.txt are gone
since a long time (commit d20ea7dc59 in November 2011), and llvm-top
itself has even been removed from llvm-archive (it can be found here:
cab7f8f160/llvm-top
) so delete Clang's ModuleInfo.txt as well.
Differential Revision: https://reviews.llvm.org/D152995
Depends on D152138.
This is the 6th commit of the patch-set.
This patch makes the indexed segment store intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152139
Depends on D152137.
This is the 5th commit of the patch-set.
This patch makes the indexed segment load intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152138
Depends on D152136.
This is the 4th commit of the patch-set.
This patch makes the strided segment store intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152137
Depends on D152135.
This is the 3rd commit of the patch-set.
This patch makes the strided segment load intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152136
Depends on D152134.
This is the 2nd commit of the patch-set.
This patch makes the unit-stride segment store intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152135
Depends on D152079.
This patch-set aims to replace the existing segment load/store
intrinsics with tuple-type segment load/store intrinsics. That is, we
are removing in the segment load/store intrinsics.
This is the 1st commit of the patch-set.
This patch makes the unit-stride segment load intrinsics and
unit-stride fault-first segment load intrinsics to use tuple
types.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D152134
This reverts commit d80fdc6fc1a6e717af1bcd7a7313e65de433ba85.
split-dwarf-local-impor3.ll fails because of an issue with
Dwo sections emission on Windows platform.
RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544
Fixed PR51501 (tests from D112337).
1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).
DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.
This addresses various FIXMEs and simplifies the next part of the patch.
2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.
Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>
Differential Revision: https://reviews.llvm.org/D144004
This reverts commit ed578f02cf44a52adde16647150e7421f3ef70f3.
Tests llvm/test/DebugInfo/Generic/split-dwarf-local-import*.ll fail
when x86_64 target is not registered.
RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544
Fixed PR51501 (tests from D112337).
1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).
DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.
This addresses various FIXMEs and simplifies the next part of the patch.
2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.
Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>
Differential Revision: https://reviews.llvm.org/D144004
Now that we print >1 line of code snippet, we printed another line of
code for now reason, because the source range we created for the fixit
expanded to the next line, if the next token was there. Don't do that.
Differential Revision: https://reviews.llvm.org/D152525
RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544
Fixed PR51501 (tests from D112337).
1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).
DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.
This addresses various FIXMEs and simplifies the next part of the patch.
2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.
Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>
Differential Revision: https://reviews.llvm.org/D144004
There are static checks on the target identifiers allowed in a single
TU. Previously theses checks were only applied to HIP even though they
should be the same for OpenMP targeting AMDGPU. Simply enable these
checks for OpenMP.
Reviewed By: JonChesterfield, yaxunl
Differential Revision: https://reviews.llvm.org/D152965
An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structure type is not
actionable for users. This silences the false positive warning, which
matches the behavior of GCC as well.
We no longer diagnose if the structure has no members, or has only
zero-sized members (unnamed bit-fields, zero-sized bit-fields, empty
structure types).
Fixes: https://github.com/llvm/llvm-project/issues/26842
Provide direct access to v_exp_f32 and v_exp_f16, so we can start
correctly lowering the generic exp intrinsics.
Unfortunately have to break from the usual naming convention of
matching the instruction name and stripping the v_ prefix. exp is
already taken by the export intrinsic. On the clang builtin side, we
have a choice of maintaining the convention to the instruction name,
or following the intrinsic name.
This patch swaps out the `void *` behind `CXFile` from `FileEntry *` to `FileEntryRef::MapEntry *`. This allows us to remove some deprecated uses of `FileEntry::getName()`.
Depends on D151854.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151938
This finally officially deprecates `DirectoryEntry::getName()`. I checked no usages remain in targets built by any of `check-clang`, `check-clang-tools`, `check-clang-extra`. There are probably some remaining usages in places like LLDB and other clients. This will give them a chance to transition to `DirectoryEntryRef::getName()` before we remove the function altogether.
Depends on D151922.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151927
This patch removes the last use of deprecated `DirectoryEntry::getName()`.
Depends on D151855.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151922
This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change intended.
Depends on D151854.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151855
AArch64 has five system registers intended to be useful as thread
pointers: one for each exception level which is RW at that level and
inaccessible to lower ones, and the special TPIDRRO_EL0 which is
readable but not writable at EL0. AArch32 has three, corresponding to
the AArch64 ones that aren't specific to EL2 or EL3.
Currently clang supports only a subset of these registers, and not
even a consistent subset between AArch64 and AArch32:
- For AArch64, clang permits you to choose between the four TPIDR_ELn
thread registers, but not the fifth one, TPIDRRO_EL0.
- In AArch32, on the other hand, the //only// thread register you can
choose (apart from 'none, use a function call') is TPIDRURO, which
corresponds to (the bottom 32 bits of) AArch64's TPIDRRO_EL0.
So there is no thread register that you can currently use in both
targets!
For custom and bare-metal purposes, users might very reasonably want
to use any of these thread registers. There's no reason they shouldn't
all be supported as options, even if the default choices follow
existing practice on typical operating systems.
This commit extends the range of values acceptable to the `-mtp=`
clang option, so that you can specify any of these registers by (the
lower-case version of) their official names in the ArmARM:
- For AArch64: tpidr_el0, tpidrro_el0, tpidr_el1, tpidr_el2, tpidr_el3
- For AArch32: tpidrurw, tpidruro, tpidrprw
All existing values of the option are still supported and behave the
same as before. Defaults are also unchanged. No command line that
worked already should change behaviour as a result of this.
The new values for the `-mtp=` option have been agreed with Arm's gcc
developers (although I don't know whether they plan to implement them
in the near future).
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D152433
The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -
# RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.
# Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.
# Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.
# Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.
# If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.
# Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.
# To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py
Reviewed By: saiislam, ABataev
Differential Revision: https://reviews.llvm.org/D129635
(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)
In CGTypes, directly create opaque pointers, without computing the
LLVM element type. This is not as straightforward as I though it
would be, because apparently computing the LLVM type also causes a
number of side effects.
In particular, we no longer produce diagnostics like -Wpacked for
typed (only) behind pointers, because we no longer depend on their
layout.
Differential Revision: https://reviews.llvm.org/D152505
On Android GP register has been repurposed for SCS so there is no need to have .sdata section.
Reviewers: enh, craig.topper, pirama, kito-cheng, jrtc27
Differential Revision: https://reviews.llvm.org/D151512
The last use was removed by:
commit 46f366494f3ca8cc98daa6fb4f29c7c446c176b6
Author: Fangrui Song <i@maskray.me>
Date: Sat May 20 08:24:20 2023 -0700
This patch also removes RTTIProxyMap, which becomes unused once I
remove GetOrCreateRTTIProxyGlobalVariable.
Differential Revision: https://reviews.llvm.org/D152782
`desugarForDiagnostic` only sets ShouldAKA to true if desugaring
happens, otherwise ShouldAKA is left intact and might be uninitialized.
Victims (including me):
25bf8cb3c00e8384a0fe
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152880
HIP texture/image support is optional as some devices
do not have image instructions. A macro __HIP_NO_IMAGE_SUPPORT
is defined for device not supporting images (d0448aa4c4/docs/reference/kernel_language.md (L426) )
Currently the macro is defined by HIP header based on predefined macros
for GPU, e.g __gfx*__ , which is error prone. This patch let clang
emit the predefined macro.
Reviewed by: Matt Arsenault, Artem Belevich
Differential Revision: https://reviews.llvm.org/D151349
Breaks check-clang on win and mac, see comments on https://reviews.llvm.org/D150023
This reverts commit d8a36b00d198fdc2ea866ea5da449628db07070f.
Also revert follow-up "[NFC] skip the test modules-vtable.cppm on windows"
This reverts commit baf0b12ca6c624b2a59aa6f2fd0310c72d35ac56.
On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWARF 4
and earlier. For DWARF 5 we should generate .debug_names, but instead we
get no accelerator tables at all.
In the backend we are correctly determining that we should be emitting
.debug_names instead of .apple_names. However, when we get to the point
of emitting the section, if the CU debug name table kind is not
"default", the accelerator table emission is skipped.
This patch sets the DebugNameTableKind to Apple in the frontend when
target an Apple target. That way we know that the CU was compiled with
the intent of emitting accelerator tables. For DWARF 4 and earlier, that
means Apple accelerator tables. For DWARF 5 and later, that means .debug
names.
Differential revision: https://reviews.llvm.org/D118754
