As suggested in review (see: #149425), I believed that using single
quotes was a nicer quoting scheme that correctly handled paths with
spaces. Alas, build bot failures have demonstrated that this is not the
case.
Revert to the original quoting scheme (see: #146749).
(cherry picked from commit 73ce0aca72348a80dc2c2175516a0993ab8d6be3)
We allowed implicit this access when checking associated constraints
after CWG2369. As a result, some of the invalid function call
expressions were not properly SFINAE'ed out and ended up as hard errors
at evaluation time.
We tried fixing that by mucking around the CurContext, but that spawned
additional breakages and I think it's probably safe to revert to the
previous behavior to avoid churns.
Though there is CWG2589, which justifies the previous change, it's not
what we're pursuing now.
Fixes https://github.com/llvm/llvm-project/issues/151271
Fixes https://github.com/llvm/llvm-project/issues/145505
Add a language option flag for experimental lifetime safety analysis in C++.
This change provides a language option to control the experimental lifetime safety analysis feature, making it more explicit and easier to enable/disable. Previously, the feature was controlled indirectly through a diagnostic warning flag, which we do not want to accidentally enable with `-Weverything` (atm)!
- Added a new language option `EnableLifetimeSafety` in `LangOptions.def` for experimental lifetime safety analysis in C++
- Added corresponding driver options `-fexperimental-lifetime-safety` and `-fno-experimental-lifetime-safety` in `Options.td`
- Modified `AnalysisBasedWarnings.cpp` to use the new language option flag instead of checking if a specific diagnostic is ignored
- Updated a test case to use the new flag instead of relying on the warning flag alone
(cherry picked from commit 0d0478903474b2e53c874427e3d6eb2ed7567e50)
The original wording can be squinted at to pretend this was always
allowed. GCC squints at it that way, so we're doing the same and no
longer issuing an extension diagnostic for use of static_assert in the
condition-1 of a for loop in C.
Fixes#149633
(cherry picked from commit cb50d78a0063244434d883d89ddda7f74abbffc9)
I was attempting to build openblas with clang in msys2's `ucrt64`
environment (I'm aware of the `clang64` environment, but I wanted
libstdc++). The openblas link failed with the following:
```
clang -march=native -mtune=native -m64 -O2 -fno-asynchronous-unwind-tables -O2 -DSMALL_MATRIX_OPT -DMS_ABI -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -DDYNAMIC_ARCH -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=512 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.29\" -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I.. libopenblas64_.def dllinit.obj \
-shared -o ../libopenblas64_.dll -Wl,--out-implib,../libopenblas64_.dll.a \
-Wl,--whole-archive ../libopenblas64_p-r0.3.29.a -Wl,--no-whole-archive -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0 -LC:/msys64/ucrt64/bin/../lib/gcc -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../x86_64-w64-mingw32/lib/../lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../x86_64-w64-mingw32/lib -LC:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../.. -lgfortran -lmingwex -lmsvcrt -lquadmath -lm -lpthread -lmingwex -lmsvcrt -defaultlib:advapi32 -lgfortran -defaultlib:advapi32 -lgfortran
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-pseudo-reloc.o): in function `__report_error':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/pseudo-reloc.c:157:(.text+0x59): undefined reference to `abort'
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-tlsthrd.o): in function `___w64_mingwthr_add_key_dtor':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/tlsthrd.c:48:(.text+0xa5): undefined reference to `calloc'
C:/msys64/ucrt64/bin/ld: C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.1.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-pesect.o): in function `_FindPESectionByName':
D:/W/B/src/mingw-w64/mingw-w64-crt/crt/pesect.c:79:(.text+0xfd): undefined reference to `strncmp'
```
These symbols come from the `-lmingw32` dep that the driver added and
are ordinarily found in `-lmsvcrt`, which got skipped here, because
openblas passed `-lmsvcrt` explicitly earlier in the link line. Since we
always add these libraries at the end here, I think that clang is "at
fault" (as opposed to a user or packaging mistake) and should have added
some crt here.
To preserve the intent of letting the user override which crt is chosen,
duplicate the (first) user chosen crt `-l` into this position, although
we should perhaps consider an explicit `-mcrtdll` like gcc has as well.
(cherry picked from commit 7f470586e10543aa12efc7e04d4d4ac814eaca35)
The current assertion failure messages produced by Hardening are not
very grep-friendly (the common part is rarther generic and requires
wildcards to match). While it's possible to use `__FILE__` for grepping,
it's easier and more straighforward to simply add a libc++-specific
prefix; this is especially important for the planned `observe` mode that
might produce many assertion failure messages over the course of the
program's execution that later need to be filtered and examined.
(cherry picked from commit 4ef92469ab341ac1bee39a9413ffaa845e307414)
The point of reentrant capabilities is that they can be acquired
multiple times, so they should probably be excluded from requiring a
negative capability on acquisition via -Wthread-safety-negative.
However, we still propagate explicit negative requirements.
(cherry picked from commit a048aeb06e5de571eadd646860c320b9a67d1efc)
The [Google C++ Style
Guide](https://google.github.io/styleguide/cppguide.html#Pointer_and_Reference_Expressions)
is being changed to specify that spaces should go after the
asterisk/ampersand, rather than permitting either before or after on a
file-by-file basis.
The new requirement is:
> When referring to a pointer or reference (variable declarations or
> definitions, arguments, return types, template parameters, etc.),
> you must not place a space before the asterisk/ampersand. Use a
> space to separate the type from the declared name (if present).
The [Google ObjC
style](https://google.github.io/styleguide/objcguide.html) is silent on
this matter, but the de-facto style is not being modified at this time.
So, keep DerivePointerAlignment enabled for ObjC language mode.
(cherry picked from commit 9281797a577b7954521fb9192d41e457ca2ca42e)
In LoongArch, we try GOT indirection to PC relative optimization in
normal or medium code model, whether or not with R_LARCH_RELAX
relocation.
From:
* pcalau12i $a0, %got_pc_hi20(sym_got)
* ld.w/d $a0, $a0, %got_pc_lo12(sym_got)
To:
* pcalau12i $a0, %pc_hi20(sym)
* addi.w/d $a0, $a0, %pc_lo12(sym)
If the original code sequence can be relaxed into a single instruction
`pcaddi`, this patch will not be taken (see
https://github.com/llvm/llvm-project/pull/123566).
The optimization related to GOT is split into two locations because the
`relax()` function is part of an iteration fixed-point algorithm. We
should minimize it to achieve better linker performance.
Note: Althouth the optimization has been performed, the GOT entries
still exists, similarly to AArch64. Eliminating the entries will
increase code complexity.
(cherry picked from commit 283c47b4c5231a1baf528355f7119a73ac168968)
This patch fixes incorrect behavior in Clang where [[noreturn]] (either
spelled or inferred) was being inherited by explicit specializations of
function templates or member function templates, even when those
specializations returned normally.
Follow up on https://github.com/llvm/llvm-project/pull/145166
(cherry picked from commit 22fef005225b129d73ade4ed995fc0ec0c7be044)
glibc 2.42 made all usage of termios ioctl constants strictly internal
Therefore, we remove all usage for those removed constants.
This should only apply for Linux.
Fix#149103
Reference:
3d3572f590
@fweimer-rh @tstellar
(cherry picked from commit 0a17483c481d82eace3b36aee9cacb619eb027af)
This patch adds support for bitcode members of thin archives to DTLTO
(https://llvm.org/docs/DTLTO.html) in ELF LLD.
For DTLTO, bitcode identifiers must be valid paths to bitcode files on
disk. Clang does not support archive inputs for ThinLTO backend
compilations. This patch adjusts the identifier for bitcode members of
thin archives in DTLTO links so that it is the path to the member file
on disk, allowing such members to be supported in DTLTO.
This patch is sufficient to allow for self-hosting an LLVM build with
DTLTO when thin archives are used.
Note: Bitcode members of non-thin archives remain unsupported. This will
be addressed in a future change.
Testing:
- LLD lit test coverage has been added to check that the identifier is
adjusted appropriately.
- A cross-project lit test has been added to show that a DTLTO link can
succeed when linking bitcode members of thin archives.
For the design discussion of the DTLTO feature, see: #126654.
(cherry picked from commit 673476d96bed306be6ed81a8174f481a9a4b2934)
As the COFF linker is usually invoked independently, update the Clang
DTLTO section to show an example. This follows what is done earlier in
the document.
Also some minor fixes and improvements:
- Use generic distributor names to avoid implying anything about what an
Incredibuild distributor may or should support.
- Use subheadings for readability.
- Correct a mis-cased hyperlink.
(cherry picked from commit c129d65995babf8bf56499c3f8b9b6df073190ef)
Update docs to state that reduction is supported on OpenMP `loop` and
`teams` standalone and compound constructs.
(cherry picked from commit 15980624ac516ae2dbbf1f2cd24d63de0f9fd2be)
Linker relaxation to R_LARCH_GOT_PC_{HI20,LO12} is only possible when
the addend of the relocation is zero.
Note: For `ld.bfd`, GOT references with non-zero addends will trigger an
assert in LoongArch, but `lld` handles these cases without any errors.
```
ld.bfd: BFD (GNU Binutils) 2.44.0 assertion fail
/usr/src/debug/binutils/binutils-gdb/bfd/elfnn-loongarch.c:4248
```
(cherry picked from commit 4ec8503e4c480f52426ddd03619b017f19a2f452)
When searching for noreturn variable initializations, do not visit CFG
blocks that are already visited, it prevents hanging the analysis.
It must fix https://github.com/llvm/llvm-project/issues/150336.
(cherry picked from commit 330b40e11fd20e9a29b9c24de17e4ba23afeedc6)
COFF associative sections is a feature where relocatable object files
can have section snippets marked as related to another section snippet,
so they are kept or discarded in relation to that other section snippet.
When llvm-objcopy removes sections, it also removes sections that are
marked as associative to the removed section (as the associative
sections otherwise would end up orphaned).
In a linked executable module (EXE or DLL), section associativity is
meaningless - thus, we should ignore those fields from the input.
After linking, GNU ld keeps the SectionDefinition auxillary part of
symbols intact as it was in the source object file, which means that it
references section numbers in the source object files.
This fixes https://github.com/llvm/llvm-project/issues/53433.
(cherry picked from commit fcbbcffd2e6ea30097809ba0cd1e3b6003fa862f)
Previously we saved registers in the shadow space of callee before
calling __delayLoadHelper2. Now we save arguments in the shadow space of
the caller and allocate shadow space for the callee.
Fixes#51941
---------
Co-authored-by: Benjamin Santerre <benjamin.santerre@gmail.com>
(cherry picked from commit 75b79c9238bc083cdff2d2364be40633fdf4d1ad)
An enumeration is compatible with its underlying type, which means that
code like the following should be accepted:
struct A { int h; };
void func() {
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
because the structures are declared in different scopes, the two
declarations of 'x' are both compatible.
Note, the structural equivalence checker does not take scope into
account, but that is something the C standard requires. This means we
are accepting code we should be rejecting per the standard, like:
void func() {
struct A { int h; };
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
Because the structures are declared in the same scope, the type
compatibility rule require the structures to use the same types, not
merely compatible ones.
Fixes#149965
(cherry picked from commit 315e2e28b13285a352d409b739ba31fb453d661b)
This adds download links to the GitHub release pages for common
platforms. The automatically built packages' links are automatically
revealed once the builds are complete. For packages built by hand,
hidden links are included in the text for release uploaders to reveal
later.
The approach taken:
* "LLVM x.y.z Release" becomes the title for this links section.
* Automatically built packages are commented out with special markers so
we can find them to uncomment them later.
* There is placeholder text for the time between release creation and
release tasks finishing.
* Hand built packages have release links but these will need to be
un-commented by release uploaders.
* I have used vendor names for the architectures, that casual users
would recognise.
* Their signature file is linked as well. I expect most will ignore this
but better to show it to remind people it exists.
* I called it "signature" as a generic term to cover the .jsonl and .sig
files. Instructions to use these were added to the text in a previous
change.
(cherry picked from commit e8b7183d866f9d51511d5570f5f1f632046ef983)
This controls whether tag checking is performed for loads and
stores, or stores only.
It requires a specific architecture feature which we detect
with a HWCAP3 and cpuinfo feature.
Live process tests look for this and adjust expectations
accordingly, core file tests are using an updated file with
this feature enabled.
The size of the core file has increased and there's nothing
I can do about that. Could be the presence of new architecure
features or kernel changes since I last generated them.
I can generate a smaller file that has the tag segment,
but that segment does not actually contain tag data. So
that's no use.
(cherry picked from commit 0209e76fe6440bc45a9ed61b9671d9593db10957)
This will be used to detect the presence of Arm's new Memory Tagging
store only checking feature. This commit just adds the plumbing to get
that value into the detection function.
FreeBSD has not allocated a number for HWCAP3 and already has AT_ARGV
defined as 29. So instead of attempting to read from FreeBSD processes,
I've explicitly passed 0. We don't want to be reading some other entry
accidentally.
If/when FreeBSD adds HWCAP3 we can handle it like we do for
AUXV_FREEBSD_AT_HWCAP.
No extra tests here, those will be coming with the next change for MTE
support.
(cherry picked from commit d26ca8b87266024546501051ccaf75cb3756aee3)
When `ptrauth_calls` is present but `ptrauth_init_fini` is not, compiler
emits raw unsigned pointers in `.init_array`/`.fini_array` sections.
Previously, `__do_init`/`__do_fini` pointers, which are explicitly added
to the sections, were implicitly signed (due to the presense of
`ptrauth_calls`), while all the other pointers in the sections were
implicitly added by the compiler and thus non-signed.. As a result, the
sections contained a mix of unsigned function pointers and function
pointers signed with default signing schema.
This patch introduces use of inline assembly for this particular case,
so we can manually specify that we do not want to sign the pointers.
Note that we cannot use `__builtin_ptrauth_strip` for this purpose since
its result is not a constant expression.
(cherry picked from commit 19ba224fb8a925d095d84836bc9896bf564dfd99)
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
(cherry picked from commit 3eee9fc2c4d1973904b1a26fa96a8c7473ef6a5e)
On COFF platform, d1b0cbff806b50d399826e79b9a53e4726c21302 generates
a debug info linked with VTable even if that is dllimport-ed. That
causes an access violation while performing runtime pseudo-relocation
if the debug section is stripped.
For the release branch, we simply disable VTable debug info on COFF
platform to avoid this problem.
Fixes#149639
Clang's current implementation only works on array types, but GCC (which
is where we got this attribute) supports it on pointers as well as
arrays.
Fixes#150951
(cherry picked from commit 837b2d464ff16fe0d892dcf2827747c97dd5465e)
If a chunk is empty and there are no other non-empty chunks in the same
section, `removeEmptySections()` will remove the entire section. In this
case, use a section index of 0, as the MSVC linker does, instead of
asserting.
(cherry picked from commit 1ab04fc94c5f68ad0dc6755e3914f2895b85e720)
The synthesized deduction guides use injected template arguments for
distinguishment of explicit and implicit deduction guides.
In partial ordering, we may substitute into these injected types when
checking consistency. Properly substituting them needs the instantiated
class template specializations which isn't the case at that point. So
instead, we check their template specialization types.
No release note because I think we want a backport, after baking it for
a couple of days.
Fixes https://github.com/llvm/llvm-project/issues/134613
(cherry picked from commit 07faafe4a4d0a5bd82b648aa9717783f001ddfae)
The i386 psABI specifies that `__float128` has 16 byte alignment and
must be passed on the stack; however, LLVM currently stores it in a
stack slot that has an offset of 4. Add a custom lowering to correct
this alignment to 16-byte.
i386 does not specify an `__int128`, but it seems reasonable to keep the
same behavior as `__float128` so this is changed as well. There also
isn't a good way to distinguish whether a set of four registers came
from an integer or a float.
The main test demonstrating this change is `store_perturbed` in
`llvm/test/CodeGen/X86/i128-fp128-abi.ll`.
Referenced ABI:
https://gitlab.com/x86-psABIs/i386-ABI/-/wikis/uploads/14c05f1b1e156e0e46b61bfa7c1df1e2/intel386-psABI-2020-08-07.pdf
Fixes: https://github.com/llvm/llvm-project/issues/77401
(cherry picked from commit a78a0f8d204393a0cce367b63395bad90311c1b8)
This change fixes an issue with the use of `-alternatename` in the MSVC
CRT on ARM64EC, where both mangled and demangled symbol names are
specified. Without this patch, the demangled name could be resolved to
an anti-dependency alias of the target. Since chaining anti-dependency
aliases is not allowed, this results in an undefined symbol.
The root cause isn't specific to ARM64EC, it can affect other targets as
well, even when anti-dependency aliases aren't involved. The
accompanying test case demonstrates a scenario where the symbol could be
resolved from an archive. However, because the archive member is pulled
in after the first pass of alternate name resolution, and archive
members don't override weak aliases, eager resolution would incorrectly
skip it.
(cherry picked from commit ac31d64a64e8a648f6834f4cf9de10c56c8d1083)
Like in other places, ignore the reference type of the base. (It might
make sense to refactor this at some point.)
Fixes#150015.
(cherry picked from commit bba846773c7dfce0f95b8846672d8dd5fa8912be)
These float operations were expanded for scalar f32/f64/f128, but not
for f16 and more problematically, not for vectors. A small subset of
them was separately set to expand for vectors.
Change these to always expand by default, and adjust targets to mark
these as legal where necessary instead.
This is a much safer default, and avoids unnecessary legalization
failures because a target failed to manually mark them as expand.
Fixes https://github.com/llvm/llvm-project/issues/110753.
Fixes https://github.com/llvm/llvm-project/issues/121390.
(cherry picked from commit fe0dbe0f2950d95071be7140c7b4680f17a7ac4e)
This fixes the following build warnings in a mingw environment:
../../lldb/source/Host/windows/MainLoopWindows.cpp:226:50: warning:
format specifies type 'int' but the argument has type
'IOObject::WaitableHandle' (aka 'void *') [-Wformat]
226 | "File descriptor %d already monitored.", waitable_handle);
| ~~ ^~~~~~~~~~~~~~~
../../lldb/source/Host/windows/MainLoopWindows.cpp:239:49: warning:
format specifies type 'int' but the argument has type 'DWORD' (aka
'unsigned long') [-Wformat]
238 | error = Status::FromErrorStringWithFormat("Unsupported file type
%d",
| ~~
| %lu
239 | file_type);
| ^~~~~~~~~
2 warnings generated.
(cherry picked from commit 98ec927fcb8697a6f6df64298835917aa1d0d3c1)
While investigating PR #149990, I noticed that while both the Oracle
Studio compilers and GCC default to `-mv8plus` on 32-bit Solaris/SPARC,
Clang does not.
This patch fixes this by enabling the `v8plus` feature.
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
(cherry picked from commit 06233892e84f96a3b4e05338cd4f6c12b8f5a185)
