[clang] [clang][sema] forbid vector_size attr when specify `-mgeneral-regs-only` on x86 (PR #75350)

2023-12-13 Thread Phoebe Wang via cfe-commits


@@ -8251,6 +8251,25 @@ static void HandleVectorSizeAttr(QualType , 
const ParsedAttr ,
 return;
   }
 
+  // check -mgeneral-regs-only is specified
+  const TargetInfo  = S.getASTContext().getTargetInfo();
+  llvm::Triple::ArchType arch = targetInfo.getTriple().getArch();
+  const auto HasFeature = [](const clang::TargetOptions ,
+ const std::string ) {
+return std::find(targetOpts.Features.begin(), targetOpts.Features.end(),
+ feature) != targetOpts.Features.end();
+  };
+  if (CurType->isSpecificBuiltinType(BuiltinType::LongDouble)) {

phoebewang wrote:

`LongDouble` is not the only problem. GCC simply disallows any vector return 
type without SSE (`sse` feature) and gives error like `SSE register return with 
SSE disabled` and give warnings to vector argument type. 
https://godbolt.org/z/fhG76nqYo
LLVM behaves differently from GCC. It can generate code for any vector types 
expect `LongDouble` with `-mgeneral-regs-only`.
I think it would be incorrect but I'm not sure if we want to make it such 
strict.
`LongDouble` cannot be supported without `x87` feature. I'd expect something 
like https://reviews.llvm.org/D98895. It would be good if you can add vector 
type check there.
And you need to add test case for this scenario.

https://github.com/llvm/llvm-project/pull/75350
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][ARM] support arm target attribute, and warning for bad typo (PR #74812)

2023-12-13 Thread via cfe-commits

https://github.com/hstk30-hw updated 
https://github.com/llvm/llvm-project/pull/74812

>From b6595d617c6ac0f3e402aeb782eeeb78f90c5fb1 Mon Sep 17 00:00:00 2001
From: hstk30-hw 
Date: Fri, 8 Dec 2023 14:29:33 +0800
Subject: [PATCH] feat: support arm target attribute, and warning for bad typo

---
 clang/lib/Basic/Targets/AArch64.cpp   |  6 +-
 clang/lib/Basic/Targets/ARM.cpp   | 87 +++
 clang/lib/Basic/Targets/ARM.h |  2 +
 clang/lib/Sema/SemaDeclAttr.cpp   |  3 +
 clang/test/CodeGen/arm-targetattr.c   | 13 +++
 .../arm-ignore-branch-protection-option.c |  4 +-
 .../Sema/arm-branch-protection-attr-warn.c| 10 +--
 clang/test/Sema/arm-branch-protection.c   | 32 +++
 clang/test/Sema/attr-target.c |  8 ++
 9 files changed, 141 insertions(+), 24 deletions(-)
 create mode 100644 clang/test/CodeGen/arm-targetattr.c

diff --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index c71af71eba60ce..934de9d0c7b68f 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -1065,13 +1065,17 @@ ParsedTargetAttr 
AArch64TargetInfo::parseTargetAttr(StringRef Features) const {
   FoundArch = true;
   std::pair Split =
   Feature.split("=").second.trim().split("+");
+  if (Split.first == "")
+continue;
   const std::optional AI =
   llvm::AArch64::parseArch(Split.first);
 
   // Parse the architecture version, adding the required features to
   // Ret.Features.
-  if (!AI)
+  if (!AI) {
+Ret.Features.push_back("+UNKNOWN");
 continue;
+  }
   Ret.Features.push_back(AI->ArchFeature.str());
   // Add any extra features, after the +
   SplitAndAddFeatures(Split.second, Ret.Features);
diff --git a/clang/lib/Basic/Targets/ARM.cpp b/clang/lib/Basic/Targets/ARM.cpp
index ce7e4d4639ceac..7ed64f4f44a9b5 100644
--- a/clang/lib/Basic/Targets/ARM.cpp
+++ b/clang/lib/Basic/Targets/ARM.cpp
@@ -11,6 +11,7 @@
 
//===--===//
 
 #include "ARM.h"
+#include "clang/AST/Attr.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/TargetBuiltins.h"
@@ -639,6 +640,92 @@ bool 
ARMTargetInfo::handleTargetFeatures(std::vector ,
   return true;
 }
 
+// Parse ARM Target attributes, which are a comma separated list of:
+//  "arch=" - parsed to features as per -march=..
+//  "cpu=" - parsed to features as per -mcpu=.., with CPU set to 
+//  "tune=" - TuneCPU set to 
+//  "feature", "no-feature" - Add (or remove) feature.
+//  "+feature", "+nofeature" - Add (or remove) feature.
+ParsedTargetAttr ARMTargetInfo::parseTargetAttr(StringRef Features) const {
+  ParsedTargetAttr Ret;
+  if (Features == "default")
+return Ret;
+  SmallVector AttrFeatures;
+  Features.split(AttrFeatures, ",");
+  bool FoundArch = false;
+
+  auto SplitAndAddFeatures = [](StringRef FeatString,
+std::vector ) {
+SmallVector SplitFeatures;
+FeatString.split(SplitFeatures, StringRef("+"), -1, false);
+for (StringRef Feature : SplitFeatures) {
+  StringRef FeatureName = llvm::ARM::getArchExtFeature(Feature);
+  if (!FeatureName.empty())
+Features.push_back(FeatureName.str());
+  else
+// Pushing the original feature string to give a sema error later on
+// when they get checked.
+Features.push_back(Feature.str());
+}
+  };
+
+  for (auto  : AttrFeatures) {
+Feature = Feature.trim();
+if (Feature.startswith("fpmath="))
+  continue;
+
+if (Feature.startswith("branch-protection=")) {
+  Ret.BranchProtection = Feature.split('=').second.trim();
+  continue;
+}
+
+if (Feature.startswith("arch=")) {
+  if (FoundArch)
+Ret.Duplicate = "arch=";
+  FoundArch = true;
+  std::pair Split =
+  Feature.split("=").second.trim().split("+");
+  if (Split.first == "")
+continue;
+  llvm::ARM::ArchKind ArchKind = llvm::ARM::parseArch(Split.first);
+
+  // Parse the architecture version, adding the required features to
+  // Ret.Features.
+  std::vector FeatureStrs;
+  if (ArchKind == llvm::ARM::ArchKind::INVALID) {
+Ret.Features.push_back("+UNKNOWN");
+continue;
+  }
+  std::string ArchFeature = ("+" + llvm::ARM::getArchName(ArchKind)).str();
+  Ret.Features.push_back(ArchFeature);
+  // Add any extra features, after the +
+  SplitAndAddFeatures(Split.second, Ret.Features);
+} else if (Feature.startswith("cpu=")) {
+  if (!Ret.CPU.empty())
+Ret.Duplicate = "cpu=";
+  else {
+// Split the cpu string into "cpu=", "cortex-a710" and any remaining
+// "+feat" features.
+std::pair Split =
+Feature.split("=").second.trim().split("+");
+Ret.CPU = Split.first;
+

[clang] [ARM] arm_acle.h add Corprocessor Instrinsics (PR #75440)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-backend-x86

Author: None (hstk30-hw)


Changes

https://github.com/llvm/llvm-project/issues/75424 

Add Corprocessor Instrinsics

---
Full diff: https://github.com/llvm/llvm-project/pull/75440.diff


1 Files Affected:

- (modified) clang/lib/Headers/arm_acle.h (+48-1) 


``diff
diff --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 61d80258d166a1..9c709550ccc45b 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -752,10 +752,57 @@ __arm_st64bv0(void *__addr, data512_t __value) {
 #define __arm_mte_ptrdiff(__ptra, __ptrb) __builtin_arm_subp(__ptra, __ptrb)
 
 /* Memory Operations Intrinsics */
-#define __arm_mops_memset_tag(__tagged_address, __value, __size)\
+#define __arm_mops_memset_tag(__tagged_address, __value, __size)   
\
   __builtin_arm_mops_memset_tag(__tagged_address, __value, __size)
 #endif
 
+/* Coprocessor Intrinsics */
+#if (!__thumb__ || __thumb2__) && __ARM_ARCH >= 4
+#define __arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)   
\
+  __builtin_arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc(__coproc, __CRd, __p) __builtin_arm_ldc(__coproc, __CRd, __p)
+#define __arm_ldcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldcl(__coproc, __CRd, __p)
+#define __arm_stc(__coproc, __CRd, __p) __builtin_arm_stc(__coproc, __CRd, __p)
+#define __arm_stcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_stcl(__coproc, __CRd, __p)
+#define __arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 5
+#define __arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldc2(__coproc, __CRd, __p)
+#define __arm_ldc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_ldc2l(__coproc, __CRd, __p)
+#define __arm_stc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_stc2(__coproc, __CRd, __p)
+#define __arm_stc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_stc2l(__coproc, __CRd, __p)
+#define __arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
\
+  __builtin_arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 6 || defined(__ARM_ARCH_5TE__)
+#define __arm_mcrr(__coproc, __opc1, __value, __CRm)   
\
+  __builtin_arm_mcrr(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc(__coproc, __opc1, __CRm)
\
+  __builtin_arm_mrrc(__coproc, __opc1, __CRm)
+
+#if __ARM_ARCH >= 6
+#define __arm_mcrr2(__coproc, __opc1, __value, __CRm)  
\
+  __builtin_arm_mcrr2(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc2(__coproc, __opc1, __CRm)   
\
+  __builtin_arm_mrrc2(__coproc, __opc1, __CRm)
+#endif /* __ARM_ARCH >= 6.  */
+#endif /* __ARM_ARCH >= 6 ||  defined (__ARM_ARCH_5TE__).  */
+#endif /*  __ARM_ARCH >= 5.  */
+#endif /* (!__thumb__ || __thumb2__) &&  __ARM_ARCH >= 4.  */
+
 /* Transactional Memory Extension (TME) Intrinsics */
 #if defined(__ARM_FEATURE_TME) && __ARM_FEATURE_TME
 

``




https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] arm_acle.h add Corprocessor Instrinsics (PR #75440)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (hstk30-hw)


Changes

https://github.com/llvm/llvm-project/issues/75424 

Add Corprocessor Instrinsics

---
Full diff: https://github.com/llvm/llvm-project/pull/75440.diff


1 Files Affected:

- (modified) clang/lib/Headers/arm_acle.h (+48-1) 


``diff
diff --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 61d80258d166a1..9c709550ccc45b 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -752,10 +752,57 @@ __arm_st64bv0(void *__addr, data512_t __value) {
 #define __arm_mte_ptrdiff(__ptra, __ptrb) __builtin_arm_subp(__ptra, __ptrb)
 
 /* Memory Operations Intrinsics */
-#define __arm_mops_memset_tag(__tagged_address, __value, __size)\
+#define __arm_mops_memset_tag(__tagged_address, __value, __size)   
\
   __builtin_arm_mops_memset_tag(__tagged_address, __value, __size)
 #endif
 
+/* Coprocessor Intrinsics */
+#if (!__thumb__ || __thumb2__) && __ARM_ARCH >= 4
+#define __arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)   
\
+  __builtin_arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc(__coproc, __CRd, __p) __builtin_arm_ldc(__coproc, __CRd, __p)
+#define __arm_ldcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldcl(__coproc, __CRd, __p)
+#define __arm_stc(__coproc, __CRd, __p) __builtin_arm_stc(__coproc, __CRd, __p)
+#define __arm_stcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_stcl(__coproc, __CRd, __p)
+#define __arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 5
+#define __arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldc2(__coproc, __CRd, __p)
+#define __arm_ldc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_ldc2l(__coproc, __CRd, __p)
+#define __arm_stc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_stc2(__coproc, __CRd, __p)
+#define __arm_stc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_stc2l(__coproc, __CRd, __p)
+#define __arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
\
+  __builtin_arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 6 || defined(__ARM_ARCH_5TE__)
+#define __arm_mcrr(__coproc, __opc1, __value, __CRm)   
\
+  __builtin_arm_mcrr(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc(__coproc, __opc1, __CRm)
\
+  __builtin_arm_mrrc(__coproc, __opc1, __CRm)
+
+#if __ARM_ARCH >= 6
+#define __arm_mcrr2(__coproc, __opc1, __value, __CRm)  
\
+  __builtin_arm_mcrr2(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc2(__coproc, __opc1, __CRm)   
\
+  __builtin_arm_mrrc2(__coproc, __opc1, __CRm)
+#endif /* __ARM_ARCH >= 6.  */
+#endif /* __ARM_ARCH >= 6 ||  defined (__ARM_ARCH_5TE__).  */
+#endif /*  __ARM_ARCH >= 5.  */
+#endif /* (!__thumb__ || __thumb2__) &&  __ARM_ARCH >= 4.  */
+
 /* Transactional Memory Extension (TME) Intrinsics */
 #if defined(__ARM_FEATURE_TME) && __ARM_FEATURE_TME
 

``




https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[compiler-rt] [libc] [libcxx] [clang] [llvm] [clang-tools-extra] [flang] [RISCV][MC] Add support for experimental Zimop extension (PR #75182)

2023-12-13 Thread Craig Topper via cfe-commits

topperc wrote:

> > > @topperc If I am not mistaken Zicfiss extension uses moprr instructions 
> > > to get ROP functionality. But Zimop does not limit only the use of 
> > > Zicfiss extension. They can be redefined and assigned other operations.
> 
> > 
> 
> > Right, but won't users be programming to each of the extensions that 
> > redefine them rather than some generic interface? We don't have 
> > builtins/intrinsics for all of the HINT encodings that can redefined.
> 
> 
> 
> Yeah, I agree with you. 
> 
> But can be cases when someone in some narrow case needs to program logic by 
> hand. Why restrict it? 
> 
> I also think that a generic interface is much better than achieving the same 
> logic through builtins/intrinsics.

I just read back over my original question. I'm not sure it was clear that I 
was asking about the need for intrinsics. I don't object to assembler support 
and inline assembly is always an option.

https://github.com/llvm/llvm-project/pull/75182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] arm_acle.h add Corprocessor Instrinsics (PR #75440)

2023-12-13 Thread via cfe-commits

https://github.com/hstk30-hw created 
https://github.com/llvm/llvm-project/pull/75440

https://github.com/llvm/llvm-project/issues/75424 

Add Corprocessor Instrinsics

>From 12fc8ec01b426fe826d049576825ec187bef0bd0 Mon Sep 17 00:00:00 2001
From: hstk30-hw 
Date: Thu, 14 Dec 2023 15:40:03 +0800
Subject: [PATCH] feat: arm_acle.h add Corprocessor Instrinsics

---
 clang/lib/Headers/arm_acle.h | 49 +++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 61d80258d166a1..9c709550ccc45b 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -752,10 +752,57 @@ __arm_st64bv0(void *__addr, data512_t __value) {
 #define __arm_mte_ptrdiff(__ptra, __ptrb) __builtin_arm_subp(__ptra, __ptrb)
 
 /* Memory Operations Intrinsics */
-#define __arm_mops_memset_tag(__tagged_address, __value, __size)\
+#define __arm_mops_memset_tag(__tagged_address, __value, __size)   
\
   __builtin_arm_mops_memset_tag(__tagged_address, __value, __size)
 #endif
 
+/* Coprocessor Intrinsics */
+#if (!__thumb__ || __thumb2__) && __ARM_ARCH >= 4
+#define __arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)   
\
+  __builtin_arm_cdp(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc(__coproc, __CRd, __p) __builtin_arm_ldc(__coproc, __CRd, __p)
+#define __arm_ldcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldcl(__coproc, __CRd, __p)
+#define __arm_stc(__coproc, __CRd, __p) __builtin_arm_stc(__coproc, __CRd, __p)
+#define __arm_stcl(__coproc, __CRd, __p)   
\
+  __builtin_arm_stcl(__coproc, __CRd, __p)
+#define __arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mcr(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_mrc(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 5
+#define __arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)  
\
+  __builtin_arm_cdp2(__coproc, __opc1, __CRd, __CRn, __CRm, __opc2)
+#define __arm_ldc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_ldc2(__coproc, __CRd, __p)
+#define __arm_ldc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_ldc2l(__coproc, __CRd, __p)
+#define __arm_stc2(__coproc, __CRd, __p)   
\
+  __builtin_arm_stc2(__coproc, __CRd, __p)
+#define __arm_stc2l(__coproc, __CRd, __p)  
\
+  __builtin_arm_stc2l(__coproc, __CRd, __p)
+#define __arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
\
+  __builtin_arm_mcr2(__coproc, __opc1, __value, __CRn, __CRm, __opc2)
+#define __arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2) 
\
+  __builtin_arm_mrc2(__coproc, __opc1, __CRn, __CRm, __opc2)
+
+#if __ARM_ARCH >= 6 || defined(__ARM_ARCH_5TE__)
+#define __arm_mcrr(__coproc, __opc1, __value, __CRm)   
\
+  __builtin_arm_mcrr(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc(__coproc, __opc1, __CRm)
\
+  __builtin_arm_mrrc(__coproc, __opc1, __CRm)
+
+#if __ARM_ARCH >= 6
+#define __arm_mcrr2(__coproc, __opc1, __value, __CRm)  
\
+  __builtin_arm_mcrr2(__coproc, __opc1, __value, __CRm)
+#define __arm_mrrc2(__coproc, __opc1, __CRm)   
\
+  __builtin_arm_mrrc2(__coproc, __opc1, __CRm)
+#endif /* __ARM_ARCH >= 6.  */
+#endif /* __ARM_ARCH >= 6 ||  defined (__ARM_ARCH_5TE__).  */
+#endif /*  __ARM_ARCH >= 5.  */
+#endif /* (!__thumb__ || __thumb2__) &&  __ARM_ARCH >= 4.  */
+
 /* Transactional Memory Extension (TME) Intrinsics */
 #if defined(__ARM_FEATURE_TME) && __ARM_FEATURE_TME
 

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


[clang] [libcxx] [clang-tools-extra] [compiler-rt] [libc] [llvm] [flang] [RISCV][MC] Add support for experimental Zimop extension (PR #75182)

2023-12-13 Thread Jivan Hakobyan via cfe-commits

JivanH wrote:

> > @topperc If I am not mistaken Zicfiss extension uses moprr instructions to 
> > get ROP functionality. But Zimop does not limit only the use of Zicfiss 
> > extension. They can be redefined and assigned other operations.
> 
> Right, but won't users be programming to each of the extensions that redefine 
> them rather than some generic interface? We don't have builtins/intrinsics 
> for all of the HINT encodings that can redefined.

Yeah, I agree with you. 
But can be cases when someone in some narrow case needs to program logic by 
hand. Why restrict it? 
I also think that a generic interface is much better than achieving the same 
logic through builtins/intrinsics.

https://github.com/llvm/llvm-project/pull/75182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK converted_to_draft 
https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread Tobias Hieta via cfe-commits

tru wrote:

It also needs tests.

https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][CodeGen] Fix crash when using bool vector in compound assignment (PR #75435)

2023-12-13 Thread Chenyang Gao via cfe-commits

https://github.com/cygao90 edited 
https://github.com/llvm/llvm-project/pull/75435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread Tobias Hieta via cfe-commits

tru wrote:

This needs to be cleaned up before it can be merged. There needs to be only one 
commit in this PR without the merge commits from main.

https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] d5953e3 - [clangd] Use StringRef::{starts,ends}_with (NFC)

2023-12-13 Thread Kazu Hirata via cfe-commits

Author: Kazu Hirata
Date: 2023-12-13T23:26:09-08:00
New Revision: d5953e3e3092f7142a07aa012fc9665ede09e53b

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

LOG: [clangd] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

Added: 


Modified: 
clang-tools-extra/clangd/AST.cpp
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/CodeCompletionStrings.cpp
clang-tools-extra/clangd/CompileCommands.cpp
clang-tools-extra/clangd/ConfigCompile.cpp
clang-tools-extra/clangd/DumpAST.cpp
clang-tools-extra/clangd/FileDistance.cpp
clang-tools-extra/clangd/FindSymbols.cpp
clang-tools-extra/clangd/Format.cpp
clang-tools-extra/clangd/Headers.cpp
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/IncludeCleaner.cpp
clang-tools-extra/clangd/IncludeFixer.cpp
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/JSONTransport.cpp
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/PathMapping.cpp
clang-tools-extra/clangd/Protocol.cpp
clang-tools-extra/clangd/SourceCode.cpp
clang-tools-extra/clangd/SystemIncludeExtractor.cpp
clang-tools-extra/clangd/URI.cpp
clang-tools-extra/clangd/index/Merge.cpp
clang-tools-extra/clangd/index/Serialization.cpp
clang-tools-extra/clangd/index/StdLib.cpp
clang-tools-extra/clangd/index/SymbolCollector.cpp
clang-tools-extra/clangd/index/dex/Dex.cpp
clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
clang-tools-extra/clangd/support/Markup.cpp
clang-tools-extra/clangd/support/ThreadsafeFS.cpp
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
clang-tools-extra/clangd/unittests/IndexActionTests.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp
clang-tools-extra/clangd/unittests/InsertionPointTests.cpp
clang-tools-extra/clangd/unittests/StdLibTests.cpp
clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/AST.cpp 
b/clang-tools-extra/clangd/AST.cpp
index 5b81ec213ff984..ae79eb21de9470 100644
--- a/clang-tools-extra/clangd/AST.cpp
+++ b/clang-tools-extra/clangd/AST.cpp
@@ -193,7 +193,7 @@ std::string printQualifiedName(const NamedDecl ) {
   Policy.AnonymousTagLocations = false;
   ND.printQualifiedName(OS, Policy);
   OS.flush();
-  assert(!StringRef(QName).startswith("::"));
+  assert(!StringRef(QName).starts_with("::"));
   return QName;
 }
 
@@ -696,7 +696,7 @@ std::string getQualification(ASTContext ,
  const NamedDecl *ND,
  llvm::ArrayRef VisibleNamespaces) {
   for (llvm::StringRef NS : VisibleNamespaces) {
-assert(NS.endswith("::"));
+assert(NS.ends_with("::"));
 (void)NS;
   }
   return getQualification(

diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 13d788162817fb..6fb2641e8793db 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -437,7 +437,7 @@ void ClangdServer::codeComplete(PathRef File, Position Pos,
 ParseInputs ParseInput{IP->Command, (), IP->Contents.str()};
 // FIXME: Add traling new line if there is none at eof, workaround a crash,
 // see https://github.com/clangd/clangd/issues/332
-if (!IP->Contents.endswith("\n"))
+if (!IP->Contents.ends_with("\n"))
   ParseInput.Contents.append("\n");
 ParseInput.Index = Index;
 
@@ -488,7 +488,7 @@ void ClangdServer::signatureHelp(PathRef File, Position Pos,
 ParseInputs ParseInput{IP->Command, (), IP->Contents.str()};
 // FIXME: Add traling new line if there is none at eof, workaround a crash,
 // see https://github.com/clangd/clangd/issues/332
-if (!IP->Contents.endswith("\n"))
+if (!IP->Contents.ends_with("\n"))
   ParseInput.Contents.append("\n");
 ParseInput.Index = Index;
 CB(clangd::signatureHelp(File, Pos, *PreambleData, ParseInput,
@@ -661,7 +661,7 @@ void ClangdServer::codeAction(const CodeActionInputs 
,
 return true;
   return llvm::any_of(Only, 

[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/6] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/6] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/6] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[clang] [Clang][CodeGen] Fix crash when using bool vector in compound assignment (PR #75435)

2023-12-13 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-codegen

Author: Chenyang Gao (cygao90)


Changes

Fixes: #72468.
The left side bool vector did not perform a specific 
conversion(`CodeGenFunction::emitBoolVecConversion`) in compound assignment

---
Full diff: https://github.com/llvm/llvm-project/pull/75435.diff


3 Files Affected:

- (modified) clang/lib/CodeGen/CGExpr.cpp (+9-4) 
- (added) clang/test/CodeGen/gh72468.c (+9) 
- (modified) clang/test/SemaCXX/vector-bool.cpp (+4-4) 


``diff
diff --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index ed9aaa28c25733..5a024761d83e3c 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -2085,10 +2085,15 @@ RValue CodeGenFunction::EmitLoadOfLValue(LValue LV, 
SourceLocation Loc) {
   }
 
   if (LV.isVectorElt()) {
-llvm::LoadInst *Load = Builder.CreateLoad(LV.getVectorAddress(),
-  LV.isVolatileQualified());
-return RValue::get(Builder.CreateExtractElement(Load, LV.getVectorIdx(),
-"vecext"));
+llvm::Value *Load = nullptr;
+if (LV.getType()->isExtVectorBoolType())
+  Load = EmitLoadOfScalar(LV.getVectorAddress(), LV.isVolatileQualified(),
+  LV.getType(), Loc);
+else
+  Load =
+  Builder.CreateLoad(LV.getVectorAddress(), LV.isVolatileQualified());
+return RValue::get(
+Builder.CreateExtractElement(Load, LV.getVectorIdx(), "vecext"));
   }
 
   // If this is a reference to a subset of the elements of a vector, either
diff --git a/clang/test/CodeGen/gh72468.c b/clang/test/CodeGen/gh72468.c
new file mode 100644
index 00..7a602d4982803e
--- /dev/null
+++ b/clang/test/CodeGen/gh72468.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -S -emit-llvm -o - %s
+
+typedef __attribute__((__ext_vector_type__(4))) _Bool BoolVector;
+
+BoolVector vec;
+
+void f(int i, int j) {
+  vec[i] |= vec[j];
+}
\ No newline at end of file
diff --git a/clang/test/SemaCXX/vector-bool.cpp 
b/clang/test/SemaCXX/vector-bool.cpp
index e99d420e73fab2..5ec87beb4ed055 100644
--- a/clang/test/SemaCXX/vector-bool.cpp
+++ b/clang/test/SemaCXX/vector-bool.cpp
@@ -38,10 +38,10 @@ void Operations() {
   // (void)(eight_bools > other_eight_bools);
   // (void)(eight_bools >= other_eight_bools);
 
-  // // Legal assignments
-  // (void)(eight_bools |= other_eight_bools);
-  // (void)(eight_bools &= other_eight_bools);
-  // (void)(eight_bools ^= other_eight_bools);
+  // Legal assignments
+  (void)(eight_bools |= other_eight_bools);
+  (void)(eight_bools &= other_eight_bools);
+  (void)(eight_bools ^= other_eight_bools);
 
   // Illegal operators
   (void)(eight_bools || other_eight_bools); // expected-error@47 {{invalid 
operands to binary expression ('EightBools' (vector of 8 'bool' values) and 
'EightBools')}}

``




https://github.com/llvm/llvm-project/pull/75435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][CodeGen] Fix crash when using bool vector in compound assignment (PR #75435)

2023-12-13 Thread via cfe-commits

github-actions[bot] wrote:

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

https://github.com/llvm/llvm-project/pull/75435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][CodeGen] Fix crash when using bool vector in compound assignment (PR #75435)

2023-12-13 Thread Chenyang Gao via cfe-commits

https://github.com/cygao90 created 
https://github.com/llvm/llvm-project/pull/75435

Fixes: #72468.
The left side bool vector did not perform a specific 
conversion(`CodeGenFunction::emitBoolVecConversion`) in compound assignment

>From 04e97b13e274a10bf199cc143c758d6d3889db31 Mon Sep 17 00:00:00 2001
From: Chenyang Gao 
Date: Thu, 14 Dec 2023 15:16:30 +0800
Subject: [PATCH] [Clang][CodeGen] Fix crash when using bool vector in compound
 assignment

---
 clang/lib/CodeGen/CGExpr.cpp   | 13 +
 clang/test/CodeGen/gh72468.c   |  9 +
 clang/test/SemaCXX/vector-bool.cpp |  8 
 3 files changed, 22 insertions(+), 8 deletions(-)
 create mode 100644 clang/test/CodeGen/gh72468.c

diff --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index ed9aaa28c25733..5a024761d83e3c 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -2085,10 +2085,15 @@ RValue CodeGenFunction::EmitLoadOfLValue(LValue LV, 
SourceLocation Loc) {
   }
 
   if (LV.isVectorElt()) {
-llvm::LoadInst *Load = Builder.CreateLoad(LV.getVectorAddress(),
-  LV.isVolatileQualified());
-return RValue::get(Builder.CreateExtractElement(Load, LV.getVectorIdx(),
-"vecext"));
+llvm::Value *Load = nullptr;
+if (LV.getType()->isExtVectorBoolType())
+  Load = EmitLoadOfScalar(LV.getVectorAddress(), LV.isVolatileQualified(),
+  LV.getType(), Loc);
+else
+  Load =
+  Builder.CreateLoad(LV.getVectorAddress(), LV.isVolatileQualified());
+return RValue::get(
+Builder.CreateExtractElement(Load, LV.getVectorIdx(), "vecext"));
   }
 
   // If this is a reference to a subset of the elements of a vector, either
diff --git a/clang/test/CodeGen/gh72468.c b/clang/test/CodeGen/gh72468.c
new file mode 100644
index 00..7a602d4982803e
--- /dev/null
+++ b/clang/test/CodeGen/gh72468.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -S -emit-llvm -o - %s
+
+typedef __attribute__((__ext_vector_type__(4))) _Bool BoolVector;
+
+BoolVector vec;
+
+void f(int i, int j) {
+  vec[i] |= vec[j];
+}
\ No newline at end of file
diff --git a/clang/test/SemaCXX/vector-bool.cpp 
b/clang/test/SemaCXX/vector-bool.cpp
index e99d420e73fab2..5ec87beb4ed055 100644
--- a/clang/test/SemaCXX/vector-bool.cpp
+++ b/clang/test/SemaCXX/vector-bool.cpp
@@ -38,10 +38,10 @@ void Operations() {
   // (void)(eight_bools > other_eight_bools);
   // (void)(eight_bools >= other_eight_bools);
 
-  // // Legal assignments
-  // (void)(eight_bools |= other_eight_bools);
-  // (void)(eight_bools &= other_eight_bools);
-  // (void)(eight_bools ^= other_eight_bools);
+  // Legal assignments
+  (void)(eight_bools |= other_eight_bools);
+  (void)(eight_bools &= other_eight_bools);
+  (void)(eight_bools ^= other_eight_bools);
 
   // Illegal operators
   (void)(eight_bools || other_eight_bools); // expected-error@47 {{invalid 
operands to binary expression ('EightBools' (vector of 8 'bool' values) and 
'EightBools')}}

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


[clang] [clang][ASTImporter] Fix import of variable template redeclarations. (PR #72841)

2023-12-13 Thread Qizhi Hu via cfe-commits
=?utf-8?q?Balázs_Kéri?= ,
=?utf-8?q?Balázs_Kéri?= 
Message-ID:
In-Reply-To: 



@@ -5050,6 +5050,59 @@ TEST_P(ImportFriendClasses, RecordVarTemplateDecl) {
   EXPECT_EQ(ToTUX, ToX);
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, VarTemplateDeclConflict) {
+  getToTuDecl(
+  R"(
+  template 
+  constexpr int X = 1;
+  )",
+  Lang_CXX14);
+
+  Decl *FromTU = getTuDecl(
+  R"(
+  template 
+  constexpr int X = 2;
+  )",
+  Lang_CXX14, "input1.cc");
+  auto *FromX = FirstDeclMatcher().match(
+  FromTU, varTemplateDecl(hasName("X")));
+  auto *ToX = Import(FromX, Lang_CXX11);
+  // FIXME: This import should fail.
+  EXPECT_TRUE(ToX);

jcsxky wrote:

If import `X` should fail, What about this case in 
`ASTImporterGenericRedeclTest.cpp`
```cpp
struct VariableTemplate {
  using DeclTy = VarTemplateDecl;
  static constexpr auto *Prototype = "template  extern T X;";
  static constexpr auto *Definition =
  R"(
  template  T X;
  template <> int X;
  )";
  // There is no matcher for varTemplateDecl so use a work-around.
  BindableMatcher getPattern() {
return namedDecl(hasName("X"), unless(isImplicit()),
 has(templateTypeParmDecl()));
  }
};
```
Storage of `X` in `Prototype` and `Definition` is different, it should fail 
when imported.
I added structural equivalence of `VarTemplateDecl` and makes this import 
failed in `VarTemplateDeclConflict`. is it also need to fix the testcase in 
`ASTImporterGenericRedeclTest.cpp`?
```cpp
static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
 VarTemplateDecl *D1,
 VarTemplateDecl *D2) {
  if (!IsStructurallyEquivalent(Context, D1->getDeclName(), D2->getDeclName()))
return false;

  // Check the templated declaration.
  if (!IsStructurallyEquivalent(Context, D1->getTemplatedDecl(),
D2->getTemplatedDecl()))
return false;

  // Check template parameters.
  return IsStructurallyEquivalent(Context, D1->getTemplateParameters(),
  D2->getTemplateParameters());
}
```

https://github.com/llvm/llvm-project/pull/72841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/5] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/5] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/5] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[clang-tools-extra] 76bbbcb - [clang-tidy] Use StringRef::{starts,ends}_with (NFC)

2023-12-13 Thread Kazu Hirata via cfe-commits

Author: Kazu Hirata
Date: 2023-12-13T23:11:05-08:00
New Revision: 76bbbcb41bcf4a1d7a26bb11b78cf97b60ea7d4b

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

LOG: [clang-tidy] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

Added: 


Modified: 
clang-tools-extra/clang-tidy/ClangTidy.cpp
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
clang-tools-extra/clang-tidy/ExpandModularHeadersPPCallbacks.cpp
clang-tools-extra/clang-tidy/GlobList.cpp
clang-tools-extra/clang-tidy/abseil/AbseilMatcher.h
clang-tools-extra/clang-tidy/abseil/FasterStrsplitDelimiterCheck.cpp
clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
clang-tools-extra/clang-tidy/bugprone/NotNullTerminatedResultCheck.cpp
clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
clang-tools-extra/clang-tidy/google/AvoidCStyleCastsCheck.cpp
clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
clang-tools-extra/clang-tidy/google/UsingNamespaceDirectiveCheck.cpp
clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp
clang-tools-extra/clang-tidy/misc/ConfusableTable/BuildConfusableTable.cpp
clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/clang-tidy/modernize/ReplaceRandomShuffleCheck.cpp
clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
clang-tools-extra/clang-tidy/modernize/UseNodiscardCheck.cpp
clang-tools-extra/clang-tidy/plugin/ClangTidyPlugin.cpp
clang-tools-extra/clang-tidy/portability/SIMDIntrinsicsCheck.cpp
clang-tools-extra/clang-tidy/readability/BracesAroundStatementsCheck.cpp
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
clang-tools-extra/clang-tidy/readability/IsolateDeclarationCheck.cpp
clang-tools-extra/clang-tidy/readability/NamespaceCommentCheck.cpp

clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/clang-tidy/utils/IncludeSorter.cpp
clang-tools-extra/clang-tidy/utils/Matchers.h

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/ClangTidy.cpp 
b/clang-tools-extra/clang-tidy/ClangTidy.cpp
index 565f044778c946..40ac6918faf407 100644
--- a/clang-tools-extra/clang-tidy/ClangTidy.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidy.cpp
@@ -390,7 +390,7 @@ static CheckersList 
getAnalyzerCheckersAndPackages(ClangTidyContext ,
   for (StringRef CheckName : RegisteredCheckers) {
 std::string ClangTidyCheckName((AnalyzerCheckNamePrefix + 
CheckName).str());
 
-if (CheckName.startswith("core") ||
+if (CheckName.starts_with("core") ||
 Context.isCheckEnabled(ClangTidyCheckName)) {
   List.emplace_back(std::string(CheckName), true);
 }
@@ -541,7 +541,7 @@ runClangTidy(clang::tidy::ClangTidyContext ,
 CommandLineArguments AdjustedArgs = Args;
 if (Opts.ExtraArgsBefore) {
   auto I = AdjustedArgs.begin();
-  if (I != AdjustedArgs.end() && !StringRef(*I).startswith("-"))
+  if (I != AdjustedArgs.end() && !StringRef(*I).starts_with("-"))
 ++I; // Skip compiler binary name, if it is there.
   AdjustedArgs.insert(I, Opts.ExtraArgsBefore->begin(),
   Opts.ExtraArgsBefore->end());

diff  --git a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp 
b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
index b19a84f5dc2157..0a80c996de 100644
--- a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -62,7 +62,7 @@ class ClangTidyDiagnosticRenderer : public DiagnosticRenderer 
{
 // appending the check name to the message in ClangTidyContext::diag and
 // using getCustomDiagID.
 std::string CheckNameInMessage = " [" + Error.DiagnosticName + "]";
-if (Message.endswith(CheckNameInMessage))
+if (Message.ends_with(CheckNameInMessage))
   Message = Message.substr(0, Message.size() - CheckNameInMessage.size());
 
 auto TidyMessage =
@@ -457,7 +457,7 @@ bool 
ClangTidyDiagnosticConsumer::passesLineFilter(StringRef FileName,
   

[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/5] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/5] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/5] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[mlir] [llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/4] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/4] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/4] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[llvm] [clang] [RISCV] Add support for experimental Zimop extension (PR #74824)

2023-12-13 Thread Jivan Hakobyan via cfe-commits

https://github.com/JivanH closed https://github.com/llvm/llvm-project/pull/74824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][analyzer] Support `fflush` in the StreamChecker (PR #74296)

2023-12-13 Thread Ben Shi via cfe-commits

https://github.com/benshi001 updated 
https://github.com/llvm/llvm-project/pull/74296

>From fbfe3492b66492948c9b0220af38d59345c5a793 Mon Sep 17 00:00:00 2001
From: Ben Shi 
Date: Mon, 4 Dec 2023 15:51:20 +0800
Subject: [PATCH 1/4] [clang][analyzer] Support `fflush` in the StreamChecker

---
 .../StaticAnalyzer/Checkers/StreamChecker.cpp| 16 
 .../Analysis/Inputs/system-header-simulator.h|  1 +
 clang/test/Analysis/stream-error.c   |  9 +
 3 files changed, 26 insertions(+)

diff --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index 925fc90e355431..2c725c01dc285b 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -266,6 +266,7 @@ class StreamChecker : public CheckerStreamArgNo)
+   ->isNullPointerConstant(C.getASTContext(),
+   Expr::NPC_ValueDependentIsNotNull)) {
+ProgramStateRef State = C.getState();
+if (State = ensureStreamOpened(getStreamArg(Desc, Call), C, State))
+  C.addTransition(State);
+  }
+}
+
 ProgramStateRef
 StreamChecker::ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
CheckerContext ,
diff --git a/clang/test/Analysis/Inputs/system-header-simulator.h 
b/clang/test/Analysis/Inputs/system-header-simulator.h
index 7089bd8bfc9d98..409a969a0d4cce 100644
--- a/clang/test/Analysis/Inputs/system-header-simulator.h
+++ b/clang/test/Analysis/Inputs/system-header-simulator.h
@@ -61,6 +61,7 @@ void clearerr(FILE *stream);
 int feof(FILE *stream);
 int ferror(FILE *stream);
 int fileno(FILE *stream);
+int fflush(FILE *stream);
 
 size_t strlen(const char *);
 
diff --git a/clang/test/Analysis/stream-error.c 
b/clang/test/Analysis/stream-error.c
index c8332bcbfa8ca7..aa5b6be851773a 100644
--- a/clang/test/Analysis/stream-error.c
+++ b/clang/test/Analysis/stream-error.c
@@ -299,6 +299,15 @@ void error_fseek_0(void) {
   fclose(F);
 }
 
+void error_fflush(void) {
+  FILE *F = tmpfile();
+  if (!F)
+return;
+  fclose(F);
+  fflush(F);// expected-warning {{Stream might be already closed}}
+  fflush(NULL); // no-warning
+}
+
 void error_indeterminate(void) {
   FILE *F = fopen("file", "r+");
   if (!F)

>From fab80da9cf06bd0fa73dfdca1d4f2ed23ad060ba Mon Sep 17 00:00:00 2001
From: Ben Shi 
Date: Wed, 6 Dec 2023 15:47:35 +0800
Subject: [PATCH 2/4] [clang][analyzer] Support `fflush` in the StreamChecker

---
 .../StaticAnalyzer/Checkers/StreamChecker.cpp | 49 ---
 clang/test/Analysis/stream-error.c| 12 +++--
 2 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index 2c725c01dc285b..a368619fd37d22 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -266,7 +266,8 @@ class StreamChecker : public CheckerStreamArgNo)
-   ->isNullPointerConstant(C.getASTContext(),
-   Expr::NPC_ValueDependentIsNotNull)) {
-ProgramStateRef State = C.getState();
-if (State = ensureStreamOpened(getStreamArg(Desc, Call), C, State))
+  ProgramStateRef State = C.getState();
+  SVal StreamVal = getStreamArg(Desc, Call);
+  std::optional Stream = StreamVal.getAs();
+  if (!Stream)
+return;
+
+  ConstraintManager::ProgramStatePair SP =
+  C.getConstraintManager().assumeDual(State, *Stream);
+  if (State = SP.first)
+if (State = ensureStreamOpened(StreamVal, C, State))
   C.addTransition(State);
+}
+
+void StreamChecker::evalFflush(const FnDescription *Desc, const CallEvent 
,
+   CheckerContext ) const {
+  ProgramStateRef State = C.getState();
+
+  // We will check the result even if the input is `NULL`,
+  // but do nothing if the input state is unknown.
+  SymbolRef StreamSym = getStreamArg(Desc, Call).getAsSymbol();
+  if (StreamSym) {
+const StreamState *OldSS = State->get(StreamSym);
+if (!OldSS)
+  return;
+assertStreamStateOpened(OldSS);
   }
+
+  const CallExpr *CE = dyn_cast_or_null(Call.getOriginExpr());
+  if (!CE)
+return;
+
+  // `fflush` returns 0 on success, otherwise returns EOF.
+  ProgramStateRef StateNotFailed = bindInt(0, State, C, CE);
+  ProgramStateRef StateFailed = bindInt(*EofVal, State, C, CE);
+
+  // This function does not affect the stream state.
+  // Still we add success and failure state with the appropriate return value.
+  C.addTransition(StateNotFailed);
+  C.addTransition(StateFailed);
 }
 
 ProgramStateRef
diff --git a/clang/test/Analysis/stream-error.c 
b/clang/test/Analysis/stream-error.c
index aa5b6be851773a..94787874cf8396 100644
--- a/clang/test/Analysis/stream-error.c
+++ b/clang/test/Analysis/stream-error.c
@@ -301,11 +301,17 @@ void error_fseek_0(void) {
 
 void error_fflush(void) {

[clang] [compiler-rt] [llvm] [clang-tools-extra] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

2023-12-13 Thread Mingming Liu via cfe-commits

https://github.com/minglotus-6 edited 
https://github.com/llvm/llvm-project/pull/74008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][ASTImporter] skip TemplateTypeParmDecl in VisitTypeAliasTemplateDecl (PR #74919)

2023-12-13 Thread Qizhi Hu via cfe-commits

jcsxky wrote:

> The `VisitTypeAliasTemplateDecl` function should be re-designed to check for 
> structural equivalence at import. The following test does not pass because an 
> existing `TypeAliasTemplateDecl` declaration with the same name is always 
> found and returned, without check for structural equivalence.
> 
> ```
> TEST_P(ASTImporterOptionSpecificTestBase, ImportTypeAliasTemplateDecl1) {
>   const char *ToCode =
>   R"(
>   struct S;
>   template 
>   using Callable = S;
>   )";
>   const char *Code =
>   R"(
>   struct S;
>   template 
>   using Callable = S;
>   )";
>   Decl *ToTU = getToTuDecl(ToCode, Lang_CXX17);
>   Decl *FromTU = getTuDecl(Code, Lang_CXX17);
> 
>   auto *FromCallable = FirstDeclMatcher().match(
>   FromTU, typeAliasTemplateDecl(hasName("Callable")));
> 
>   auto *ToCallable = FirstDeclMatcher().match(
>   ToTU, typeAliasTemplateDecl(hasName("Callable")));
> 
>   auto *ImportedCallable = Import(FromCallable, Lang_CXX17);
>   EXPECT_TRUE(ImportedCallable);
>   EXPECT_NE(ImportedCallable, ToCallable);
> }
> ```
> 
> Additionally I discovered that import of `ClassTemplateDecl` is not correct 
> too: If there is an object with the same name that is not a 
> `ClassTemplateDecl`, it is just ignored at import. This is not correct, the 
> existing object may cause name conflict (for example it can be a non-template 
> `RecordDecl`). (I found this when checking the questions in my last comment.) 
> This is an independent problem but should be fixed.


Is import of `Callable` should be failed? I compiled this code
```cpp
struct S;
template 
using Callable = S;
template 
using Callable = S;
```
and clang report an error.

https://github.com/llvm/llvm-project/pull/74919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][ASTImporter] skip TemplateTypeParmDecl in VisitTypeAliasTemplateDecl (PR #74919)

2023-12-13 Thread Qizhi Hu via cfe-commits

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/74919

>From a2dcc7f471237e78f374c204216c6574059aa950 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sat, 9 Dec 2023 12:00:02 +0800
Subject: [PATCH] [clang][ASTImporter] skip TemplateTypeParmDecl in
 VisitTypeAliasTemplateDecl

---
 clang/lib/AST/ASTImporter.cpp  |  9 +++--
 clang/lib/AST/ASTStructuralEquivalence.cpp | 16 
 clang/unittests/AST/ASTImporterTest.cpp| 47 ++
 3 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index f1f335118f37a4..270574a7704505 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -2771,9 +2771,11 @@ 
ASTNodeImporter::VisitTypeAliasTemplateDecl(TypeAliasTemplateDecl *D) {
 for (auto *FoundDecl : FoundDecls) {
   if (!FoundDecl->isInIdentifierNamespace(IDNS))
 continue;
-  if (auto *FoundAlias = dyn_cast(FoundDecl))
-return Importer.MapImported(D, FoundAlias);
-  ConflictingDecls.push_back(FoundDecl);
+  if (auto *FoundAlias = dyn_cast(FoundDecl)) {
+if (IsStructuralMatch(D, FoundAlias))
+  return Importer.MapImported(D, FoundAlias);
+ConflictingDecls.push_back(FoundDecl);
+  }
 }
 
 if (!ConflictingDecls.empty()) {
@@ -9391,7 +9393,6 @@ Expected ASTImporter::Import(Decl *FromD) {
 setImportDeclError(FromD, *Error);
 return make_error(*Error);
   }
-
   // Make sure that ImportImpl registered the imported decl.
   assert(ImportedDecls.count(FromD) != 0 && "Missing call to MapImported?");
   if (auto Error = ImportAttrs(ToD, FromD))
diff --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index 6bb4bf14b873d7..ae55ff7811e794 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1977,6 +1977,22 @@ static bool 
IsStructurallyEquivalent(StructuralEquivalenceContext ,
   D2->getTemplatedDecl()->getType());
 }
 
+static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
+ TypeAliasTemplateDecl *D1,
+ TypeAliasTemplateDecl *D2) {
+  if (!IsStructurallyEquivalent(Context, D1->getDeclName(), D2->getDeclName()))
+return false;
+
+  // Check the templated declaration.
+  if (!IsStructurallyEquivalent(Context, D1->getTemplatedDecl(),
+D2->getTemplatedDecl()))
+return false;
+
+  // Check template parameters.
+  return IsStructurallyEquivalent(Context, D1->getTemplateParameters(),
+  D2->getTemplateParameters());
+}
+
 static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
  ConceptDecl *D1,
  ConceptDecl *D2) {
diff --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 4dd7510bf8ddf8..2328e98a663810 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9284,6 +9284,53 @@ TEST_P(ASTImporterOptionSpecificTestBase,
   // EXPECT_EQ(ToF1Imported->getPreviousDecl(), ToF1);
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportTypeAliasTemplateAfterSimilarCalledTemplateTypeParm) {
+  const char *Code =
+  R"(
+  struct S;
+  template 
+  using Callable = S;
+  template 
+  int bindingFunctionVTable;
+  )";
+  Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+  auto *FromCallable = FirstDeclMatcher().match(
+  FromTU, typeAliasTemplateDecl(hasName("Callable")));
+
+  auto *FromCallableParm = FirstDeclMatcher().match(
+  FromTU, templateTypeParmDecl(hasName("Callable")));
+
+  auto *ToFromCallableParm = Import(FromCallableParm, Lang_CXX17);
+  auto *ToCallable = Import(FromCallable, Lang_CXX17);
+  EXPECT_TRUE(ToFromCallableParm);
+  EXPECT_TRUE(ToCallable);
+}
+
+TEST_P(ASTImporterOptionSpecificTestBase, ImportConflictTypeAliasTemplate) {
+  const char *ToCode =
+  R"(
+  struct S;
+  template 
+  using Callable = S;
+  )";
+  const char *Code =
+  R"(
+  struct S;
+  template 
+  using Callable = S;
+  )";
+  (void)getToTuDecl(ToCode, Lang_CXX17);
+  Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+  auto *FromCallable = FirstDeclMatcher().match(
+  FromTU, typeAliasTemplateDecl(hasName("Callable")));
+
+  auto *ImportedCallable = Import(FromCallable, Lang_CXX17);
+  EXPECT_FALSE(ImportedCallable);
+}
+
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ASTImporterLookupTableTest,
  DefaultTestValuesForRunOptions);
 

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


[clang] [clang][ASTImporter] skip TemplateTypeParmDecl in VisitTypeAliasTemplateDecl (PR #74919)

2023-12-13 Thread Qizhi Hu via cfe-commits

https://github.com/jcsxky updated 
https://github.com/llvm/llvm-project/pull/74919

>From e4e981ed4f545f3dd4cc709bab30468a8ceb3962 Mon Sep 17 00:00:00 2001
From: huqizhi 
Date: Sat, 9 Dec 2023 12:00:02 +0800
Subject: [PATCH] [clang][ASTImporter] skip TemplateTypeParmDecl in
 VisitTypeAliasTemplateDecl

---
 clang/lib/AST/ASTImporter.cpp  | 16 ---
 clang/lib/AST/ASTStructuralEquivalence.cpp | 16 +++
 clang/unittests/AST/ASTImporterTest.cpp| 50 ++
 3 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index f1f335118f37a4..40e5ac6ecb13e4 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -2771,9 +2771,12 @@ 
ASTNodeImporter::VisitTypeAliasTemplateDecl(TypeAliasTemplateDecl *D) {
 for (auto *FoundDecl : FoundDecls) {
   if (!FoundDecl->isInIdentifierNamespace(IDNS))
 continue;
-  if (auto *FoundAlias = dyn_cast(FoundDecl))
-return Importer.MapImported(D, FoundAlias);
-  ConflictingDecls.push_back(FoundDecl);
+  if (auto *FoundAlias = dyn_cast(FoundDecl)) {
+// if (IsStructuralMatch(D,FoundAlias)) 
+  return Importer.MapImported(D, FoundAlias);
+
+ConflictingDecls.push_back(FoundDecl);
+  }
 }
 
 if (!ConflictingDecls.empty()) {
@@ -9073,7 +9076,6 @@ class AttrImporter {
 
 ToAttr = FromAttr->clone(Importer.getToContext());
 ToAttr->setRange(ToRange);
-ToAttr->setAttrName(Importer.Import(FromAttr->getAttrName()));
   }
 
   // Get the result of the previous import attempt (can be used only once).
@@ -9223,6 +9225,11 @@ Expected ASTImporter::Import(const Attr 
*FromAttr) {
 AI.castAttrAs()->setCountedByFieldLoc(SR.get());
 break;
   }
+  case attr::AlignValue:{
+auto *From = cast(FromAttr);
+AI.importAttr(From,AI.importArg(From->getAlignment()).value());
+break;
+  }
 
   default: {
 // The default branch works for attributes that have no arguments to 
import.
@@ -9391,7 +9398,6 @@ Expected ASTImporter::Import(Decl *FromD) {
 setImportDeclError(FromD, *Error);
 return make_error(*Error);
   }
-
   // Make sure that ImportImpl registered the imported decl.
   assert(ImportedDecls.count(FromD) != 0 && "Missing call to MapImported?");
   if (auto Error = ImportAttrs(ToD, FromD))
diff --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index 6bb4bf14b873d7..5d6c3f35e50832 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1977,6 +1977,22 @@ static bool 
IsStructurallyEquivalent(StructuralEquivalenceContext ,
   D2->getTemplatedDecl()->getType());
 }
 
+// static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
+//  TypeAliasTemplateDecl *D1,
+//  TypeAliasTemplateDecl *D2) {
+//   if (!IsStructurallyEquivalent(Context, D1->getDeclName(), 
D2->getDeclName()))
+// return false;
+
+//   // Check the templated declaration.
+//   if (!IsStructurallyEquivalent(Context, D1->getTemplatedDecl(),
+// D2->getTemplatedDecl()))
+// return false;
+
+//   // Check template parameters.
+//   return IsStructurallyEquivalent(Context, D1->getTemplateParameters(),
+//   D2->getTemplateParameters());
+// }
+
 static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
  ConceptDecl *D1,
  ConceptDecl *D2) {
diff --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 4dd7510bf8ddf8..454a4d42d77520 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -9284,6 +9284,56 @@ TEST_P(ASTImporterOptionSpecificTestBase,
   // EXPECT_EQ(ToF1Imported->getPreviousDecl(), ToF1);
 }
 
+// TEST_P(ASTImporterOptionSpecificTestBase, ImportTypeAliasTemplateDecl) {
+//   const char *Code =
+//   R"(
+//   struct S;
+//   template 
+//   using Callable = S;
+//   template 
+//   int bindingFunctionVTable;
+//   )";
+//   Decl *FromTU = getTuDecl(Code, Lang_CXX17);
+
+//   auto *FromCallable1 = FirstDeclMatcher().match(
+//   FromTU, typeAliasTemplateDecl(hasName("Callable")));
+
+//   auto *FromCallable2 = FirstDeclMatcher().match(
+//   FromTU, templateTypeParmDecl(hasName("Callable")));
+
+//   auto *ToCallable2 = Import(FromCallable2, Lang_CXX17);
+//   auto *ToCallable1 = Import(FromCallable1, Lang_CXX17);
+//   EXPECT_TRUE(ToCallable1);
+//   EXPECT_TRUE(ToCallable2);
+// }
+
+// TEST_P(ASTImporterOptionSpecificTestBase, X) {
+//   const char *CodeFrom1 =
+//   R"(
+//   template 
+//   bool A = A;
+//   )";
+//   const char *CodeFrom2 =
+//   R"(
+//   template 
+//   

[clang-tools-extra] [compiler-rt] [clang] [llvm] [PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. (PR #74008)

2023-12-13 Thread Mingming Liu via cfe-commits

minglotus-6 wrote:

> Resolved comments except the pending discussion about whether to use 
> `.proftext` or`.profraw`.
> 
> Added `REQUIRES: zlib` for LLVM IR test since the profile reader should be 
> built with zlib support.
> 
> I'll probably spend sometime to get this test running on my laptop (haven't 
> tried to build llvm on mac before), while waiting for more feedbacks. I'm 
> thinking of submitting it on Thursday or Friday. @ellishg I think the added 
> compiler-rt test (on macosx) should be a test case for issue 74565.

The test failed on mac, but initially on trying to find `dso_local` of line 
`PGOName: define dso_local void @_Z7callee1v() {{.*}} !prof ![[#]] !PGOFuncName 
![[#]] `.
-  Debugging with `lldb` points to [this 
comment](https://github.com/llvm/llvm-project/blob/4f1ddf7523c0bbb4075b1682dbe2278080642eee/clang/lib/CodeGen/CodeGenModule.cpp#L1528),
 saying only COFF and ELF assumes `dso_local`. 

After making the `dso_local` optional in the [latest 
commit](https://github.com/llvm/llvm-project/pull/74008/commits/f6a718d80d7a70d60ef8affc282f525e8282),
 the test started to fail due to the difference of `` and 
``. 
1. Test failed, when external func `callee1` in expected output doesn't have 
`!PGOFuncName` metadata but the test output has it. Note `!PGOFuncName` is 
annotated [only 
if](https://github.com/llvm/llvm-project/blob/90c23981768713736208d76578ca119a20f6ac60/llvm/lib/ProfileData/InstrProf.cpp#L1262-1265)
 `PGOName != Func.getName()`
2. Fixing the first error allows me to see the missed import errors.

https://github.com/llvm/llvm-project/pull/74008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [compiler-rt] [InstrProf] Single byte counters in coverage (PR #75425)

2023-12-13 Thread via cfe-commits

https://github.com/gulfemsavrun edited 
https://github.com/llvm/llvm-project/pull/75425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Michael Spencer via cfe-commits

https://github.com/Bigcheese approved this pull request.


https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[compiler-rt] [llvm] [clang] [InstrProf] Single byte counters in coverage (PR #75425)

2023-12-13 Thread via cfe-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 9d02770832ea6b32235865e9ac03fb177d8daba1 
ae8413b299b1606ce9b806f3617bfa5cf8aec1a7 -- 
clang/test/CoverageMapping/single-byte-counters.cpp 
clang/lib/CodeGen/CGExprAgg.cpp clang/lib/CodeGen/CGExprComplex.cpp 
clang/lib/CodeGen/CGExprScalar.cpp clang/lib/CodeGen/CGStmt.cpp 
clang/lib/CodeGen/CodeGenFunction.cpp clang/lib/CodeGen/CodeGenFunction.h 
clang/lib/CodeGen/CodeGenModule.cpp clang/lib/CodeGen/CodeGenPGO.cpp 
clang/lib/CodeGen/CodeGenPGO.h clang/lib/CodeGen/CoverageMappingGen.cpp 
compiler-rt/lib/profile/InstrProfiling.h 
llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h 
llvm/include/llvm/ProfileData/InstrProf.h 
llvm/include/llvm/ProfileData/InstrProfWriter.h 
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp 
llvm/lib/ProfileData/InstrProf.cpp llvm/lib/ProfileData/InstrProfWriter.cpp
``





View the diff from clang-format here.


``diff
diff --git a/compiler-rt/lib/profile/InstrProfiling.h 
b/compiler-rt/lib/profile/InstrProfiling.h
index f5bb648282..846a399d36 100644
--- a/compiler-rt/lib/profile/InstrProfiling.h
+++ b/compiler-rt/lib/profile/InstrProfiling.h
@@ -333,7 +333,8 @@ COMPILER_RT_VISIBILITY extern int 
INSTR_PROF_PROFILE_RUNTIME_VAR;
  * variable is defined as weak so that compiler can emit an overriding
  * definition depending on user option.
  */
-COMPILER_RT_VISIBILITY extern uint64_t INSTR_PROF_RAW_VERSION_VAR; /* 
__llvm_profile_raw_version */
+COMPILER_RT_VISIBILITY extern uint64_t
+INSTR_PROF_RAW_VERSION_VAR; /* __llvm_profile_raw_version */
 
 /*!
  * This variable is a weak symbol defined in InstrProfiling.c. It allows

``




https://github.com/llvm/llvm-project/pull/75425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[compiler-rt] [llvm] [clang] [InstrProf] Single byte counters in coverage (PR #75425)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang-codegen

Author: None (gulfemsavrun)


Changes

This patch inserts 1-byte counters instead of an 8-byte counters into llvm 
profiles for source-based code coverage. The origial idea was proposed as 
block-cov for PGO, and this patch repurposes that idea for coverage: 
https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The current 8-byte counters mechanism add counters to minimal regions, and 
infer the counters in the remaining regions via adding or subtracting counters. 
For example, it infers the counter in the if.else region by subtracting the 
counters between if.entry and if.then regions in an if statement. Whenever 
there is a control-flow merge, it adds the counters from all the incoming 
regions. However, we are not going to be
able to infer counters by subtracting two execution counts when using 
single-byte counters. Therefore, this patch conservatively inserts additional
counters for the cases where we need to add or subtract counters.

---

Patch is 56.62 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/75425.diff


18 Files Affected:

- (modified) clang/lib/CodeGen/CGExprAgg.cpp (+12-1) 
- (modified) clang/lib/CodeGen/CGExprComplex.cpp (+13-1) 
- (modified) clang/lib/CodeGen/CGExprScalar.cpp (+29-3) 
- (modified) clang/lib/CodeGen/CGStmt.cpp (+68-5) 
- (modified) clang/lib/CodeGen/CodeGenFunction.cpp (+8-1) 
- (modified) clang/lib/CodeGen/CodeGenFunction.h (+1-1) 
- (modified) clang/lib/CodeGen/CodeGenModule.cpp (+1) 
- (modified) clang/lib/CodeGen/CodeGenPGO.cpp (+133-12) 
- (modified) clang/lib/CodeGen/CodeGenPGO.h (+4-2) 
- (modified) clang/lib/CodeGen/CoverageMappingGen.cpp (+152-54) 
- (added) clang/test/CoverageMapping/single-byte-counters.cpp (+169) 
- (modified) compiler-rt/lib/profile/InstrProfiling.h (+1-1) 
- (modified) llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h (+13-7) 
- (modified) llvm/include/llvm/ProfileData/InstrProf.h (+2-1) 
- (modified) llvm/include/llvm/ProfileData/InstrProfWriter.h (+4) 
- (modified) llvm/lib/ProfileData/Coverage/CoverageMapping.cpp (+10-3) 
- (modified) llvm/lib/ProfileData/InstrProf.cpp (+17-8) 
- (modified) llvm/lib/ProfileData/InstrProfWriter.cpp (+1-1) 


``diff
diff --git a/clang/lib/CodeGen/CGExprAgg.cpp b/clang/lib/CodeGen/CGExprAgg.cpp
index 810b28f25fa18b..d794afa66c2153 100644
--- a/clang/lib/CodeGen/CGExprAgg.cpp
+++ b/clang/lib/CodeGen/CGExprAgg.cpp
@@ -33,6 +33,10 @@ using namespace CodeGen;
 //Aggregate Expression Emitter
 
//===--===//
 
+namespace llvm {
+extern cl::opt EnableSingleByteCoverage;
+} // namespace llvm
+
 namespace  {
 class AggExprEmitter : public StmtVisitor {
   CodeGenFunction 
@@ -1275,7 +1279,10 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(LHSBlock);
-  CGF.incrementProfileCounter(E);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E->getTrueExpr());
+  else
+CGF.incrementProfileCounter(E);
   Visit(E->getTrueExpr());
   eval.end(CGF);
 
@@ -1290,6 +1297,8 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(RHSBlock);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E->getFalseExpr());
   Visit(E->getFalseExpr());
   eval.end(CGF);
 
@@ -1298,6 +1307,8 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 E->getType());
 
   CGF.EmitBlock(ContBlock);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E);
 }
 
 void AggExprEmitter::VisitChooseExpr(const ChooseExpr *CE) {
diff --git a/clang/lib/CodeGen/CGExprComplex.cpp 
b/clang/lib/CodeGen/CGExprComplex.cpp
index e532794b71bdb4..d1d66089280fbe 100644
--- a/clang/lib/CodeGen/CGExprComplex.cpp
+++ b/clang/lib/CodeGen/CGExprComplex.cpp
@@ -28,6 +28,10 @@ using namespace CodeGen;
 //Complex Expression Emitter
 
//===--===//
 
+namespace llvm {
+extern cl::opt EnableSingleByteCoverage;
+} // namespace llvm
+
 typedef CodeGenFunction::ComplexPairTy ComplexPairTy;
 
 /// Return the complex type that we are meant to emit.
@@ -1319,7 +1323,11 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(LHSBlock);
-  CGF.incrementProfileCounter(E);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E->getTrueExpr());
+  else
+CGF.incrementProfileCounter(E);
+
   ComplexPairTy LHS = Visit(E->getTrueExpr());
   LHSBlock = Builder.GetInsertBlock();
   CGF.EmitBranch(ContBlock);
@@ -1327,9 +1335,13 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(RHSBlock);
+  if (llvm::EnableSingleByteCoverage)
+

[compiler-rt] [llvm] [clang] [InstrProf] Single byte counters in coverage (PR #75425)

2023-12-13 Thread via cfe-commits

https://github.com/gulfemsavrun created 
https://github.com/llvm/llvm-project/pull/75425

This patch inserts 1-byte counters instead of an 8-byte counters into llvm 
profiles for source-based code coverage. The origial idea was proposed as 
block-cov for PGO, and this patch repurposes that idea for coverage: 
https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The current 8-byte counters mechanism add counters to minimal regions, and 
infer the counters in the remaining regions via adding or subtracting counters. 
For example, it infers the counter in the if.else region by subtracting the 
counters between if.entry and if.then regions in an if statement. Whenever 
there is a control-flow merge, it adds the counters from all the incoming 
regions. However, we are not going to be
able to infer counters by subtracting two execution counts when using 
single-byte counters. Therefore, this patch conservatively inserts additional
counters for the cases where we need to add or subtract counters.

>From ae8413b299b1606ce9b806f3617bfa5cf8aec1a7 Mon Sep 17 00:00:00 2001
From: Gulfem Savrun Yeniceri 
Date: Thu, 14 Dec 2023 03:40:57 +
Subject: [PATCH] [InstrProf] Single byte counters in coverage

This patch inserts 1-byte counters instead of an 8-byte counters
into llvm profiles for source-based code coverage. The origial idea
was proposed as block-cov for PGO, and this patch repurposes that
idea for coverage: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The current 8-byte counters mechanism add counters to minimal regions,
and infer the counters in the remaining regions via adding or
subtracting counters. For example, it infers the counter in the if.else
region by subtracting the counters between if.entry and if.then regions
in an if statement. Whenever there is a control-flow merge, it adds
the counters from all the incoming regions. However, we are not going to
be
able to infer counters by subtracting two execution counts when using
single-byte counters. Therefore, this patch conservatively inserts
additional
counters for the cases where we need to add or subtract counters.
---
 clang/lib/CodeGen/CGExprAgg.cpp   |  13 +-
 clang/lib/CodeGen/CGExprComplex.cpp   |  14 +-
 clang/lib/CodeGen/CGExprScalar.cpp|  32 ++-
 clang/lib/CodeGen/CGStmt.cpp  |  73 ++-
 clang/lib/CodeGen/CodeGenFunction.cpp |   9 +-
 clang/lib/CodeGen/CodeGenFunction.h   |   2 +-
 clang/lib/CodeGen/CodeGenModule.cpp   |   1 +
 clang/lib/CodeGen/CodeGenPGO.cpp  | 145 +++-
 clang/lib/CodeGen/CodeGenPGO.h|   6 +-
 clang/lib/CodeGen/CoverageMappingGen.cpp  | 206 +-
 .../CoverageMapping/single-byte-counters.cpp  | 169 ++
 compiler-rt/lib/profile/InstrProfiling.h  |   2 +-
 .../ProfileData/Coverage/CoverageMapping.h|  20 +-
 llvm/include/llvm/ProfileData/InstrProf.h |   3 +-
 .../llvm/ProfileData/InstrProfWriter.h|   4 +
 .../ProfileData/Coverage/CoverageMapping.cpp  |  13 +-
 llvm/lib/ProfileData/InstrProf.cpp|  25 ++-
 llvm/lib/ProfileData/InstrProfWriter.cpp  |   2 +-
 18 files changed, 638 insertions(+), 101 deletions(-)
 create mode 100644 clang/test/CoverageMapping/single-byte-counters.cpp

diff --git a/clang/lib/CodeGen/CGExprAgg.cpp b/clang/lib/CodeGen/CGExprAgg.cpp
index 810b28f25fa18b..d794afa66c2153 100644
--- a/clang/lib/CodeGen/CGExprAgg.cpp
+++ b/clang/lib/CodeGen/CGExprAgg.cpp
@@ -33,6 +33,10 @@ using namespace CodeGen;
 //Aggregate Expression Emitter
 
//===--===//
 
+namespace llvm {
+extern cl::opt EnableSingleByteCoverage;
+} // namespace llvm
+
 namespace  {
 class AggExprEmitter : public StmtVisitor {
   CodeGenFunction 
@@ -1275,7 +1279,10 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(LHSBlock);
-  CGF.incrementProfileCounter(E);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E->getTrueExpr());
+  else
+CGF.incrementProfileCounter(E);
   Visit(E->getTrueExpr());
   eval.end(CGF);
 
@@ -1290,6 +1297,8 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 
   eval.begin(CGF);
   CGF.EmitBlock(RHSBlock);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E->getFalseExpr());
   Visit(E->getFalseExpr());
   eval.end(CGF);
 
@@ -1298,6 +1307,8 @@ VisitAbstractConditionalOperator(const 
AbstractConditionalOperator *E) {
 E->getType());
 
   CGF.EmitBlock(ContBlock);
+  if (llvm::EnableSingleByteCoverage)
+CGF.incrementProfileCounter(E);
 }
 
 void AggExprEmitter::VisitChooseExpr(const ChooseExpr *CE) {
diff --git a/clang/lib/CodeGen/CGExprComplex.cpp 
b/clang/lib/CodeGen/CGExprComplex.cpp
index e532794b71bdb4..d1d66089280fbe 100644
--- a/clang/lib/CodeGen/CGExprComplex.cpp
+++ 

[mlir] [clang-tools-extra] [llvm] [clang] Generalize depthwise conv (PR #75017)

2023-12-13 Thread via cfe-commits

https://github.com/srcarroll edited 
https://github.com/llvm/llvm-project/pull/75017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Parse attribute [[gnu::no_stack_protector]] (PR #75289)

2023-12-13 Thread Yingchi Long via cfe-commits

https://github.com/inclyc closed https://github.com/llvm/llvm-project/pull/75289
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 9d02770 - [clang] Parse attribute [[gnu::no_stack_protector]] (#75289)

2023-12-13 Thread via cfe-commits

Author: Sirui Mu
Date: 2023-12-14T11:31:17+08:00
New Revision: 9d02770832ea6b32235865e9ac03fb177d8daba1

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

LOG: [clang] Parse attribute [[gnu::no_stack_protector]] (#75289)

This commit adds relative TableGen definitions to parse the
`[[gnu::no_stack_protector]]` attribute.

This PR addresses issue #75235.

Added: 
clang/test/Sema/no_stack_protector.cpp

Modified: 
clang/include/clang/Basic/Attr.td
clang/test/Sema/no_stack_protector.c

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index d47a59b3f7ca4f..5943583d92773a 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2212,7 +2212,8 @@ def NotTailCalled : InheritableAttr {
 def : MutualExclusions<[AlwaysInline, NotTailCalled]>;
 
 def NoStackProtector : InheritableAttr {
-  let Spellings = [Clang<"no_stack_protector">, Declspec<"safebuffers">];
+  let Spellings = [Clang<"no_stack_protector">, CXX11<"gnu", 
"no_stack_protector">,
+   C23<"gnu", "no_stack_protector">, Declspec<"safebuffers">];
   let Subjects = SubjectList<[Function]>;
   let Documentation = [NoStackProtectorDocs];
   let SimpleHandler = 1;

diff  --git a/clang/test/Sema/no_stack_protector.c 
b/clang/test/Sema/no_stack_protector.c
index 0007435901e840..1ecd46bc624ceb 100644
--- a/clang/test/Sema/no_stack_protector.c
+++ b/clang/test/Sema/no_stack_protector.c
@@ -1,4 +1,7 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c23 %s
+
+[[gnu::no_stack_protector]] void test1(void) {}
+[[clang::no_stack_protector]] void test2(void) {}
 
 void __attribute__((no_stack_protector)) foo(void) {}
 int __attribute__((no_stack_protector)) var; // expected-warning 
{{'no_stack_protector' attribute only applies to functions}}

diff  --git a/clang/test/Sema/no_stack_protector.cpp 
b/clang/test/Sema/no_stack_protector.cpp
new file mode 100644
index 00..160e3d32a9389a
--- /dev/null
+++ b/clang/test/Sema/no_stack_protector.cpp
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// expected-no-diagnostics
+
+[[gnu::no_stack_protector]] void test1() {}
+[[clang::no_stack_protector]] void test2() {}



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


[clang] [clang] Parse attribute [[gnu::no_stack_protector]] (PR #75289)

2023-12-13 Thread Yingchi Long via cfe-commits

https://github.com/inclyc approved this pull request.


https://github.com/llvm/llvm-project/pull/75289
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [AArch64][SME] Warn when using a streaming builtin from a non-streaming function (PR #74064)

2023-12-13 Thread Nico Weber via cfe-commits

nico wrote:

On my system, this increases the compilation time of SemaChecking.cpp from 7 
seconds to 2 minutes 46 seconds (using clang as a host compiler). That seems 
excessive. Let's please find a way to not make compilation so slow, and let's 
consider reverting this until a faster approach is found.

https://github.com/llvm/llvm-project/pull/74064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] Reapply "InstCombine: Introduce SimplifyDemandedUseFPClass"" (PR #74056)

2023-12-13 Thread Matt Arsenault via cfe-commits

arsenm wrote:

ping

https://github.com/llvm/llvm-project/pull/74056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [WIP][libc++] Add builtin to clear padding bytes (prework for P0528R3) (PR #75371)

2023-12-13 Thread Nikolas Klauser via cfe-commits

philnik777 wrote:

I don't think this should be tagged as libc++, since it doesn't actually touch 
anything of libc++.

https://github.com/llvm/llvm-project/pull/75371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [openmp] [clang] [libcxx] [lldb] [libcxxabi] [clang-tools-extra] [flang] [mlir] [compiler-rt] [MachineCopyPropagation] When the source of PreviousCopy is undef, we cannot replace sub register (

2023-12-13 Thread via cfe-commits

https://github.com/DianQK closed https://github.com/llvm/llvm-project/pull/74682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ef3f476 - [attributes][analyzer] Implement [[clang::suppress]] - suppress static analysis warnings.

2023-12-13 Thread Artem Dergachev via cfe-commits

Author: Artem Dergachev
Date: 2023-12-13T18:09:16-08:00
New Revision: ef3f476097c7a13c0578e331e44b584b706089ed

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

LOG: [attributes][analyzer] Implement [[clang::suppress]] - suppress static 
analysis warnings.

The new attribute can be placed on statements in order to suppress
arbitrary warnings produced by static analysis tools at those statements.

Previously such suppressions were implemented as either informal comments
(eg. clang-tidy `// NOLINT:`) or with preprocessor macros (eg.
clang static analyzer's `#ifdef __clang_analyzer__`). The attribute
provides a universal, formal, flexible and neat-looking suppression mechanism.

Implement support for the new attribute in the clang static analyzer;
clang-tidy coming soon.

The attribute allows specifying which specific warnings to suppress,
in the form of free-form strings that are intended to be specific to
the tools, but currently none are actually supported; so this is also
going to be a future improvement.

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

Added: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugSuppression.h
clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
clang/test/Analysis/suppression-attr-doc.cpp
clang/test/Analysis/suppression-attr.m
clang/test/SemaCXX/attr-suppress.cpp
clang/test/SemaObjC/attr-suppress.m

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaStmtAttr.cpp
clang/lib/StaticAnalyzer/Core/BugReporter.cpp
clang/lib/StaticAnalyzer/Core/CMakeLists.txt
clang/www/analyzer/faq.html

Removed: 
clang/test/SemaCXX/suppress.cpp



diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index c8b17cbe8ab7e7..d47a59b3f7ca4f 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2792,9 +2792,10 @@ def SwiftAsyncError : InheritableAttr {
   let Documentation = [SwiftAsyncErrorDocs];
 }
 
-def Suppress : StmtAttr {
-  let Spellings = [CXX11<"gsl", "suppress">];
+def Suppress : DeclOrStmtAttr {
+  let Spellings = [CXX11<"gsl", "suppress">, Clang<"suppress">];
   let Args = [VariadicStringArgument<"DiagnosticIdentifiers">];
+  let Accessors = [Accessor<"isGSL", [CXX11<"gsl", "suppress">]>];
   let Documentation = [SuppressDocs];
 }
 

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 1a98196834cefc..77950ab6d877ea 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5267,7 +5267,74 @@ the ``int`` parameter is the one that represents the 
error.
 def SuppressDocs : Documentation {
   let Category = DocCatStmt;
   let Content = [{
-The ``[[gsl::suppress]]`` attribute suppresses specific
+The ``suppress`` attribute suppresses unwanted warnings coming from static
+analysis tools such as the Clang Static Analyzer. The tool will not report
+any issues in source code annotated with the attribute.
+
+The attribute cannot be used to suppress traditional Clang warnings, because
+many such warnings are emitted before the attribute is fully parsed.
+Consider using ``#pragma clang diagnostic`` to control such diagnostics,
+as described in `Controlling Diagnostics via Pragmas
+`_.
+
+The ``suppress`` attribute can be placed on an individual statement in order to
+suppress warnings about undesirable behavior occurring at that statement:
+
+.. code-block:: c++
+
+  int foo() {
+int *x = nullptr;
+...
+[[clang::suppress]]
+return *x;  // null pointer dereference warning suppressed here
+  }
+
+Putting the attribute on a compound statement suppresses all warnings in scope:
+
+.. code-block:: c++
+
+  int foo() {
+[[clang::suppress]] {
+  int *x = nullptr;
+  ...
+  return *x;  // warnings suppressed in the entire scope
+}
+  }
+
+Some static analysis warnings are accompanied by one or more notes, and the
+line of code against which the warning is emitted isn't necessarily the best
+for suppression purposes. In such cases the tools are allowed to implement
+additional ways to suppress specific warnings based on the attribute attached
+to a note location.
+
+For example, the Clang Static Analyzer suppresses memory leak warnings when
+the suppression attribute is placed at the allocation site (highlited by
+a "note: memory is allocated"), which may be 
diff erent from the line of code
+at which the program "loses track" of the pointer (where the warning
+is ultimately emitted):
+
+.. code-block:: c
+
+  

[llvm] [clang] [clang-tools-extra] [HLSL] Vector standard conversions (PR #71098)

2023-12-13 Thread Chris B via cfe-commits

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/71098

>From 91e8d9d9f63fe2ac481bb01549e3d69ac59d68f8 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 1 Nov 2023 12:18:43 -0500
Subject: [PATCH 1/7] [HLSL] Vector vector standard conversions

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

../clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hl
sl
../clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl
../clang/test/SemaHLSL/standard_conversion_sequences.hlsl
---
 clang/include/clang/AST/OperationKinds.def|   3 +
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Sema/Overload.h   |  12 +-
 clang/lib/AST/Expr.cpp|   1 +
 clang/lib/AST/ExprConstant.cpp|   2 +
 clang/lib/CodeGen/CGExpr.cpp  |   2 +
 clang/lib/CodeGen/CGExprAgg.cpp   |   2 +
 clang/lib/CodeGen/CGExprComplex.cpp   |   1 +
 clang/lib/CodeGen/CGExprConstant.cpp  |   1 +
 clang/lib/CodeGen/CGExprScalar.cpp|  23 +-
 clang/lib/Edit/RewriteObjCFoundationAPI.cpp   |   4 +
 clang/lib/Sema/SemaChecking.cpp   |  11 +-
 clang/lib/Sema/SemaExprCXX.cpp|  84 ++
 clang/lib/Sema/SemaInit.cpp   |   2 +-
 clang/lib/Sema/SemaOverload.cpp   | 281 +++---
 clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp |   3 +-
 .../standard_conversion_sequences.hlsl| 119 
 .../BuiltIns/vector-constructors-erros.hlsl   |   2 +-
 .../standard_conversion_sequences.hlsl|  92 ++
 19 files changed, 536 insertions(+), 112 deletions(-)
 create mode 100644 
clang/test/CodeGenHLSL/BasicFeatures/standard_conversion_sequences.hlsl
 create mode 100644 clang/test/SemaHLSL/standard_conversion_sequences.hlsl

diff --git a/clang/include/clang/AST/OperationKinds.def 
b/clang/include/clang/AST/OperationKinds.def
index 8dd98730dff742..e497fe4d1f93ff 100644
--- a/clang/include/clang/AST/OperationKinds.def
+++ b/clang/include/clang/AST/OperationKinds.def
@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion)
 // Convert an integer initializer to an OpenCL sampler.
 CAST_OPERATION(IntToOCLSampler)
 
+// Truncate a vector type (HLSL only).
+CAST_OPERATION(VectorTruncation)
+
 //===- Binary Operations  
-===//
 // Operators listed in order of precedence.
 // Note that additions to this should also update the StmtVisitor class,
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d164177251e4db..6f21674d21fa54 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -12023,6 +12023,9 @@ def err_hlsl_operator_unsupported : Error<
 def err_hlsl_param_qualifier_mismatch :
   Error<"conflicting parameter qualifier %0 on parameter %1">;
 
+def warn_hlsl_impcast_vector_truncation : Warning<
+  "implicit conversion truncates vector: %0 to %1">, InGroup;
+
 // Layout randomization diagnostics.
 def err_non_designated_init_used : Error<
   "a randomized struct can only be initialized with a designated initializer">;
diff --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 6ccabad3af5446..2f93fee4d9806a 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -195,6 +195,9 @@ class Sema;
 /// Fixed point type conversions according to N1169.
 ICK_Fixed_Point_Conversion,
 
+/// HLSL vector truncation.
+ICK_HLSL_Vector_Truncation,
+
 /// The number of conversion kinds
 ICK_Num_Conversion_Kinds,
   };
@@ -271,6 +274,12 @@ class Sema;
 /// pointer-to-member conversion, or boolean conversion.
 ImplicitConversionKind Second : 8;
 
+/// Element - Between the second and third conversion a vector or matrix
+/// element conversion may occur. If this is not ICK_Identity this
+/// conversion is applied element-wise to each element in the vector or
+/// matrix.
+ImplicitConversionKind Element : 8;
+
 /// Third - The third conversion can be a qualification conversion
 /// or a function conversion.
 ImplicitConversionKind Third : 8;
@@ -357,7 +366,8 @@ class Sema;
 void setAsIdentityConversion();
 
 bool isIdentityConversion() const {
-  return Second == ICK_Identity && Third == ICK_Identity;
+  return Second == ICK_Identity && Element == ICK_Identity 

[clang] [clang] Parse attribute [[gnu::no_stack_protector]] (PR #75289)

2023-12-13 Thread Sirui Mu via cfe-commits

https://github.com/Lancern updated 
https://github.com/llvm/llvm-project/pull/75289

>From d8de529580101ba68dc1c981aec8711aa0c58da4 Mon Sep 17 00:00:00 2001
From: Sirui Mu 
Date: Wed, 13 Dec 2023 06:51:09 +
Subject: [PATCH 1/3] [clang] Parse attribute [[gnu::no_stack_protector]]

This commit adds relative TableGen definitions to parse the
[[gnu::no_stack_protector]] attribute.
---
 clang/include/clang/Basic/Attr.td | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 0d94ea2851c9ab..0344fa23e15369 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2212,7 +2212,8 @@ def NotTailCalled : InheritableAttr {
 def : MutualExclusions<[AlwaysInline, NotTailCalled]>;
 
 def NoStackProtector : InheritableAttr {
-  let Spellings = [Clang<"no_stack_protector">, Declspec<"safebuffers">];
+  let Spellings = [Clang<"no_stack_protector">, CXX11<"gnu", 
"no_stack_protector">,
+   C23<"gnu", "no_stack_protector">, Declspec<"safebuffers">];
   let Subjects = SubjectList<[Function]>;
   let Documentation = [NoStackProtectorDocs];
   let SimpleHandler = 1;

>From 0efedf8a3af361077c59174b008862cc8a0a Mon Sep 17 00:00:00 2001
From: Sirui Mu 
Date: Wed, 13 Dec 2023 14:29:12 +0800
Subject: [PATCH 2/3] [clang] Add unit tests for parsing
 [[gnu::no_stack_protector]]

---
 clang/test/Parser/gnu-attributes.c   | 4 
 clang/test/Parser/gnu-attributes.cpp | 4 
 2 files changed, 8 insertions(+)
 create mode 100644 clang/test/Parser/gnu-attributes.c
 create mode 100644 clang/test/Parser/gnu-attributes.cpp

diff --git a/clang/test/Parser/gnu-attributes.c 
b/clang/test/Parser/gnu-attributes.c
new file mode 100644
index 00..f75728915b685d
--- /dev/null
+++ b/clang/test/Parser/gnu-attributes.c
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c23 %s
+// expected-no-diagnostics
+
+[[gnu::no_stack_protector]] void test1(int i) {} // ok
diff --git a/clang/test/Parser/gnu-attributes.cpp 
b/clang/test/Parser/gnu-attributes.cpp
new file mode 100644
index 00..a1c3c7abe92ed8
--- /dev/null
+++ b/clang/test/Parser/gnu-attributes.cpp
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -fsyntax-only -verify 
-std=c++11 %s
+// expected-no-diagnostics
+
+[[gnu::no_stack_protector]] void test1(int i) {} // ok

>From e9d2bcb0d6fc4ddf0acde5deed2096c6a515ab3c Mon Sep 17 00:00:00 2001
From: Sirui Mu 
Date: Thu, 14 Dec 2023 01:55:09 +
Subject: [PATCH 3/3] [clang] Move no_stack_protector parsing tests to
 test/Sema

---
 clang/test/Parser/gnu-attributes.c | 4 
 clang/test/Parser/gnu-attributes.cpp   | 4 
 clang/test/Sema/no_stack_protector.c   | 5 -
 clang/test/Sema/no_stack_protector.cpp | 5 +
 4 files changed, 9 insertions(+), 9 deletions(-)
 delete mode 100644 clang/test/Parser/gnu-attributes.c
 delete mode 100644 clang/test/Parser/gnu-attributes.cpp
 create mode 100644 clang/test/Sema/no_stack_protector.cpp

diff --git a/clang/test/Parser/gnu-attributes.c 
b/clang/test/Parser/gnu-attributes.c
deleted file mode 100644
index f75728915b685d..00
--- a/clang/test/Parser/gnu-attributes.c
+++ /dev/null
@@ -1,4 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c23 %s
-// expected-no-diagnostics
-
-[[gnu::no_stack_protector]] void test1(int i) {} // ok
diff --git a/clang/test/Parser/gnu-attributes.cpp 
b/clang/test/Parser/gnu-attributes.cpp
deleted file mode 100644
index a1c3c7abe92ed8..00
--- a/clang/test/Parser/gnu-attributes.cpp
+++ /dev/null
@@ -1,4 +0,0 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -fsyntax-only -verify 
-std=c++11 %s
-// expected-no-diagnostics
-
-[[gnu::no_stack_protector]] void test1(int i) {} // ok
diff --git a/clang/test/Sema/no_stack_protector.c 
b/clang/test/Sema/no_stack_protector.c
index 0007435901e840..1ecd46bc624ceb 100644
--- a/clang/test/Sema/no_stack_protector.c
+++ b/clang/test/Sema/no_stack_protector.c
@@ -1,4 +1,7 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c23 %s
+
+[[gnu::no_stack_protector]] void test1(void) {}
+[[clang::no_stack_protector]] void test2(void) {}
 
 void __attribute__((no_stack_protector)) foo(void) {}
 int __attribute__((no_stack_protector)) var; // expected-warning 
{{'no_stack_protector' attribute only applies to functions}}
diff --git a/clang/test/Sema/no_stack_protector.cpp 
b/clang/test/Sema/no_stack_protector.cpp
new file mode 100644
index 00..160e3d32a9389a
--- /dev/null
+++ b/clang/test/Sema/no_stack_protector.cpp
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// expected-no-diagnostics
+
+[[gnu::no_stack_protector]] void test1() {}
+[[clang::no_stack_protector]] void test2() {}

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


[llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/4] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/4] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/4] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/3] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/3] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/3] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[llvm] [clang-tools-extra] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (ZijunZhaoCCK)


Changes

Clang always silently ignores garbage target versions and this makes debug 
harder. So clang will report when target versions are invalid.

---
Full diff: https://github.com/llvm/llvm-project/pull/75373.diff


3 Files Affected:

- (modified) clang/lib/Basic/Targets/OSTargets.h (+5) 
- (modified) llvm/include/llvm/TargetParser/Triple.h (+4) 
- (modified) llvm/lib/TargetParser/Triple.cpp (+13-1) 


``diff
diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index ac04dab0489717..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1198,9 +1199,20 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "version "<< Name << " is invalid\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

``




https://github.com/llvm/llvm-project/pull/75373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [llvm] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/3] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/3] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

>From b2dda9ce95804783c59aa1ca4e81a7941aae805d Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 3/3] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 clang/lib/Basic/Targets/OSTargets.h | 5 +
 llvm/include/llvm/TargetParser/Triple.h | 4 
 llvm/lib/TargetParser/Triple.cpp| 8 
 3 files changed, 17 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 342af4bbc42b7b..bc28066019971c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -323,6 +323,11 @@ class LLVM_LIBRARY_VISIBILITY LinuxTargetInfo : public 
OSTargetInfo {
 // This historical but ambiguous name for the minSdkVersion macro. Keep
 // defined for compatibility.
 Builder.defineMacro("__ANDROID_API__", "__ANDROID_MIN_SDK_VERSION__");
+  } else {
+llvm::errs() << "version "<< Triple.getVersionName() <<
+" in triple " << Triple.getArchName() << "-" << Triple.getVendorName()
+<< "-" << Triple.getOSAndEnvironmentName() << " is invalid\n";
+exit(1);
   }
 } else {
 Builder.defineMacro("__gnu_linux__");
diff --git a/llvm/include/llvm/TargetParser/Triple.h 
b/llvm/include/llvm/TargetParser/Triple.h
index 47904621c0967f..05df1c489ad06e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -434,6 +434,10 @@ class Triple {
   /// string (separated by a '-' if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// Get the version component of the environment component as a single
+  /// string (the version after the environment).
+  StringRef getVersionName() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 49bc24ffbfae6c..db4ba7100781bc 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1199,6 +1199,14 @@ StringRef Triple::getOSAndEnvironmentName() const {
   return Tmp.split('-').second;  // Strip second component
 }
 
+StringRef Triple::getVersionName() const {
+  StringRef VersionName = getEnvironmentName();
+  StringRef EnvironmentTypeName = getEnvironmentTypeName(getEnvironment());
+  if (VersionName.startswith(EnvironmentTypeName))
+return VersionName.substr(EnvironmentTypeName.size());
+  return VersionName;
+}
+
 static 

[clang-tools-extra] [llvm] [clang] Make clang report garbage target versions. (PR #75373)

2023-12-13 Thread via cfe-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/75373

>From 74f256d8a77ee2ba8e0d5bbb6519aa2729cf94d5 Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:07:45 +
Subject: [PATCH 1/2] Make clang report garbage target versions.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.
---
 llvm/lib/TargetParser/Triple.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index c5e9ad43d22588..335253194d1cf8 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -11,6 +11,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Support/SwapByteOrder.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/TargetParser/ARMTargetParser.h"
@@ -1199,7 +1200,11 @@ StringRef Triple::getOSAndEnvironmentName() const {
 
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
-  Version.tryParse(Name);
+  if (Version.tryParse(Name)) {
+errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
+"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+exit(1);
+  }
   return Version.withoutBuild();
 }
 

>From 0d159b2a9b76e233e020ac0aef15b49b03f4d86c Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Wed, 13 Dec 2023 20:23:54 +
Subject: [PATCH 2/2] rephrase

---
 llvm/lib/TargetParser/Triple.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 335253194d1cf8..713ca447403d50 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -1201,8 +1201,7 @@ StringRef Triple::getOSAndEnvironmentName() const {
 static VersionTuple parseVersionFromName(StringRef Name) {
   VersionTuple Version;
   if (Version.tryParse(Name)) {
-errs() << "The input is "<< Name << " and it is invalid. Should pass an "<<
-"integer or integer combination! e.g. 2, 9.5 or 3.4.5\n";
+errs() << "version "<< Name << " is invalid\n";
 exit(1);
   }
   return Version.withoutBuild();

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


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (if the
+parameter is not explicitly initialized inside the function an undefined value
+is stored back to the argument expression). For input and output parameters, 
the
+temporary is initialized from  the lvalue argument expression through implicit
+or explicit casting from the lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(arr[0], arr[1], arr[2], arr[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``arr[0]`` is ``3``. In HLSL, the array is passed by 
value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (if the
+parameter is not explicitly initialized inside the function an undefined value
+is stored back to the argument expression). For input and output parameters, 
the
+temporary is initialized from  the lvalue argument expression through implicit
+or explicit casting from the lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(arr[0], arr[1], arr[2], arr[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``arr[0]`` is ``3``. In HLSL, the array is passed by 
value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.

tex3d wrote:

This results in an implicit float to int conversion for each component of the 
vector, not a vector truncation (which would be a reduction in the size of the 
vector).

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.

tex3d wrote:

Well, not reliably.  This area is weird and buggy, in both DXC and FXC.  This 
was originally supported in DXC because it appeared that FXC supported it.  
However, support of unsized array parameters in FXC was limited to resource 
arrays (and only on SM 5.1).  These can also be buggy in FXC, with differences 
in behavior between SM 5.0 and SM 5.1.

In DXC, use of unsized arrays can lead to asserts or crashes.  The primary area 
where they are likely to be useful is when passing an unbounded resource array 
to a function, where you do not want a copy of the resource handles, but want 
the original resource range declared globally to be passed to a function and 
indexed there.  This scenario works for SM 5.1 in FXC, but appears to assert in 
DXC.

For these reasons, we should consider removing support for them in DXC.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clangd] check for synthesized symbols when tracking include locations (PR #75128)

2023-12-13 Thread Matheus Izvekov via cfe-commits

https://github.com/mizvekov updated 
https://github.com/llvm/llvm-project/pull/75128

>From 8b5fa481b399cc49dcdc39c49ed22c7aed0cb844 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov 
Date: Mon, 11 Dec 2023 17:36:44 -0300
Subject: [PATCH 1/2] [clangd] Add test for GH75115

Add test for https://github.com/llvm/llvm-project/issues/75115
---
 clang-tools-extra/clangd/test/GH75115.test | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 clang-tools-extra/clangd/test/GH75115.test

diff --git a/clang-tools-extra/clangd/test/GH75115.test 
b/clang-tools-extra/clangd/test/GH75115.test
new file mode 100644
index 00..030392f1d69b30
--- /dev/null
+++ b/clang-tools-extra/clangd/test/GH75115.test
@@ -0,0 +1,12 @@
+// RUN: rm -rf %t.dir && mkdir -p %t.dir
+// RUN: echo '[{"directory": "%/t.dir", "command": "clang 
--target=x86_64-pc-windows-msvc -x c GH75115.test", "file": "GH75115.test"}]' > 
%t.dir/compile_commands.json
+// RUN: not --crash clangd -enable-config=0 --compile-commands-dir=%t.dir 
-check=%s 2>&1 | FileCheck -strict-whitespace %s
+
+// FIXME: Crashes
+
+// CHECK: Building preamble...
+// CHECK-NEXT: Built preamble
+// CHECK-NEXT: Indexing headers...
+// CHECK-NEXT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, 
TombstoneKey) && "Empty/Tombstone value shouldn't be inserted into map!"
+
+#define assert

>From 25bc82590687582ecc6e45614c7dd5a15b89ac08 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov 
Date: Wed, 13 Dec 2023 01:44:16 -0300
Subject: [PATCH 2/2] [clangd] check for synthesized symbols when tracking
 include locations

This fixes https://github.com/llvm/llvm-project/issues/75115

In C mode with MSVC compatibility, when the `assert` macro is defined,
as a workaround, `static_assert` is implicitly defined as well,
if not already so, in order to work around a broken `assert.h`
implementation.
This workaround was implemented in 
https://github.com/llvm/llvm-project/commit/8da090381d567d0ec555840f6b2a651d2997e4b3

A synthesized symbol does not occur in source code, and therefore
should not have valid source location, but this was not checked when
inserting this into a `symbol -> include file` map.

The invalid FileID value is used for empty key representation in
the include file hash table, so it's not valid to insert it.
---
 clang-tools-extra/clangd/index/SymbolCollector.cpp |  8 
 clang-tools-extra/clangd/test/GH75115.test | 11 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/clang-tools-extra/clangd/index/SymbolCollector.cpp 
b/clang-tools-extra/clangd/index/SymbolCollector.cpp
index aac6676a995fed..5d995cdae6d665 100644
--- a/clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ b/clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -821,7 +821,8 @@ void SymbolCollector::setIncludeLocation(const Symbol , 
SourceLocation DefLoc,
 
   // Use the expansion location to get the #include header since this is
   // where the symbol is exposed.
-  IncludeFiles[S.ID] = SM.getDecomposedExpansionLoc(DefLoc).first;
+  if (FileID FID = SM.getDecomposedExpansionLoc(DefLoc).first; FID.isValid())
+IncludeFiles[S.ID] = FID;
 
   // We update providers for a symbol with each occurence, as SymbolCollector
   // might run while parsing, rather than at the end of a translation unit.
@@ -893,16 +894,15 @@ void SymbolCollector::finish() {
 const Symbol *S = Symbols.find(SID);
 if (!S)
   continue;
-assert(IncludeFiles.contains(SID));
 
-const auto FID = IncludeFiles.at(SID);
+FileID FID = IncludeFiles.lookup(SID);
 // Determine if the FID is #include'd or #import'ed.
 Symbol::IncludeDirective Directives = Symbol::Invalid;
 auto CollectDirectives = shouldCollectIncludePath(S->SymInfo.Kind);
 if ((CollectDirectives & Symbol::Include) != 0)
   Directives |= Symbol::Include;
 // Only allow #import for symbols from ObjC-like files.
-if ((CollectDirectives & Symbol::Import) != 0) {
+if ((CollectDirectives & Symbol::Import) != 0 && FID.isValid()) {
   auto [It, Inserted] = FileToContainsImportsOrObjC.try_emplace(FID);
   if (Inserted)
 It->second = FilesWithObjCConstructs.contains(FID) ||
diff --git a/clang-tools-extra/clangd/test/GH75115.test 
b/clang-tools-extra/clangd/test/GH75115.test
index 030392f1d69b30..dc86f5b9a6cee0 100644
--- a/clang-tools-extra/clangd/test/GH75115.test
+++ b/clang-tools-extra/clangd/test/GH75115.test
@@ -1,12 +1,15 @@
 // RUN: rm -rf %t.dir && mkdir -p %t.dir
 // RUN: echo '[{"directory": "%/t.dir", "command": "clang 
--target=x86_64-pc-windows-msvc -x c GH75115.test", "file": "GH75115.test"}]' > 
%t.dir/compile_commands.json
-// RUN: not --crash clangd -enable-config=0 --compile-commands-dir=%t.dir 
-check=%s 2>&1 | FileCheck -strict-whitespace %s
-
-// FIXME: Crashes
+// RUN: clangd -enable-config=0 --compile-commands-dir=%t.dir -check=%s 2>&1 | 
FileCheck -strict-whitespace %s
 
 // CHECK: Building preamble...
 // CHECK-NEXT: Built 

[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Jan Svoboda via cfe-commits

https://github.com/jansvoboda11 approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Juergen Ributzka via cfe-commits


@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version
+// of module A.
+
+// CHECK:"modules": [
+// CHECK-NEXT: {
+// CHECK:"command-line": [
+// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"

ributzka wrote:

Updated the test to check for `-mllvm` instead.

https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Juergen Ributzka via cfe-commits


@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version

ributzka wrote:

I copy pasted this from another test. I removed the comment.

https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Juergen Ributzka via cfe-commits

https://github.com/ributzka updated 
https://github.com/llvm/llvm-project/pull/75405

>From ef0b260488d1de1cc89ead90d35cc6abf189fd6c Mon Sep 17 00:00:00 2001
From: Juergen Ributzka 
Date: Wed, 13 Dec 2023 15:44:54 -0800
Subject: [PATCH 1/2] [clang][modules] Strip LLVM options

Currently, the dep scanner does not remove LLVM options from the argument list.
Since LLVM options shouldn't affect the AST, it is safe to remove them all.
---
 .../DependencyScanning/ModuleDepCollector.cpp |  2 +
 clang/test/ClangScanDeps/strip-llvm-args.m| 49 +++
 2 files changed, 51 insertions(+)
 create mode 100644 clang/test/ClangScanDeps/strip-llvm-args.m

diff --git a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp 
b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
index 4a3cd054f23d92..bfaa897851041d 100644
--- a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -119,6 +119,8 @@ makeCommonInvocationForModuleBuild(CompilerInvocation CI) {
   // units.
   CI.getFrontendOpts().Inputs.clear();
   CI.getFrontendOpts().OutputFile.clear();
+  // LLVM options are not going to affect the AST
+  CI.getFrontendOpts().LLVMArgs.clear();
 
   // TODO: Figure out better way to set options to their default value.
   CI.getCodeGenOpts().MainFileName.clear();
diff --git a/clang/test/ClangScanDeps/strip-llvm-args.m 
b/clang/test/ClangScanDeps/strip-llvm-args.m
new file mode 100644
index 00..a2ab1b4ab5c767
--- /dev/null
+++ b/clang/test/ClangScanDeps/strip-llvm-args.m
@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version
+// of module A.
+
+// CHECK:"modules": [
+// CHECK-NEXT: {
+// CHECK:"command-line": [
+// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"
+// CHECK:]
+// CHECK:"name": "A"
+// CHECK:  }
+// CHECK-NOT:"name": "A"
+// CHECK:"translation-units"
+
+//--- cdb1.json.template
+[
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-fsyntax-only DIR/t1.m",
+"file": "DIR/t1.m"
+  },
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-mllvm -stackmap-version=2 -fsyntax-only DIR/t2.m",
+"file": "DIR/t2.m"
+  }
+]
+
+//--- modules/A/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- t1.m
+@import A;
+
+//--- t2.m
+@import A;

>From 427ec5728c06fb95836fee3f25111c873f4246a3 Mon Sep 17 00:00:00 2001
From: Juergen Ributzka 
Date: Wed, 13 Dec 2023 16:16:47 -0800
Subject: [PATCH 2/2] Commit missing test changes.

---
 clang/test/ClangScanDeps/strip-llvm-args.m | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/clang/test/ClangScanDeps/strip-llvm-args.m 
b/clang/test/ClangScanDeps/strip-llvm-args.m
index a2ab1b4ab5c767..ca8eab7729232b 100644
--- a/clang/test/ClangScanDeps/strip-llvm-args.m
+++ b/clang/test/ClangScanDeps/strip-llvm-args.m
@@ -5,13 +5,10 @@
 // RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
 // RUN: FileCheck %s -input-file %t/result1.txt
 
-// Verify that secondary actions get stripped, and that there's a single 
version
-// of module A.
-
 // CHECK:"modules": [
 // CHECK-NEXT: {
 // CHECK:"command-line": [
-// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"
+// CHECK-NOT:  "-mllvm"
 // CHECK:]
 // CHECK:"name": "A"
 // CHECK:  }

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


[llvm] [libcxxabi] [compiler-rt] [mlir] [openmp] [lldb] [flang] [clang-tools-extra] [libc] [lld] [libcxx] [clang] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-13 Thread Ahmed Bougacha via cfe-commits


@@ -2147,24 +2148,80 @@ void AsmPrinter::emitGlobalIFunc(Module , const 
GlobalIFunc ) {
   assert(!TM.getTargetTriple().isOSBinFormatXCOFF() &&
  "IFunc is not supported on AIX.");
 
-  MCSymbol *Name = getSymbol();
+  auto EmitLinkage = [&](MCSymbol *Sym) {
+if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
+  OutStreamer->emitSymbolAttribute(Sym, MCSA_Global);
+else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
+  OutStreamer->emitSymbolAttribute(Sym, MCSA_WeakReference);
+else
+  assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+  };
 
-  if (GI.hasExternalLinkage() || !MAI->getWeakRefDirective())
-OutStreamer->emitSymbolAttribute(Name, MCSA_Global);
-  else if (GI.hasWeakLinkage() || GI.hasLinkOnceLinkage())
-OutStreamer->emitSymbolAttribute(Name, MCSA_WeakReference);
-  else
-assert(GI.hasLocalLinkage() && "Invalid ifunc linkage");
+  if (TM.getTargetTriple().isOSBinFormatELF()) {
+MCSymbol *Name = getSymbol();
+EmitLinkage(Name);
+OutStreamer->emitSymbolAttribute(Name, MCSA_ELF_TypeIndFunction);
+emitVisibility(Name, GI.getVisibility());
+
+// Emit the directives as assignments aka .set:
+const MCExpr *Expr = lowerConstant(GI.getResolver());
+OutStreamer->emitAssignment(Name, Expr);
+MCSymbol *LocalAlias = getSymbolPreferLocal(GI);
+if (LocalAlias != Name)
+  OutStreamer->emitAssignment(LocalAlias, Expr);
+  } else if (TM.getTargetTriple().isOSBinFormatMachO() &&

ahmedbougacha wrote:

early return with if->fatal_error, for indentation?

https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[lldb] [clang] [openmp] [lld] [compiler-rt] [libc] [flang] [libcxxabi] [llvm] [libcxx] [clang-tools-extra] [mlir] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-13 Thread Ahmed Bougacha via cfe-commits


@@ -599,6 +599,26 @@ class AsmPrinter : public MachineFunctionPass {
   /// instructions in verbose mode.
   virtual void emitImplicitDef(const MachineInstr *MI) const;
 
+  /// getSubtargetInfo() cannot be used where this is needed because we don't
+  /// have a MachineFunction when we're lowering a GlobalIFunc, and
+  /// getSubtargetInfo requires one. Override the implementation in targets
+  /// that support the Mach-O IFunc lowering.
+  virtual const MCSubtargetInfo *getIFuncMCSubtargetInfo() const {
+return nullptr;
+  }
+
+  virtual void emitMachOIFuncStubBody(Module , const GlobalIFunc ,
+  MCSymbol *LazyPointer) {

ahmedbougacha wrote:

Maybe pass the symbol string directly, since the implementations make their own 
symbol references anyway?  That way you also don't have to do the awkward 
de-mangle/re-mangle dance with the +1

https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] [clang] [libcxxabi] [lld] [flang] [openmp] [mlir] [llvm] [libc] [compiler-rt] [clang-tools-extra] [lldb] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-13 Thread Ahmed Bougacha via cfe-commits

https://github.com/ahmedbougacha edited 
https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libc] [lld] [clang] [libcxx] [lldb] [mlir] [clang-tools-extra] [libcxxabi] [flang] [llvm] [openmp] [compiler-rt] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-13 Thread Ahmed Bougacha via cfe-commits

https://github.com/ahmedbougacha commented:

Only a couple minor comments, LG otherwise, thanks!  The Subtarget weirdness is 
unfortunate but I can't say I have a better alternative

https://github.com/llvm/llvm-project/pull/73686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [AArch64][SME] Warn when using a streaming builtin from a non-streaming function (PR #74064)

2023-12-13 Thread Sam Tebbs via cfe-commits

https://github.com/SamTebbs33 closed 
https://github.com/llvm/llvm-project/pull/74064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/3] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Jan Svoboda via cfe-commits


@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version
+// of module A.
+
+// CHECK:"modules": [
+// CHECK-NEXT: {
+// CHECK:"command-line": [
+// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"

jansvoboda11 wrote:

I'd expect this to check for "-mllvm -stackmap-version=2" from the TU 
invocation, what's the reason for checking 
"-treat-scalable-fixed-error-as-warning" instead?

https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Jan Svoboda via cfe-commits


@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version

jansvoboda11 wrote:

What do you mean by "secondary actions"?

https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);

llvm-beanz wrote:

doh!

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL] Vector standard conversions (PR #71098)

2023-12-13 Thread John McCall via cfe-commits


@@ -1422,6 +1424,9 @@ Value *ScalarExprEmitter::EmitScalarConversion(Value 
*Src, QualType SrcType,
 return Builder.CreateVectorSplat(NumElements, Src, "splat");
   }
 
+  if (SrcType->isExtVectorType() && DstType->isExtVectorType())
+return EmitVectorElementConversion(SrcType, DstType, Src);

rjmccall wrote:

Yeah, I believe the reason we still have this whole analysis in 
`EmitScalarConversion` is, sadly enough, just to deal with the LHS and final 
result of a compound assignment expression, which we don't have `CastKind`s 
for.  The more we can get away from relying on this, the better.

https://github.com/llvm/llvm-project/pull/71098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Juergen Ributzka (ributzka)


Changes

Currently, the dep scanner does not remove LLVM options from the argument list.
Since LLVM options shouldn't affect the AST, it is safe to remove them all.


---
Full diff: https://github.com/llvm/llvm-project/pull/75405.diff


2 Files Affected:

- (modified) clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp (+2) 
- (added) clang/test/ClangScanDeps/strip-llvm-args.m (+49) 


``diff
diff --git a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp 
b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
index 4a3cd054f23d92..bfaa897851041d 100644
--- a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -119,6 +119,8 @@ makeCommonInvocationForModuleBuild(CompilerInvocation CI) {
   // units.
   CI.getFrontendOpts().Inputs.clear();
   CI.getFrontendOpts().OutputFile.clear();
+  // LLVM options are not going to affect the AST
+  CI.getFrontendOpts().LLVMArgs.clear();
 
   // TODO: Figure out better way to set options to their default value.
   CI.getCodeGenOpts().MainFileName.clear();
diff --git a/clang/test/ClangScanDeps/strip-llvm-args.m 
b/clang/test/ClangScanDeps/strip-llvm-args.m
new file mode 100644
index 00..a2ab1b4ab5c767
--- /dev/null
+++ b/clang/test/ClangScanDeps/strip-llvm-args.m
@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version
+// of module A.
+
+// CHECK:"modules": [
+// CHECK-NEXT: {
+// CHECK:"command-line": [
+// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"
+// CHECK:]
+// CHECK:"name": "A"
+// CHECK:  }
+// CHECK-NOT:"name": "A"
+// CHECK:"translation-units"
+
+//--- cdb1.json.template
+[
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-fsyntax-only DIR/t1.m",
+"file": "DIR/t1.m"
+  },
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-mllvm -stackmap-version=2 -fsyntax-only DIR/t2.m",
+"file": "DIR/t2.m"
+  }
+]
+
+//--- modules/A/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- t1.m
+@import A;
+
+//--- t2.m
+@import A;

``




https://github.com/llvm/llvm-project/pull/75405
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][modules] Strip LLVM options (PR #75405)

2023-12-13 Thread Juergen Ributzka via cfe-commits

https://github.com/ributzka created 
https://github.com/llvm/llvm-project/pull/75405

Currently, the dep scanner does not remove LLVM options from the argument list.
Since LLVM options shouldn't affect the AST, it is safe to remove them all.


>From ef0b260488d1de1cc89ead90d35cc6abf189fd6c Mon Sep 17 00:00:00 2001
From: Juergen Ributzka 
Date: Wed, 13 Dec 2023 15:44:54 -0800
Subject: [PATCH] [clang][modules] Strip LLVM options

Currently, the dep scanner does not remove LLVM options from the argument list.
Since LLVM options shouldn't affect the AST, it is safe to remove them all.
---
 .../DependencyScanning/ModuleDepCollector.cpp |  2 +
 clang/test/ClangScanDeps/strip-llvm-args.m| 49 +++
 2 files changed, 51 insertions(+)
 create mode 100644 clang/test/ClangScanDeps/strip-llvm-args.m

diff --git a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp 
b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
index 4a3cd054f23d92..bfaa897851041d 100644
--- a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -119,6 +119,8 @@ makeCommonInvocationForModuleBuild(CompilerInvocation CI) {
   // units.
   CI.getFrontendOpts().Inputs.clear();
   CI.getFrontendOpts().OutputFile.clear();
+  // LLVM options are not going to affect the AST
+  CI.getFrontendOpts().LLVMArgs.clear();
 
   // TODO: Figure out better way to set options to their default value.
   CI.getCodeGenOpts().MainFileName.clear();
diff --git a/clang/test/ClangScanDeps/strip-llvm-args.m 
b/clang/test/ClangScanDeps/strip-llvm-args.m
new file mode 100644
index 00..a2ab1b4ab5c767
--- /dev/null
+++ b/clang/test/ClangScanDeps/strip-llvm-args.m
@@ -0,0 +1,49 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb1.json.template > %t/cdb1.json
+
+// RUN: clang-scan-deps -compilation-database %t/cdb1.json -format 
experimental-full > %t/result1.txt
+// RUN: FileCheck %s -input-file %t/result1.txt
+
+// Verify that secondary actions get stripped, and that there's a single 
version
+// of module A.
+
+// CHECK:"modules": [
+// CHECK-NEXT: {
+// CHECK:"command-line": [
+// CHECK-NOT:  "-treat-scalable-fixed-error-as-warning"
+// CHECK:]
+// CHECK:"name": "A"
+// CHECK:  }
+// CHECK-NOT:"name": "A"
+// CHECK:"translation-units"
+
+//--- cdb1.json.template
+[
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-fsyntax-only DIR/t1.m",
+"file": "DIR/t1.m"
+  },
+  {
+"directory": "DIR",
+"command": "clang -Imodules/A -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-mllvm -stackmap-version=2 -fsyntax-only DIR/t2.m",
+"file": "DIR/t2.m"
+  }
+]
+
+//--- modules/A/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- t1.m
+@import A;
+
+//--- t2.m
+@import A;

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


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,

tex3d wrote:

Shouldn't this say: "the value of `arr[0]` is `3`"?  (wrong array again)

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);

tex3d wrote:

`return float4(a[0], a[1], a[2], a[3]);` references the wrong array.  It should 
be `arr[0], ...`, right?

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Tex Riddell via cfe-commits


@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document describes the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from

tex3d wrote:

> (it is undefined behavior to not explicitly initialize an ``out`` parameter 
> inside a function)

Perhaps it's better to say that an out parameter has an undefined value if not 
initialized inside the function, rather than this being considered undefined 
**_behavior_**?

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [polly] [polly][ScheduleOptimizer] Fix long compile time(hang) reported in polly (PR #75141)

2023-12-13 Thread Eli Friedman via cfe-commits

efriedma-quic wrote:

The isl_options_set_on_error thing still seems like an issue; there's a path to 
restore on_error, but it doesn't run if the quota is hit.

Do we actually need to explicitly check hasQuotaExceeded() at all?  If there's 
an error, the schedule should be null, and there's already a check for `if 
(Schedule.is_null())`.

https://github.com/llvm/llvm-project/pull/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH 1/2] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits


@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when it is copied back to the argument expression. This is

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits


@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call

llvm-beanz wrote:

I don't think we explicitly define it, but we need the Clang DXIL generation to 
match otherwise we could expose subtle bugs.

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp edited 
https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Damyan Pepper via cfe-commits


@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the floating point vector type ``float3``. This results in an implicit
+truncation of the vector even if the value is unused in the function.
+
+
+.. code-block:: c++
+  void UB(out int X) {}
+
+  void main() {
+int X = 7;
+UB(X); // X is undefined!
+  }
+
+In this example an initialized value is passed to an ``out`` parameter.
+Parameters marked ``out`` are not initialized by the argument expression or
+implicitly by the function. They must be explicitly initialized. In this case
+the argument is not initialized in the function so the temporary is still
+uninitialized when it is copied back to the argument expression. This is

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Damyan Pepper via cfe-commits


@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call

damyanp wrote:

Is this defined behavior that we have to ensure continues to work so HLSL 
developers targeting DXIL can depend on it?

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Damyan Pepper via cfe-commits


@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call

damyanp wrote:

typo: `descries` -> `describes`

https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp approved this pull request.


https://github.com/llvm/llvm-project/pull/75397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/75397

>From 4ebc0c58dc751f422de85b0909636cb1a87f8ce4 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 316 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 317 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..e62b249e011a94
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,316 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification `_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the 

[libunwind] [clang] [libc] [compiler-rt] [libcxx] [clang-tools-extra] [flang] [lldb] [lld] [mlir] [libcxxabi] [llvm] [hwasan] Improve support of forking with threads (PR #75291)

2023-12-13 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka closed 
https://github.com/llvm/llvm-project/pull/75291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libunwind] [clang] [libc] [compiler-rt] [libcxx] [clang-tools-extra] [flang] [lldb] [lld] [mlir] [libcxxabi] [llvm] [hwasan] Improve support of forking with threads (PR #75291)

2023-12-13 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka updated 
https://github.com/llvm/llvm-project/pull/75291

>From 1a361826b5345460c201c506f2d2c78a84aebf84 Mon Sep 17 00:00:00 2001
From: Vitaly Buka 
Date: Tue, 12 Dec 2023 22:59:10 -0800
Subject: [PATCH 1/4] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20ch?=
 =?UTF-8?q?anges=20to=20main=20this=20commit=20is=20based=20on?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4

[skip ci]
---
 .../include/sanitizer/hwasan_interface.h  |  4 
 compiler-rt/lib/asan/asan_fuchsia.cpp |  2 ++
 compiler-rt/lib/asan/asan_internal.h  |  1 +
 compiler-rt/lib/asan/asan_posix.cpp   | 24 +++
 compiler-rt/lib/asan/asan_rtl.cpp |  2 ++
 compiler-rt/lib/asan/asan_win.cpp |  2 ++
 compiler-rt/lib/hwasan/hwasan.cpp |  2 ++
 compiler-rt/lib/hwasan/hwasan.h   |  6 ++---
 .../lib/hwasan/hwasan_interface_internal.h|  3 +++
 compiler-rt/lib/lsan/lsan.cpp |  1 +
 compiler-rt/lib/lsan/lsan.h   |  1 +
 compiler-rt/lib/lsan/lsan_common.cpp  |  3 +++
 compiler-rt/lib/lsan/lsan_common.h|  4 
 compiler-rt/lib/lsan/lsan_fuchsia.cpp |  1 +
 compiler-rt/lib/lsan/lsan_posix.cpp   | 18 ++
 compiler-rt/test/hwasan/TestCases/tag-ptr.cpp | 24 +++
 .../TestCases/Posix/fork_threaded.c   |  2 +-
 .../sanitizer_common/sanitizer_specific.h | 13 ++
 18 files changed, 109 insertions(+), 4 deletions(-)
 create mode 100644 compiler-rt/test/hwasan/TestCases/tag-ptr.cpp

diff --git a/compiler-rt/include/sanitizer/hwasan_interface.h 
b/compiler-rt/include/sanitizer/hwasan_interface.h
index abe310c0666948..407f488a24a617 100644
--- a/compiler-rt/include/sanitizer/hwasan_interface.h
+++ b/compiler-rt/include/sanitizer/hwasan_interface.h
@@ -44,6 +44,10 @@ void SANITIZER_CDECL __hwasan_tag_memory(const volatile void 
*p,
 void *SANITIZER_CDECL __hwasan_tag_pointer(const volatile void *p,
unsigned char tag);
 
+/// Get tag from the pointer.
+unsigned char SANITIZER_CDECL
+__hwasan_get_tag_from_pointer(const volatile void *p);
+
 // Set memory tag from the current SP address to the given address to zero.
 // This is meant to annotate longjmp and other non-local jumps.
 // This function needs to know the (almost) exact destination frame address;
diff --git a/compiler-rt/lib/asan/asan_fuchsia.cpp 
b/compiler-rt/lib/asan/asan_fuchsia.cpp
index 2b15504123bee7..12625e9d75833d 100644
--- a/compiler-rt/lib/asan/asan_fuchsia.cpp
+++ b/compiler-rt/lib/asan/asan_fuchsia.cpp
@@ -240,6 +240,8 @@ void FlushUnneededASanShadowMemory(uptr p, uptr size) {
 // So this doesn't install any atexit hook like on other platforms.
 void InstallAtExitCheckLeaks() {}
 
+void InstallAtForkHandler() {}
+
 }  // namespace __asan
 
 namespace __lsan {
diff --git a/compiler-rt/lib/asan/asan_internal.h 
b/compiler-rt/lib/asan/asan_internal.h
index 5b97e77882cd67..2944ebe213b5d5 100644
--- a/compiler-rt/lib/asan/asan_internal.h
+++ b/compiler-rt/lib/asan/asan_internal.h
@@ -126,6 +126,7 @@ void *AsanDlSymNext(const char *sym);
 bool HandleDlopenInit();
 
 void InstallAtExitCheckLeaks();
+void InstallAtForkHandler();
 
 #define ASAN_ON_ERROR() \
   if (&__asan_on_error) \
diff --git a/compiler-rt/lib/asan/asan_posix.cpp 
b/compiler-rt/lib/asan/asan_posix.cpp
index e1f66641617cc1..37fca8aea51511 100644
--- a/compiler-rt/lib/asan/asan_posix.cpp
+++ b/compiler-rt/lib/asan/asan_posix.cpp
@@ -148,6 +148,30 @@ void PlatformTSDDtor(void *tsd) {
 }
 #endif
 
+void InstallAtForkHandler() {
+  auto before = []() {
+if (CAN_SANITIZE_LEAKS) {
+  __lsan::LockGlobal();
+}
+// `_lsan` functions defined regardless of `CAN_SANITIZE_LEAKS` and do the
+// job.
+__lsan::LockThreads();
+__lsan::LockAllocator();
+StackDepotLockAll();
+  };
+  auto after = []() {
+StackDepotUnlockAll();
+// `_lsan` functions defined regardless of `CAN_SANITIZE_LEAKS` and do the
+// job.
+__lsan::UnlockAllocator();
+__lsan::UnlockThreads();
+if (CAN_SANITIZE_LEAKS) {
+  __lsan::UnlockGlobal();
+}
+  };
+  pthread_atfork(before, after, after);
+}
+
 void InstallAtExitCheckLeaks() {
   if (CAN_SANITIZE_LEAKS) {
 if (common_flags()->detect_leaks && common_flags()->leak_check_at_exit) {
diff --git a/compiler-rt/lib/asan/asan_rtl.cpp 
b/compiler-rt/lib/asan/asan_rtl.cpp
index b28f9f181239b3..a61deed7382b02 100644
--- a/compiler-rt/lib/asan/asan_rtl.cpp
+++ b/compiler-rt/lib/asan/asan_rtl.cpp
@@ -493,6 +493,8 @@ static bool AsanInitInternal() {
 InstallAtExitCheckLeaks();
   }
 
+  InstallAtForkHandler();
+
 #if CAN_SANITIZE_UB
   __ubsan::InitAsPlugin();
 #endif
diff --git a/compiler-rt/lib/asan/asan_win.cpp 
b/compiler-rt/lib/asan/asan_win.cpp
index d5a30f471e2b0d..f16ce677618e4f 100644
--- 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Chris B (llvm-beanz)


Changes

This adds a new document that covers the HLSL approach to function calls and 
parameter semantics. At time of writing this document is a proposal for the 
implementation.

---
Full diff: https://github.com/llvm/llvm-project/pull/75397.diff


2 Files Affected:

- (added) clang/docs/HLSL/FunctionCalls.rst (+300) 
- (modified) clang/docs/HLSL/HLSLDocs.rst (+1) 


``diff
diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..aeddac087cb89d
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: c++
+  void Trunc(inout int3 V) { }
+
+
+  void main() {
+float3 F = {1.5, 2.6, 3.3};
+Trunc(F); // F == {1.0, 2.0, 3.0}
+  }
+
+In the above example, the argument expression ``F`` undergoes element-wise
+conversion from a float vector to an integer vector to create a temporary
+``int3``. On expiration the temporary undergoes elementwise conversion back to
+the 

[clang] [HLSL][Docs] Add documentation for HLSL functions (PR #75397)

2023-12-13 Thread Chris B via cfe-commits

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/75397

This adds a new document that covers the HLSL approach to function calls and 
parameter semantics. At time of writing this document is a proposal for the 
implementation.

>From d6f57c27a3030f242bba62077ecd84ba49d8e468 Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Wed, 13 Dec 2023 16:44:09 -0600
Subject: [PATCH] [HLSL][Docs] Add documentation for HLSL functions

This adds a new document that covers the HLSL approach to function
calls and parameter semantics. At time of writing this document is a
proposal for the implementation.
---
 clang/docs/HLSL/FunctionCalls.rst | 300 ++
 clang/docs/HLSL/HLSLDocs.rst  |   1 +
 2 files changed, 301 insertions(+)
 create mode 100644 clang/docs/HLSL/FunctionCalls.rst

diff --git a/clang/docs/HLSL/FunctionCalls.rst 
b/clang/docs/HLSL/FunctionCalls.rst
new file mode 100644
index 00..aeddac087cb89d
--- /dev/null
+++ b/clang/docs/HLSL/FunctionCalls.rst
@@ -0,0 +1,300 @@
+===
+HLSL Function Calls
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+This document descries the design and implementation of HLSL's function call
+semantics in Clang. This includes details related to argument conversion and
+parameter lifetimes.
+
+This document does not seek to serve as official documentation for HLSL's
+call semantics, but does provide an overview to assist a reader. The
+authoritative documentation for HLSL's language semantics is the `draft 
language
+specification`_.
+
+Argument Semantics
+==
+
+In HLSL, all function arguments are passed by value in and out of functions.
+HLSL has 3 keywords which denote the parameter semantics (``in``, ``out`` and
+``inout``). In a function declaration a parameter may be annotated any of the
+following ways:
+
+#.  - denotes input
+#. ``in`` - denotes input
+#. ``out`` - denotes output
+#. ``in out`` - denotes input and output
+#. ``out in`` - denotes input and output
+#. ``inout`` - denotes input and output
+
+Parameters that are exclusively input behave like C/C++ parameters that are
+passed by value.
+
+For parameters that are output (or input and output), a temporary value is
+created in the caller. The temporary value is then passed by-address. For
+output-only parameters, the temporary is uninitialized when passed (it is
+undefined behavior to not explicitly initialize an ``out`` parameter inside a
+function). For input and output parameters, the temporary is initialized from
+the lvalue argument expression through implicit or explicit casting from the
+lvalue argument type to the parameter type.
+
+On return of the function, the values of any parameter temporaries are written
+back to the argument expression through an inverted conversion sequence (if an
+``out`` parameter was not initialized in the function, the uninitialized value
+may be written back).
+
+Parameters of constant-sized array type, are also passed with value semantics.
+This requires input parameters of arrays to construct temporaries and the
+temporaries go through array-to-pointer decay when initializing parameters.
+
+Implementations are allowed to avoid unnecessary temporaries, and HLSL's strict
+no-alias rules can enable some trivial optimizations.
+
+Array Temporaries
+-
+
+Given the following example:
+
+.. code-block:: c++
+  void fn(float a[4]) {
+a[0] = a[1] + a[2] + a[3];
+  }
+
+  float4 main() : SV_Target {
+float arr[4] = {1, 1, 1, 1};
+fn(arr);
+return float4(a[0], a[1], a[2], a[3]);
+  }
+
+In C or C++, the array parameter decays to a pointer, so after the call to
+``fn``, the value of ``a[0]`` is ``3``. In HLSL, the array is passed by value,
+so modifications inside ``fn`` do not propagate out.
+
+.. note::
+  DXC supports unsized arrays passed directly as decayed pointers, which is an
+  unfortunate behavior divergence.
+
+Out Parameter Temporaries
+-
+
+.. code-block:: c++
+  void Init(inout int X, inout int Y) {
+Y = 2;
+X = 1;
+  }
+
+  void main() {
+int V;
+Init(V, V); // MSVC ABI V == 2, Itanium V == 1
+  }
+
+In the above example the ``Init`` function's behavior depends on the C++ ABI
+implementation. In the MSVC C++ ABI (used for the HLSL DXIL target), call
+arguments are emitted right-to-left and destroyed left-to-right. This means 
that
+the parameter initialization and destruction occurs in the order: {``Y``,
+``X``, ``~X``, ``~Y``}. This causes the write-back of the value of ``Y`` to 
occur
+last, so the resulting value of ``V`` is ``2``. In the Itanium C++ ABI, the
+parameter ordering is reversed, so the initialization and destruction occurs in
+the order: {``X``, ``Y``, ``~Y``, ``X``}. This causes the write-back of the
+value ``X`` to occur last, resulting in the value of ``V`` being set to ``1``.
+
+.. code-block:: 

[clang] [Cygwin] Value.h consider Cygwin (PR #75395)

2023-12-13 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: 徐持恒 Xu Chiheng (xu-chiheng)


Changes



---
Full diff: https://github.com/llvm/llvm-project/pull/75395.diff


1 Files Affected:

- (modified) clang/include/clang/Interpreter/Value.h (+1-1) 


``diff
diff --git a/clang/include/clang/Interpreter/Value.h 
b/clang/include/clang/Interpreter/Value.h
index c380cd91550def..f0b26dc3c89c40 100644
--- a/clang/include/clang/Interpreter/Value.h
+++ b/clang/include/clang/Interpreter/Value.h
@@ -52,7 +52,7 @@ class ASTContext;
 class Interpreter;
 class QualType;
 
-#if defined(_WIN32)
+#if defined(_WIN32) || defined(__CYGWIN__)
 // REPL_EXTERNAL_VISIBILITY are symbols that we need to be able to locate
 // at runtime. On Windows, this requires them to be exported from any of the
 // modules loaded at runtime. Marking them as dllexport achieves this; both

``




https://github.com/llvm/llvm-project/pull/75395
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Cygwin] Value.h consider Cygwin (PR #75395)

2023-12-13 Thread via cfe-commits

github-actions[bot] wrote:

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

https://github.com/llvm/llvm-project/pull/75395
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Cygwin] Value.h consider Cygwin (PR #75395)

2023-12-13 Thread 徐持恒 Xu Chiheng via cfe-commits

https://github.com/xu-chiheng created 
https://github.com/llvm/llvm-project/pull/75395

None

From c3da4faacc108d7cdbc92f426571eab65482f8ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=BE=90=E6=8C=81=E6=81=92=20Xu=20Chiheng?=
 
Date: Thu, 14 Dec 2023 06:38:09 +0800
Subject: [PATCH] 1

---
 clang/include/clang/Interpreter/Value.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/include/clang/Interpreter/Value.h 
b/clang/include/clang/Interpreter/Value.h
index c380cd91550def..f0b26dc3c89c40 100644
--- a/clang/include/clang/Interpreter/Value.h
+++ b/clang/include/clang/Interpreter/Value.h
@@ -52,7 +52,7 @@ class ASTContext;
 class Interpreter;
 class QualType;
 
-#if defined(_WIN32)
+#if defined(_WIN32) || defined(__CYGWIN__)
 // REPL_EXTERNAL_VISIBILITY are symbols that we need to be able to locate
 // at runtime. On Windows, this requires them to be exported from any of the
 // modules loaded at runtime. Marking them as dllexport achieves this; both

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


[clang] [flang] [libcxx] [llvm] [lld] [mlir] [libunwind] [clang-tools-extra] [libcxxabi] [libc] [lldb] [compiler-rt] [hwasan] Improve support of forking with threads (PR #75291)

2023-12-13 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka edited 
https://github.com/llvm/llvm-project/pull/75291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] [clang] [flang] [llvm] [lld] [mlir] [libunwind] [clang-tools-extra] [libcxxabi] [libc] [lldb] [compiler-rt] [test][hwasan] Implement sanitizer_specific for HWASAN (PR #75280)

2023-12-13 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka closed 
https://github.com/llvm/llvm-project/pull/75280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [MinGW] Fix the regression caused by commit 592e935e115ffb451eb9b782376711dab6558fe0, that, in MinGW, Clang can't be built by system Clang 15.0.4. (PR #74982)

2023-12-13 Thread 徐持恒 Xu Chiheng via cfe-commits

https://github.com/xu-chiheng closed 
https://github.com/llvm/llvm-project/pull/74982
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [MinGW] Fix the regression caused by commit 592e935e115ffb451eb9b782376711dab6558fe0, that, in MinGW, Clang can't be built by system Clang 15.0.4. (PR #74982)

2023-12-13 Thread 徐持恒 Xu Chiheng via cfe-commits

xu-chiheng wrote:

As commit 49b27b150b97c190dedf8b45bf991c4b811ed953 2023-12-09, this patch is 
not needed.


https://github.com/llvm/llvm-project/pull/74982
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Cygwin] Reduced number of inline elements of CallArgList. (PR #74977)

2023-12-13 Thread 徐持恒 Xu Chiheng via cfe-commits

https://github.com/xu-chiheng closed 
https://github.com/llvm/llvm-project/pull/74977
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [MinGW] MinGW dynamicbase (PR #74979)

2023-12-13 Thread 徐持恒 Xu Chiheng via cfe-commits

https://github.com/xu-chiheng closed 
https://github.com/llvm/llvm-project/pull/74979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] [clang] [flang] [llvm] [lld] [mlir] [libunwind] [clang-tools-extra] [libcxxabi] [libc] [lldb] [compiler-rt] [test][hwasan] Implement sanitizer_specific for HWASAN (PR #75280)

2023-12-13 Thread Vitaly Buka via cfe-commits

https://github.com/vitalybuka edited 
https://github.com/llvm/llvm-project/pull/75280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [ValueTracking] Add dominating condition support in computeKnownBits() (PR #73662)

2023-12-13 Thread Björn Pettersson via cfe-commits

bjope wrote:

> > Here is another thing that I noticed after this patch: 
> > https://godbolt.org/z/1P7bnKGjh
> > So early instcombine is eliminating an `and` operation (in the foo 
> > example), resulting in simplifycfg not being able to collapse the control 
> > flow any longer.
> 
> I don't think it's a profitable transformation in simplifycfg with larger 
> amount of instructions. In x86, backend generates much larger code for the 
> example with collapsed cfg: https://godbolt.org/z/YP9GjjP8c.

Optimization pipeline is doing simplifications and canonicalizations. If you 
for example use `-target amdcgn`, then I think you will see that the codegen is 
impacted negatively when not simplifying the control flow. So it depends on the 
backend if one form is profitable or not.
I don't know really which form that should be considered best (simplest and 
easiest for most backends to deal with) here. Just saying that it changed. And 
that could indeed be one reason for regressions (as for our backend).

https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[flang] [clang] [flang][Driver] Let the linker fail on multiple definitions of main() (PR #73124)

2023-12-13 Thread Andrzej Warzyński via cfe-commits

banach-space wrote:

Could folks confirm whether this fixes the issue on Darwin: 
https://github.com/llvm/llvm-project/pull/75393?

https://github.com/llvm/llvm-project/pull/73124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [flang][driver] Don't use -whole-archive on Darwin (PR #75393)

2023-12-13 Thread Andrzej Warzyński via cfe-commits

https://github.com/banach-space edited 
https://github.com/llvm/llvm-project/pull/75393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [flang][driver] Don't use -whole-archive on Darwin (PR #75393)

2023-12-13 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Andrzej Warzyński (banach-space)


Changes

Direct follow-up of #7312 - the linker on Darwin does not support
`-whole-archive`, so that needs to be removed from the linker
invocation.

For context:
  * https://github.com/llvm/llvm-project/pull/7312


---
Full diff: https://github.com/llvm/llvm-project/pull/75393.diff


1 Files Affected:

- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+9-5) 


``diff
diff --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 51b336216c5653..4ce456d52c3e5e 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1128,20 +1128,24 @@ void tools::addFortranRuntimeLibs(const ToolChain , 
const ArgList ,
 // --whole-archive flag to the link line.  If it's not, add a proper
 // --whole-archive/--no-whole-archive bracket to the link line.
 bool WholeArchiveActive = false;
-for (auto *Arg : Args.filtered(options::OPT_Wl_COMMA))
-  if (Arg)
+for (auto *Arg : Args.filtered(options::OPT_Wl_COMMA)) {
+  if (Arg) {
 for (StringRef ArgValue : Arg->getValues()) {
   if (ArgValue == "--whole-archive")
 WholeArchiveActive = true;
   if (ArgValue == "--no-whole-archive")
 WholeArchiveActive = false;
 }
+  }
+}
 
-if (!WholeArchiveActive)
+if (!WholeArchiveActive && !TC.getTriple().isMacOSX()) {
   CmdArgs.push_back("--whole-archive");
-CmdArgs.push_back("-lFortran_main");
-if (!WholeArchiveActive)
+  CmdArgs.push_back("-lFortran_main");
   CmdArgs.push_back("--no-whole-archive");
+} else {
+  CmdArgs.push_back("-lFortran_main");
+}
 
 // Perform regular linkage of the remaining runtime libraries.
 CmdArgs.push_back("-lFortranRuntime");

``




https://github.com/llvm/llvm-project/pull/75393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   3   4   >