Commit Graph

90469 Commits

Author SHA1 Message Date
Jon Chesterfield 06cdf48a0d [openmp] Drop test from D109057, disproportionately difficult to run on windows 2021-09-01 21:51:51 +01:00
Jon Chesterfield c7cbf1a03e [openmp] Accept directory for libomptarget-bc-path
The commandline flag to specify a particular openmp devicertl library
currently errors like:
```
fatal error: cannot open file
      './runtimes/runtimes-bins/openmp/libomptarget':
      Is a directory
```
CommonArgs successfully appends the directory to the commandline args then
mlink-builtin-bitcode rejects it.

This patch is a point fix to that. If --libomptarget-amdgcn-bc-path=directory
then append the expected name for the current architecture and go on as before.
This is useful for test runners that don't hardcode the architecture.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D109057
2021-09-01 21:22:35 +01:00
Duncan P. N. Exon Smith 8976a1e111 VFS: Document goals of 'use-external-name' and related logic, NFC
Document 'use-external-name' and the various bits of logic that make it
work, to avoid others having to repeat the archival work (given that I
added getFileRefReturnsCorrectNameForDifferentStatPath to
FileManagerTest, seems possible I understood this once before!).

- b59cf679e8 added 'use-external-name' to
  RedirectingFileSystem. This causes `stat`s to return the external
  name for a redirected file instead of the name it was accessed by,
  leaking it through the VFS.
- d066d4c849 propagated the external name
  further through clang::FileManager.
- 4dc5573acc, which added
  clang::FileEntryRef to clang::FileManager, has complicated concession
  to account for this as well (since refactored a bit).

The goal of 'use-external-name' is to enable Clang to report "real" file
paths to users (via diagnostics) and to external tools (such as
debuggers reading debug info and build systems reading `.d` files).

I've added FIXMEs to look at other channels for communicating the
external names, since the current implementation adds complexity to
FileManager and exposes an inconsistent interface to clients.

Besides that, the FileManager logic appears to be kicking in outside of
'use-external-name'. Seems that *some* vfs::FileSystem implementations
canonicalize some paths returned by `stat` in *some* cases (the bug
isn't fully understood yet). Volodymyr Sapsai is investigating, this at
least better documents what *is* understood.
2021-09-01 15:55:33 -04:00
Jon Chesterfield 6b0636ce53 Revert "[openmp] Accept directory for libomptarget-bc-path"
Windows separator problem. Fixing that broke another regex.
This reverts commit 0173e024fd.
2021-09-01 20:45:41 +01:00
Jon Chesterfield cef1199686 Revert "[openmp] No longer use LIBRARY_PATH to find devicertl"
This reverts commit 7a228f872f.
Failing test case under CI
2021-09-01 20:44:12 +01:00
Jon Chesterfield 88511f6bc5 [libomptarget] Drop path separator from test to fix windows build 2021-09-01 20:34:58 +01:00
Jon Chesterfield 7a228f872f [openmp] No longer use LIBRARY_PATH to find devicertl
Given D109057, change test runner to use the libomptarget-x-bc-path
argument instead of the LIBRARY_PATH environment variable to find the device
library.

Also drop the use of LIBRARY_PATH environment variable as it is far
too easy to pull in the device library from an unrelated toolchain by accident
with the current setup. No loss in flexibility to developers as the clang
commandline used here is still available.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D109061
2021-09-01 20:24:34 +01:00
Nico Weber 3d157cfcc4 [clang] Add a -canonical-prefixes option
In https://reviews.llvm.org/D47480 I complained that there's no positive
form of this flag, so let's add one :)

https://gcc.gnu.org/PR29931 also has a pending patch to add the positive
form to gcc (but there's admittedly not a lot of movement on that bug).

This doesn't change any defaults.

Differential Revision: https://reviews.llvm.org/D108818
2021-09-01 14:51:06 -04:00
Jon Chesterfield 0173e024fd [openmp] Accept directory for libomptarget-bc-path
The commandline flag to specify a particular openmp devicertl library
currently errors like:
```
fatal error: cannot open file
      './runtimes/runtimes-bins/openmp/libomptarget':
      Is a directory
```
CommonArgs successfully appends the directory to the commandline args then
mlink-builtin-bitcode rejects it.

This patch is a point fix to that. If --libomptarget-amdgcn-bc-path=directory
then append the expected name for the current architecture and go on as before.
This is useful for test runners that don't hardcode the architecture.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D109057
2021-09-01 19:46:21 +01:00
Erich Keane 42ae7eb581 Ensure field-annotations on pointers properly match the AS of the field.
Discovered in SYCL, the field annotations were always cast to an i8*,
which is an invalid bitcast for a pointer type with an address space.
This patch makes sure that we create an intrinsic that takes a pointer
to the correct address-space and properly do our casts.

Differential Revision: https://reviews.llvm.org/D109003
2021-09-01 06:12:24 -07:00
Nico Weber 9b6c8132d3 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit f0514a4d26.
Test fails on macOS: https://reviews.llvm.org/D107049#2976603
2021-09-01 08:35:33 -04:00
Zahira Ammarguellat cec7c2b32e Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"
The intent of this patch is to add support of -fp-model=[source|double|extended] to allow
the compiler to use a wider type for intermediate floating point calculations. As a side
effect to that, the value of FLT_EVAL_METHOD is changed according to the pragma
float_control.
Unfortunately some issue was uncovered with this change in preprocessing. See details in
https://reviews.llvm.org/D93769 . We are therefore reverting this patch until we find a way
to reconcile the value of FLT_EVAL_METHOD, the pragma and the -E flow.

This reverts commit 66ddac22e2.
2021-09-01 04:48:50 -07:00
Saiyedul Islam 83f3782c61 [clang-nvlink-wrapper] Wrapper around nvlink for archive files
nvlink does not support linking of cubin files archived in an archive.
 This tool extracts all the cubin files in the given device specific archive
 and pass them to nvlink. It is required for linking static device libraries
 for nvptx.

 Reviewed By: ye-luo

 Differential Revision: https://reviews.llvm.org/D108291
2021-09-01 16:00:29 +05:30
Vassil Vassilev f0514a4d26 Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message:"
  The current infrastructure in lib/Interpreter has a tool, clang-repl, very
  similar to clang-interpreter which also allows incremental compilation.

  This patch moves clang-interpreter as a test case and drops it as conditionally
  built example as we already have clang-repl in place.

  Differential revision: https://reviews.llvm.org/D107049
"

This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
2021-09-01 10:21:38 +00:00
Justas Janickas fb321c2ea2 [OpenCL] Define OpenCL 3.0 optional core features in C++ for OpenCL 2021
Modifies OpenCL 3.0 optional core feature macro definitions so that
they are set analogously in C++ for OpenCL 2021.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.

Differential Revision: https://reviews.llvm.org/D108704
2021-09-01 10:15:17 +01:00
Vassil Vassilev 04bbd189a9 Revert "[clang-repl] Re-implement clang-interpreter as a test case."
This reverts commit 319ce98011 because it fails
on various platforms.
2021-09-01 06:49:52 +00:00
Anton Afanasyev ff780014b2 [Test][Time profiler] Fix test time checking
This test sometimes triggers failures during build testing. For instance, see:
https://lab.llvm.org/buildbot/#/builders/52/builds/10161, details: https://lab.llvm.org/buildbot/#/builders/52/builds/10161/steps/5/logs/FAIL__Clang__check-time-trace-sections_cpp .
AFAICT the time between driver calling and checking its time tracker output
is not guaranteed to be stable and small:
```
> head -2 check-time-trace-sections.cpp
// RUN: %clangxx -S -ftime-trace -ftime-trace-granularity=0 -o %T/check-time-trace-sections %s
// RUN: cat %T/check-time-trace-sections.json | %python %S/check-time-trace-sections.py
> clang -S -ftime-trace -ftime-trace-granularity=0 -o /tmp/check check-time-trace-sections.cpp
> cat /tmp/check.json | python check-time-trace-sections.py
> sleep 10
> cat /tmp/check.json | python check-time-trace-sections.py
'beginningOfTime' should represent the absolute time when the process has started
>
```
The attribute `beginningOfTime` was introduced here: https://reviews.llvm.org/D78030
One can change "10 sec" value to something longer, but I believe
it's enough just to check that `beginningOfTime` exists and is
not later than current time.

Differential Revision: https://reviews.llvm.org/D108625
2021-09-01 09:11:36 +03:00
Vassil Vassilev 319ce98011 [clang-repl] Re-implement clang-interpreter as a test case.
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.

This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.

Differential revision: https://reviews.llvm.org/D107049
2021-09-01 05:23:21 +00:00
Joel E. Denny 83ddfa0d22 [OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2)
This patch implements Clang support for an original OpenMP extension
we have developed to support OpenACC: the `ompx_hold` map type
modifier.  The next patch in this series, D106510, implements OpenMP
runtime support.

Consider the following example:

```
 #pragma omp target data map(ompx_hold, tofrom: x) // holds onto mapping of x
 {
   foo(); // might have map(delete: x)
   #pragma omp target map(present, alloc: x) // x is guaranteed to be present
   printf("%d\n", x);
 }
```

The `ompx_hold` map type modifier above specifies that the `target
data` directive holds onto the mapping for `x` throughout the
associated region regardless of any `target exit data` directives
executed during the call to `foo`.  Thus, the presence assertion for
`x` at the enclosed `target` construct cannot fail.  (As usual, the
standard OpenMP reference count for `x` must also reach zero before
the data is unmapped.)

Justification for inclusion in Clang and LLVM's OpenMP runtime:

* The `ompx_hold` modifier supports OpenACC functionality (structured
  reference count) that cannot be achieved in standard OpenMP, as of
  5.1.
* The runtime implementation for `ompx_hold` (next patch) will thus be
  used by Flang's OpenACC support.
* The Clang implementation for `ompx_hold` (this patch) as well as the
  runtime implementation are required for the Clang OpenACC support
  being developed as part of the ECP Clacc project, which translates
  OpenACC to OpenMP at the directive AST level.  These patches are the
  first step in upstreaming OpenACC functionality from Clacc.
* The Clang implementation for `ompx_hold` is also used by the tests
  in the runtime implementation.  That syntactic support makes the
  tests more readable than low-level runtime calls can.  Moreover,
  upstream Flang and Clang do not yet support OpenACC syntax
  sufficiently for writing the tests.
* More generally, the Clang implementation enables a clean separation
  of concerns between OpenACC and OpenMP development in LLVM.  That
  is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's
  extended OpenMP implementation and test suite without directly
  considering OpenACC's language and execution model, which can be
  handled by LLVM's OpenACC developers.
* OpenMP users might find the `ompx_hold` modifier useful, as in the
  above example.

See new documentation introduced by this patch in `openmp/docs` for
more detail on the functionality of this extension and its
relationship with OpenACC.  For example, it explains how the runtime
must support two reference counts, as specified by OpenACC.

Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new
command-line option introduced by this patch, is specified.

Reviewed By: ABataev, jdoerfert, protze.joachim, grokos

Differential Revision: https://reviews.llvm.org/D106509
2021-08-31 16:13:49 -04:00
Yaron Keren 10d78a06ba [llvm-lit] unbreak clang-only builds by not assuming llvm-lit in build dir
Reviewed By: tstellar

Differential Revision: https://reviews.llvm.org/D109000
2021-08-31 18:57:47 +03:00
Kazu Hirata b8debabb77 [clang] Remove redundant calls to c_str() (NFC)
Identified with readability-redundant-string-cstr.
2021-08-31 08:53:51 -07:00
Fanbo Meng ae206db2d6 [SystemZ][z/OS] Create html report file with text flag
Change OF_None to OF_Text flag in file creation, same reasoning as https://reviews.llvm.org/D97785

Reviewed By: abhina.sreeskantharajan

Differential Revision: https://reviews.llvm.org/D108998
2021-08-31 11:52:04 -04:00
Vassil Vassilev c9948e9254 [clang-repl] Install clang-repl
This is essentially what D106813 was supposed to do but did not.

Differential revision: https://reviews.llvm.org/D108919
2021-08-31 15:20:15 +00:00
Justas Janickas f9bc1b3bee [OpenCL] Defines helper function for kernel language compatible OpenCL version
This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapping between
C++ for OpenCL versions and their corresponding compatible OpenCL
versions. This mapping function should be updated each time a new
C++ for OpenCL language version is introduced. The helper function
is expected to simplify conditions on OpenCL C and C++ for OpenCL
versions inside compiler code.

Code refactoring performed.

Differential Revision: https://reviews.llvm.org/D108693
2021-08-31 10:08:38 +01:00
Shivam Gupta e01ac501af Fix typo in two files in Clang, patch by FusionBolt
Reviewed By: xgupta

Differential Revision: https://reviews.llvm.org/D98254
2021-08-31 12:33:37 +05:30
Shivam Gupta 4a6d8a11f8 [clang] Fix Typo in AST Matcher Reference
In [[ https://clang.llvm.org/docs/LibASTMatchersReference.html | AST Matcher Reference]], the example of matcher `hasDeclContext` contained a typo.

`cxxRcordDecl` was changed to `cxxRecordDecl`.

Differential Revision: https://reviews.llvm.org/D102836
2021-08-31 12:21:47 +05:30
David Blaikie 4f3a92ca0a DebugInfo: Refactor/deduplicate various template argument list emission
Streamline template arguments across types, variables, and functions -
for convenient reuse in experiments related to template argument list
reconstitution (not including template argument lists in the "name" of
those entities, and leaving it to debug info consumers to rebuild the
full template name from the semantic descriptions of the argument lists)

But the change seems like a good refactoring/cleanup anyway.

I'd certainly be open to suggestions about how this might be more
streamlined - like is there no generic way to query template argument
lists across the 3 kinds of entities, rather than needing special case
code?
2021-08-30 22:39:46 -07:00
Volodymyr Sapsai 93764ff6e2 [modules] Fix miscompilation when using two RecordDecl definitions with the same name.
When deserializing a RecordDecl we don't enforce that redeclaration
chain contains only a single definition. So if the canonical decl is not
a definition itself, `RecordType::getDecl` can return different objects
before and after an include. It means we can build CGRecordLayout for
one RecordDecl with its set of FieldDecl but try to use it with
FieldDecl belonging to a different RecordDecl. With assertions enabled
it results in

> Assertion failed: (FieldInfo.count(FD) && "Invalid field for record!"),
> function getLLVMFieldNo, file llvm-project/clang/lib/CodeGen/CGRecordLayout.h, line 199.

and with assertions disabled a bunch of fields are treated as their
memory is located at offset 0.

Fix by keeping the first encountered RecordDecl definition and marking
the subsequent ones as non-definitions. Also need to merge FieldDecl
properly, so that `getPrimaryMergedDecl` works correctly and during name
lookup we don't treat fields from same-name RecordDecl as ambiguous.

rdar://80184238

Differential Revision: https://reviews.llvm.org/D106994
2021-08-30 17:51:38 -07:00
Ellis Hoag 47b239eb5a [DIBuilder] Do not replace empty enum types
It looks like this array was missed in 4276d4a8d0

Fixed tests that expected `elements` to be empty or depeneded on the order of the empty DINode.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D107024
2021-08-30 12:33:03 -07:00
David Blaikie 0e42ec1add DebugInfo: Correct printing empty template parameter packs
Empty packs in the non-final position would result in an extra ", ".
Empty packs in the final position would result in missing the space
between trailing >>.
2021-08-30 10:20:12 -07:00
Andrei Elovikov 1724a16437 [NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp
...that is located under llvm/lib/Support/.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D108423
2021-08-30 09:48:48 -07:00
Victor Huang 2e5c17d19e [PowerPC][NFC] Rename P10 builtins vec_clrl, vec_clrr to vec_clr_first and vec_clr_last
This patch renames the vector clear left/right builtins vec_clrl, vec_clrr to
vec_clr_first and vec_clr_last to avoid the ambiguities when dealing with endianness.

Reviewed By: amyk, lei

Differential revision: https://reviews.llvm.org/D108702
2021-08-30 09:52:15 -05:00
Simon Moll a5791badde [clang] Add gcc-toolset-10 support (RHEL/CentOS 8)
Clang only adds GCC paths for RHEL <= 7 'devtoolset-<N>' Software
Collections (SCL).  This generalizes this support to also include the
'gcc-toolset-10' SCL in RHEL/CentOS 8.

Reviewed By: stephan.dollberg

Differential Revision: https://reviews.llvm.org/D108908
2021-08-30 13:33:30 +02:00
Wang, Pengfei ab40dbfe03 [X86] AVX512FP16 instructions enabling 6/6
Enable FP16 complex FMA instructions.

Ref.: https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html

Reviewed By: LuoYuanke

Differential Revision: https://reviews.llvm.org/D105269
2021-08-30 13:08:45 +08:00
Xiang1 Zhang 80f7ce8993 [X86] Support __SSC_MARK(const int id)
Differential Revision: https://reviews.llvm.org/D108682
2021-08-30 09:55:35 +08:00
Xiang1 Zhang 4c29dc18cf Revert "[X86] Support __SSC_MARK(const int id)"
This reverts commit 78fbde5779.
2021-08-30 09:50:26 +08:00
Steven Wan 71b170ccf3 [AIX] "aligned" attribute does not decrease alignment
The "aligned" attribute can only increase the alignment of a struct, or struct member, unless it's used together with the "packed" attribute, or used as a part of a typedef, in which case, the "aligned" attribute can both increase and decrease alignment.

That said, we expect:
1. "aligned" attribute alone: does not interfere with the alignment upgrade instrumented by the AIX "power" alignment rule,
2. "aligned" attribute + typedef: overrides any computed alignment,
3. "aligned" attribute + "packed" attribute: overrides any computed alignment.
The old implementation achieved 2 and 3, but didn't get 1 right, in that any field marked attribute "aligned" would not go through the alignment upgrade.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D107394
2021-08-29 21:33:05 -04:00
Xiang1 Zhang 78fbde5779 [X86] Support __SSC_MARK(const int id)
Differential Revision: https://reviews.llvm.org/D108682
2021-08-30 09:21:22 +08:00
Xiang1 Zhang fd88fac6ca Revert "[X86] Support __SSC_MARK(const int id)"
This reverts commit 83e82ff767.
2021-08-30 09:18:27 +08:00
Xiang1 Zhang 83e82ff767 [X86] Support __SSC_MARK(const int id)
Differential Revision: https://reviews.llvm.org/D108682
2021-08-30 08:51:20 +08:00
owenca 4b1fde8a2b [clang-format] Add PackConstructorInitializers backward compat test
Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine to
PackConstructorInitializers.

Differential Revision: https://reviews.llvm.org/D108882
2021-08-29 13:47:11 -07:00
Steven Wan 73733ae526 TypeInfo records more information about align requirement
Extend the information preserved in `TypeInfo` by replacing the `AlignIsRequired` bool flag with a three-valued enum, the enum also indicates where the alignment attribute come from, which could be helpful in determining whether the attribute should overrule.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D108858
2021-08-28 19:47:48 -04:00
Ben Barham a4a5c00b53 [Modules] Change result of reading AST block to llvm::Error instead
Reading the AST block can never fail with a recoverable error as modules
cannot be removed during this phase. Change the return type of these
functions to return an llvm::Error instead, ie. either success or
failure.

NFC other than the wording of some of the errors.

Differential Revision: https://reviews.llvm.org/D108268
2021-08-27 20:16:20 -07:00
David Blaikie 32b280809f TypePrinter:printTo remove redundant parameter (IsPack/SkipBrackets) 2021-08-27 17:12:42 -07:00
owenca 170a3c6f7a [clang-format] Fix AllowAllConstructorInitializersOnNextLine value
The default value of the now deprecated
AllowAllConstructorInitializersOnNextLine was always true
regardless of the value of BasedOnStyle. This patch fixes the typo
in the code that handles the related backward compatibility.
2021-08-27 14:47:49 -07:00
owenca 696e7905a1 [clang-format] [NFC] Fix the coding style of unit tests header file 2021-08-27 14:25:38 -07:00
mydeveloperday ed367b9dff [clang-format] [PR51640] - New AfterEnum brace wrapping changes have cause C# behaviour to change
LLVM 13.0.0-rc2 shows change of behaviour in enum and interface BraceWrapping (likely before we simply didn't wrap)  but may be related to {D99840}

Logged as https://bugs.llvm.org/show_bug.cgi?id=51640

This change ensure AfterEnum works for

`internal|public|protected|private enum A {`  in the same way as it works for `enum A {` in C++

A similar issue was also observed with `interface` in C#

Reviewed By: krasimir, owenpan

Differential Revision: https://reviews.llvm.org/D108810
2021-08-27 19:13:53 +01:00
Johannes Doerfert 2930c839a5 [OpenMP][FIX] Allow declare variant to work with reference types
Reference types in the return or parameter position did cause the OpenMP
declare variant overload reasoning to give up. We should allow them as
we allow any other type.

This should fix the bug reported on the mailing list:
https://lists.llvm.org/pipermail/openmp-dev/2021-August/004094.html

Reviewed By: ABataev, pdhaliwal

Differential Revision: https://reviews.llvm.org/D108774
2021-08-27 13:12:14 -05:00
Jason Liu fe177a1773 Fix assertion when passing function into inline asm's input operand
This seem to be a regression caused by this change:
https://reviews.llvm.org/D60943.
Since we delayed report the error, we would run into some invalid
state in clang and llvm.

Without this fix, clang would assert when passing function into
inline asm's input operand.

Differential Revision: https://reviews.llvm.org/D107941
2021-08-27 13:39:41 -04:00
Fanbo Meng 9d7a77c26d [MCParser][z/OS] Mark test as unsupported for the z/OS Target
Marking test as unsupported for the same reason as https://reviews.llvm.org/D105204

Reviewed By: abhina.sreeskantharajan

Differential Revision: https://reviews.llvm.org/D108819
2021-08-27 11:45:38 -04:00