AIX and OpenBSD seem to use -p. For most targets (at least FreeBSD and Linux),
-p is legacy (GCC freebsd has a warning). We don't want the uses to grow, so
making -p an alias for -pg is not recommended. I think the uses are small.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D138255
This patch:
- Adds target-feature and target-cpu to FC1Options.
- Moves getTargetFeatures() from Clang.cpp to CommonArgs.cpp.
- Processes target cpu and features in the flang driver. Right now
features are only added for AArch64/x86 because I only did basic
testing on them but it should generally work for others as well.
Option handling is similar to clang.
- Adds appropriate structures in TargetOptions and passes them to
the target machine.
What's missing:
- Adding the CPU info and the features as attributes in the LLVM IR
module.
- Processing target specific flags, e.g. SVE vector bits for AArch64,
ABI etc.
Differential Revision: https://reviews.llvm.org/D137995
Change-Id: Ib081a74ea98617674845518a5d2754edba596418
Enable frame pointer optimization by default to match it with other targets.
This brings a small reduction in generated binary sizes.
Fixes bug #48327
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138532
The OpenMP offloading toolchain uses wrapper headers to implement some
standard features on the GPU. Currently there is no way to turn these
off without also disabling all the standard includes altogether. This
patch makes `-nogpuinc` apply to these wrapper headers so we can use a
sterile toolchain. This was causing problems when attempting to compile
a `libc` for the GPU using OpenMP.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D138598
`-fapprox-func` should be disabled by `-fp-model={strict|precise}`,
as well as other fast-math flags. See the last changes in
`clang/test/Driver/fp-model.c`.
Probably this route (`case options::OPT_ffp_model_EQ`) was forgot
to update in D106191 and D114564. There is no appropriate reason not
to disable the flag.
This commit also updates other regression tests, which are not directly
related to this bug, for consistency with other fast-math flags.
Differential Revision: https://reviews.llvm.org/D138109
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.
So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.
Reviewed By: Bigcheese, dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D137609
-ffp-model=strict -ffp-model=fast will still enable strict exception
handling behavior, therefore clang still emits constrained FP operations
in IR.
-ffp-model=fast -ffp-model=strict emits two warnings: one for strict
overriding fast, the other for strict overriding strict, which is
confusing.
Reviewed By: zahiraam
Differential Revision: https://reviews.llvm.org/D137618
Add support for this GCC option which has the purpose of disallowing text
relative accesses of module local symbols with PIC. In effect, this changes
the code model to "medium".
Reviewed By: uweigand, efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D137044
flag. But the driver checks for 'fno-math-errno' before passing
'funsafe-math-optimizations' to the FE. In GCC, the option
'funsafe-math-optimizations' doesn't affect the 'fmath-errno' flag.
This patch aligns clang with GCC.
'-ffast-math' sets the FPContract to 'fast'. But 'funsafe-math-optimizations'
the driver doesn't consider the FPContract when handling the option.
Unfortunately there are places in the BE that interpret unsafe math
mode as allowing FMA. This patch makes -ffast-math' and
'funsafe-math-optimizations' behave similarly in regard to the setting of the
FPContract.
Differential Revision: https://reviews.llvm.org/D137578
For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
This patch enable `-sample-profile-use-profi` in Clang frontend as user-facing
feature. By using this patch, we can use the cflag of `-fsample-profile-use-profi`
instead of `-mllvm -sample-profile-use-profi`.
Reviewed By: hans, MaskRay
Differential Revision: https://reviews.llvm.org/D136846
We may need hosted Clang/LLVM to compile and `getHostCpuName`
can be used for native detection.
Tests are added in riscv-cpus.c just like what AArch64/PPC
have done.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D136930
The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir
Enable in clang: -Xclang -fexperimental-assignment-tracking
Enable in llvm tools: -experimental-assignment-tracking
When assignment tracking is enabled in clang it will pass on the flag to enable
the feature in lllvm. It's undefined behaviour to read IR that contains
assignment tracking metadata without specifying the feature flags.
Tests will come with later patches that add assignment tracking features.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D132221
In https://reviews.llvm.org/D80833, there were concerns about
determinism emitting the commandline into CodeView. We're actually
hitting these when running clang-cl on Linux (cross compiling) versus on
Windows (e.g. -fmessage-length being inferred on terminals).
Add -g[no-]codeview-command-line to enable/disable this feature.
It's still on by default to preserve the current state of clang.
Reviewed By: thakis, rnk
Differential Revision: https://reviews.llvm.org/D136474
Avoid calling getenv in the MC layer and let the clang driver do it so
that it is reflected in the command-line as an -mllvm option.
rdar://101558354
Differential Revision: https://reviews.llvm.org/D136888
Move the check for SOURCE_DATE_EPOCH to the driver and use a cc1 option
to pass it to the frontend. This avoids hidden state in the cc1
invocation and makes this env variable behave more like other env
variables that clang handles in the driver.
Differential Revision: https://reviews.llvm.org/D136717
We've been working around this for a long time in the Linux kernel; we
bend over backwards to continue to support CC=clang (w/
-fno-integrated-as) for architectures where clang can't yet be used to
assemble the kernel's assembler sources. Supporting debug info for the
combination of CC=clang w/ GNU binutils as "GAS" has been painful.
Fix this in clang so that we can work towards dropping complexity in the
Linux kernel's build system, Kbuild, for supporting this combination of
tools.
GAS added support for -gdwarf-{3|4|5} in 2020 2.35 release via
commit 31bf18645d98 ("Add support for --dwarf-[3|4|5] to assembler command line.")
Refactor code to share logic between integrated-as and non-integrated-as
for determining the implicit default. This change will now always
explicitly pass a -gdwarf-* flag to the GNU assembler when -g is
specified.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136707
Adds a `--extract-api-ignores=` command line option that allows users to
provide a file containing a new line separated list of symbols to
unconditionally ignore when extracting API information.
Differential Revision: https://reviews.llvm.org/D136450
On AIX, the default debugger is `dbx` so it is not necessary to explicitly set `-debugger-tuning=dbx` in the presence of `-g`.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D136187
This patch moves the judgement if the std c++ modules feature is enabled
into the RenderModulesOptions function. It simplify the code a little
bit further more. It also helps further patches.
D121868 provided support for -darwin-target-variant-triple, but the
support for -darwin-target-variant-sdk-version was still missing for
cc1as. These changes build upon the previous and provides such support.
- Extracted the common code to handle -darwin-target-variant-triple and
-darwin-target-variant-sdk-version in the Darwin toolchain to a method
that can be used for both the cc1 and the cc1as job construction.
cc1as does not support some of the parameters that were provided to
cc1, so the same code cannot be used for both.
- Invoke that new common code when constructing a cc1as invocation.
- Parse the new -darwin-target-variant-sdk-version in the cc1as driver.
Apply its value to the MCObjectFileInfo to generate the right values
in the object files.
- Includes two new tests that check that cc1as uses the provided values
in -darwin-target-variant-sdk and that the Clang driver creates the
jobs with the correct arguments.
Differential Revision: https://reviews.llvm.org/D135729
There are currently two options that are used to tell the compiler to perform
unsafe floating-point optimizations:
'-ffast-math' and '-funsafe-math-optimizations'.
'-ffast-math' is enabled by default. It automatically enables the driver option
'-menable-unsafe-fp-math'.
Below is a table illustrating the special operations enabled automatically by
'-ffast-math', '-funsafe-math-optimizations' and '-menable-unsafe-fp-math'
respectively.
Special Operations -ffast-math -funsafe-math-optimizations -menable-unsafe-fp-math
MathErrno 0 1 1
FiniteMathOnly 1 0 0
AllowFPReassoc 1 1 1
NoSignedZero 1 1 1
AllowRecip 1 1 1
ApproxFunc 1 1 1
RoundingMath 0 0 0
UnsafeFPMath 1 0 1
FPContract fast on on
'-ffast-math' enables '-fno-math-errno', '-ffinite-math-only',
'-funsafe-math-optimzations' and sets 'FpContract' to 'fast'. The driver option
'-menable-unsafe-fp-math' enables the same special options than
'-funsafe-math-optimizations'. This is redundant.
We propose to remove the driver option '-menable-unsafe-fp-math' and use
instead, the setting of the special operations to set the function attribute
'unsafe-fp-math'. This attribute will be enabled only if those special
operations are enabled and if 'FPContract' is either 'fast' or set to the
default value.
Differential Revision: https://reviews.llvm.org/D135097
On LoongArch, currently neither of "f" and "d" feature is passed from
clang driver to cc1 by default. This means the backend generates code
for soft float.
In order to run programs in current LoongArch machines (hard float
environment) this patch temporarily enables "f" and "d" features.
In future, we should conditionally turn on these features depend on
various clang options, e.g. -mdouble-float, -msingle-float,
-msoft-float and -mfpu.
Summary:
A previous patch ensured that we can't use `-foffload-lto` with CUDA in
non-RDC mode. This did not correctly check for if we were actually
offloading to CUDA so it ended up preventing us from using LTO for
OpenMP.
Summary:
This option forwards a clang flag with a `-no` variant to the Clang
compiler. It should use the `hasFlag` so it works properly when the
option is overridden.
The new driver supports LTO for RDC-mode compilations. However, this was
not correctly handled for non-LTO compilations. HIP can handle this as
it is fed to `lld` which will perform the LTO itself. CUDA however would
require every work which is wholly useless in non-RDC mode so it should
report an error.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D135305
Remove the ability to disable opaque pointers by default in clang.
It is still possible to explicitly disable them via cc1
-no-opaque-pointers.
Differential Revision: https://reviews.llvm.org/D135259
D103221 changed HIP's default to C++14, removing the driver logic to
force it into a different std.
Change-Id: I9f5220a7456687039b0bd3b3574f3124d3cc7665
Differential Revision: https://reviews.llvm.org/D134314
Change-Id: I40513f2ebe93ee53ea95c8bb3cc704487d970263
There are lots of options interacting in complex ways here, and when moving to
`getDefaultUnwindTableLevel` I had refactored this and changed behaviour in
some cases. So this reverts the basic structure of the logic back to the
original, while leaving the hook in the new style.
This cc1 option -fallow-half-arguments-and-returns allows __fp16 to be
passed by argument and returned, without giving an error. It is
currently always enabled for Arm and AArch64, by forcing the option in
the driver. This means any cc1 tests (especially those needing
arm_neon.h) need to specify the option too, to prevent the error from
being emitted.
This changes it to a target option instead, set to true for Arm and
AArch64. This allows the option to be removed. Previously it was implied
by -fnative_half_arguments_and_returns, which is set for certain
languages like open_cl, renderscript and hlsl, so that option now too
controls the errors. There were are few other non-arm uses of
-fallow-half-arguments-and-returns but I believe they were unnecessary.
The strictfp_builtins.c tests were converted from __fp16 to _Float16 to
avoid the issues.
Differential Revision: https://reviews.llvm.org/D133885
The /Zl flag omits default C runtime library name from obj files.
This patch just adds an equivalent clang driver flag.
Differential Revision: https://reviews.llvm.org/D133959
This can be used to disable vectorization and memcpy/memset
expansion for things like OS kernels. It also disables implicit
uses of scalar FP, but I don't know if we have any of those for
RISC-V.
NOTE: Without this patch you can still do -Xclang -no-implicit-float
Reviewed By: rui.zhang
Differential Revision: https://reviews.llvm.org/D134077
Having the flags only pass through if you're using the dxc-driver means
that the clang driver doesn't work for HLSL, which is undesirable. This
change switches to instead passing flags based on the language mode
similar to how OpenCL does it. This allows the clang driver to be used
for HLSL source files as well.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D133958
When ‘ffast-math’ is set, ffp-contract is altered this way:
-ffast-math/ Ofast -> ffp-contract=fast
-fno-fast-math -> if ffp-contract= fast then ffp-contract=on else
ffp-contract unchanged
This differs from gcc which doesn’t connect the two options.
Connecting these two options in clang, resulted in spurious warnings
when the user combines these two options -ffast-math -fno-fast-math; see
issue https://github.com/llvm/llvm-project/issues/54625.
The issue is that the ‘ffast-math’ option is an on/off flag, but the
‘ffp-contract’ is an on/off/fast flag. So when ‘fno-fast-math’ is used
there is no obvious value for ‘ffp-contract’. What should the value of
ffp-contract be for -ffp-contract=fast -fno-fast-math and -ffast-math
-ffp-contract=fast -fno-fast-math? The current logic sets ffp-contract
back to on in these cases. This doesn’t take into account that the value
of ffp-contract is modified by an explicit ffp-contract` option.
This patch is proposing a set of rules to apply when ffp-contract',
ffast-math and fno-fast-math are combined. These rules would give the
user the expected behavior and no diagnostic would be needed.
See RFC
https://discourse.llvm.org/t/rfc-making-ffast-math-option-unrelated-to-ffp-contract-option/61912
Previously, we linked in the ROCm device libraries which provide math
and other utility functions late. This is not stricly correct as this
library contains several flags that are only set per-TU, such as fast
math or denormalization. This patch changes this to pass the bitcode
libraries per-TU using the same method we use for the CUDA libraries.
This has the advantage that we correctly propagate attributes making
this implementation more correct. Additionally, many annoying unused
functions were not being fully removed during LTO. This lead to
erroneous warning messages and remarks on unused functions.
I am not sure if not finding these libraries should be a hard error. let
me know if it should be demoted to a warning saying that some device
utilities will not work without them.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D133726
Fangrui Song