This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.
The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.
Reviewed By: JonChesterfield, gregrodgers
Differential Revision: https://reviews.llvm.org/D99949
Darwin driver currently uses libc++ headers that are part of Clang
toolchain when available (by default ../include/c++/v1 relative to
executable), but it completely ignores the libc++ library itself
because it doesn't pass the location of libc++ library that's part
of Clang (by default ../lib relative to the exceutable) to the linker
always using the system copy of libc++.
This may lead to subtle issues when the compilation fails because the
headers that are part of Clang toolchain are incompatible with the
system library. Either the driver should ignore both headers as well as
the library, or it should always try to use both when available.
This patch changes the driver behavior to do the latter which seems more
reasonable, it makes it easy to test and use custom libc++ build on
Darwin while still allowing the use of system version. This also matches
the Clang driver behavior on other systems.
Differential Revision: https://reviews.llvm.org/D45639
This demotes the apple-a12 CPU selection for arm64e to just be the
last-resort default. Concretely, this means:
- an explicitly-specified -mcpu will override the arm64e default;
a user could potentially pick an invalid CPU that doesn't have
v8.3a support, but that's not a major problem anymore
- arm64e-apple-macos (and variants) will pick apple-m1 instead of
being forced to apple-a12.
apple-m1 has the same level of ISA support as apple-a14,
so this is a straightforward mechanical change. However, that
also means this inherits apple-a14's v8.5a+nobti quirkiness.
rdar://68287159
This is a user-facing option, so it doesn't make sense for it to be cc1
only.
Follow-up to D100420
Differential revision: https://reviews.llvm.org/D100759
In baremetal::Linker::ConstructJob, LinkerInput is handled prior to T_Group options,
but on the other side in RISCV::Linker::ConstructJob, it is opposite.
We want it to be consistent whether users are using RISCV::Linker or baremetal::Linker.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100615
This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.
The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.
Reviewed By: JonChesterfield, gregrodgers
Differential Revision: https://reviews.llvm.org/D99949
Test Plan: using kernel ASAN and MSAN implementations in FreeBSD
Reviewed By: emaste, dim, arichardson
Differential Revision: https://reviews.llvm.org/D98286
PATH usage on Windows is case-insensitive. There could be situations
when toolchain path can't be obtained from PATH because of
case-sensitivity of the findVCToolChainViaEnvironment.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D100361
https://lists.llvm.org/pipermail/openmp-dev/2021-March/003940.html reports
test failure in `openmp-offload-gpu.c`. The failure is, when using `-S` in the
clang driver, it still reports bitcode library doesn't exist. However, it is not
exposed in my local run and Phabiractor test. The reason it escaped from Phabricator
test is, the test machine doesn't have CUDA, so `LibDeviceFile` is empty. In this
case, the check of `OPT_S` will be hit, and we get "expected" result. However, if
the test machine has CUDA, `LibDeviceFile` will not be empty, then the check will
not be done, and it just proceeds, trying to add the bitcode library. The reason
it escaped from my local run is, I didn't build ALL targets, so this case was
marked UNSUPPORTED.
Reviewed By: kkwli0
Differential Revision: https://reviews.llvm.org/D98902
This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfortran. In Flang the preprocessor is always run. Instead,
`-cpp/-nocpp` are used to control whether predefined and command-line
preprocessor macro definitions are enabled or not. In practice this is
sufficient to model gfortran`s `-cpp/-nocpp`.
In the absence of `-cpp/-nocpp`, the driver will use the extension of
the input file to decide whether to include the standard macro
predefinitions. gfortran's documentation [1] was used to decide which
file extension to use for this.
The logic mentioned above was added in FrontendAction::BeginSourceFile.
That's relatively late in the driver set-up, but this roughly where the
name of the input file becomes available. The logic for deciding between
fixed and free form works in a similar way and was also moved to
FrontendAction::BeginSourceFile for consistency (and to reduce
code-duplication).
The `-cpp/-nocpp` flags are respected also when the input is read from
stdin. This is different to:
* gfortran (behaves as if `-cpp` was used)
* f18 (behaves as if `-nocpp` was used)
Starting with this patch, file extensions are significant and some test
files had to be renamed to reflect that. Where possible, preprocessor
tests were updated so that they can be shared between `f18` and
`flang-new`. This was implemented on top of adding new test for
`-cpp/-nocpp`.
[1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99292
This allows frontend and backend diagnostic files to all go into the
same place. Have it control the Windows (mini-)dump location.
Differential Revision: https://reviews.llvm.org/D99199
Programmers would like to be able to test direct methods by calling them from a
different linkage unit or mocking them, both of which are impossible. This
patch adds a flag that effectively disables the attribute, which will fix this
when enabled in testable builds. rdar://71190891
Differential revision: https://reviews.llvm.org/D95845
Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.
Solution:
This patch adds two new flags
- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.
Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.
So this is the behaviour per platform with my patch:
z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode
Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return
The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;
```
These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D99426
Take gcc-8 on Debian i386 as an example. The target-specific libstdc++ search
path (`GPLUSPLUS_TOOL_INCLUDE_DIR`) uses the multiarch name `i386-linux-gnu`,
instead of the triple of the GCC installation `i686-linux-gnu` (the directory
under `usr/lib/gcc/`):
```
/usr/include/c++/8
/usr/include/i386-linux-gnu/c++/8
/usr/include/c++/8/backward
```
Clang currently detects `/usr/lib/gcc/i686-linux-gnu/8/../../../include/i686-linux-gnu/c++/8`.
This patch changes the second i686-linux-gnu to i386-linux-gnu so that
`/usr/include/i386-linux-gnu/c++/8` can be found.
Fix PR49827 - this was somehow regressed by my previous libstdc++ include path
cleanups and fixes for gcc-cross, but it seems that the paths were never properly tested before.
Differential Revision: https://reviews.llvm.org/D99852
In order to bring up scalable vector support in LLVM incrementally,
we introduced behaviour to emit a warning, instead of an error, when
asking the wrong question of a scalable vector, like asking for the
fixed number of elements.
This patch puts that behaviour under a flag. The default behaviour is
that the compiler will always error, which means that all LLVM unit
tests and regression tests will now fail when a code-path is taken that
still uses the wrong interface.
The behaviour to demote an error to a warning can be individually enabled
for tools that want to support experimental use of scalable vectors.
This patch enables that behaviour when driving compilation from Clang.
This means that for users who want to try out scalable-vector support,
fixed-width codegen support, or build user-code with scalable vector
intrinsics, Clang will not crash and burn when the compiler encounters
such a case.
This allows us to do away with the following pattern in many of the SVE tests:
RUN: .... 2>%t
RUN: cat %t | FileCheck --check-prefix=WARN
WARN-NOT: warning: ...
The behaviour to emit warnings is only temporary and we expect this flag
to be removed in the future when scalable vector support is more stable.
This patch also has fixes the following tests:
unittests:
ScalableVectorMVTsTest.SizeQueries
SelectionDAGAddressAnalysisTest.unknownSizeFrameObjects
AArch64SelectionDAGTest.computeKnownBitsSVE_ZERO_EXTEND_VECTOR_INREG
regression tests:
Transforms/InstCombine/vscale_gep.ll
Reviewed By: paulwalker-arm, ctetreau
Differential Revision: https://reviews.llvm.org/D98856
For DBX, it does not handle column info well. Set -gno-column-info
by default for DBX.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D99703
Currently, support for the x32 ABI is handled as a multilib to the
x86_64 target only. However, full self-hosting x32 systems treating it
as a separate architecture with its own architecture triplets as well as
search paths exist as well, in Debian's x32 port and elsewhere.
This adds the missing architecture triplets and search paths so that
clang can work as a native compiler on x32, and updates the tests so
that they pass when using an x32 libdir suffix.
Additionally, we would previously also assume that objects from any
x86_64-linux-gnu GCC installation could be used to target x32. This
changes the logic so that only GCC installations that include x32
support are used when targetting x32, meaning x86_64-linux-gnux32 GCC
installations, and x86_64-linux-gnu and i686-linux-gnu GCC installations
that include x32 multilib support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D52050
Based on this debugger type, for now, we plan to:
1: use inline string by default for XCOFF DWARF
2: generate no column info for debug line table.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D99400
This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.
Differential Revision: https://reviews.llvm.org/D88452
This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR
should not conflict with the resource directory include so users should not
observe any difference.
This follows GCC. Having libstdc++/libc++ include paths is not useful
anyway because libstdc++/libc++ header files cannot find features.h.
While here, suppress -stdlib++-isystem with -nostdlibinc.
The contents of the string returned by getenv() is not guaranteed across calls to getenv(). The code to handle the CC_PRINT etc env vars calls getenv() and saves the results in just a char *. The string returned by getenv() needs to be copied and saved. Switching the type of the strings from char * to std::string will do this and manage the alloated memory.
Differential Revision: https://reviews.llvm.org/D98554
These contain clang driver changes for supporting HWASan on Fuchsia.
This includes hwasan multilibs and the dylib path change.
Differential Revision: https://reviews.llvm.org/D99361
Summary: Add -fno-split-stack and rename CC1 option from `-split-stacks`
to `-fsplit-stack`.
Test Plan: check-all
Differential Revision: https://reviews.llvm.org/D99245
This reverts commit aae84b8e39.
The chromium goma folks want to use a Debian sysroot without
lib/x86_64-linux-gnu to perform `clang -c` but no link action. The previous
commit has removed D.getVFS().exists check to make such usage work.
Not only can this save unneeded filesystem stats, it can make `clang
--sysroot=/path/to/debian-sysroot -c a.cc` work (get `-internal-isystem
$sysroot/usr/include/x86_64-linux-gnu`) even without `lib/x86_64-linux-gnu/`.
This should make thakis happy.
Functions specified in `-emscripten-cxx-exceptions-allowed`, which is
set by Emscripten's `EXCEPTION_CATCHING_ALLOWED` setting, can be inlined
in LLVM middle ends before we reach WebAssemblyLowerEmscriptenEHSjLj
pass in the wasm backend and thus don't get transformed for exception
catching.
This fixes the issue by adding `--force-attribute=FUNC_NAME:noinline`
for each function name in `-emscripten-cxx-exceptions-allowed`, which
adds `noinline` attribute to the specified function and thus excludes
the function from inlining candidates in optimization passes.
Fixes the remaining half of
https://github.com/emscripten-core/emscripten/issues/10721.
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D99259
This patch sets the OF_Text flag correctly for the json file created in Clang::DumpCompilationDatabaseFragmentToDir.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D99200
Files compiled with C++ for OpenCL mode can now have a distinct
file extension - clcpp, then clang driver picks the compilation
mode automatically (-x clcpp) without the use of -cl-std=clc++.
Differential Revision: https://reviews.llvm.org/D96771
Pushpinder Singh