[PATCH] D112284: [Clang][NFC] Clang CUDA codegen clean-up

[Uday Bondhugula via Phabricator via cfe-commits]

bondhugula added a comment.

@tra While on this, I also wanted to ask as to why clang cuda codegen is using 
an argument on the global ctor and the dtor it's generating. The argument is 
unused and I couldn't find any code comments to support it in either 
`CGCUDANV.cpp` or `CodeGenModule.cpp`.  I assume there is a reason because 
`CodeGenModule.cpp` is generating an explicit bitcast and has additional 
utilities to convert the function type to one with no arguments. Without the 
argument, one could just use `appendToGlobalCtors/Dtors` from `ModuleUtils`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112284

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

[PATCH] D112481: [Sema] fix nondeterminism in ASTContext::getDeducedTemplateSpecializationType

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a reviewer: bruno.
bruno added a comment.

Nice catch, thanks for working on this!




Comment at: clang/lib/AST/ASTContext.cpp:5640
+  DeducedTemplateSpecializationType::Profile(
+  ID, Template, DeducedType, IsDependent || Template.isDependent());
   if (DeducedTemplateSpecializationType *DTST =

Should this be done in the implementation (like done for the ctor)?
```
static void Profile(llvm::FoldingSetNodeID &ID, TemplateName Template,
  QualType Deduced, bool IsDependent) {
Template.Profile(ID);
ID.AddPointer(Deduced.getAsOpaquePtr());
ID.AddBoolean(IsDependent || Template.isDependent());
  }
```



Comment at: clang/lib/AST/ASTContext.cpp:5649
+  DTST->Profile(TempID);
+  assert(ID == TempID && "ID does not match");
   Types.push_back(DTST);

Seems like this assertion is failing in some of the tests above!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112481

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

[PATCH] D112284: [Clang][NFC] Clang CUDA codegen clean-up

[Uday Bondhugula via Phabricator via cfe-commits]

bondhugula updated this revision to Diff 382201.
bondhugula marked an inline comment as done.
bondhugula retitled this revision from "[Clang][NFC] Clang CUDA codegen: a 
dyn_cast -> cast instance + clang-tidy fixes" to "[Clang][NFC] Clang CUDA 
codegen clean-up".
bondhugula edited the summary of this revision.
bondhugula added a comment.

Address review comments. Update commit title and summary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112284

Files:
  clang/lib/CodeGen/CGCUDANV.cpp


Index: clang/lib/CodeGen/CGCUDANV.cpp
===
--- clang/lib/CodeGen/CGCUDANV.cpp
+++ clang/lib/CodeGen/CGCUDANV.cpp
@@ -177,7 +177,7 @@
   llvm::Function *finalizeModule() override;
 };
 
-}
+} // end anonymous namespace
 
 std::string CGNVCUDARuntime::addPrefixToName(StringRef FuncName) const {
   if (CGM.getLangOpts().HIP)
@@ -237,11 +237,10 @@
 // hipError_t hipLaunchByPtr(char *);
 return CGM.CreateRuntimeFunction(
 llvm::FunctionType::get(IntTy, CharPtrTy, false), "hipLaunchByPtr");
-  } else {
-// cudaError_t cudaLaunch(char *);
-return CGM.CreateRuntimeFunction(
-llvm::FunctionType::get(IntTy, CharPtrTy, false), "cudaLaunch");
   }
+  // cudaError_t cudaLaunch(char *);
+  return CGM.CreateRuntimeFunction(
+  llvm::FunctionType::get(IntTy, CharPtrTy, false), "cudaLaunch");
 }
 
 llvm::FunctionType *CGNVCUDARuntime::getRegisterGlobalsFnTy() const {
@@ -253,8 +252,8 @@
 }
 
 llvm::FunctionType *CGNVCUDARuntime::getRegisterLinkedBinaryFnTy() const {
-  auto CallbackFnTy = getCallbackFnTy();
-  auto RegisterGlobalsFnTy = getRegisterGlobalsFnTy();
+  auto *CallbackFnTy = getCallbackFnTy();
+  auto *RegisterGlobalsFnTy = getRegisterGlobalsFnTy();
   llvm::Type *Params[] = {RegisterGlobalsFnTy->getPointerTo(), VoidPtrTy,
   VoidPtrTy, CallbackFnTy->getPointerTo()};
   return llvm::FunctionType::get(VoidTy, Params, false);
@@ -397,7 +396,7 @@
   QualType QT = cudaLaunchKernelFD->getType();
   QualType CQT = QT.getCanonicalType();
   llvm::Type *Ty = CGM.getTypes().ConvertType(CQT);
-  llvm::FunctionType *FTy = dyn_cast(Ty);
+  llvm::FunctionType *FTy = cast(Ty);
 
   const CGFunctionInfo &FI =
   CGM.getTypes().arrangeFunctionDeclaration(cudaLaunchKernelFD);
@@ -590,7 +589,7 @@
   uint64_t VarSize =
   CGM.getDataLayout().getTypeAllocSize(Var->getValueType());
   if (Info.Flags.isManaged()) {
-auto ManagedVar = new llvm::GlobalVariable(
+auto *ManagedVar = new llvm::GlobalVariable(
 CGM.getModule(), Var->getType(),
 /*isConstant=*/false, Var->getLinkage(),
 /*Init=*/Var->isDeclaration()
@@ -823,7 +822,7 @@
 GpuBinaryHandle,
 CharUnits::fromQuantity(GpuBinaryHandle->getAlignment()));
 {
-  auto HandleValue = CtorBuilder.CreateLoad(GpuBinaryAddr);
+  auto *HandleValue = CtorBuilder.CreateLoad(GpuBinaryAddr);
   llvm::Constant *Zero =
   llvm::Constant::getNullValue(HandleValue->getType());
   llvm::Value *EQZero = CtorBuilder.CreateICmpEQ(HandleValue, Zero);
@@ -842,7 +841,7 @@
   CtorBuilder.SetInsertPoint(ExitBlock);
   // Call __hip_register_globals(GpuBinaryHandle);
   if (RegisterGlobalsFunc) {
-auto HandleValue = CtorBuilder.CreateLoad(GpuBinaryAddr);
+auto *HandleValue = CtorBuilder.CreateLoad(GpuBinaryAddr);
 CtorBuilder.CreateCall(RegisterGlobalsFunc, HandleValue);
   }
 }
@@ -958,7 +957,7 @@
 
   Address GpuBinaryAddr(GpuBinaryHandle, CharUnits::fromQuantity(
  GpuBinaryHandle->getAlignment()));
-  auto HandleValue = DtorBuilder.CreateLoad(GpuBinaryAddr);
+  auto *HandleValue = DtorBuilder.CreateLoad(GpuBinaryAddr);
   // There is only one HIP fat binary per linked module, however there are
   // multiple destructor functions. Make sure the fat binary is unregistered
   // only once.
@@ -1071,7 +1070,7 @@
 llvm::GlobalVariable *Var = Info.Var;
 if (Info.Flags.getKind() == DeviceVarFlags::Variable &&
 Info.Flags.isManaged()) {
-  auto ManagedVar = new llvm::GlobalVariable(
+  auto *ManagedVar = new llvm::GlobalVariable(
   CGM.getModule(), Var->getType(),
   /*isConstant=*/false, Var->getLinkage(),
   /*Init=*/Var->isDeclaration()


Index: clang/lib/CodeGen/CGCUDANV.cpp
===
--- clang/lib/CodeGen/CGCUDANV.cpp
+++ clang/lib/CodeGen/CGCUDANV.cpp
@@ -177,7 +177,7 @@
   llvm::Function *finalizeModule() override;
 };
 
-}
+} // end anonymous namespace
 
 std::string CGNVCUDARuntime::addPrefixToName(StringRef FuncName) const {
   if (CGM.getLangOpts().HIP)
@@ -237,11 +237,10 @@
 // hipError_t hipLaunchByPtr(char *);
 return CGM.CreateRuntimeFunction(
 llvm::FunctionType::get(IntTy, CharPtrTy, 

[PATCH] D112284: [Clang][NFC] Clang CUDA codegen: a dyn_cast -> cast instance + clang-tidy fixes

[Uday Bondhugula via Phabricator via cfe-commits]

bondhugula marked an inline comment as done.
bondhugula added a comment.

In D112284#3085086 , @tra wrote:

> The description is a bit misleading. The dyn_cast->cast appears to be a minor 
> part of this patch.
> I'd separate clang-tidy cleanups into a separate patch or would just describe 
> all of these changes as a clean-up. dyn_cast->cast is an NFC change here, 
> too, considering that we're operating on a type of `FunctionDecl 
> *cudaLaunchKernelFD`.

I agree. I've done the latter.




Comment at: clang/lib/CodeGen/CGCUDANV.cpp:240
 llvm::FunctionType::get(IntTy, CharPtrTy, false), "hipLaunchByPtr");
-  } else {
-// cudaError_t cudaLaunch(char *);
-return CGM.CreateRuntimeFunction(
-llvm::FunctionType::get(IntTy, CharPtrTy, false), "cudaLaunch");
   }
+  // cudaError_t cudaLaunch(char *);

tra wrote:
> Nit: you could remove these `{...}` now, too.
I retained this part due to the extra comment in line with LLVM style:
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
"//We consider that readability is harmed when omitting the brace in the 
presence of a single statement that is accompanied by a comment (assuming the 
comment can’t be hoisted above the if or loop statement, see below).//"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112284

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

[PATCH] D112504: [OpenMP] Wrap (v)printf in the new RT and use same handling for AMD

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

That's an interesting approach.

Do you happen to know where I can find details of the data format behind that 
void*? Have been meaning to look at writing printf for amdgpu as host side 
decoding of that buffer. If the compiler knows how long it is, that would be a 
useful third argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112504

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

[PATCH] D111866: [RISCV] Support Zfhmin extension

[Shao-Ce SUN via Phabricator via cfe-commits]

achieveartificialintelligence updated this revision to Diff 382195.
achieveartificialintelligence added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111866

Files:
  clang/test/Driver/riscv-arch.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoZfh.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rv32zfhmin-invalid.s
  llvm/test/MC/RISCV/rv32zfhmin-valid.s

Index: llvm/test/MC/RISCV/rv32zfhmin-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zfhmin-valid.s
@@ -0,0 +1,62 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zfhmin,+d -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zfhmin,+d -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-zfhmin,+d < %s \
+# RUN: | llvm-objdump --mattr=+experimental-zfhmin,+d -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+experimental-zfhmin,+d < %s \
+# RUN: | llvm-objdump --mattr=+experimental-zfhmin,+d -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: flh ft0, 12(a0)
+# CHECK-ASM: encoding: [0x07,0x10,0xc5,0x00]
+flh f0, 12(a0)
+# CHECK-ASM-AND-OBJ: flh ft1, 4(ra)
+# CHECK-ASM: encoding: [0x87,0x90,0x40,0x00]
+flh f1, +4(ra)
+# CHECK-ASM-AND-OBJ: flh ft2, -2048(a3)
+# CHECK-ASM: encoding: [0x07,0x91,0x06,0x80]
+flh f2, -2048(x13)
+# CHECK-ASM-AND-OBJ: flh ft3, -2048(s1)
+# CHECK-ASM: encoding: [0x87,0x91,0x04,0x80]
+flh f3, %lo(2048)(s1)
+# CHECK-ASM-AND-OBJ: flh ft4, 2047(s2)
+# CHECK-ASM: encoding: [0x07,0x12,0xf9,0x7f]
+flh f4, 2047(s2)
+# CHECK-ASM-AND-OBJ: flh ft5, 0(s3)
+# CHECK-ASM: encoding: [0x87,0x92,0x09,0x00]
+flh f5, 0(s3)
+
+# CHECK-ASM-AND-OBJ: fsh ft6, 2047(s4)
+# CHECK-ASM: encoding: [0xa7,0x1f,0x6a,0x7e]
+fsh f6, 2047(s4)
+# CHECK-ASM-AND-OBJ: fsh ft7, -2048(s5)
+# CHECK-ASM: encoding: [0x27,0x90,0x7a,0x80]
+fsh f7, -2048(s5)
+# CHECK-ASM-AND-OBJ: fsh fs0, -2048(s6)
+# CHECK-ASM: encoding: [0x27,0x10,0x8b,0x80]
+fsh f8, %lo(2048)(s6)
+# CHECK-ASM-AND-OBJ: fsh fs1, 999(s7)
+# CHECK-ASM: encoding: [0xa7,0x93,0x9b,0x3e]
+fsh f9, 999(s7)
+
+# CHECK-ASM-AND-OBJ: fmv.x.h a2, fs7
+# CHECK-ASM: encoding: [0x53,0x86,0x0b,0xe4]
+fmv.x.h a2, fs7
+# CHECK-ASM-AND-OBJ: fmv.h.x ft1, a6
+# CHECK-ASM: encoding: [0xd3,0x00,0x08,0xf4]
+fmv.h.x ft1, a6
+
+# CHECK-ASM-AND-OBJ: fcvt.s.h fa0, ft0
+# CHECK-ASM: encoding: [0x53,0x05,0x20,0x40]
+fcvt.s.h fa0, ft0
+# CHECK-ASM-AND-OBJ: fcvt.h.s ft2, fa2
+# CHECK-ASM: encoding: [0x53,0x71,0x06,0x44]
+fcvt.h.s ft2, fa2
+# CHECK-ASM-AND-OBJ: fcvt.d.h fa0, ft0
+# CHECK-ASM: encoding: [0x53,0x05,0x20,0x42]
+fcvt.d.h fa0, ft0
+# CHECK-ASM-AND-OBJ: fcvt.h.d ft2, fa2
+# CHECK-ASM: encoding: [0x53,0x71,0x16,0x44]
+fcvt.h.d ft2, fa2
Index: llvm/test/MC/RISCV/rv32zfhmin-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zfhmin-invalid.s
@@ -0,0 +1,23 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+experimental-zfhmin < %s 2>&1 | \
+# RUN:   FileCheck %s
+
+# Out of range immediates
+## simm12
+flh ft1, -2049(a0) # CHECK: :[[@LINE]]:10: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo modifier or an integer in the range [-2048, 2047]
+fsh ft2, 2048(a1) # CHECK: :[[@LINE]]:10: error: operand must be a symbol with %lo/%pcrel_lo/%tprel_lo modifier or an integer in the range [-2048, 2047]
+
+# Memory operand not formatted correctly
+flh ft1, a0, -200 # CHECK: :[[@LINE]]:14: error: invalid operand for instruction
+
+# Invalid register names
+flh ft15, 100(a0) # CHECK: :[[@LINE]]:5: error: invalid operand for instruction
+flh ft1, 100(a10) # CHECK: :[[@LINE]]:14: error: expected register
+
+# Integer registers where FP regs are expected
+fmv.x.h fs7, a2 # CHECK: :[[@LINE]]:9: error: invalid operand for instruction
+
+# FP registers where integer regs are expected
+fmv.h.x a8, ft2 # CHECK: :[[@LINE]]:9: error: invalid operand for instruction
+
+# Zfh instructions
+fmadd.h f10, f11, f12, f13, dyn # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zfh' (Half-Precision Floating-Point)
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -66,8 +66,11 @@
 .attribute arch, "rv32izbt"
 # CHECK: attribute  5, "rv32i2p0_zbt0p93"
 
+.attribute arch, "rv32ifzfhmi

[PATCH] D112334: [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Thanks for the review! I forgot to mention the Differential Revision in the 
commit message after pushing so this review stays open, is there any way I can 
add it now in some other way? I suppose we don't want force-push?


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

https://reviews.llvm.org/D112334

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

[clang-tools-extra] b43a2ae - [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Carlos Galvez via cfe-commits]

Author: Carlos Galvez
Date: 2021-10-26T05:45:25Z
New Revision: b43a2aee4ee946d8897880e824f4b09fe4c46143

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

LOG: [clang-tidy] Suppress readability-static-access-through-instance for CUDA 
built-in variables

clang-tidy can be used to statically analyze CUDA code,
thanks to clang being able to compile CUDA code natively.
This makes clang-tidy the one and only open-source
static analyzer for CUDA.

However it currently warns for native CUDA built-in
variables, like threadIdx, due to the way they
are implemented in clang.

Users don't need to know the details of the clang
implementation, and they should continue to write
idiomatic code. Therefore, suppress the warning
if a CUDA built-in variable is encountered.

Fixes https://bugs.llvm.org/show_bug.cgi?id=48758

Added: 

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h

Modified: 

clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp

clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
 
b/clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
index df4a39e11ce43..f2c1b0f5ec49b 100644
--- 
a/clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ 
b/clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -9,6 +9,7 @@
 #include "StaticAccessedThroughInstanceCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "llvm/ADT/StringRef.h"
 
 using namespace clang::ast_matchers;
 
@@ -54,7 +55,7 @@ void StaticAccessedThroughInstanceCheck::check(
 
   const Expr *BaseExpr = MemberExpression->getBase();
 
-  // Do not warn for overlaoded -> operators.
+  // Do not warn for overloaded -> operators.
   if (isa(BaseExpr))
 return;
 
@@ -70,6 +71,10 @@ void StaticAccessedThroughInstanceCheck::check(
   std::string BaseTypeName =
   BaseType.getAsString(PrintingPolicyWithSupressedTag);
 
+  // Do not warn for CUDA built-in variables.
+  if (StringRef(BaseTypeName).startswith("__cuda_builtin_"))
+return;
+
   SourceLocation MemberExprStartLoc = MemberExpression->getBeginLoc();
   auto Diag =
   diag(MemberExprStartLoc, "static member accessed through instance");

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
new file mode 100644
index 0..63eb17303c6e8
--- /dev/null
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
@@ -0,0 +1,36 @@
+//===--- __clang_cuda_builtin_vars.h - Stub header for tests *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef ___CLANG_CUDA_BUILTIN_VARS_H_
+#define ___CLANG_CUDA_BUILTIN_VARS_H_
+
+#define __CUDA_DEVICE_BUILTIN(FIELD) \
+  static unsigned int FIELD;
+
+struct __cuda_builtin_threadIdx_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_blockIdx_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_blockDim_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_gridDim_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+__cuda_builtin_threadIdx_t threadIdx;
+__cuda_builtin_blockIdx_t blockIdx;
+__cuda_builtin_blockDim_t blockDim;
+__cuda_builtin_gridDim_t gridDim;
+
+#endif // ___CLANG_CUDA_BUILTIN_VARS_H_

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
index 9de96ae3a9d35..cd8d198c3d47d 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
@@ -1,4 +1,5 @@
-// RUN: %check_clang_tidy %s readability-static-accessed-through-instance %t
+// RUN: %check_clang_tidy %s readability-static-accessed-through-instance %t 
-- -- -isystem %S/Inputs/readability-static-accessed-through-instance
+#include <__clang_cuda_builtin_vars.h>
 
 struct C {
   static void foo();
@@ -248,3 +249,17 @@ void use_inline() {

[PATCH] D112390: [AIX][ZOS] Disable tests due to lack of Objective-C support

[Jake Egan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1ff1bcab970a: [AIX][ZOS] Disable tests due to lack of 
Objective-C support (authored by Jake-Egan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112390

Files:
  clang/test/Modules/ModuleDebugInfo.cpp
  clang/test/Modules/ModuleDebugInfo.m
  clang/test/Modules/clang_module_file_info.m
  clang/test/Modules/debug-info-moduleimport-in-module.m
  clang/test/Modules/module-debuginfo-prefix.m
  llvm/test/DebugInfo/X86/objc_direct.ll


Index: llvm/test/DebugInfo/X86/objc_direct.ll
===
--- llvm/test/DebugInfo/X86/objc_direct.ll
+++ llvm/test/DebugInfo/X86/objc_direct.ll
@@ -1,3 +1,4 @@
+; UNSUPPORTED: -zos, -aix
 ; RUN: llc < %s -filetype=obj -o %t
 ; RUN: llvm-dwarfdump -v %t | FileCheck %s
 
Index: clang/test/Modules/module-debuginfo-prefix.m
===
--- clang/test/Modules/module-debuginfo-prefix.m
+++ clang/test/Modules/module-debuginfo-prefix.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // REQUIRES: asserts
 
 // Modules:
Index: clang/test/Modules/debug-info-moduleimport-in-module.m
===
--- clang/test/Modules/debug-info-moduleimport-in-module.m
+++ clang/test/Modules/debug-info-moduleimport-in-module.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that an @import inside a module is not represented in the debug info.
 
 // REQUIRES: asserts
Index: clang/test/Modules/clang_module_file_info.m
===
--- clang/test/Modules/clang_module_file_info.m
+++ clang/test/Modules/clang_module_file_info.m
@@ -1,4 +1,4 @@
-
+// UNSUPPORTED: -zos, -aix
 @import DependsOnModule;
 
 // RUN: rm -rf %t %t-obj
Index: clang/test/Modules/ModuleDebugInfo.m
===
--- clang/test/Modules/ModuleDebugInfo.m
+++ clang/test/Modules/ModuleDebugInfo.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that debug info is emitted for an Objective-C module and
 // a precompiled header.
 
Index: clang/test/Modules/ModuleDebugInfo.cpp
===
--- clang/test/Modules/ModuleDebugInfo.cpp
+++ clang/test/Modules/ModuleDebugInfo.cpp
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that (the same) debug info is emitted for an Objective-C++
 // module and a C++ precompiled header.
 


Index: llvm/test/DebugInfo/X86/objc_direct.ll
===
--- llvm/test/DebugInfo/X86/objc_direct.ll
+++ llvm/test/DebugInfo/X86/objc_direct.ll
@@ -1,3 +1,4 @@
+; UNSUPPORTED: -zos, -aix
 ; RUN: llc < %s -filetype=obj -o %t
 ; RUN: llvm-dwarfdump -v %t | FileCheck %s
 
Index: clang/test/Modules/module-debuginfo-prefix.m
===
--- clang/test/Modules/module-debuginfo-prefix.m
+++ clang/test/Modules/module-debuginfo-prefix.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // REQUIRES: asserts
 
 // Modules:
Index: clang/test/Modules/debug-info-moduleimport-in-module.m
===
--- clang/test/Modules/debug-info-moduleimport-in-module.m
+++ clang/test/Modules/debug-info-moduleimport-in-module.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that an @import inside a module is not represented in the debug info.
 
 // REQUIRES: asserts
Index: clang/test/Modules/clang_module_file_info.m
===
--- clang/test/Modules/clang_module_file_info.m
+++ clang/test/Modules/clang_module_file_info.m
@@ -1,4 +1,4 @@
-
+// UNSUPPORTED: -zos, -aix
 @import DependsOnModule;
 
 // RUN: rm -rf %t %t-obj
Index: clang/test/Modules/ModuleDebugInfo.m
===
--- clang/test/Modules/ModuleDebugInfo.m
+++ clang/test/Modules/ModuleDebugInfo.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that debug info is emitted for an Objective-C module and
 // a precompiled header.
 
Index: clang/test/Modules/ModuleDebugInfo.cpp
===
--- clang/test/Modules/ModuleDebugInfo.cpp
+++ clang/test/Modules/ModuleDebugInfo.cpp
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that (the same) debug info is emitted for an Objective-C++
 // module and a C++ precompiled header.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1ff1bca - [AIX][ZOS] Disable tests due to lack of Objective-C support

[Jake Egan via cfe-commits]

Author: Jake Egan
Date: 2021-10-25T23:32:13-04:00
New Revision: 1ff1bcab970afaef49e2ab8ab7681a12d11ad17d

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

LOG: [AIX][ZOS] Disable tests due to lack of Objective-C support

AIX and z/OS lack Objective-C support, so mark these tests as unsupported for 
AIX and z/OS.

This patch follows the same reasoning as D109060.

Reviewed By: jsji

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

Added: 


Modified: 
clang/test/Modules/ModuleDebugInfo.cpp
clang/test/Modules/ModuleDebugInfo.m
clang/test/Modules/clang_module_file_info.m
clang/test/Modules/debug-info-moduleimport-in-module.m
clang/test/Modules/module-debuginfo-prefix.m
llvm/test/DebugInfo/X86/objc_direct.ll

Removed: 




diff  --git a/clang/test/Modules/ModuleDebugInfo.cpp 
b/clang/test/Modules/ModuleDebugInfo.cpp
index 836f0d28fb2a2..433002c6cdbe3 100644
--- a/clang/test/Modules/ModuleDebugInfo.cpp
+++ b/clang/test/Modules/ModuleDebugInfo.cpp
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that (the same) debug info is emitted for an Objective-C++
 // module and a C++ precompiled header.
 

diff  --git a/clang/test/Modules/ModuleDebugInfo.m 
b/clang/test/Modules/ModuleDebugInfo.m
index ed576e441e5da..5493d6edc581c 100644
--- a/clang/test/Modules/ModuleDebugInfo.m
+++ b/clang/test/Modules/ModuleDebugInfo.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that debug info is emitted for an Objective-C module and
 // a precompiled header.
 

diff  --git a/clang/test/Modules/clang_module_file_info.m 
b/clang/test/Modules/clang_module_file_info.m
index b949c68c63903..8ae7483639661 100644
--- a/clang/test/Modules/clang_module_file_info.m
+++ b/clang/test/Modules/clang_module_file_info.m
@@ -1,4 +1,4 @@
-
+// UNSUPPORTED: -zos, -aix
 @import DependsOnModule;
 
 // RUN: rm -rf %t %t-obj

diff  --git a/clang/test/Modules/debug-info-moduleimport-in-module.m 
b/clang/test/Modules/debug-info-moduleimport-in-module.m
index cde46115d288a..71b863e8bce15 100644
--- a/clang/test/Modules/debug-info-moduleimport-in-module.m
+++ b/clang/test/Modules/debug-info-moduleimport-in-module.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // Test that an @import inside a module is not represented in the debug info.
 
 // REQUIRES: asserts

diff  --git a/clang/test/Modules/module-debuginfo-prefix.m 
b/clang/test/Modules/module-debuginfo-prefix.m
index da5d86abefd08..5a6f924bf60e7 100644
--- a/clang/test/Modules/module-debuginfo-prefix.m
+++ b/clang/test/Modules/module-debuginfo-prefix.m
@@ -1,3 +1,4 @@
+// UNSUPPORTED: -zos, -aix
 // REQUIRES: asserts
 
 // Modules:

diff  --git a/llvm/test/DebugInfo/X86/objc_direct.ll 
b/llvm/test/DebugInfo/X86/objc_direct.ll
index c29dec14a4488..87e0f08241a3e 100644
--- a/llvm/test/DebugInfo/X86/objc_direct.ll
+++ b/llvm/test/DebugInfo/X86/objc_direct.ll
@@ -1,3 +1,4 @@
+; UNSUPPORTED: -zos, -aix
 ; RUN: llc < %s -filetype=obj -o %t
 ; RUN: llvm-dwarfdump -v %t | FileCheck %s
 



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

[PATCH] D112504: [OpenMP] Wrap (v)printf in the new RT and use same handling for AMD

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert updated this revision to Diff 382171.
jdoerfert added a comment.

Actually use the new wrapper for OpenMP offload targeting AMD (and the new RT)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112504

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGGPUBuiltin.cpp
  openmp/libomptarget/DeviceRTL/include/Debug.h
  openmp/libomptarget/DeviceRTL/include/Interface.h
  openmp/libomptarget/DeviceRTL/src/Debug.cpp

Index: openmp/libomptarget/DeviceRTL/src/Debug.cpp
===
--- openmp/libomptarget/DeviceRTL/src/Debug.cpp
+++ openmp/libomptarget/DeviceRTL/src/Debug.cpp
@@ -38,6 +38,15 @@
  assertion);
   __builtin_trap();
 }
+
+// We do not have a vprintf implementation for AMD GPU yet so we use a stub.
+#pragma omp begin declare variant match(device = {arch(amdgcn)})
+int32_t vprintf(const char *, void *) { return 0; }
+#pragma omp end declare variant
+
+int32_t __llvm_omp_vprintf(const char *Format, void *Arguments) {
+  return vprintf(Format, Arguments);
+}
 }
 
 /// Current indentation level for the function trace. Only accessed by thread 0.
Index: openmp/libomptarget/DeviceRTL/include/Interface.h
===
--- openmp/libomptarget/DeviceRTL/include/Interface.h
+++ openmp/libomptarget/DeviceRTL/include/Interface.h
@@ -340,6 +340,9 @@
 int32_t __kmpc_shuffle_int32(int32_t val, int16_t delta, int16_t size);
 int64_t __kmpc_shuffle_int64(int64_t val, int16_t delta, int16_t size);
 ///}
+
+/// Printf
+int32_t __llvm_omp_vprintf(const char *Format, void *Arguments);
 }
 
 #endif
Index: openmp/libomptarget/DeviceRTL/include/Debug.h
===
--- openmp/libomptarget/DeviceRTL/include/Debug.h
+++ openmp/libomptarget/DeviceRTL/include/Debug.h
@@ -46,17 +46,12 @@
 /// macro.
 /// {
 
-#ifndef __AMDGCN__
 extern "C" {
 int printf(const char *format, ...);
 }
 
 #define PRINTF(fmt, ...) (void)printf(fmt, __VA_ARGS__)
 #define PRINT(str) PRINTF("%s", str)
-#else
-#define PRINTF(fmt, ...)
-#define PRINT(str)
-#endif
 
 #define WARN(fmt, ...) PRINTF("WARNING: " #fmt, __VA_ARGS__)
 
Index: clang/lib/CodeGen/CGGPUBuiltin.cpp
===
--- clang/lib/CodeGen/CGGPUBuiltin.cpp
+++ clang/lib/CodeGen/CGGPUBuiltin.cpp
@@ -21,24 +21,30 @@
 using namespace clang;
 using namespace CodeGen;
 
-static llvm::Function *GetVprintfDeclaration(llvm::Module &M) {
+static llvm::Function *GetVprintfDeclaration(CodeGenModule &CGM) {
+  bool UsesNewOpenMPDeviceRuntime = CGM.getLangOpts().OpenMPIsDevice &&
+CGM.getLangOpts().OpenMPTargetNewRuntime;
+  const char *Name =
+  UsesNewOpenMPDeviceRuntime ? "__llvm_omp_vprintf" : "vprintf";
+  llvm::Module &M = CGM.getModule();
   llvm::Type *ArgTypes[] = {llvm::Type::getInt8PtrTy(M.getContext()),
 llvm::Type::getInt8PtrTy(M.getContext())};
   llvm::FunctionType *VprintfFuncType = llvm::FunctionType::get(
   llvm::Type::getInt32Ty(M.getContext()), ArgTypes, false);
 
-  if (auto* F = M.getFunction("vprintf")) {
+  if (auto *F = M.getFunction(Name)) {
 // Our CUDA system header declares vprintf with the right signature, so
 // nobody else should have been able to declare vprintf with a bogus
-// signature.
+// signature. The OpenMP device runtime provides a wrapper around vprintf
+// which we use here. The signature should match though.
 assert(F->getFunctionType() == VprintfFuncType);
 return F;
   }
 
-  // vprintf doesn't already exist; create a declaration and insert it into the
-  // module.
+  // vprintf, or for OpenMP device offloading the vprintf wrapper, doesn't
+  // already exist; create a declaration and insert it into the module.
   return llvm::Function::Create(
-  VprintfFuncType, llvm::GlobalVariable::ExternalLinkage, "vprintf", &M);
+  VprintfFuncType, llvm::GlobalVariable::ExternalLinkage, Name, &M);
 }
 
 // Transforms a call to printf into a call to the NVPTX vprintf syscall (which
@@ -117,7 +123,7 @@
   }
 
   // Invoke vprintf and return.
-  llvm::Function* VprintfFunc = GetVprintfDeclaration(CGM.getModule());
+  llvm::Function *VprintfFunc = GetVprintfDeclaration(CGM);
   return RValue::get(Builder.CreateCall(
   VprintfFunc, {Args[0].getRValue(*this).getScalarVal(), BufferPtr}));
 }
@@ -130,6 +136,12 @@
  E->getBuiltinCallee() == Builtin::BI__builtin_printf);
   assert(E->getNumArgs() >= 1); // printf always has at least one arg.
 
+  // For OpenMP target offloading we go with a modified nvptx printf method.
+  // Basically creating calls to __llvm_omp_vprintf with the arguments and
+  // dealing with the details in the device runtime itself.
+  if (getLangOpts().OpenMPIsDevice && getLangOpts().OpenMPTargetNewRuntime)
+  

[PATCH] D109506: [clangd] Print current request context along with the stack trace

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In D109506#3086183 , @thakis wrote:

> This doesn't build on windows: http://45.33.8.238/win/47615/step_4.txt
>
> Please take a look and revert for now if it takes a while to fix.

I pushed rGba94b8bdffb4 
 as a 
speculative fix. I'll keep an eye on that bot. Thanks for the heads up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

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

[clang-tools-extra] ba94b8b - [clangd] Attempt to fix buildbots

[Shoaib Meenai via cfe-commits]

Author: Shoaib Meenai
Date: 2021-10-25T20:16:59-07:00
New Revision: ba94b8bdffb4c65d5475746a6ba43d279683e5bd

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

LOG: [clangd] Attempt to fix buildbots

http://45.33.8.238/win/47615/step_4.txt is a sample error; I believe it
just needs the right header to be included.

Added: 


Modified: 
clang-tools-extra/clangd/support/ThreadCrashReporter.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/support/ThreadCrashReporter.cpp 
b/clang-tools-extra/clangd/support/ThreadCrashReporter.cpp
index e67900e6916d9..b0386ba0089d0 100644
--- a/clang-tools-extra/clangd/support/ThreadCrashReporter.cpp
+++ b/clang-tools-extra/clangd/support/ThreadCrashReporter.cpp
@@ -9,6 +9,7 @@
 #include "support/ThreadCrashReporter.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/ThreadLocal.h"
+#include 
 
 namespace clang {
 namespace clangd {



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

[PATCH] D108696: [Coroutines] [Frontend] Lookup in std namespace first

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D108696#3086011 , @lewissbaker 
wrote:

> So am I correct in understanding that the main issue with the chicken/egg 
> problem for updating both the compiler to use the new stdlib facilities and 
> updating the stdlib facilities is that we don't want to issue warnings about 
> using `` and telling users to use `` 
> instead if there is no `` header.
>
> I wonder if a suitable transition approach here might be to have the compiler 
> do:
>
> - try lookup of std::coroutine_handle/coroutine_traits; if found try to 
> instantiate the expression (e.g. await-suspend) using the std:: type
> - if not found then try lookup of 
> std::experimental::coroutine_handle/coroutine_traits; and if found try to 
> instantiate the expression using the std::experimental:: type; and if 
> successful, then;
>   - if std:: type was found but instantiating the expression failed, then 
> issue a warning about using deprecated std::experimental:: types
>   - otherwise if std:: type was not found, try to find  header and 
> if present then issue a warning suggesting using  instead of 
> 
>
> Then you should be able to land the compiler change and it should continue to 
> have the same behaviour for existing code using std::experimental:: types 
> with the existing stdlib.
> It is only once the stdlib changes that land which add the  header 
> that users would start seeing the warnings about using  instead of 
> 

It looks odd for me with the sentence:

> otherwise if std:: type was not found, try to find  header and if 
> present then issue a warning suggesting using  instead of 
> 

If we could find the  header, we should be able to find `std::coro*` 
types. Otherwise, the  header is fake.

My transition plan would be:

- Land this.
- Land D109433 , it is the change who added 
.
- Land another patch in clang to issue a warning for the deprecated use of 
. The reason why we need to split this with the first 
step is that we don't want to trigger the CI system for libc++. (It's the 
reason this patch is rejected before).
- Remove  in libcxx in LLVM15.
- Remove the support for `std::experimental::coro*` in clang in LLVM16.



> Note that there are still some potential breakages for code that could go on 
> here, however.
>
> Imagine that some header I included has been updated to use  while 
> my current header is still using  so that both are in 
> scope.
>
> I might have defined an awaitable type that looks like the following:
>
>   c++
>   #include  // which transitively includes 
>   #include 
>   
>   struct my_awaitable {
> bool await_ready();
> void await_suspend(std::experimental::coroutine_handle<> coro);
> void await_resume();
>   };
>
> In this case, the compiler would find the `std::coroutine_handle<>` and try 
> to instantiate the await-suspend expression with that type, which would fail 
> because `await_suspend()` is not callable with a `std::coroutine_handle`.
> The compiler would need to fall back to instantiating the expression with 
> `std::experimental::coroutine_handle`.

My personal opinion is that this case should fail instead of requiring the 
compiler to fall back to instantiating with `std::experimental::coro*`. There 
are two reasons:

- It is not easy to implement such fall back to instantiating logics. It would 
make the current search process much more complex.
- It is not worth to do so in my opinion. Since  is the 
deprecated use. It is odd for me that we need to do extra work to conform it.

> There is also the variation where await_suspend() is a template function that 
> deduces the promise-type argument.
> e.g.
>
>   c++
>   template
>   void await_suspend(std::experimental::coroutine_handle coro);
>
> There are also cases where the template parameter to await_suspend() is 
> unconstrained.
> e.g.
>
>   c++
>   struct promise_type {
> ...
> std::experimental::coroutine_handle<> continuation;
>   };
>   
>   struct my_awaitable {
> bool await_ready();
> template
> auto await_suspend(CoroHandle handle) {
>   coro.promise().continuation = handle;
>   return coro;
> }
> void await_resume();
>   
> std::experimental::coroutine_handle coro;
>   };
>
> Such a type would successfully deduce the template parameter using 
> std::coroutine_handle and so the await-suspend expression would be valid, but 
> the instantiation of the await_suspend() body would fail as a 
> std::coroutine_handle cannot be assigned to an lvalue of type 
> `std::experimentl::coroutine_handle<>`. This would not produce a 
> SFINAE-friendly error that the compiler could retry with std::experimental 
> types.
>
> I'm not sure if there's a great way of keeping such code working in a mixed 
> `` and `` world.
> Maybe the cost of doing so is not worth the benefit?

Thanks for offering these examples. It is valuable. But I think the root cause 
may be the mixed use for `` and ``. It is 

[PATCH] D109506: [clangd] Print current request context along with the stack trace

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

This doesn't build on windows: http://45.33.8.238/win/47615/step_4.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

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

[PATCH] D112504: [OpenMP] Wrap (v)printf in the new RT and use same handling for AMD

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added reviewers: JonChesterfield, tianshilei1992, jhuber6.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added projects: clang, OpenMP.

To support `printf` NVPTX and AMD targets are handled differently. The
latter performs host calls, which we don't really want in OpenMP, the
former translates `printf` calls to `vprintf` calls as the NVIDIA
runtime provides an implementation for the device of `vprintf`. This
patch unifies the AMD and NVPTX handling and emits for both calls to the
`vprintf` wrapper `__llvm_omp_vprintf` which we define in our new device
runtime. The main benefit of this wrapper is that we can more easily
control (and profile) the emission of `printf` calls in device code.

Note: Tests are coming.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112504

Files:
  clang/lib/CodeGen/CGGPUBuiltin.cpp
  openmp/libomptarget/DeviceRTL/include/Debug.h
  openmp/libomptarget/DeviceRTL/include/Interface.h
  openmp/libomptarget/DeviceRTL/src/Debug.cpp

Index: openmp/libomptarget/DeviceRTL/src/Debug.cpp
===
--- openmp/libomptarget/DeviceRTL/src/Debug.cpp
+++ openmp/libomptarget/DeviceRTL/src/Debug.cpp
@@ -38,6 +38,15 @@
  assertion);
   __builtin_trap();
 }
+
+// We do not have a vprintf implementation for AMD GPU yet so we use a stub.
+#pragma omp begin declare variant match(device = {arch(amdgcn)})
+int32_t vprintf(const char *, void *) { return 0; }
+#pragma omp end declare variant
+
+int32_t __llvm_omp_vprintf(const char *Format, void *Arguments) {
+  return vprintf(Format, Arguments);
+}
 }
 
 /// Current indentation level for the function trace. Only accessed by thread 0.
Index: openmp/libomptarget/DeviceRTL/include/Interface.h
===
--- openmp/libomptarget/DeviceRTL/include/Interface.h
+++ openmp/libomptarget/DeviceRTL/include/Interface.h
@@ -340,6 +340,9 @@
 int32_t __kmpc_shuffle_int32(int32_t val, int16_t delta, int16_t size);
 int64_t __kmpc_shuffle_int64(int64_t val, int16_t delta, int16_t size);
 ///}
+
+/// Printf
+int32_t __llvm_omp_vprintf(const char *Format, void *Arguments);
 }
 
 #endif
Index: openmp/libomptarget/DeviceRTL/include/Debug.h
===
--- openmp/libomptarget/DeviceRTL/include/Debug.h
+++ openmp/libomptarget/DeviceRTL/include/Debug.h
@@ -46,17 +46,12 @@
 /// macro.
 /// {
 
-#ifndef __AMDGCN__
 extern "C" {
 int printf(const char *format, ...);
 }
 
 #define PRINTF(fmt, ...) (void)printf(fmt, __VA_ARGS__)
 #define PRINT(str) PRINTF("%s", str)
-#else
-#define PRINTF(fmt, ...)
-#define PRINT(str)
-#endif
 
 #define WARN(fmt, ...) PRINTF("WARNING: " #fmt, __VA_ARGS__)
 
Index: clang/lib/CodeGen/CGGPUBuiltin.cpp
===
--- clang/lib/CodeGen/CGGPUBuiltin.cpp
+++ clang/lib/CodeGen/CGGPUBuiltin.cpp
@@ -21,24 +21,30 @@
 using namespace clang;
 using namespace CodeGen;
 
-static llvm::Function *GetVprintfDeclaration(llvm::Module &M) {
+static llvm::Function *GetVprintfDeclaration(CodeGenModule &CGM) {
+  bool UsesNewOpenMPDeviceRuntime = CGM.getLangOpts().OpenMPIsDevice &&
+CGM.getLangOpts().OpenMPTargetNewRuntime;
+  const char *Name =
+  UsesNewOpenMPDeviceRuntime ? "__llvm_omp_vprintf" : "vprintf";
+  llvm::Module &M = CGM.getModule();
   llvm::Type *ArgTypes[] = {llvm::Type::getInt8PtrTy(M.getContext()),
 llvm::Type::getInt8PtrTy(M.getContext())};
   llvm::FunctionType *VprintfFuncType = llvm::FunctionType::get(
   llvm::Type::getInt32Ty(M.getContext()), ArgTypes, false);
 
-  if (auto* F = M.getFunction("vprintf")) {
+  if (auto *F = M.getFunction(Name)) {
 // Our CUDA system header declares vprintf with the right signature, so
 // nobody else should have been able to declare vprintf with a bogus
-// signature.
+// signature. The OpenMP device runtime provides a wrapper around vprintf
+// which we use here. The signature should match though.
 assert(F->getFunctionType() == VprintfFuncType);
 return F;
   }
 
-  // vprintf doesn't already exist; create a declaration and insert it into the
-  // module.
+  // vprintf, or for OpenMP device offloading the vprintf wrapper, doesn't
+  // already exist; create a declaration and insert it into the module.
   return llvm::Function::Create(
-  VprintfFuncType, llvm::GlobalVariable::ExternalLinkage, "vprintf", &M);
+  VprintfFuncType, llvm::GlobalVariable::ExternalLinkage, Name, &M);
 }
 
 // Transforms a call to printf into a call to the NVPTX vprintf syscall (which
@@ -117,7 +123,7 @@
   }
 
   // Invoke vprintf and return.
-  llvm::Function* VprintfFunc = GetVprintfDeclaration(CGM.getModule());
+  llvm::Function *Vpr

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

[Chandler Carruth via Phabricator via cfe-commits]

chandlerc added inline comments.



Comment at: clang/include/clang/Basic/Builtins.def:1059
+#undef strcasecmp
+#undef strncasecmp
+

thakis wrote:
> Why do we need this with bazel but not with other windows builds?
I don't know how this never was hit by other builders. I don't usually develop 
on Windows so I have very little experience with different builds there.

My guess is that it is the particular way that Bazel+clang-cl compile on 
Windows causes sligthtly more to be transitively included with `#include 
` and that grows the number of functions hit with this. I thought 
about trying to "fix" that, but the existing `#undef` lines made me think it 
wouldn't be completely successful.

Are you worried about the change? Looking for a different fix?



Comment at: 
utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h:78
 /* Define if we have sys/resource.h (rlimits) */
-#define CLANG_HAVE_RLIMITS 1
+/* CLANG_HAVE_RLIMITS defined in Bazel */
 

GMNGeoffrey wrote:
> Hmm I think we probably should have a change-detector for this config as well 
> as the LLVM ones
Yeah, but didn't want to try to add that in this change.

IMO, the better thing would be for this to go away as it is almost entirely 
redundant already But agin, not this change



Comment at: utils/bazel/llvm-project-overlay/llvm/cc_plugin_library.bzl:33
+for impl_name in [dll_name, dylib_name, so_name]:
+cc_binary(
+name = impl_name,

GMNGeoffrey wrote:
> What about this makes `binary_alias` no longer work?
The `output_group` in the subsequent `filegroup`. It requires the actions in 
the sources to have a correctly named `output_group`, which `cc_binary` with 
`linkshared` does.

It's possible that I could just rename things enough by adding multiple layers 
of file groups and maybe some added "copy this file" rules... But I'm worried 
that wouldn't work well long term. For example, it seems reasonable for the 
`.lib` file to *name* the `.dll` file that should be loaded. And so if we build 
it with `cc_binary` that has the wrong name, I'm worried things won't work as 
expected. I have higher confidence in this arrangement where the `cc_binary` 
directly produces the desired name.

Something like that actually happened when I tried a different way of wiring 
this up that still used the `binary_alias` on Linux -- it ended up actually 
loading `liblibclang_impl.so` and not `libclang.so`. That was a different 
setup, so maaaybe I wouldn't hit that exact situation, but its the kind of 
thing that inclined me towards this model.


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

https://reviews.llvm.org/D112399

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

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

That sounds right. You can test that scenario in a debugger, by putting a 
breakpoint before BuryPointer in clang/tools/driver/driver.cpp and verifying 
that the TimerGroup still has a pointer to the deleted stack frames, after the 
CrashRecoveryContext has successfully catches the abort().


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112498

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

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/include/clang/Basic/Builtins.def:1059
+#undef strcasecmp
+#undef strncasecmp
+

Why do we need this with bazel but not with other windows builds?


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

https://reviews.llvm.org/D112399

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

Re: [clang] 2edb89c - Lex arguments for __has_cpp_attribute and friends as expanded tokens

[Nico Weber via cfe-commits]

Looks like the reason for this check was that
https://github.com/llvm/llvm-project/blob/3b42fc8a07c37e47efae80c931eff7e63103e0e9/clang/include/clang/Basic/Attr.td#L1946
contains __unsafe_unretained despite it just being a macro here:
http://llvm-cs.pcc.me.uk/tools/clang/lib/Frontend/InitPreprocessor.cpp#1019

Is that Attr.td entry incorrect?

On Mon, Oct 25, 2021 at 8:40 PM Nico Weber  wrote:

> Was this reviewed anywhere?
>
> I'll note that some internal project apparently used to check `#if
> __has_attribute(__unsafe_unretained)`. That used to silently (and
> incorrectly I think) always return 0 as far as I can tell, but now it fails
> with:
>
> ```
> $ out/gn/bin/clang -c foo.mm
> foo.mm:1:21: error: missing ')' after '__attribute__'
> #if __has_attribute(__unsafe_unretained)
> ^~~
> :350:42: note: expanded from here
> #define __unsafe_unretained __attribute__((objc_ownership(none)))
> ~^
> foo.mm:1:20: note: to match this '('
> #if __has_attribute(__unsafe_unretained)
>^
> 1 error generated.
> ```
>
> That's arguably a progression and I'm still finding out what the intent
> there was (maybe `#ifdef __unsafe_unretained`?).
>
> So nothing to do here I think, but I thought I'd mention it.
>
> On Sun, Oct 17, 2021 at 7:58 AM Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Aaron Ballman
>> Date: 2021-10-17T07:54:48-04:00
>> New Revision: 2edb89c746848c52964537268bf03e7906bf2542
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/2edb89c746848c52964537268bf03e7906bf2542
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/2edb89c746848c52964537268bf03e7906bf2542.diff
>>
>> LOG: Lex arguments for __has_cpp_attribute and friends as expanded tokens
>>
>> The C and C++ standards require the argument to __has_cpp_attribute and
>> __has_c_attribute to be expanded ([cpp.cond]p5). It would make little
>> sense
>> to expand the argument to those operators but not expand the argument to
>> __has_attribute and __has_declspec, so those were both also changed in
>> this
>> patch.
>>
>> Note that it might make sense for the other builtins to also expand their
>> argument, but it wasn't as clear to me whether the behavior would be
>> correct
>> there, and so they were left for a future revision.
>>
>> Added:
>> clang/test/Preprocessor/has_attribute_errors.cpp
>>
>> Modified:
>> clang/docs/ReleaseNotes.rst
>> clang/lib/Lex/PPMacroExpansion.cpp
>> clang/test/Preprocessor/has_attribute.c
>> clang/test/Preprocessor/has_attribute.cpp
>> clang/test/Preprocessor/has_c_attribute.c
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
>> index 6501a4870e2a6..263eae83036df 100644
>> --- a/clang/docs/ReleaseNotes.rst
>> +++ b/clang/docs/ReleaseNotes.rst
>> @@ -110,6 +110,13 @@ Attribute Changes in Clang
>>attribute is handled instead, e.g. in ``handleDeclAttribute``.
>>(This was changed in order to better support attributes in code
>> completion).
>>
>> +- __has_cpp_attribute, __has_c_attribute, __has_attribute, and
>> __has_declspec
>> +  will now macro expand their argument. This causes a change in behavior
>> for
>> +  code using ``__has_cpp_attribute(__clang__::attr)`` (and same for
>> +  ``__has_c_attribute``) where it would previously expand to ``0`` for
>> all
>> +  attributes, but will now issue an error due to the expansion of the
>> +  predefined ``__clang__`` macro.
>> +
>>  Windows Support
>>  ---
>>
>>
>> diff  --git a/clang/lib/Lex/PPMacroExpansion.cpp
>> b/clang/lib/Lex/PPMacroExpansion.cpp
>> index bf19f538647e6..5a0fa5184e38b 100644
>> --- a/clang/lib/Lex/PPMacroExpansion.cpp
>> +++ b/clang/lib/Lex/PPMacroExpansion.cpp
>> @@ -1293,7 +1293,7 @@ static bool EvaluateHasIncludeNext(Token &Tok,
>>  /// integer values.
>>  static void EvaluateFeatureLikeBuiltinMacro(llvm::raw_svector_ostream&
>> OS,
>>  Token &Tok, IdentifierInfo
>> *II,
>> -Preprocessor &PP,
>> +Preprocessor &PP, bool
>> ExpandArgs,
>>  llvm::function_ref<
>>int(Token &Tok,
>>bool
>> &HasLexedNextTok)> Op) {
>> @@ -1319,7 +1319,10 @@ static void
>> EvaluateFeatureLikeBuiltinMacro(llvm::raw_svector_ostream& OS,
>>bool SuppressDiagnostic = false;
>>while (true) {
>>  // Parse next token.
>> -PP.LexUnexpandedToken(Tok);
>> +if (ExpandArgs)
>> +  PP.Lex(Tok);
>> +else
>> +  PP.LexUnexpandedToken(Tok);
>>
>>  already_lexed:
>>  switch (Tok.getKind()) {
>> @@ -1609,21 +1612,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok)
>> {
>>  O

Re: [clang] 2edb89c - Lex arguments for __has_cpp_attribute and friends as expanded tokens

[Nico Weber via cfe-commits]

Was this reviewed anywhere?

I'll note that some internal project apparently used to check `#if
__has_attribute(__unsafe_unretained)`. That used to silently (and
incorrectly I think) always return 0 as far as I can tell, but now it fails
with:

```
$ out/gn/bin/clang -c foo.mm
foo.mm:1:21: error: missing ')' after '__attribute__'
#if __has_attribute(__unsafe_unretained)
^~~
:350:42: note: expanded from here
#define __unsafe_unretained __attribute__((objc_ownership(none)))
~^
foo.mm:1:20: note: to match this '('
#if __has_attribute(__unsafe_unretained)
   ^
1 error generated.
```

That's arguably a progression and I'm still finding out what the intent
there was (maybe `#ifdef __unsafe_unretained`?).

So nothing to do here I think, but I thought I'd mention it.

On Sun, Oct 17, 2021 at 7:58 AM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Aaron Ballman
> Date: 2021-10-17T07:54:48-04:00
> New Revision: 2edb89c746848c52964537268bf03e7906bf2542
>
> URL:
> https://github.com/llvm/llvm-project/commit/2edb89c746848c52964537268bf03e7906bf2542
> DIFF:
> https://github.com/llvm/llvm-project/commit/2edb89c746848c52964537268bf03e7906bf2542.diff
>
> LOG: Lex arguments for __has_cpp_attribute and friends as expanded tokens
>
> The C and C++ standards require the argument to __has_cpp_attribute and
> __has_c_attribute to be expanded ([cpp.cond]p5). It would make little sense
> to expand the argument to those operators but not expand the argument to
> __has_attribute and __has_declspec, so those were both also changed in this
> patch.
>
> Note that it might make sense for the other builtins to also expand their
> argument, but it wasn't as clear to me whether the behavior would be
> correct
> there, and so they were left for a future revision.
>
> Added:
> clang/test/Preprocessor/has_attribute_errors.cpp
>
> Modified:
> clang/docs/ReleaseNotes.rst
> clang/lib/Lex/PPMacroExpansion.cpp
> clang/test/Preprocessor/has_attribute.c
> clang/test/Preprocessor/has_attribute.cpp
> clang/test/Preprocessor/has_c_attribute.c
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
> index 6501a4870e2a6..263eae83036df 100644
> --- a/clang/docs/ReleaseNotes.rst
> +++ b/clang/docs/ReleaseNotes.rst
> @@ -110,6 +110,13 @@ Attribute Changes in Clang
>attribute is handled instead, e.g. in ``handleDeclAttribute``.
>(This was changed in order to better support attributes in code
> completion).
>
> +- __has_cpp_attribute, __has_c_attribute, __has_attribute, and
> __has_declspec
> +  will now macro expand their argument. This causes a change in behavior
> for
> +  code using ``__has_cpp_attribute(__clang__::attr)`` (and same for
> +  ``__has_c_attribute``) where it would previously expand to ``0`` for all
> +  attributes, but will now issue an error due to the expansion of the
> +  predefined ``__clang__`` macro.
> +
>  Windows Support
>  ---
>
>
> diff  --git a/clang/lib/Lex/PPMacroExpansion.cpp
> b/clang/lib/Lex/PPMacroExpansion.cpp
> index bf19f538647e6..5a0fa5184e38b 100644
> --- a/clang/lib/Lex/PPMacroExpansion.cpp
> +++ b/clang/lib/Lex/PPMacroExpansion.cpp
> @@ -1293,7 +1293,7 @@ static bool EvaluateHasIncludeNext(Token &Tok,
>  /// integer values.
>  static void EvaluateFeatureLikeBuiltinMacro(llvm::raw_svector_ostream& OS,
>  Token &Tok, IdentifierInfo
> *II,
> -Preprocessor &PP,
> +Preprocessor &PP, bool
> ExpandArgs,
>  llvm::function_ref<
>int(Token &Tok,
>bool &HasLexedNextTok)>
> Op) {
> @@ -1319,7 +1319,10 @@ static void
> EvaluateFeatureLikeBuiltinMacro(llvm::raw_svector_ostream& OS,
>bool SuppressDiagnostic = false;
>while (true) {
>  // Parse next token.
> -PP.LexUnexpandedToken(Tok);
> +if (ExpandArgs)
> +  PP.Lex(Tok);
> +else
> +  PP.LexUnexpandedToken(Tok);
>
>  already_lexed:
>  switch (Tok.getKind()) {
> @@ -1609,21 +1612,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
>  OS << CounterValue++;
>  Tok.setKind(tok::numeric_constant);
>} else if (II == Ident__has_feature) {
> -EvaluateFeatureLikeBuiltinMacro(OS, Tok, II, *this,
> +EvaluateFeatureLikeBuiltinMacro(OS, Tok, II, *this, false,
>[this](Token &Tok, bool &HasLexedNextToken) -> int {
>  IdentifierInfo *II = ExpectFeatureIdentifierInfo(Tok, *this,
>
> diag::err_feature_check_malformed);
>  return II && HasFeature(*this, II->getName());
>});
>} else if (II == Ident__has_extension) {
> -EvaluateFeatureLikeBuiltin

[PATCH] D109632: [clang] de-duplicate methods from AST files

[Richard Howell via Phabricator via cfe-commits]

rmaz abandoned this revision.
rmaz added a comment.

@vsapsai i'll abandon this diff then, thanks for your extensive feedback on the 
approach. Is D110123  shippable already, or 
are there some more corner cases to cover?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109632

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

[PATCH] D110092: [clang][NFC] encapsulate global method list in GlobalMethodPool

[Richard Howell via Phabricator via cfe-commits]

rmaz abandoned this revision.
rmaz added a comment.

Abandoning in favor of D110123 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110092

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

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D112498#3086029 , @aganea wrote:

> This Timer is actually the test coverage for that commit.

Ah, our issue is that it runs in production as well as in the tests. Each time 
the parser sees the crash pragma it dumps a bunch of output to stderr, even if 
the pragma is disabled in PP opts.

> If we don’t want it here, I guess you could move it to the Support unit tests?

Makes sense. Do I understand right that we want to a crash recovery context, a 
timer region within it, and then `abort()` within that?
And we're just verifying we can do that a couple of times without crashing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112498

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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void updated this revision to Diff 382155.
void added a comment.

Count sub/super registers as "uses" in terminating instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/zero-call-used-regs.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/zero_call_used_regs.c
  llvm/include/llvm/Support/CodeGen.h
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86RegisterInfo.h
  llvm/test/CodeGen/X86/zero-call-used-regs-all-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-fmod.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-skip.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-smoke-tests.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used.ll

Index: llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = 

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

This Timer is actually the test coverage for that commit. If we don’t want it 
here, I guess you could move it to the Support unit tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112498

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

[PATCH] D108696: [Coroutines] [Frontend] Lookup in std namespace first

[Lewis Baker via Phabricator via cfe-commits]

lewissbaker added a comment.

So am I correct in understanding that the main issue with the chicken/egg 
problem for updating both the compiler to use the new stdlib facilities and 
updating the stdlib facilities is that we don't want to issue warnings about 
using `` and telling users to use `` instead 
if there is no `` header.

I wonder if a suitable transition approach here might be to have the compiler 
do:

- try lookup of std::coroutine_handle/coroutine_traits; if found try to 
instantiate the expression (e.g. await-suspend) using the std:: type
- if not found then try lookup of 
std::experimental::coroutine_handle/coroutine_traits; and if found try to 
instantiate the expression using the std::experimental:: type; and if 
successful, then;
  - if std:: type was found but instantiating the expression failed, then issue 
a warning about using deprecated std::experimental:: types
  - otherwise if std:: type was not found, try to find  header and 
if present then issue a warning suggesting using  instead of 


Then you should be able to land the compiler change and it should continue to 
have the same behaviour for existing code using std::experimental:: types with 
the existing stdlib.
It is only once the stdlib changes that land which add the  header 
that users would start seeing the warnings about using  instead of 


Note that there are still some potential breakages for code that could go on 
here, however.

Imagine that some header I included has been updated to use  while 
my current header is still using  so that both are in 
scope.

I might have defined an awaitable type that looks like the following:

  c++
  #include  // which transitively includes 
  #include 
  
  struct my_awaitable {
bool await_ready();
void await_suspend(std::experimental::coroutine_handle<> coro);
void await_resume();
  };

In this case, the compiler would find the `std::coroutine_handle<>` and try to 
instantiate the await-suspend expression with that type, which would fail 
because `await_suspend()` is not callable with a `std::coroutine_handle`.
The compiler would need to fall back to instantiating the expression with 
`std::experimental::coroutine_handle`.

There is also the variation where await_suspend() is a template function that 
deduces the promise-type argument.
e.g.

  c++
  template
  void await_suspend(std::experimental::coroutine_handle coro);

There are also cases where the template parameter to await_suspend() is 
unconstrained.
e.g.

  c++
  struct promise_type {
...
std::experimental::coroutine_handle<> continuation;
  };
  
  struct my_awaitable {
bool await_ready();
template
auto await_suspend(CoroHandle handle) {
  coro.promise().continuation = handle;
  return coro;
}
void await_resume();
  
std::experimental::coroutine_handle coro;
  };

Such a type would successfully deduce the template parameter using 
std::coroutine_handle and so the await-suspend expression would be valid, but 
the instantiation of the await_suspend() body would fail as a 
std::coroutine_handle cannot be assigned to an lvalue of type 
`std::experimentl::coroutine_handle<>`. This would not produce a 
SFINAE-friendly error that the compiler could retry with std::experimental 
types.

I'm not sure if there's a great way of keeping such code working in a mixed 
`` and `` world.
Maybe the cost of doing so is not worth the benefit?

The only way I can think of making this work is to just make 
`std::experimental::*` an alias for `std::*`.
But that only works for `std::experimental::coroutine_handle`. It doesn't work 
for `std::experimental::coroutine_traits` as you can't add specialisations 
through an alias.


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

https://reviews.llvm.org/D108696

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

[PATCH] D112498: [Lex] Remove timer from #pragma clang __debug crash handler

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added reviewers: kadircet, aganea.
sammccall requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This seems to be temporary code for testing 
28ad9fc20823678881baa0d723834b88ea9e8e3a 

which was never removed


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112498

Files:
  clang/lib/Lex/Pragma.cpp


Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -45,7 +45,6 @@
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/ErrorHandling.h"
-#include "llvm/Support/Timer.h"
 #include 
 #include 
 #include 
@@ -1108,8 +1107,6 @@
   if (!PP.getPreprocessorOpts().DisablePragmaDebugCrash)
 llvm_unreachable("This is an assertion!");
 } else if (II->isStr("crash")) {
-  llvm::Timer T("crash", "pragma crash");
-  llvm::TimeRegion R(&T);
   if (!PP.getPreprocessorOpts().DisablePragmaDebugCrash)
 LLVM_BUILTIN_TRAP;
 } else if (II->isStr("parser_crash")) {


Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -45,7 +45,6 @@
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/ErrorHandling.h"
-#include "llvm/Support/Timer.h"
 #include 
 #include 
 #include 
@@ -1108,8 +1107,6 @@
   if (!PP.getPreprocessorOpts().DisablePragmaDebugCrash)
 llvm_unreachable("This is an assertion!");
 } else if (II->isStr("crash")) {
-  llvm::Timer T("crash", "pragma crash");
-  llvm::TimeRegion R(&T);
   if (!PP.getPreprocessorOpts().DisablePragmaDebugCrash)
 LLVM_BUILTIN_TRAP;
 } else if (II->isStr("parser_crash")) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] aa1ac2a - [clangd] Flush stderr after signal handlers run, so we always get the full stack/crash info

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2021-10-26T01:08:36+02:00
New Revision: aa1ac2ae451e54dfa19dce2794800bbd034e2194

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

LOG: [clangd] Flush stderr after signal handlers run, so we always get the full 
stack/crash info

Added: 


Modified: 
clang-tools-extra/clangd/tool/ClangdMain.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/tool/ClangdMain.cpp 
b/clang-tools-extra/clangd/tool/ClangdMain.cpp
index 2e48bfb433f0c..4f8895b5d605c 100644
--- a/clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ b/clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -681,7 +681,12 @@ int main(int argc, char *argv[]) {
   llvm::InitializeAllTargetInfos();
   llvm::sys::PrintStackTraceOnErrorSignal(argv[0]);
   llvm::sys::AddSignalHandler(
-  [](void *) { ThreadCrashReporter::runCrashHandlers(); }, nullptr);
+  [](void *) {
+ThreadCrashReporter::runCrashHandlers();
+// Ensure ThreadCrashReporter and PrintStackTrace output is visible.
+llvm::errs().flush();
+  },
+  nullptr);
   llvm::sys::SetInterruptFunction(&requestShutdown);
   llvm::cl::SetVersionPrinter([](llvm::raw_ostream &OS) {
 OS << versionString() << "\n"



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

[PATCH] D109506: [clangd] Print current request context along with the stack trace

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG045695f85cb8: [clangd] Print current request context along 
with the stack trace (authored by 0x1eaf, committed by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D109506?vs=379124&id=382149#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

Files:
  clang-tools-extra/clangd/JSONTransport.cpp
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/support/CMakeLists.txt
  clang-tools-extra/clangd/support/ThreadCrashReporter.cpp
  clang-tools-extra/clangd/support/ThreadCrashReporter.h
  clang-tools-extra/clangd/test/crash.test
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/ThreadCrashReporterTests.cpp

Index: clang-tools-extra/clangd/unittests/ThreadCrashReporterTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/ThreadCrashReporterTests.cpp
@@ -0,0 +1,78 @@
+///===- ThreadCrashReporterTests.cpp - Thread local signal handling tests -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "support/ThreadCrashReporter.h"
+#include "support/Threading.h"
+#include "llvm/Support/Signals.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace clangd {
+
+namespace {
+
+static void infoSignalHandler() { ThreadCrashReporter::runCrashHandlers(); }
+
+TEST(ThreadCrashReporterTest, All) {
+#if defined(_WIN32)
+  // Simulate signals on Windows for unit testing purposes.
+  // The `crash.test` lit test checks the end-to-end integration.
+  auto SignalCurrentThread = []() { infoSignalHandler(); };
+#else
+  llvm::sys::SetInfoSignalFunction(&infoSignalHandler);
+  auto SignalCurrentThread = []() { raise(SIGUSR1); };
+#endif
+
+  AsyncTaskRunner Runner;
+  auto SignalAnotherThread = [&]() {
+Runner.runAsync("signal another thread", SignalCurrentThread);
+Runner.wait();
+  };
+
+  bool Called;
+  {
+ThreadCrashReporter ScopedReporter([&Called]() { Called = true; });
+// Check handler gets called when a signal gets delivered to the current
+// thread.
+Called = false;
+SignalCurrentThread();
+EXPECT_TRUE(Called);
+
+// Check handler does not get called when another thread gets signalled.
+Called = false;
+SignalAnotherThread();
+EXPECT_FALSE(Called);
+  }
+  // Check handler does not get called when the reporter object goes out of
+  // scope.
+  Called = false;
+  SignalCurrentThread();
+  EXPECT_FALSE(Called);
+
+  std::string Order = "";
+  {
+ThreadCrashReporter ScopedReporter([&Order] { Order.push_back('a'); });
+{
+  ThreadCrashReporter ScopedReporter([&Order] { Order.push_back('b'); });
+  SignalCurrentThread();
+}
+// Check that handlers are called in LIFO order.
+EXPECT_EQ(Order, "ba");
+
+// Check that current handler is the only one after the nested scope is
+// over.
+SignalCurrentThread();
+EXPECT_EQ(Order, "baa");
+  }
+}
+
+} // namespace
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/CMakeLists.txt
===
--- clang-tools-extra/clangd/unittests/CMakeLists.txt
+++ clang-tools-extra/clangd/unittests/CMakeLists.txt
@@ -88,6 +88,7 @@
   TestIndex.cpp
   TestTU.cpp
   TestWorkspace.cpp
+  ThreadCrashReporterTests.cpp
   TidyProviderTests.cpp
   TypeHierarchyTests.cpp
   URITests.cpp
Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -24,6 +24,7 @@
 #include "refactor/Rename.h"
 #include "support/Path.h"
 #include "support/Shutdown.h"
+#include "support/ThreadCrashReporter.h"
 #include "support/ThreadsafeFS.h"
 #include "support/Trace.h"
 #include "clang/Format/Format.h"
@@ -679,6 +680,8 @@
 
   llvm::InitializeAllTargetInfos();
   llvm::sys::PrintStackTraceOnErrorSignal(argv[0]);
+  llvm::sys::AddSignalHandler(
+  [](void *) { ThreadCrashReporter::runCrashHandlers(); }, nullptr);
   llvm::sys::SetInterruptFunction(&requestShutdown);
   llvm::cl::SetVersionPrinter([](llvm::raw_ostream &OS) {
 OS << versionString() << "\n"
Index: clang-tools-extra/clangd/test/crash.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/crash.test
@@ -0,0 +1,5 @@
+# Overflow the recursive json parser, prevent `yes` error due to broken pipe and `clang

[clang-tools-extra] 045695f - [clangd] Print current request context along with the stack trace

[Sam McCall via cfe-commits]

Author: Emma Blink
Date: 2021-10-26T00:58:09+02:00
New Revision: 045695f85cb8cdf9b8373123749efe1781f337b4

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

LOG: [clangd] Print current request context along with the stack trace

Motivation:

At the moment it is hard to attribute a clangd crash to a specific request out 
of all in-flight requests that might be processed concurrently. So before we 
can act on production clangd crashes, we have to do quite some digging through 
the log tables populated by our in-house VSCode extension or sometimes even 
directly reach out to the affected developer. Having all the details needed to 
reproduce a crash printed alongside its stack trace has a potential to save us 
quite some time, that could better be spent on fixing the actual problems.

Implementation approach:

* introduce `ThreadCrashReporter` class that allows to set a temporary signal 
handler for the current thread
* follow RAII pattern to simplify printing context for crashes occurring within 
a particular scope
* hold `std::function` as a handler to allow capturing context to print
* set local `ThreadCrashReporter` within `JSONTransport::loop()` to print 
request JSON for main thread crashes, and in `ASTWorker::run()` to print the 
file paths, arguments and contents for worker thread crashes

`ThreadCrashReporter` currently allows only one active handler per thread, but 
the approach can be extended to support stacked handlers printing context 
incrementally.

Example output for main thread crashes:

  ```
  ...
  #15 0x7f7ddc819493 __libc_start_main (/lib64/libc.so.6+0x23493)
  #16 0x0249775e _start 
(/home/emmablink/local/llvm-project/build/bin/clangd+0x249775e)
  Signalled while processing message:
  {"jsonrpc": "2.0", "method": "textDocument/didOpen", "params": 
{"textDocument": {"uri": "file:///home/emmablink/test.cpp", "languageId": 
"cpp", "version": 1, "text": "template \nclass Bar {\n  Bar 
*variables_to_modify;\n  foo() {\nfor (auto *c : *variables_to_modify)\n
  delete c;\n  }\n};\n"}}}
  ```

Example output for AST worker crashes:

  ```
  ...
  #41 0x7fb18304c14a start_thread pthread_create.c:0:0
  #42 0x7fb181bfcdc3 clone (/lib64/libc.so.6+0xfcdc3)
  Signalled during AST action:
  Filename: test.cpp
  Directory: /home/emmablink
  Command Line: /usr/bin/clang 
-resource-dir=/data/users/emmablink/llvm-project/build/lib/clang/14.0.0 -- 
/home/emmablink/test.cpp
  Version: 1
  Contents:
  template 
  class Bar {
Bar *variables_to_modify;
foo() {
  for (auto *c : *variables_to_modify)
delete c;
}
  };
  ```

Testing:

The unit test covers the thread-localitity and nesting aspects of 
`ThreadCrashReporter`. There might be way to set up a lit-based integration 
test that would spawn clangd, send a message to it, signal it immediately and 
check the standard output, but this might be prone to raceconditions.

Reviewed By: sammccall

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

Added: 
clang-tools-extra/clangd/support/ThreadCrashReporter.cpp
clang-tools-extra/clangd/support/ThreadCrashReporter.h
clang-tools-extra/clangd/test/crash.test
clang-tools-extra/clangd/unittests/ThreadCrashReporterTests.cpp

Modified: 
clang-tools-extra/clangd/JSONTransport.cpp
clang-tools-extra/clangd/TUScheduler.cpp
clang-tools-extra/clangd/support/CMakeLists.txt
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/JSONTransport.cpp 
b/clang-tools-extra/clangd/JSONTransport.cpp
index 49cd4e0903e3d..fd405c192591b 100644
--- a/clang-tools-extra/clangd/JSONTransport.cpp
+++ b/clang-tools-extra/clangd/JSONTransport.cpp
@@ -10,9 +10,11 @@
 #include "support/Cancellation.h"
 #include "support/Logger.h"
 #include "support/Shutdown.h"
+#include "support/ThreadCrashReporter.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/Errno.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/Threading.h"
 #include 
 
 namespace clang {
@@ -109,6 +111,11 @@ class JSONTransport : public Transport {
 return llvm::errorCodeToError(
 std::error_code(errno, std::system_category()));
   if (readRawMessage(JSON)) {
+ThreadCrashReporter ScopedReporter([&JSON]() {
+  auto &OS = llvm::errs();
+  OS << "Signalled while processing message:\n";
+  OS << JSON << "\n";
+});
 if (auto Doc = llvm::json::parse(JSON)) {
   vlog(Pretty ? "<<< {0:2}\n" : "<<< {0}\n", *Doc);
   if (!handleMessage(std::move(*Doc), Handler))

diff  --git a/clang-tools-extra/clangd/TUScheduler.cpp 
b/clang-tools-extra/clangd/TUScheduler.cpp
index bbcda5bc0dfb9..8d696b

[PATCH] D112271: [clang][Fuchsia] Add additional unit test for availability attr

[Haowei Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG07bed3ae52b0: [clang][Fuchsia] Add additional unit test for 
availability attr (authored by haowei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112271

Files:
  clang/test/Sema/attr-availability-fuchsia.c


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); 
// expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 
11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); 
// expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), 
availability(fuchsia, unavailable)));   
// expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));
  
// expected-warning {{Fuchsia API Level prohibits specifying a minor or 
sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // 
expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor 
version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // 
nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 
16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); // expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 07bed3a - [clang][Fuchsia] Add additional unit test for availability attr

[Haowei Wu via cfe-commits]

Author: Haowei Wu
Date: 2021-10-25T15:40:30-07:00
New Revision: 07bed3ae52b0a94d9de7f12ca5f2a92589c6c4b6

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

LOG: [clang][Fuchsia] Add additional unit test for availability attr

This change adds additional unit tests for availability attribute
support for Fuchsia platform.

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

Added: 


Modified: 
clang/test/Sema/attr-availability-fuchsia.c

Removed: 




diff  --git a/clang/test/Sema/attr-availability-fuchsia.c 
b/clang/test/Sema/attr-availability-fuchsia.c
index 6b273fe2ae5f6..53bea9a7db3a1 100644
--- a/clang/test/Sema/attr-availability-fuchsia.c
+++ b/clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); 
// expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 
11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); 
// expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), 
availability(fuchsia, unavailable)));   
// expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));
  
// expected-warning {{Fuchsia API Level prohibits specifying a minor or 
sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // 
expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor 
version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // 
nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 
16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }



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

[PATCH] D112447: [clangd] IncludeCleaner: Support macros

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:140
+// locations for the found macros.
+void findReferencedMacros(ParsedAST &AST, ReferencedLocations &Result) {
+  auto Tokens =

can you add a trace for this and verify that it's not a signficant amount of 
time on a macro-heavy file (e.g. unittests?)

locateMacroAt wasn't designed to be called in a loop like this, but it seems 
plausible it'll be fine




Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:140
+// locations for the found macros.
+void findReferencedMacros(ParsedAST &AST, ReferencedLocations &Result) {
+  auto Tokens =

sammccall wrote:
> can you add a trace for this and verify that it's not a signficant amount of 
> time on a macro-heavy file (e.g. unittests?)
> 
> locateMacroAt wasn't designed to be called in a loop like this, but it seems 
> plausible it'll be fine
> 
iterating over all the tokens and examining them individually seems like we're 
doing too much work.

ParsedAST.MainFileMacros.Names already knows the names of all macros referenced 
from the main file.
PP.getLocalMacroDirectiveHistory() will give you the last seen definition for a 
given macro name. If we want, we can also get the previous definitions.

This seems like it should be close enough, and wade through many fewer tokens?



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:144
+  for (const syntax::Token &Tok : Tokens) {
+auto Macro = locateMacroAt(Tok, AST.getPreprocessor());
+if (!Macro)

locateMacroAt doesn't check that the token is an identifier before trying to 
fetch its text, maybe do that? either here or there...



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:115
+  },
+  // Misc
   {

#define INNER 42
#define OUTER INNER

int answer = OUTER;

(whatever the behavior is, let's add a test for it)



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:115
+  },
+  // Misc
   {

sammccall wrote:
> #define INNER 42
> #define OUTER INNER
> 
> int answer = OUTER;
> 
> (whatever the behavior is, let's add a test for it)
#define ANSWER 42
#define SQUARE(X) X * X

int sq = SQUARE(ANSWER);


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112447

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

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song updated this revision to Diff 382143.
yonghong-song added a comment.

- fix clang-format warnings


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/attr-btf_type_tag-func.c
  clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
  clang/test/CodeGen/attr-btf_type_tag-var.c
  clang/test/Sema/attr-btf_type_tag.c
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/IR/DIBuilder.cpp
  llvm/test/Bitcode/attr-btf_type_tag.ll
  llvm/test/DebugInfo/attr-btf_type_tag.ll

Index: llvm/test/DebugInfo/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/attr-btf_type_tag.ll
@@ -0,0 +1,62 @@
+; REQUIRES: x86-registered-target
+; RUN: llc -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   #define __tag2 __attribute__((btf_type_tag("tag2")))
+;
+;   int * __tag1 * __tag2 *g;
+; Compilation flag:
+;   clang -target x86_64 -g -S -emit-llvm t.c
+
+@g = dso_local global i32*** null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!13, !14, !15, !16, !17}
+!llvm.ident = !{!18}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 4, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.c", directory: "/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !11)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, annotations: !9)
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{!10}
+!10 = !{!"btf_type_tag", !"tag1"}
+!11 = !{!12}
+!12 = !{!"btf_type_tag", !"tag2"}
+
+; CHECK:  DW_TAG_variable
+; CHECK-NEXT:   DW_AT_name  ("g")
+; CHECK-NEXT:   DW_AT_type  (0x[[T1:[0-9]+]] "int ***")
+
+; CHECK:  0x[[T1]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T2:[0-9]+]] "int **")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag2")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T2]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T3:[0-9]+]] "int *")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag1")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T3]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[#]] "int")
+
+!13 = !{i32 7, !"Dwarf Version", i32 4}
+!14 = !{i32 2, !"Debug Info Version", i32 3}
+!15 = !{i32 1, !"wchar_size", i32 4}
+!16 = !{i32 7, !"uwtable", i32 1}
+!17 = !{i32 7, !"frame-pointer", i32 2}
+!18 = !{!"clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)"}
Index: llvm/test/Bitcode/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/Bitcode/attr-btf_type_tag.ll
@@ -0,0 +1,36 @@
+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+;
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   int __tag1 *g;
+; Compilation flag:
+;   clang -S -g -emit-llvm test.c
+
+@g = dso_local global i32* null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!9, !10, !11, !12, !13}
+!llvm.ident = !{!14}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 2, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 248122328bfefe82608a2e110af3a3ff04279ddf)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "test.c", directory: "/tmp/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !7)
+!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!7 = !{!8}
+!8 = !{!"btf_type_tag", !"tag1"}
+
+; CHECK:   distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, li

[PATCH] D112408: [WIP][RISCV] Add the zve extension according to the v1.0-rc2 spec

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCV.td:182
 
+def FeatureExtZve32x
+: SubtargetFeature<"experimental-zve32x", "HasStdExtZve32x", "true",

frasercrmck wrote:
> Do we need to define distinct `SubtargetFeature`s for each of these 
> extensions or could they be broken down into a single `MaxEEW` feature (32 or 
> 64) in conjunction with the pre-existing F/D features. This seems like it's 
> more complicated than it needs to be.
I don't think it is quite that simple. Couldn't you have a scalar D and have 
zve64f vector?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112408: [WIP][RISCV] Add the zve extension according to the v1.0-rc2 spec

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:184
 Builder.defineMacro("__riscv_v_min_vlen", Twine(MinVLen));
+Builder.defineMacro("__riscv_v_max_eew", Twine(MaxEew));
+Builder.defineMacro("__riscv_v_max_eew_fp", Twine(MaxEewFp));

Would't ELEN be the correct term here? Not EEW.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112408: [WIP][RISCV] Add the zve extension according to the v1.0-rc2 spec

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:141
+  // either v or zve* suppaort v instructions
+  bool hasStdExtV() const { return HasStdExtV || HasStdExtZve32x; }
+  bool hasStdExtZve32x() const { return HasStdExtZve32x; }

frasercrmck wrote:
> Is this correct? I thought we'd keep `hasStdExtV` as being the single-letter 
> V extension, and Zve32x isn't that.
I just put up D112496 to stop using hasStdExtV everywhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[PATCH] D112296: [Analyzer][solver] Handle adjustments in constraint assignor remainder

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1623
 if (!Constraint.containsZero()) {
-  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  State = RCM.assumeSymRel(State, LHS, BO_NE, Zero);
   if (!State)

martong wrote:
> martong wrote:
> > ASDenysPetrov wrote:
> > > martong wrote:
> > > > ASDenysPetrov wrote:
> > > > > What I see, you're still trying to avoid using `State->assume`, which 
> > > > > I recommend in a parent revision, but coming closer using its guts.
> > > > So, it would look like this:
> > > > ```
> > > > State = 
> > > > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > > > true);
> > > > ```
> > > > The main  reason why we cannot use `State->assume` is that it boils 
> > > > down to `RangedConstraintManager::assumeSym` that has a specific logic 
> > > > for the `boolean` assumption. I.e. the operator is being negated in a 
> > > > case:
> > > > ```
> > > > if (BinaryOperator::isComparisonOp(op) && op != BO_Cmp) {
> > > >   if (!Assumption)
> > > > op = BinaryOperator::negateComparisonOp(op);
> > > > 
> > > >   return assumeSymRel(State, SIE->getLHS(), op, SIE->getRHS());
> > > > }
> > > > ```
> > > > You can try it for yourself, and see that the test case added in this 
> > > > patch will not pass if we were to use `State->assume`. Essentially, we 
> > > > have to evade the special "bool" logic, and the closest we can get is 
> > > > using `assumeSymRel`.
> > > > 
> > > > Besides that, by using `State->assume` we would have a superfluous 
> > > > conversion chain `Symbol->SVal->Symbol` until we reach `assumeSymRel`. 
> > > >You can try it for yourself, and see that the test case added in this 
> > > >patch will not pass if we were to use `State->assume.`
> > > I can't confirm. Your test case passed when I replaced with `State = 
> > > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > > true);`.
> > > > specific logic for the boolean assumption. I.e. the operator is being 
> > > > negated in a case:
> > > That just simplifies the expression, say, you want to find whether `x > 5 
> > > is false`, than the Solver finds for you whether 
> > > `x <= 5 is true`, which is an equivalent.
> > > > Essentially, we have to evade the special "bool" logic
> > > There is no problem with //bool// logic. It's an equivalent of `SVal != 
> > > 0` when //true//, and `SVal == 0` when //false//. Nothing more.
> > > 
> > > All in all I see the problem to use `assume`. Not because of this 
> > > function itself, but because you do it incorrect by getting an `SVal` 
> > > from `LHS` with `makeSymbolVal`. We should get it with `State->getSVal` 
> > > which needs `LocationContext` as a second parameter. And that's the 
> > > challenge, to pass `LocationContext` here, since 
> > > `RangedConstraintManager` doesn't use it, at least for now.
> > > I can't confirm. Your test case passed when I replaced with `State = 
> > > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > > true);`.
> > 
> > Actually, since the last time I tried with `State->assume` we merged 
> > D110913. If you revert the changes of that patch you'll see that this test 
> > case indeed fails. However, here is a slightly modified case that fails 
> > even on the current llvm/main branch with `State->assume` but passes with 
> > `assumeSymRel`:
> > ```
> > void rem_constant_adj(int x, int y) {
> >   if ((x + y + 1) % 3 == 0) // (x + y + 1) % 3 != 0 -> x + y + 1 != 0 -> x 
> > != -1
> > return;
> >   clang_analyzer_eval(x + y + 1 != 0); // expected-warning{{TRUE}}
> >   clang_analyzer_eval(x + y != -1);// expected-warning{{TRUE}}
> >   (void)(x * y); // keep the constraints alive.
> > }
> > ```
> > 
> > The only change is that we have `x + y` instead of `x`. 
> > 
> > Now, the explanation for the original test case when we have `(x + 1) % 3`: 
> > When we ask the value of `x != -1` then `assumeDual` evaluates the TRUE 
> > case which is feasible and then it tries to evaluate the FALSE case, so it 
> > queries `x == -1` is true. However, this kicks in the simplification, which 
> > simplifies the previous constraint of `x+1, [not 0]` to `-1 + 1, [not 0]` 
> > which is a contradiction, thus an infeasible state is returned.
> > When we have `x + y` in the test case, then simplification cannot simplify 
> > `x + y + 1`, thus the situation is different.
> > 
> > So, the main problem with `State->assume` is that it does not compute the 
> > adjustment. I.e. when we have `x + 1` as LHS then `assumeSym(LHS)` calls 
> > into `assumeSymUnsupported` and that does not compute the adjustment. The 
> > only functions that compute the adjustment are `assumeSymRel` and 
> > `assumeSymInclusiveRange`.
> BTW, if D103317 was merged, then I'd have to find another test case that 
> fails here, but I think I could find one. Anyway, the point is that we need a 
> function here, that handles the adjustments.
> So, 

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

In D110869#3034616 , @nickdesaulniers 
wrote:

> We'll probably need to investigate code gen a little.
>
> A mainline linux kernel defconfig built with `CONFIG_ZERO_CALL_USED_REGS=y` 
> enabled doesn't boot, for example.  I consider that a blocker before landing 
> this (much-appreciated) feature; marking it as such.  (Though it's possible 
> that there are TUs in the kernel that may need to be built with 
> `-fzero-call-used-regs=skip` that aren't (yet) failing with GCC).  I don't 
> observe the kernel getting to `start_kernel`, which is the arch-agnostic 
> entry point of the boot; so there's likely x86 specific C code invoked before 
> the generic boot code takes over that may not play well with the 
> instrumentation as implemented.

I found a likely issue. In `arch/x86/kernel/e820.c`, the function `cpcompare` 
returns a value, but we generate `xorq %rax, %rax` before returning. So not 
great. The issue is telling which registers are "live out" of the function (or 
exit block) so that we don't accidentally zero them out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D112493: [OpenMP][NFCI] Record the location string as part of the ident_t

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added reviewers: tianshilei1992, jhuber6, JonChesterfield.
Herald added subscribers: ormris, guansong, bollu, hiraditya, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, OpenMP, LLVM.

When we want to inspect ident_t objects from the device on the host we
need to copy the string over. So far we did not know how long the string
was which prevented an efficient way of copying it. Given that we have
two unused fields in the struct we can just store the string size.

NOTE: Tests will be adjusted shortly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112493

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  openmp/libomptarget/DeviceRTL/include/Types.h

Index: openmp/libomptarget/DeviceRTL/include/Types.h
===
--- openmp/libomptarget/DeviceRTL/include/Types.h
+++ openmp/libomptarget/DeviceRTL/include/Types.h
@@ -133,17 +133,19 @@
 
 /// The ident structure that describes a source location. The struct is
 /// identical to the one in the kmp.h file. We maintain the same data structure
-/// for compatibility.
+/// for compatibility but we interpret the fields different.
 struct IdentTy {
-  int32_t reserved_1;  /**<  might be used in Fortran; see above  */
-  int32_t flags;   /**<  also f.flags; KMP_IDENT_xxx flags; KMP_IDENT_KMPC
-identifies this union member  */
-  int32_t reserved_2;  /**<  not really used in Fortran any more; see above */
-  int32_t reserved_3;  /**<  source[4] in Fortran, do not use for C++  */
-  char const *psource; /**<  String describing the source location.
-   The string is composed of semi-colon separated fields
-   which describe the source file, the function and a pair
-   of line numbers that delimit the construct. */
+  int32_t unused0;
+  int32_t Flags;
+  int32_t unused1;
+
+  /// Size of the `SourceLocation` string member.
+  int32_t SourceLocationSize;
+
+  /// String describing the source location. The string is composed of
+  /// semi-colon separated fields which describe the source file, the function
+  /// and a pair of line numbers that delimit the construct.
+  char const *SourceLocation;
 };
 
 using __kmpc_impl_lanemask_t = LaneMaskTy;
Index: llvm/lib/Transforms/IPO/OpenMPOpt.cpp
===
--- llvm/lib/Transforms/IPO/OpenMPOpt.cpp
+++ llvm/lib/Transforms/IPO/OpenMPOpt.cpp
@@ -633,13 +633,15 @@
   KernelInfoState operator^=(const KernelInfoState &KIS) {
 // Do not merge two different _init and _deinit call sites.
 if (KIS.KernelInitCB) {
-  if(KernelInitCB && KernelInitCB != KIS.KernelInitCB)
-llvm_unreachable("Kernel that calls another kernel violates OpenMP-Opt assumptions.");
+  if (KernelInitCB && KernelInitCB != KIS.KernelInitCB)
+llvm_unreachable("Kernel that calls another kernel violates OpenMP-Opt "
+ "assumptions.");
   KernelInitCB = KIS.KernelInitCB;
 }
 if (KIS.KernelDeinitCB) {
-  if(KernelDeinitCB && KernelDeinitCB != KIS.KernelDeinitCB)
-llvm_unreachable("Kernel that calls another kernel violates OpenMP-Opt assumptions.");
+  if (KernelDeinitCB && KernelDeinitCB != KIS.KernelDeinitCB)
+llvm_unreachable("Kernel that calls another kernel violates OpenMP-Opt "
+ "assumptions.");
   KernelDeinitCB = KIS.KernelDeinitCB;
 }
 SPMDCompatibilityTracker ^= KIS.SPMDCompatibilityTracker;
@@ -1588,8 +1590,11 @@
 &F.getEntryBlock(), F.getEntryBlock().begin()));
   // Create a fallback location if non was found.
   // TODO: Use the debug locations of the calls instead.
-  Constant *Loc = OMPInfoCache.OMPBuilder.getOrCreateDefaultSrcLocStr();
-  Ident = OMPInfoCache.OMPBuilder.getOrCreateIdent(Loc);
+
+  uint32_t SrcLocStrSize;
+  Constant *Loc =
+  OMPInfoCache.OMPBuilder.getOrCreateDefaultSrcLocStr(SrcLocStrSize);
+  Ident = OMPInfoCache.OMPBuilder.getOrCreateIdent(Loc, SrcLocStrSize);
 }
 return Ident;
   }
@@ -3189,8 +3194,9 @@
   OpenMPIRBuilder::LocationDescription Loc(
   InsertPointTy(ParentBB, ParentBB->end()), DL);
   OMPInfoCache.OMPBuilder.updateToLocation(Loc);
-  auto *SrcLocStr = OMPInfoCache.OMPBuilder.getOrCreateSrcLocStr(Loc);
-  Value *Ident = OMPInfoCache.OMPBuilder.getOrCreateIdent(SrcLocStr);
+  uint32_t SrcLocStrSize;
+  auto *SrcLocStr = OMPInfoCache.OMPBuilder.getOrCreateSrcLocStr(Loc, SrcLocStrSize);
+  Value *Ident = OMPInfoCache.OMPBuilder.getOrCreateIdent(SrcLocStr, SrcLocStrSize);
   BranchInst::Create(RegionCheckTidBB, Pare

[PATCH] D112296: [Analyzer][solver] Handle adjustments in constraint assignor remainder

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1623
 if (!Constraint.containsZero()) {
-  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  State = RCM.assumeSymRel(State, LHS, BO_NE, Zero);
   if (!State)

martong wrote:
> ASDenysPetrov wrote:
> > martong wrote:
> > > ASDenysPetrov wrote:
> > > > What I see, you're still trying to avoid using `State->assume`, which I 
> > > > recommend in a parent revision, but coming closer using its guts.
> > > So, it would look like this:
> > > ```
> > > State = 
> > > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > > true);
> > > ```
> > > The main  reason why we cannot use `State->assume` is that it boils down 
> > > to `RangedConstraintManager::assumeSym` that has a specific logic for the 
> > > `boolean` assumption. I.e. the operator is being negated in a case:
> > > ```
> > > if (BinaryOperator::isComparisonOp(op) && op != BO_Cmp) {
> > >   if (!Assumption)
> > > op = BinaryOperator::negateComparisonOp(op);
> > > 
> > >   return assumeSymRel(State, SIE->getLHS(), op, SIE->getRHS());
> > > }
> > > ```
> > > You can try it for yourself, and see that the test case added in this 
> > > patch will not pass if we were to use `State->assume`. Essentially, we 
> > > have to evade the special "bool" logic, and the closest we can get is 
> > > using `assumeSymRel`.
> > > 
> > > Besides that, by using `State->assume` we would have a superfluous 
> > > conversion chain `Symbol->SVal->Symbol` until we reach `assumeSymRel`. 
> > >You can try it for yourself, and see that the test case added in this 
> > >patch will not pass if we were to use `State->assume.`
> > I can't confirm. Your test case passed when I replaced with `State = 
> > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > true);`.
> > > specific logic for the boolean assumption. I.e. the operator is being 
> > > negated in a case:
> > That just simplifies the expression, say, you want to find whether `x > 5 
> > is false`, than the Solver finds for you whether 
> > `x <= 5 is true`, which is an equivalent.
> > > Essentially, we have to evade the special "bool" logic
> > There is no problem with //bool// logic. It's an equivalent of `SVal != 0` 
> > when //true//, and `SVal == 0` when //false//. Nothing more.
> > 
> > All in all I see the problem to use `assume`. Not because of this function 
> > itself, but because you do it incorrect by getting an `SVal` from `LHS` 
> > with `makeSymbolVal`. We should get it with `State->getSVal` which needs 
> > `LocationContext` as a second parameter. And that's the challenge, to pass 
> > `LocationContext` here, since `RangedConstraintManager` doesn't use it, at 
> > least for now.
> > I can't confirm. Your test case passed when I replaced with `State = 
> > State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> > true);`.
> 
> Actually, since the last time I tried with `State->assume` we merged D110913. 
> If you revert the changes of that patch you'll see that this test case indeed 
> fails. However, here is a slightly modified case that fails even on the 
> current llvm/main branch with `State->assume` but passes with `assumeSymRel`:
> ```
> void rem_constant_adj(int x, int y) {
>   if ((x + y + 1) % 3 == 0) // (x + y + 1) % 3 != 0 -> x + y + 1 != 0 -> x != 
> -1
> return;
>   clang_analyzer_eval(x + y + 1 != 0); // expected-warning{{TRUE}}
>   clang_analyzer_eval(x + y != -1);// expected-warning{{TRUE}}
>   (void)(x * y); // keep the constraints alive.
> }
> ```
> 
> The only change is that we have `x + y` instead of `x`. 
> 
> Now, the explanation for the original test case when we have `(x + 1) % 3`: 
> When we ask the value of `x != -1` then `assumeDual` evaluates the TRUE case 
> which is feasible and then it tries to evaluate the FALSE case, so it queries 
> `x == -1` is true. However, this kicks in the simplification, which 
> simplifies the previous constraint of `x+1, [not 0]` to `-1 + 1, [not 0]` 
> which is a contradiction, thus an infeasible state is returned.
> When we have `x + y` in the test case, then simplification cannot simplify `x 
> + y + 1`, thus the situation is different.
> 
> So, the main problem with `State->assume` is that it does not compute the 
> adjustment. I.e. when we have `x + 1` as LHS then `assumeSym(LHS)` calls into 
> `assumeSymUnsupported` and that does not compute the adjustment. The only 
> functions that compute the adjustment are `assumeSymRel` and 
> `assumeSymInclusiveRange`.
BTW, if D103317 was merged, then I'd have to find another test case that fails 
here, but I think I could find one. Anyway, the point is that we need a 
function here, that handles the adjustments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112296

___
cfe-commits mailing list
cf

[PATCH] D112403: [clangd] Respect diagnostic suppression during preamble build

[Nathan Ridge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe6a971b1baec: [clangd] Respect diagnostic suppression during 
preamble build (authored by nridge).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112403

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -449,6 +449,21 @@
"use of undeclared identifier 'unknown'")));
 }
 
+TEST(DiagnosticTest, RespectsDiagnosticConfigInHeader) {
+  Annotations Header(R"cpp(
+int x = "42";  // error-ok
+  )cpp");
+  Annotations Main(R"cpp(
+#include "header.hpp"
+  )cpp");
+  auto TU = TestTU::withCode(Main.code());
+  TU.AdditionalFiles["header.hpp"] = std::string(Header.code());
+  Config Cfg;
+  Cfg.Diagnostics.Suppress.insert("init_conversion_failed");
+  WithContextValue WithCfg(Config::Key, std::move(Cfg));
+  EXPECT_THAT(*TU.build().getDiagnostics(), IsEmpty());
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -8,6 +8,7 @@
 
 #include "Preamble.h"
 #include "Compiler.h"
+#include "Config.h"
 #include "Headers.h"
 #include "SourceCode.h"
 #include "support/Logger.h"
@@ -347,20 +348,24 @@
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagnostics, false);
-  PreambleDiagnostics.setLevelAdjuster(
-  [&](DiagnosticsEngine::Level DiagLevel, const clang::Diagnostic &Info) {
-switch (Info.getID()) {
-case diag::warn_no_newline_eof:
-case diag::warn_cxx98_compat_no_newline_eof:
-case diag::ext_no_newline_eof:
-  // If the preamble doesn't span the whole file, drop the no newline 
at
-  // eof warnings.
-  return Bounds.Size != ContentsBuffer->getBufferSize()
- ? DiagnosticsEngine::Level::Ignored
- : DiagLevel;
-}
-return DiagLevel;
-  });
+  const Config &Cfg = Config::current();
+  PreambleDiagnostics.setLevelAdjuster([&](DiagnosticsEngine::Level DiagLevel,
+   const clang::Diagnostic &Info) {
+if (Cfg.Diagnostics.SuppressAll ||
+isBuiltinDiagnosticSuppressed(Info.getID(), Cfg.Diagnostics.Suppress))
+  return DiagnosticsEngine::Ignored;
+switch (Info.getID()) {
+case diag::warn_no_newline_eof:
+case diag::warn_cxx98_compat_no_newline_eof:
+case diag::ext_no_newline_eof:
+  // If the preamble doesn't span the whole file, drop the no newline at
+  // eof warnings.
+  return Bounds.Size != ContentsBuffer->getBufferSize()
+ ? DiagnosticsEngine::Level::Ignored
+ : DiagLevel;
+}
+return DiagLevel;
+  });
 
   // Skip function bodies when building the preamble to speed up building
   // the preamble and make it smaller.


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -449,6 +449,21 @@
"use of undeclared identifier 'unknown'")));
 }
 
+TEST(DiagnosticTest, RespectsDiagnosticConfigInHeader) {
+  Annotations Header(R"cpp(
+int x = "42";  // error-ok
+  )cpp");
+  Annotations Main(R"cpp(
+#include "header.hpp"
+  )cpp");
+  auto TU = TestTU::withCode(Main.code());
+  TU.AdditionalFiles["header.hpp"] = std::string(Header.code());
+  Config Cfg;
+  Cfg.Diagnostics.Suppress.insert("init_conversion_failed");
+  WithContextValue WithCfg(Config::Key, std::move(Cfg));
+  EXPECT_THAT(*TU.build().getDiagnostics(), IsEmpty());
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -8,6 +8,7 @@
 
 #include "Preamble.h"
 #include "Compiler.h"
+#include "Config.h"
 #include "Headers.h"
 #include "SourceCode.h"
 #include "support/Logger.h"
@@ -347,20 +348,24 @@
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagno

[clang-tools-extra] e6a971b - [clangd] Respect diagnostic suppression during preamble build

[Nathan Ridge via cfe-commits]

Author: Nathan Ridge
Date: 2021-10-25T17:39:32-04:00
New Revision: e6a971b1baecbeab612600337c1d2f06e3dea702

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

LOG: [clangd] Respect diagnostic suppression during preamble build

Fixes https://github.com/clangd/clangd/issues/906

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

Added: 


Modified: 
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index b307f99821b1..8b80ee1bc265 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -8,6 +8,7 @@
 
 #include "Preamble.h"
 #include "Compiler.h"
+#include "Config.h"
 #include "Headers.h"
 #include "SourceCode.h"
 #include "support/Logger.h"
@@ -347,20 +348,24 @@ buildPreamble(PathRef FileName, CompilerInvocation CI,
   llvm::IntrusiveRefCntPtr PreambleDiagsEngine =
   CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
   &PreambleDiagnostics, false);
-  PreambleDiagnostics.setLevelAdjuster(
-  [&](DiagnosticsEngine::Level DiagLevel, const clang::Diagnostic &Info) {
-switch (Info.getID()) {
-case diag::warn_no_newline_eof:
-case diag::warn_cxx98_compat_no_newline_eof:
-case diag::ext_no_newline_eof:
-  // If the preamble doesn't span the whole file, drop the no newline 
at
-  // eof warnings.
-  return Bounds.Size != ContentsBuffer->getBufferSize()
- ? DiagnosticsEngine::Level::Ignored
- : DiagLevel;
-}
-return DiagLevel;
-  });
+  const Config &Cfg = Config::current();
+  PreambleDiagnostics.setLevelAdjuster([&](DiagnosticsEngine::Level DiagLevel,
+   const clang::Diagnostic &Info) {
+if (Cfg.Diagnostics.SuppressAll ||
+isBuiltinDiagnosticSuppressed(Info.getID(), Cfg.Diagnostics.Suppress))
+  return DiagnosticsEngine::Ignored;
+switch (Info.getID()) {
+case diag::warn_no_newline_eof:
+case diag::warn_cxx98_compat_no_newline_eof:
+case diag::ext_no_newline_eof:
+  // If the preamble doesn't span the whole file, drop the no newline at
+  // eof warnings.
+  return Bounds.Size != ContentsBuffer->getBufferSize()
+ ? DiagnosticsEngine::Level::Ignored
+ : DiagLevel;
+}
+return DiagLevel;
+  });
 
   // Skip function bodies when building the preamble to speed up building
   // the preamble and make it smaller.

diff  --git a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp 
b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
index 45e55585ad5d..1b778e4d0388 100644
--- a/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -449,6 +449,21 @@ TEST(DiagnosticTest, RespectsDiagnosticConfig) {
"use of undeclared identifier 'unknown'")));
 }
 
+TEST(DiagnosticTest, RespectsDiagnosticConfigInHeader) {
+  Annotations Header(R"cpp(
+int x = "42";  // error-ok
+  )cpp");
+  Annotations Main(R"cpp(
+#include "header.hpp"
+  )cpp");
+  auto TU = TestTU::withCode(Main.code());
+  TU.AdditionalFiles["header.hpp"] = std::string(Header.code());
+  Config Cfg;
+  Cfg.Diagnostics.Suppress.insert("init_conversion_failed");
+  WithContextValue WithCfg(Config::Key, std::move(Cfg));
+  EXPECT_THAT(*TU.build().getDiagnostics(), IsEmpty());
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {



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

[PATCH] D112296: [Analyzer][solver] Handle adjustments in constraint assignor remainder

[Gabor Marton via Phabricator via cfe-commits]

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



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1623
 if (!Constraint.containsZero()) {
-  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  State = RCM.assumeSymRel(State, LHS, BO_NE, Zero);
   if (!State)

ASDenysPetrov wrote:
> martong wrote:
> > ASDenysPetrov wrote:
> > > What I see, you're still trying to avoid using `State->assume`, which I 
> > > recommend in a parent revision, but coming closer using its guts.
> > So, it would look like this:
> > ```
> > State = 
> > State->assume(Builder.makeSymbolVal(LHS).castAs(), true);
> > ```
> > The main  reason why we cannot use `State->assume` is that it boils down to 
> > `RangedConstraintManager::assumeSym` that has a specific logic for the 
> > `boolean` assumption. I.e. the operator is being negated in a case:
> > ```
> > if (BinaryOperator::isComparisonOp(op) && op != BO_Cmp) {
> >   if (!Assumption)
> > op = BinaryOperator::negateComparisonOp(op);
> > 
> >   return assumeSymRel(State, SIE->getLHS(), op, SIE->getRHS());
> > }
> > ```
> > You can try it for yourself, and see that the test case added in this patch 
> > will not pass if we were to use `State->assume`. Essentially, we have to 
> > evade the special "bool" logic, and the closest we can get is using 
> > `assumeSymRel`.
> > 
> > Besides that, by using `State->assume` we would have a superfluous 
> > conversion chain `Symbol->SVal->Symbol` until we reach `assumeSymRel`. 
> >You can try it for yourself, and see that the test case added in this patch 
> >will not pass if we were to use `State->assume.`
> I can't confirm. Your test case passed when I replaced with `State = 
> State->assume(Builder.makeSymbolVal(LHS).castAs(), true);`.
> > specific logic for the boolean assumption. I.e. the operator is being 
> > negated in a case:
> That just simplifies the expression, say, you want to find whether `x > 5 is 
> false`, than the Solver finds for you whether 
> `x <= 5 is true`, which is an equivalent.
> > Essentially, we have to evade the special "bool" logic
> There is no problem with //bool// logic. It's an equivalent of `SVal != 0` 
> when //true//, and `SVal == 0` when //false//. Nothing more.
> 
> All in all I see the problem to use `assume`. Not because of this function 
> itself, but because you do it incorrect by getting an `SVal` from `LHS` with 
> `makeSymbolVal`. We should get it with `State->getSVal` which needs 
> `LocationContext` as a second parameter. And that's the challenge, to pass 
> `LocationContext` here, since `RangedConstraintManager` doesn't use it, at 
> least for now.
> I can't confirm. Your test case passed when I replaced with `State = 
> State->assume(Builder.makeSymbolVal(LHS).castAs(), true);`.

Actually, since the last time I tried with `State->assume` we merged D110913. 
If you revert the changes of that patch you'll see that this test case indeed 
fails. However, here is a slightly modified case that fails even on the current 
llvm/main branch with `State->assume` but passes with `assumeSymRel`:
```
void rem_constant_adj(int x, int y) {
  if ((x + y + 1) % 3 == 0) // (x + y + 1) % 3 != 0 -> x + y + 1 != 0 -> x != -1
return;
  clang_analyzer_eval(x + y + 1 != 0); // expected-warning{{TRUE}}
  clang_analyzer_eval(x + y != -1);// expected-warning{{TRUE}}
  (void)(x * y); // keep the constraints alive.
}
```

The only change is that we have `x + y` instead of `x`. 

Now, the explanation for the original test case when we have `(x + 1) % 3`: 
When we ask the value of `x != -1` then `assumeDual` evaluates the TRUE case 
which is feasible and then it tries to evaluate the FALSE case, so it queries 
`x == -1` is true. However, this kicks in the simplification, which simplifies 
the previous constraint of `x+1, [not 0]` to `-1 + 1, [not 0]` which is a 
contradiction, thus an infeasible state is returned.
When we have `x + y` in the test case, then simplification cannot simplify `x + 
y + 1`, thus the situation is different.

So, the main problem with `State->assume` is that it does not compute the 
adjustment. I.e. when we have `x + 1` as LHS then `assumeSym(LHS)` calls into 
`assumeSymUnsupported` and that does not compute the adjustment. The only 
functions that compute the adjustment are `assumeSymRel` and 
`assumeSymInclusiveRange`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112296

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

[PATCH] D112353: [bazel] fixes for windows build

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added inline comments.



Comment at: utils/bazel/llvm-project-overlay/llvm/config.bzl:63
 # MSVC specific
-"stricmp=_stricmp",
-"strdup=_strdup",
+#"stricmp=_stricmp",
+#"strdup=_strdup",

GMNGeoffrey wrote:
> Just commenting these out isn't right. I believe you're likely hitting the 
> same issue fixed in https://reviews.llvm.org/D112399 with macro redefines
Thanks for the link. Yeah, I wasn't sure about this part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112353

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

[PATCH] D112492: [HIP] Do not use kernel handle for MSVC target

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.
yaxunl requested review of this revision.

Currently Visual Studio 2019 has a linker issue which causes linking error
when a template kernel is instantiated in different compilation units.
On the other hand, it is unnecessary to prefix kernel stub for MSVC
target since the host and device compilation uses different mangling
ABI.

This patch let clang not emit kernel handle for MSVC target to work
around the linker issue.


https://reviews.llvm.org/D112492

Files:
  clang/include/clang/AST/GlobalDecl.h
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGenCUDA/kernel-stub-name.cu

Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -2,16 +2,35 @@
 
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s \
 // RUN: -fcuda-include-gpubinary %t -o - -x hip\
-// RUN:   | FileCheck %s
+// RUN:   | FileCheck -check-prefixes=CHECK,GNU %s
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s \
+// RUN: -fcuda-include-gpubinary %t -o - -x hip\
+// RUN:   | FileCheck -check-prefix=GNUNEG %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm %s \
+// RUN: -aux-triple amdgcn-amd-amdhsa -fcuda-include-gpubinary \
+// RUN: %t -o - -x hip\
+// RUN:   | FileCheck -check-prefixes=CHECK,MSVC %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm %s \
+// RUN: -aux-triple amdgcn-amd-amdhsa -fcuda-include-gpubinary \
+// RUN: %t -o - -x hip\
+// RUN:   | FileCheck -check-prefix=MSVCNEG %s
 
 #include "Inputs/cuda.h"
 
-// Kernel handles
+// Check kernel handles are emitted for non-MSVC target but not for MSVC target.
+
+// GNU: @[[HCKERN:ckernel]] = constant void ()* @[[CSTUB:__device_stub__ckernel]], align 8
+// GNU: @[[HNSKERN:_ZN2ns8nskernelEv]] = constant void ()* @[[NSSTUB:_ZN2ns23__device_stub__nskernelEv]], align 8
+// GNU: @[[HTKERN:_Z10kernelfuncIiEvv]] = linkonce_odr constant void ()* @[[TSTUB:_Z25__device_stub__kernelfuncIiEvv]], align 8
+// GNU: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
 
-// CHECK: @[[HCKERN:ckernel]] = constant void ()* @__device_stub__ckernel, align 8
-// CHECK: @[[HNSKERN:_ZN2ns8nskernelEv]] = constant void ()* @_ZN2ns23__device_stub__nskernelEv, align 8
-// CHECK: @[[HTKERN:_Z10kernelfuncIiEvv]] = linkonce_odr constant void ()* @_Z25__device_stub__kernelfuncIiEvv, align 8
-// CHECK: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
+// MSVCNEG-NOT: @ckernel =
+// MSVCNEG-NOT: @{{"\?nskernel@ns@@YAXXZ.*"}} =
+// MSVCNEG-NOT: @{{"\?\?\$kernelfunc@H@@YAXXZ.*"}} =
+// MSVCNEG-NOT: @{{"\?kernel_decl@@YAXXZ.*"}} =
 
 extern "C" __global__ void ckernel() {}
 
@@ -24,10 +43,10 @@
 
 __global__ void kernel_decl();
 
-void (*kernel_ptr)();
-void *void_ptr;
+extern "C" void (*kernel_ptr)();
+extern "C" void *void_ptr;
 
-void launch(void *kern);
+extern "C" void launch(void *kern);
 
 // Device side kernel names
 
@@ -37,21 +56,27 @@
 
 // Non-template kernel stub functions
 
-// CHECK: define{{.*}}@[[CSTUB:__device_stub__ckernel]]
-// CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HCKERN]]
-// CHECK: define{{.*}}@[[NSSTUB:_ZN2ns23__device_stub__nskernelEv]]
-// CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HNSKERN]]
+// GNU: define{{.*}}@[[CSTUB]]
+// GNU: call{{.*}}@hipLaunchByPtr{{.*}}@[[HCKERN]]
+// MSVC: define{{.*}}@[[CSTUB:ckernel]]
+// MSVC: call{{.*}}@hipLaunchByPtr{{.*}}@[[CSTUB]]
 
+// GNU: define{{.*}}@[[NSSTUB]]
+// GNU: call{{.*}}@hipLaunchByPtr{{.*}}@[[HNSKERN]]
+// MSVC: define{{.*}}@[[NSSTUB:"\?nskernel@ns@@YAXXZ"]]
+// MSVC: call{{.*}}@hipLaunchByPtr{{.*}}@[[NSSTUB]]
 
-// Check kernel stub is used for triple chevron
+// Check kernel stub is called for triple chevron.
 
-// CHECK-LABEL: define{{.*}}@_Z4fun1v()
+// CHECK-LABEL: define{{.*}}@fun1()
 // CHECK: call void @[[CSTUB]]()
 // CHECK: call void @[[NSSTUB]]()
-// CHECK: call void @[[TSTUB:_Z25__device_stub__kernelfuncIiEvv]]()
-// CHECK: call void @[[DSTUB:_Z26__device_stub__kernel_declv]]()
+// GNU: call void @[[TSTUB]]()
+// GNU: call void @[[DSTUB:_Z26__device_stub__kernel_declv]]()
+// MSVC: call void @[[TSTUB:"\?\?\$kernelfunc@H@@YAXXZ"]]()
+// MSVC: call void @[[DSTUB:"\?kernel_decl@@YAXXZ"]]()
 
-void fun1(void) {
+extern "C" void fun1(void) {
   ckernel<<<1, 1>>>();
   ns::nskernel<<<1, 1>>>();
   kernelfunc<<<1, 1>>>();
@@ -61,34 +86,45 @@
 // Template kernel stub functions
 
 // CHECK: define{{.*}}@[[TSTUB]]
-// CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HTKERN]]
+// GNU: call{{.*}}@hipLaunchByPtr{{.*}}@[[HTKERN]]
+// MSVC: call{{.*}}@hipLaunchByPtr{{.*}}@[[TSTUB]]
 
 // Check declaration of stub function for external kernel.
 
 // CHECK: declare{{.*}}@[[DSTUB]]
 
 // Check kernel handle is used for passing the kernel as a function pointer
-
-// CHECK-LABEL: define{{.*}}@_Z4fun2v()
-// C

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked 4 inline comments as done.
fhahn added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:16669
+ExprResult Sema::SemaBuiltinElementwiseMath(CallExpr *TheCall,
+ExprResult CallResult) {
+  if (checkArgCount(*this, TheCall, 2))

aaron.ballman wrote:
> fhahn wrote:
> > aaron.ballman wrote:
> > > Do we actually need this parameter?
> > No, it can just return `ExprResult(TheCall)` instead I think!
> Could also return a `bool` and have the caller fiddle with `ExprResult`, too. 
> I don't have strong opinions on which way to go though.
updated to return a bool



Comment at: clang/lib/Sema/SemaChecking.cpp:16673-16678
+  Expr *A = TheCall->getArg(0);
+  Expr *B = TheCall->getArg(1);
+  QualType TyA = A->getType();
+  QualType TyB = B->getType();
+
+  if (TyA != TyB)

aaron.ballman wrote:
> fhahn wrote:
> > aaron.ballman wrote:
> > > fhahn wrote:
> > > > aaron.ballman wrote:
> > > > > Should these arguments undergo usual conversions (array to pointer 
> > > > > decay, integer promotions, etc)?
> > > > I intentionally went with not performing conversions, because it might 
> > > > lead to surprising results. If the arguments have different types, it 
> > > > is not clear to me which type should be chosen to try convert the other 
> > > > one; e.g. if we have __builtin_elementwise_max(float, int)` should the 
> > > > first argument be converted to `int` or the second one to `float`?
> > > > 
> > > > Forcing the types to match without conversion seem to make them less 
> > > > error-prone to use, but I might be missing some general rule to handle 
> > > > type conflicts here?
> > > I'm not certain how these builtins are expected to be used, but if 
> > > they're likely to be used with literals, I think we may want integer 
> > > promotions because of that alone.
> > > 
> > > Btw, given that these only have two arguments, it seems like we could use 
> > > the usual arithmetic conversions to pick a common type the same way as 
> > > happens for binary operators.
> > > 
> > > If you end up not adding any conversions here, we should have a test case 
> > > to cover passing in two array objects (which won't decay to pointers).
> > > I'm not certain how these builtins are expected to be used, but if 
> > > they're likely to be used with literals, I think we may want integer 
> > > promotions because of that alone.
> > 
> > Yes, they should ideally work with literals! I think it should be 
> > relatively straight-forward to add promotion of literals.
> > 
> > > Btw, given that these only have two arguments, it seems like we could use 
> > > the usual arithmetic conversions to pick a common type the same way as 
> > > happens for binary operators.
> > 
> > IIUC this happens in `SemaOverload.cpp`, but I am not sure how builtins 
> > would hook into the infrastructure there. Are there other builtins that are 
> > similarly overloaded by any chance?
> > Yes, they should ideally work with literals! I think it should be 
> > relatively straight-forward to add promotion of literals.
> 
> I was thinking of the literal being an `int` and the variable being a 
> `short`, so the literal isn't what needs promotion in that case. That said, I 
> suppose character literals in C++ would promote from `char` to `int`, so 
> there are some literals that could promote. That'd be a somewhat amusing test 
> case for C and C++ both (`__builtin_elementwise_max('a', 1);`).
> 
> > IUC this happens in SemaOverload.cpp, but I am not sure how builtins would 
> > hook into the infrastructure there. Are there other builtins that are 
> > similarly overloaded by any chance?
> 
> `Sema::SemaBuiltinUnorderedCompare()` uses this, for example:
> ```
>   ExprResult OrigArg0 = TheCall->getArg(0);
>   ExprResult OrigArg1 = TheCall->getArg(1);
> 
>   // Do standard promotions between the two arguments, returning their common
>   // type.
>   QualType Res = UsualArithmeticConversions(
>   OrigArg0, OrigArg1, TheCall->getExprLoc(), ACK_Comparison);
>   if (OrigArg0.isInvalid() || OrigArg1.isInvalid())
> return true;
> ```
> hat'd be a somewhat amusing test case for C and C++ both 
> (__builtin_elementwise_max('a', 1);).

I added ` i1 = __builtin_elementwise_max(1, 'a');` to the codegen tests.

> Sema::SemaBuiltinUnorderedCompare() uses this, for example:

Thanks a lot! I updated to code to use `UsualArithmeticConversions` and added 
the tests you suggested (hope I didn't miss any important ones). Looks like all 
should work as expected now.



Comment at: clang/test/Sema/builtins-elementwise-math.c:42
+  // expected-error@-1 {{argument types do not match, 'float4' (vector of 4 
'float' values) != 'int3' (vector of 3 'int' values)}}
+}

aaron.ballman wrote:
> aaron.ballman wrote:
> > fhahn wrote:
> > > aaron.ballman wrote:
> > > > Additional tests I would like to see:
> > > > ```
> > > > int i;

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 382128.
fhahn marked an inline comment as done.
fhahn added a comment.

Address comments @aaron.ballman, thanks!

The most notable changes are using `UsualArithmeticConversions` for argument 
conversion and checking the canonical types. Also added a bunch of additional 
Sema tests as suggested, and some codegen tests for a couple of conversions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111985

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-elementwise-math.c
  clang/test/Sema/builtins-elementwise-math.c

Index: clang/test/Sema/builtins-elementwise-math.c
===
--- /dev/null
+++ clang/test/Sema/builtins-elementwise-math.c
@@ -0,0 +1,102 @@
+// RUN: %clang_cc1 %s -pedantic -verify -triple=x86_64-apple-darwin9
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef int int3 __attribute__((ext_vector_type(3)));
+
+struct Foo {
+  char *p;
+};
+
+__attribute__((address_space(1))) int int_as_one;
+typedef int bar;
+bar b;
+
+void test_builtin_elementwise_max(int i, short s, double d, float4 v, int3 iv, int *p) {
+  i = __builtin_elementwise_max(p, d);
+  // expected-error@-1 {{argument types do not match, 'int *' != 'double'}}
+
+  struct Foo foo = __builtin_elementwise_max(i, i);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int'}}
+
+  i = __builtin_elementwise_max(i);
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 1}}
+
+  i = __builtin_elementwise_max();
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 0}}
+
+  i = __builtin_elementwise_max(v, iv);
+  // expected-error@-1 {{argument types do not match, 'float4' (vector of 4 'float' values) != 'int3' (vector of 3 'int' values)}}
+
+  s = __builtin_elementwise_max(i, s);
+
+  enum e { one,
+   two };
+  i = __builtin_elementwise_max(one, two);
+
+  enum f { three };
+  enum f x = __builtin_elementwise_max(one, three);
+
+  _ExtInt(32) ext;
+  ext = __builtin_elementwise_max(ext, ext);
+
+  const int ci;
+  i = __builtin_elementwise_max(ci, i);
+  i = __builtin_elementwise_max(i, ci);
+  i = __builtin_elementwise_max(ci, ci);
+
+  i = __builtin_elementwise_max(i, int_as_one); // ok (attributes don't match)?
+  i = __builtin_elementwise_max(i, b);  // ok (sugar doesn't match)?
+
+  int A[10];
+  A = __builtin_elementwise_max(A, A);
+  // expected-error@-1 {{argument type 'int *' is not supported}}
+
+  int(ii);
+  int j;
+  j = __builtin_elementwise_max(i, j);
+}
+
+void test_builtin_elementwise_min(int i, short s, double d, float4 v, int3 iv, int *p) {
+  i = __builtin_elementwise_min(p, d);
+  // expected-error@-1 {{argument types do not match, 'int *' != 'double'}}
+
+  struct Foo foo = __builtin_elementwise_min(i, i);
+  // expected-error@-1 {{initializing 'struct Foo' with an expression of incompatible type 'int'}}
+
+  i = __builtin_elementwise_min(i);
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 1}}
+
+  i = __builtin_elementwise_min();
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 0}}
+
+  i = __builtin_elementwise_min(v, iv);
+  // expected-error@-1 {{argument types do not match, 'float4' (vector of 4 'float' values) != 'int3' (vector of 3 'int' values)}}
+
+  s = __builtin_elementwise_min(i, s);
+
+  enum e { one,
+   two };
+  i = __builtin_elementwise_min(one, two);
+
+  enum f { three };
+  enum f x = __builtin_elementwise_min(one, three);
+
+  _ExtInt(32) ext;
+  ext = __builtin_elementwise_min(ext, ext);
+
+  const int ci;
+  i = __builtin_elementwise_min(ci, i);
+  i = __builtin_elementwise_min(i, ci);
+  i = __builtin_elementwise_min(ci, ci);
+
+  i = __builtin_elementwise_min(i, int_as_one); // ok (attributes don't match)?
+  i = __builtin_elementwise_min(i, b);  // ok (sugar doesn't match)?
+
+  int A[10];
+  A = __builtin_elementwise_min(A, A);
+  // expected-error@-1 {{argument type 'int *' is not supported}}
+
+  int(ii);
+  int j;
+  j = __builtin_elementwise_min(i, j);
+}
Index: clang/test/CodeGen/builtins-elementwise-math.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-elementwise-math.c
@@ -0,0 +1,149 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin %s -emit-llvm -disable-llvm-passes -o - | FileCheck %s
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+typedef short int si8 __attribute__((ext_vector_type(8)));
+typedef unsigned int u4 __attribute__((ext_vector_type(4)));
+
+__attribute__((address_space(1))) int int_as_one;
+typedef int bar;
+bar b;
+
+void test_builtin_e

[PATCH] D112353: [bazel] fixes for windows build

[Geoffrey Martin-Noble via Phabricator via cfe-commits]

GMNGeoffrey added a subscriber: chandlerc.
GMNGeoffrey added a comment.

Thanks for upstreaming your fixes :-) It looks like this has some overlap with 
https://reviews.llvm.org/D112399 and https://reviews.llvm.org/D111930. Let's 
let those land and then see what's still necessary here




Comment at: utils/bazel/llvm-project-overlay/clang/BUILD.bazel:1336
+linkopts = select({
+"@bazel_tools//src/conditions:windows": ["/DEFAULTLIB:version.lib"],
+"//conditions:default": [],

@chandlerc thoughts on this?



Comment at: utils/bazel/llvm-project-overlay/clang/BUILD.bazel:1805
+"@bazel_tools//src/conditions:windows": [],
+"//conditions:default": ["-Wno-uninitialized"],
+}),

I don't understand why we need this at all, actually :-/ Let me investigate



Comment at: 
utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h:78
 /* Define if we have sys/resource.h (rlimits) */
-#define CLANG_HAVE_RLIMITS 1
+/* #undef CLANG_HAVE_RLIMITS */
 

FYI, https://reviews.llvm.org/D112399 is also fixing this



Comment at: utils/bazel/llvm-project-overlay/llvm/config.bzl:63
 # MSVC specific
-"stricmp=_stricmp",
-"strdup=_strdup",
+#"stricmp=_stricmp",
+#"strdup=_strdup",

Just commenting these out isn't right. I believe you're likely hitting the same 
issue fixed in https://reviews.llvm.org/D112399 with macro redefines


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112353

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

[PATCH] D112491: Add `LambdaCapture`-related matchers.

[James King via Phabricator via cfe-commits]

jcking1034 created this revision.
jcking1034 added reviewers: ymandel, aaron.ballman.
jcking1034 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This provides better support for `LambdaCapture`s, and implements several
`LambdaCapture`-related matchers. This does not update how lambdas are
traversed. As a result, something like trying to match `lambdaCapture()` by
itself will not work - it must be used as an inner matcher.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112491

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/ASTMatchers/ASTMatchFinder.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -2237,6 +2237,52 @@
  varDecl(hasName("ss"), hasTypeLoc(elaboratedTypeLoc();
 }
 
+TEST_P(ASTMatchersTest, LambdaCaptureTest) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  lambdaExpr(hasAnyCapture(lambdaCapture();
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_BindsToCaptureReferringToVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(refersToVarDecl(varDecl(hasName("cc"));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [&cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [=](){ return cc; }; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [&](){ return cc; }; }", matcher));
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  EXPECT_TRUE(
+  matches("int main() { auto lambda = [cc = 1] {return cc;}; }", matcher));
+}
+
+TEST_P(ASTMatchersTest,
+   LambdaCaptureTest_DoesNotBindToCaptureReferringToVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(refersToVarDecl(varDecl(hasName("cc"));
+  EXPECT_FALSE(matches("int main() { auto f = [](){ return 5; }; }", matcher));
+  EXPECT_FALSE(matches("int main() { int xx; auto f = [xx](){ return xx; }; }",
+   matcher));
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  EXPECT_FALSE(
+  matches("int main() { auto lambda = [xx = 1] {return xx;}; }", matcher));
+}
+
 TEST(ASTMatchersTestObjC, ObjCMessageExpr) {
   // Don't find ObjCMessageExpr where none are present.
   EXPECT_TRUE(notMatchesObjC("", objcMessageExpr(anything(;
Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -4445,5 +4445,42 @@
   cxxRecordDecl(hasName("Derived"),
 hasDirectBase(hasType(cxxRecordDecl(hasName("Base")));
 }
+
+TEST_P(ASTMatchersTest, RefersToThis) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(hasAnyCapture(lambdaCapture(refersToThis(;
+  EXPECT_TRUE(matches("class C { int cc; int f() { auto l = [this](){ return "
+  "cc; }; return l(); } };",
+  matcher));
+  EXPECT_TRUE(matches("class C { int cc; int f() { auto l = [=](){ return cc; "
+  "}; return l(); } };",
+  matcher));
+  EXPECT_TRUE(matches("class C { int cc; int f() { auto l = [&](){ return cc; "
+  "}; return l(); } };",
+  matcher));
+  EXPECT_FALSE(matches("class C { int cc; int f() { auto l = [cc](){ return "
+   "cc; }; return l(); } };",
+   matcher));
+  EXPECT_FALSE(matches("class C { int this; int f() { auto l = [this](){ "
+   "return this; }; return l(); } };",
+   matcher));
+}
+
+TEST_P(ASTMatchersTest, IsImplicit_LambdaCapture) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(hasAnyCapture(
+  lambdaCapture(isImplicit(), refersToVarDecl(varDecl(hasName("cc"));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [&](){ return cc; }; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [=

[PATCH] D112408: [WIP][RISCV] Add the zve extension according to the v1.0-rc2 spec

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: llvm/test/CodeGen/RISCV/rvv/fixed-vectors-bitcast.ll:158
 ; CHECK-NEXT:vmv.x.s a0, v8
+; CHECK-NEXT:lui a1, 1048560
+; CHECK-NEXT:or a0, a0, a1

frasercrmck wrote:
> What's going on here, do you know?
I believe this is coming from the nan-boxing for f16 in 
RISCVTargetLowering::splitValueIntoRegisterParts. The addition of +f must have 
changed PartVT from i32/i64 to f32. Even though we're using i32 for the return 
due to ABI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408

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

[clang] da47ec3 - Basic: Stop using expectedToOptional() in FileManagerTest, NFC

[Duncan P. N. Exon Smith via cfe-commits]

Author: Duncan P. N. Exon Smith
Date: 2021-10-25T13:44:45-07:00
New Revision: da47ec3ca076477b994a5fdd7b777aed9b8cbdf4

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

LOG: Basic: Stop using expectedToOptional() in FileManagerTest, NFC

Remove a couple of uses of expectedToOptional() in FileManagerTest,
using Expected::moveInto() to extract the value instead instead.

Added: 


Modified: 
clang/unittests/Basic/CMakeLists.txt
clang/unittests/Basic/FileManagerTest.cpp

Removed: 




diff  --git a/clang/unittests/Basic/CMakeLists.txt 
b/clang/unittests/Basic/CMakeLists.txt
index cbb18ca87a80c..e633040eac153 100644
--- a/clang/unittests/Basic/CMakeLists.txt
+++ b/clang/unittests/Basic/CMakeLists.txt
@@ -18,4 +18,5 @@ clang_target_link_libraries(BasicTests
   clangAST
   clangBasic
   clangLex
+  LLVMTestingSupport
   )

diff  --git a/clang/unittests/Basic/FileManagerTest.cpp 
b/clang/unittests/Basic/FileManagerTest.cpp
index b40ba01121f8f..a122747efdc11 100644
--- a/clang/unittests/Basic/FileManagerTest.cpp
+++ b/clang/unittests/Basic/FileManagerTest.cpp
@@ -12,6 +12,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include "llvm/Testing/Support/Error.h"
 #include "gtest/gtest.h"
 
 using namespace llvm;
@@ -559,9 +560,10 @@ TEST_F(FileManagerTest, getBypassFile) {
 
   // Calling a second time should not affect the UID or size.
   unsigned VirtualUID = FE.getUID();
-  EXPECT_EQ(
-  &FE,
-  &expectedToOptional(Manager.getFileRef("/tmp/test"))->getFileEntry());
+  llvm::Optional SearchRef;
+  ASSERT_THAT_ERROR(Manager.getFileRef("/tmp/test").moveInto(SearchRef),
+Succeeded());
+  EXPECT_EQ(&FE, &SearchRef->getFileEntry());
   EXPECT_EQ(FE.getUID(), VirtualUID);
   EXPECT_EQ(FE.getSize(), 10);
 
@@ -578,9 +580,9 @@ TEST_F(FileManagerTest, getBypassFile) {
   EXPECT_NE(BypassRef->getSize(), FE.getSize());
 
   // The virtual file should still be returned when searching.
-  EXPECT_EQ(
-  &FE,
-  &expectedToOptional(Manager.getFileRef("/tmp/test"))->getFileEntry());
+  ASSERT_THAT_ERROR(Manager.getFileRef("/tmp/test").moveInto(SearchRef),
+Succeeded());
+  EXPECT_EQ(&FE, &SearchRef->getFileEntry());
 }
 
 } // anonymous namespace



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

[PATCH] D112399: Get Bazel building `//clang` on Windows with clang-cl.

[Geoffrey Martin-Noble via Phabricator via cfe-commits]

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



Comment at: 
utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h:78
 /* Define if we have sys/resource.h (rlimits) */
-#define CLANG_HAVE_RLIMITS 1
+/* CLANG_HAVE_RLIMITS defined in Bazel */
 

Hmm I think we probably should have a change-detector for this config as well 
as the LLVM ones



Comment at: utils/bazel/llvm-project-overlay/llvm/cc_plugin_library.bzl:33
+for impl_name in [dll_name, dylib_name, so_name]:
+cc_binary(
+name = impl_name,

What about this makes `binary_alias` no longer work?


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

https://reviews.llvm.org/D112399

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

[PATCH] D112481: [Sema] fix nondeterminism in ASTContext::getDeducedTemplateSpecializationType

[Igor Sugak via Phabricator via cfe-commits]

sugak updated this revision to Diff 382109.
sugak added a comment.

apply clang-format suggestion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112481

Files:
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -5636,14 +5636,17 @@
   // Look in the folding set for an existing type.
   void *InsertPos = nullptr;
   llvm::FoldingSetNodeID ID;
-  DeducedTemplateSpecializationType::Profile(ID, Template, DeducedType,
- IsDependent);
+  DeducedTemplateSpecializationType::Profile(
+  ID, Template, DeducedType, IsDependent || Template.isDependent());
   if (DeducedTemplateSpecializationType *DTST =
   DeducedTemplateSpecializationTypes.FindNodeOrInsertPos(ID, 
InsertPos))
 return QualType(DTST, 0);
 
   auto *DTST = new (*this, TypeAlignment)
   DeducedTemplateSpecializationType(Template, DeducedType, IsDependent);
+  llvm::FoldingSetNodeID TempID;
+  DTST->Profile(TempID);
+  assert(ID == TempID && "ID does not match");
   Types.push_back(DTST);
   if (InsertPos)
 DeducedTemplateSpecializationTypes.InsertNode(DTST, InsertPos);


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -5636,14 +5636,17 @@
   // Look in the folding set for an existing type.
   void *InsertPos = nullptr;
   llvm::FoldingSetNodeID ID;
-  DeducedTemplateSpecializationType::Profile(ID, Template, DeducedType,
- IsDependent);
+  DeducedTemplateSpecializationType::Profile(
+  ID, Template, DeducedType, IsDependent || Template.isDependent());
   if (DeducedTemplateSpecializationType *DTST =
   DeducedTemplateSpecializationTypes.FindNodeOrInsertPos(ID, InsertPos))
 return QualType(DTST, 0);
 
   auto *DTST = new (*this, TypeAlignment)
   DeducedTemplateSpecializationType(Template, DeducedType, IsDependent);
+  llvm::FoldingSetNodeID TempID;
+  DTST->Profile(TempID);
+  assert(ID == TempID && "ID does not match");
   Types.push_back(DTST);
   if (InsertPos)
 DeducedTemplateSpecializationTypes.InsertNode(DTST, InsertPos);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112209: [clangd] IncludeCleaner: Complicated rules for enum usage

[Kirill Bobyrev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG593814a10cb4: [clangd] IncludeCleaner: Complicated rules for 
enum usage (authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112209

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,30 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color *c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the 
declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,30 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color *c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Aaron Ballman via Phabricator via cfe-commits]

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

Rebased and hopefully fixes the CI pipeline failures. I find it very odd that 
Linux was failing but Windows was not...


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

https://reviews.llvm.org/D112221

Files:
  clang/lib/Headers/stdatomic.h
  clang/test/Headers/stdatomic-deprecations.c


Index: clang/test/Headers/stdatomic-deprecations.c
===
--- /dev/null
+++ clang/test/Headers/stdatomic-deprecations.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c11 %s -verify=okay
+// RUN: %clang_cc1 -fsyntax-only -std=c17 %s -verify
+// RUN: %clang_cc1 -fsyntax-only -std=c++11 -x c++ %s -verify=okay
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -x c++ %s -verify=cxx,expected
+
+// okay-no-diagnostics
+
+#include 
+
+void func(void) {
+  (void)ATOMIC_VAR_INIT(12); // expected-warning {{macro 'ATOMIC_VAR_INIT' has 
been marked as deprecated}} \
+ // expected-note@stdatomic.h:* {{macro marked 
'deprecated' here}}
+  #if defined(ATOMIC_FLAG_INIT) // cxx-warning {{macro 'ATOMIC_FLAG_INIT' has 
been marked as deprecated}} \
+// cxx-note@stdatomic.h:* {{macro marked 
'deprecated' here}}
+  #endif
+}
Index: clang/lib/Headers/stdatomic.h
===
--- clang/lib/Headers/stdatomic.h
+++ clang/lib/Headers/stdatomic.h
@@ -40,6 +40,10 @@
 /* 7.17.2 Initialization */
 
 #define ATOMIC_VAR_INIT(value) (value)
+#if __STDC_VERSION__ >= 201710L || __cplusplus >= 202002L
+/* ATOMIC_VAR_INIT was deprecated in C17 and C++20. */
+#pragma clang deprecated(ATOMIC_VAR_INIT)
+#endif
 #define atomic_init __c11_atomic_init
 
 /* 7.17.3 Order and consistency */
@@ -149,6 +153,10 @@
 typedef struct atomic_flag { atomic_bool _Value; } atomic_flag;
 
 #define ATOMIC_FLAG_INIT { 0 }
+#if __cplusplus >= 202002L
+/* ATOMIC_FLAG_INIT was deprecated in C++20 but is not deprecated in C. */
+#pragma clang deprecated(ATOMIC_FLAG_INIT)
+#endif
 
 /* These should be provided by the libc implementation. */
 #ifdef __cplusplus


Index: clang/test/Headers/stdatomic-deprecations.c
===
--- /dev/null
+++ clang/test/Headers/stdatomic-deprecations.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c11 %s -verify=okay
+// RUN: %clang_cc1 -fsyntax-only -std=c17 %s -verify
+// RUN: %clang_cc1 -fsyntax-only -std=c++11 -x c++ %s -verify=okay
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -x c++ %s -verify=cxx,expected
+
+// okay-no-diagnostics
+
+#include 
+
+void func(void) {
+  (void)ATOMIC_VAR_INIT(12); // expected-warning {{macro 'ATOMIC_VAR_INIT' has been marked as deprecated}} \
+ // expected-note@stdatomic.h:* {{macro marked 'deprecated' here}}
+  #if defined(ATOMIC_FLAG_INIT) // cxx-warning {{macro 'ATOMIC_FLAG_INIT' has been marked as deprecated}} \
+// cxx-note@stdatomic.h:* {{macro marked 'deprecated' here}}
+  #endif
+}
Index: clang/lib/Headers/stdatomic.h
===
--- clang/lib/Headers/stdatomic.h
+++ clang/lib/Headers/stdatomic.h
@@ -40,6 +40,10 @@
 /* 7.17.2 Initialization */
 
 #define ATOMIC_VAR_INIT(value) (value)
+#if __STDC_VERSION__ >= 201710L || __cplusplus >= 202002L
+/* ATOMIC_VAR_INIT was deprecated in C17 and C++20. */
+#pragma clang deprecated(ATOMIC_VAR_INIT)
+#endif
 #define atomic_init __c11_atomic_init
 
 /* 7.17.3 Order and consistency */
@@ -149,6 +153,10 @@
 typedef struct atomic_flag { atomic_bool _Value; } atomic_flag;
 
 #define ATOMIC_FLAG_INIT { 0 }
+#if __cplusplus >= 202002L
+/* ATOMIC_FLAG_INIT was deprecated in C++20 but is not deprecated in C. */
+#pragma clang deprecated(ATOMIC_FLAG_INIT)
+#endif
 
 /* These should be provided by the libc implementation. */
 #ifdef __cplusplus
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song updated this revision to Diff 382088.
yonghong-song added a comment.

- removed AttributedBTFType subclass. Instead of using corresponding *TypeLoc 
to retrieve string argument for btf_type_tag attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/attr-btf_type_tag-func.c
  clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
  clang/test/CodeGen/attr-btf_type_tag-var.c
  clang/test/Sema/attr-btf_type_tag.c
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/IR/DIBuilder.cpp
  llvm/test/Bitcode/attr-btf_type_tag.ll
  llvm/test/DebugInfo/attr-btf_type_tag.ll

Index: llvm/test/DebugInfo/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/attr-btf_type_tag.ll
@@ -0,0 +1,62 @@
+; REQUIRES: x86-registered-target
+; RUN: llc -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   #define __tag2 __attribute__((btf_type_tag("tag2")))
+;
+;   int * __tag1 * __tag2 *g;
+; Compilation flag:
+;   clang -target x86_64 -g -S -emit-llvm t.c
+
+@g = dso_local global i32*** null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!13, !14, !15, !16, !17}
+!llvm.ident = !{!18}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 4, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.c", directory: "/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !11)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, annotations: !9)
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{!10}
+!10 = !{!"btf_type_tag", !"tag1"}
+!11 = !{!12}
+!12 = !{!"btf_type_tag", !"tag2"}
+
+; CHECK:  DW_TAG_variable
+; CHECK-NEXT:   DW_AT_name  ("g")
+; CHECK-NEXT:   DW_AT_type  (0x[[T1:[0-9]+]] "int ***")
+
+; CHECK:  0x[[T1]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T2:[0-9]+]] "int **")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag2")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T2]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T3:[0-9]+]] "int *")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag1")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T3]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[#]] "int")
+
+!13 = !{i32 7, !"Dwarf Version", i32 4}
+!14 = !{i32 2, !"Debug Info Version", i32 3}
+!15 = !{i32 1, !"wchar_size", i32 4}
+!16 = !{i32 7, !"uwtable", i32 1}
+!17 = !{i32 7, !"frame-pointer", i32 2}
+!18 = !{!"clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)"}
Index: llvm/test/Bitcode/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/Bitcode/attr-btf_type_tag.ll
@@ -0,0 +1,36 @@
+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+;
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   int __tag1 *g;
+; Compilation flag:
+;   clang -S -g -emit-llvm test.c
+
+@g = dso_local global i32* null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!9, !10, !11, !12, !13}
+!llvm.ident = !{!14}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 2, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 248122328bfefe82608a2e110af3a3ff04279ddf)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "test.c", directory: "/tmp/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !7)
+!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!7 = !{!8}
+!8 = 

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

aaron.ballman wrote:
> nickdesaulniers wrote:
> > aaron.ballman wrote:
> > > nickdesaulniers wrote:
> > > > aaron.ballman wrote:
> > > > > nickdesaulniers wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > nickdesaulniers wrote:
> > > > > > > > I don't think we want to do all this work if just `Fn`; ie. 
> > > > > > > > create a new `std::string` with `.inline` suffix for every 
> > > > > > > > function we're going to generate code (IR) for.  How about we 
> > > > > > > > add an additional unlikely guard:
> > > > > > > > 
> > > > > > > > `if (FD->getBuiltinID() && FN) {`
> > > > > > > > 
> > > > > > > > Because in the usual case, `FD` both has a builtin ID and is an 
> > > > > > > > inline builtin declaration, while in the exceptional case that 
> > > > > > > > this patch addresses, `FD` has a builtin ID but is not an 
> > > > > > > > inline builtin declaration.
> > > > > > > Is it correct to gate this on whether it's a builtin or not? I 
> > > > > > > thought that builtin-like (e.g., the usual pile of attributes) 
> > > > > > > user code should also have the same effect, shouldn't it?
> > > > > > What do you mean? I'm sorry, I don't quite follow.
> > > > > From the test cases below:
> > > > > ```
> > > > > extern inline __attribute__((always_inline)) 
> > > > > __attribute__((gnu_inline)) unsigned long strlen(const char *p) {
> > > > >   return 1;
> > > > > }
> > > > > unsigned long mystrlen(char const *s) {
> > > > >   return strlen(s);
> > > > > }
> > > > > unsigned long strlen(const char *s) {
> > > > >   return 2;
> > > > > }
> > > > > ```
> > > > > These redeclarations resolve a particular way by GCC and this patch 
> > > > > is intending to match that behavior. My question ultimately boils 
> > > > > down to whether that also happens for this code, where the function 
> > > > > is not a builtin but looks like one due to the attributes:
> > > > > ```
> > > > > extern inline __attribute__((always_inline)) 
> > > > > __attribute__((gnu_inline)) unsigned long wahoo(const char *p) {
> > > > >   return 1;
> > > > > }
> > > > > unsigned long mywahoo(char const *s) {
> > > > >   return wahoo(s);
> > > > > }
> > > > > unsigned long wahoo(const char *s) {
> > > > >   return 2;
> > > > > }
> > > > > ```
> > > > > If this also reorders, then I don't think we can look at whether 
> > > > > `FD->getBuiltinID() != 0` to decide whether to do the reordering 
> > > > > dance because arbitrary user functions aren't Clang builtins and so 
> > > > > they'd not get the correct behavior. Does that make sense?
> > > > > If this also reorders
> > > > 
> > > > It does; https://godbolt.org/z/bbrox7f6e.
> > > > 
> > > > > Does that make sense?
> > > > 
> > > > Yes, thanks for the additional info. In this case, I guess we can 
> > > > disregard my feedback that started this thread, marking it as done?
> > > > 
> > > > Perhaps @serge-sans-paille should add such a non-builtin test case as 
> > > > part of the change?
> > > I think you have a valid concern about the extra allocations, but I'm not 
> > > certain of a better predicate to use. My intuition is that the overhead 
> > > here won't be unacceptable, but it'd be good to know we're not regressing 
> > > compile time performance significantly.
> > > 
> > > Additional test coverage with a comment as to why we're testing it is a 
> > > good idea!
> > Perhaps we can first test whether this FuctionDecl is a redecl, then do the 
> > allocation, then check if the `.inline` suffix?
> > 
> > That way we avoid creating the new string unless we're codgen'ing a redecl, 
> > which should be uncommon in practice.
> That could save us a bit of perf, but I think redecls are actually quite 
> common because a definition is itself a declaration, so having a decl in a 
> header file and defn in a source file will produce a redecl chain.
Ah, ok then.

> Additional test coverage with a comment as to why we're testing it is a good 
> idea!

Yeah, with that and fixes to the other small nits in the test case, then I 
think this is ready to land.


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

https://reviews.llvm.org/D112059

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

[PATCH] D112481: [Sema] fix nondeterminism in ASTContext::getDeducedTemplateSpecializationType

[Igor Sugak via Phabricator via cfe-commits]

sugak created this revision.
sugak added a reviewer: rsmith.
Herald added a subscriber: mgrang.
sugak requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

`DeducedTemplateSpecializationTypes` is a  
`llvm::FoldingSet` [1], where  
`FoldingSetNodeID` is based on the values: `TemplateName`, `QualType`, 
`IsDeducedAsDependent`, those values are also used 
`DeducedTemplateSpecializationType` constructor arguments.

The problem is that `FoldingSetNodeID` created by the static 
`DeducedTemplateSpecializationType::Profile` may not be equal 
to`FoldingSetNodeID` created by a member 
`DeducedTemplateSpecializationType::Profile` of instance created with the same 
`TemplateName`, `QualType`, `IsDeducedAsDependent`, which makes 
`DeducedTemplateSpecializationTypes`.

Specifically, while `IsDeducedAsDependent` value is passes to the constructor, 
`IsDependent()` method on the created instance may return a different value, 
because `IsDependent` is not saved as is:

name=clang/include/clang/AST/Type.h
  DeducedTemplateSpecializationType(TemplateName Template,  QualType 
DeducedAsType, bool IsDeducedAsDependent)
  : DeducedType(DeducedTemplateSpecialization, DeducedAsType,
toTypeDependence(Template.getDependence()) | // <~  also 
considers `TemplateName` parameter
(IsDeducedAsDependent ? 
TypeDependence::DependentInstantiation : TypeDependence::None)),

For example, if an instance A with key `FoldingSetNodeID {A, B, false}` is 
inserted. Then a key `FoldingSetNodeID {A, B, true}` is probed: if it happens 
to correspond to the same bucket in `FoldingSet` as the first key, and 
`A.Profile()` returns  `FoldingSetNodeID {A, B, true}`, then we have a cache 
hit. If the bucket for the second key is different from the first key, it's a 
no hit, even if `A.Profile()` returns  `FoldingSetNodeID {A, B, true}`. Since  
`TemplateName`, `QualType` parameter values involve memory pointers, the query 
result depend on allocator, and may differ from run to run.

When this is used as part of modules compilation, it may result in "module out 
of date" errors, if imported modules are built on different machines.

1. https://llvm.org/docs/ProgrammersManual.html#llvm-adt-foldingset-h


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112481

Files:
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -5491,13 +5491,16 @@
   void *InsertPos = nullptr;
   llvm::FoldingSetNodeID ID;
   DeducedTemplateSpecializationType::Profile(ID, Template, DeducedType,
- IsDependent);
+ IsDependent || 
Template.isDependent());
   if (DeducedTemplateSpecializationType *DTST =
   DeducedTemplateSpecializationTypes.FindNodeOrInsertPos(ID, 
InsertPos))
 return QualType(DTST, 0);
 
   auto *DTST = new (*this, TypeAlignment)
   DeducedTemplateSpecializationType(Template, DeducedType, IsDependent);
+  llvm::FoldingSetNodeID TempID;
+  DTST->Profile(TempID);
+  assert(ID == TempID && "ID does not match");
   Types.push_back(DTST);
   if (InsertPos)
 DeducedTemplateSpecializationTypes.InsertNode(DTST, InsertPos);


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -5491,13 +5491,16 @@
   void *InsertPos = nullptr;
   llvm::FoldingSetNodeID ID;
   DeducedTemplateSpecializationType::Profile(ID, Template, DeducedType,
- IsDependent);
+ IsDependent || Template.isDependent());
   if (DeducedTemplateSpecializationType *DTST =
   DeducedTemplateSpecializationTypes.FindNodeOrInsertPos(ID, InsertPos))
 return QualType(DTST, 0);
 
   auto *DTST = new (*this, TypeAlignment)
   DeducedTemplateSpecializationType(Template, DeducedType, IsDependent);
+  llvm::FoldingSetNodeID TempID;
+  DTST->Profile(TempID);
+  assert(ID == TempID && "ID does not match");
   Types.push_back(DTST);
   if (InsertPos)
 DeducedTemplateSpecializationTypes.InsertNode(DTST, InsertPos);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

nickdesaulniers wrote:
> aaron.ballman wrote:
> > nickdesaulniers wrote:
> > > aaron.ballman wrote:
> > > > nickdesaulniers wrote:
> > > > > aaron.ballman wrote:
> > > > > > nickdesaulniers wrote:
> > > > > > > I don't think we want to do all this work if just `Fn`; ie. 
> > > > > > > create a new `std::string` with `.inline` suffix for every 
> > > > > > > function we're going to generate code (IR) for.  How about we add 
> > > > > > > an additional unlikely guard:
> > > > > > > 
> > > > > > > `if (FD->getBuiltinID() && FN) {`
> > > > > > > 
> > > > > > > Because in the usual case, `FD` both has a builtin ID and is an 
> > > > > > > inline builtin declaration, while in the exceptional case that 
> > > > > > > this patch addresses, `FD` has a builtin ID but is not an inline 
> > > > > > > builtin declaration.
> > > > > > Is it correct to gate this on whether it's a builtin or not? I 
> > > > > > thought that builtin-like (e.g., the usual pile of attributes) user 
> > > > > > code should also have the same effect, shouldn't it?
> > > > > What do you mean? I'm sorry, I don't quite follow.
> > > > From the test cases below:
> > > > ```
> > > > extern inline __attribute__((always_inline)) 
> > > > __attribute__((gnu_inline)) unsigned long strlen(const char *p) {
> > > >   return 1;
> > > > }
> > > > unsigned long mystrlen(char const *s) {
> > > >   return strlen(s);
> > > > }
> > > > unsigned long strlen(const char *s) {
> > > >   return 2;
> > > > }
> > > > ```
> > > > These redeclarations resolve a particular way by GCC and this patch is 
> > > > intending to match that behavior. My question ultimately boils down to 
> > > > whether that also happens for this code, where the function is not a 
> > > > builtin but looks like one due to the attributes:
> > > > ```
> > > > extern inline __attribute__((always_inline)) 
> > > > __attribute__((gnu_inline)) unsigned long wahoo(const char *p) {
> > > >   return 1;
> > > > }
> > > > unsigned long mywahoo(char const *s) {
> > > >   return wahoo(s);
> > > > }
> > > > unsigned long wahoo(const char *s) {
> > > >   return 2;
> > > > }
> > > > ```
> > > > If this also reorders, then I don't think we can look at whether 
> > > > `FD->getBuiltinID() != 0` to decide whether to do the reordering dance 
> > > > because arbitrary user functions aren't Clang builtins and so they'd 
> > > > not get the correct behavior. Does that make sense?
> > > > If this also reorders
> > > 
> > > It does; https://godbolt.org/z/bbrox7f6e.
> > > 
> > > > Does that make sense?
> > > 
> > > Yes, thanks for the additional info. In this case, I guess we can 
> > > disregard my feedback that started this thread, marking it as done?
> > > 
> > > Perhaps @serge-sans-paille should add such a non-builtin test case as 
> > > part of the change?
> > I think you have a valid concern about the extra allocations, but I'm not 
> > certain of a better predicate to use. My intuition is that the overhead 
> > here won't be unacceptable, but it'd be good to know we're not regressing 
> > compile time performance significantly.
> > 
> > Additional test coverage with a comment as to why we're testing it is a 
> > good idea!
> Perhaps we can first test whether this FuctionDecl is a redecl, then do the 
> allocation, then check if the `.inline` suffix?
> 
> That way we avoid creating the new string unless we're codgen'ing a redecl, 
> which should be uncommon in practice.
That could save us a bit of perf, but I think redecls are actually quite common 
because a definition is itself a declaration, so having a decl in a header file 
and defn in a source file will produce a redecl chain.


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

https://reviews.llvm.org/D112059

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

[PATCH] D112101: [AST] Fix the EndLoc calculation for ObjCObjectPointer

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM! Do you need someone to commit on your behalf? If so, let me know what 
name and email address you would like me to use for patch attribution and I can 
land it after giving a day or two for @rsmith to review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112101

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

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

aaron.ballman wrote:
> nickdesaulniers wrote:
> > aaron.ballman wrote:
> > > nickdesaulniers wrote:
> > > > aaron.ballman wrote:
> > > > > nickdesaulniers wrote:
> > > > > > I don't think we want to do all this work if just `Fn`; ie. create 
> > > > > > a new `std::string` with `.inline` suffix for every function we're 
> > > > > > going to generate code (IR) for.  How about we add an additional 
> > > > > > unlikely guard:
> > > > > > 
> > > > > > `if (FD->getBuiltinID() && FN) {`
> > > > > > 
> > > > > > Because in the usual case, `FD` both has a builtin ID and is an 
> > > > > > inline builtin declaration, while in the exceptional case that this 
> > > > > > patch addresses, `FD` has a builtin ID but is not an inline builtin 
> > > > > > declaration.
> > > > > Is it correct to gate this on whether it's a builtin or not? I 
> > > > > thought that builtin-like (e.g., the usual pile of attributes) user 
> > > > > code should also have the same effect, shouldn't it?
> > > > What do you mean? I'm sorry, I don't quite follow.
> > > From the test cases below:
> > > ```
> > > extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> > > unsigned long strlen(const char *p) {
> > >   return 1;
> > > }
> > > unsigned long mystrlen(char const *s) {
> > >   return strlen(s);
> > > }
> > > unsigned long strlen(const char *s) {
> > >   return 2;
> > > }
> > > ```
> > > These redeclarations resolve a particular way by GCC and this patch is 
> > > intending to match that behavior. My question ultimately boils down to 
> > > whether that also happens for this code, where the function is not a 
> > > builtin but looks like one due to the attributes:
> > > ```
> > > extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> > > unsigned long wahoo(const char *p) {
> > >   return 1;
> > > }
> > > unsigned long mywahoo(char const *s) {
> > >   return wahoo(s);
> > > }
> > > unsigned long wahoo(const char *s) {
> > >   return 2;
> > > }
> > > ```
> > > If this also reorders, then I don't think we can look at whether 
> > > `FD->getBuiltinID() != 0` to decide whether to do the reordering dance 
> > > because arbitrary user functions aren't Clang builtins and so they'd not 
> > > get the correct behavior. Does that make sense?
> > > If this also reorders
> > 
> > It does; https://godbolt.org/z/bbrox7f6e.
> > 
> > > Does that make sense?
> > 
> > Yes, thanks for the additional info. In this case, I guess we can disregard 
> > my feedback that started this thread, marking it as done?
> > 
> > Perhaps @serge-sans-paille should add such a non-builtin test case as part 
> > of the change?
> I think you have a valid concern about the extra allocations, but I'm not 
> certain of a better predicate to use. My intuition is that the overhead here 
> won't be unacceptable, but it'd be good to know we're not regressing compile 
> time performance significantly.
> 
> Additional test coverage with a comment as to why we're testing it is a good 
> idea!
Perhaps we can first test whether this FuctionDecl is a redecl, then do the 
allocation, then check if the `.inline` suffix?

That way we avoid creating the new string unless we're codgen'ing a redecl, 
which should be uncommon in practice.


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

https://reviews.llvm.org/D112059

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

[PATCH] D111457: [clang][test] Add lit helper for windows paths

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a subscriber: rnk.
mstorsjo added a comment.

In D111457#3085273 , @keith wrote:

> Yep this makes sense. I would rather not scope that into this if that's ok. 
> Since this test was already invalid and broken (actual fix in 
> https://reviews.llvm.org/D111579) I would rather land these and then take 
> that on to unblock my original use case (https://reviews.llvm.org/D111587) if 
> I can find some more time

Ok, fair enough - I guess that sounds reasonable, so that'd be a +1 from me to 
this patch. Ideally it'd be good to find someone more authoritative around 
clang and these areas than me, but I guess reviewer attention is scarce and 
hard to come by. @rnk - does this seem sensible to you?

Let's give it a little more time for someone else to comment on it, otherwise I 
guess I could approve it...

Then for the future cleanup, one might be able to stop using the native 
substitutions, by keeping one test entirely using possibly-foreign posix style 
forward slashes, and one using the windows style paths (with that test possibly 
limited to only executed when on windows, if necessary - but being able to map 
things to a windows path while cross compiling is good too).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111457

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

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:16673-16678
+  Expr *A = TheCall->getArg(0);
+  Expr *B = TheCall->getArg(1);
+  QualType TyA = A->getType();
+  QualType TyB = B->getType();
+
+  if (TyA != TyB)

fhahn wrote:
> aaron.ballman wrote:
> > fhahn wrote:
> > > aaron.ballman wrote:
> > > > Should these arguments undergo usual conversions (array to pointer 
> > > > decay, integer promotions, etc)?
> > > I intentionally went with not performing conversions, because it might 
> > > lead to surprising results. If the arguments have different types, it is 
> > > not clear to me which type should be chosen to try convert the other one; 
> > > e.g. if we have __builtin_elementwise_max(float, int)` should the first 
> > > argument be converted to `int` or the second one to `float`?
> > > 
> > > Forcing the types to match without conversion seem to make them less 
> > > error-prone to use, but I might be missing some general rule to handle 
> > > type conflicts here?
> > I'm not certain how these builtins are expected to be used, but if they're 
> > likely to be used with literals, I think we may want integer promotions 
> > because of that alone.
> > 
> > Btw, given that these only have two arguments, it seems like we could use 
> > the usual arithmetic conversions to pick a common type the same way as 
> > happens for binary operators.
> > 
> > If you end up not adding any conversions here, we should have a test case 
> > to cover passing in two array objects (which won't decay to pointers).
> > I'm not certain how these builtins are expected to be used, but if they're 
> > likely to be used with literals, I think we may want integer promotions 
> > because of that alone.
> 
> Yes, they should ideally work with literals! I think it should be relatively 
> straight-forward to add promotion of literals.
> 
> > Btw, given that these only have two arguments, it seems like we could use 
> > the usual arithmetic conversions to pick a common type the same way as 
> > happens for binary operators.
> 
> IIUC this happens in `SemaOverload.cpp`, but I am not sure how builtins would 
> hook into the infrastructure there. Are there other builtins that are 
> similarly overloaded by any chance?
> Yes, they should ideally work with literals! I think it should be relatively 
> straight-forward to add promotion of literals.

I was thinking of the literal being an `int` and the variable being a `short`, 
so the literal isn't what needs promotion in that case. That said, I suppose 
character literals in C++ would promote from `char` to `int`, so there are some 
literals that could promote. That'd be a somewhat amusing test case for C and 
C++ both (`__builtin_elementwise_max('a', 1);`).

> IUC this happens in SemaOverload.cpp, but I am not sure how builtins would 
> hook into the infrastructure there. Are there other builtins that are 
> similarly overloaded by any chance?

`Sema::SemaBuiltinUnorderedCompare()` uses this, for example:
```
  ExprResult OrigArg0 = TheCall->getArg(0);
  ExprResult OrigArg1 = TheCall->getArg(1);

  // Do standard promotions between the two arguments, returning their common
  // type.
  QualType Res = UsualArithmeticConversions(
  OrigArg0, OrigArg1, TheCall->getExprLoc(), ACK_Comparison);
  if (OrigArg0.isInvalid() || OrigArg1.isInvalid())
return true;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111985

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

[PATCH] D112334: [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

In D112334#3085119 , @tra wrote:

> Is there a way to annotate the builtin vars in the header to let clang-tidy 
> know explicitly that the code must be handled in a special way? That would 
> avoid the guesswork.

Hmmm, there's 
https://github.com/llvm/llvm-project/commit/e09107ab80dced55414fa458cf78e6cdfe90da6e
 but that's for identifying builtin functions, not builtin types. I don't think 
we have an attribute for identifying builtin type declarations. It might be 
worthwhile for someone to explore whether it would make sense for `BuiltinAttr` 
to be used here or not, but that might be a heavy lift to make this clang-tidy 
check a bit more robust.

Patch LGTM again. :-)


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

https://reviews.llvm.org/D112334

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

[PATCH] D110357: [Analyzer] Extend ConstraintAssignor to handle remainder op

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1618-1627
+const SymbolRef LHS = Sym->getLHS();
+const llvm::APSInt &Zero =
+Builder.getBasicValueFactory().getValue(0, Sym->getType());
+// a % b != 0 implies that a != 0.
+if (!Constraint.containsZero()) {
+  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  if (!State)

martong wrote:
> ASDenysPetrov wrote:
> > martong wrote:
> > > ASDenysPetrov wrote:
> > > > How about using the family of `ProgramState::isNonNull` or 
> > > > `ProgramState::isNull` or `RangeConstraintManager::checkNull` functoins 
> > > > for this stuff?
> > > I've been checking this and turend out that `ProgramState::isNull` does 
> > > not modify the State (this is aligned with being a `const` member 
> > > function). So, these functions do not "assume" anything, they can be used 
> > > only to query some property of an SVal (or Symbol) from the State.
> > > 
> > > However, this comment and your other previous comment made me to do 
> > > further investigations towards exploiting the "assume" machinery better. 
> > > The result is a new child patch, where we can handle "adjustments" as 
> > > well.
> > But I don't see you use the modified `State` in any way. Why it's important 
> > for you to change the `State`?
> > 
> > 
> > But I don't see you use the modified `State` in any way. 
> 
> Actually, we do use it. The `State` we overwrite here is the member of the 
> class `ConstraintAssignor`, it is not a local variable.
> 
> > Why it's important for you to change the `State`?
> 
> It is important, because we'd like to assign new information to the existing 
> things we know (i.e. to the State). So, once we see a modulo then we can 
> defer some extra constraints and that is done via the `ConstraintAssignor`.
OK. I see. Thanks :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110357

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

[PATCH] D112296: [Analyzer][solver] Handle adjustments in constraint assignor remainder

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1623
 if (!Constraint.containsZero()) {
-  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  State = RCM.assumeSymRel(State, LHS, BO_NE, Zero);
   if (!State)

martong wrote:
> ASDenysPetrov wrote:
> > What I see, you're still trying to avoid using `State->assume`, which I 
> > recommend in a parent revision, but coming closer using its guts.
> So, it would look like this:
> ```
> State = State->assume(Builder.makeSymbolVal(LHS).castAs(), 
> true);
> ```
> The main  reason why we cannot use `State->assume` is that it boils down to 
> `RangedConstraintManager::assumeSym` that has a specific logic for the 
> `boolean` assumption. I.e. the operator is being negated in a case:
> ```
> if (BinaryOperator::isComparisonOp(op) && op != BO_Cmp) {
>   if (!Assumption)
> op = BinaryOperator::negateComparisonOp(op);
> 
>   return assumeSymRel(State, SIE->getLHS(), op, SIE->getRHS());
> }
> ```
> You can try it for yourself, and see that the test case added in this patch 
> will not pass if we were to use `State->assume`. Essentially, we have to 
> evade the special "bool" logic, and the closest we can get is using 
> `assumeSymRel`.
> 
> Besides that, by using `State->assume` we would have a superfluous conversion 
> chain `Symbol->SVal->Symbol` until we reach `assumeSymRel`. 
>You can try it for yourself, and see that the test case added in this patch 
>will not pass if we were to use `State->assume.`
I can't confirm. Your test case passed when I replaced with `State = 
State->assume(Builder.makeSymbolVal(LHS).castAs(), true);`.
> specific logic for the boolean assumption. I.e. the operator is being negated 
> in a case:
That just simplifies the expression, say, you want to find whether `x > 5 is 
false`, than the Solver finds for you whether 
`x <= 5 is true`, which is an equivalent.
> Essentially, we have to evade the special "bool" logic
There is no problem with //bool// logic. It's an equivalent of `SVal != 0` when 
//true//, and `SVal == 0` when //false//. Nothing more.

All in all I see the problem to use `assume`. Not because of this function 
itself, but because you do it incorrect by getting an `SVal` from `LHS` with 
`makeSymbolVal`. We should get it with `State->getSVal` which needs 
`LocationContext` as a second parameter. And that's the challenge, to pass 
`LocationContext` here, since `RangedConstraintManager` doesn't use it, at 
least for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112296

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

[PATCH] D109632: [clang] de-duplicate methods from AST files

[Richard Howell via Phabricator via cfe-commits]

rmaz added a comment.

In D109632#3085187 , @dexonsmith 
wrote:

> But another benefit of not double-storing transitively imported methods is 
> that it makes the PCMs more independent, tacking slightly closer to 
> "ImmediateDep1.pcm" being reproducible even when "SharedDep.pcm" adds a 
> method to the global pool. This is a nice property if it's not too expensive. 
> Looking at the numbers above, it doesn't look expensive; the relative 
> performance for @rmaz's motivating use case seems pretty small.
>
> @rmaz, will your goals be achieved by taking @vsapsai's approach? If so, I'm 
> leaning slightly that way.

We can definitely work with it. From my perspective the faster solution would 
be preferred, but if there are potential future benefits from not storing 
dependent modules methods in a pcm them we can ship this solution and look at 
other possible avenues for performance improvement to gain parity with the 
non-modular case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109632

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

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

nickdesaulniers wrote:
> aaron.ballman wrote:
> > nickdesaulniers wrote:
> > > aaron.ballman wrote:
> > > > nickdesaulniers wrote:
> > > > > I don't think we want to do all this work if just `Fn`; ie. create a 
> > > > > new `std::string` with `.inline` suffix for every function we're 
> > > > > going to generate code (IR) for.  How about we add an additional 
> > > > > unlikely guard:
> > > > > 
> > > > > `if (FD->getBuiltinID() && FN) {`
> > > > > 
> > > > > Because in the usual case, `FD` both has a builtin ID and is an 
> > > > > inline builtin declaration, while in the exceptional case that this 
> > > > > patch addresses, `FD` has a builtin ID but is not an inline builtin 
> > > > > declaration.
> > > > Is it correct to gate this on whether it's a builtin or not? I thought 
> > > > that builtin-like (e.g., the usual pile of attributes) user code should 
> > > > also have the same effect, shouldn't it?
> > > What do you mean? I'm sorry, I don't quite follow.
> > From the test cases below:
> > ```
> > extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> > unsigned long strlen(const char *p) {
> >   return 1;
> > }
> > unsigned long mystrlen(char const *s) {
> >   return strlen(s);
> > }
> > unsigned long strlen(const char *s) {
> >   return 2;
> > }
> > ```
> > These redeclarations resolve a particular way by GCC and this patch is 
> > intending to match that behavior. My question ultimately boils down to 
> > whether that also happens for this code, where the function is not a 
> > builtin but looks like one due to the attributes:
> > ```
> > extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> > unsigned long wahoo(const char *p) {
> >   return 1;
> > }
> > unsigned long mywahoo(char const *s) {
> >   return wahoo(s);
> > }
> > unsigned long wahoo(const char *s) {
> >   return 2;
> > }
> > ```
> > If this also reorders, then I don't think we can look at whether 
> > `FD->getBuiltinID() != 0` to decide whether to do the reordering dance 
> > because arbitrary user functions aren't Clang builtins and so they'd not 
> > get the correct behavior. Does that make sense?
> > If this also reorders
> 
> It does; https://godbolt.org/z/bbrox7f6e.
> 
> > Does that make sense?
> 
> Yes, thanks for the additional info. In this case, I guess we can disregard 
> my feedback that started this thread, marking it as done?
> 
> Perhaps @serge-sans-paille should add such a non-builtin test case as part of 
> the change?
I think you have a valid concern about the extra allocations, but I'm not 
certain of a better predicate to use. My intuition is that the overhead here 
won't be unacceptable, but it'd be good to know we're not regressing compile 
time performance significantly.

Additional test coverage with a comment as to why we're testing it is a good 
idea!


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

https://reviews.llvm.org/D112059

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

[PATCH] D112406: [Driver][AArch64]Add driver support for neoverse-512tvb target

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

This one might get a `VScaleForTuning`:
https://reviews.llvm.org/D112459
Do you need this as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112406

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

[PATCH] D74130: [clang] fix consteval call in default arguments

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D74130#3079630 , @Tyker wrote:

> In D74130#3073271 , @aaron.ballman 
> wrote:
>
>> @Tyker -- are you planning to pick this review back up again sometime in the 
>> near future? If not, do you care if the review gets commandeered?
>
> here is an update that i think is close to committable. if it is not i am 
> fine if it gets commandeered.
>
> Changes
>
> - rebased
> - fix the default parameter situation for functions and lambdas.
> - fix the top level variables not being properly checked.
>
> the double errors are not fixed on code like:
>
>   consteval int f1() { return 0; }
>   consteval auto g() { return f1; }
>   
>   constexpr auto e = g();
>   constexpr auto e1 = f1;

Thank you for the update and letting me know you're fine if this is 
commandeered.

FWIW, I am not seeing double errors on that code. Here's the output I get with 
this patch applied locally:

  F:\source\llvm-project>cat "C:\Users\aballman\OneDrive - Intel 
Corporation\Desktop\test.cpp"
  consteval int f1() { return 0; }
  consteval auto g() { return f1; }
  
  constexpr auto e = g();
  constexpr auto e1 = f1;
  
  F:\source\llvm-project>llvm\out\build\x64-Debug\bin\clang.exe -fsyntax-only 
-std=c++2b "C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp"
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:20: error: 
call to consteval function 'g' is not a
constant expression
  constexpr auto e = g();
 ^
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:20: note: 
pointer to a consteval declaration is not a
constant expression
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: 
declared here
  consteval int f1() { return 0; }
^
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:16: error: 
constexpr variable 'e' must be initialized
by a constant expression
  constexpr auto e = g();
 ^   ~~~
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:16: note: 
pointer to a consteval declaration is not a
constant expression
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: 
declared here
  consteval int f1() { return 0; }
^
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:21: error: 
cannot take address of consteval function
'f1' outside of an immediate invocation
  constexpr auto e1 = f1;
  ^
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: 
declared here
  consteval int f1() { return 0; }
^
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:16: error: 
constexpr variable 'e1' must be initialized
by a constant expression
  constexpr auto e1 = f1;
 ^~~
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:16: note: 
pointer to a consteval declaration is not a
constant expression
  C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: 
declared here
  consteval int f1() { return 0; }
^
  4 errors generated.

These look like valid errors to me, so am I misunderstanding something? Is the 
concern that we're emitting `error: constexpr variable '' must be 
initialized by a constant expression` after we already issued a diagnostic on 
the same line?

From my testing, there's more work to be done, but I think it can be done in a 
follow-up. Consider:

  template 
  struct S {
consteval S() = default;
Ty Val;
  };
  
  struct foo {
foo();
  };
  
  S s1; // Correctly rejected
  S s2; // Incorrectly accepted

With this patch applied, `s1` is correctly diagnosed, but `s2` is not. The 
reason it's not is because `Sema::CheckForImmediateInvocation()` tests 
`!Decl->isConsteval()` to early return, and for the instantiation of `S`, 
the constructor is marked as "unspecified" rather than `consteval`. The reason 
for that is because we set `DefaultedDefaultConstructorIsConstexpr` to false at 
https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/DeclCXX.cpp#L1309 
when instantiating the class. I think we may have some confusion where we mean 
"*IsConstexpr" to mean "is a constexpr function" or "is usable as a constexpr 
function", because my reading of https://eel.is/c++draft/dcl.constexpr#7 is 
that the instantiated template constructor IS a constexpr function but it is 
not usable in a constant expression. However, that might be orthogonal to the 
fixes here and should be done separately.




Comment at: clang/lib/Parse/ParseDecl.cpp:2393
 
   InitScope.pop();
 

Is there a reason we're not moving this one to below `AddInititializerToDecl()` 
as we did elsewhere?



Comment at: clang/lib/Sema/SemaDecl.cpp:14510
+auto LSI = getCurLambda();
+//

[PATCH] D111833: [clang] Fortify warning for scanf calls with field width too big.

[Michael Benfield via Phabricator via cfe-commits]

mbenfield updated this revision to Diff 382075.
mbenfield added a comment.

rebase and rerun tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111833

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/warn-fortify-scanf.c

Index: clang/test/Sema/warn-fortify-scanf.c
===
--- /dev/null
+++ clang/test/Sema/warn-fortify-scanf.c
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
+
+typedef struct _FILE FILE;
+extern int scanf(const char *format, ...);
+extern int fscanf(FILE *f, const char *format, ...);
+extern int sscanf(const char *input, const char *format, ...);
+
+void call_scanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  scanf("%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding field width plus NUL byte is 11}}
+  scanf("%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding field width plus NUL byte is 12}}
+  scanf("%4s %5s %9s", buf20, buf30, buf10);
+  scanf("%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding field width plus NUL byte is 21}}
+  scanf("%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding field width plus NUL byte is 22}}
+  scanf("%19s %5s %9s", buf20, buf30, buf10);
+  scanf("%19s %29s %9s", buf20, buf30, buf10);
+}
+
+void call_sscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  sscanf("a b c", "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus NUL byte is 11}}
+  sscanf("a b c", "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus NUL byte is 12}}
+  sscanf("a b c", "%4s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus NUL byte is 21}}
+  sscanf("a b c", "%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus NUL byte is 22}}
+  sscanf("a b c", "%19s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%19s %29s %9s", buf20, buf30, buf10);
+}
+
+void call_fscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  fscanf(0, "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus NUL byte is 11}}
+  fscanf(0, "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus NUL byte is 12}}
+  fscanf(0, "%4s %5s %9s", buf20, buf30, buf10);
+  fscanf(0, "%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus NUL byte is 21}}
+  fscanf(0, "%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus NUL byte is 22}}
+  fscanf(0, "%19s %5s %9s", buf20, buf30, buf10);
+  fscanf(0, "%19s %29s %9s", buf20, buf30, buf10);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -408,6 +408,50 @@
 
 namespace {
 
+class ScanfDiagnosticFormatHandler
+: public analyze_format_string::FormatStringHandler {
+  // Accepts the argument index (relative to the first destination index) of the
+  // argument whose size we want.
+  using ComputeSizeFunction =
+  llvm::function_ref(unsigned)>;
+
+  // Accepts the argument index (relative to the first destination index), the
+  // destination size, and the source size).
+  using DiagnoseFunction =
+  llvm::function_ref;
+
+  ComputeSizeFunction ComputeSizeArgument;
+  DiagnoseFunction Diagnose;
+
+public:
+  ScanfDiagnosticFormatHandler(ComputeSizeFunction ComputeSizeArgument,
+   DiagnoseFunction Diagnose)
+  : ComputeSizeArgument(ComputeSizeArgument), Diagnose(Diagnose) {}
+
+  bool HandleScanfSpecifier(const analyze_scanf::ScanfSpecifier &FS,
+const char *St

[PATCH] D111457: [clang][test] Add lit helper for windows paths

[Keith Smiley via Phabricator via cfe-commits]

keith added a comment.

In D111457#3082398 , @mstorsjo wrote:

> In D111457#3073726 , @keith wrote:
>
>> In D111457#3066508 , @mstorsjo 
>> wrote:
>>
>>> Wouldn't this one also be solved pretty much the same, but differently, by 
>>> changing `if (llvm::sys::path::is_absolute(RemappedFile)) {` into 
>>> `is_absolute_gnu`?
>>
>> I think it //could// but also users could still remap to native window's 
>> paths, so likely we'd want this test as well I think either way?
>
> I guess this might be a good addition as a new test, yeah, but I think it 
> would be good to keep this test as is too, and change the code to use 
> `is_absolute_gnu` (and fix up the test reference here to expect an empty 
> directory in the output).
>
>>> Since we're remapping debug paths, it's plausible that the target path can 
>>> be a different style (when cross compiling, where debug prefix remapping is 
>>> kinda important), and then it's probably good to use a more lax definition 
>>> of whether a path is absolute. (Alternatively, we maybe should try to 
>>> detect the kind of path used and use the appropriate style as argument to 
>>> `is_absolute`, but I don't think that necessarily helps here.)
>>
>> Good point here, I could definitely see wanting to support the entire matrix 
>> of host windows paths vs not, and target windows paths vs not, but I think 
>> that would require significantly more changes for other places that call 
>> `llvm::sys::path::*` APIs and also use the default `native` argument (I'm 
>> not sure how difficult this would be, but it would require a bit of auditing)
>
> I would expect that to mostly work so far, except for corner cases like 
> these. Auditing probably doesn't hurt if one wants to spend the effort, 
> otherwise I'd just expect it to work and try it out and see if one runs into 
> any issues somewhere, if someone has such a usecase.

Yep this makes sense. I would rather not scope that into this if that's ok. 
Since this test was already invalid and broken (actual fix in 
https://reviews.llvm.org/D111579) I would rather land these and then take that 
on to unblock my original use case (https://reviews.llvm.org/D111587) if I can 
find some more time


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111457

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

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

aaron.ballman wrote:
> nickdesaulniers wrote:
> > aaron.ballman wrote:
> > > nickdesaulniers wrote:
> > > > I don't think we want to do all this work if just `Fn`; ie. create a 
> > > > new `std::string` with `.inline` suffix for every function we're going 
> > > > to generate code (IR) for.  How about we add an additional unlikely 
> > > > guard:
> > > > 
> > > > `if (FD->getBuiltinID() && FN) {`
> > > > 
> > > > Because in the usual case, `FD` both has a builtin ID and is an inline 
> > > > builtin declaration, while in the exceptional case that this patch 
> > > > addresses, `FD` has a builtin ID but is not an inline builtin 
> > > > declaration.
> > > Is it correct to gate this on whether it's a builtin or not? I thought 
> > > that builtin-like (e.g., the usual pile of attributes) user code should 
> > > also have the same effect, shouldn't it?
> > What do you mean? I'm sorry, I don't quite follow.
> From the test cases below:
> ```
> extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> unsigned long strlen(const char *p) {
>   return 1;
> }
> unsigned long mystrlen(char const *s) {
>   return strlen(s);
> }
> unsigned long strlen(const char *s) {
>   return 2;
> }
> ```
> These redeclarations resolve a particular way by GCC and this patch is 
> intending to match that behavior. My question ultimately boils down to 
> whether that also happens for this code, where the function is not a builtin 
> but looks like one due to the attributes:
> ```
> extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
> unsigned long wahoo(const char *p) {
>   return 1;
> }
> unsigned long mywahoo(char const *s) {
>   return wahoo(s);
> }
> unsigned long wahoo(const char *s) {
>   return 2;
> }
> ```
> If this also reorders, then I don't think we can look at whether 
> `FD->getBuiltinID() != 0` to decide whether to do the reordering dance 
> because arbitrary user functions aren't Clang builtins and so they'd not get 
> the correct behavior. Does that make sense?
> If this also reorders

It does; https://godbolt.org/z/bbrox7f6e.

> Does that make sense?

Yes, thanks for the additional info. In this case, I guess we can disregard my 
feedback that started this thread, marking it as done?

Perhaps @serge-sans-paille should add such a non-builtin test case as part of 
the change?


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

https://reviews.llvm.org/D112059

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

[PATCH] D109175: [openmp] Emit deferred diag only when device compilation presents

[Wei Wang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb283d55c90dd: [openmp] Emit deferred diag only when device 
compilation presents (authored by weiwang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109175

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/OpenMP/declare_target_messages.cpp
  clang/test/SemaCUDA/openmp-target.cu


Index: clang/test/SemaCUDA/openmp-target.cu
===
--- clang/test/SemaCUDA/openmp-target.cu
+++ clang/test/SemaCUDA/openmp-target.cu
@@ -1,8 +1,8 @@
 // RUN: %clang_cc1 -triple x86_64 -verify=expected,dev \
 // RUN:-verify-ignore-unexpected=note \
-// RUN:-fopenmp -fopenmp-version=50 -o - %s
+// RUN:-fopenmp -fopenmp-version=50 
-fopenmp-targets=amdgcn-amd-amdhsa -o - %s
 // RUN: %clang_cc1 -triple x86_64 -verify -verify-ignore-unexpected=note\
-// RUN:-fopenmp -fopenmp-version=50 -o - -x c++ %s
+// RUN:-fopenmp -fopenmp-version=50 
-fopenmp-targets=amdgcn-amd-amdhsa -o - -x c++ %s
 // RUN: %clang_cc1 -triple x86_64 -verify=dev -verify-ignore-unexpected=note\
 // RUN:-fcuda-is-device -o - %s
 
Index: clang/test/OpenMP/declare_target_messages.cpp
===
--- clang/test/OpenMP/declare_target_messages.cpp
+++ clang/test/OpenMP/declare_target_messages.cpp
@@ -1,11 +1,12 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp45 
-fopenmp -fopenmp-version=45 -fnoopenmp-use-tls -ferror-limit 100 -o - %s
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - 
%s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp -fopenmp-targets=x86_64-apple-macos10.7.0 
-fnoopenmp-use-tls -ferror-limit 100 -o - %s
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp5,dev5 
-fopenmp -fopenmp-is-device -fopenmp-targets=x86_64-apple-macos10.7.0 
-aux-triple x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 -o - 
%s
 
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fopenmp-is-device -fnoopenmp-use-tls 
-ferror-limit 100 -o - %s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd 
-fopenmp-targets=x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fopenmp-is-device 
-fopenmp-targets=x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp45 
-fopenmp-version=45 -fopenmp-simd -fnoopenmp-use-tls -ferror-limit 100 -o - %s
 
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp5 
-fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - %s
 #pragma omp end declare target // expected-error {{unexpected OpenMP directive 
'#pragma omp end declare target'}}
 
 int a, b, z; // omp5-error {{variable captured in declare target region must 
appear in a to clause}}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12609,7 +12609,9 @@
 VDecl->setInitStyle(VarDecl::ListInit);
   }
 
-  if (LangOpts.OpenMP && VDecl->isFileVarDecl())
+  if (LangOpts.OpenMP &&
+  (LangOpts.OpenMPIsDevice || !LangOpts.OMPTargetTriples.empty()) &&
+  VDecl->isFileVarDecl())
 DeclsToCheckForDeferredDiags.insert(VDecl);
   CheckCompleteVariableDeclaration(VDecl);
 }
@@ -14839,7 +14841,9 @@
 DiscardCleanupsInEvaluationContext();
   }
 
-  if (FD && (LangOpts.OpenMP || LangOpts.CUDA || LangOpts.SYCLIsDevice)) {
+  if (FD && ((LangOpts.OpenMP && (LangOpts.OpenMPIsDevice ||
+  !LangOpts.OMPTargetTriples.empty())) ||
+ LangOpts.CUDA || LangOpts.SYCLIsDevice)) {
 auto ES = getEmissionStatus(FD);
 if (ES == Sema::FunctionEmissionStatus::Emitted ||
 ES == Sema::FunctionEmissionStatus::Unknown)


Index: clang/test/SemaCUDA/openmp-target.cu
===
--- clang/test/SemaCUDA/openmp-target.cu
+++ clang/test/SemaCUDA/openmp-target.cu
@@ -1,8 +1,8 @@
 // RUN: %clang_cc1 -triple x86_64 -verify=expected,dev \
 // RUN:-verify-ignore-unexpected=note \
-// RUN:-fopenmp -fopenmp-version=50 -o - %s
+// RUN:-fopenmp -fopenmp-version=50 -fopenmp-targets=amdgcn-amd-amdhsa -o - %s
 // RUN: %clang_cc1 -triple x86_64 -verify -verify-ignore-unexpected=no

[clang] b283d55 - [openmp] Emit deferred diag only when device compilation presents

[Wei Wang via cfe-commits]

Author: Wei Wang
Date: 2021-10-25T11:19:18-07:00
New Revision: b283d55c90dd0b9495c9e91a76c2c62e587eb9b6

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

LOG: [openmp] Emit deferred diag only when device compilation presents

There is no need to check for deferred diag when device compilation or target is
not given. This results in considerable build time improvement in some cases.

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/OpenMP/declare_target_messages.cpp
clang/test/SemaCUDA/openmp-target.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 1491407b0533c..69d2ef631872d 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -12609,7 +12609,9 @@ void Sema::AddInitializerToDecl(Decl *RealDecl, Expr 
*Init, bool DirectInit) {
 VDecl->setInitStyle(VarDecl::ListInit);
   }
 
-  if (LangOpts.OpenMP && VDecl->isFileVarDecl())
+  if (LangOpts.OpenMP &&
+  (LangOpts.OpenMPIsDevice || !LangOpts.OMPTargetTriples.empty()) &&
+  VDecl->isFileVarDecl())
 DeclsToCheckForDeferredDiags.insert(VDecl);
   CheckCompleteVariableDeclaration(VDecl);
 }
@@ -14839,7 +14841,9 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
 DiscardCleanupsInEvaluationContext();
   }
 
-  if (FD && (LangOpts.OpenMP || LangOpts.CUDA || LangOpts.SYCLIsDevice)) {
+  if (FD && ((LangOpts.OpenMP && (LangOpts.OpenMPIsDevice ||
+  !LangOpts.OMPTargetTriples.empty())) ||
+ LangOpts.CUDA || LangOpts.SYCLIsDevice)) {
 auto ES = getEmissionStatus(FD);
 if (ES == Sema::FunctionEmissionStatus::Emitted ||
 ES == Sema::FunctionEmissionStatus::Unknown)

diff  --git a/clang/test/OpenMP/declare_target_messages.cpp 
b/clang/test/OpenMP/declare_target_messages.cpp
index b5ffe7bc698d1..1f608e927421d 100644
--- a/clang/test/OpenMP/declare_target_messages.cpp
+++ b/clang/test/OpenMP/declare_target_messages.cpp
@@ -1,11 +1,12 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp45 
-fopenmp -fopenmp-version=45 -fnoopenmp-use-tls -ferror-limit 100 -o - %s
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - 
%s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp -fopenmp-targets=x86_64-apple-macos10.7.0 
-fnoopenmp-use-tls -ferror-limit 100 -o - %s
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp5,dev5 
-fopenmp -fopenmp-is-device -fopenmp-targets=x86_64-apple-macos10.7.0 
-aux-triple x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 -o - 
%s
 
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
-// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fopenmp-is-device -fnoopenmp-use-tls 
-ferror-limit 100 -o - %s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd 
-fopenmp-targets=x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 
-verify=expected,omp5,host5 -fopenmp-simd -fopenmp-is-device 
-fopenmp-targets=x86_64-apple-macos10.7.0 -fnoopenmp-use-tls -ferror-limit 100 
-o - %s
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp45 
-fopenmp-version=45 -fopenmp-simd -fnoopenmp-use-tls -ferror-limit 100 -o - %s
 
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp5 
-fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - %s
 #pragma omp end declare target // expected-error {{unexpected OpenMP directive 
'#pragma omp end declare target'}}
 
 int a, b, z; // omp5-error {{variable captured in declare target region must 
appear in a to clause}}

diff  --git a/clang/test/SemaCUDA/openmp-target.cu 
b/clang/test/SemaCUDA/openmp-target.cu
index c32aed44fb624..6d22fa27c1952 100644
--- a/clang/test/SemaCUDA/openmp-target.cu
+++ b/clang/test/SemaCUDA/openmp-target.cu
@@ -1,8 +1,8 @@
 // RUN: %clang_cc1 -triple x86_64 -verify=expected,dev \
 // RUN:-verify-ignore-unexpected=note \
-// RUN:-fopenmp -fopenmp-version=50 -o - %s
+// RUN:-fopenmp -fopenmp-version=50 
-fopenmp-targets=amdgcn-amd-amdhsa -o - %s
 // RUN: %clang_cc1 -triple x86_64 -verify -verify-ignore-unexpected=note\
-// RUN:-fopenmp -fopenmp-version=50 -o - -x c++ %s
+// RUN:-fopenmp -fopenmp-version=50 
-fopenmp-targets=amdgcn-amd-amdhsa -o - -x c++ %s
 // RUN: %clang_cc1 -triple x86_64 -verify=dev -verify-ignore-unexpected=note\
 // RUN

[PATCH] D112209: [clangd] IncludeCleaner: Complicated rules for enum usage

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 382065.
kbobyrev added a comment.

Delete duplicate tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112209

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,30 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color *c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the 
declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,30 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color *c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109632: [clang] de-duplicate methods from AST files

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D109632#3081580 , @vsapsai wrote:

> We are targeting the use case where in impl.m we have
>
>   @import ImmediateDep1;
>   @import ImmediateDep2;
>   ...
>   @import ImmediateDepN;
>
> and each of ImmediateDep has `@import SharedDep;`.
>
> For simplicity we'll consider that we are working with a single selector as 
> each of them is processed separately and independently. When clang encounters 
> a selector, it wants to collect methods corresponding to this selector from 
> all modules to a GlobalMethodPool. As in GlobalMethodPool  we store methods 
> in a list, adding a new method requires traversing this list. It is possible 
> to change the list to something else but this change isn't about that, in 
> `O(L*X)` complexity we are reducing `X` (which can be ~10) and not `L` 
> (which is closer to ~1000).
>
> In the baseline METHOD_POOL for each "ImmediateDep" contains methods from 
> "SharedDep". When we add methods to the GlobalMethodPool, we try to add 
> methods from all "ImmediateDep". As the result we iterate through 
> GlobalMethodPool method list multiple time for each method from "SharedDep" 
> as they are available in each "ImmediateDep".
>
> Richard's idea is to put a DenseSet of encountered methods in front of 
> GlobalMethodPool method list. This way duplicates from "SharedDep" can be 
> detected and discarded quickly so we traverse a list only for each unique 
> method and not for duplicates.
>
> My idea is not to store any duplicates in METHOD_POOL. This is achieved by 
> each module storing only their own methods and not storing any [transitively] 
> imported methods. In turn, populating GlobalMethodPool requires traversing 
> the full dependency graph once and loading methods from METHOD_POOL in 
> corresponding modules compared to traversing only immediate dependencies as 
> in the baseline.

Thanks for the explanation; this was helpful.

What's the relative storage cost between the two proposals? I assume small or 
it would have been mentioned.

But another benefit of not double-storing transitively imported methods is that 
it makes the PCMs more independent, tacking slightly closer to 
"ImmediateDep1.pcm" being reproducible even when "SharedDep.pcm" adds a method 
to the global pool. This is a nice property if it's not too expensive. Looking 
at the numbers above, it doesn't look expensive; the relative performance for 
@rmaz's motivating use case seems pretty small.

@rmaz, will your goals be achieved by taking @vsapsai's approach? If so, I'm 
leaning slightly that way.

> I believe MultiOnDiskHashTable isn't really applicable to this performance 
> issue. Even if we use it to store methods, it doesn't affect the amount of 
> methods we process. And right now processing all the duplicates is the 
> expensive part.

Thanks for explaining.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109632

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

[PATCH] D112209: [clangd] IncludeCleaner: Complicated rules for enum usage

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added inline comments.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:38
   bool VisitTagType(TagType *TT) {
+// For enumerations we will require only the definition if it's present and
+// the underlying type is not specified.

sammccall wrote:
> kbobyrev wrote:
> > sammccall wrote:
> > > I don't understand this special case.
> > > It seems you're trying to avoid requiring too many redecls of a 
> > > referenced type. Why is this important, and different from e.g. Class?
> > Yes, this is for cases like
> > 
> > ```
> >   {
> >   "enum class Color;",
> >   "enum class Color {}; Color c;",
> >   },
> > ```
> > 
> > I think the problem here is that if we see the definition of the enum, it 
> > should be the "ground truth" for the usage, forward declarations are not 
> > really useful in this case. It's not much different from the class but I 
> > just wanted to handle it separately, not sure if it's OK to merge these two 
> > changes into one patch.
> The heuristic seems plausible, though there are counterexamples like:
> 
> ```
> "enum Color;"
> "void foo(Color); enum Color {};"
> ```
> 
> My main argument would be that we have a general policy here: conservatively 
> consider all redecls as used, rather than trying to work out which is best. 
> It's not clear why enums are special enough that we should hack around them 
> without rethinking the policy.
> 
> (I think `VisitEnumDecl` is different - our general policy is that decls 
> *aren't* references to forward-decls, and in enums' case this is violates our 
> meta-policy of "be conservative, consider everything that might be a use").
This and our offline discussion makes total sense, I will delete it from the 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112209

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

[PATCH] D112209: [clangd] IncludeCleaner: Complicated rules for enum usage

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 382063.
kbobyrev marked 2 inline comments as done.
kbobyrev added a comment.

Resolve review & offline comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112209

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,34 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color c;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the 
declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -103,6 +103,34 @@
   "struct ^X { enum ^Language { ^CXX = 42, Python = 9000}; };",
   "int Lang = X::CXX;",
   },
+  {
+  "enum class ^Color : int;",
+  "enum class Color : int {};",
+  },
+  {
+  "enum class Color : int {};",
+  "enum class Color : int;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : int;",
+  "Color c;",
+  },
+  {
+  "enum class ^Color : char;",
+  "Color *c;",
+  },
+  {
+  "enum class ^Color : char {};",
+  "Color c;",
+  },
+  {
+  "enum class ^Color;",
+  "Color c;",
+  },
   {
   // When a type is resolved via a using declaration, the
   // UsingShadowDecl is not referenced in the AST.
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -80,6 +80,15 @@
 return true;
   }
 
+  // Enums may be usefully forward-declared as *complete* types by specifying
+  // an underlying type. In this case, the definition should see the declaration
+  // so they can be checked for compatibility.
+  bool VisitEnumDecl(EnumDecl *D) {
+if (D->isThisDeclarationADefinition() && D->getIntegerTypeSourceInfo())
+  add(D);
+return false;
+  }
+
 private:
   using Base = RecursiveASTVisitor;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

nickdesaulniers wrote:
> aaron.ballman wrote:
> > nickdesaulniers wrote:
> > > I don't think we want to do all this work if just `Fn`; ie. create a new 
> > > `std::string` with `.inline` suffix for every function we're going to 
> > > generate code (IR) for.  How about we add an additional unlikely guard:
> > > 
> > > `if (FD->getBuiltinID() && FN) {`
> > > 
> > > Because in the usual case, `FD` both has a builtin ID and is an inline 
> > > builtin declaration, while in the exceptional case that this patch 
> > > addresses, `FD` has a builtin ID but is not an inline builtin declaration.
> > Is it correct to gate this on whether it's a builtin or not? I thought that 
> > builtin-like (e.g., the usual pile of attributes) user code should also 
> > have the same effect, shouldn't it?
> What do you mean? I'm sorry, I don't quite follow.
From the test cases below:
```
extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
unsigned long strlen(const char *p) {
  return 1;
}
unsigned long mystrlen(char const *s) {
  return strlen(s);
}
unsigned long strlen(const char *s) {
  return 2;
}
```
These redeclarations resolve a particular way by GCC and this patch is 
intending to match that behavior. My question ultimately boils down to whether 
that also happens for this code, where the function is not a builtin but looks 
like one due to the attributes:
```
extern inline __attribute__((always_inline)) __attribute__((gnu_inline)) 
unsigned long wahoo(const char *p) {
  return 1;
}
unsigned long mywahoo(char const *s) {
  return wahoo(s);
}
unsigned long wahoo(const char *s) {
  return 2;
}
```
If this also reorders, then I don't think we can look at whether 
`FD->getBuiltinID() != 0` to decide whether to do the reordering dance because 
arbitrary user functions aren't Clang builtins and so they'd not get the 
correct behavior. Does that make sense?



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1319-1321
+// everywhere. That's GCC behavior too. Unfortunately, I cannot find a way
+// to detect that situation before we reach codegen, so do some late
+// replacement.

nickdesaulniers wrote:
> aaron.ballman wrote:
> > nickdesaulniers wrote:
> > > Perhaps in `Sema::CheckFunctionDeclaration`?  I see there is where we 
> > > detect redeclarations. The calls from there to 
> > > `FunctionDecl::setPreviousDeclaration()` seem to set up the redecl chain. 
> > >  Perhaps this exceptional case (or both cases, even) would be handled 
> > > better there?
> > > 
> > > cc @rsmith @aaron.ballman in case they have feedback/tips/cycles.
> > I don't know that it's a good idea to modify the redeclaration chain in 
> > this case. The comments on the chain are pretty clear that it's a temporal 
> > chain where "previous" means previously declared in relation to the current 
> > declaration. @rsmith may feel differently, however.
> Sorry, I don't quite follow whether your approving of the current approach or 
> dismissive?
I don't think we should modify the redecl chain from 
`CheckFunctionDeclaration()` -- this case would create a redeclaration chain 
whose previous link was not temporally the previous declaration. There might be 
another approach so we can avoid `replaceAllUsesWith()`. One possibility (no 
idea how feasible or what explodes) is to modify 
`FunctionDecl::getDefinition()` to look through the chain to return the best 
definition when there are multiple definitions to pick from.


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

https://reviews.llvm.org/D112059

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

[PATCH] D112334: [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Is there a way to annotate the builtin vars in the header to let clang-tidy 
know explicitly that the code must be handled in a special way? That would 
avoid the guesswork.


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

https://reviews.llvm.org/D112334

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

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked 6 inline comments as done.
fhahn added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:16673-16678
+  Expr *A = TheCall->getArg(0);
+  Expr *B = TheCall->getArg(1);
+  QualType TyA = A->getType();
+  QualType TyB = B->getType();
+
+  if (TyA != TyB)

aaron.ballman wrote:
> fhahn wrote:
> > aaron.ballman wrote:
> > > Should these arguments undergo usual conversions (array to pointer decay, 
> > > integer promotions, etc)?
> > I intentionally went with not performing conversions, because it might lead 
> > to surprising results. If the arguments have different types, it is not 
> > clear to me which type should be chosen to try convert the other one; e.g. 
> > if we have __builtin_elementwise_max(float, int)` should the first argument 
> > be converted to `int` or the second one to `float`?
> > 
> > Forcing the types to match without conversion seem to make them less 
> > error-prone to use, but I might be missing some general rule to handle type 
> > conflicts here?
> I'm not certain how these builtins are expected to be used, but if they're 
> likely to be used with literals, I think we may want integer promotions 
> because of that alone.
> 
> Btw, given that these only have two arguments, it seems like we could use the 
> usual arithmetic conversions to pick a common type the same way as happens 
> for binary operators.
> 
> If you end up not adding any conversions here, we should have a test case to 
> cover passing in two array objects (which won't decay to pointers).
> I'm not certain how these builtins are expected to be used, but if they're 
> likely to be used with literals, I think we may want integer promotions 
> because of that alone.

Yes, they should ideally work with literals! I think it should be relatively 
straight-forward to add promotion of literals.

> Btw, given that these only have two arguments, it seems like we could use the 
> usual arithmetic conversions to pick a common type the same way as happens 
> for binary operators.

IIUC this happens in `SemaOverload.cpp`, but I am not sure how builtins would 
hook into the infrastructure there. Are there other builtins that are similarly 
overloaded by any chance?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111985

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

[PATCH] D112284: [Clang][NFC] Clang CUDA codegen: a dyn_cast -> cast instance + clang-tidy fixes

[Artem Belevich via Phabricator via cfe-commits]

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

The description is a bit misleading. The dyn_cast->cast appears to be a minor 
part of this patch.
I'd separate clang-tidy cleanups into a separate patch or would just describe 
all of these changes as a clean-up. dyn_cast->cast is an NFC change here, too, 
considering that we're operating on a type of `FunctionDecl 
*cudaLaunchKernelFD`.




Comment at: clang/lib/CodeGen/CGCUDANV.cpp:240
 llvm::FunctionType::get(IntTy, CharPtrTy, false), "hipLaunchByPtr");
-  } else {
-// cudaError_t cudaLaunch(char *);
-return CGM.CreateRuntimeFunction(
-llvm::FunctionType::get(IntTy, CharPtrTy, false), "cudaLaunch");
   }
+  // cudaError_t cudaLaunch(char *);

Nit: you could remove these `{...}` now, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112284

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

[PATCH] D111047: CUDA/HIP: Allow __int128 on the host side

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

LGTM. This could be useful for other types. 
E.g. `long double` is technically not supported by NVPTX. We current demote it 
to double, so host-side does not cause errors, but ideally it should be treated 
similar to what you propose for i128 here.




Comment at: clang/lib/Sema/Sema.cpp:1858-1859
 void Sema::checkTypeSupport(QualType Ty, SourceLocation Loc, ValueDecl *D) {
-  if (!LangOpts.SYCLIsDevice && !(LangOpts.OpenMP && LangOpts.OpenMPIsDevice))
+  if (!LangOpts.SYCLIsDevice && !(LangOpts.OpenMP && LangOpts.OpenMPIsDevice) 
&&
+  !LangOpts.CUDAIsDevice)
 return;

Nit:I'd rephrase it a bit to make it a bit easier to understand (less 
negations).




Comment at: clang/lib/Sema/SemaType.cpp:1498-1500
 if (!S.Context.getTargetInfo().hasInt128Type() &&
-!S.getLangOpts().SYCLIsDevice &&
+!S.getLangOpts().SYCLIsDevice && !S.getLangOpts().CUDAIsDevice &&
 !(S.getLangOpts().OpenMP && S.getLangOpts().OpenMPIsDevice))

Similarly, here I'd separate the check for i128 support by the target and the 
compilation mode check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111047

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

[PATCH] D112059: Fix inline builtin handling in case of redefinition

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

Bumping for an update here.  We can tolerate a build breakage for our older 
kernels over the weekend, but we should really try to get this resolved by EOW, 
otherwise we need to look into reverting:

- 3d6f49a56995b845c40be5827ded5d1e3f692cec 
 Tue Sep 
28 13:24:25 2021 +0200 (breakage)
- bd379915de38a9af3d65e19075a6a64ebbb8d6db 
 Tue Sep 
28 16:07:33 2021 +0200 (attempted fix forward of 3d6f49a56995b845 
)
- 0d76d4833dd2815e0b1c786250f474d222f6a0a1 
 Tue Sep 
28 11:30:37 2021 -0700 (revert of 3d6f49a56995b845 
)
- c3717b6858d32d64514a187ede1a77be8ba4e542 
 Tue Sep 
28 21:00:47 2021 +0200 (reland, introduced kernel breakage)
- 0f0e31cf511def3e92244e615b2646c1fd0df0cd 
 Mon Oct 4 
22:26:25 2021 +0200 (fix forward)




Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1302
   // in case the function pointer is referenced somewhere.
-  if (FD->isInlineBuiltinDeclaration() && Fn) {
+  if (Fn) {
 std::string FDInlineName = (Fn->getName() + ".inline").str();

aaron.ballman wrote:
> nickdesaulniers wrote:
> > I don't think we want to do all this work if just `Fn`; ie. create a new 
> > `std::string` with `.inline` suffix for every function we're going to 
> > generate code (IR) for.  How about we add an additional unlikely guard:
> > 
> > `if (FD->getBuiltinID() && FN) {`
> > 
> > Because in the usual case, `FD` both has a builtin ID and is an inline 
> > builtin declaration, while in the exceptional case that this patch 
> > addresses, `FD` has a builtin ID but is not an inline builtin declaration.
> Is it correct to gate this on whether it's a builtin or not? I thought that 
> builtin-like (e.g., the usual pile of attributes) user code should also have 
> the same effect, shouldn't it?
What do you mean? I'm sorry, I don't quite follow.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1319-1321
+// everywhere. That's GCC behavior too. Unfortunately, I cannot find a way
+// to detect that situation before we reach codegen, so do some late
+// replacement.

aaron.ballman wrote:
> nickdesaulniers wrote:
> > Perhaps in `Sema::CheckFunctionDeclaration`?  I see there is where we 
> > detect redeclarations. The calls from there to 
> > `FunctionDecl::setPreviousDeclaration()` seem to set up the redecl chain.  
> > Perhaps this exceptional case (or both cases, even) would be handled better 
> > there?
> > 
> > cc @rsmith @aaron.ballman in case they have feedback/tips/cycles.
> I don't know that it's a good idea to modify the redeclaration chain in this 
> case. The comments on the chain are pretty clear that it's a temporal chain 
> where "previous" means previously declared in relation to the current 
> declaration. @rsmith may feel differently, however.
Sorry, I don't quite follow whether your approving of the current approach or 
dismissive?


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

https://reviews.llvm.org/D112059

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

[PATCH] D112409: [clang-tidy] Add check 'cert-err33-c'.

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Also:

- Please add a unit test. You, can probably re-use the corresponding `bugprone` 
test and tell it to add the `cert-err33-c` check as well. If they are too 
different I suppose it's fine to create it's own standalone test?
- Mention this new check in the clang-tidy release notes.




Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:303-304
 CheckFactories.registerCheck("cert-err34-c");
+CheckFactories.registerCheck(
+"cert-err33-c");
 // MSC

Keep alphabetical order (err33 before err34)



Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:328
 Opts["cert-str34-c.DiagnoseSignedUnsignedCharComparisons"] = "false";
+Opts["cert-err33-c.CheckedFunctions"] = CertErr33CCheckedFunctions;
 return Options;

Same here



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst:49
+
+`cert-err33-c` is a version of this check that checks exactly the functions
+listed in CERT_rule ERR33-C.

an alias



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst:50
+`cert-err33-c` is a version of this check that checks exactly the functions
+listed in CERT_rule ERR33-C.

Add link?



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-err33-c.rst:1
+.. title:: clang-tidy - cert-err33-c
+

I believe we usually mention that this is an alias to another check, and then 
redirect the user to that original check.



Comment at: clang-tools-extra/docs/clang-tidy/checks/list.rst:118
+   `cert-err33-c `_,
`cert-err34-c `_,
`cert-err52-cpp `_,

Missing referring to the alias check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112409

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

[PATCH] D112334: [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp updated this revision to Diff 382038.
carlosgalvezp added a comment.

Move CUDA built-in declarations to a separate header, and create a macro to 
define the variables just like it's done in the real version. Back to named 
namespace.


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

https://reviews.llvm.org/D112334

Files:
  
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
  
clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
@@ -1,4 +1,5 @@
-// RUN: %check_clang_tidy %s readability-static-accessed-through-instance %t
+// RUN: %check_clang_tidy %s readability-static-accessed-through-instance %t -- -- -isystem %S/Inputs/readability-static-accessed-through-instance
+#include <__clang_cuda_builtin_vars.h>
 
 struct C {
   static void foo();
@@ -248,3 +249,17 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
   // CHECK-FIXES: {{^}}  Outer::S::I;{{$}}
 }
+
+// https://bugs.llvm.org/show_bug.cgi?id=48758
+namespace Bugzilla_48758 {
+
+unsigned int x1 = threadIdx.x;
+// CHECK-MESSAGES-NOT: :[[@LINE-1]]:10: warning: static member
+unsigned int x2 = blockIdx.x;
+// CHECK-MESSAGES-NOT: :[[@LINE-1]]:10: warning: static member
+unsigned int x3 = blockDim.x;
+// CHECK-MESSAGES-NOT: :[[@LINE-1]]:10: warning: static member
+unsigned int x4 = gridDim.x;
+// CHECK-MESSAGES-NOT: :[[@LINE-1]]:10: warning: static member
+
+} // namespace Bugzilla_48758
Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-static-accessed-through-instance/__clang_cuda_builtin_vars.h
@@ -0,0 +1,36 @@
+//===--- __clang_cuda_builtin_vars.h - Stub header for tests *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef ___CLANG_CUDA_BUILTIN_VARS_H_
+#define ___CLANG_CUDA_BUILTIN_VARS_H_
+
+#define __CUDA_DEVICE_BUILTIN(FIELD) \
+  static unsigned int FIELD;
+
+struct __cuda_builtin_threadIdx_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_blockIdx_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_blockDim_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+struct __cuda_builtin_gridDim_t {
+  __CUDA_DEVICE_BUILTIN(x);
+};
+
+__cuda_builtin_threadIdx_t threadIdx;
+__cuda_builtin_blockIdx_t blockIdx;
+__cuda_builtin_blockDim_t blockDim;
+__cuda_builtin_gridDim_t gridDim;
+
+#endif // ___CLANG_CUDA_BUILTIN_VARS_H_
Index: clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -9,6 +9,7 @@
 #include "StaticAccessedThroughInstanceCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "llvm/ADT/StringRef.h"
 
 using namespace clang::ast_matchers;
 
@@ -54,7 +55,7 @@
 
   const Expr *BaseExpr = MemberExpression->getBase();
 
-  // Do not warn for overlaoded -> operators.
+  // Do not warn for overloaded -> operators.
   if (isa(BaseExpr))
 return;
 
@@ -70,6 +71,10 @@
   std::string BaseTypeName =
   BaseType.getAsString(PrintingPolicyWithSupressedTag);
 
+  // Do not warn for CUDA built-in variables.
+  if (StringRef(BaseTypeName).startswith("__cuda_builtin_"))
+return;
+
   SourceLocation MemberExprStartLoc = MemberExpression->getBeginLoc();
   auto Diag =
   diag(MemberExprStartLoc, "static member accessed through instance");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111854: [OPENMP51]Initial parsing/sema for append_args clause for 'declare variant'

[Mike Rice 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 rGd8699391a431: [OPENMP51]Initial parsing/sema for append_args 
clause for 'declare variant' (authored by mikerice).
Herald added projects: clang, Flang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111854

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/AttrImpl.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/OpenMP/declare_variant_clauses_ast_print.cpp
  clang/test/OpenMP/declare_variant_clauses_messages.cpp
  clang/test/OpenMP/declare_variant_messages.cpp
  flang/lib/Semantics/check-omp-structure.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -315,6 +315,7 @@
 def OMPC_DeviceType : Clause<"device_type"> {}
 def OMPC_Match : Clause<"match"> {}
 def OMPC_AdjustArgs : Clause<"adjust_args"> { }
+def OMPC_AppendArgs : Clause<"append_args"> { }
 def OMPC_Depobj : Clause<"depobj"> {
   let clangClass = "OMPDepobjClause";
   let isImplicit = true;
@@ -1520,7 +1521,8 @@
 VersionedClause
   ];
   let allowedExclusiveClauses = [
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_MasterTaskloop : Directive<"master taskloop"> {
Index: flang/lib/Semantics/check-omp-structure.cpp
===
--- flang/lib/Semantics/check-omp-structure.cpp
+++ flang/lib/Semantics/check-omp-structure.cpp
@@ -1478,6 +1478,7 @@
 CHECK_SIMPLE_CLAUSE(Filter, OMPC_filter)
 CHECK_SIMPLE_CLAUSE(When, OMPC_when)
 CHECK_SIMPLE_CLAUSE(AdjustArgs, OMPC_adjust_args)
+CHECK_SIMPLE_CLAUSE(AppendArgs, OMPC_append_args)
 
 CHECK_REQ_SCALAR_INT_CLAUSE(Grainsize, OMPC_grainsize)
 CHECK_REQ_SCALAR_INT_CLAUSE(NumTasks, OMPC_num_tasks)
Index: clang/test/OpenMP/declare_variant_messages.cpp
===
--- clang/test/OpenMP/declare_variant_messages.cpp
+++ clang/test/OpenMP/declare_variant_messages.cpp
@@ -278,6 +278,12 @@
   void baz();
   void bar();
   void bar(int);
+  virtual void car();
+  virtual void dar() = 0;
+
+#pragma omp declare variant(SpecialFuncs::car) match(construct={dispatch}) // expected-error {{'#pragma omp declare variant' does not support virtual functions}}
+#pragma omp declare variant(SpecialFuncs::dar) match(construct={dispatch}) // expected-error {{'#pragma omp declare variant' does not support virtual functions}}
+
 #pragma omp declare variant(SpecialFuncs::baz) match(implementation = {}) // expected-warning {{expected identifier or string literal describing a context selector; selector skipped}} expected-note {{context selector options are: 'vendor' 'extension' 'unified_address' 'unified_shared_memory' 'reverse_offload' 'dynamic_allocators' 'atomic_default_mem_order'}} expected-note {{the ignored selector spans until here}}
 #pragma omp declare variant(SpecialFuncs::bar) match(xxx = {}) // expected-warning {{'xxx' is not a valid context set in a `declare variant`; set ignored}} expected-note {{context set options are: 'construct' 'device' 'implementation' 'user'}} expected-note {{the ignored set spans until here}}
 
Index: clang/test/OpenMP/declare_variant_clauses_messages.cpp
===
--- clang/test/OpenMP/declare_variant_clauses_messages.cpp
+++ clang/test/OpenMP/declare_variant_clauses_messages.cpp
@@ -1,14 +1,107 @@
 // RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=51 -DOMP51 -std=c++11 -o - %s
-
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=51 -DOMP51 -std=c++11 \
+// RUN:  -DNO_INTEROP_T_DEF -o - %s
 // RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP50 -std=c++11 -o - %s
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=51 -DOMP51 -DC -x c -o - %s
+
+#ifdef NO_INTEROP_T_DEF
+void foo_v1(float *, void *);
+// expected-error@+1 {{'omp_interop_t' must be defined when 'append_args' clause is used; include }}
+#pragma omp declare variant(foo_v1) append_args(interop(target)) \
+  match(construct={dispatch})
+void foo_v1(float *);
+#else
+typedef void *omp_interop_t;
 
 int Other;
 
+#ifdef OMP51
+#ifdef __cplusplus
+class A {
+public:
+  void memberfoo_v0(float *A, float *B, int *I);
+  void memberfoo_v1(float *A, float *B, int *I, omp_interop_t IOp);
+
+  // expected-error@+1 {{variant in '#p

[clang] d869939 - [OPENMP51]Initial parsing/sema for append_args clause for 'declare variant'

[Mike Rice via cfe-commits]

Author: Mike Rice
Date: 2021-10-25T09:38:50-07:00
New Revision: d8699391a431af5730fe36ac4b05840020c42203

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

LOG: [OPENMP51]Initial parsing/sema for append_args clause for 'declare variant'

Adds initial parsing and sema for the 'append_args' clause.

Note that an AST clause is not created as it instead adds its values
to the OMPDeclareVariantAttr.

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

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/AttrImpl.cpp
clang/lib/Basic/OpenMPKinds.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/test/OpenMP/declare_variant_clauses_ast_print.cpp
clang/test/OpenMP/declare_variant_clauses_messages.cpp
clang/test/OpenMP/declare_variant_messages.cpp
flang/lib/Semantics/check-omp-structure.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index f58217f8f44a..31ca7d21b902 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3692,7 +3692,10 @@ def OMPDeclareVariant : InheritableAttr {
 ExprArgument<"VariantFuncRef">,
 OMPTraitInfoArgument<"TraitInfos">,
 VariadicExprArgument<"AdjustArgsNothing">,
-VariadicExprArgument<"AdjustArgsNeedDevicePtr">
+VariadicExprArgument<"AdjustArgsNeedDevicePtr">,
+VariadicEnumArgument<"AppendArgs", "InteropType",
+ ["target", "targetsync", "target,targetsync"],
+ ["Target", "TargetSync", "Target_TargetSync"]>
   ];
   let AdditionalMembers = [{
 OMPTraitInfo &getTraitInfo() { return *traitInfos; }

diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 367da91afbae..297e974c6488 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1359,9 +1359,11 @@ def err_omp_mapper_illegal_identifier : Error<
   "illegal OpenMP user-defined mapper identifier">;
 def err_omp_mapper_expected_declarator : Error<
   "expected declarator on 'omp declare mapper' directive">;
+def err_omp_unexpected_append_op : Error<
+  "unexpected operation specified in 'append_args' clause, expected 
'interop'">;
 def err_omp_declare_variant_wrong_clause : Error<
-  "expected %select{'match'|'match' or 'adjust_args'}0 clause on "
-  "'omp declare variant' directive">;
+  "expected %select{'match'|'match', 'adjust_args', or 'append_args'}0 clause "
+  "on 'omp declare variant' directive">;
 def err_omp_declare_variant_duplicate_nested_trait : Error<
   "nested OpenMP context selector contains duplicated trait '%0'"
   " in selector '%1' and set '%2' with 
diff erent score">;

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 7cee98c8a64c..370ccd01ee8e 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10747,9 +10747,14 @@ def err_omp_declare_variant_
diff  : Error<
   "function with '#pragma omp declare variant' has a 
diff erent %select{calling convention"
   "|return type|constexpr specification|inline specification|storage class|"
   "linkage}0">;
+def err_omp_declare_variant_prototype_required : Error<
+  "function with '#pragma omp declare variant' must have a prototype when "
+  "'append_args' is used">;
+def err_omp_interop_type_not_found : Error<
+  "'omp_interop_t' must be defined when 'append_args' clause is used; include 
">;
 def err_omp_declare_variant_incompat_types : Error<
-  "variant in '#pragma omp declare variant' with type %0 is incompatible with 
type %1"
-  >;
+  "variant in '#pragma omp declare variant' with type %0 is incompatible with"
+  " type %1%select{| with appended arguments}2">;
 def warn_omp_declare_variant_marked_as_declare_variant : Warning<
   "variant function in '#pragma omp declare variant' is itself marked as 
'#pragma omp declare variant'"
   >, InGroup;
@@ -10818,6 +10823,8 @@ def err_omp_adjust_arg_multiple_clauses : Error<
   "'adjust_arg' argument %0 used in multiple clauses">;
 def err_omp_clause_requires_dispatch_construct : Error<
   "'%0' clause requires 'dispatch' context selector">;
+def err_omp_append_args_with_varargs : Error<
+  "'append_args' is not allowed with varargs functions">;
 } // end of OpenMP category
 
 let CategoryName

[PATCH] D112409: [clang-tidy] Add check 'cert-err33-c'.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:45-50
+// The following functions are
+// deliberately excluded because they can
+// be called with NULL argument and in
+// this case the check is not applicable:
+// mblen, mbrlen, mbrtowc, mbtowc, wctomb,
+// wctomb_s

Pretty sure this comment can be re-flowed to 80 columns. Also needs trailing 
punctuation.



Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:52
+// FIXME: The check can be improved to handle such cases.
+const llvm::StringRef CertErr33CCheckedFunctions = "::aligned_alloc;"
+   "::asctime_s;"

Was this list generated automatically or manually? (Just wondering how hard to 
match it to the CERT rule -- spot checking hasn't found issues so far.)



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst:51
+listed in CERT_rule ERR33-C.
\ No newline at end of file


Can you add a newline back?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112409

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

[clang] 2e94c2b - [RISCV] Remove always_inline and nodebug attributes from RISCV vector intrinsic header.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-10-25T09:29:37-07:00
New Revision: 2e94c2bd75367a8a26ac71560963ecb9f0bf6bea

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

LOG: [RISCV] Remove always_inline and nodebug attributes from RISCV vector 
intrinsic header.

I don't think these are needed with the way builtin_alias is
implemented.

Added: 


Modified: 
clang/utils/TableGen/RISCVVEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/RISCVVEmitter.cpp 
b/clang/utils/TableGen/RISCVVEmitter.cpp
index 7a23a4bcd9fd..62eef830318f 100644
--- a/clang/utils/TableGen/RISCVVEmitter.cpp
+++ b/clang/utils/TableGen/RISCVVEmitter.cpp
@@ -981,8 +981,7 @@ void RVVEmitter::createHeader(raw_ostream &OS) {
 return A->getRISCVExtensions() < B->getRISCVExtensions();
   });
 
-  OS << "#define __rvv_ai static __inline__ "
-"__attribute__((__always_inline__, __nodebug__))\n";
+  OS << "#define __rvv_ai static __inline__\n";
 
   // Print intrinsic functions with macro
   emitArchMacroAndBody(Defs, OS, [](raw_ostream &OS, const RVVIntrinsic &Inst) 
{
@@ -996,7 +995,7 @@ void RVVEmitter::createHeader(raw_ostream &OS) {
 
   // Print Overloaded APIs
   OS << "#define __rvv_aio static __inline__ "
-"__attribute__((__always_inline__, __nodebug__, __overloadable__))\n";
+"__attribute__((__overloadable__))\n";
 
   emitArchMacroAndBody(Defs, OS, [](raw_ostream &OS, const RVVIntrinsic &Inst) 
{
 if (!Inst.isMask() && !Inst.hasNoMaskedOverloaded())



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

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/builtins-elementwise-math.c:42
+  // expected-error@-1 {{argument types do not match, 'float4' (vector of 4 
'float' values) != 'int3' (vector of 3 'int' values)}}
+}

aaron.ballman wrote:
> fhahn wrote:
> > aaron.ballman wrote:
> > > Additional tests I would like to see:
> > > ```
> > > int i;
> > > short s;
> > > 
> > > __builtin_elementwise_min(i, s); // ok (integer promotions)?
> > > 
> > > enum e { one, two };
> > > __builtin_elementwise_min(one, two); // ok (using enums)?
> > > 
> > > enum f { three };
> > > __builtin_elementwise_min(one, three); // ok (different enums)?
> > > 
> > > _ExtInt(32) ext;
> > > __builtin_elementwise_min(ext, ext); // ok (using bit-precise integers)?
> > > 
> > > const int ci;
> > > __builtin_elementwise_min(i, ci); // ok (qualifiers don't match)?
> > > ```
> > Thanks I'll add those!
> > 
> > at the moment `__builtin_elementwise_min(i, s); // ok (integer 
> > promotions)?` would be rejected, as per my response in Sema.
> > 
> > The other currently are not handled properly, which I'll fix!
> I'd still like to see the test case added so it's clear we intend to reject 
> it. It may also be wise to add a test case involving an integer literal and a 
> `short` variable cast to `int` to make it clear that you have to add casts 
> sometimes to make this work.
> 
> Another interesting test is where sugars don't match. e.g.,
> ```
> int i;
> __attribute__((address_space(0))) int addr_space_i;
> typedef int foo;
> 
> __builtin_elementwise_min(i, addr_space_i); // ok (attributes don't match)?
> __builtin_elementwise_min(i, foo); // ok (sugar doesn't match)?
> ```
You might also need to handle something like:
```
int (i);
int j;
__builtin_elementwise_min(i, j);  // May get a type mismatch here
```
So you may need to do some type canonicalization to avoid these sorts of issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111985

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

[PATCH] D112409: [clang-tidy] Add check 'cert-err33-c'.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-err33-c.rst:7
+Warns on unused function return values.
+This check corresponds to (a part of) CERT C Coding Standard rule `ERR33-C.
+Detect and handle standard library errors

Usually such statement is located at the end.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-err33-c.rst:13
+
+* These functions are safe if called with NULL argument. The check can not
+  differentiate this case from the others.::

Please enclose `NULL` into double back-ticks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112409

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

[PATCH] D111985: [Clang] Add elementwise min/max builtins.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:16661
+Sema &S) {
+  if (!Ty->getAs() && !ConstantMatrixType::isValidElementType(Ty)) 
{
+S.Diag(Loc, diag::err_elementwise_math_invalid_arg_type) << Ty;

fhahn wrote:
> aaron.ballman wrote:
> > I'm a bit surprised we'd need `!Ty->getAs()` as I would have 
> > expected `!ConstantMatrixType::isValidElementType(Ty)` to cover all the 
> > type checking of `Ty`. Can you explain why the extra check is needed here?
> The builtins as implemented accept either vector types or a scalar type, 
> which then must be a valid element type for matrix types. The second check 
> may be a bit confusing, but the restrictions laid out in the spec for 
> scalar/element-types match the matrix element type restrictions, so this 
> seems a convenient helper to use.
> 
> Does this in general make sense?
Thanks for the explanation, that makes sense.



Comment at: clang/lib/Sema/SemaChecking.cpp:16669
+ExprResult Sema::SemaBuiltinElementwiseMath(CallExpr *TheCall,
+ExprResult CallResult) {
+  if (checkArgCount(*this, TheCall, 2))

fhahn wrote:
> aaron.ballman wrote:
> > Do we actually need this parameter?
> No, it can just return `ExprResult(TheCall)` instead I think!
Could also return a `bool` and have the caller fiddle with `ExprResult`, too. I 
don't have strong opinions on which way to go though.



Comment at: clang/lib/Sema/SemaChecking.cpp:16673-16678
+  Expr *A = TheCall->getArg(0);
+  Expr *B = TheCall->getArg(1);
+  QualType TyA = A->getType();
+  QualType TyB = B->getType();
+
+  if (TyA != TyB)

fhahn wrote:
> aaron.ballman wrote:
> > Should these arguments undergo usual conversions (array to pointer decay, 
> > integer promotions, etc)?
> I intentionally went with not performing conversions, because it might lead 
> to surprising results. If the arguments have different types, it is not clear 
> to me which type should be chosen to try convert the other one; e.g. if we 
> have __builtin_elementwise_max(float, int)` should the first argument be 
> converted to `int` or the second one to `float`?
> 
> Forcing the types to match without conversion seem to make them less 
> error-prone to use, but I might be missing some general rule to handle type 
> conflicts here?
I'm not certain how these builtins are expected to be used, but if they're 
likely to be used with literals, I think we may want integer promotions because 
of that alone.

Btw, given that these only have two arguments, it seems like we could use the 
usual arithmetic conversions to pick a common type the same way as happens for 
binary operators.

If you end up not adding any conversions here, we should have a test case to 
cover passing in two array objects (which won't decay to pointers).



Comment at: clang/test/Sema/builtins-elementwise-math.c:42
+  // expected-error@-1 {{argument types do not match, 'float4' (vector of 4 
'float' values) != 'int3' (vector of 3 'int' values)}}
+}

fhahn wrote:
> aaron.ballman wrote:
> > Additional tests I would like to see:
> > ```
> > int i;
> > short s;
> > 
> > __builtin_elementwise_min(i, s); // ok (integer promotions)?
> > 
> > enum e { one, two };
> > __builtin_elementwise_min(one, two); // ok (using enums)?
> > 
> > enum f { three };
> > __builtin_elementwise_min(one, three); // ok (different enums)?
> > 
> > _ExtInt(32) ext;
> > __builtin_elementwise_min(ext, ext); // ok (using bit-precise integers)?
> > 
> > const int ci;
> > __builtin_elementwise_min(i, ci); // ok (qualifiers don't match)?
> > ```
> Thanks I'll add those!
> 
> at the moment `__builtin_elementwise_min(i, s); // ok (integer promotions)?` 
> would be rejected, as per my response in Sema.
> 
> The other currently are not handled properly, which I'll fix!
I'd still like to see the test case added so it's clear we intend to reject it. 
It may also be wise to add a test case involving an integer literal and a 
`short` variable cast to `int` to make it clear that you have to add casts 
sometimes to make this work.

Another interesting test is where sugars don't match. e.g.,
```
int i;
__attribute__((address_space(0))) int addr_space_i;
typedef int foo;

__builtin_elementwise_min(i, addr_space_i); // ok (attributes don't match)?
__builtin_elementwise_min(i, foo); // ok (sugar doesn't match)?
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111985

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

[PATCH] D112409: [clang-tidy] Add check 'cert-err33-c'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added a comment.

This check is likely to generate many warnings on a "random" open-source 
project because many of these functions are usually not checked. But the rule 
contains this list and if a project wants to conform this check can be useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112409

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

[clang] 16ceb44 - [clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC)

[Kazu Hirata via cfe-commits]

Author: Kazu Hirata
Date: 2021-10-25T09:14:45-07:00
New Revision: 16ceb44e62c3e7e2077198bb0211fc89d5770bc4

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

LOG: [clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC)

Added: 


Modified: 
clang/lib/AST/ASTContext.cpp
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/CodeGen/CGVTables.cpp
clang/lib/CodeGen/MicrosoftCXXABI.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Format/BreakableToken.cpp
clang/lib/Lex/PPLexerChange.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/tools/driver/driver.cpp
clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
clang/utils/TableGen/NeonEmitter.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index 796a737b8c6d..2611295d21a8 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -5168,11 +5168,8 @@ QualType ASTContext::getObjCObjectType(
   // sorted-and-uniqued list of protocols and the type arguments
   // canonicalized.
   QualType canonical;
-  bool typeArgsAreCanonical = std::all_of(effectiveTypeArgs.begin(),
-  effectiveTypeArgs.end(),
-  [&](QualType type) {
-return type.isCanonical();
-  });
+  bool typeArgsAreCanonical = llvm::all_of(
+  effectiveTypeArgs, [&](QualType type) { return type.isCanonical(); });
   bool protocolsSorted = areSortedAndUniqued(protocols);
   if (!typeArgsAreCanonical || !protocolsSorted || !baseType.isCanonical()) {
 // Determine the canonical type arguments.

diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 399bfdbd33a5..5188ebc89600 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -11713,11 +11713,11 @@ getNDSWDS(const FunctionDecl *FD, 
ArrayRef ParamAttrs) {
   assert(!Sizes.empty() && "Unable to determine NDS and WDS.");
   // The LS of a function parameter / return value can only be a power
   // of 2, starting from 8 bits, up to 128.
-  assert(std::all_of(Sizes.begin(), Sizes.end(),
- [](unsigned Size) {
-   return Size == 8 || Size == 16 || Size == 32 ||
-  Size == 64 || Size == 128;
- }) &&
+  assert(llvm::all_of(Sizes,
+  [](unsigned Size) {
+return Size == 8 || Size == 16 || Size == 32 ||
+   Size == 64 || Size == 128;
+  }) &&
  "Invalid size");
 
   return std::make_tuple(*std::min_element(std::begin(Sizes), std::end(Sizes)),

diff  --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index bcc55b6b4786..7b87441803f3 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -201,7 +201,7 @@ CodeGenFunction::GenerateVarArgsThunk(llvm::Function *Fn,
   Address ThisPtr(&*AI, CGM.getClassPointerAlignment(MD->getParent()));
   llvm::BasicBlock *EntryBB = &Fn->front();
   llvm::BasicBlock::iterator ThisStore =
-  std::find_if(EntryBB->begin(), EntryBB->end(), [&](llvm::Instruction &I) 
{
+  llvm::find_if(*EntryBB, [&](llvm::Instruction &I) {
 return isa(I) &&
I.getOperand(0) == ThisPtr.getPointer();
   });

diff  --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index a53e10027b13..0fd5a0ffe06c 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1810,8 +1810,8 @@ llvm::GlobalVariable 
*MicrosoftCXXABI::getAddrOfVTable(const CXXRecordDecl *RD,
 #endif
   }
 
-  const std::unique_ptr *VFPtrI = std::find_if(
-  VFPtrs.begin(), VFPtrs.end(), [&](const std::unique_ptr& VPI) {
+  const std::unique_ptr *VFPtrI =
+  llvm::find_if(VFPtrs, [&](const std::unique_ptr &VPI) {
 return VPI->FullOffsetInMDC == VPtrOffset;
   });
   if (VFPtrI == VFPtrs.end()) {

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index b9960059e707..2e69e6c50f4a 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -879,10 +879,9 @@ bool Driver::loadConfigFile() {
 std::vector ConfigFiles =
 CLOptions->getAllArgValues(options::OPT_config);
 if (ConfigFiles.size() > 1) {
-  if (!std::all_of(ConfigFiles.begin(), ConfigFiles.end(),
- 

[PATCH] D112334: [clang-tidy] Suppress readability-static-access-through-instance for CUDA built-in variables

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D112334#3084668 , @carlosgalvezp 
wrote:

> Thanks for the review!
>
> I'm not super happy with the commit in the sense that it feels more like a 
> workaround than a proper fix, with the hardcoded name `__cuda_built_in` and 
> so on. But honestly I don't know how implement it more properly, for example 
> check if the `BaseTypeName` is a CUDA built-in type. Another issue is that 
> currently one can't ignore warnings from system headers (like 
> `__clang_cuda_builtin_vars.h`)if they come from a macro defined there. But I 
> suppose that's a harder problem to tackle.
>
> But if you are happy with the patch I can go ahead and merge, and come back 
> to it if I learn how to improve it later on as I get to learn more about the 
> codebase.

I'm also a bit uneasy about it because I suspect this may apply to more than 
just CUDA (e.g., I would imagine this applies to any builtin type). However, 
there's no easy way to tell that these are builtin types because they're 
exposed via a `Headers` include, and not via one of the intrinsic types in 
`Types.h`. So I don't know of a better way to fix this and this seems like an 
incremental improvement.

However, this won't be fool-proof either. A user could make a typedef to one of 
these types; access through the typedef will still warn because of the 
name-based matching. You could look through type sugar for that issue, but I'm 
not certain how critical that is to solve.




Comment at: 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp:75
+  // Do not warn for CUDA built-in variables.
+  if (StringRef(BaseTypeName).contains("__cuda_builtin_"))
+return;

carlosgalvezp wrote:
> aaron.ballman wrote:
> > I presume we want this to strictly be a prefix?
> Sure, but then I can't put the test in a named namespace. I changed it to 
> anonymous namespace + link to Bugzilla, hope it works.
These types are not defined within a namespace in 
`__clang_cuda_builtin_vars.h`, so I wouldn't expect them to be in the test file 
TBH.


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

https://reviews.llvm.org/D112334

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

[PATCH] D112102: [RISCV] Reduce the number of RISCV vector builtins by an order of magnitude.

[Craig Topper via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe2b7aabb57d5: [RISCV] Reduce the number of RISCV vector 
builtins by an order of magnitude. (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112102

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmerge.c
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/test/CodeGen/RISCV/rvv/vmerge-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmerge-rv64.ll

Index: llvm/test/CodeGen/RISCV/rvv/vmerge-rv64.ll
===
--- llvm/test/CodeGen/RISCV/rvv/vmerge-rv64.ll
+++ llvm/test/CodeGen/RISCV/rvv/vmerge-rv64.ll
@@ -1,5 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv64 -mattr=+experimental-v,+d -verify-machineinstrs \
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-v,+d,+experimental-zfh -verify-machineinstrs \
 ; RUN:   < %s | FileCheck %s
 declare  @llvm.riscv.vmerge.nxv1i8.nxv1i8(
   ,
@@ -1320,3 +1320,333 @@
 
   ret  %a
 }
+
+declare  @llvm.riscv.vmerge.nxv1f16.nxv1f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv1f16_nxv1f16_nxv1f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv1f16_nxv1f16_nxv1f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, mf4, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v9, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv1f16.nxv1f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv2f16.nxv2f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv2f16_nxv2f16_nxv2f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv2f16_nxv2f16_nxv2f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, mf2, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v9, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv2f16.nxv2f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv4f16.nxv4f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv4f16_nxv4f16_nxv4f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv4f16_nxv4f16_nxv4f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, m1, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v9, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv4f16.nxv4f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv8f16.nxv8f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv8f16_nxv8f16_nxv8f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv8f16_nxv8f16_nxv8f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, m2, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v10, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv8f16.nxv8f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv16f16.nxv16f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv16f16_nxv16f16_nxv16f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv16f16_nxv16f16_nxv16f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, m4, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v12, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv16f16.nxv16f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv32f16.nxv32f16(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv32f16_nxv32f16_nxv32f16( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv32f16_nxv32f16_nxv32f16:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e16, m8, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v16, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv32f16.nxv32f16(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv1f32.nxv1f32(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv1f32_nxv1f32_nxv1f32( %0,  %1,  %2, i64 %3) nounwind {
+; CHECK-LABEL: intrinsic_vmerge_vvm_nxv1f32_nxv1f32_nxv1f32:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vsetvli zero, a0, e32, mf2, ta, mu
+; CHECK-NEXT:vmerge.vvm v8, v8, v9, v0
+; CHECK-NEXT:ret
+entry:
+  %a = call  @llvm.riscv.vmerge.nxv1f32.nxv1f32(
+ %0,
+ %1,
+ %2,
+i64 %3)
+
+  ret  %a
+}
+
+declare  @llvm.riscv.vmerge.nxv2f32.nxv2f32(
+  ,
+  ,
+  ,
+  i64);
+
+define  @intrinsic_vmerge_vvm_nxv2f32_nxv2f32_nxv2