[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Paulo Matos via Phabricator via cfe-commits]

pmatos marked an inline comment as done.
pmatos added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:2258
+Width = 0; 
\
+Align = 8; /* ? */ 
\
+break;

pmatos wrote:
> tlively wrote:
> > I assume things will break if you say 0 here, but would 1 work?
> Yes, 1 seems to work. I am not 100% sure but since externref cannot be 
> written to memory, does it matter?
Nope... I take that back. `builtins-wasm.c` seems to break with anything under 
8 with the error: 

```
clang: /home/pmatos/dev/llvm-project/llvm/include/llvm/Support/Alignment.h:77: 
llvm::Align::Align(uint64_t): Assertion `Value > 0 && "Value must not be 0"' 
failed.
```

Still need to investigate why a value of `Align = 1;` here ends up causing a 
zero alignment value in `Alignment.h`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122215/new/

https://reviews.llvm.org/D122215

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peixin Qiao via Phabricator via cfe-commits]

peixin added inline comments.



Comment at: flang/test/Driver/emit-mlir.f90:16
 ! CHECK-NEXT: }
+! CHECK-NEXT: fir.global @_QQEnvironmentDefaults constant : 
!fir.ref, 
!fir.ref> {
+! CHECK-NEXT:  %[[VAL_0:.*]] = fir.zero_bits !fir.ref, !fir.ref>

jpenix-quic wrote:
> peixin wrote:
> > jpenix-quic wrote:
> > > peixin wrote:
> > > > jpenix-quic wrote:
> > > > > peixin wrote:
> > > > > > Is it possible not to generated this global variable if `fconvert=` 
> > > > > > is not specified?
> > > > > I'm not entirely sure--the issue I was running into was how to handle 
> > > > > this in Fortran_main.c in a way which worked for all of 
> > > > > GCC/Clang/Visual Studio (and maybe others?). I was originally 
> > > > > thinking of doing this by using a weak definition of 
> > > > > _QQEnvironmentDefaults set to nullptr so fconvert, etc. could 
> > > > > override this definition without explicitly generating the fallback 
> > > > > case. For GCC/clang, I think I could use __attribute__((weak)), but I 
> > > > > wasn't sure how to handle this if someone tried to build with Visual 
> > > > > Studio (or maybe another toolchain). I saw a few workarounds (ex: 
> > > > > https://devblogs.microsoft.com/oldnewthing/20200731-00/?p=104024) but 
> > > > > I shied away from this since it seems to be an undocumented feature 
> > > > > (and presumably only helps with Visual Studio). 
> > > > > 
> > > > > Do you know of a better or more general way I could do this? (Or, is 
> > > > > there non-weak symbol approach that might be better that I'm missing?)
> > > > How about generate one runtime function with the argument of 
> > > > `EnvironmentDefaultList`? This will avoid this and using one extern 
> > > > variable?
> > > > 
> > > > If users use one variable with bind C name `_QQEnvironmentDefaults` in 
> > > > fortran or one variable with name `_QQEnvironmentDefaults` in C, it is 
> > > > risky. Would using the runtime function and static variable with the 
> > > > type `EnvironmentDefaultList` in runtime be safer?
> > > Agreed that there are potential risks with the current approach 
> > > (although, are the `_Q*` names considered reserved?). Unfortunately, I 
> > > think generating a call to set the environment defaults requires somewhat 
> > > significant changes to the runtime. The runtime reads environment 
> > > variables during initialization in `ExecutionEnvironment::Configure` 
> > > which is ultimately called from the "hardcoded" `Fortran_main.c` and I 
> > > need to set the defaults before this happens. So, I believe I'd either 
> > > have to move the initialization to `_QQmain`  or make it so that `main` 
> > > isn't hardcoded so that I could insert the appropriate runtime function.
> > > 
> > > @klausler I think I asked you about this when I was first trying to 
> > > figure out how to implement the environment defaults and you suggested I 
> > > try the extern approach--please let me know if you have 
> > > thoughts/suggestions around this!
> > This is what @klausler suggested:
> > ```
> > Instead of adding new custom APIs that let command-line options control 
> > behavior in a way that is redundant with the runtime environment, I suggest 
> > that you try a more general runtime library API by which the main program 
> > can specify a default environment variable setting, or a set of them. Then 
> > turn the command-line options into the equivalent environment settings and 
> > pass them as default settings that could be overridden by the actual 
> > environment.
> > ```
> > If I understand correctly, what I am suggesting match his comments. The 
> > "main program" he means should be fortran main program, not the 
> > `RTNAME(ProgramStart`. In your initial patch, you add the runtime specified 
> > for "convert option". I think @klausler suggest you making the runtime 
> > argument more general used for a set of runtime environment variable 
> > settings, not restricted to "convert option". And that is what you already 
> > added -- `EnvironmentDefaultList`. So, combining this patch and your 
> > initial patch will be the solution. Hope I understand it correctly.
> The issue I hit with the suggested approach is that in order to use the 
> pre-existing runtime environment variable handling to set the internal state 
> I need to set the environment variable defaults before the environment 
> variables are read by the runtime.
> 
> I might be misunderstanding/missing something, but given that the environment 
> variables are read as part of `RTNAME(ProgramStart)` in `main` and the 
> earliest I can place the call if I am generating it is `_QQmain`, I think 
> that leaves three options: 1. don't hardcode `main` so that I can place the 
> call early enough 2. delay or rerun the code [[ 
> https://github.com/llvm/llvm-project/blob/c619d4f840dcba54751ff8c5aaafce0f173a4ad5/flang/runtime/environment.cpp#L50-L90
>  | here ]] that is responsible for initializing the runtime state so that 

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

azat added a comment.

Can someone do a final review on this? And apply it if everything is OK.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133092/new/

https://reviews.llvm.org/D133092

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134186: [Clang][OpenMP] Codegen generation for has_device_addr claues.

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 added inline comments.



Comment at: clang/test/OpenMP/target_has_device_addr_codegen.cpp:317
+// CHECK-NEXT:store [10 x i32]* [[AA]], [10 x i32]** [[RAA]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = load i32*, i32** [[K]], align 8
+// CHECK-NEXT:[[TMP3:%.*]] = getelementptr inbounds [1 x i8*], [1 x i8*]* 
[[DOTOFFLOAD_BASEPTRS]], i32 0, i32 0

abhinavgaba wrote:
> This looks the same as `is_device_ptr(k)`. I don't think that's the correct 
> thing to do for `has_device_addr(k)`. For `has_device_addr(k)`, the value 
> being stored to `%offload.baseptrs` should be `i32** [[K]]`, and not a load 
> from it.
> 
> Similarly, the kernel argument should be `[[K]]` and not `[[TMP2]]` (which is 
> a load from `[[K]]`).
Good point.  I mad change by passing &var to BP instead pointer.



Comment at: openmp/libomptarget/test/mapping/has_device_addr.cpp:19
+data_device = (int *)omp_target_alloc(bytes, device_id);
+#pragma omp target teams distribute parallel for has_device_addr(data_device)
+for (int i = 0; i < size; ++i)

abhinavgaba wrote:
> The clause used here should either be `has_device_addr(data_device[0])` or 
> `is_device_ptr(data_device)`. `data_device` itself is an `i32**` which is 
> allocated on the host (`%data_device = alloca i32*`). Its pointee has a 
> device address (`%data_device_0 = load i32*, i32** %data_device`).
Changed.  Thanks.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134186/new/

https://reviews.llvm.org/D134186

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134137: [clangd] Return earlier when snippet is empty

[Nathan Ridge via Phabricator via cfe-commits]

nridge accepted this revision.
nridge added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

tom-anders wrote:
> tom-anders wrote:
> > kadircet wrote:
> > > tom-anders wrote:
> > > > nridge wrote:
> > > > > Does this test trigger the crash for you when run without the fix?
> > > > Yes it does, I double checked. Not sure why it didn't work for you
> > > it doesn't trigger the crash for me either.
> > Huh, maybe this is a b
> Hmm could be a build type thing? I ran the tests for a Debug build, maybe 
> it's different in Release?
> 
> Maybe we could also ask the author of the GitHub issue to check if it fixes 
> the crash for them?
Ok, I verified that the test case does produce completion proposals with empty 
snippets, i.e. it does trigger the problematic code path, it just happens not 
to crash for me. I think that's fine.

Thank you for tracking this down and fixing!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134137/new/

https://reviews.llvm.org/D134137

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134267: [C++] [Modules] Support one phase compilation model for named modules

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu created this revision.
ChuanqiXu added reviewers: iains, dblaikie, Bigcheese, vsapsai.
ChuanqiXu added projects: clang, clang-modules.
Herald added a project: All.
ChuanqiXu requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.

This patch tries to make clang to generate the BMI implicitly in the module 
cache, which allow the user to compile a hello world example in one command 
line.

This also tries to fix the problem I raised a year ago: 
https://discourse.llvm.org/t/make-command-line-support-for-c-20-module-uniform-with-gcc/59144

More importantly, the patch ease the implementation for build system writers, 
which makes their initial support more easily. For example, in this branch 
https://github.com/ChuanqiXu9/llvm-project/tree/MyP1689, we can compile the 
HelloWorld examples by cmake with some little changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134267

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/create_module_cache.cpp
  clang/test/Modules/one-phase-compilation-named-modules.cppm

Index: clang/test/Modules/one-phase-compilation-named-modules.cppm
===
--- /dev/null
+++ clang/test/Modules/one-phase-compilation-named-modules.cppm
@@ -0,0 +1,25 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/M.cppm -c -o - -fmodules-cache-path=%t/pcm.cache
+// RUN: %clang -std=c++20 %t/Use.cpp -fsyntax-only  -fprebuilt-module-path=%t/pcm.cache -Xclang -verify
+//
+// RUN: rm -f %t/M.pcm
+// RUN: %clang -std=c++20 %t/MismatchedName.cppm -c -o - -fmodules-cache-path=%t/pcm.cache -fmodule-name=M
+// RUN: %clang -std=c++20 %t/Use.cpp -fsyntax-only  -fprebuilt-module-path=%t/pcm.cache -Xclang -verify
+
+//--- M.cppm
+export module M;
+export int getValue();
+
+//--- MismatchedName.cppm
+export module M;
+export int getValue();
+
+//--- Use.cpp
+// expected-no-diagnostics
+import M;
+int Use() {
+return getValue();
+}
Index: clang/test/Driver/create_module_cache.cpp
===
--- /dev/null
+++ clang/test/Driver/create_module_cache.cpp
@@ -0,0 +1,20 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: not %clang -std=c++20 %t/M.cppm -fmodules-cache-path= -c -o %t/M.tmp.o 2>&1 | FileCheck %t/M.cppm --check-prefix=ERROR
+// RUN: %clang -std=c++20 %t/M.cppm -fmodules-cache-path=%t/abc -c -o -
+// RUN: ls %t | FileCheck %t/M.cppm --check-prefix=CHECK-AVAILABLE
+//
+// RUN: %clang -std=c++20 %t/Use.cpp -fmodules-cache-path=abc -### 2>&1 | FileCheck %t/Use.cpp
+
+//--- M.cppm
+export module M;
+
+// ERROR: unable to create default module cache path "": No such file or directory
+// CHECK-AVAILABLE: abc
+
+//--- Use.cpp
+import M;
+
+// CHECK: -fprebuilt-module-path=abc
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3658,6 +3658,7 @@
  const ArgList &Args, const InputInfo &Input,
  const InputInfo &Output,
  ArgStringList &CmdArgs, bool &HaveModules) {
+  bool HasCXXModules = HaveModules;
   // -fmodules enables the use of precompiled modules (off by default).
   // Users can pass -fno-cxx-modules to turn off modules support for
   // C++/Objective-C++ programs.
@@ -3699,33 +3700,34 @@
 options::OPT_fno_implicit_modules, HaveClangModules)) {
 if (HaveModules)
   CmdArgs.push_back("-fno-implicit-modules");
-  } else if (HaveModules) {
+  } else if (HaveModules)
 ImplicitModules = true;
-// -fmodule-cache-path specifies where our implicitly-built module files
-// should be written.
-SmallString<128> Path;
-if (Arg *A = Args.getLastArg(options::OPT_fmodules_cache_path))
-  Path = A->getValue();
 
-bool HasPath = true;
-if (C.isForDiagnostics()) {
-  // When generating crash reports, we want to emit the modules along with
-  // the reproduction sources, so we ignore any provided module path.
-  Path = Output.getFilename();
-  llvm::sys::path::replace_extension(Path, ".cache");
-  llvm::sys::path::append(Path, "modules");
-} else if (Path.empty()) {
-  // No module path was provided: use the default.
-  HasPath = Driver::getDefaultModuleCachePath(Path);
-}
-
-// `HasPath` will only be false if getDefaultModuleCachePath() fails.
-// That being said, that failure is unlikely and not caching is harmless.
-if (HasPath) {
-  const char Arg[] = "-fmodules-cache-path=";
-  Path.insert(Path.begin(), Arg, Arg + strlen(Arg));
-  CmdArgs.push_back(Args.MakeArgString(Path));
-}
+  // -fmodule-cache-path specif

[PATCH] D134269: [docs] Document the one-phase style compilation to c++ standard modules

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu created this revision.
ChuanqiXu added reviewers: iains, dblaikie, ruoso, ben.boeckel.
ChuanqiXu added a project: clang-modules.
Herald added a project: All.
ChuanqiXu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is the followup of D134267 . The patch 
documents the new behavior with D134267 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134269

Files:
  clang/docs/StandardCPlusPlusModules.rst

Index: clang/docs/StandardCPlusPlusModules.rst
===
--- clang/docs/StandardCPlusPlusModules.rst
+++ clang/docs/StandardCPlusPlusModules.rst
@@ -142,8 +142,7 @@
 
 .. code-block:: console
 
-  $ clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm
-  $ clang++ -std=c++20 use.cpp -fprebuilt-module-path=. Hello.pcm -o Hello.out
+  $ clang++ -std=c++20 Hello.cppm use.cpp -o Hello.out
   $ ./Hello.out
   Hello World!
 
@@ -223,7 +222,21 @@
 How to produce a BMI
 
 
-It is possible to generate a BMI for an importable module unit by specifying the ``--precompile`` option.
+It is possible to generate a BMI explicitly for an importable
+module unit by specifying the ``--precompile`` option.
+
+Also if when we compile an importable module unit to an object file,
+the compiler will generate the corresponding BMI implicitly in the module cache path.
+See :ref:`Module Cache Path`.
+
+The file name for the implicitly generated BMI will be:
+
+* (1) If the module name is specified by `-fmodule-name={module-name}` option,
+  the file name of the BMI will be `{module-name}.pcm`
+* (2) If `-fmodule-name` is not specified, the file name of the BMI will be
+  the same with the name with source file except with the different suffix `.pcm`.
+  For example, if the source file is `M.cppm`, then the name of the implicitly
+  generated BMI in this manner will be `M.pcm`.
 
 File name requirement
 ~
@@ -309,6 +322,27 @@
 ``-fprebuilt-module-path`` is more convenient and ``-fmodule-file`` is faster since
 it saves time for file lookup.
 
+Module Cache Path
+~
+
+When we compile an importable module unit to an object file directly, the BMI
+will be generated in the module cache path.
+Users can specifiy the module cache path by ``-fmodules-cache-path=/path/`` option.
+If the module cache path is not specified explicitly, the compiler will choose
+the default module cache path.
+
+If we set the environment variable ``CLANG_MODULE_CACHE_PATH``, its value will
+be the default module cache path.
+Otherwise, the default module path is system specified. In Unix systems, its value
+will be ``~/.cache/clang/ModuleCache/``.
+
+If the directory specified by module cache path doesn't exist,
+the compiler will try to create the directory.
+The compiler will emit an error if it fails to create the directory.
+
+The module cache path will be passed to ``-fprebuilt-module-path`` so that
+the translation unit are able to lookup these implicitly generated BMI implicitly.
+
 Remember that module units still have an object counterpart to the BMI
 ~~
 
@@ -874,3 +908,52 @@
 this means the build speedup at higher optimization levels may be lower than expected given ``O0`` experience, 
 but does provide by more optimization opportunities.
 
+Why two-phase compilation?
+--
+
+The readers may notice that the document generates the BMI explicitly.
+We call this manner as two-phase compilation
+(sources to BMIs and BMIs to object files) to disambiguate the tranditional
+compilation process (sources to object files directly),
+which we call one-phase compilation.
+
+The two-phase compilation will have higher parallelism than the one-phase compilation.
+Image the following example:
+
+.. code-block:: c++
+
+  // A.cppm
+  export module A;
+  // ...
+
+  // B.cppm
+  export module B;
+  import A;
+
+  // C.cpp
+  import B;
+
+In this example, `C.cpp` dependent on Module B and `B.cppm` dependent on Module A.
+So the compilation process in one-phase style will be:
+
+.. code-block:: text
+
+  A.cppm --- A.pcm ---> A.o ->
+   B.cppm --- B.pcm ---> B.o ->
+C.cppm --- C.pcm ---> C.o
+
+But if it is compiled by the two-phase compilation, the process will be:
+
+.. code-block:: text
+
+  A.cppm --- A.pcm ---> A.o
+   B.cppm --- B.pcm ---> B.o
+C.cppm --- C.pcm ---> C.o
+
+From the example, we can find the two-phase compilation can bring more parallelism and
+the higher compilation speed.
+Especially, the middle end and the backend usually take much much more time than the frontend.
+So the gap will be larger in larger projects.
+
+So we highly recommend to use two-phas

[clang] 41dbee1 - [clang] Update ReleaseNotes about a crash fix (Issue 53628)

[Dmitry Polukhin via cfe-commits]

Author: Dmitry Polukhin
Date: 2022-09-20T02:05:36-07:00
New Revision: 41dbee1e66937fe7d579b73d30dc790cd79b8738

URL: 
https://github.com/llvm/llvm-project/commit/41dbee1e66937fe7d579b73d30dc790cd79b8738
DIFF: 
https://github.com/llvm/llvm-project/commit/41dbee1e66937fe7d579b73d30dc790cd79b8738.diff

LOG: [clang] Update ReleaseNotes about a crash fix (Issue 53628)

Update ReleaseNotes about a crash fix (Issue 53628)

Test Plan: none

Differential Revision: https://reviews.llvm.org/D134112

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1744a8b6f84b..5d6b53b3a4fc 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -155,6 +155,9 @@ Bug Fixes
   This is the suggested resolution to CWG DR2628.
   `Issue 57646 `_
   `Issue 43829 `_
+- Fixed a crash in C++20 mode in Clang and Clangd when compile source
+  with compilation errors.
+  `Issue 53628 `_
 
 
 Improvements to Clang's diagnostics



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134112: [clang] Update ReleaseNotes about a crash fix (Issue 53628)

[Dmitry Polukhin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG41dbee1e6693: [clang] Update ReleaseNotes about a crash fix 
(Issue 53628) (authored by DmitryPolukhin).

Changed prior to commit:
  https://reviews.llvm.org/D134112?vs=461009&id=461514#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134112/new/

https://reviews.llvm.org/D134112

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -155,6 +155,9 @@
   This is the suggested resolution to CWG DR2628.
   `Issue 57646 `_
   `Issue 43829 `_
+- Fixed a crash in C++20 mode in Clang and Clangd when compile source
+  with compilation errors.
+  `Issue 53628 `_
 
 
 Improvements to Clang's diagnostics


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -155,6 +155,9 @@
   This is the suggested resolution to CWG DR2628.
   `Issue 57646 `_
   `Issue 43829 `_
+- Fixed a crash in C++20 mode in Clang and Clangd when compile source
+  with compilation errors.
+  `Issue 53628 `_
 
 
 Improvements to Clang's diagnostics
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134136: [Clang] Support constexpr for builtin fmax, fmin, ilogb, logb, scalbn

[Evgeny Shulgin via Phabricator via cfe-commits]

Izaron abandoned this revision.
Izaron added a comment.

In D134136#3801495 , @efriedma wrote:

> These patches are hard to review, yes; the reviewer has to go through and 
> verify for each function that the substitutes you've written actually match 
> the C library semantics.  (It's very easy to make mistakes with that sort of 
> thing.)
>
> On that front, I'm pretty sure the NaN handling in your fmin/fmax 
> implementations are wrong.

Thanks! I'm abandoning this patch, will make new smaller but better patches.

> each function that the substitutes you've written actually match the C 
> library semantics

I think this can be verified with libc++/libc tests that would substitute 
either `std::fmax` or (constant) `__builtin_fmax` on same checks and assert 
that they behave in the same way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134136/new/

https://reviews.llvm.org/D134136

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Paulo Matos via Phabricator via cfe-commits]

pmatos updated this revision to Diff 461518.
pmatos added a comment.

Address further concerns.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122215/new/

https://reviews.llvm.org/D122215

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/WebAssemblyReferenceTypes.def
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/module.modulemap
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGen/WebAssembly/wasm-externref.c
  clang/test/CodeGen/builtins-wasm.c
  clang/test/CodeGenCXX/wasm-reftypes-mangle.cpp
  clang/test/CodeGenCXX/wasm-reftypes-typeinfo.cpp
  clang/test/Sema/wasm-refs-and-tables.c
  clang/test/SemaCXX/wasm-refs.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/ValueTypes.cpp
  llvm/lib/IR/Type.cpp

Index: llvm/lib/IR/Type.cpp
===
--- llvm/lib/IR/Type.cpp
+++ llvm/lib/IR/Type.cpp
@@ -304,6 +304,18 @@
   return getInt64Ty(C)->getPointerTo(AS);
 }
 
+Type *Type::getWasm_ExternrefTy(LLVMContext &C) {
+  // opaque pointer in addrspace(10)
+  static PointerType *Ty = PointerType::get(C, 10);
+  return Ty;
+}
+
+Type *Type::getWasm_FuncrefTy(LLVMContext &C) {
+  // opaque pointer in addrspace(20)
+  static PointerType *Ty = PointerType::get(C, 20);
+  return Ty;
+}
+
 //===--===//
 //   IntegerType Implementation
 //===--===//
Index: llvm/lib/CodeGen/ValueTypes.cpp
===
--- llvm/lib/CodeGen/ValueTypes.cpp
+++ llvm/lib/CodeGen/ValueTypes.cpp
@@ -204,12 +204,8 @@
   case MVT::x86mmx:  return Type::getX86_MMXTy(Context);
   case MVT::x86amx:  return Type::getX86_AMXTy(Context);
   case MVT::i64x8:   return IntegerType::get(Context, 512);
-  case MVT::externref:
-// pointer to opaque struct in addrspace(10)
-return PointerType::get(StructType::create(Context), 10);
-  case MVT::funcref:
-// pointer to i8 addrspace(20)
-return PointerType::get(Type::getInt8Ty(Context), 20);
+  case MVT::externref: return Type::getWasm_ExternrefTy(Context);
+  case MVT::funcref: return Type::getWasm_FuncrefTy(Context);
   case MVT::v1i1:
 return FixedVectorType::get(Type::getInt1Ty(Context), 1);
   case MVT::v2i1:
Index: llvm/include/llvm/IR/Type.h
===
--- llvm/include/llvm/IR/Type.h
+++ llvm/include/llvm/IR/Type.h
@@ -473,6 +473,8 @@
   static PointerType *getInt16PtrTy(LLVMContext &C, unsigned AS = 0);
   static PointerType *getInt32PtrTy(LLVMContext &C, unsigned AS = 0);
   static PointerType *getInt64PtrTy(LLVMContext &C, unsigned AS = 0);
+  static Type *getWasm_ExternrefTy(LLVMContext &C);
+  static Type *getWasm_FuncrefTy(LLVMContext &C);
 
   /// Return a pointer to the current type. This is equivalent to
   /// PointerType::get(Foo, AddrSpace).
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1627,6 +1627,8 @@
 #include "clang/Basic/PPCTypes.def"
 #define RVV_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
 #include "clang/Basic/RISCVVTypes.def"
+#define WASM_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/WebAssemblyReferenceTypes.def"
 #define BUILTIN_TYPE(Id, SingletonId)
 #define SIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define UNSIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
Index: clang/test/SemaTemplate/address_space-dependent.cpp

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Paulo Matos via Phabricator via cfe-commits]

pmatos planned changes to this revision.
pmatos added a comment.

Current patch addresses most of the concerns - also passed through 
`./clang/tools/clang-format/git-clang-format`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122215/new/

https://reviews.llvm.org/D122215

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134268: [Clang][OpenMP] Codegen generation for has_device_addr claues.

[Abhinav Gaba via Phabricator via cfe-commits]

abhinavgaba added inline comments.



Comment at: clang/test/OpenMP/target_has_device_addr_codegen.cpp:351
+// CHECK:   omp_offload.failed:
+// CHECK-NEXT:call void 
@{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}_main_l145(i32* [[TMP2]]) 
#[[ATTR5:[0-9]+]]
+// CHECK-NEXT:br label [[OMP_OFFLOAD_CONT]]

The kernel argument should be `[[K]]` instead of `[[TMP2]]`. And the kernel's 
definition would need to be updated to take that extra pointer indirection into 
account.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134268/new/

https://reviews.llvm.org/D134268

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134270: [clang] [Driver] Support multiple configuration files

[Michał Górny via Phabricator via cfe-commits]

mgorny created this revision.
mgorny added reviewers: sepavloff, MaskRay.
Herald added a subscriber: StephenFan.
Herald added a project: All.
mgorny requested review of this revision.

Support specifying multiple configuration files via multiple `--config`
options.  When multiple files are specified, the options from subsequent
files are appended to the options from the initial file.

While at it, remove the incorrect assertion about CfgFileName being
non-empty.  It can be empty if `--config ""` is passed, and it makes
sense to report it as non-existing file rather than crash.


https://reviews.llvm.org/D134270

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/config-file-errs.c
  clang/test/Driver/config-file.c

Index: clang/test/Driver/config-file.c
===
--- clang/test/Driver/config-file.c
+++ clang/test/Driver/config-file.c
@@ -73,6 +73,10 @@
 // CHECK-PRECEDENCE: -Wall
 
 
-//--- Duplicate --config options are allowed if the value is the same
-// RUN: %clang --config-system-dir=%S/Inputs/config --config-user-dir=%S/Inputs/config2 --config config-4.cfg --config config-4.cfg -S %s -o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-SAME-CONFIG
-// CHECK-SAME-CONFIG: Configuration file: {{.*}}Inputs{{.}}config2{{.}}config-4.cfg
+//--- Multiple configuration files can be specified.
+// RUN: %clang --config-system-dir=%S/Inputs/config --config-user-dir= --config config-4.cfg --config %S/Inputs/config2/config-4.cfg -S %s -o /dev/null -v 2>&1 | FileCheck %s -check-prefix CHECK-TWO-CONFIGS
+// CHECK-TWO-CONFIGS: Configuration file: {{.*}}Inputs{{.}}config{{.}}config-4.cfg
+// CHECK-TWO-CONFIGS: Configuration file: {{.*}}Inputs{{.}}config2{{.}}config-4.cfg
+// CHECK-TWO-CONFIGS: -isysroot
+// CHECK-TWO-CONFIGS-SAME: /opt/data
+// CHECK-TWO-CONFIGS-SAME: -Wall
Index: clang/test/Driver/config-file-errs.c
===
--- clang/test/Driver/config-file-errs.c
+++ clang/test/Driver/config-file-errs.c
@@ -1,9 +1,3 @@
-//--- No more than one '--config' may be specified.
-//
-// RUN: not %clang --config 1.cfg --config 2.cfg 2>&1 | FileCheck %s -check-prefix CHECK-DUPLICATE
-// CHECK-DUPLICATE: no more than one option '--config' is allowed
-
-
 //--- '--config' must be followed by config file name.
 //
 // RUN: not %clang --config 2>&1 | FileCheck %s -check-prefix CHECK-MISSING-FILE
@@ -22,6 +16,11 @@
 // CHECK-NONEXISTENT: configuration file '{{.*}}somewhere/nonexistent-config-file' does not exist
 
 
+//--- All '--config' arguments must be existing files.
+//
+// RUN: not %clang --config %S/Inputs/config-4.cfg --config somewhere/nonexistent-config-file 2>&1 | FileCheck %s -check-prefix CHECK-NONEXISTENT
+
+
 //--- Argument of '--config' must exist somewhere in well-known directories, if it is specified by bare name.
 //
 // RUN: not %clang --config-system-dir= --config-user-dir= --config nonexistent-config-file.cfg 2>&1 | FileCheck %s -check-prefix CHECK-NOTFOUND0
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -929,6 +929,22 @@
   return false;
 }
 
+static void appendOneArg(InputArgList &Args, const Arg *Opt,
+ const Arg *BaseArg) {
+  // The args for config files or /clang: flags belong to different InputArgList
+  // objects than Args. This copies an Arg from one of those other InputArgLists
+  // to the ownership of Args.
+  unsigned Index = Args.MakeIndex(Opt->getSpelling());
+  Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Args.getArgString(Index),
+ Index, BaseArg);
+  Copy->getValues() = Opt->getValues();
+  if (Opt->isClaimed())
+Copy->claim();
+  Copy->setOwnsValues(Opt->getOwnsValues());
+  Opt->setOwnsValues(false);
+  Args.append(Copy);
+}
+
 bool Driver::readConfigFile(StringRef FileName) {
   // Try reading the given file.
   SmallVector NewCfgArgs;
@@ -940,31 +956,38 @@
   // Read options from config file.
   llvm::SmallString<128> CfgFileName(FileName);
   llvm::sys::path::native(CfgFileName);
-  ConfigFile = std::string(CfgFileName);
   bool ContainErrors;
-  CfgOptions = std::make_unique(
+  std::unique_ptr NewOptions = std::make_unique(
   ParseArgStrings(NewCfgArgs, IsCLMode(), ContainErrors));
-  if (ContainErrors) {
-CfgOptions.reset();
+  if (ContainErrors)
 return true;
-  }
 
-  if (CfgOptions->hasArg(options::OPT_config)) {
-CfgOptions.reset();
+  if (NewOptions->hasArg(options::OPT_config)) {
 Diag(diag::err_drv_nested_config_file);
 return true;
   }
 
   // Claim all arguments that come from a configuration file so that the driver
   // does not warn on any that is unused.
-  for (Arg *A : *CfgOptions)
+  for (Arg *A : *NewOptions)
 A->claim();
+
+  if (!CfgOptions)
+CfgOptions = std::move(NewOptions);
+  else

[PATCH] D134271: [clang] [docs] Improve formatting & fix typo in config docs

[Michał Górny via Phabricator via cfe-commits]

mgorny created this revision.
mgorny added reviewers: sepavloff, MaskRay.
Herald added a subscriber: StephenFan.
Herald added a project: All.
mgorny requested review of this revision.

Fix teletype formatting in configuration file documentation to use
double backticks rather than single backticks.  Cover some more names
with this formatting.  Correct the name of config file for `clang-cl`
invocation.


https://reviews.llvm.org/D134271

Files:
  clang/docs/UsersManual.rst


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -881,9 +881,9 @@
 Configuration files group command-line options and allow all of them to be
 specified just by referencing the configuration file. They may be used, for
 example, to collect options required to tune compilation for particular
-target, such as -L, -I, -l, --sysroot, codegen options, etc.
+target, such as ``-L``, ``-I``, ``-l``, ``--sysroot``, codegen options, etc.
 
-The command line option `--config` can be used to specify configuration
+The command line option ``--config`` can be used to specify configuration
 file in a Clang invocation. For example:
 
 ::
@@ -900,39 +900,39 @@
 - the directory where Clang executable resides.
 
 Both user and system directories for configuration files are specified during
-clang build using CMake parameters, CLANG_CONFIG_FILE_USER_DIR and
-CLANG_CONFIG_FILE_SYSTEM_DIR respectively. The first file found is used. It is
-an error if the required file cannot be found.
+clang build using CMake parameters, ``CLANG_CONFIG_FILE_USER_DIR`` and
+``CLANG_CONFIG_FILE_SYSTEM_DIR`` respectively. The first file found is used.
+It is an error if the required file cannot be found.
 
 If no explicit configuration file is specified, Clang searches for a default
 configuration file following the rules described in the next paragraphs.
-To disable this behavior, `--no-default-config` flag can be used.
+To disable this behavior, ``--no-default-config`` flag can be used.
 
 Another way to specify a configuration file is to encode it in executable name.
-For example, if the Clang executable is named `armv7l-clang` (it may be a
-symbolic link to `clang`), then Clang will search for file `armv7l.cfg` in the
-directory where Clang resides.
+For example, if the Clang executable is named ``armv7l-clang`` (it may be a
+symbolic link to ``clang``), then Clang will search for file ``armv7l.cfg``
+in the directory where Clang resides.
 
 If a driver mode is specified in invocation, Clang tries to find a file 
specific
 for the specified mode. For example, if the executable file is named
-`x86_64-clang-cl`, Clang first looks for `x86_64-cl.cfg` and if it is not 
found,
-looks for `x86_64.cfg`.
+``x86_64-clang-cl``, Clang first looks for ``x86_64-clang-cl.cfg`` and if it is
+not found, looks for ``x86_64.cfg``.
 
 If the command line contains options that effectively change target 
architecture
-(these are -m32, -EL, and some others) and the configuration file starts with 
an
-architecture name, Clang tries to load the configuration file for the effective
-architecture. For example, invocation:
+(these are ``-m32``, ``-EL``, and some others) and the configuration file 
starts
+with an architecture name, Clang tries to load the configuration file for the
+effective architecture. For example, invocation:
 
 ::
 
 x86_64-clang -m32 abc.c
 
-causes Clang search for a file `i368.cfg` first, and if no such file is found,
-Clang looks for the file `x86_64.cfg`.
+causes Clang search for a file ``i368.cfg`` first, and if no such file is 
found,
+Clang looks for the file ``x86_64.cfg``.
 
 The configuration file consists of command-line options specified on one or
 more lines. Lines composed of whitespace characters only are ignored as well as
-lines in which the first non-blank character is `#`. Long options may be split
+lines in which the first non-blank character is ``#``. Long options may be 
split
 between several lines by a trailing backslash. Here is example of a
 configuration file:
 
@@ -948,19 +948,19 @@
 # other config files may be included
 @linux.options
 
-Files included by `@file` directives in configuration files are resolved
+Files included by ``@file`` directives in configuration files are resolved
 relative to the including file. For example, if a configuration file
-`~/.llvm/target.cfg` contains the directive `@os/linux.opts`, the file
-`linux.opts` is searched for in the directory `~/.llvm/os`.
+``~/.llvm/target.cfg`` contains the directive ``@os/linux.opts``, the file
+``linux.opts`` is searched for in the directory ``~/.llvm/os``.
 
-To generate paths relative to the configuration file, the `` token may
+To generate paths relative to the configuration file, the  token 
may
 be used. This will expand to the absolute path of the directory containing the
 configuration file.
 
 In cases where a configuration file is deployed a

[PATCH] D133443: [RISCV][MC] Add support for experimental Zawrs extension

[Luís Marques via Phabricator via cfe-commits]

luismarques added a comment.

Regarding the overkill of "RISCVInstrInfoZawrs.td", how about having a 
"RISCVInstrInfoExtra.td" (or "RISCVInstrInfoExt.td") as a grab bag for 
everything that doesn't merit its own .td file?

I think this is fine regarding the versioning issue. Seems to only be missing 
the actual instruction tests, otherwise LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133443/new/

https://reviews.llvm.org/D133443

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 58f9aba - AAArch64: disable asynchronous unwind by default for MachO.

[Tim Northover via cfe-commits]

Author: Tim Northover
Date: 2022-09-20T10:47:18+01:00
New Revision: 58f9abaed4aa148566d5f14afdf473e57b20d687

URL: 
https://github.com/llvm/llvm-project/commit/58f9abaed4aa148566d5f14afdf473e57b20d687
DIFF: 
https://github.com/llvm/llvm-project/commit/58f9abaed4aa148566d5f14afdf473e57b20d687.diff

LOG: AAArch64: disable asynchronous unwind by default for MachO.

AArch64 MachO has a compact unwind format where most functions' unwind info can
be represented in just 4 bytes. But this cannot represent any asynchronous CFI
function, so it's essentially disabled when that's used. This is a large
code-size hit that we'd rather not take unless explicitly requested.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/clang-translation.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index e466ce935a68..50572ff04ff8 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2932,7 +2932,8 @@ ToolChain::UnwindTableLevel 
MachO::getDefaultUnwindTableLevel(const ArgList &Arg
   (GetExceptionModel(Args) != llvm::ExceptionHandling::SjLj &&
Args.hasFlag(options::OPT_fexceptions, options::OPT_fno_exceptions,
 true)))
-return UnwindTableLevel::Asynchronous;
+return getArch() == llvm::Triple::aarch64 ? UnwindTableLevel::Synchronous
+  : UnwindTableLevel::Asynchronous;
 
   return UnwindTableLevel::None;
 }

diff  --git a/clang/test/Driver/clang-translation.c 
b/clang/test/Driver/clang-translation.c
index c471c6a8f73d..ffa732c8f656 100644
--- a/clang/test/Driver/clang-translation.c
+++ b/clang/test/Driver/clang-translation.c
@@ -77,7 +77,11 @@
 
 // RUN: %clang -target arm64-apple-ios10 -### -S %s -arch arm64 2>&1 | \
 // RUN: FileCheck -check-prefix=ARM64-APPLE %s
-// ARM64-APPLE: -funwind-tables=2
+// ARM64-APPLE: -funwind-tables=1
+
+// RUN: %clang -target arm64-apple-ios10 -funwind-tables -### -S %s -arch 
arm64 2>&1 | \
+// RUN: FileCheck -check-prefix=ARM64-APPLE-UNWIND %s
+// ARM64-APPLE-UNWIND: -funwind-tables=1
 
 // RUN: %clang -target arm64-apple-ios10 -### -ffreestanding -S %s -arch arm64 
2>&1 | \
 // RUN: FileCheck -check-prefix=ARM64-FREESTANDING-APPLE %s



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4388b56 - Refactor unwind table driver interface to expose default level. NFC.

[Tim Northover via cfe-commits]

Author: Tim Northover
Date: 2022-09-20T10:47:18+01:00
New Revision: 4388b56d525c08ce3cf941cfbad2428b0e1695b0

URL: 
https://github.com/llvm/llvm-project/commit/4388b56d525c08ce3cf941cfbad2428b0e1695b0
DIFF: 
https://github.com/llvm/llvm-project/commit/4388b56d525c08ce3cf941cfbad2428b0e1695b0.diff

LOG: Refactor unwind table driver interface to expose default level. NFC.

Added: 


Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CrossWindows.cpp
clang/lib/Driver/ToolChains/CrossWindows.h
clang/lib/Driver/ToolChains/Darwin.cpp
clang/lib/Driver/ToolChains/Darwin.h
clang/lib/Driver/ToolChains/FreeBSD.cpp
clang/lib/Driver/ToolChains/FreeBSD.h
clang/lib/Driver/ToolChains/Fuchsia.h
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Gnu.h
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Driver/ToolChains/MSVC.h
clang/lib/Driver/ToolChains/MinGW.cpp
clang/lib/Driver/ToolChains/MinGW.h
clang/lib/Driver/ToolChains/NetBSD.h
clang/lib/Driver/ToolChains/OpenBSD.cpp
clang/lib/Driver/ToolChains/OpenBSD.h

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index 28137e36e2af..a0d5127007cf 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -108,6 +108,12 @@ class ToolChain {
 UNW_Libgcc
   };
 
+  enum class UnwindTableLevel {
+None,
+Synchronous,
+Asynchronous,
+  };
+
   enum RTTIMode {
 RM_Enabled,
 RM_Disabled,
@@ -495,9 +501,9 @@ class ToolChain {
   /// Returns true if gcov instrumentation (-fprofile-arcs or --coverage) is 
on.
   static bool needsGCovInstrumentation(const llvm::opt::ArgList &Args);
 
-  /// IsUnwindTablesDefault - Does this tool chain use -funwind-tables
-  /// by default.
-  virtual bool IsUnwindTablesDefault(const llvm::opt::ArgList &Args) const;
+  /// How detailed should the unwind tables be by default.
+  virtual UnwindTableLevel
+  getDefaultUnwindTableLevel(const llvm::opt::ArgList &Args) const;
 
   /// Test whether this toolchain supports outline atomics by default.
   virtual bool

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 26c5087b4ac2..5547f28d6351 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -287,8 +287,9 @@ std::string ToolChain::getInputFilename(const InputInfo 
&Input) const {
   return Input.getFilename();
 }
 
-bool ToolChain::IsUnwindTablesDefault(const ArgList &Args) const {
-  return false;
+ToolChain::UnwindTableLevel
+ToolChain::getDefaultUnwindTableLevel(const ArgList &Args) const {
+  return UnwindTableLevel::None;
 }
 
 Tool *ToolChain::getClang() const {

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 9cc08306471c..34caeaf0f6af 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5461,17 +5461,26 @@ void Clang::ConstructJob(Compilation &C, const 
JobAction &JA,
   // -fasynchronous-unwind-tables and -fnon-call-exceptions interact in more
   // complicated ways.
   auto SanitizeArgs = TC.getSanitizerArgs(Args);
-  bool AsyncUnwindTables = Args.hasFlag(
-  options::OPT_fasynchronous_unwind_tables,
-  options::OPT_fno_asynchronous_unwind_tables,
-  (TC.IsUnwindTablesDefault(Args) || SanitizeArgs.needsUnwindTables()) &&
-  !Freestanding);
-  bool UnwindTables = Args.hasFlag(options::OPT_funwind_tables,
-   options::OPT_fno_unwind_tables, false);
-  if (AsyncUnwindTables)
-CmdArgs.push_back("-funwind-tables=2");
-  else if (UnwindTables)
+  auto UnwindTables = TC.getDefaultUnwindTableLevel(Args);
+
+  if (Args.hasFlag(options::OPT_fasynchronous_unwind_tables,
+   options::OPT_fno_asynchronous_unwind_tables,
+   SanitizeArgs.needsUnwindTables()) &&
+  !Freestanding)
+UnwindTables = ToolChain::UnwindTableLevel::Asynchronous;
+  else if (Args.hasFlag(options::OPT_funwind_tables,
+options::OPT_fno_unwind_tables, false))
+UnwindTables = ToolChain::UnwindTableLevel::Synchronous;
+  else if (Args.hasFlag(options::OPT_fno_unwind_tables,
+   options::OPT_fno_asynchronous_unwind_tables,
+   options::OPT_funwind_tables, false) || Freestanding)
+UnwindTables = ToolChain::UnwindTableLevel::None;
+
+
+  if (UnwindTables == ToolChain::UnwindTableLevel::Synchronous)
 CmdArgs.push_back("-funwind-tables=1");
+  else if (UnwindTables == ToolChain::UnwindTableLevel::Asynchronous)
+CmdArgs.push_back("-funwind-tables=2");
 
   // Prepare `-aux-target-cpu` and `-aux-target-feature` unless
   // `--gpu-use-aux-triple-only` is specified.
@@ -7293,7 +7302,7 @@ void C

[PATCH] D131153: AArch64: disable asynchronous unwind by default for MachO.

[Tim Northover via Phabricator via cfe-commits]

t.p.northover closed this revision.
t.p.northover added a comment.

Just noticed it'd already been approved with those suggestions, so pushed the 
revised version: 4388b56d 
 and 
58f9abaed4aa 
.




Comment at: clang/include/clang/Driver/ToolChain.h:111
 
+  enum UnwindTableLevel {
+UTL_None,

MaskRay wrote:
> I'd prefer `enum class` without the `UTL_` prefix. That will be more 
> readable. `UTL` isn't very clear (`RM_Enabled` is kinda a bad name as without 
> `RTTIMode` it's clear what's enabled; `UNW_CompilerRT` is fine as from 
> CompilerRT/Libgcc we know it refers to the unwind or builtin library; 
> Asynchrounous/Synchronous is not very clear).
Makes sense now that we have classes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131153/new/

https://reviews.llvm.org/D131153

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added inline comments.



Comment at: 
flang/include/flang/Optimizer/Builder/Runtime/EnvironmentDefaults.h:7
+//
+//===--===//
+

Could you document what these are? And what are they used for?



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:403-413
+  if (const auto *arg =
+  args.getLastArg(clang::driver::options::OPT_fconvert_EQ)) {
+auto parseConvertArg = [](const char *s) {
+  return llvm::StringSwitch>(s)
+  .Case("unknown", "UNKNOWN")
+  .Case("native", "NATIVE")
+  .Case("little-endian", "LITTLE_ENDIAN")

I'm OK with a lambda here, just pointing our that in other cases we added small 
hooks, e.g. `getOptimizationLevel`. I personally prefer hooks as this means 
that methods like `parseFrontendArgs` can be a bit shorter. But this is a very 
weak preference!



Comment at: flang/test/Driver/convert.f90:1
+! Ensure argument -fconvert= works as expected.
+

Could you be more specific? IIUC, this is more about making sure that the 
option parser works correctly and reports invalid usage of `-fconvert` as an 
error, right?



Comment at: flang/test/Driver/emit-mlir.f90:16
 ! CHECK-NEXT: }
+! CHECK-NEXT: fir.global @_QQEnvironmentDefaults constant : 
!fir.ref, 
!fir.ref> {
+! CHECK-NEXT:  %[[VAL_0:.*]] = fir.zero_bits !fir.ref, !fir.ref>

peixin wrote:
> jpenix-quic wrote:
> > peixin wrote:
> > > jpenix-quic wrote:
> > > > peixin wrote:
> > > > > jpenix-quic wrote:
> > > > > > peixin wrote:
> > > > > > > Is it possible not to generated this global variable if 
> > > > > > > `fconvert=` is not specified?
> > > > > > I'm not entirely sure--the issue I was running into was how to 
> > > > > > handle this in Fortran_main.c in a way which worked for all of 
> > > > > > GCC/Clang/Visual Studio (and maybe others?). I was originally 
> > > > > > thinking of doing this by using a weak definition of 
> > > > > > _QQEnvironmentDefaults set to nullptr so fconvert, etc. could 
> > > > > > override this definition without explicitly generating the fallback 
> > > > > > case. For GCC/clang, I think I could use __attribute__((weak)), but 
> > > > > > I wasn't sure how to handle this if someone tried to build with 
> > > > > > Visual Studio (or maybe another toolchain). I saw a few workarounds 
> > > > > > (ex: 
> > > > > > https://devblogs.microsoft.com/oldnewthing/20200731-00/?p=104024) 
> > > > > > but I shied away from this since it seems to be an undocumented 
> > > > > > feature (and presumably only helps with Visual Studio). 
> > > > > > 
> > > > > > Do you know of a better or more general way I could do this? (Or, 
> > > > > > is there non-weak symbol approach that might be better that I'm 
> > > > > > missing?)
> > > > > How about generate one runtime function with the argument of 
> > > > > `EnvironmentDefaultList`? This will avoid this and using one extern 
> > > > > variable?
> > > > > 
> > > > > If users use one variable with bind C name `_QQEnvironmentDefaults` 
> > > > > in fortran or one variable with name `_QQEnvironmentDefaults` in C, 
> > > > > it is risky. Would using the runtime function and static variable 
> > > > > with the type `EnvironmentDefaultList` in runtime be safer?
> > > > Agreed that there are potential risks with the current approach 
> > > > (although, are the `_Q*` names considered reserved?). Unfortunately, I 
> > > > think generating a call to set the environment defaults requires 
> > > > somewhat significant changes to the runtime. The runtime reads 
> > > > environment variables during initialization in 
> > > > `ExecutionEnvironment::Configure` which is ultimately called from the 
> > > > "hardcoded" `Fortran_main.c` and I need to set the defaults before this 
> > > > happens. So, I believe I'd either have to move the initialization to 
> > > > `_QQmain`  or make it so that `main` isn't hardcoded so that I could 
> > > > insert the appropriate runtime function.
> > > > 
> > > > @klausler I think I asked you about this when I was first trying to 
> > > > figure out how to implement the environment defaults and you suggested 
> > > > I try the extern approach--please let me know if you have 
> > > > thoughts/suggestions around this!
> > > This is what @klausler suggested:
> > > ```
> > > Instead of adding new custom APIs that let command-line options control 
> > > behavior in a way that is redundant with the runtime environment, I 
> > > suggest that you try a more general runtime library API by which the main 
> > > program can specify a default environment variable setting, or a set of 
> > > them. Then turn the command-line options into the equivalent environment 
> > > settings and pass them as default settings that could be overridden by 
> > > the actual environment.
> > > ```
> > > If I understand correctly, what I a

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D133468#3801838 , @davrec wrote:

> If I understand this correctly: whenever isDivergent() is true, `getDecl()` 
> or `getFoundDecl()` is an arbitrary choice between multiple candidate 
> (re)declarations of a typedef or using decl.  In particular it will be the 
> first redeclaration, //even though each different redeclaration can contain 
> different sugar information//.

Well that is only true for this particular way, as used in the tests for this 
patch, of creating a divergent TypedefType.

The general idea is just that the TypedefType will have an underlying type 
sugar which is decoupled from the one in the declaration.

In general, forgetting about just the above particular way of creating them, 
there might still exist only one TypedefDecl in the whole program, which every 
TypedefType is referencing, and they can still be divergent, ie have different 
sugared underlying type.

> But these types are a different matter:
>
>   auto t29 = 0 ? (RPX1){} : (RPY1){};
>   auto t32 = 0 ? (UPX1){} : (UPY1){};
>
> In the process of unifying the sugar to get the deduced type of t29/t32, we 
> will compare their sugar, which has the same basic structure for each, but 
> different decls/found decls; so unifying these types will simply involve 
> unifying their decls; and getCommonDecl(X,Y) has been defined to will simply 
> get the older declaration between them.  So, the TypedefType/UsingType sugar 
> in t29/t32 will reference the X1 decls and friends, *not* the Y1s, as its 
> Decls/FoundDecls.  (Right?)

But again, we are discussing one particular mechanism of creating these 
divergent types.
How that mechanism works was defined by a previous patch.

But I don't think the choice between declarations is arbitrary. That type 
unification mechanism has one basic principle, when two properties of a type 
are different, we pick the one that is closest to the canonical property, 
(except in some very special circumstances where the standard requires 
something different).
So the choice for the older decl is principled, the canonical decl will be the 
oldest one. If that wasn't the case, we would need some other choice.

> The UnderlyingType however will not be as arbitrary, as it will use 
> getCommonType to skip over everything the two don't have in common.

Yes, except that neither is just arbitrary.

> If I have this right, my question is: since the Decl/FoundDecl is an 
> arbitrary choice, should we solve this by either
>
> 1. constructing these with a null Decl/FoundDecl for such types, or if that 
> is problematic,
> 2. renaming `isDivergent` to `declIsArbitrary()` or something like that, to 
> suggest that not only do the underlying type and decl diverge, it is the 
> underlying type which is more meaningful, not the decl.

I don't think the declaration picked is arbitrary, and again they are the 
"Same" declaration, so picking null would be throwing out more information than 
is necessary for no principled reason.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133468/new/

https://reviews.llvm.org/D133468

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134269: [docs] Document the one-phase style compilation to c++ standard modules

[Adrian Vogelsgesang via Phabricator via cfe-commits]

avogelsgesang added inline comments.



Comment at: clang/docs/StandardCPlusPlusModules.rst:916
+We call this manner as two-phase compilation
+(sources to BMIs and BMIs to object files) to disambiguate the tranditional
+compilation process (sources to object files directly),





Comment at: clang/docs/StandardCPlusPlusModules.rst:936
+
+In this example, `C.cpp` dependent on Module B and `B.cppm` dependent on 
Module A.
+So the compilation process in one-phase style will be:




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134269/new/

https://reviews.llvm.org/D134269

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133583: [clang][ubsan] Fix __builtin_assume_aligned incorrect type descriptor and C++ object polymorphic address

[Lin Yurong via Phabricator via cfe-commits]

yronglin added a comment.

Thanks for take a review @aaron.ballman @rjmccall , can you land this patch for 
me? Please use 'yronglin ' to commit the change.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133583/new/

https://reviews.llvm.org/D133583

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134243: Don't crash when code completing `using enum ^Foo`.

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added a comment.

Might be mooted by fixing https://github.com/llvm/llvm-project/issues/57659, 
which I am working on


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134243/new/

https://reviews.llvm.org/D134243

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133834: [RISCV] Remove support for the unratified Zbt extension.

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

There seemed to be consensus on this in last week's meeting, and there's no 
upstream activity on the spec, so removing zbt makes sense to me.




Comment at: llvm/docs/ReleaseNotes.rst:115
 
+* Support the unratified Zbt extension has been removed.
+

"Support for the"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133834/new/

https://reviews.llvm.org/D133834

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133698: [clang][dataflow] SignAnalysis, edgeTransfer, branchTransfer

[Gabor Marton via Phabricator via cfe-commits]

martong planned changes to this revision.
martong added a comment.

Aligned with the RFC, I am going to dissect this patch into two patches:

1. This patch will remain a simple infrastructural change that introduces 
transferBranch. This could be useful for complex lattices (e.g integer value 
ranges) until we have an SMT solver in the core framework. I'll try to add a 
very simple unit test case instead of having SignAnalysis itself as a huge 
integration test case.
2. An independent patch for SignAnalysis implementation. I am going to rework 
it by using the boolean Value abstraction as suggested in the RFC.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133698/new/

https://reviews.llvm.org/D133698

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134233: [clang-format] Wrap inserted braces only if preceded by comments

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

I love the little and often approach, its so much easier to review, LGTM...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134233/new/

https://reviews.llvm.org/D134233

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Diana Picus via Phabricator via cfe-commits]

rovka added a comment.

IMO this is a reasonable approach, I only have a few nits.




Comment at: flang/runtime/environment.cpp:42
+#else
+if (setenv(name, value, 0) == -1) {
+#endif





Comment at: flang/runtime/environment.cpp:77
+#else
+  envp = environ;
+#endif

peixin wrote:
> jpenix-quic wrote:
> > peixin wrote:
> > > What is `environ` used for? Should we try to keep as less extern variable 
> > > as possible in runtime for security.
> > I think `setenv` is only required to make sure that the `environ` pointer 
> > points to the correct copy of the environment variables. So, as long as we 
> > are storing a copy of the environment pointer in `ExecutionEnvironment` and 
> > potentially making changes to the environment via `setenv`, I think we need 
> > to base it off the `environ` pointer after `setenv` has been called rather 
> > than the `envp` from `main`.
> > 
> > That said, I don't think the `envp` variable we are storing is being used 
> > for anything at the moment (reading environment variables was changed to 
> > use `getenv` rather than `envp` in the commit [[ 
> > https://github.com/llvm/llvm-project/commit/824bf908194c9267f1f09065ba8e41d7969006ab
> >  | here]]). If removing the usage of `environ` is preferable, we could 
> > maybe remove the usage of `envp` altogether (in a separate patch)--does 
> > this sound like a good idea or would it be better to just leave in the 
> > `environ` usage for now?
> Thanks for the explanations. The current fix makes sense to me.
I agree that we should remove envp altogether in a follow-up patch. As it 
stands it's just causing confusion.



Comment at: flang/test/Driver/convert.f90:1
+! Ensure argument -fconvert= works as expected.
+

Nit: Shouldn't you also check that valid values (e.g. unknown, swap etc) are 
accepted? 



Comment at: flang/test/Driver/driver-help.f90:27
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
+! HELP-NEXT: -fconvert=   Set endian conversion of data for 
unformatted files
 ! HELP-NEXT: -fdefault-double-8 Set the default double precision kind to 
an 8 byte wide type

Nit: Why is there an extra blank for these?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130513/new/

https://reviews.llvm.org/D130513

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134042: [clang-format] Fix alignment in #else preprocessor blocks

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Should we test nested if/else/endif


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134042/new/

https://reviews.llvm.org/D134042

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134049: [clang-format] Disallow trailing return arrows to be operators

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

@rymiel you definitely deserve the commit access: comments and initial 
investigations and possible bug locations in github issues, defect focused 
initial commits, way to go!, Welcome aboard..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134049/new/

https://reviews.llvm.org/D134049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134243: Don't crash when code completing `using enum ^Foo`.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D134243#3802457 , @urnathan wrote:

> Might be mooted by fixing https://github.com/llvm/llvm-project/issues/57659, 
> which I am working on

Great! Agree that larger changes around using-enum parsing would probably end 
up solving this in some better way.

Do you mind if I land it anyway? The testcase is useful even if the impl 
changes.
(Plus this is crashing for us in production, so just in case that larger change 
takes longer...)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134243/new/

https://reviews.llvm.org/D134243

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

[Paulo Matos via Phabricator via cfe-commits]

pmatos updated this revision to Diff 461544.
pmatos added a comment.

Address most of the comments.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128440/new/

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Format/FormatToken.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388587)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388586)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFEA>();
+  correct<0x7FFFE9>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650L>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/CodeGen/WebAssembly/wasm-funcref.c
===
--- /dev/null
+++ clang/test/CodeGen/WebAssembly/wasm-funcref.c
@@ -0,0 +1,84 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple wasm32 -target-feature +reference-types -o - -emit-llvm %s | FileCheck %s
+
+typedef void (*__funcref funcref_t)();
+typedef int (*__funcref fn_funcref_t)(int);
+typedef int (*fn_t)(int);
+
+// Null funcref builtin call
+// CHECK-LABEL: @get_null(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+funcref_t get_null() {
+  return __builtin_wasm_ref_null_func();
+}
+
+// Call to null funcref builtin but requires cast since
+// default return value for builtin is a funcref with function type () -> ().
+// CHECK-LABEL: @get_null_ii(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+fn_funcref_t get_null_ii() {
+  return (fn_funcref_t) __builtin_wasm_ref_null_func();
+}
+
+// Identity function for funcref.
+// CHECK-LABEL: @identity(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[FN_ADDR:%.*]] = alloca ptr addrspace(20), align 4
+// CHECK-NEXT:store ptr addrspace(20) [[FN:%.*]], ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr addrspace(20), ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+funcref_t identity(funcref_t fn) {
+  return fn;
+}
+
+void helper(funcref_t);
+
+// Pass funcref ref as an argument to a helper function.
+// CHECK-LABEL: @handle(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[FN_ADDR:%.*]] = alloca ptr addrspace(20), align 4
+// CHECK-NEXT:store ptr addrspace(20) [[FN:%.*]], ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr addrspace(20), ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:call void @helper(ptr addrspace(20) noundef [[TMP0]])
+// CHECK-NEXT:ret i32 0
+//
+int handle(funcref_t fn) {
+  helper(fn);
+  return 0;
+}
+
+// Return funcref from function pointer.
+// CHECK-LABEL: @get_ref(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[FNPTR_ADDR:%.*]] = alloca ptr, align 4
+// CHECK-NEXT:store ptr [[FNPTR:%.*]], ptr [[FNPTR_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr, ptr [[FNPTR_ADDR]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = addrspacecast ptr [[TMP0]] to ptr addrspace(20)
+// CHECK-NEXT:ret ptr addrspace(20) [[T

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peixin Qiao via Phabricator via cfe-commits]

peixin added inline comments.



Comment at: flang/test/Driver/emit-mlir.f90:16
 ! CHECK-NEXT: }
+! CHECK-NEXT: fir.global @_QQEnvironmentDefaults constant : 
!fir.ref, 
!fir.ref> {
+! CHECK-NEXT:  %[[VAL_0:.*]] = fir.zero_bits !fir.ref, !fir.ref>

awarzynski wrote:
> peixin wrote:
> > jpenix-quic wrote:
> > > peixin wrote:
> > > > jpenix-quic wrote:
> > > > > peixin wrote:
> > > > > > jpenix-quic wrote:
> > > > > > > peixin wrote:
> > > > > > > > Is it possible not to generated this global variable if 
> > > > > > > > `fconvert=` is not specified?
> > > > > > > I'm not entirely sure--the issue I was running into was how to 
> > > > > > > handle this in Fortran_main.c in a way which worked for all of 
> > > > > > > GCC/Clang/Visual Studio (and maybe others?). I was originally 
> > > > > > > thinking of doing this by using a weak definition of 
> > > > > > > _QQEnvironmentDefaults set to nullptr so fconvert, etc. could 
> > > > > > > override this definition without explicitly generating the 
> > > > > > > fallback case. For GCC/clang, I think I could use 
> > > > > > > __attribute__((weak)), but I wasn't sure how to handle this if 
> > > > > > > someone tried to build with Visual Studio (or maybe another 
> > > > > > > toolchain). I saw a few workarounds (ex: 
> > > > > > > https://devblogs.microsoft.com/oldnewthing/20200731-00/?p=104024) 
> > > > > > > but I shied away from this since it seems to be an undocumented 
> > > > > > > feature (and presumably only helps with Visual Studio). 
> > > > > > > 
> > > > > > > Do you know of a better or more general way I could do this? (Or, 
> > > > > > > is there non-weak symbol approach that might be better that I'm 
> > > > > > > missing?)
> > > > > > How about generate one runtime function with the argument of 
> > > > > > `EnvironmentDefaultList`? This will avoid this and using one extern 
> > > > > > variable?
> > > > > > 
> > > > > > If users use one variable with bind C name `_QQEnvironmentDefaults` 
> > > > > > in fortran or one variable with name `_QQEnvironmentDefaults` in C, 
> > > > > > it is risky. Would using the runtime function and static variable 
> > > > > > with the type `EnvironmentDefaultList` in runtime be safer?
> > > > > Agreed that there are potential risks with the current approach 
> > > > > (although, are the `_Q*` names considered reserved?). Unfortunately, 
> > > > > I think generating a call to set the environment defaults requires 
> > > > > somewhat significant changes to the runtime. The runtime reads 
> > > > > environment variables during initialization in 
> > > > > `ExecutionEnvironment::Configure` which is ultimately called from the 
> > > > > "hardcoded" `Fortran_main.c` and I need to set the defaults before 
> > > > > this happens. So, I believe I'd either have to move the 
> > > > > initialization to `_QQmain`  or make it so that `main` isn't 
> > > > > hardcoded so that I could insert the appropriate runtime function.
> > > > > 
> > > > > @klausler I think I asked you about this when I was first trying to 
> > > > > figure out how to implement the environment defaults and you 
> > > > > suggested I try the extern approach--please let me know if you have 
> > > > > thoughts/suggestions around this!
> > > > This is what @klausler suggested:
> > > > ```
> > > > Instead of adding new custom APIs that let command-line options control 
> > > > behavior in a way that is redundant with the runtime environment, I 
> > > > suggest that you try a more general runtime library API by which the 
> > > > main program can specify a default environment variable setting, or a 
> > > > set of them. Then turn the command-line options into the equivalent 
> > > > environment settings and pass them as default settings that could be 
> > > > overridden by the actual environment.
> > > > ```
> > > > If I understand correctly, what I am suggesting match his comments. The 
> > > > "main program" he means should be fortran main program, not the 
> > > > `RTNAME(ProgramStart`. In your initial patch, you add the runtime 
> > > > specified for "convert option". I think @klausler suggest you making 
> > > > the runtime argument more general used for a set of runtime environment 
> > > > variable settings, not restricted to "convert option". And that is what 
> > > > you already added -- `EnvironmentDefaultList`. So, combining this patch 
> > > > and your initial patch will be the solution. Hope I understand it 
> > > > correctly.
> > > The issue I hit with the suggested approach is that in order to use the 
> > > pre-existing runtime environment variable handling to set the internal 
> > > state I need to set the environment variable defaults before the 
> > > environment variables are read by the runtime.
> > > 
> > > I might be misunderstanding/missing something, but given that the 
> > > environment variables are read as part of `RTNAME(ProgramStart)` in 
> > > `main` and the earliest I can place the call if I a

[PATCH] D132816: [clang] AST: SubstTemplateTypeParmType support for non-canonical underlying type

[David Rector via Phabricator via cfe-commits]

davrec accepted this revision.
davrec added a comment.

Agree this needs a brief commit message, just explaining that previously the 
underlying type had to be canonical, but now it can be sugared, allowing a 
better/more informative representation.




Comment at: clang/include/clang/AST/TypeProperties.td:738
   def : Creator<[{
 // The call to getCanonicalType here existed in ASTReader.cpp, too.
 return ctx.getSubstTemplateTypeParmType(

^ Delete this comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132816/new/

https://reviews.llvm.org/D132816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132329: [X86][RFC] Using `__bf16` for AVX512_BF16 intrinsics

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

A few minors - and this probably needs a release notes entry for 16.x?




Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:2185
+addRegisterClass(MVT::v32bf16, &X86::VR512RegClass);
+setOperationAction(ISD::BUILD_VECTOR, MVT::bf16, Custom);
+setOperationAction(ISD::BUILD_VECTOR, MVT::v8bf16, Custom);

Isn't MVT::bf16 scalar? 



Comment at: llvm/test/CodeGen/X86/avx512bf16-intrinsics-upgrade.ll:30
 ; X64-NEXT:kmovd %edi, %k1 # encoding: [0xc5,0xfb,0x92,0xcf]
-; X64-NEXT:vcvtne2ps2bf16 %zmm1, %zmm0, %zmm0 {%k1} {z} # encoding: 
[0x62,0xf2,0x7f,0xc9,0x72,0xc1]
+; X64-NEXT:vmovdqu16 %zmm0, %zmm0 {%k1} {z} # encoding: 
[0x62,0xf1,0xff,0xc9,0x6f,0xc0]
 ; X64-NEXT:retq # encoding: [0xc3]

any chance we can recover the predicated instruction?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132329/new/

https://reviews.llvm.org/D132329

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134243: Don't crash when code completing `using enum ^Foo`.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM to fix the crash.
If @urnathan's changes happen to make this change obsolete, we could also 
revert consider reverting it afterwards.




Comment at: clang/lib/Parse/ParseDecl.cpp:4591
 Actions.CodeCompleteTag(getCurScope(), DeclSpec::TST_enum);
+DS.SetTypeSpecError();
 return;

sammccall wrote:
> this is a bit unusual, usually parse() functions just stop after hitting CC, 
> as if they hit something unexpected.
> 
> However ParseUsingDeclaration immediately calls ActOnUsingDeclaration, which 
> asserts that the enum specifier we parsed was one of {enum, typename, error}. 
> It seems simpler to signal failure using the existing mechanism than add a 
> new one - LMK what you think.
Could you add a comment mentioning that `ActOnUsingDeclaration` will break if 
we don't do this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134243/new/

https://reviews.llvm.org/D134243

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[David Rector via Phabricator via cfe-commits]

davrec added a subscriber: sammccall.
davrec added a comment.

> In general, forgetting about just the above particular way of creating them, 
> there might still exist only one TypedefDecl in the whole program, which 
> every TypedefType is referencing, and they can still be divergent, ie have 
> different sugared underlying type.

Can you give a code example demonstrating such a case, and any other 
distinctive cases where isDivergent() will be true?

>> But these types are a different matter:
>>
>>   auto t29 = 0 ? (RPX1){} : (RPY1){};
>>   auto t32 = 0 ? (UPX1){} : (UPY1){};
>>
>> In the process of unifying the sugar to get the deduced type of t29/t32, we 
>> will compare their sugar, which has the same basic structure for each, but 
>> different decls/found decls; so unifying these types will simply involve 
>> unifying their decls; and getCommonDecl(X,Y) has been defined to will simply 
>> get the older declaration between them.  So, the TypedefType/UsingType sugar 
>> in t29/t32 will reference the X1 decls and friends, *not* the Y1s, as its 
>> Decls/FoundDecls.  (Right?)
>
> But again, we are discussing one particular mechanism of creating these 
> divergent types.
> How that mechanism works was defined by a previous patch.
>
> But I don't think the choice between declarations is arbitrary. That type 
> unification mechanism has one basic principle, when two properties of a type 
> are different, we pick the one that is closest to the canonical property, 
> (except in some very special circumstances where the standard requires 
> something different).
> So the choice for the older decl is principled, the canonical decl will be 
> the oldest one. If that wasn't the case, we would need some other choice.



> I don't think the declaration picked is arbitrary, and again they are the 
> "Same" declaration, so picking null would be throwing out more information 
> than is necessary for no principled reason.

Hmm.  Redeclarations never change semantic information, and in general don't 
change sugar information, so the older one is indeed the common one from any 
principled standpoint - but as your test cases demonstrate, in the case of 
typedef and using-decl redeclarations, the sugar information can be changed.  
Does this result in some arbitrariness in choosing the older decl as the common 
decl?  My first instinct is that it does.  But as I think about it further...I 
think I agree with you, it is still principled to choose the earlier 
using-decl/typedef decl (though an argument can be made for choosing the very 
first decl, not just the earlier one, for typedefs and using-decls).

But, if we agree the decl choice is principled, the next question: what is the 
different principle behind choosing a different underlying type?   Why can't 
the underlying type for `t29`/`t32` be sugar for X1 and friends too?

To state the issue more practically: when users of the AST see 
isDivergent()==true, what do they do?  Which path should they take to fetch 
information from this node?

If we absolutely have to allow these types to diverge, we need very good 
documentation that helps them answer this.

Wrangling in @sammccall here since he developed `UsingType` and so might be 
affected/need clarity on how to handle `isDivergent()`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133468/new/

https://reviews.llvm.org/D133468

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133436: Ground work for cuda-related checks in clang-tidy

[Bartłomiej Cieślar via Phabricator via cfe-commits]

barcisz updated this revision to Diff 461561.
barcisz added a comment.

Inlined definition of size_t


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133436/new/

https://reviews.llvm.org/D133436

Files:
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
  clang-tools-extra/clang-tidy/cuda/CMakeLists.txt
  clang-tools-extra/clang-tidy/cuda/CudaTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/check_clang_tidy.py
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/cuda/cuda.h

Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/cuda/cuda.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/cuda/cuda.h
@@ -0,0 +1,28 @@
+/* Minimal declarations for CUDA support.  Testing purposes only. */
+
+using size_t = decltype(sizeof(0));
+
+#define __constant__ __attribute__((constant))
+#define __device__ __attribute__((device))
+#define __global__ __attribute__((global))
+#define __host__ __attribute__((host))
+#define __shared__ __attribute__((shared))
+
+struct dim3 {
+  unsigned x, y, z;
+  __host__ __device__ dim3(unsigned x, unsigned y = 1, unsigned z = 1) : x(x), y(y), z(z) {}
+};
+
+typedef struct cudaStream *cudaStream_t;
+typedef enum cudaError {} cudaError_t;
+extern "C" int cudaConfigureCall(dim3 gridSize, dim3 blockSize,
+ size_t sharedSize = 0,
+ cudaStream_t stream = 0);
+extern "C" int __cudaPushCallConfiguration(dim3 gridSize, dim3 blockSize,
+   size_t sharedSize = 0,
+   cudaStream_t stream = 0);
+extern "C" cudaError_t cudaLaunchKernel(const void *func, dim3 gridDim,
+dim3 blockDim, void **args,
+size_t sharedMem, cudaStream_t stream);
+
+extern "C" __device__ int printf(const char*, ...);
Index: clang-tools-extra/test/clang-tidy/check_clang_tidy.py
===
--- clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -93,7 +93,7 @@
 
 file_name_with_extension = self.assume_file_name or self.input_file_name
 _, extension = os.path.splitext(file_name_with_extension)
-if extension not in ['.c', '.hpp', '.m', '.mm']:
+if extension not in ['.c', '.cu', '.hpp', '.m', '.mm']:
   extension = '.cpp'
 self.temp_file_name = self.temp_file_name + extension
 
@@ -115,9 +115,14 @@
   self.clang_extra_args = ['-fobjc-abi-version=2', '-fobjc-arc', '-fblocks'] + \
   self.clang_extra_args
 
-if extension in ['.cpp', '.hpp', '.mm']:
+if extension in ['.cpp', '.cu', '.hpp', '.mm']:
   self.clang_extra_args.append('-std=' + self.std)
 
+# Tests should not rely on a certain cuda headers and library version
+# being available on the machine
+if extension == '.cu':
+  self.clang_extra_args.extend(["--no-cuda-version-check", "-nocudalib", "-nocudainc"])
+
 # Tests should not rely on STL being available, and instead provide mock
 # implementations of relevant APIs.
 self.clang_extra_args.append('-nostdinc++')
Index: clang-tools-extra/docs/clang-tidy/index.rst
===
--- clang-tools-extra/docs/clang-tidy/index.rst
+++ clang-tools-extra/docs/clang-tidy/index.rst
@@ -67,6 +67,7 @@
 ``concurrency-``   Checks related to concurrent programming (including
threads, fibers, coroutines, etc.).
 ``cppcoreguidelines-`` Checks related to C++ Core Guidelines.
+``cuda-``  Checks related to CUDA best practices.
 ``darwin-``Checks related to Darwin coding conventions.
 ``fuchsia-``   Checks related to Fuchsia coding conventions.
 ``google-``Checks related to Google coding conventions.
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -16,6 +16,7 @@
clang-analyzer/*
concurrency/*
cppcoreguidelines/*
+   cuda/*
darwin/*
fuchsia/*
google/*
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -96,6 +96,8 @@
 Improvements to clang-tidy
 --
 
+- Introduce the cuda module for checks specific to CUDA code.
+
 New checks
 ^^
 
Index: clang-tools-extra/clang-tidy/cuda/CudaTidyMod

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin created this revision.
DiggerLin added reviewers: jhenderson, daltenty, hubert.reinterpretcast.
Herald added subscribers: ormris, steven_wu, hiraditya.
Herald added a project: All.
DiggerLin requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

since default object mode of llvm-nm is change to -X32 (from default  -Xany) in 
patch https://reviews.llvm.org/D132494. the test cases using the llvm-nm also 
need to change based on the new feature on AIX OS.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134284

Files:
  clang/test/CodeGen/thinlto-inline-asm2.c
  clang/test/CodeGen/thinlto-multi-module.ll
  clang/test/CodeGen/thinlto_backend.ll
  clang/test/InterfaceStubs/driver-test.c
  clang/test/InterfaceStubs/driver-test3.c
  clang/test/InterfaceStubs/externstatic.c
  clang/test/InterfaceStubs/function-template-specialization.cpp
  clang/test/InterfaceStubs/inline.c
  clang/test/InterfaceStubs/template-namespace-function.cpp
  clang/test/InterfaceStubs/weak.cpp

Index: clang/test/InterfaceStubs/weak.cpp
===
--- clang/test/InterfaceStubs/weak.cpp
+++ clang/test/InterfaceStubs/weak.cpp
@@ -3,7 +3,7 @@
 // RUN: -interface-stub-version=ifs-v1 %s | \
 // RUN: FileCheck %s
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-nm - 2>&1 | \
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-nm -Xany - 2>&1 | \
 // RUN: FileCheck -check-prefix=CHECK-SYMBOLS %s
 
 // CHECK: Symbols:
Index: clang/test/InterfaceStubs/template-namespace-function.cpp
===
--- clang/test/InterfaceStubs/template-namespace-function.cpp
+++ clang/test/InterfaceStubs/template-namespace-function.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs %s | \
 // RUN: FileCheck %s
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-nm - 2>&1 | \
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-nm -Xany - 2>&1 | \
 // RUN: FileCheck -check-prefix=CHECK-SYMBOLS %s
 
 // CHECK: Symbols:
Index: clang/test/InterfaceStubs/inline.c
===
--- clang/test/InterfaceStubs/inline.c
+++ clang/test/InterfaceStubs/inline.c
@@ -3,33 +3,33 @@
 // RUN: -emit-interface-stubs -std=gnu89 -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-GNU %s
 // RUN: %clang -DINLINE=inline -target x86_64-linux-gnu -O0 -o - -c \
-// RUN: -std=gnu89 -xc %s | llvm-nm - | FileCheck -check-prefix=CHECK-GNU %s
+// RUN: -std=gnu89 -xc %s | llvm-nm -Xany - | FileCheck -check-prefix=CHECK-GNU %s
 
 // RUN: %clang_cc1 -DINLINE="__attribute__((always_inline))" \
 // RUN: -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-GNU %s
 // RUN: %clang -DINLINE="__attribute__((always_inline))" \
 // RUN: -target x86_64-linux-gnu -O0 -o - -c -xc %s | \
-// RUN: llvm-nm - | FileCheck -check-prefix=CHECK-GNU %s
+// RUN: llvm-nm -Xany - | FileCheck -check-prefix=CHECK-GNU %s
 
 // RUN: %clang_cc1 -DINLINE=inline -triple x86_64-unknown-linux-gnu -o - \
 // RUN: -emit-interface-stubs -std=c99 -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-STD %s
 // RUN: %clang -DINLINE=inline -target x86_64-linux-gnu -O0 -o - -c -std=c99 \
-// RUN: -xc %s | llvm-nm - 2>&1 | count 0
+// RUN: -xc %s | llvm-nm -Xany - 2>&1 | count 0
 
 // RUN: %clang_cc1 -DINLINE="__attribute__((noinline))" \
 // RUN: -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs -std=c99 -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-NOINLINE %s
 // RUN: %clang -DINLINE="__attribute__((noinline))" -target x86_64-linux-gnu \
-// RUN: -O0 -o - -c -std=c99 -xc %s | llvm-nm - 2>&1 | \
+// RUN: -O0 -o - -c -std=c99 -xc %s | llvm-nm -Xany - 2>&1 | \
 // RUN: FileCheck -check-prefix=CHECK-NOINLINE %s
 
 // RUN: %clang_cc1 -DINLINE="static" -triple x86_64-unknown-linux-gnu -o - \
 // RUN: -emit-interface-stubs -std=c99 -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-STATIC %s
 // RUN: %clang -DINLINE="static" -target x86_64-linux-gnu -O0 -o - -c \
-// RUN:   -std=c99 -xc %s | llvm-nm - 2>&1 | count 0
+// RUN:   -std=c99 -xc %s | llvm-nm -Xany - 2>&1 | count 0
 
 // CHECK-GNU-DAG: foo
 // CHECK-GNU-DAG: foo.var
@@ -52,7 +52,7 @@
 // RUN: -emit-interface-stubs \
 // RUN: -std=gnu89 -xc %s | FileCheck -check-prefix=CHECK-SYMBOLS %s
 // RUN: %clang -DINLINE=inline -target x86_64-linux-gnu -o - \
-// RUN: -c -std=gnu89 -xc %s | llvm-nm - 2>&1 | \
+// RUN: -c -std=gnu89 -xc %s | llvm-nm -Xany - 2>&1 | \
 // RUN: FileCheck -check-prefix=CHECK-SYMBOLS %s
 
 // CHECK-TAPI-DAG: foo", Type: Func }
Index: clang/test/InterfaceStubs/function-template-specialization.cpp
===
--- clang/test/InterfaceStubs/function-template-specialization.cpp
+++ clang/test/InterfaceS

[PATCH] D133801: Extraction of a matcher for an unused value from an expression from the bugprone-unused-return-value check

[Bartłomiej Cieślar via Phabricator via cfe-commits]

barcisz updated this revision to Diff 461562.
barcisz added a comment.

Removed unused matcher definitions from bugprone-unused-return-value


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133801/new/

https://reviews.llvm.org/D133801

Files:
  clang-tools-extra/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
  clang-tools-extra/clang-tidy/utils/Matchers.h


Index: clang-tools-extra/clang-tidy/utils/Matchers.h
===
--- clang-tools-extra/clang-tidy/utils/Matchers.h
+++ clang-tools-extra/clang-tidy/utils/Matchers.h
@@ -49,6 +49,51 @@
   return pointerType(pointee(qualType(isConstQualified(;
 }
 
+// Matches the statements in a GNU statement-expression that are not returned
+// from it.
+AST_MATCHER_P(StmtExpr, hasUnreturning,
+  clang::ast_matchers::internal::Matcher, matcher) {
+  const auto compoundStmt = Node.getSubStmt();
+  assert(compoundStmt);
+
+  clang::ast_matchers::internal::BoundNodesTreeBuilder result;
+  bool matched = false;
+  for (auto stmt = compoundStmt->body_begin();
+   stmt + 1 < compoundStmt->body_end(); ++stmt) {
+clang::ast_matchers::internal::BoundNodesTreeBuilder 
builderInner(*Builder);
+assert(stmt && *stmt);
+if (matcher.matches(**stmt, Finder, &builderInner)) {
+  result.addMatch(builderInner);
+  matched = true;
+}
+  }
+  *Builder = result;
+  return matched;
+}
+
+// Matches all of the nodes (simmilar to forEach) that match the matcher
+// and have return values not used in any statement.
+AST_MATCHER_FUNCTION_P(ast_matchers::StatementMatcher, isValueUnused,
+   ast_matchers::StatementMatcher, Matcher) {
+  using namespace ast_matchers;
+  const auto UnusedInCompoundStmt =
+  compoundStmt(forEach(Matcher), unless(hasParent(stmtExpr(;
+  const auto UnusedInGnuExprStmt = stmtExpr(hasUnreturning(Matcher));
+  const auto UnusedInIfStmt =
+  ifStmt(eachOf(hasThen(Matcher), hasElse(Matcher)));
+  const auto UnusedInWhileStmt = whileStmt(hasBody(Matcher));
+  const auto UnusedInDoStmt = doStmt(hasBody(Matcher));
+  const auto UnusedInForStmt = forStmt(
+  eachOf(hasLoopInit(Matcher), hasIncrement(Matcher), hasBody(Matcher)));
+  const auto UnusedInRangeForStmt = cxxForRangeStmt(hasBody(Matcher));
+  const auto UnusedInCaseStmt = switchCase(forEach(Matcher));
+  const auto Unused =
+  stmt(anyOf(UnusedInCompoundStmt, UnusedInGnuExprStmt, UnusedInIfStmt,
+ UnusedInWhileStmt, UnusedInDoStmt, UnusedInForStmt,
+ UnusedInRangeForStmt, UnusedInCaseStmt));
+  return stmt(eachOf(Unused, forEachDescendant(Unused)));
+}
+
 // A matcher implementation that matches a list of type name regular 
expressions
 // against a NamedDecl. If a regular expression contains the substring "::"
 // matching will occur against the qualified name, otherwise only the typename.
Index: clang-tools-extra/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "UnusedReturnValueCheck.h"
+#include "../utils/Matchers.h"
 #include "../utils/OptionsUtils.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
@@ -140,29 +141,8 @@
unless(returns(voidType())),
isInstantiatedFrom(hasAnyName(FunVec)
   .bind("match";
-
-  auto UnusedInCompoundStmt =
-  compoundStmt(forEach(MatchedCallExpr),
-   // The checker can't currently differentiate between the
-   // return statement and other statements inside GNU 
statement
-   // expressions, so disable the checker inside them to avoid
-   // false positives.
-   unless(hasParent(stmtExpr(;
-  auto UnusedInIfStmt =
-  ifStmt(eachOf(hasThen(MatchedCallExpr), hasElse(MatchedCallExpr)));
-  auto UnusedInWhileStmt = whileStmt(hasBody(MatchedCallExpr));
-  auto UnusedInDoStmt = doStmt(hasBody(MatchedCallExpr));
-  auto UnusedInForStmt =
-  forStmt(eachOf(hasLoopInit(MatchedCallExpr),
- hasIncrement(MatchedCallExpr), hasBody(MatchedCallExpr)));
-  auto UnusedInRangeForStmt = cxxForRangeStmt(hasBody(MatchedCallExpr));
-  auto UnusedInCaseStmt = switchCase(forEach(MatchedCallExpr));
-
   Finder->addMatcher(
-  stmt(anyOf(UnusedInCompoundStmt, UnusedInIfStmt, UnusedInWhileStmt,
- UnusedInDoStmt, UnusedInForStmt, UnusedInRangeForStmt,
- UnusedInCaseStmt)),
-  this);
+  functionDecl(hasBody(matchers::isValueUnused(MatchedCallExpr))), this);
 }
 
 void UnusedReturnValueCheck::check(const MatchFinder::MatchResult &Result) {


Ind

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[James Henderson via Phabricator via cfe-commits]

jhenderson added a comment.

Wouldn't it be better to change the lit config to specify the `OBJECT_MODE` 
environment variable on AIX?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin added a comment.

In D134284#3802763 , @jhenderson 
wrote:

> Wouldn't it be better to change the lit config to specify the `OBJECT_MODE` 
> environment variable on AIX?

I have tried it before, I added the following in clang/test/lit.cfg.py
if 'system-aix' in config.available_features:

  config.environment['OBJECT_MODE'] = 'any' 

it will cause  clang some problem in test cases. something like , clang do not 
know environment variable " OBJECT_MODE"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[James Henderson via Phabricator via cfe-commits]

jhenderson added a comment.

In D134284#3802766 , @DiggerLin wrote:

> In D134284#3802763 , @jhenderson 
> wrote:
>
>> Wouldn't it be better to change the lit config to specify the `OBJECT_MODE` 
>> environment variable on AIX?
>
> I have tried it before, I added the following in clang/test/lit.cfg.py
>
>   if 'system-aix' in config.available_features:
>config.environment['OBJECT_MODE'] = 'any' 
>
> it will cause  clang some problem in some test cases. something like 
> ,"clang-16: error: OBJECT_MODE setting any is not recognized and is not a 
> valid setting"

Not sure I entirely follow. If `OBJECT_MODE` isn't an environment variable that 
clang uses, surely it should ignore it? What clang tests throw this sort of 
error?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin added a comment.

In D134284#3802791 , @jhenderson 
wrote:

> In D134284#3802766 , @DiggerLin 
> wrote:
>
>> In D134284#3802763 , @jhenderson 
>> wrote:
>>
>>> Wouldn't it be better to change the lit config to specify the `OBJECT_MODE` 
>>> environment variable on AIX?
>>
>> I have tried it before, I added the following in clang/test/lit.cfg.py
>>
>>   if 'system-aix' in config.available_features:
>>config.environment['OBJECT_MODE'] = 'any' 
>>
>> it will cause  clang some problem in some test cases. something like 
>> ,"clang-16: error: OBJECT_MODE setting any is not recognized and is not a 
>> valid setting"
>
> Not sure I entirely follow. If `OBJECT_MODE` isn't an environment variable 
> that clang uses, surely it should ignore it? What clang tests throw this sort 
> of error?

for example: clang/test/Parser/parser_overflow.c


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[James Henderson via Phabricator via cfe-commits]

jhenderson added a subscriber: jasonliu.
jhenderson added a comment.

In D134284#3802793 , @DiggerLin wrote:

> In D134284#3802791 , @jhenderson 
> wrote:
>
>> In D134284#3802766 , @DiggerLin 
>> wrote:
>>
>>> In D134284#3802763 , @jhenderson 
>>> wrote:
>>>
 Wouldn't it be better to change the lit config to specify the 
 `OBJECT_MODE` environment variable on AIX?
>>>
>>> I have tried it before, I added the following in clang/test/lit.cfg.py
>>>
>>>   if 'system-aix' in config.available_features:
>>>config.environment['OBJECT_MODE'] = 'any' 
>>>
>>> it will cause  clang some problem in some test cases. something like 
>>> ,"clang-16: error: OBJECT_MODE setting any is not recognized and is not a 
>>> valid setting"
>>
>> Not sure I entirely follow. If `OBJECT_MODE` isn't an environment variable 
>> that clang uses, surely it should ignore it? What clang tests throw this 
>> sort of error?
>
> for example: clang/test/Parser/parser_overflow.c
>
>   Input was:
> 1: clang-16: error: OBJECT_MODE setting any is not recognized and is 
> not a valid setting

It looks to me like 
https://github.com/llvm/llvm-project/blob/b982ba2a6e0f11340b4e75d1d4eba9ff62a81df7/clang/lib/Driver/Driver.cpp#L554
 should be modified to accept the OBJECT_MODE values you've implemented for 
llvm-nm and llvm-ar. Otherwise, you'll never be able to use the `any` and 
`32_64` values supported by those tools as full environment variables (as 
opposed to variables set for a single or limited set of commands) on a system 
where clang is also used.

I'm neither a clang nor an AIX developer though, so my opinion is based only on 
what I've been reviewing in the llvm tools so far. Pinging @daltenty who 
implemented the functionality (see D82476 ) 
and @hubert.reinterpretcast and @jasonliu who reviewed it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[David Tenty via Phabricator via cfe-commits]

daltenty added a comment.

> If OBJECT_MODE isn't an environment variable that clang uses, surely it 
> should ignore it?

The clang driver does in fact respect OBJECT_MODE on AIX, but I'm guessing it 
doesn't accept the `any` setting (since it doesn't really make sense in that 
context).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin added a comment.

In D134284#3802806 , @daltenty wrote:

>> If OBJECT_MODE isn't an environment variable that clang uses, surely it 
>> should ignore it?
>
> The clang driver does in fact respect OBJECT_MODE on AIX, but I'm guessing it 
> doesn't accept the `any` setting (since it doesn't really make sense in that 
> context).
>
> Maybe it's better to leave the `llvm-nm` default as `any` even on AIX? It 
> doesn't match the system 'nm' but other wise we diverge from the `llvm-nm` 
> behaviour on other platforms it seems, and cause these test issues.

if change to default is Xany, the default value will be different with llvm-ar 
-X option(default value is -X32), that means llvm tool has different default -X 
option value on AIX OS.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8aed4bb - [CMake] [NFC] Add clang headers to IDE projects

[Chris Bieneman via cfe-commits]

Author: Chris Bieneman
Date: 2022-09-20T10:41:27-05:00
New Revision: 8aed4bb2783d32c40fae998b6518cd40a16b6ec5

URL: 
https://github.com/llvm/llvm-project/commit/8aed4bb2783d32c40fae998b6518cd40a16b6ec5
DIFF: 
https://github.com/llvm/llvm-project/commit/8aed4bb2783d32c40fae998b6518cd40a16b6ec5.diff

LOG: [CMake] [NFC] Add clang headers to IDE projects

This just adds the clang headers into a source group so that they get
collected and added into generated IDE projects.

Added: 


Modified: 
clang/lib/Headers/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Headers/CMakeLists.txt 
b/clang/lib/Headers/CMakeLists.txt
index 6e2060991b921..c374580ceb5c8 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -646,3 +646,5 @@ if (NOT LLVM_ENABLE_IDE)
DEPENDS utility-resource-headers
COMPONENT utility-resource-headers)
 endif()
+
+source_group("Clang Runtime Headers" FILES ${files})



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[David Tenty via Phabricator via cfe-commits]

daltenty added a comment.

> It looks to me like 
> https://github.com/llvm/llvm-project/blob/b982ba2a6e0f11340b4e75d1d4eba9ff62a81df7/clang/lib/Driver/Driver.cpp#L554
>  should be modified to accept the OBJECT_MODE values you've implemented for 
> llvm-nm and llvm-ar. Otherwise, you'll never be able to use the any and 32_64 
> values supported by those tools as full environment variables (as opposed to 
> variables set for a single or limited set of commands) on a system where 
> clang is also used.

Those settings don't really make sense for clang since you need to pick a 
single target and aren't typically supported for a compiler driver on AIX. For 
example the XL compiler would give you:

  error: 1501-255 OBJECT_MODE setting is not recognized and is not a valid 
setting for the compiler.

if you try `OBJECT_MODE=any`, so I don't think most folks are using such an 
environment setting on AIX currently (i.e. typically they select either 32 or 
64).

I prefect the solution of adding something to the lit config rather than 
modifying individual tests, since I doubt most LLVM developers are not going to 
know to add -X any to their tests just for AIX. Ideally we’d find a way to get 
those tools to act in the AIX fashion, without placing the burden on developers 
to add options in their tests.

Maybe we can distinguish OBJECT_MODE settings for LLVM tools (which generally 
accept `any`) from a setting for the driver (which can't)? Something like a 
`TOOL_OBJECT_MODE` env which is preferred for the tools.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

Instead of applying `OBJECT_MODE` to everything, maybe we can apply it only to 
the tool invocations via a LIT expansion?
Something like `%llvm-nm` that expands (for AIX) to `OBJECT_MODE=any llvm-nm`?

Would need to check that the LIT internal shell accepts that syntax.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: erichkeane, jyknight, rsmith, rjmccall, 
clang-language-wg.
Herald added a subscriber: martong.
Herald added a reviewer: shafik.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

This implements WG14 N2927 and WG14 N2930, which together define the feature 
for `typeof` and `typeof_unqual`, which get the type of their argument as 
either fully qualified or fully unqualified. The argument to either operator is 
either a type name or an expression. If given a type name, the type information 
is pulled directly from the given name. If given an expression, the type 
information is pulled from the expression. Recursive use of these operators is 
allowed and has the expected behavior (the innermost operator is resolved to a 
type, and that's used to resolve the next layer of typeof specifier, until a 
fully resolved type is determined.

Note, we already supported `typeof` in GNU mode as a non-conforming extension 
and we are *not* exposing `typeof_unqual` as a non-conforming extension in that 
mode, nor are we exposing `typeof` or `typeof_unqual` as a nonconforming 
extension in other language modes. The GNU variant of `typeof` supports a form 
where the parentheses are elided from the operator when given an expression 
(e.g., `typeof 0 i = 12;`). When in C2x mode, we do not support this extension.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134286

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/C/C2x/n2927.c
  clang/test/C/C2x/n2927_2.c
  clang/test/C/C2x/n2930.c
  clang/test/Lexer/keywords_test.c
  clang/test/Parser/c2x-typeof-ext-warns.c
  clang/test/Parser/c2x-typeof.c
  clang/test/Sema/c2x-typeof.c

Index: clang/test/Sema/c2x-typeof.c
===
--- /dev/null
+++ clang/test/Sema/c2x-typeof.c
@@ -0,0 +1,94 @@
+// RUN: %clang_cc1 -verify -std=c2x %s
+
+// Demonstrate that we get the correct type information. Do this by leaning
+// heavily on redeclarations needing to use the same type for both decls.
+extern int i;
+extern typeof(i) i;
+extern typeof_unqual(i) i;
+
+extern const int j;
+extern typeof(j) j;
+
+extern const int n; // expected-note 2 {{previous declaration is here}}
+extern typeof(i) n; // expected-error {{redeclaration of 'n' with a different type: 'typeof (i)' (aka 'int') vs 'const int'}}
+extern typeof_unqual(n) n;  // expected-error {{redeclaration of 'n' with a different type: 'typeof_unqual (n)' (aka 'int') vs 'const int'}}
+
+// Ensure we get a redeclaration error here for the types not matching.
+extern typeof(j) k;// expected-note {{previous declaration is here}}
+extern typeof_unqual(j) k; // expected-error {{redeclaration of 'k' with a different type: 'typeof_unqual (j)' (aka 'int') vs 'typeof (j)' (aka 'const int')}}
+
+// Make sure the type-form of the operator also works.
+extern typeof(int) l;
+extern typeof_unqual(const int) l;
+
+extern typeof(const int) m;// expected-note {{previous declaration is here}}
+extern typeof_unqual(const int) m; // expected-error {{redeclaration of 'm' with a different type: 'typeof_unqual(const int)' (aka 'int') vs 'typeof(const int)' (aka 'const int')}}
+
+// Show that we can use an incomplete type which is then completed later.
+extern typeof(struct T) *o;
+struct T { int a; } t;
+extern typeof(struct T) *o;
+extern typeof(t) *o;
+extern typeof(&t) o;
+extern typeof_unqual(volatile struct T) *o;
+extern typeof_unqual(t) *o;
+extern typeof_unqual(&t) o;
+
+// Show that we properly strip the _Atomic qualifier.
+extern _Atomic int i2;
+extern _Atomic(int) i2;
+extern typeof(i2) i2;// expected-note {{previous declaration is here}}
+extern typeof_unqual(i2) i2; // expected-error {{redeclaration of 'i2' with a different type: 'typeof_unqual (i2)' (aka 'int') vs 'typeof (i2)' (aka '_Atomic(int)')}}
+
+// We cannot take the type of a bit-field.
+struct S {
+  int bit : 4;
+} s;
+
+typeof(s.bit) nope1; // expected-error {{invalid application of 'typeof' to bit-field}}
+typeof_unqual(s.bit) nope2; // expected-error {{invalid application of 'typeof_unqual' to bit-field}}

[clang] 0c89b34 - [HLSL] Pass flags to cc1 based on language

[Chris Bieneman via cfe-commits]

Author: Chris Bieneman
Date: 2022-09-20T10:56:17-05:00
New Revision: 0c89b343371fca437a86093a01dc5eb6ed1a4a9b

URL: 
https://github.com/llvm/llvm-project/commit/0c89b343371fca437a86093a01dc5eb6ed1a4a9b
DIFF: 
https://github.com/llvm/llvm-project/commit/0c89b343371fca437a86093a01dc5eb6ed1a4a9b.diff

LOG: [HLSL] Pass flags to cc1 based on language

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

Added: 


Modified: 
clang/include/clang/Driver/Types.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/Types.cpp
clang/test/Driver/hlsl_no_stdinc.hlsl

Removed: 




diff  --git a/clang/include/clang/Driver/Types.h 
b/clang/include/clang/Driver/Types.h
index fc5dd7bbfd6f..4a21af3534de 100644
--- a/clang/include/clang/Driver/Types.h
+++ b/clang/include/clang/Driver/Types.h
@@ -95,6 +95,9 @@ namespace types {
   /// isOpenCL - Is this an "OpenCL" input.
   bool isOpenCL(ID Id);
 
+  /// isHLSL - Is this an HLSL input.
+  bool isHLSL(ID Id);
+
   /// isSrcFile - Is this a source file, i.e. something that still has to be
   /// preprocessed. The logic behind this is the same that decides if the first
   /// compilation phase is a preprocessing one.

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 34caeaf0f6af..7af0f9998455 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3529,12 +3529,14 @@ static void RenderHLSLOptions(const ArgList &Args, 
ArgStringList &CmdArgs,
  options::OPT_disable_llvm_passes,
  options::OPT_fnative_half_type,
  options::OPT_hlsl_entrypoint};
-
+  if (!types::isHLSL(InputType))
+return;
   for (const auto &Arg : ForwardedArguments)
 if (const auto *A = Args.getLastArg(Arg))
   A->renderAsInput(Args, CmdArgs);
   // Add the default headers if dxc_no_stdinc is not set.
-  if (!Args.hasArg(options::OPT_dxc_no_stdinc))
+  if (!Args.hasArg(options::OPT_dxc_no_stdinc) &&
+  !Args.hasArg(options::OPT_nostdinc))
 CmdArgs.push_back("-finclude-default-header");
 }
 
@@ -6389,8 +6391,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
   RenderOpenCLOptions(Args, CmdArgs, InputType);
 
   // Forward hlsl options to -cc1
-  if (C.getDriver().IsDXCMode())
-RenderHLSLOptions(Args, CmdArgs, InputType);
+  RenderHLSLOptions(Args, CmdArgs, InputType);
 
   if (IsHIP) {
 if (Args.hasFlag(options::OPT_fhip_new_launch_api,

diff  --git a/clang/lib/Driver/Types.cpp b/clang/lib/Driver/Types.cpp
index 6e30bb744b4f..ffbca82c98c3 100644
--- a/clang/lib/Driver/Types.cpp
+++ b/clang/lib/Driver/Types.cpp
@@ -286,6 +286,8 @@ bool types::isHIP(ID Id) {
   }
 }
 
+bool types::isHLSL(ID Id) { return Id == TY_HLSL; }
+
 bool types::isSrcFile(ID Id) {
   return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
 }

diff  --git a/clang/test/Driver/hlsl_no_stdinc.hlsl 
b/clang/test/Driver/hlsl_no_stdinc.hlsl
index ec6d0612a9ed..b5567aae5236 100644
--- a/clang/test/Driver/hlsl_no_stdinc.hlsl
+++ b/clang/test/Driver/hlsl_no_stdinc.hlsl
@@ -1,5 +1,7 @@
 // RUN: %clang_dxc  -Tlib_6_7 -fcgl -Fo - %s -### 2>&1 | FileCheck %s 
--check-prefix=STDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -o - %s -### 2>&1 | 
FileCheck %s --check-prefix=STDINC
 // RUN: %clang_dxc  -Tlib_6_7 -hlsl-no-stdinc -fcgl -Fo - %s -### 2>&1 | 
FileCheck %s --check-prefix=NOSTDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -nostdinc -o - %s -### 
2>&1 | FileCheck %s --check-prefix=NOSTDINC
 
 // RUN: %clang -cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -ast-dump 
-o - %s -verify
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133958: [HLSL] Pass flags to cc1 based on language

[Chris Bieneman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0c89b343371f: [HLSL] Pass flags to cc1 based on language 
(authored by beanz).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133958/new/

https://reviews.llvm.org/D133958

Files:
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/Types.cpp
  clang/test/Driver/hlsl_no_stdinc.hlsl


Index: clang/test/Driver/hlsl_no_stdinc.hlsl
===
--- clang/test/Driver/hlsl_no_stdinc.hlsl
+++ clang/test/Driver/hlsl_no_stdinc.hlsl
@@ -1,5 +1,7 @@
 // RUN: %clang_dxc  -Tlib_6_7 -fcgl -Fo - %s -### 2>&1 | FileCheck %s 
--check-prefix=STDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -o - %s -### 2>&1 | 
FileCheck %s --check-prefix=STDINC
 // RUN: %clang_dxc  -Tlib_6_7 -hlsl-no-stdinc -fcgl -Fo - %s -### 2>&1 | 
FileCheck %s --check-prefix=NOSTDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -nostdinc -o - %s -### 
2>&1 | FileCheck %s --check-prefix=NOSTDINC
 
 // RUN: %clang -cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -ast-dump 
-o - %s -verify
 
Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -286,6 +286,8 @@
   }
 }
 
+bool types::isHLSL(ID Id) { return Id == TY_HLSL; }
+
 bool types::isSrcFile(ID Id) {
   return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3529,12 +3529,14 @@
  options::OPT_disable_llvm_passes,
  options::OPT_fnative_half_type,
  options::OPT_hlsl_entrypoint};
-
+  if (!types::isHLSL(InputType))
+return;
   for (const auto &Arg : ForwardedArguments)
 if (const auto *A = Args.getLastArg(Arg))
   A->renderAsInput(Args, CmdArgs);
   // Add the default headers if dxc_no_stdinc is not set.
-  if (!Args.hasArg(options::OPT_dxc_no_stdinc))
+  if (!Args.hasArg(options::OPT_dxc_no_stdinc) &&
+  !Args.hasArg(options::OPT_nostdinc))
 CmdArgs.push_back("-finclude-default-header");
 }
 
@@ -6389,8 +6391,7 @@
   RenderOpenCLOptions(Args, CmdArgs, InputType);
 
   // Forward hlsl options to -cc1
-  if (C.getDriver().IsDXCMode())
-RenderHLSLOptions(Args, CmdArgs, InputType);
+  RenderHLSLOptions(Args, CmdArgs, InputType);
 
   if (IsHIP) {
 if (Args.hasFlag(options::OPT_fhip_new_launch_api,
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -95,6 +95,9 @@
   /// isOpenCL - Is this an "OpenCL" input.
   bool isOpenCL(ID Id);
 
+  /// isHLSL - Is this an HLSL input.
+  bool isHLSL(ID Id);
+
   /// isSrcFile - Is this a source file, i.e. something that still has to be
   /// preprocessed. The logic behind this is the same that decides if the first
   /// compilation phase is a preprocessing one.


Index: clang/test/Driver/hlsl_no_stdinc.hlsl
===
--- clang/test/Driver/hlsl_no_stdinc.hlsl
+++ clang/test/Driver/hlsl_no_stdinc.hlsl
@@ -1,5 +1,7 @@
 // RUN: %clang_dxc  -Tlib_6_7 -fcgl -Fo - %s -### 2>&1 | FileCheck %s --check-prefix=STDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -o - %s -### 2>&1 | FileCheck %s --check-prefix=STDINC
 // RUN: %clang_dxc  -Tlib_6_7 -hlsl-no-stdinc -fcgl -Fo - %s -### 2>&1 | FileCheck %s --check-prefix=NOSTDINC
+// RUN: %clang -target dxil-pc-shadermodel6.3-library -nostdinc -o - %s -### 2>&1 | FileCheck %s --check-prefix=NOSTDINC
 
 // RUN: %clang -cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -ast-dump -o - %s -verify
 
Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -286,6 +286,8 @@
   }
 }
 
+bool types::isHLSL(ID Id) { return Id == TY_HLSL; }
+
 bool types::isSrcFile(ID Id) {
   return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3529,12 +3529,14 @@
  options::OPT_disable_llvm_passes,
  options::OPT_fnative_half_type,
  options::OPT_hlsl_entrypoint};
-
+  if (!types::isHLSL(InputType))
+return;
   for (const auto &Arg : ForwardedArguments)
 if (const auto *A = Args.getLas

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 461583.
aaron.ballman added a comment.

Updated the C status page accordingly.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/C/C2x/n2927.c
  clang/test/C/C2x/n2927_2.c
  clang/test/C/C2x/n2930.c
  clang/test/Lexer/keywords_test.c
  clang/test/Parser/c2x-typeof-ext-warns.c
  clang/test/Parser/c2x-typeof.c
  clang/test/Sema/c2x-typeof.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -1092,17 +1092,11 @@
 

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm";>N2927
-
-  Partial
-Clang supports typeof in GNU standards mode, but its
-compatibility with this proposal is unknown. Also, Clang does not yet
-support remove_quals.
-  
-
+Clang 16
   

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2930.pdf";>N2930
-No
+Clang 16
   
 
   Type annex tgmath narrowing macros with integer args v2
Index: clang/test/Sema/c2x-typeof.c
===
--- /dev/null
+++ clang/test/Sema/c2x-typeof.c
@@ -0,0 +1,94 @@
+// RUN: %clang_cc1 -verify -std=c2x %s
+
+// Demonstrate that we get the correct type information. Do this by leaning
+// heavily on redeclarations needing to use the same type for both decls.
+extern int i;
+extern typeof(i) i;
+extern typeof_unqual(i) i;
+
+extern const int j;
+extern typeof(j) j;
+
+extern const int n; // expected-note 2 {{previous declaration is here}}
+extern typeof(i) n; // expected-error {{redeclaration of 'n' with a different type: 'typeof (i)' (aka 'int') vs 'const int'}}
+extern typeof_unqual(n) n;  // expected-error {{redeclaration of 'n' with a different type: 'typeof_unqual (n)' (aka 'int') vs 'const int'}}
+
+// Ensure we get a redeclaration error here for the types not matching.
+extern typeof(j) k;// expected-note {{previous declaration is here}}
+extern typeof_unqual(j) k; // expected-error {{redeclaration of 'k' with a different type: 'typeof_unqual (j)' (aka 'int') vs 'typeof (j)' (aka 'const int')}}
+
+// Make sure the type-form of the operator also works.
+extern typeof(int) l;
+extern typeof_unqual(const int) l;
+
+extern typeof(const int) m;// expected-note {{previous declaration is here}}
+extern typeof_unqual(const int) m; // expected-error {{redeclaration of 'm' with a different type: 'typeof_unqual(const int)' (aka 'int') vs 'typeof(const int)' (aka 'const int')}}
+
+// Show that we can use an incomplete type which is then completed later.
+extern typeof(struct T) *o;
+struct T { int a; } t;
+extern typeof(struct T) *o;
+extern typeof(t) *o;
+extern typeof(&t) o;
+extern typeof_unqual(volatile struct T) *o;
+extern typeof_unqual(t) *o;
+extern typeof_unqual(&t) o;
+
+// Show that we properly strip the _Atomic qualifier.
+extern _Atomic int i2;
+extern _Atomic(int) i2;
+extern typeof(i2) i2;// expected-note {{previous declaration is here}}
+extern typeof_unqual(i2) i2; // expected-error {{redeclaration of 'i2' with a different type: 'typeof_unqual (i2)' (aka 'int') vs 'typeof (i2)' (aka '_Atomic(int)')}}
+
+// We cannot take the type of a bit-field.
+struct S {
+  int bit : 4;
+} s;
+
+typeof(s.bit) nope1; // expected-error {{invalid application of 'typeof' to bit-field}}
+typeof_unqual(s.bit) nope2; // expected-error {{invalid application of 'typeof_unqual' to bit-field}}
+
+// Show that we properly resolve nested typeof specifiers.
+extern typeof(typeof(0)) i3;
+extern typeof(typeof(int)) i3;
+extern typeof(typeof_unqual(0)) i3;
+extern typeof(typeof_unqual(int)) i3;
+extern typeof_unqual(typeof(0)) i3;
+extern typeof_unqual(typeof(int)) i3;
+extern typeof_unqual(typeof_unqual(0)) i3;
+extern typeof_unqual(typeof_unqual(int)) i3;
+extern typeof(typeof_unqual(j)) i3;
+extern typeof(typeof_unqual(const int)) i3;
+extern typeof_unqual(typeof(j)) i3;
+extern typeof_unqual(typeof(const int)) i3;
+extern ty

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D133468#3802727 , @davrec wrote:

> what is the different principle behind choosing a different underlying type?  
>  Why can't the underlying type for `t29`/`t32` be sugar for X1 and friends 
> too?

The underlying type is taken from the mechanism implemented in D130308 
, but it's not a different principle. We are 
still trying to keep the information they have in common, and go towards the 
canonical state when there is a difference.

> If we absolutely have to allow these types to diverge, we need very good 
> documentation that helps them answer this.

We are adding the minimum amount of new information to the AST to get what we 
want: A TypedefType which can have an underlying different from the one in the 
declaration it references.
This is the minimum we need in order to be able to represent a resugared 
typedef, without losing the information that the type came from a typedef in 
the first place.

Otherwise, just knowing that they can diverge doesn't help much, they would 
still be missing the reason of why they diverged, and that will depend on what 
mechanisms were at play.

There is an engineering compromise in that we don't want to pack new AST nodes 
that help fully expose that some divergence was created either by type 
combination, or by template specialization resugaring (when that is 
implemented), to avoid ballooning complexity with information that might not be 
useful.

But if that information were important, that could justify the cost in memory 
and complexity. Do you foresee any need for it?

Otherwise, the `isDivergent()` flag is there just for exposition / debugging 
purposes when looking at the AST dump, as I find that helpful.
But we could not add the method and not print a flag in the AST dumper, 
implementing just the behavior change.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133468/new/

https://reviews.llvm.org/D133468

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Louis Dionne via Phabricator via cfe-commits]

ldionne accepted this revision.
ldionne added inline comments.



Comment at: clang/www/hacking.html:311-312
+  Unlike Clang, libc++ supports multiple versions of Clang. Therefore when a
+  patch changes the diagnostics it might be required to use a regex in the
+  "expected" tests to make it pass the CI.
+

Mordante wrote:
> Mordante wrote:
> > philnik wrote:
> > > aaron.ballman wrote:
> > > > Should we document the expectation that breaking libc++ due to 
> > > > conforming changes in Clang (in terms of diagnostics and bug fixes, not 
> > > > so much in terms of introducing new language extensions) are generally 
> > > > the responsibility of libc++ maintainers to address, but Clang 
> > > > contributors should attempt to reduce disruptions as much as possible 
> > > > by collaborating with libc++ maintainers when this situation comes up?
> > > That's definitely a good idea. Maybe mention that clang contributors 
> > > should ping the #libc group to get the attention of libc++ contributors 
> > > so we can prepare a follow-up patch or, if the author is comfortable with 
> > > it, also fix libc++ in the same patch (and hopefully get fast approval). 
> > > Most breakages should be relatively simple to fix.
> > I like the idea to collaborate more.
> > 
> > I want to give this some thought and especially how to word it. I want to 
> > avoid that it's seen as a carte blanche to commit Clang changes which break 
> > libc++. This would mean HEAD is broken and that's a huge issue for 
> > downstream users like Google who tend to follow HEAD closely.
> > 
> > I would prefer to use commandeering and instead of two patches where one 
> > leave HEAD in a broken state. Even if it's short it would make bi-secting 
> > harder. Personally I really dislike the idea of having commits that 
> > knowingly leave a repository in a broken state. It also doesn't align with 
> > the LLVM developer policy 
> > https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy 
> > ```
> > As a community, we strongly value having the tip of tree in a good state 
> > while allowing rapid iterative development. 
> > ```
> > 
> > Should we document the expectation that breaking libc++ due to conforming 
> > changes in Clang (in terms of diagnostics and bug fixes, not so much in 
> > terms of introducing new language extensions) are generally the 
> > responsibility of libc++ maintainers to address, but Clang contributors 
> > should attempt to reduce disruptions as much as possible by collaborating 
> > with libc++ maintainers when this situation comes up?
> 
> @aaron.ballman I have given this some thought. I think it would be best to 
> discuss this with some libc++ and Clang contributors/code owners. For libc++ 
> at least @ldionne should be present since he's the libc++ code owner. I would 
> like to be present too. After we have agreement we can update this 
> documentation accordingly.
I remember discussing this with @aaron.ballman.

I am 100% on-board with the notion that if Clang makes a legitimate conforming 
change and it breaks libc++ (most likely because we are doing something wrong, 
UB, or relying on Clang details), then it is *primarily* libc++'s 
responsibility to fix this ASAP. I also remember that we agreed it should be a 
collaborative effort, i.e. the Clang folks should try to help us understand the 
failure, and should be understanding if the fix on our side is really 
non-trivial. But, the bottom line is that if they change something and it 
breaks us because we're doing something wrong, it's our responsibility to fix 
our stuff ASAP to get the CI green again.

This is the same situation that we sometimes have with the LLDB data 
formatters, and I think the dynamics need to be the same there as well. If we 
break that because of a 100% legitimate change in libc++, our expectation is 
that they'll fix it ASAP, and their expectation is that we'll provide support 
as needed.

I think it would be useful to document that, since it technically departs from 
LLVM's usual policy of "revert when it breaks anything at all". And more 
generally speaking, I strongly think that this policy needs to be revisited, 
however that's beyond the scope of this documentation improvement.



Comment at: clang/www/hacking.html:306-308
+  documentation about the pre-commit CI. When having questions regarding
+  libc++, best ask them in the #libcxx channel on
+  https://discord.gg/jzUbyP26tQ";>LLVM's Discord server.





Comment at: libcxx/docs/Contributing.rst:103
+The CI tests libc++ for all :ref:`supported platforms `.
+The build is started for every diff uploaded. A complete CI run takes
+approximately one hour. To reduce the load:




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133249/new/

https://reviews.llvm.org/D133249

___
cfe-commits mailing l

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl updated this revision to Diff 461588.
mingmingl added a comment.

It has been a while since this patch was updated, rebase for review now that 
the Github PR was accepted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127798/new/

https://reviews.llvm.org/D127798

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/test/Preprocessor/aarch64-target-features.c


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -560,3 +561,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang --target=aarch64 -march=armv8.2-a+rcpc -x c -E -dM %s -o - | 
FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -551,6 +554,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -600,6 +604,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -560,3 +561,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang --target=aarch64 -march=armv8.2-a+rcpc -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -551,6 +554,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -600,6 +604,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl added a comment.

Hi folks,

  The ARM ACLE PR (https://github.com/ARM-software/acle/pull/199) was accepted. 
Would you take another look of this patch at your convenience? Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127798/new/

https://reviews.llvm.org/D127798

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132186: Clang: Add a new flag Wmisnoinline for printing hot noinline functions

[Paul Kirth via Phabricator via cfe-commits]

paulkirth added a comment.

@iamarchit123 I think the standard advice is to start w/ the llvm-test-suite 
and then explore other benchmarks as needed. Also, Clang itself is often a very 
good starting point.

As for profiles, it probably won't be representative, but you could collect the 
profile using your benchmark and then assess how often the mismatch w/ inlining 
happens. if you want to do it w/ Clang itself, then a common approach I've 
heard is to record have Clang build your project and then use ninja trace or 
equivalent to find the 5-10 TUs w/ the longest compile time. Then stick them in 
the https://github.com/llvm/llvm-project/tree/main/clang/utils/perf-training 
directory, which will use them for PGO automatically. If you go that route, you 
may need to preprocess the source files.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132186/new/

https://reviews.llvm.org/D132186

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/www/hacking.html:311-312
+  Unlike Clang, libc++ supports multiple versions of Clang. Therefore when a
+  patch changes the diagnostics it might be required to use a regex in the
+  "expected" tests to make it pass the CI.
+

ldionne wrote:
> Mordante wrote:
> > Mordante wrote:
> > > philnik wrote:
> > > > aaron.ballman wrote:
> > > > > Should we document the expectation that breaking libc++ due to 
> > > > > conforming changes in Clang (in terms of diagnostics and bug fixes, 
> > > > > not so much in terms of introducing new language extensions) are 
> > > > > generally the responsibility of libc++ maintainers to address, but 
> > > > > Clang contributors should attempt to reduce disruptions as much as 
> > > > > possible by collaborating with libc++ maintainers when this situation 
> > > > > comes up?
> > > > That's definitely a good idea. Maybe mention that clang contributors 
> > > > should ping the #libc group to get the attention of libc++ contributors 
> > > > so we can prepare a follow-up patch or, if the author is comfortable 
> > > > with it, also fix libc++ in the same patch (and hopefully get fast 
> > > > approval). Most breakages should be relatively simple to fix.
> > > I like the idea to collaborate more.
> > > 
> > > I want to give this some thought and especially how to word it. I want to 
> > > avoid that it's seen as a carte blanche to commit Clang changes which 
> > > break libc++. This would mean HEAD is broken and that's a huge issue for 
> > > downstream users like Google who tend to follow HEAD closely.
> > > 
> > > I would prefer to use commandeering and instead of two patches where one 
> > > leave HEAD in a broken state. Even if it's short it would make bi-secting 
> > > harder. Personally I really dislike the idea of having commits that 
> > > knowingly leave a repository in a broken state. It also doesn't align 
> > > with the LLVM developer policy 
> > > https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy 
> > > ```
> > > As a community, we strongly value having the tip of tree in a good state 
> > > while allowing rapid iterative development. 
> > > ```
> > > 
> > > Should we document the expectation that breaking libc++ due to conforming 
> > > changes in Clang (in terms of diagnostics and bug fixes, not so much in 
> > > terms of introducing new language extensions) are generally the 
> > > responsibility of libc++ maintainers to address, but Clang contributors 
> > > should attempt to reduce disruptions as much as possible by collaborating 
> > > with libc++ maintainers when this situation comes up?
> > 
> > @aaron.ballman I have given this some thought. I think it would be best to 
> > discuss this with some libc++ and Clang contributors/code owners. For 
> > libc++ at least @ldionne should be present since he's the libc++ code 
> > owner. I would like to be present too. After we have agreement we can 
> > update this documentation accordingly.
> I remember discussing this with @aaron.ballman.
> 
> I am 100% on-board with the notion that if Clang makes a legitimate 
> conforming change and it breaks libc++ (most likely because we are doing 
> something wrong, UB, or relying on Clang details), then it is *primarily* 
> libc++'s responsibility to fix this ASAP. I also remember that we agreed it 
> should be a collaborative effort, i.e. the Clang folks should try to help us 
> understand the failure, and should be understanding if the fix on our side is 
> really non-trivial. But, the bottom line is that if they change something and 
> it breaks us because we're doing something wrong, it's our responsibility to 
> fix our stuff ASAP to get the CI green again.
> 
> This is the same situation that we sometimes have with the LLDB data 
> formatters, and I think the dynamics need to be the same there as well. If we 
> break that because of a 100% legitimate change in libc++, our expectation is 
> that they'll fix it ASAP, and their expectation is that we'll provide support 
> as needed.
> 
> I think it would be useful to document that, since it technically departs 
> from LLVM's usual policy of "revert when it breaks anything at all". And more 
> generally speaking, I strongly think that this policy needs to be revisited, 
> however that's beyond the scope of this documentation improvement.
> I am 100% on-board with the notion that if Clang makes a legitimate 
> conforming change and it breaks libc++ (most likely because we are doing 
> something wrong, UB, or relying on Clang details), then it is *primarily* 
> libc++'s responsibility to fix this ASAP. I also remember that we agreed it 
> should be a collaborative effort, i.e. the Clang folks should try to help us 
> understand the failure, and should be understanding if the fix on our side is 
> really non-trivial. But, the bottom line is that if they change something and 
> it breaks us because we're doing something wrong,

[PATCH] D133583: [clang][ubsan] Fix __builtin_assume_aligned incorrect type descriptor and C++ object polymorphic address

[Aaron Ballman via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8392f1cc7827: Fix __builtin_assume_aligned incorrect type 
descriptor and C++ object… (authored by yronglin, committed by aaron.ballman).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133583/new/

https://reviews.llvm.org/D133583

Files:
  clang/include/clang/Basic/Builtins.def
  clang/lib/Basic/Builtins.cpp
  clang/lib/Sema/SemaChecking.cpp
  
clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
  clang/test/Sema/builtin-redecl.cpp

Index: clang/test/Sema/builtin-redecl.cpp
===
--- clang/test/Sema/builtin-redecl.cpp
+++ clang/test/Sema/builtin-redecl.cpp
@@ -2,6 +2,8 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify -x c
 // RUN: %clang_cc1 %s -fsyntax-only -verify -fms-compatibility
 
+typedef __typeof__(sizeof(0)) size_t;
+
 // Redeclaring library builtins is OK.
 void exit(int);
 
@@ -16,3 +18,9 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify -x c
 
 void __va_start(__builtin_va_list*, ...);
+
+#ifdef __cplusplus
+void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
+#else
+void *__builtin_assume_aligned(const void *, size_t, ...);
+#endif
Index: clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
===
--- /dev/null
+++ clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -fsanitize=alignment -fno-sanitize-recover=alignment -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck %s -implicit-check-not="call void @__ubsan_handle_alignment_assumption" --check-prefixes=CHECK,CHECK-SANITIZE,CHECK-SANITIZE-ANYRECOVER,CHECK-SANITIZE-NORECOVER,CHECK-SANITIZE-UNREACHABLE
+// RUN: %clang_cc1 -no-opaque-pointers -fsanitize=alignment -fsanitize-recover=alignment -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck %s -implicit-check-not="call void @__ubsan_handle_alignment_assumption" --check-prefixes=CHECK,CHECK-SANITIZE,CHECK-SANITIZE-ANYRECOVER,CHECK-SANITIZE-RECOVER
+// RUN: %clang_cc1 -no-opaque-pointers -fsanitize=alignment -fsanitize-trap=alignment -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck %s -implicit-check-not="call void @__ubsan_handle_alignment_assumption" --check-prefixes=CHECK,CHECK-SANITIZE,CHECK-SANITIZE-TRAP,CHECK-SANITIZE-UNREACHABLE
+
+// CHECK-SANITIZE-ANYRECOVER: @[[CHAR:.*]] = {{.*}} c"'B *'\00" }
+// CHECK-SANITIZE-ANYRECOVER: @[[LINE_100_ALIGNMENT_ASSUMPTION:.*]] = {{.*}}, i32 100, i32 35 }, {{.*}}* @[[CHAR]] }
+
+struct A { int n; };
+struct B { int n; };
+struct C : A, B {};
+
+void *f(C *c) {
+  // CHECK: define {{.*}} i8* @{{.*}}(%struct.C* noundef %[[C:.*]]) {{.*}} {
+  // CHECK-NEXT:[[ENTRY:.*]]:
+  // CHECK-NEXT:  %[[C_ADDR:.*]] = alloca %struct.C*
+  // CHECK-NEXT:  store %struct.C* %[[C]], %struct.C** %[[C_ADDR]]
+  // CHECK-NEXT:  %[[C_RELOAD:.*]] = load %struct.C*, %struct.C** %[[C_ADDR]]
+  // CHECK-NEXT:  %[[IS_NULL:.*]] = icmp eq %struct.C* %[[C_RELOAD]], null
+  // CHECK-NEXT:  br i1 %[[IS_NULL]], label %[[CAST_END:[^,]+]], label %[[CAST_NOT_NULL:[^,]+]]
+  // CHECK: [[CAST_NOT_NULL]]:
+  // CHECK-NOSANITIZE-NEXT:   %[[BITCAST:.*]] = bitcast %struct.C* %[[C_RELOAD]] to i8*
+  // CHECK-NOSANITIZE-NEXT:   %[[ADD_PTR:.*]] = getelementptr inbounds i8, i8* %[[BITCAST]], i64 4
+  // CHECK-NOSANITIZE-NEXT:   %[[BITCAST2:.*]] = bitcast i8* %[[ADD_PTR]] to %struct.B*
+  // CHECK-NOSANITIZE-NEXT:   br label %[[CAST_END]]
+  // CHECK-SANITIZE-NEXT: %[[PTRTOINT:.*]] = ptrtoint %struct.C* %[[C_RELOAD]] to i64, !nosanitize
+  // CHECK-SANITIZE-NEXT: %[[MASKEDPTR:.*]] = and i64 %[[PTRTOINT]], 3, !nosanitize
+  // CHECK-SANITIZE-NEXT: %[[MASKCOND:.*]] = icmp eq i64 %[[MASKEDPTR]], 0, !nosanitize
+  // CHECK-SANITIZE-NEXT: br i1 %[[MASKCOND]], label %[[CONT:[^,]+]], label %[[HANDLER_TYPE_MISMATCH:[^,]+]]
+  // CHECK-SANITIZE:[[HANDLER_TYPE_MISMATCH]]:
+  // CHECK-SANITIZE-NORECOVER-NEXT:   call void @__ubsan_handle_type_mismatch_v1_abort(
+  // CHECK-SANITIZE-RECOVER-NEXT: call void @__ubsan_handle_type_mismatch_v1(
+  // CHECK-SANITIZE-TRAP-NEXT:call void @llvm.ubsantrap(
+  // CHECK-SANITIZE-UNREACHABLE-NEXT: unreachable, !nosanitize
+  // CHECK-SANITIZE:[[CONT]]:
+  // CHECK-SANITIZE-NEXT: %[[BITCAST:.*

[clang] 8392f1c - Fix __builtin_assume_aligned incorrect type descriptor and C++ object polymorphic address

[Aaron Ballman via cfe-commits]

Author: yronglin
Date: 2022-09-20T12:35:18-04:00
New Revision: 8392f1cc78270c7039970b413dfd836bf4def602

URL: 
https://github.com/llvm/llvm-project/commit/8392f1cc78270c7039970b413dfd836bf4def602
DIFF: 
https://github.com/llvm/llvm-project/commit/8392f1cc78270c7039970b413dfd836bf4def602.diff

LOG: Fix __builtin_assume_aligned incorrect type descriptor and C++ object 
polymorphic address

Fix __builtin_assume_aligned incorrect type descriptor

example from @rsmith

struct A { int n; };
struct B { int n; };
struct C : A, B {};

void *f(C *c) {
  // Incorrectly returns `c` rather than the address of the B base class.
  return __builtin_assume_aligned((B*)c, 8);
}

Differential Revision: https://reviews.llvm.org/D133583

Added: 

clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp

Modified: 
clang/include/clang/Basic/Builtins.def
clang/lib/Basic/Builtins.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/builtin-redecl.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index 249a3913dc0b6..dc7671ed16cec 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -546,7 +546,7 @@ BUILTIN(__builtin_va_start, "vA.", "nt")
 BUILTIN(__builtin_va_end, "vA", "n")
 BUILTIN(__builtin_va_copy, "vAA", "n")
 BUILTIN(__builtin_stdarg_start, "vA.", "nt")
-BUILTIN(__builtin_assume_aligned, "v*vC*z.", "nc")
+BUILTIN(__builtin_assume_aligned, "v*vC*z.", "nct")
 BUILTIN(__builtin_bcmp, "ivC*vC*z", "Fn")
 BUILTIN(__builtin_bcopy, "vv*v*z", "n")
 BUILTIN(__builtin_bzero, "vv*z", "nF")

diff  --git a/clang/lib/Basic/Builtins.cpp b/clang/lib/Basic/Builtins.cpp
index b42e8f416cfca..0e0566878c30c 100644
--- a/clang/lib/Basic/Builtins.cpp
+++ b/clang/lib/Basic/Builtins.cpp
@@ -209,6 +209,7 @@ bool Builtin::Context::performsCallback(unsigned ID,
 
 bool Builtin::Context::canBeRedeclared(unsigned ID) const {
   return ID == Builtin::NotBuiltin || ID == Builtin::BI__va_start ||
+ ID == Builtin::BI__builtin_assume_aligned ||
  (!hasReferenceArgsOrResult(ID) && !hasCustomTypechecking(ID)) ||
  isInStdNamespace(ID);
 }

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index e419287014893..1b74b091dd270 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -141,6 +141,15 @@ static bool checkArgCountAtMost(Sema &S, CallExpr *Call, 
unsigned MaxArgCount) {
  << Call->getSourceRange();
 }
 
+/// Checks that a call expression's argument count is in the desired range. 
This
+/// is useful when doing custom type-checking on a variadic function. Returns
+/// true on error.
+static bool checkArgCountRange(Sema &S, CallExpr *Call, unsigned MinArgCount,
+   unsigned MaxArgCount) {
+  return checkArgCountAtLeast(S, Call, MinArgCount) ||
+ checkArgCountAtMost(S, Call, MaxArgCount);
+}
+
 /// Checks that a call expression's argument count is the desired number.
 /// This is useful when doing custom type-checking.  Returns true on error.
 static bool checkArgCount(Sema &S, CallExpr *Call, unsigned DesiredArgCount) {
@@ -7651,17 +7660,15 @@ bool Sema::SemaBuiltinAllocaWithAlign(CallExpr 
*TheCall) {
 /// Handle __builtin_assume_aligned. This is declared
 /// as (const void*, size_t, ...) and can take one optional constant int arg.
 bool Sema::SemaBuiltinAssumeAligned(CallExpr *TheCall) {
-  if (checkArgCountAtMost(*this, TheCall, 3))
+  if (checkArgCountRange(*this, TheCall, 2, 3))
 return true;
 
   unsigned NumArgs = TheCall->getNumArgs();
   Expr *FirstArg = TheCall->getArg(0);
-  if (auto *CE = dyn_cast(FirstArg))
-FirstArg = CE->getSubExprAsWritten();
 
   {
 ExprResult FirstArgResult =
-DefaultFunctionArrayLvalueConversion(FirstArg, /*Diagnose=*/false);
+DefaultFunctionArrayLvalueConversion(FirstArg);
 if (FirstArgResult.isInvalid())
   return true;
 TheCall->setArg(0, FirstArgResult.get());

diff  --git 
a/clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
 
b/clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
new file mode 100644
index 0..2206a73472f1b
--- /dev/null
+++ 
b/clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-polymorphism.cpp
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 -no-opaque-pointers -emit-llvm %s -o - -triple 
x86_64-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -fsanitize=alignment 
-fno-sanitize-recover=alignment -emit-llvm %s -o - -triple x86_64-linux-gnu | 
FileCheck %s -implicit-check-not="call void 
@__ubsan_handle_alignment_assumption" 
--check-prefixes=CHECK,CHECK-SANITIZE,CHECK-SANITIZE-ANYRECOVER,CHECK-SANITIZE-NORECOVER,CHECK-SANITIZE-UNREACHABLE
+// RUN: %clang_cc1 -no-opaque-pointers -fsanitize=alig

[PATCH] D131939: [clang-tidy] Add performance-expensive-flat-container-operation check

[Nicolas van Kempen via Phabricator via cfe-commits]

nicovank updated this revision to Diff 461592.
nicovank added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131939/new/

https://reviews.llvm.org/D131939

Files:
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  
clang-tools-extra/clang-tidy/performance/ExpensiveFlatContainerOperationCheck.cpp
  
clang-tools-extra/clang-tidy/performance/ExpensiveFlatContainerOperationCheck.h
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance/expensive-flat-container-operation.rst
  
clang-tools-extra/test/clang-tidy/checkers/performance/expensive-flat-container-operation-only-warn-in-loops.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance/expensive-flat-container-operation.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance/expensive-flat-container-operation.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance/expensive-flat-container-operation.cpp
@@ -0,0 +1,383 @@
+// RUN: %check_clang_tidy %s performance-expensive-flat-container-operation %t -- \
+// RUN:   -config="{CheckOptions: \
+// RUN: [{key: performance-expensive-flat-container-operation.OnlyWarnInLoops, \
+// RUN:   value: false}] \
+// RUN: }"
+
+namespace std {
+template 
+struct pair {
+  pair(T1, T2);
+};
+
+template
+struct initializer_list {
+  initializer_list();
+};
+
+template struct remove_reference  { typedef T type; };
+template struct remove_reference  { typedef T type; };
+template struct remove_reference { typedef T type; };
+
+template
+typename std::remove_reference::type&& move(T&&) noexcept;
+} // namespace std
+
+// Copied from boost/container/flat_map.hpp and boost/container/flat_set.hpp and simplified.
+namespace boost {
+namespace container {
+struct ordered_unique_range_t {};
+
+template 
+struct flat_map {
+  typedef Key key_type;
+  typedef T mapped_type;
+  typedef std::pair value_type;
+
+  typedef int size_type;
+  typedef struct {} iterator;
+  typedef struct {} const_iterator;
+
+  const_iterator begin() const noexcept;
+  const_iterator end() const noexcept;
+
+  template  std::pair emplace(Args&&...);
+
+  template  iterator emplace_hint(const_iterator, Args&&...);
+
+  template  std::pair try_emplace(const key_type&, Args&&...);
+  template  iterator try_emplace(const_iterator, const key_type&, Args&&...);
+  template  std::pair try_emplace(key_type&&, Args&&...);
+  template  iterator try_emplace(const_iterator, key_type&&, Args&&...);
+
+  std::pair insert(const value_type&);
+  std::pair insert(value_type&&);
+  iterator insert(const_iterator, const value_type&);
+  iterator insert(const_iterator, value_type&&);
+  template  void insert(InputIterator, InputIterator);
+  template  void insert(ordered_unique_range_t, InputIterator, InputIterator);
+  void insert(std::initializer_list);
+  void insert(ordered_unique_range_t, std::initializer_list);
+
+  iterator erase(const_iterator);
+  size_type erase(const key_type&);
+  iterator erase(const_iterator, const_iterator);
+};
+
+template 
+struct flat_set {
+  typedef Key key_type;
+  typedef Key value_type;
+
+  typedef int size_type;
+  typedef struct {} iterator;
+  typedef struct {} const_iterator;
+
+  const_iterator begin() const noexcept;
+  const_iterator end() const noexcept;
+
+  template  std::pair emplace(Args&&...);
+
+  template  iterator emplace_hint(const_iterator, Args&&...);
+
+  std::pair insert(const value_type&);
+  std::pair insert(value_type&&);
+  iterator insert(const_iterator, const value_type&);
+  iterator insert(const_iterator, value_type&&);
+  template  void insert(InputIterator, InputIterator);
+  template  void insert(ordered_unique_range_t, InputIterator, InputIterator);
+  void insert(std::initializer_list);
+  void insert(ordered_unique_range_t, std::initializer_list);
+
+  iterator erase(const_iterator);
+  size_type erase(const key_type&);
+  iterator erase(const_iterator, const_iterator);
+};
+} // namespace container
+} // namespace boost
+
+// Copied from folly/sorted_vector_types.h and simplified.
+namespace folly {
+template  struct sorted_vector_map {
+  typedef Key key_type;
+  typedef Value mapped_type;
+  typedef std::pair value_type;
+
+  typedef int size_type;
+  typedef struct {} iterator;
+  typedef struct {} const_iterator;
+
+  const_iterator begin() const;
+  const_iterator end() const;
+
+  std::pair insert(const value_type&);
+  std::pair insert(value_type&&);
+  iterator insert(const_iterator, const value_type&);
+  iterator insert(const_iterator, value_type&&);
+  template  void insert(InputIterator, InputIterator);
+  void insert(std::initializer_list);
+
+  template  std::pair emplace(Args&&...);
+  std::pair emplace(const

[PATCH] D133583: [clang][ubsan] Fix __builtin_assume_aligned incorrect type descriptor and C++ object polymorphic address

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D133583#3802451 , @yronglin wrote:

> Thanks for take a review @aaron.ballman @rjmccall , can you land this patch 
> for me? Please use 'yronglin ' to commit the change.

Happy to do so! I've landed on your behalf in 
https://github.com/llvm/llvm-project/commit/8392f1cc78270c7039970b413dfd836bf4def602


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133583/new/

https://reviews.llvm.org/D133583

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131939: [clang-tidy] Add performance-expensive-flat-container-operation check

[Nicolas van Kempen via Phabricator via cfe-commits]

nicovank added a comment.

Ping.

F24615059: image.png 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131939/new/

https://reviews.llvm.org/D131939

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin updated this revision to Diff 461589.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

Files:
  clang/test/lit.cfg.py


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -283,3 +283,6 @@
 config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
 elif platform.system() == 'AIX':
 config.environment['AIXTHREAD_STK'] = '4194304'
+
+if 'system-aix' in config.available_features:
+config.substitutions.append(('llvm-nm', 'env OBJECT_MODE=any llvm-nm'))


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -283,3 +283,6 @@
 config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
 elif platform.system() == 'AIX':
 config.environment['AIXTHREAD_STK'] = '4194304'
+
+if 'system-aix' in config.available_features:
+config.substitutions.append(('llvm-nm', 'env OBJECT_MODE=any llvm-nm'))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change the clang tests with llvm-nm -Xany

[Digger Lin via Phabricator via cfe-commits]

DiggerLin updated this revision to Diff 461598.
DiggerLin added a comment.

address comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

Files:
  clang/test/lit.cfg.py


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -283,3 +283,13 @@
 config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
 elif platform.system() == 'AIX':
 config.environment['AIXTHREAD_STK'] = '4194304'
+
+# llvm-nm tools support an environment variable "OBJECT_MODE" on AIX OS, which
+# controls the kind of objects they will support. If there is no "OBJECT_MODE"
+# environment variable specified, the default behaviour is to support 32-bit
+# objects only. In order to not affect most test cases, which expect to support
+# 32-bit and 64-bit objects by default, set the environment variable
+# "OBJECT_MODE" to 'any' for llvm-nm on AIX OS.
+
+if 'system-aix' in config.available_features:
+config.substitutions.append(('llvm-nm', 'env OBJECT_MODE=any llvm-nm'))


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -283,3 +283,13 @@
 config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
 elif platform.system() == 'AIX':
 config.environment['AIXTHREAD_STK'] = '4194304'
+
+# llvm-nm tools support an environment variable "OBJECT_MODE" on AIX OS, which
+# controls the kind of objects they will support. If there is no "OBJECT_MODE"
+# environment variable specified, the default behaviour is to support 32-bit
+# objects only. In order to not affect most test cases, which expect to support
+# 32-bit and 64-bit objects by default, set the environment variable
+# "OBJECT_MODE" to 'any' for llvm-nm on AIX OS.
+
+if 'system-aix' in config.available_features:
+config.substitutions.append(('llvm-nm', 'env OBJECT_MODE=any llvm-nm'))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133583: [clang][ubsan] Fix __builtin_assume_aligned incorrect type descriptor and C++ object polymorphic address

[Lin Yurong via Phabricator via cfe-commits]

yronglin added a comment.

In D133583#3803002 , @aaron.ballman 
wrote:

> In D133583#3802451 , @yronglin 
> wrote:
>
>> Thanks for take a review @aaron.ballman @rjmccall , can you land this patch 
>> for me? Please use 'yronglin ' to commit the change.
>
> Happy to do so! I've landed on your behalf in 
> https://github.com/llvm/llvm-project/commit/8392f1cc78270c7039970b413dfd836bf4def602

Thanks very much!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133583/new/

https://reviews.llvm.org/D133583

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

I'm on the fence about re-using the same nodes for `typeof` and 
`typeof_unqual`.  However, I have a preference to stop shuffling a bool around 
everywhere as parameters, and would like an enum (even if we store it as a 
bitfield : 1).  Something like:

  enum class TypeofKind {
 Typeof, TypeofUnqual };

I think improves readability in a bunch of places, AND gives us less work to do 
if we need to extend this node in the future.




Comment at: clang/include/clang/AST/ASTContext.h:1718
   /// GCC extension.
-  QualType getTypeOfExprType(Expr *e) const;
-  QualType getTypeOfType(QualType t) const;
+  QualType getTypeOfExprType(Expr *E, bool IsUnqual) const;
+  QualType getTypeOfType(QualType QT, bool IsUnqual) const;

Mild preference for an enum, instead of a bool here.

Alternatively, depending on your design below that I haven't seen yet, perhaps 
unqual versions of these functions?



Comment at: clang/include/clang/AST/Type.h:4542
 
-  TypeOfExprType(Expr *E, QualType can = QualType());
+  TypeOfExprType(Expr *E, bool IsUnqual, QualType Can = QualType());
 

This constructor is smelly Am I to guess this does something like, "if E, 
type is the type of this, else it is the type passed in Can?"



Comment at: clang/include/clang/AST/Type.h:4592
+  T->getDependence()), TOType(T), IsUnqual(IsUnqual) {
+assert(!isa(Can) && "Invalid canonical type");
   }

Are `TypedefType`'s EVER canonical?  Should you just be asserting 'Can' is 
canonical?



Comment at: clang/lib/AST/ASTContext.cpp:12910
   case Type::TypeOf:
-return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying));
+// FIXME:: is this assumption correct or do we need to do work here to find
+// the common type sugar regarding the stripped qualifiers if only one side

I'm unfamiliar with this function, but I would expect you MIGHT need to?  If 
only because they are the same AST node.  Should 'unqual' version be its own 
node?  I'm on the fence, as it is a LOT of code to do so, but also ends up 
being simpler in many places.



Comment at: clang/lib/AST/Type.cpp:3502
+  // We strip all qualifier-like attributes as well.
+  if (const auto *AT =
+  dyn_cast_if_present(Ret.getTypePtrOrNull());

In what situation is getTypePtrOrNull required here?  I would imagine that the 
'isNull' check above should make sure we aren't in a situation where 'Ret' 
could be 'null' here?  Same with the 'if_present'.



Comment at: clang/lib/Lex/Preprocessor.cpp:61
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/Capacity.h"

Oh?



Comment at: clang/lib/Parse/ParseDecl.cpp:7463
   SourceLocation StartLoc = ConsumeToken();
-
-  const bool hasParens = Tok.is(tok::l_paren);
+  bool HasParens = Tok.is(tok::l_paren);
 

Should it be an error to `!HasParens` if `IsUnqual`.



Comment at: clang/lib/Sema/SemaType.cpp:9137
+Diag(E->getExprLoc(), diag::err_sizeof_alignof_typeof_bitfield)
+<< (IsUnqual ? 3 : 2);
 

`(IsUnqual + 2)` maybe?  Or perhaps too cute.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

mingmingl added a comment.

Thanks! Going to submit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127798/new/

https://reviews.llvm.org/D127798

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127798: [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGce7b4747e8b3: [AArch64] Define __ARM_FEATURE_RCPC (authored 
by mingmingl).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127798/new/

https://reviews.llvm.org/D127798

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/test/Preprocessor/aarch64-target-features.c


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -560,3 +561,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang --target=aarch64 -march=armv8.2-a+rcpc -x c -E -dM %s -o - | 
FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -551,6 +554,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -600,6 +604,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -560,3 +561,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang --target=aarch64 -march=armv8.2-a+rcpc -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1
Index: clang/lib/Basic/Targets/AArch64.h
===
--- clang/lib/Basic/Targets/AArch64.h
+++ clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -551,6 +554,7 @@
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -600,6 +604,8 @@
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ce7b474 - [AArch64] Define __ARM_FEATURE_RCPC

[Mingming Liu via cfe-commits]

Author: Mingming Liu
Date: 2022-09-20T10:03:13-07:00
New Revision: ce7b4747e8b329ad6bc3362a3e3c245331127d6d

URL: 
https://github.com/llvm/llvm-project/commit/ce7b4747e8b329ad6bc3362a3e3c245331127d6d
DIFF: 
https://github.com/llvm/llvm-project/commit/ce7b4747e8b329ad6bc3362a3e3c245331127d6d.diff

LOG: [AArch64] Define __ARM_FEATURE_RCPC

This patch implements the definition of __ARM_FEATURE_RCPC when clang
command specifies +rcpc.

Differential Revision: https://reviews.llvm.org/D127798

Added: 


Modified: 
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Basic/Targets/AArch64.h
clang/test/Preprocessor/aarch64-target-features.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index 85346ebf92ab6..19e6ccacf100e 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -341,6 +341,9 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   if (HasCRC)
 Builder.defineMacro("__ARM_FEATURE_CRC32", "1");
 
+  if (HasRCPC)
+Builder.defineMacro("__ARM_FEATURE_RCPC", "1");
+
   // The __ARM_FEATURE_CRYPTO is deprecated in favor of finer grained feature
   // macros for AES, SHA2, SHA3 and SM4
   if (HasAES && HasSHA2)
@@ -551,6 +554,7 @@ bool 
AArch64TargetInfo::handleTargetFeatures(std::vector &Features,
   HasMatmulFP32 = false;
   HasLSE = false;
   HasMOPS = false;
+  HasRCPC = false;
 
   ArchKind = llvm::AArch64::ArchKind::INVALID;
 
@@ -600,6 +604,8 @@ bool 
AArch64TargetInfo::handleTargetFeatures(std::vector &Features,
 }
 if (Feature == "+crc")
   HasCRC = true;
+if (Feature == "+rcpc")
+  HasRCPC = true;
 if (Feature == "+aes")
   HasAES = true;
 if (Feature == "+sha2")

diff  --git a/clang/lib/Basic/Targets/AArch64.h 
b/clang/lib/Basic/Targets/AArch64.h
index e28a4c5b63905..1930092c248b2 100644
--- a/clang/lib/Basic/Targets/AArch64.h
+++ b/clang/lib/Basic/Targets/AArch64.h
@@ -54,6 +54,7 @@ class LLVM_LIBRARY_VISIBILITY AArch64TargetInfo : public 
TargetInfo {
   bool HasLSE;
   bool HasFlagM;
   bool HasMOPS;
+  bool HasRCPC;
 
   llvm::AArch64::ArchKind ArchKind;
 

diff  --git a/clang/test/Preprocessor/aarch64-target-features.c 
b/clang/test/Preprocessor/aarch64-target-features.c
index 2d4ec2bbcae92..e0004ab9fdb6c 100644
--- a/clang/test/Preprocessor/aarch64-target-features.c
+++ b/clang/test/Preprocessor/aarch64-target-features.c
@@ -26,6 +26,7 @@
 // CHECK: __ARM_FEATURE_IDIV 1
 // CHECK: __ARM_FEATURE_LDREX 0xF
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK-NOT: __ARM_FEATURE_RCPC 1
 // CHECK-NOT: __ARM_FEATURE_SHA2 1
 // CHECK-NOT: __ARM_FEATURE_SHA3 1
 // CHECK-NOT: __ARM_FEATURE_SHA512 1
@@ -560,3 +561,6 @@
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_COMPLEX 1
 // CHECK-BEFORE-V83-NOT: __ARM_FEATURE_JCVT 1
 // CHECK-BEFORE-V85-NOT: __ARM_FEATURE_FRINT 1
+
+// RUN: %clang --target=aarch64 -march=armv8.2-a+rcpc -x c -E -dM %s -o - | 
FileCheck --check-prefix=CHECK-RCPC %s
+// CHECK-RCPC: __ARM_FEATURE_RCPC 1



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133443: [RISCV][MC] Add support for experimental Zawrs extension

[Philip Reames via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGeda2af575fdf: [RISCV][MC] Add support for experimental Zawrs 
extension (authored by reames).

Changed prior to commit:
  https://reviews.llvm.org/D133443?vs=461345&id=461608#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133443/new/

https://reviews.llvm.org/D133443

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/docs/RISCVUsage.rst
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/Zawrs-valid.s
  llvm/test/MC/RISCV/attribute-arch.s

Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -197,5 +197,8 @@
 .attribute arch, "rv32izca0p70"
 # CHECK: attribute  5, "rv32i2p0_zca0p70"
 
+.attribute arch, "rv32izawrs1p0"
+# CHECK: attribute  5, "rv32i2p0_zawrs1p0"
+
 .attribute arch, "rv32iztso0p1"
 # CHECK: attribute  5, "rv32i2p0_ztso0p1"
Index: llvm/test/MC/RISCV/Zawrs-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/Zawrs-valid.s
@@ -0,0 +1,18 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zawrs -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zawrs -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+experimental-zawrs < %s \
+# RUN: | llvm-objdump --mattr=+experimental-zawrs -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+experimental-zawrs < %s \
+# RUN: | llvm-objdump --mattr=+experimental-zawrs -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: wrs.nto
+# CHECK-ASM: encoding: [0x73,0x00,0xd0,0x00]
+wrs.nto
+
+# CHECK-ASM-AND-OBJ: wrs.sto
+# CHECK-ASM: encoding: [0x73,0x00,0xd0,0x01]
+wrs.sto
Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -84,6 +84,7 @@
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbom %s -o - | FileCheck --check-prefix=RV64ZICBOM %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicboz %s -o - | FileCheck --check-prefix=RV64ZICBOZ %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbop %s -o - | FileCheck --check-prefix=RV64ZICBOP %s
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zawrs %s -o - | FileCheck --check-prefix=RV64ZAWRS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-ztso %s -o - | FileCheck --check-prefix=RV64ZTSO %s
 
 ; RV32M: .attribute 5, "rv32i2p0_m2p0"
@@ -170,6 +171,7 @@
 ; RV64COMBINEINTOZKS: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 ; RV64ZICBOM: .attribute 5, "rv64i2p0_zicbom1p0"
 ; RV64ZICBOZ: .attribute 5, "rv64i2p0_zicboz1p0"
+; RV64ZAWRS: .attribute 5, "rv64i2p0_zawrs1p0"
 ; RV64ZICBOP: .attribute 5, "rv64i2p0_zicbop1p0"
 ; RV64ZTSO: .attribute 5, "rv64i2p0_ztso0p1"
 
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -92,6 +92,7 @@
   bool HasStdExtZicboz = false;
   bool HasStdExtZicbop = false;
   bool HasStdExtZmmul = false;
+  bool HasStdExtZawrs = false;
   bool HasStdExtZtso = false;
   bool HasRV32 = false;
   bool HasRV64 = false;
@@ -192,6 +193,7 @@
   bool hasStdExtZicbom() const { return HasStdExtZicbom; }
   bool hasStdExtZicboz() const { return HasStdExtZicboz; }
   bool hasStdExtZicbop() const { return HasStdExtZicbop; }
+  bool hasStdExtZawrs() const { return HasStdExtZawrs; }
   bool hasStdExtZmmul() const { return HasStdExtZmmul; }
   bool hasStdExtZtso() const { return HasStdExtZtso; }
   bool is64Bit() const { return HasRV64; }
Index: llvm/lib/Target/RISCV/RISCVInstrInfo.td
===
--- llvm/lib/Target/RISCV/RISCVInstrInfo.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfo.td
@@ -705,6 +705,23 @@
   let rd = 0;
   let imm12 = 0b1100;
 }
+
+let Predicates = [HasStdExtZawrs] in {
+def WRS_NTO : RVInstI<0b000, OPC_SYSTEM, (outs), (ins), "wrs.nto", "">,
+  Sched<[]> {
+  let rs1 = 0;
+  let rd = 0;
+  let imm12 = 0b1101;
+}
+
+def WRS_STO : RVInstI<0b000, OPC_SYSTEM, (outs), (ins), "wrs.sto", "">,
+  Sched<[]> {
+  let rs1 = 0;
+  let rd = 0;
+  let imm

[clang] eda2af5 - [RISCV][MC] Add support for experimental Zawrs extension

[Philip Reames via cfe-commits]

Author: Philip Reames
Date: 2022-09-20T10:15:11-07:00
New Revision: eda2af575fdf038f3508112b42845516e7cb6192

URL: 
https://github.com/llvm/llvm-project/commit/eda2af575fdf038f3508112b42845516e7cb6192
DIFF: 
https://github.com/llvm/llvm-project/commit/eda2af575fdf038f3508112b42845516e7cb6192.diff

LOG: [RISCV][MC] Add support for experimental Zawrs extension

This implements experimental support for the Zawrs extension as specified here: 
https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf. 
Despite the 1.0 version name, this has not been ratified and there was a major 
change to proposed specification between rc2 and rc3.  Once this is ratified, 
it'll move out of experimental status.

This change adds assembly support, but does not include C language or IR 
intrinsics. We can decide if we want them, and handle that in a separate patch.

Differential Revision: https://reviews.llvm.org/D133443

Added: 
llvm/test/MC/RISCV/Zawrs-valid.s

Modified: 
clang/test/Preprocessor/riscv-target-features.c
llvm/docs/RISCVUsage.rst
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVInstrInfo.td
llvm/lib/Target/RISCV/RISCVSubtarget.h
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s

Removed: 




diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 9ec91171e8f05..39ab684e575b0 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -463,6 +463,14 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOP-EXT %s
 // CHECK-ZICBOP-EXT: __riscv_zicbop 100{{$}}
 
+// RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN: -march=rv32izawrs1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZAWRS-EXT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN: -march=rv64izawrs1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZAWRS-EXT %s
+// CHECK-ZAWRS-EXT: __riscv_zawrs 100{{$}}
+
 // RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
 // RUN: -march=rv32iztso0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZTSO-EXT %s

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index ddfea5b99117a..5db374c24f0d6 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -128,6 +128,9 @@ LLVM supports (to various degrees) a number of experimental 
extensions.  All exp
 
 The primary goal of experimental support is to assist in the process of 
ratification by providing an existence proof of an implementation, and 
simplifying efforts to validate the value of a proposed extension against large 
code bases.  Experimental extensions are expected to either transition to 
ratified status, or be eventually removed.  The decision on whether to accept 
an experimental extension is currently done on an entirely case by case basis; 
if you want to propose one, attending the bi-weekly RISC-V sync-up call is 
strongly advised.
 
+``experimental-zawrs``
+  LLVM implements the `1.0-rc3 draft specification 
`_.  
Note that have been backwards incompatible changes made between release 
candidates for the 1.0 draft.
+
 ``experimental-zbe``, ``experimental-zbf``, ``experimental-zbm``, 
``experimental-zbp``, ``experimental-zbr``, ``experimental-zbt``
   LLVM implements the `latest state of the bitmanip working branch 
`_, which is largely 
similar to the 0.93 draft specification but with some instruction naming 
changes.  These are individual portions of the bitmanip efforts which did *not* 
get ratified.  Given ratification for these sub-extensions appears stalled; 
they are a likely candidate for removal in the future.
 

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 8deedfb8c8fd7..a9ae60746ad10 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -114,6 +114,7 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 {"zbt", RISCVExtensionVersion{0, 93}},
 {"zca", RISCVExtensionVersion{0, 70}},
 {"zvfh", RISCVExtensionVersion{0, 1}},
+{"zawrs", RISCVExtensionVersion{1, 0}},
 {"ztso", RISCVExtensionVersion{0, 1}},
 };
 

diff  --git a/llvm/lib/Target/RISCV/RISCV.td b/llvm/lib/Target/RISCV/RISCV.td
index b4f3416857749..5ce40e0dcbff7 100644
--- a/llvm/lib/Target/RISCV/RISCV.td
+++ b/llvm/lib/Target/RISCV/RISCV.td
@@ -461,6 +461,13 @@ def HasStdExtZtso : 
Predicate<"Subtarget->hasStdExtZTso()">,
AssemblerPredicate<(all_of FeatureStdExtZtso),
  

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:1717
 
   /// GCC extension.
+  QualType getTypeOfExprType(Expr *E, bool IsUnqual) const;

I guess these are not purely extensions anymore?



Comment at: clang/include/clang/AST/Type.h:1071
 
+  /// Returns the typeof_unqual-unqualified version of the type.
+  QualType getTypeofUnqualType() const;

I think your trying to say this is more than the unqualified type but maybe 
just be more explicit like `it returns the ununqualified type including atomic 
type qualification and type attributes which behave like a qualifier, such as 
an address space attribute`



Comment at: clang/include/clang/AST/Type.h:4601
+QualType QT = getUnderlyingType();
+return IsUnqual ? QT.getTypeofUnqualType() : QT;
+  }

It is interesting that you do `getTypeofUnqualType` in the constructor and then 
you have to do it again when desuguring. Is this tested in the tests?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133443: [RISCV][MC] Add support for experimental Zawrs extension

[Philip Reames via Phabricator via cfe-commits]

reames added a comment.

In D133443#3801899 , @asb wrote:

> It looks like they're still missing in this updated version of the patch?

I have no idea what's going wrong here.  I had been very careful to make sure 
the patch contained the new test file, but you're right, the revision in phab 
didn't.

Since we now had two LGTMs, and the tests had been in the original patch 
upload, I went ahead and landed.  The tests are in the committed patch; if you 
want any changes, let me know.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133443/new/

https://reviews.llvm.org/D133443

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131424: Remove the unused/undefined _cmd parameter to objc_direct methods.

[Michael Wyman via Phabricator via cfe-commits]

mwyman added a reviewer: ahatanak.
mwyman added a comment.

Hi Akira,

I'd reached out to John offline and he'd mentioned you might be able to help on 
some of these objc_direct reviews; if so, that would be wonderful!

-Michael


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131424/new/

https://reviews.llvm.org/D131424

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125418/new/

https://reviews.llvm.org/D125418

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/include/clang/AST/Type.h:4537
   Expr *TOExpr;
+  bool IsUnqual;
 

You can use the Type Bitfields in order to avoid bumping the size of the node.




Comment at: clang/lib/AST/ASTContext.cpp:12910-12916
+// FIXME:: is this assumption correct or do we need to do work here to find
+// the common type sugar regarding the stripped qualifiers if only one side
+// is unqual?
+assert(cast(X)->isUnqual() == cast(Y)->isUnqual() 
&&
+   "typeof vs typeof_unqual mismatch?");
+return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying),
+ cast(X)->isUnqual());

erichkeane wrote:
> I'm unfamiliar with this function, but I would expect you MIGHT need to?  If 
> only because they are the same AST node.  Should 'unqual' version be its own 
> node?  I'm on the fence, as it is a LOT of code to do so, but also ends up 
> being simpler in many places.
A qualified and an unqualified typeof could have the same underlying type, so 
this assert can trip.

I think what makes most sense is to unify them to a qualified typeof in case 
they differ, as that holds the underlying type unchanged:
```
return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying),
 cast(X)->isUnqual() && 
cast(Y)->isUnqual());
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/include/clang/AST/Type.h:4601
+QualType QT = getUnderlyingType();
+return IsUnqual ? QT.getTypeofUnqualType() : QT;
+  }

shafik wrote:
> It is interesting that you do `getTypeofUnqualType` in the constructor and 
> then you have to do it again when desuguring. Is this tested in the tests?
The constructor takes the canonical type, while this preserves the unmodified 
type (which can be accessed through getUnderlyingType).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/include/clang/AST/Type.h:4592
+  T->getDependence()), TOType(T), IsUnqual(IsUnqual) {
+assert(!isa(Can) && "Invalid canonical type");
   }

erichkeane wrote:
> Are `TypedefType`'s EVER canonical?  Should you just be asserting 'Can' is 
> canonical?
They can't, the original assert didn't make much sense.

Though asserting on CanonicalType being canonical is a job better left to the 
`Type` constructor, just so we don't have to repeat it everywhere.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134284: [AIX] change "llvm-nm" to "env OBJECT_MODE=any llvm-nm" in clang/test for AIX OS

[David Tenty via Phabricator via cfe-commits]

daltenty accepted this revision.
daltenty added a comment.
This revision is now accepted and ready to land.

LGTM to unblock the AIX buildbots. We can follow up on a separate env later if 
desired.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134284/new/

https://reviews.llvm.org/D134284

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134225: [clang-doc] Centralize TypeInfo creation.

[Paul Kirth via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4df84ac377df: [clang-doc] Centralize TypeInfo creation. 
(authored by brettw, committed by paulkirth).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134225/new/

https://reviews.llvm.org/D134225

Files:
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp

Index: clang-tools-extra/clang-doc/Serialize.cpp
===
--- clang-tools-extra/clang-doc/Serialize.cpp
+++ clang-tools-extra/clang-doc/Serialize.cpp
@@ -224,12 +224,35 @@
   return hashUSR(USR);
 }
 
-static RecordDecl *getDeclForType(const QualType &T) {
+static TagDecl *getTagDeclForType(const QualType &T) {
+  if (const TagDecl *D = T->getAsTagDecl())
+return D->getDefinition();
+  return nullptr;
+}
+
+static RecordDecl *getRecordDeclForType(const QualType &T) {
   if (const RecordDecl *D = T->getAsRecordDecl())
 return D->getDefinition();
   return nullptr;
 }
 
+TypeInfo getTypeInfoForType(const QualType &T) {
+  const TagDecl *TD = getTagDeclForType(T);
+  if (!TD)
+return TypeInfo(Reference(T.getAsString()));
+
+  InfoType IT;
+  if (dyn_cast(TD)) {
+IT = InfoType::IT_enum;
+  } else if (dyn_cast(TD)) {
+IT = InfoType::IT_record;
+  } else {
+IT = InfoType::IT_default;
+  }
+  return TypeInfo(Reference(getUSRForDecl(TD), TD->getNameAsString(), IT,
+getInfoRelativePath(TD)));
+}
+
 static bool isPublic(const clang::AccessSpecifier AS,
  const clang::Linkage Link) {
   if (AS == clang::AccessSpecifier::AS_private)
@@ -286,28 +309,14 @@
   for (const FieldDecl *F : D->fields()) {
 if (!shouldSerializeInfo(PublicOnly, /*IsInAnonymousNamespace=*/false, F))
   continue;
-if (const auto *T = getDeclForType(F->getTypeSourceInfo()->getType())) {
-  // Use getAccessUnsafe so that we just get the default AS_none if it's not
-  // valid, as opposed to an assert.
-  if (const auto *N = dyn_cast(T)) {
-I.Members.emplace_back(
-getUSRForDecl(T), N->getNameAsString(), InfoType::IT_enum,
-getInfoRelativePath(N), F->getNameAsString(),
-getFinalAccessSpecifier(Access, N->getAccessUnsafe()));
-continue;
-  } else if (const auto *N = dyn_cast(T)) {
-I.Members.emplace_back(
-getUSRForDecl(T), N->getNameAsString(), InfoType::IT_record,
-getInfoRelativePath(N), F->getNameAsString(),
-getFinalAccessSpecifier(Access, N->getAccessUnsafe()));
-continue;
-  }
-}
 
-auto& member = I.Members.emplace_back(
-F->getTypeSourceInfo()->getType().getAsString(), F->getNameAsString(),
+// Use getAccessUnsafe so that we just get the default AS_none if it's not
+// valid, as opposed to an assert.
+MemberTypeInfo &NewMember = I.Members.emplace_back(
+getTypeInfoForType(F->getTypeSourceInfo()->getType()),
+F->getNameAsString(),
 getFinalAccessSpecifier(Access, F->getAccessUnsafe()));
-populateMemberTypeInfo(member, F);
+populateMemberTypeInfo(NewMember, F);
   }
 }
 
@@ -325,27 +334,11 @@
 
 static void parseParameters(FunctionInfo &I, const FunctionDecl *D) {
   for (const ParmVarDecl *P : D->parameters()) {
-FieldTypeInfo *FieldInfo = nullptr;
-if (const auto *T = getDeclForType(P->getOriginalType())) {
-  if (const auto *N = dyn_cast(T)) {
-FieldInfo = &I.Params.emplace_back(
-getUSRForDecl(N), N->getNameAsString(), InfoType::IT_enum,
-getInfoRelativePath(N), P->getNameAsString());
-  } else if (const auto *N = dyn_cast(T)) {
-FieldInfo = &I.Params.emplace_back(
-getUSRForDecl(N), N->getNameAsString(), InfoType::IT_record,
-getInfoRelativePath(N), P->getNameAsString());
-  }
-  // Otherwise fall through to the default case below.
-}
-
-if (!FieldInfo) {
-  FieldInfo = &I.Params.emplace_back(P->getOriginalType().getAsString(),
- P->getNameAsString());
-}
+FieldTypeInfo &FieldInfo = I.Params.emplace_back(
+getTypeInfoForType(P->getOriginalType()), P->getNameAsString());
 
 if (const Expr *DefaultArg = P->getDefaultArg()) {
-  FieldInfo->DefaultValue = getSourceCode(D, DefaultArg->getSourceRange());
+  FieldInfo.DefaultValue = getSourceCode(D, DefaultArg->getSourceRange());
 }
   }
 }
@@ -363,14 +356,14 @@
   const TemplateDecl *D = Ty->getTemplateName().getAsTemplateDecl();
   I.Parents.emplace_back(getUSRForDecl(D), B.getType().getAsString(),
  InfoType::IT_record);
-} else if (const RecordDecl *P = getDeclForType(B.getType()))
+} else if (const RecordDecl *P = getRecordDeclForType(B.getType()))
   I.Parents.emplace_back(getUSRForDecl(P), P->getNameAsString(),
  

[clang-tools-extra] 4df84ac - [clang-doc] Centralize TypeInfo creation.

[Paul Kirth via cfe-commits]

Author: Brett Wilson
Date: 2022-09-20T17:55:47Z
New Revision: 4df84ac377dfc88da0217dc8cbb9aa69be6cbe55

URL: 
https://github.com/llvm/llvm-project/commit/4df84ac377dfc88da0217dc8cbb9aa69be6cbe55
DIFF: 
https://github.com/llvm/llvm-project/commit/4df84ac377dfc88da0217dc8cbb9aa69be6cbe55.diff

LOG: [clang-doc] Centralize TypeInfo creation.

Several different places in the code had similar computations for the 
parameters that were eventually passed to the TypeInfo constructor.

This centralizes that code in one function, and allows passing TypeInfo to the 
various other *Info structures that need it.

Remove some "auto" types and replace with the real type for getting 
declarations. This was making some duplicate checking difficult to see.

Reviewed By: paulkirth

Differential Revision: https://reviews.llvm.org/D134225

Added: 


Modified: 
clang-tools-extra/clang-doc/Representation.h
clang-tools-extra/clang-doc/Serialize.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-doc/Representation.h 
b/clang-tools-extra/clang-doc/Representation.h
index 0f0a838148223..5385aa96c1f52 100644
--- a/clang-tools-extra/clang-doc/Representation.h
+++ b/clang-tools-extra/clang-doc/Representation.h
@@ -158,6 +158,8 @@ struct Reference {
 // A base struct for TypeInfos
 struct TypeInfo {
   TypeInfo() = default;
+  TypeInfo(const Reference &R) : Type(R) {}
+
   TypeInfo(SymbolID Type, StringRef Field, InfoType IT)
   : Type(Type, Field, IT) {}
   TypeInfo(SymbolID Type, StringRef Field, InfoType IT, StringRef Path)
@@ -173,6 +175,9 @@ struct TypeInfo {
 // Info for field types.
 struct FieldTypeInfo : public TypeInfo {
   FieldTypeInfo() = default;
+  FieldTypeInfo(const TypeInfo &TI, StringRef Name = StringRef(),
+StringRef DefaultValue = StringRef())
+  : TypeInfo(TI), Name(Name), DefaultValue(DefaultValue) {}
   FieldTypeInfo(SymbolID Type, StringRef Field, InfoType IT, StringRef Path,
 llvm::StringRef Name)
   : TypeInfo(Type, Field, IT, Path), Name(Name) {}
@@ -196,6 +201,8 @@ struct FieldTypeInfo : public TypeInfo {
 // Info for member types.
 struct MemberTypeInfo : public FieldTypeInfo {
   MemberTypeInfo() = default;
+  MemberTypeInfo(const TypeInfo &TI, StringRef Name, AccessSpecifier Access)
+  : FieldTypeInfo(TI, Name), Access(Access) {}
   MemberTypeInfo(SymbolID Type, StringRef Field, InfoType IT, StringRef Path,
  llvm::StringRef Name, AccessSpecifier Access)
   : FieldTypeInfo(Type, Field, IT, Path, Name), Access(Access) {}

diff  --git a/clang-tools-extra/clang-doc/Serialize.cpp 
b/clang-tools-extra/clang-doc/Serialize.cpp
index 4c161f0640c61..45056061a6407 100644
--- a/clang-tools-extra/clang-doc/Serialize.cpp
+++ b/clang-tools-extra/clang-doc/Serialize.cpp
@@ -224,12 +224,35 @@ static SymbolID getUSRForDecl(const Decl *D) {
   return hashUSR(USR);
 }
 
-static RecordDecl *getDeclForType(const QualType &T) {
+static TagDecl *getTagDeclForType(const QualType &T) {
+  if (const TagDecl *D = T->getAsTagDecl())
+return D->getDefinition();
+  return nullptr;
+}
+
+static RecordDecl *getRecordDeclForType(const QualType &T) {
   if (const RecordDecl *D = T->getAsRecordDecl())
 return D->getDefinition();
   return nullptr;
 }
 
+TypeInfo getTypeInfoForType(const QualType &T) {
+  const TagDecl *TD = getTagDeclForType(T);
+  if (!TD)
+return TypeInfo(Reference(T.getAsString()));
+
+  InfoType IT;
+  if (dyn_cast(TD)) {
+IT = InfoType::IT_enum;
+  } else if (dyn_cast(TD)) {
+IT = InfoType::IT_record;
+  } else {
+IT = InfoType::IT_default;
+  }
+  return TypeInfo(Reference(getUSRForDecl(TD), TD->getNameAsString(), IT,
+getInfoRelativePath(TD)));
+}
+
 static bool isPublic(const clang::AccessSpecifier AS,
  const clang::Linkage Link) {
   if (AS == clang::AccessSpecifier::AS_private)
@@ -286,28 +309,14 @@ static void parseFields(RecordInfo &I, const RecordDecl 
*D, bool PublicOnly,
   for (const FieldDecl *F : D->fields()) {
 if (!shouldSerializeInfo(PublicOnly, /*IsInAnonymousNamespace=*/false, F))
   continue;
-if (const auto *T = getDeclForType(F->getTypeSourceInfo()->getType())) {
-  // Use getAccessUnsafe so that we just get the default AS_none if it's 
not
-  // valid, as opposed to an assert.
-  if (const auto *N = dyn_cast(T)) {
-I.Members.emplace_back(
-getUSRForDecl(T), N->getNameAsString(), InfoType::IT_enum,
-getInfoRelativePath(N), F->getNameAsString(),
-getFinalAccessSpecifier(Access, N->getAccessUnsafe()));
-continue;
-  } else if (const auto *N = dyn_cast(T)) {
-I.Members.emplace_back(
-getUSRForDecl(T), N->getNameAsString(), InfoType::IT_record,
-getInfoRelativePath(N), F->getNameAsString(),
-getFinalAccessSpecifier(Access, N->getAccessUnsafe(

[PATCH] D134286: [C2x] implement typeof and typeof_unqual

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12910-12916
+// FIXME:: is this assumption correct or do we need to do work here to find
+// the common type sugar regarding the stripped qualifiers if only one side
+// is unqual?
+assert(cast(X)->isUnqual() == cast(Y)->isUnqual() 
&&
+   "typeof vs typeof_unqual mismatch?");
+return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying),
+ cast(X)->isUnqual());

mizvekov wrote:
> erichkeane wrote:
> > I'm unfamiliar with this function, but I would expect you MIGHT need to?  
> > If only because they are the same AST node.  Should 'unqual' version be its 
> > own node?  I'm on the fence, as it is a LOT of code to do so, but also ends 
> > up being simpler in many places.
> A qualified and an unqualified typeof could have the same underlying type, so 
> this assert can trip.
> 
> I think what makes most sense is to unify them to a qualified typeof in case 
> they differ, as that holds the underlying type unchanged:
> ```
> return Ctx.getTypeOfType(Ctx.getQualifiedType(Underlying),
>  cast(X)->isUnqual() && 
> cast(Y)->isUnqual());
> ```
By the way, one thing to notice is the confusion regarding what is the 
underlying type of this node, the result of `desugar()` or the result of 
`getUnderlyingType()`?

On my previous post, I meant the former.

Maybe this is a good reason to rename `getUnderlyingType()` to 
`getUnmodifiedType()` or something similar?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134286/new/

https://reviews.llvm.org/D134286

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 461627.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133468/new/

https://reviews.llvm.org/D133468

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/test/SemaCXX/sugar-common-types.cpp

Index: clang/test/SemaCXX/sugar-common-types.cpp
===
--- clang/test/SemaCXX/sugar-common-types.cpp
+++ clang/test/SemaCXX/sugar-common-types.cpp
@@ -112,3 +112,22 @@
 C2 auto t26_3 = (::SB1){};
 N t26 = 0 ? t26_1 : t26_2; // expected-error {{from 'SB1' (aka 'SS1')}}
 N t27 = 0 ? t26_1 : t26_3; // expected-error {{from 'SB1' (aka 'SS1')}}
+
+using RPB1 = X1*;
+using RPX1 = RPB1;
+using RPB1 = Y1*; // redeclared
+using RPY1 = RPB1;
+N t28 = *(RPB1){}; // expected-error {{lvalue of type 'Y1' (aka 'int')}}
+auto t29 = 0 ? (RPX1){} : (RPY1){};
+N t30 = t29;  // expected-error {{lvalue of type 'RPB1' (aka 'int *')}}
+N t31 = *t29; // expected-error {{lvalue of type 'B1' (aka 'int')}}
+
+namespace A { using type1 = X1*; };
+namespace C { using A::type1; };
+using UPX1 = C::type1;
+namespace A { using type1 = Y1*; };  // redeclared
+namespace C { using A::type1; }; // redeclared
+using UPY1 = C::type1;
+auto t32 = 0 ? (UPX1){} : (UPY1){};
+N t33 = t32;  // expected-error {{lvalue of type 'C::type1' (aka 'int *')}}
+N t34 = *t32; // expected-error {{lvalue of type 'B1' (aka 'int')}}
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3434,25 +3434,34 @@
 }
 
 TypedefType::TypedefType(TypeClass tc, const TypedefNameDecl *D,
- QualType underlying, QualType can)
-: Type(tc, can, toSemanticDependence(underlying->getDependence())),
+ QualType Underlying, QualType can)
+: Type(tc, can, toSemanticDependence(can->getDependence())),
   Decl(const_cast(D)) {
   assert(!isa(can) && "Invalid canonical type");
+  TypedefBits.isDivergent = !Underlying.isNull();
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }
 
 QualType TypedefType::desugar() const {
-  return getDecl()->getUnderlyingType();
+  return isDivergent() ? *getTrailingObjects()
+   : Decl->getUnderlyingType();
 }
 
 UsingType::UsingType(const UsingShadowDecl *Found, QualType Underlying,
  QualType Canon)
-: Type(Using, Canon, toSemanticDependence(Underlying->getDependence())),
+: Type(Using, Canon, toSemanticDependence(Canon->getDependence())),
   Found(const_cast(Found)) {
-  assert(Underlying == getUnderlyingType());
+  UsingBits.isDivergent = !Underlying.isNull();
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }
 
 QualType UsingType::getUnderlyingType() const {
-  return QualType(cast(Found->getTargetDecl())->getTypeForDecl(), 0);
+  return isDivergent()
+ ? *getTrailingObjects()
+ : QualType(
+   cast(Found->getTargetDecl())->getTypeForDecl(), 0);
 }
 
 QualType MacroQualifiedType::desugar() const { return getUnderlyingType(); }
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1543,10 +1543,14 @@
 
 void TextNodeDumper::VisitUsingType(const UsingType *T) {
   dumpDeclRef(T->getFoundDecl());
+  if (T->isDivergent())
+OS << " divergent";
 }
 
 void TextNodeDumper::VisitTypedefType(const TypedefType *T) {
   dumpDeclRef(T->getDecl());
+  if (T->isDivergent())
+OS << " divergent";
 }
 
 void TextNodeDumper::VisitUnaryTransformType(const UnaryTransformType *T) {
Index: clang/lib/AST/JSONNodeDumper.cpp
===
--- clang/lib/AST/JSONNodeDumper.cpp
+++ clang/lib/AST/JSONNodeDumper.cpp
@@ -530,6 +530,14 @@
 
 void JSONNodeDumper::VisitTypedefType(const TypedefType *TT) {
   JOS.attribute("decl", createBareDeclRef(TT->getDecl()));
+  if (TT->isDivergent())
+JOS.attribute("type", createQualType(TT->desugar()));
+}
+
+void JSONNodeDumper::VisitUsingType(const UsingType *TT) {
+  JOS.attribute("decl", createBareDeclRef(TT->getFoundDecl()));
+  if (TT->isDivergent())
+JOS.attribute("type", createQualType(TT->desugar()));
 }
 
 void JSONNodeDumper::VisitFunctionType(const FunctionType *T) {
Index: clang/lib/AST/ASTStructuralEquivalence.cpp
===
--- clang/lib/AST/ASTStructuralEquivalence.cpp
+++ clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -957,11 +957,

[PATCH] D132816: [clang] AST: SubstTemplateTypeParmType support for non-canonical underlying type

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov edited the summary of this revision.
mizvekov updated this revision to Diff 461628.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132816/new/

https://reviews.llvm.org/D132816

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/AST/ast-dump-template-decls.cpp

Index: clang/test/AST/ast-dump-template-decls.cpp
===
--- clang/test/AST/ast-dump-template-decls.cpp
+++ clang/test/AST/ast-dump-template-decls.cpp
@@ -162,3 +162,22 @@
 // CHECK:  SubstTemplateTypeParmType 0x{{[^ ]*}} 'short' sugar pack_index 0
 // CHECK-NEXT: TemplateTypeParmType 0x{{[^ ]*}} 'U' dependent contains_unexpanded_pack depth 0 index 0 pack
 } // namespace PR56099
+
+namespace subst_default_argument {
+template class A {};
+template> class D1, class D2> using D = D1;
+
+template class E {};
+using test1 = D;
+// CHECK:  TypeAliasDecl 0x{{[^ ]*}}  col:7 test1 'D':'subst_default_argument::E>'
+// CHECK:  TemplateSpecializationType 0x{{[^ ]*}} 'A' sugar A
+// CHECK-NEXT: |-TemplateArgument type 'int':'int'
+// CHECK-NEXT: | `-SubstTemplateTypeParmType 0x{{[^ ]*}} 'int' sugar
+// CHECK-NEXT: |   |-TemplateTypeParmType 0x{{[^ ]*}} 'C1' dependent depth 1 index 0
+// CHECK-NEXT: |   | `-TemplateTypeParm 0x{{[^ ]*}} 'C1'
+// CHECK-NEXT: |   `-SubstTemplateTypeParmType 0x{{[^ ]*}} 'int' sugar
+// CHECK-NEXT: | |-TemplateTypeParmType 0x{{[^ ]*}} 'type-parameter-0-1' dependent depth 0 index 1
+// CHECK-NEXT: | `-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NEXT: `-RecordType 0x{{[^ ]*}} 'subst_default_argument::A'
+// CHECK-NEXT:   `-ClassTemplateSpecialization 0x{{[^ ]*}} 'A'
+} // namespace subst_default_argument
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -6408,8 +6408,6 @@
   if (Replacement.isNull())
 return QualType();
 
-  // Always canonicalize the replacement type.
-  Replacement = SemaRef.Context.getCanonicalType(Replacement);
   QualType Result = SemaRef.Context.getSubstTemplateTypeParmType(
   T->getReplacedParameter(), Replacement, T->getPackIndex());
 
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -3513,8 +3513,7 @@
 0, IndexReplaced, false,
 cast(TPL->getParam(IndexReplaced)));
 return SemaRef.Context.getSubstTemplateTypeParmType(
-cast(TTP), Replacement.getCanonicalType(),
-PackIndexReplaced);
+cast(TTP), Replacement, PackIndexReplaced);
   };
 
   switch (BTD->getBuiltinTemplateKind()) {
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3659,10 +3659,16 @@
 }
 
 SubstTemplateTypeParmType::SubstTemplateTypeParmType(
-const TemplateTypeParmType *Param, QualType Canon,
+const TemplateTypeParmType *Param, QualType Replacement,
 Optional PackIndex)
-: Type(SubstTemplateTypeParm, Canon, Canon->getDependence()),
+: Type(SubstTemplateTypeParm, Replacement.getCanonicalType(),
+   Replacement->getDependence()),
   Replaced(Param) {
+  SubstTemplateTypeParmTypeBits.HasNonCanonicalUnderlyingType =
+  Replacement != getCanonicalTypeInternal();
+  if (SubstTemplateTypeParmTypeBits.HasNonCanonicalUnderlyingType)
+*getTrailingObjects() = Replacement;
+
   SubstTemplateTypeParmTypeBits.PackIndex = PackIndex ? *PackIndex + 1 : 0;
 }
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -1534,8 +1534,7 @@
 return ToReplacementTypeOrErr.takeError();
 
   return Importer.getToContext().getSubstTemplateTypeParmType(
-  *ReplacedOrErr, ToReplacementTypeOrErr->getCanonicalType(),
-  T->getPackIndex());
+  *ReplacedOrErr, *ToReplacementTypeOrErr, T->getPackIndex());
 }
 
 ExpectedType ASTNodeImporter::VisitSubstTemplateTypeParmPackType(
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4790,9 +4790,6 @@
 ASTContext::getSubstTemplateTypeParmType(const TemplateTypeParmType *Parm,
  QualType Replacement,
  Optional PackIndex) const {
-  assert(Replacement.isCanonical()
- && "replacement types must always be canonical");
-
   llvm::FoldingSetNodeID ID;
   SubstTemplateTypeParmType::Profile(ID, Parm, Replacement, PackIndex);
 

[PATCH] D134295: [clang] Fix missing template arguments in AST of access to member variable template

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
Herald added a project: All.
mizvekov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Signed-off-by: Matheus Izvekov 

Depends on D132816 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134295

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/SemaCXX/cxx1z-ast-print.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -2262,8 +2262,6 @@
   template
   static constexpr T x = 42;
 };
-// FIXME: `` should be a child of `MemberExpression` and `;` of
-// `ExpressionStatement`. This is a bug in clang, in `getSourceRange` methods.
 void test(S s) [[{
   s.x;
 }]]
@@ -2272,18 +2270,18 @@
 CompoundStatement
 |-'{' OpenParen
 |-ExpressionStatement Statement
-| `-MemberExpression Expression
-|   |-IdExpression Object
-|   | `-UnqualifiedId UnqualifiedId
-|   |   `-'s'
-|   |-'.' AccessToken
-|   `-IdExpression Member
-| `-UnqualifiedId UnqualifiedId
-|   `-'x'
-|-'<'
-|-'int'
-|-'>'
-|-';'
+| |-MemberExpression Expression
+| | |-IdExpression Object
+| | | `-UnqualifiedId UnqualifiedId
+| | |   `-'s'
+| | |-'.' AccessToken
+| | `-IdExpression Member
+| |   `-UnqualifiedId UnqualifiedId
+| | |-'x'
+| | |-'<'
+| | |-'int'
+| | `-'>'
+| `-';'
 `-'}' CloseParen
 )txt"}));
 }
Index: clang/test/SemaCXX/cxx1z-ast-print.cpp
===
--- clang/test/SemaCXX/cxx1z-ast-print.cpp
+++ clang/test/SemaCXX/cxx1z-ast-print.cpp
@@ -4,7 +4,7 @@
   template  static int x; // expected-note {{forward declaration of 
template entity is here}}
   template  static int y; // expected-note {{forward declaration of 
template entity is here}}
 };
-// CHECK: int k = TypeSuffix().x + TypeSuffix().y;
+// CHECK: int k = TypeSuffix().x<0L> + TypeSuffix().y<0L>;
 int k = TypeSuffix().x<0L> + TypeSuffix().y<0L>; // expected-warning 
{{instantiation of variable 'TypeSuffix::x<0>' required here, but no definition 
is available}} \
  // expected-note {{add an 
explicit instantiation declaration to suppress this warning if 
'TypeSuffix::x<0>' is explicitly instantiated in another translation unit}} \
  // expected-warning 
{{instantiation of variable 'TypeSuffix::y<0L>' required here, but no 
definition is available}} \
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -1161,10 +1161,10 @@
 if (!Var->getTemplateSpecializationKind())
   Var->setTemplateSpecializationKind(TSK_ImplicitInstantiation, MemberLoc);
 
-return BuildMemberExpr(
-BaseExpr, IsArrow, OpLoc, &SS, TemplateKWLoc, Var, FoundDecl,
-/*HadMultipleCandidates=*/false, MemberNameInfo,
-Var->getType().getNonReferenceType(), VK_LValue, OK_Ordinary);
+return BuildMemberExpr(BaseExpr, IsArrow, OpLoc, &SS, TemplateKWLoc, Var,
+   FoundDecl, /*HadMultipleCandidates=*/false,
+   MemberNameInfo, 
Var->getType().getNonReferenceType(),
+   VK_LValue, OK_Ordinary, TemplateArgs);
   }
 
   // We found something that we didn't expect. Complain.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -158,6 +158,8 @@
 - Fixed a crash in C++20 mode in Clang and Clangd when compile source
   with compilation errors.
   `Issue 53628 `_
+- The template arguments of a variable template being accessed as a
+  member will now be represented in the AST.
 
 
 Improvements to Clang's diagnostics


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -2262,8 +2262,6 @@
   template
   static constexpr T x = 42;
 };
-// FIXME: `` should be a child of `MemberExpression` and `;` of
-// `ExpressionStatement`. This is a bug in clang, in `getSourceRange` methods.
 void test(S s) [[{
   s.x;
 }]]
@@ -2272,18 +2270,18 @@
 CompoundStatement
 |-'{' OpenParen
 |-ExpressionStatement Statement
-| `-MemberExpression Expression
-|   |-IdExpression Object
-|   | `-UnqualifiedId UnqualifiedId
-|   |   `-'s'
-|   |-'.' AccessToken
-|   `-IdExpression Member
-| `-UnqualifiedId UnqualifiedId
-|   `-'x'
-|-'<'
-|-'int'
-|-'>'
-|-';'
+| |-MemberExpression Expression

[PATCH] D134231: [clang][C++20] p0960 Allow initializing aggregates from a parenthesized list of values

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

Hello Ed, thank you for picking up this work.

I liked the approach in the first PR, did you consider reaching out to the 
author is asking if it was ok to commandeer the work to allow it to move 
forward?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134231/new/

https://reviews.llvm.org/D134231

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53847: [C++2a] P0634r3: Down with typename!

[Alan Zhao via Phabricator via cfe-commits]

ayzhao marked an inline comment as done.
ayzhao added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:3377-3379
   // FIXME: This is not quite correct recovery as we don't transform SS
   // into the corresponding dependent form (and we don't diagnose missing
   // 'template' keywords within SS as a result).

ayzhao wrote:
> Rakete wrote:
> > rsmith wrote:
> > > Rakete wrote:
> > > > Rakete wrote:
> > > > > rsmith wrote:
> > > > > > This FIXME is concerning. Is this a problem with this patch? (Is 
> > > > > > the FIXME wrong now?)
> > > > > Yes you're right, I believe it not longer applies due to the change 
> > > > > in ParseDecl.cpp in ParseDeclarationSpecifiers.
> > > > Although I'm not that sure I fully understand what that comments 
> > > > alludes to.
> > > The example would be something like this:
> > > 
> > > ```
> > > template struct X {
> > >   template struct Y { Y(); using V = int; };
> > >   template typename Y::V f();
> > > };
> > > template template
> > > X::Y::V X::f() {} 
> > > ```
> > > 
> > > Clang trunk today points out that the `typename` keyword is missing on 
> > > the final line, but fails to point out that the `template` keyword is 
> > > also missing. The reason is that in the case where that construct is 
> > > valid:
> > > 
> > > ```
> > > template template
> > > X::Y::Y() {}
> > > ```
> > > 
> > > ... we are "entering the context" of the //nested-name-specifier//, which 
> > > means we don't need a `template` keyword.
> > > 
> > > If the FIXME is fixed, then we should diagnose the missing `template` in 
> > > the above program.
> > > 
> > > Also, because we don't rebuild the //nested-name-specifier// as a 
> > > dependent nested name specifier in this case, we fail to match it against 
> > > the declaration in the class, so in my example above, we also produce an 
> > > "out-of-line definition does not match" error.
> > > 
> > > 
> > > A closely-related issue can be seen in an example such as:
> > > 
> > > ```
> > > template struct X {
> > >   template struct Y { Y(); typedef void V; }; 
> > >   template typename Y::V::W f();
> > > };
> > > template template
> > > X::template Y::V::W X::f() { return 0; } 
> > > ```
> > > 
> > > Here, we produce a completely bogus error:
> > > 
> > > ```
> > > :6:13: error: 'X::Y::V' (aka 'void') is not a class, namespace, or 
> > > enumeration
> > > X::template Y::V::W X::f() { return 0; } 
> > > ^
> > > ```
> > > 
> > > ... because we parse this in "entering context" mode and so resolve 
> > > `X::Y::V` to the type in the primary template (that is, `void`). 
> > > That's wrong: we should defer resolving this name to a type until we know 
> > > what `T` and `U` are, or until we know that we're *actually* entering the 
> > > context. Specifically, the above program can be extended as follows:
> > > 
> > > ```
> > > template<> template<> struct X::Y {
> > >   struct V { using W = int; };
> > > };
> > > void call(X x) { x.f(); } // OK, f returns int
> > > ```
> > > 
> > > The above program should be accepted by this patch, if the FIXME is 
> > > indeed now fixed. Please add it as a testcase :)
> > Oh ok, got it thanks. So no, the program is still not accepted in clang, 
> > and a pretty dumb side effect of it is that 
> > 
> > ```
> > template struct X {
> >   template struct Y { Y(); using V = int; };
> >   template typename Y::V f();
> > };
> > template template
> > X::Y::V X::f() {}
> > ```
> > 
> > is accepted without the diagnostic for the missing `template`. :(
> Currently looking into this.
> 
> It is interesting to note that for the following example in one of the parent 
> comments:
> 
> ```
> template struct X {
>   template struct Y { Y(); typedef void V; }; 
>   template typename Y::V::W f();
> };
> template template
> X::template Y::V::W X::f() { return 0; }
> ```
> 
> GCC doesn't like the fact that the `template` keyword is on the final line if 
> compiled with `-pedantic` [0]:
> 
> ```
> :6:16: warning: keyword 'template' not allowed in declarator-id 
> [-Wpedantic]
> 6 | X::template Y::V::W X::f() { return 0; }
>   |^~~~
> Compiler returned: 0
> ```
> 
> [0]: https://godbolt.org/z/dYddW3ErY
This is starting to feel like a separate issue. I filed 
https://github.com/llvm/llvm-project/issues/57853 to track it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53847/new/

https://reviews.llvm.org/D53847

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132711: [HLSL] add sqrt library function

[Joshua Batista via Phabricator via cfe-commits]

bob80905 updated this revision to Diff 461636.
bob80905 added a comment.

include both commits


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132711/new/

https://reviews.llvm.org/D132711

Files:
  clang/test/CodeGenHLSL/builtins/sqrt.hlsl


Index: clang/test/CodeGenHLSL/builtins/sqrt.hlsl
===
--- clang/test/CodeGenHLSL/builtins/sqrt.hlsl
+++ clang/test/CodeGenHLSL/builtins/sqrt.hlsl
@@ -1,8 +1,8 @@
 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
-// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   dxil-pc-shadermodel6.2-library %s -fnative-half-type \
 // RUN:   -emit-llvm -disable-llvm-passes -o - | FileCheck %s
 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
-// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   dxil-pc-shadermodel6.2-library %s -emit-llvm -disable-llvm-passes \
 // RUN:   -o - | FileCheck %s --check-prefix=NO_HALF
 
 double sqrt_d(double x)


Index: clang/test/CodeGenHLSL/builtins/sqrt.hlsl
===
--- clang/test/CodeGenHLSL/builtins/sqrt.hlsl
+++ clang/test/CodeGenHLSL/builtins/sqrt.hlsl
@@ -1,8 +1,8 @@
 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
-// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   dxil-pc-shadermodel6.2-library %s -fnative-half-type \
 // RUN:   -emit-llvm -disable-llvm-passes -o - | FileCheck %s
 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
-// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   dxil-pc-shadermodel6.2-library %s -emit-llvm -disable-llvm-passes \
 // RUN:   -o - | FileCheck %s --check-prefix=NO_HALF
 
 double sqrt_d(double x)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 16f735d - [Driver] Make --execute-only the default for aarch64-fuchsia

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-09-20T18:25:16Z
New Revision: 16f735d2fbe8660659f1dde10eea79b0f0f7c11d

URL: 
https://github.com/llvm/llvm-project/commit/16f735d2fbe8660659f1dde10eea79b0f0f7c11d
DIFF: 
https://github.com/llvm/llvm-project/commit/16f735d2fbe8660659f1dde10eea79b0f0f7c11d.diff

LOG: [Driver] Make --execute-only the default for aarch64-fuchsia

Clang already generates code that doesn't use writeable data in executable
sections so the linker flag is all that is necessary.

-Wl,--no-execute-only can be used to turn this default off.

Differential Revision: https://reviews.llvm.org/D134289

Added: 


Modified: 
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/test/Driver/fuchsia.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index d63c69c63b1f..6f4fa2ce7c40 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -87,6 +87,8 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   }
 
   if (ToolChain.getArch() == llvm::Triple::aarch64) {
+CmdArgs.push_back("--execute-only");
+
 std::string CPU = getCPUName(D, Args, Triple);
 if (CPU.empty() || CPU == "generic" || CPU == "cortex-a53")
   CmdArgs.push_back("--fix-cortex-a53-843419");

diff  --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index ce356a4faca1..099a88c2e4e3 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -41,7 +41,7 @@
 // CHECK: "-pie"
 // CHECK: "--build-id"
 // CHECK: "--hash-style=gnu"
-// CHECK-AARCH64: "--fix-cortex-a53-843419"
+// CHECK-AARCH64: "--execute-only" "--fix-cortex-a53-843419"
 // CHECK: "-dynamic-linker" "ld.so.1"
 // CHECK-RISCV64: "-X"
 // CHECK: Scrt1.o



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134289: [Driver] Make --execute-only the default for aarch64-fuchsia

[Alex Brachet via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG16f735d2fbe8: [Driver] Make --execute-only the default for 
aarch64-fuchsia (authored by abrachet).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D134289?vs=461609&id=461637#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134289/new/

https://reviews.llvm.org/D134289

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/test/Driver/fuchsia.c


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -41,7 +41,7 @@
 // CHECK: "-pie"
 // CHECK: "--build-id"
 // CHECK: "--hash-style=gnu"
-// CHECK-AARCH64: "--fix-cortex-a53-843419"
+// CHECK-AARCH64: "--execute-only" "--fix-cortex-a53-843419"
 // CHECK: "-dynamic-linker" "ld.so.1"
 // CHECK-RISCV64: "-X"
 // CHECK: Scrt1.o
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -87,6 +87,8 @@
   }
 
   if (ToolChain.getArch() == llvm::Triple::aarch64) {
+CmdArgs.push_back("--execute-only");
+
 std::string CPU = getCPUName(D, Args, Triple);
 if (CPU.empty() || CPU == "generic" || CPU == "cortex-a53")
   CmdArgs.push_back("--fix-cortex-a53-843419");


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -41,7 +41,7 @@
 // CHECK: "-pie"
 // CHECK: "--build-id"
 // CHECK: "--hash-style=gnu"
-// CHECK-AARCH64: "--fix-cortex-a53-843419"
+// CHECK-AARCH64: "--execute-only" "--fix-cortex-a53-843419"
 // CHECK: "-dynamic-linker" "ld.so.1"
 // CHECK-RISCV64: "-X"
 // CHECK: Scrt1.o
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -87,6 +87,8 @@
   }
 
   if (ToolChain.getArch() == llvm::Triple::aarch64) {
+CmdArgs.push_back("--execute-only");
+
 std::string CPU = getCPUName(D, Args, Triple);
 if (CPU.empty() || CPU == "generic" || CPU == "cortex-a53")
   CmdArgs.push_back("--fix-cortex-a53-843419");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134289: [Driver] Make --execute-only the default for aarch64-fuchsia

[Alex Brachet via Phabricator via cfe-commits]

abrachet marked an inline comment as done.
abrachet added inline comments.



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:93
   CmdArgs.push_back("--fix-cortex-a53-843419");
+CmdArgs.push_back("--execute-only");
   }

mcgrathr wrote:
> This is a little confusing to read when it's after the other lines.
> I'd put it first in the block with a blank line after it.
> 
Fixed in commit


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134289/new/

https://reviews.llvm.org/D134289

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132186: Clang: Add a new flag Wmisnoinline for printing hot noinline functions

[Di Mo via Phabricator via cfe-commits]

modimo added a comment.

In D132186#3802989 , @paulkirth wrote:

> @iamarchit123 I think the standard advice is to start w/ the llvm-test-suite 
> and then explore other benchmarks as needed. Also, Clang itself is often a 
> very good starting point.
>
> As for profiles, it probably won't be representative, but you could collect 
> the profile using your benchmark and then assess how often the mismatch w/ 
> inlining happens. if you want to do it w/ Clang itself, then a common 
> approach I've heard is to record have Clang build your project and then use 
> ninja trace or equivalent to find the 5-10 TUs w/ the longest compile time. 
> Then stick them in the 
> https://github.com/llvm/llvm-project/tree/main/clang/utils/perf-training 
> directory, which will use them for PGO automatically. If you go that route, 
> you may need to preprocess the source files.

+1 Clang is the best starting point. I've been busy recently so haven't had a 
chance to run the HHVM experiments, starting a run today. Paul left some good 
review comments that you can address without requiring performance runs--I 
would recommend getting the patch updated so when the results come back 
everything will be ready to commit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132186/new/

https://reviews.llvm.org/D132186

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132711: [HLSL] add sqrt library function

[Joshua Batista via Phabricator via cfe-commits]

bob80905 updated this revision to Diff 461638.
bob80905 added a comment.

add hlslintr.h file


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132711/new/

https://reviews.llvm.org/D132711

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h


Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -13,15 +13,13 @@
 __attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) 
uint
 WaveActiveCountBits(bool bBit);
 
-<<< HEAD
-===
+
 // abs builtins
 __attribute__((clang_builtin_alias(__builtin_abs))) int abs(int In);
 __attribute__((clang_builtin_alias(__builtin_labs))) int64_t abs(int64_t In);
 __attribute__((clang_builtin_alias(__builtin_fabsf))) float abs(float In);
 __attribute__((clang_builtin_alias(__builtin_fabs))) double abs(double In);
 
->>> cb3f11ce6110 ([HLSL] add sqrt library function)
 #ifdef __HLSL_ENABLE_16_BIT
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
 int16_t abs(int16_t);
@@ -40,7 +38,7 @@
 half4 abs(half4);
 #endif
 
-<<< HEAD
+
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int abs(int);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int2 abs(int2);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int3 abs(int3);
@@ -69,7 +67,7 @@
 double3 abs(double3);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
 double4 abs(double4);
-===
+
 // sqrt builtins
 __attribute__((clang_builtin_alias(__builtin_sqrt))) double sqrt(double In);
 __attribute__((clang_builtin_alias(__builtin_sqrtf))) float sqrt(float In);
@@ -77,6 +75,6 @@
 #ifdef __HLSL_ENABLE_16_BIT
 __attribute__((clang_builtin_alias(__builtin_sqrtf16))) half sqrt(half In);
 #endif
->>> cb3f11ce6110 ([HLSL] add sqrt library function)
+
 
 #endif //_HLSL_HLSL_INTRINSICS_H_


Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -13,15 +13,13 @@
 __attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) uint
 WaveActiveCountBits(bool bBit);
 
-<<< HEAD
-===
+
 // abs builtins
 __attribute__((clang_builtin_alias(__builtin_abs))) int abs(int In);
 __attribute__((clang_builtin_alias(__builtin_labs))) int64_t abs(int64_t In);
 __attribute__((clang_builtin_alias(__builtin_fabsf))) float abs(float In);
 __attribute__((clang_builtin_alias(__builtin_fabs))) double abs(double In);
 
->>> cb3f11ce6110 ([HLSL] add sqrt library function)
 #ifdef __HLSL_ENABLE_16_BIT
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
 int16_t abs(int16_t);
@@ -40,7 +38,7 @@
 half4 abs(half4);
 #endif
 
-<<< HEAD
+
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int abs(int);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int2 abs(int2);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs))) int3 abs(int3);
@@ -69,7 +67,7 @@
 double3 abs(double3);
 __attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
 double4 abs(double4);
-===
+
 // sqrt builtins
 __attribute__((clang_builtin_alias(__builtin_sqrt))) double sqrt(double In);
 __attribute__((clang_builtin_alias(__builtin_sqrtf))) float sqrt(float In);
@@ -77,6 +75,6 @@
 #ifdef __HLSL_ENABLE_16_BIT
 __attribute__((clang_builtin_alias(__builtin_sqrtf16))) half sqrt(half In);
 #endif
->>> cb3f11ce6110 ([HLSL] add sqrt library function)
+
 
 #endif //_HLSL_HLSL_INTRINSICS_H_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

The descriptions here are pretty general and opaque nad it's hard to follow 
what this means in practice.
It sounds like the motivating cases are to do with template instantiation - can 
we see them? e.g. code + proposed diagnostics before/after, or some other 
description of how this will be used?
The ternary-expression stuff doesn't seem compelling enough to justify the 
complexity here without more context. (Probably others have this context, but 
future readers of this code won't).

My intuition is that if a type desugars to something other than what the 
UsingDecl points to, then UsingType isn't the right model - it seems we're 
trying to shim some extra indirection that doesn't have much to do with 
`using`. Maybe we can isolate the complexity better in a new sugar typenode, 
rather than weakening the semantics of Using/TypedefType?
But I can easily imagine I'm missing the point and concrete examples might 
clear it up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133468/new/

https://reviews.llvm.org/D133468

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] f2949fe - Add explicit tests for the PS4/PS5 C/C++ standards version defaults.

[Douglas Yung via cfe-commits]

Author: Douglas Yung
Date: 2022-09-20T11:31:38-07:00
New Revision: f2949febf354eb8aded7db3e63d2c878fe86db3b

URL: 
https://github.com/llvm/llvm-project/commit/f2949febf354eb8aded7db3e63d2c878fe86db3b
DIFF: 
https://github.com/llvm/llvm-project/commit/f2949febf354eb8aded7db3e63d2c878fe86db3b.diff

LOG: Add explicit tests for the PS4/PS5 C/C++ standards version defaults.

Added: 
clang/test/Preprocessor/lang-std-sie.cpp

Modified: 


Removed: 




diff  --git a/clang/test/Preprocessor/lang-std-sie.cpp 
b/clang/test/Preprocessor/lang-std-sie.cpp
new file mode 100644
index ..e8e65690277a
--- /dev/null
+++ b/clang/test/Preprocessor/lang-std-sie.cpp
@@ -0,0 +1,6 @@
+/// Test that PS4/PS5 defaults to gnu++14.
+
+// RUN: %clang_cc1 -dM -E -triple x86_64-scei-ps4 %s | FileCheck 
--check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -triple x86_64-sie-ps5 %s | FileCheck 
--check-prefix=CXX14 %s
+
+// CXX14: #define __cplusplus 201402L



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82087: AMDGPU/clang: Add builtins for llvm.amdgcn.ballot

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D82087#3797883 , @jdoerfert wrote:

> Can we land this? I'd like to use the new intrinsics as I don't understand 
> the old ones.

What do you think about using the two separate builtins, vs. one magic builtin 
that auto-changes the wavesize?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82087/new/

https://reviews.llvm.org/D82087

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82087: AMDGPU/clang: Add builtins for llvm.amdgcn.ballot

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

In D82087#3803464 , @arsenm wrote:

> In D82087#3797883 , @jdoerfert wrote:
>
>> Can we land this? I'd like to use the new intrinsics as I don't understand 
>> the old ones.
>
> What do you think about using the two separate builtins, vs. one magic 
> builtin that auto-changes the wavesize?

The magic one would also change its return type, or always be i64 with high 
bits (zext or maybe sext or maybe copy of low), so less magic seems clearer


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82087/new/

https://reviews.llvm.org/D82087

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits