This broke building the TSan runtime on Mac, see comment on
5548843d69
> so that they get an error on other targets. This change uses let statements to
> apply `Flags = [TargetSpecific]` to options (mostly -m*) without specifying `Flags`.
> Follow-up to D151590.
>
> For some options, e.g. -mdefault-build-attributes (D31813), -mbranch-likely
> (D38168), -mfpu=/-mabi= (6890b9b71e525020ab58d436336664beede71575), a warning
> seems desired in at least certain cases. This is not the best practice, but this
> change works around them by not applying `Flags = [TargetSpecific]`.
>
> (
> For Intel CPU errata -malign-branch= family options, we also drop the unneeded
> NotXarchOption flag. This flag reports an error if the option is used with
> -Xarch_*. This error reporting does not seem very useful.
> )
This reverts commit 5548843d692a92a7840f14002debc3cebcb3cdc3.
We would like to move the preamble index out of the critical path.
This patch is an RFC to get feedback on the correct implementation and potential pitfalls to keep into consideration.
I am not entirely sure if the lazy AST initialisation would create using Preamble AST in parallel. I tried with tsan enabled clangd but it seems to work OK (at least for the cases I tried)
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D148088
As explained by commit 849f1dd15e92fda2b83dbb6144e6b28b2cb946e0,
-fxray-function-index was the original default but was accidentally flipped by
commit d8a8e5d6240a1db809cd95106910358e69bbf299. Restore the previous behavior.
Originally reported by Oleksii Lozovskyi in D145848.
Apply my post-commit comment on D81995. The negative name misguided commit
d8a8e5d6240a1db809cd95106910358e69bbf299 (`[clang][cli] Remove marshalling from
Opt{In,Out}FFlag`) to:
* accidentally flip the option to not emit the xray_fn_idx section.
* change -fno-xray-function-index (instead of -fxray-function-index) to emit xray_fn_idx
This patch renames XRayOmitFunctionIndex and makes -fxray-function-index emit
xray_fn_idx, but the default remains -fno-xray-function-index .
Also add driver test missed by D87953 (-fxray-function-groups=).
(test/Driver/XRay/lit.local.cfg misunderstands how driver testing works.
We place the test in test/Driver instead.)
Fix https://github.com/llvm/llvm-project/issues/63237
With only a link action, we claim all CompileOnly_Group options (including -f*,
-m*, -i*, etc). -mharden-sls= is not in a Group and therefore not claimed,
leading to a spurious -Wunused-command-line-argument warning, and after
5548843d692a92a7840f14002debc3cebcb3cdc3, an error.
This is an alternative to currently existing hostcall implementation and uses printf buffer similar to OpenCL,
The data stored in the buffer (i.e the data frame) for each printf call are as follows,
1. Control DWord - contains info regarding stream, format string constness and size of data frame
2. Hash of the format string (if constant) else the format string itself
3. Printf arguments (each aligned to 8 byte boundary)
The format string Hash is generated using LLVM's MD5 Message-Digest Algorithm implementation and only low 64 bits are used.
The implementation still uses amdhsa metadata and hash is stored as part of format string itself to ensure
minimal changes in runtime.
Differential Revision: https://reviews.llvm.org/D150427
This commit implements support for WebAssembly table types and
respective builtins. Table tables are WebAssembly objects to store
reference types. They have a large amount of semantic restrictions
including, but not limited to, only being allowed to be declared
at the top-level as static arrays of zero-length. Not being arguments
or result of functions, not being stored ot memory, etc.
This commit introduces the __attribute__((wasm_table)) to attach to
arrays of WebAssembly reference types. And the following builtins to
manage tables:
* ref __builtin_wasm_table_get(table, idx)
* void __builtin_wasm_table_set(table, idx, ref)
* uint __builtin_wasm_table_size(table)
* uint __builtin_wasm_table_grow(table, ref, uint)
* void __builtin_wasm_table_fill(table, idx, ref, uint)
* void __builtin_wasm_table_copy(table, table, uint, uint, uint)
This commit also enables reference-types feature at bleeding-edge.
This is joint work with Alex Bradbury (@asb).
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D139010
After https://reviews.llvm.org/D151954 we've noticed some issues w/
clang-format behavior, as outlined in
https://github.com/llvm/llvm-project/issues/63170.
Valid C/C++ files, that were previously accepted, are now rejected by
clang-format, emitting the message:
"The new replacement overlaps with an existing replacement."
This reverts commit 4b9764959dc4b8783e18747c1742ab164e4bc4ee and
d2627cf88d2553a4c2e850430bdb908a4b7d2e52, which depends on it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D152473
so that they get an error on other targets. This change uses let statements to
apply `Flags = [TargetSpecific]` to options (mostly -m*) without specifying `Flags`.
Follow-up to D151590.
For some options, e.g. -mdefault-build-attributes (D31813), -mbranch-likely
(D38168), -mfpu=/-mabi= (6890b9b71e525020ab58d436336664beede71575), a warning
seems desired in at least certain cases. This is not the best practice, but this
change works around them by not applying `Flags = [TargetSpecific]`.
(
For Intel CPU errata -malign-branch= family options, we also drop the unneeded
NotXarchOption flag. This flag reports an error if the option is used with
-Xarch_*. This error reporting does not seem very useful.
)
This patch-set aims to expand all variants of the RVV segment
load/store intrinsics. The first commit expands the limitation of
builtin types from 256 to 512. The following patches expands the
full variants one-by-one.
The next patch introduces a number of new RVV tuple types and lets the
total of builtin types exceed the current limit (256). This patch
attempts to increase the bits used so we can continue to expand new
builtin types.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D152069
Recent expansion D152070 exceeds the limit and I had a hard time
triaging the bug because the overflow just creates unexpected
behaviors within the compiler.
This patch adds a static assertion to keep an eye for overflows when we
expand more types in the future.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152429
The first patch supported only LMUL=1 types. This patch supports
LMUL!=1.
LMUL is length multiplier that allows multiple vector registers to
be treated as one large register or a fraction of a single vector
register. Supported values for LMUL are 1/8, 1/4, 1/2, 1, 2, 4, and 8.
An LMUL=2 type will be twice as large as an LMUL=1 type. An LMUL=1/2
type will be half the size as an LMUL=1 type.
Type name with "m2" is LMUL=2, "m4" is LMUL=4.
Type name with "mf2" is LMUL=1/2, "mf4" is LMUL=1/4.
For the LMUL!=1 types the user will need to scale __riscv_v_fixed_vlen
by the LMUL before passing to the attribute.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D150926
so that we report `unsupported option '-G' for target ...` on
unsupported targets (most targets).
This error is tested by one target in aix-err-options.c.
Follow-up to D89897 and D90063.
Migration of clang tests to opaque pointers is finished, so remove
the -no-opaque-pointers flag.
Differential Revision: https://reviews.llvm.org/D152447
Adds an option KeepEmptyLinesAtEOF to keep empty lines (up to
MaxEmptyLinesToKeep) before EOF. This remedies the probably unintentional
change in behavior introduced in 3d3ea84a4f8f, which started to always
remove empty lines before EOF.
Fixes#56054.
Fixes#63150.
Differential Revision: https://reviews.llvm.org/D152305
Rename parameter in Sema::addInitCapture as proposed in review of Sema::addInitCapture. Sorry, that I have missed the comment there!
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D139541
Reasons for rolling forward:
- the crash reported from Chromium was fixed in D151824 (not related to this patch at all)
- since D152824 was committed, it should now be safe to roll this forward.
New change:
- add an additional _ in name check
This reverts commit 4980eead4d0b4666d53dad07afb091375b3a13a0.
This patch implemed the change proposed in [P2002R1] to 11.11.1 [class.compare.default] paragraph 1.
A defaulted compariosn operator function must be non-volatile and must either have no ref-qualifier or the ref-qualifier &.
Differential Revision: https://reviews.llvm.org/D148924
Some CPUs do not allow memory accesses to be unaligned, e.g. 2k1000la
who uses the la264 core on which misaligned access will trigger an
exception.
In this patch, a backend feature called `ual` is defined to decribe
whether the CPU supports unaligned memroy accesses. And this feature
can be toggled by clang options `-m[no-]unaligned-access` or the
aliases `-m[no-]strict-align`. When this feature is on,
`allowsMisalignedMemoryAccesses` sets the speed number to 1 and returns
true that allows the codegen to generate unaligned memory access insns.
Clang options `-m[no-]unaligned-access` are moved from `m_arm_Features_Group`
to `m_Group` because now more than one targets use them. And a test
is added to show that they remain unused on a target that does not
support them. In addition, to keep compatible with gcc, a new alias
`-mno-strict-align` is added which is equal to `-munaligned-access`.
The feature name `ual` is consistent with linux kernel [1] and the
output of `lscpu` or `/proc/cpuinfo` [2].
There is an `LLT` variant of `allowsMisalignedMemoryAccesses`, but
seems that curently it is only used in GlobalISel which LoongArch
doesn't support yet. So this variant is not implemented in this patch.
[1]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cpu.h#L77
[2]: https://github.com/torvalds/linux/blob/master/arch/loongarch/kernel/proc.c#L75
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D149946
This new representation means that a valid command line option may
potentially be used directly as a multilib flag without any translation.
To indicate that a flag is required not to be present, its first
character is replaced with '!', which is intended for consistency with
the logical not operator in many programming languages.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D151438
Decouple the interface of the MultilibBuilder flag method from how flags
are stored internally. Likewise change the addMultilibFlag function.
Currently a multilib flag like "-fexceptions" means a multilib is
*incompatible* with the -fexceptions command line option, which is
counter-intuitive. This change is a step towards changing this scheme.
Differential Revision: https://reviews.llvm.org/D151437
Elaborated types are sugar that represent how the type was spelled in
the original source. When printing a type outside of that original
context, the qualifiers as saved in the elaborated type will be
incorrect. Additionally, their existence also inhibits the use of
`PrintingCallbacks::isScopeVisible` as a customization point.
Differential Revision: https://reviews.llvm.org/D149677
The `TrackConstraintBRVisitor` should accept a message for the note
instead of creating one. It would let us inject domain-specific
knowledge in a non-intrusive way, leading to a more generic visitor.
Differential Revision: https://reviews.llvm.org/D152255
In https://reviews.llvm.org/D127762#4102578 @erichkeane suggested to
limit size of this field to 16bits, such that the field that encodes the
SME attributes for a function fall within the alignment of the struct for
32bit platforms.
Standard implimits defines the minimum handlers per try block to 256,
which suggests that 16bits should be more than sufficient for most
programs. Erich also pointed out that exception specs are being
deprecated and are rarely used, so hopefully this change is safe to make.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D152140
Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU
Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.
Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.
My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.
Fixes part of https://github.com/llvm/llvm-project/issues/55755
Differential Revision: https://reviews.llvm.org/D150902
The report of NULL stream was removed in commit 570bf97.
The old reason is not actual any more because the checker dependencies are changed.
It is not good to eliminate a failure state (where the stream is NULL) without
generating a bug report because other checkers are not able to find it later.
The checker did this with the NULL stream pointer, and because this checker
runs now before other checkers that can detect NULL pointers, the null pointer
bug was not found at all.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D152169
Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU
Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.
Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.
My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.
Fixes part of https://github.com/llvm/llvm-project/issues/55755
Differential Revision: https://reviews.llvm.org/D150902
_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.
This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.
This extension is also supported in C++ as we already supported
_Generic selection expressions there.
The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388
Differential Revision: https://reviews.llvm.org/D149904
[SystemZ} This revision fixes the following error caused by 301eb6b68f30074ee3a90e2dfbd11dfd87076323.
LLVM ERROR: IO failure on output stream: EDC5122I Input/output error.
The characters seems to be 3-byte characters which cause the failure with auto conversion from EBCDIC to ASCII.
Credit to @Kai who found this issue.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D152016
The corresponding function definition was removed by:
commit f634c9006977fcbed5f55eaee831852e453fdf76
Author: Richard Smith <richard-llvm@metafoo.co.uk>
Date: Fri Mar 16 06:12:59 2012 +0000
The last use was removed by:
commit 603cd869f7cdb0da7a545e86a1786f3175f72475
Author: Douglas Gregor <dgregor@apple.com>
Date: Fri Mar 22 18:50:14 2013 +0000
With only a link action, we claim all CompileOnly_Group options (including -f*,
-m*, -i*, etc). It makes sense to claim -nostdinc family options as well.
We can achieve this by placing these options into IncludePath_Group, a derivative of
CompileOnly_Group.
Reviewed By: theuni
Differential Revision: https://reviews.llvm.org/D151944
In review for https://reviews.llvm.org/D146278, @vzakhari asked to
separate -emit-fir and -emit-hlfir. This will allow FIR to be easily
outputted after the HLFIR passes have been run.
The new semantics are as follows:
| Action | -flang-experimental-hlfir? | Result |
| =========== | ========================== | =============================== |
| -emit-hlfir | N | Outputs HLFIR |
| -emit-hlfir | Y | Outputs HLFIR |
| -emit-fir | N | Outputs FIR, using old lowering |
| -emit-fir | Y | Outputs FIR, lowering via HLFIR |
A patch for bbc will follow.
Differential Revision: https://reviews.llvm.org/D151088
