Follow on to #92460 (reporting old android builds failing) and #98264
(powerpc failing to discover gtests).
Getting back to stability by getting back down to a very basic set of
supported arches and OS's. In the future if there is demand we can build
it back up. Especially when I understand how to test these systems, or
have people who want to do the work on them.
---------
Co-authored-by: David Trevelyan <david.trevelyan@gmail.com>
We ran into a FE crash and root caused to `ER.get()` on line 5584 here
being nullptr. I think this is a result of not checking if ER here is
invalid.
Example of crash-on-valid C++
https://gist.github.com/yuxuanchen1997/576dce964666f0f8713fccacf5847138
Note that this crash happens only with `-std=c++20`.
This fixes formatting for durations using the unsigned types unsigned
short, unsigned, unsigned long, and unsigned long long. It does not
allow the unsigned char type. Since the formatting function uses
ostream::operator<< this type probably does not do what it should do.
Note that based on the standard all arithmetic types are allowed,
including bool, char, wchar_t. These types are not implemented either.
Allowing them seems like a defect in the Standard.
No effort is done to support user-defined types; the wording in the
Standard is unclear regarding the constrains for these types.
[LWG 4118](https://cplusplus.github.io/LWG/issue4118) discusses this
issue further.
Fixes https://github.com/llvm/llvm-project/issues/96820
This upcoming removal was recorded in the release notes for LLVM 19
as part of the deprecation of the C++20 synchronization library in
pre-C++20 modes, but wasn't included in "Upcoming Deprecations and Removals".
This patch ensures that the CI script controls which file extensions are
considered instead of letting git-clang-format apply its own filtering
rules. In particular, this properly handles libc++ extension-less
headers which were passed to git-clang-format, but then dropped by
the tool as having an unrecognized extension.
This is a second attempt to land 7620fe0d2d1e, which was reverted in
9572388 because it caused formatting not to be enforced for several patches.
The problem was that we'd incorrectly pass the extensions with additional
quoting to git-clang-format. The incorrect quoting has been removed in this
version of the patch.
This should disable the failing test on the ubuntu build bots
@JDevlieghere (I forgot to disable the 'baseline' test, as it tests the
debugger's basic handling of DWP files, but again, the API
infrastructure doesn't quite support DWP generation)
https://github.com/llvm/llvm-project/pull/98344#issuecomment-2221000566
Summary:
There's an extra argument that's required to *actually* enable f16
usage. For whatever reason there's a difference between fp16 and f16,
where fp16 is some weird version that converts between the two. Long
story short, without this the math builtins are blatantly broken.
When looking for a largest legal integer type for a target
`TargetLowering::findOptimalMemOpLowering` assumes that `MVT::i64` is
the largets possible integer type. The patch removes this assumption and
uses `MVT::LAST_INTEGER_VALUETYPE` instead.
Adjusting the name of the recurrence phi in the scalar loop is a bit
inconsistent, as we do not adjust any other names in the scalar loops
(including other phis).
Remove this adjustment in preparation for
https://github.com/llvm/llvm-project/pull/94760/ and as discussed there.
Some targets only pass a TargetMachine & to their subtarget constructor
and require a static_cast to their target-specific TargetMachine subclass
to create *InstructionSelector.
These 3 targets already have the correct TargetMachine subclass
reference so no cast is needed.
This helps compatibility with gcc, which has (static|shared)-libasan,
but not *-libsan.
Clang currently has
-shared-libasan
-shared-libsan
-static-libsan
This change improves consistency by adding
-static-libasan
The RefSCC that a function marked dead is in may still contain valid
SCCs that we want to visit. We rely on InvalidatedSCCs to skip SCCs
containing dead functions.
The addition of RefSCCs in CallGraphUpdater to InvalidatedRefSCCs was
causing asserts as reported in #94815. Fix some more CallGraphUpdater
function deletion methods as well.
This is the first step in being able to track the total profiled sizes
of allocations successfully marked as cold.
Under a new option -memprof-report-hinted-sizes:
- For unambiguous (non-context-sensitive) allocations, print the
profiled size and the allocation coldness, along with a hash of the
allocation's location (to allow for deduplication across modules or
inline instances).
- For context sensitive allocations, add the size as a 3rd operand on
the MIB metadata. A follow on patch will propagate this through to the
thin link where the sizes will be reported for each context after
cloning.
The default `dyld_chained_import` entry format only allocates 8 bits to
the library ordinal, of which values 0xF1 - 0xFF are reserved for
special ordinals (`BIND_SPECIAL_DYLIB_*` values). If there are more than
240 imported dylibs (as in the case of component builds of Chromium), we
need to switch to `dyld_chained_import_addend64`, which stores 16-bit
ordinals.
This is all the tests and fixes I've had percolating since my first
attempt at this in January. After 6 months of trying, I've given up on
adding the ability to test DWP files in LLDB API tests. I've left both
the tests (disabled) and the changes to Makefile.rules in place, in the
hopes that someone who can configure the build bots will be able to
enable the tests once a non-borked dwp tool is widely available.
Other than disabling the DWP tests, this continues to be the same diff
that I've tried to land and
[not](https://github.com/llvm/llvm-project/pull/90622)
[revert](https://github.com/llvm/llvm-project/pull/87676)
[five](https://github.com/llvm/llvm-project/pull/86812)
[times](https://github.com/llvm/llvm-project/pull/85693)
[before](https://github.com/llvm/llvm-project/pull/96802). There are a
couple of fixes that the testing exposed, and I've abandoned the DWP
tests because I want to get those fixes finally upstreamed, as without
them DebugInfoD is less useful.
before this change, we use an output parameter so
`UseAfterMoveFinder::find()` can return the found `UseAfterMove`, and
addition to it, `UseAfterMoveFinder::find()` return a bool, so we can
tell if a use-after-free is identified. this arrangement could be
confusing when one needs to understand when the each member variable of
the returned `UseAfterMove` instance is initialized.
in this change, we return an `std::optional<UseAfterMove>` instead of a
bool, so that it's more obvious on when/where the returned
`UseAfterMove` is initialized.
this change is a cleanup. so it does not change the behavior of this
check.
Signed-off-by: Kefu Chai <kefu.chai@scylladb.com>
This improves consistency in the trace files as other entries are
demangled too.
Submitted by jamieschmeiser on behalf of trass3r
@jamieschmeiser @An-DJ
Taint propagation is a a generic modeling feature of the Clang Static
Analyzer which many other checkers depend on. Therefore
GenericTaintChecker is split into a TaintPropagation modeling checker
and a GenericTaint reporting checker.
In order to define the format __cpp_lib_format to its initial value
(201907) these papers need to be completed:
- P0645R10 Text Formatting
- P1652R1 Printf corner cases in std::format
- 1361R2 Integration of chrono with text formatting The first two have
been implemented for a while the latter is almost done.
The next value (202106) requires:
- P2216R3 std::format improvements which has been implemented
The next value (202110) requires:
- P2418R2 Add support for std::generator-like types to std::format
- P2372R3 Fixing locale handling in chrono formatters The first one has
been implemented for a while the latter is almost done. The latter paper
is a DR against 1361R2 and both are implemented at the same time.
We've had user feedback that the missing of the __cpp_lib_format makes
their lives harder (https://github.com/llvm/llvm-project/issues/77773).
The missing papers 1361R2 and P2372R3 are very close to completion and
might completed before LLVM-19, but it will be a close call. This has
been discussed in the monthly libc++ meeting and we decided to set the
__cpp_lib_format so it will be set in LLVM-19.
Based on the discussion and the implementation status the
__cpp_lib_format is set to 202110.
Fixes#77773
[clang][ARM] Fix warning for using VFP from interrupts.
This warning has three issues:
- The interrupt attribute causes the function to return using an
exception
return instruction. This warning allows calls from one function with
the interrupt attribute to another, and the diagnostic text suggests
that not having the attribute on the callee is a problem. Actually
making such a call will lead to a double exception return, which is
unpredictable according to the ARM architecture manual section
B9.1.1, "Restrictions on exception return instructions". Even on
machines where an exception return from user/system mode is
tolerated, if the callee's interrupt type is anything other than a
supervisor call or secure monitor call, it will also return to a
different address than a normal function would. For example,
returning from an "IRQ" handler will return to lr - 4, which will
generally result in calling the same function again.
- The interrupt attribute currently does not cause caller-saved VFP
registers to be saved and restored if they are used, so putting
__attribute__((interrupt)) on a called function doesn't prevent it
from clobbering VFP state.
- It is part of the -Wextra diagnostic group and can't be individually
disabled when using -Wextra, which also means the diagnostic text of
this specific warning appears in the documentation of -Wextra.
This change addresses all three issues by instead generating a warning
for any interrupt handler where the vfp feature is enabled. The warning
is
also given its own diagnostic group.
Closes#34876.
[clang][ARM] Emit an error when an interrupt handler is called.
Closes#95359.
This patch addresses static analyzer concern where TSI could be
dereferenced after being assigned a null value from SubstType in
clang::TemplateDeclInstantiator::VisitUsingEnumDecl(clang::UsingEnumDecl
*).
The fix now checks null value of TSI after the call to SubstType and
return nullptr to prevent potential null pointer dereferences when
calling UsingEnumDecl::Create() and ensures safe execution.
The day is coming for creating the release branch for clang-19,
[scheduled](https://discourse.llvm.org/t/llvm-19-release-schedule-and-planning/79828)
for the 23rd of July.
Let's start syncing the ReleaseNotes, and be proud of what we achieved
since clang-18.
After this is merged, let's try to keep the ReleaseNotes in sync with
the changes.
`$ld$previous` symbols need to be exported for them to be seen by
clients. TAPI cannot omit them in tbd files, so account for this in
installapi verification when handling reexport verification.
Reviewed internally by Zixu Wang
resolves: rdar://131317591
Some cores implement an optimization for a strided load with an x0
stride, which results in fewer memory operations being performed then
implied by VL since all address are the same. It seems to be the case
that this is the case only for a minority of available implementations.
We know that sifive-x280 does, but sifive-p670 and spacemit-x60 both do
not.
(To be more precise, measurements on the x60 appear to indicate that a
stride of x0 has similar latency to a non-zero stride, and that both
are about twice a vleN.v. I'm taking this to mean the x0
case is not optimized.)
We had an existing flag by which a processor could opt out of this
assumption but no upstream users. Instead of adding this flag to the
p670 and x60, this patch reverses the default and adds the opt-in flag
only to the x280.
API Notes now support in C++. In preparation for supporting C++ methods
in API Notes, this change renames the remaining usages of
`ObjCContextABC` into `ContextABC` to make it clear that those contexts
might actually be C++, not Objective-C.
This is NFC-ish.
Clang 19 turned on sized deallocation *by default*, but older versions
of Clang did support sized deallocation nonetheless. This updates a few
comments and removes UNSUPPORTED annotations that shouldn't be needed in
a test that passes -fsized-deallocation directly.
This adds the *_NORM_MAX macros to <float.h> for freestanding mode in
Clang; the values were chosen based on the behavior seen coming from GCC
and the values already produced for the *_MAX macros by Clang.
Add a spec for yet-to-be-implemented metadata to allow the backend to
fully handle atomicrmw lowering. This is the base of an alternative
to #69229, which inverts the direction to be correct by default, and
extends to cover the peer device case.
The code that handled allocatable array had swapped `count` with
`upperBound`. This did not get caught earlier as all the example were
using 1 as `lowerBound`.
Fixes#98166.
With the fix in place, the GDB now correctly handles the case pointed in
the bug ticket.
(gdb) p min::alloc2d
$2 = ((0, 0, 0) (0, 0, 0) (0, 0, 0) (0, 0, 0) (0, 0, 0))
(gdb) ptype min::alloc2d
type = integer, allocatable (-1:1,-2:2)
The "26.3.1. Stack-Pointer-Based Loads and Stores" compressed opcodes
have access to all registers (except x0). Fix the opcode aliases with 0
offset so that the aliases also work for all registers, not only the RVC
registers.
Previously, LLVM would accept e.g. `c.lwsp x8, (sp)` but not e.g.
`c.lwsp x18, (sp)`, even though e.g. `c.lwsp x18, 0(sp)` would be
accepted.
This was noticed while implementing
https://github.com/llvm/llvm-project/pull/97925 . The implementation in
that other PR is indeed correct (i.e `qk.c.lhusp` et al are restricted
to the RVC registers).
Several operations from the EmitC dialect don't produce output directly
during emission, but rather when being used as an operand. These changes
unify the handling of such operations and fix a bug in the emission of
global ops.
Co-authored-by: Marius Brehler <marius.brehler@iml.fraunhofer.de>
This reverts commit 6f538f6a2d3224efda985e9eb09012fa4275ea92.
A number of crashes have been fixed by separate fixes, including
ttps://github.com/llvm/llvm-project/pull/96622. This version of the
PR also pre-computes the costs for branches (except the latch) instead
of computing their costs as part of costing of replicate regions, as
there may not be a direct correspondence between original branches and
number of replicate regions.
Original message:
This adds a new interface to compute the cost of recipes, VPBasicBlocks,
VPRegionBlocks and VPlan, initially falling back to the legacy cost model
for all recipes. Follow-up patches will gradually migrate recipes to
compute their own costs step-by-step.
It also adds getBestPlan function to LVP which computes the cost of all
VPlans and picks the most profitable one together with the most
profitable VF.
The VPlan selected by the VPlan cost model is executed and there is an
assert to catch cases where the VPlan cost model and the legacy cost
model disagree. Even though I checked a number of different build
configurations on AArch64 and X86, there may be some differences
that have been missed.
Additional discussions and context can be found in @arcbbb's
https://github.com/llvm/llvm-project/pull/67647 and
https://github.com/llvm/llvm-project/pull/67934 which is an earlier
version of the current PR.
PR: https://github.com/llvm/llvm-project/pull/92555
