[PATCH] D124534: [clang] Add a diagnostic for line directive of a gnu extension

[Ken Matsui via Phabricator via cfe-commits]

ken-matsui updated this revision to Diff 428301.
ken-matsui added a comment.

Add a test file that uses the `-Wsystem-headers` option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124534

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/line-directive-system-headers.c
  clang/test/Preprocessor/line-directive.c
  clang/test/SemaCXX/constexpr-string.cpp

Index: clang/test/SemaCXX/constexpr-string.cpp
===
--- clang/test/SemaCXX/constexpr-string.cpp
+++ clang/test/SemaCXX/constexpr-string.cpp
@@ -7,7 +7,7 @@
 // RUN: %clang_cc1 %s -triple armebv7-unknown-linux -std=c++2a -fsyntax-only -verify -pedantic -Wno-vla-extension -fno-signed-char
 // RUN: %clang_cc1 %s -triple armebv7-unknown-linux -std=c++2a -fsyntax-only -verify -pedantic -Wno-vla-extension -fno-wchar -DNO_PREDEFINED_WCHAR_T
 
-# 9 "/usr/include/string.h" 1 3 4
+# 9 "/usr/include/string.h" 1 3 4  // expected-warning {{this style of line directive is a GNU extension}}
 extern "C" {
   typedef decltype(sizeof(int)) size_t;
 
@@ -29,7 +29,7 @@
 }
 # 25 "SemaCXX/constexpr-string.cpp" 2
 
-# 27 "/usr/include/wchar.h" 1 3 4
+# 27 "/usr/include/wchar.h" 1 3 4  // expected-warning {{this style of line directive is a GNU extension}}
 extern "C" {
 #if NO_PREDEFINED_WCHAR_T
   typedef decltype(L'0') wchar_t;
Index: clang/test/Preprocessor/line-directive.c
===
--- clang/test/Preprocessor/line-directive.c
+++ clang/test/Preprocessor/line-directive.c
@@ -9,8 +9,8 @@
 # 20 "" 2
 
 // a push/pop before any other line control
-# 10 "enter-0" 1
-# 11 "" 2 // pop to main file
+# 10 "enter-0" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 11 "" 2 // pop to main file: expected-warning {{this style of line directive is a GNU extension}}
 #error MAIN7
 // expected-error@-1{{MAIN7}}
 
@@ -27,13 +27,13 @@
 #define A 42 "foo"
 #line A
 
-# 42
-# 42 "foo"
+# 42 // expected-warning {{this style of line directive is a GNU extension}}
+# 42 "foo" // expected-warning {{this style of line directive is a GNU extension}}
 # 42 "foo" 2 // expected-error {{invalid line marker flag '2': cannot pop empty include stack}}
 # 42 "foo" 1 3  // enter
 # 42 "foo" 2 3  // exit
 # 42 "foo" 2 3 4 // expected-error {{invalid line marker flag '2': cannot pop empty include stack}}
-# 42 "foo" 3 4
+# 42 "foo" 3 4 // expected-warning {{this style of line directive is a GNU extension}}
 
 # 'a'// expected-error {{invalid preprocessing directive}}
 # 42 'f' // expected-error {{invalid filename for line marker directive}}
@@ -54,7 +54,7 @@
 
 // Verify that linemarker diddling of the system header flag works.
 
-# 192 "glomp.h" // not a system header.
+# 192 "glomp.h" // not a system header.: expected-warning {{this style of line directive is a GNU extension}}
 typedef int x;  // expected-note {{previous definition is here}}
 typedef int x;  // expected-warning {{redefinition of typedef 'x' is a C11 feature}}
 
@@ -97,7 +97,7 @@
 #line 010  // expected-warning {{#line directive interprets number as decimal, not octal}}
 extern int array[__LINE__ == 10 ? 1:-1];
 
-# 020  // expected-warning {{GNU line marker directive interprets number as decimal, not octal}}
+# 020  // expected-warning {{GNU line marker directive interprets number as decimal, not octal}} expected-warning {{this style of line directive is a GNU extension}}
 extern int array_gnuline[__LINE__ == 20 ? 1:-1];
 
 /* PR3917 */
@@ -106,7 +106,7 @@
 _\
 _LINE__ == 42 ? 1: -1];  /* line marker is location of first _ */
 
-# 51
+# 51 // expected-warning {{this style of line directive is a GNU extension}}
 extern char array2_gnuline[\
 _\
 _LINE__ == 52 ? 1: -1];  /* line marker is location of first _ */
@@ -115,12 +115,12 @@
 #line 0 "line-directive.c" // expected-warning {{#line directive with zero argument is a GNU extension}}
 undefined t; // expected-error {{unknown type name 'undefined'}}
 
-# 115 "main"
-# 116 "enter-1" 1
-# 117 "enter-2" 1
-# 118 "" 2 // pop to enter-1
+# 115 "main" // expected-warning {{this style of line directive is a GNU extension}}
+# 116 "enter-1" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 117 "enter-2" 1 // expected-warning {{this style of line directive is a GNU extension}}
+# 118 "" 2 // pop to enter-1: expected-warning {{this style of line directive is a GNU extension}}
 #error ENTER1
 // expected-error@-1{{ENTER1}}
-# 121 "" 2 // pop to "main"
+# 121 "" 2 // pop to "main": expected-warning {{this style of line directive is a GNU extension}}
 #error MAIN2
 // expected-error@-1{{MAIN2}}
Index: clang/test/Preprocessor/line-directive-system-headers.c
===

[PATCH] D125272: [clang] Add -fcheck-new support

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5984
 
+  if (Args.hasFlag(options::OPT_fcheck_new, options::OPT_fno_check_new, false))
+CmdArgs.push_back("-fcheck-new");

See `addOptInFlag` in this file.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:1
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new --target=x86_64-linux-gnu -emit-llvm -S %s -o - | 
opt -S -mem2reg | FileCheck %s

jrtc27 wrote:
> Not sure why they were checked before, but you'll need this to actually get 
> the attributes checked
We generally only use `%clang_cc1` for clang code gen tests. `%clang` generally 
is only used for test/Driver tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm updated this revision to Diff 428300.
srishti-pm added a comment.

Make the sorting strictly stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

Files:
  clang/docs/tools/clang-formatted-files.txt
  mlir/include/mlir/Transforms/CommutativityUtils.h
  mlir/lib/Transforms/Utils/CMakeLists.txt
  mlir/lib/Transforms/Utils/CommutativityUtils.cpp
  mlir/test/Transforms/test-commutativity-utils.mlir
  mlir/test/lib/Dialect/Test/TestOps.td
  mlir/test/lib/Transforms/CMakeLists.txt
  mlir/test/lib/Transforms/TestCommutativityUtils.cpp
  mlir/tools/mlir-opt/mlir-opt.cpp

Index: mlir/tools/mlir-opt/mlir-opt.cpp
===
--- mlir/tools/mlir-opt/mlir-opt.cpp
+++ mlir/tools/mlir-opt/mlir-opt.cpp
@@ -56,6 +56,7 @@
 void registerVectorizerTestPass();
 
 namespace test {
+void registerCommutativityUtils();
 void registerConvertCallOpPass();
 void registerInliner();
 void registerMemRefBoundCheck();
@@ -146,6 +147,7 @@
   registerVectorizerTestPass();
   registerTosaTestQuantUtilAPIPass();
 
+  mlir::test::registerCommutativityUtils();
   mlir::test::registerConvertCallOpPass();
   mlir::test::registerInliner();
   mlir::test::registerMemRefBoundCheck();
Index: mlir/test/lib/Transforms/TestCommutativityUtils.cpp
===
--- /dev/null
+++ mlir/test/lib/Transforms/TestCommutativityUtils.cpp
@@ -0,0 +1,67 @@
+//===- TestCommutativityUtils.cpp - Pass to test the commutativity utility-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This pass tests the functionality of the commutativity utility.
+//
+//===--===//
+
+#include "mlir/Transforms/CommutativityUtils.h"
+
+#include "TestDialect.h"
+#include "mlir/Pass/Pass.h"
+#include "mlir/Transforms/GreedyPatternRewriteDriver.h"
+
+using namespace mlir;
+using namespace test;
+
+namespace {
+
+struct SmallPattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestCommutativeOp testCommOp,
+PatternRewriter &rewriter) const override {
+sortCommutativeOperands(testCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct LargePattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestLargeCommutativeOp testLargeCommOp,
+PatternRewriter &rewriter) const override {
+sortCommutativeOperands(testLargeCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct CommutativityUtils
+: public PassWrapper> {
+  MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(CommutativityUtils)
+
+  StringRef getArgument() const final { return "test-commutativity-utils"; }
+  StringRef getDescription() const final {
+return "Test the functionality of the commutativity utility";
+  }
+
+  void runOnOperation() override {
+auto func = getOperation();
+auto *context = &getContext();
+
+RewritePatternSet patterns(context);
+patterns.add(context);
+
+(void)applyPatternsAndFoldGreedily(func, std::move(patterns));
+  }
+};
+} // namespace
+
+namespace mlir {
+namespace test {
+void registerCommutativityUtils() { PassRegistration(); }
+} // namespace test
+} // namespace mlir
Index: mlir/test/lib/Transforms/CMakeLists.txt
===
--- mlir/test/lib/Transforms/CMakeLists.txt
+++ mlir/test/lib/Transforms/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Exclude tests from libMLIR.so
 add_mlir_library(MLIRTestTransforms
+  TestCommutativityUtils.cpp
   TestConstantFold.cpp
   TestControlFlowSink.cpp
   TestInlining.cpp
Index: mlir/test/lib/Dialect/Test/TestOps.td
===
--- mlir/test/lib/Dialect/Test/TestOps.td
+++ mlir/test/lib/Dialect/Test/TestOps.td
@@ -1101,11 +1101,21 @@
   let hasFolder = 1;
 }
 
+def TestAddIOp : TEST_Op<"addi"> {
+  let arguments = (ins I32:$op1, I32:$op2);
+  let results = (outs I32);
+}
+
 def TestCommutativeOp : TEST_Op<"op_commutative", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4);
   let results = (outs I32);
 }
 
+def TestLargeCommutativeOp : TEST_Op<"op_large_commutative", [Commutative]> {
+  let arguments = (ins I32:$op1, I32:$op2, I32:$op3, I32:$op4, I32:$op5, I32:$op6, I32:$op7);
+  let results = (outs I32);
+}
+
 def TestCommutative2Op : TEST_Op<"op_commutative2", [Commutative]> {
   let arguments = (ins I32:$op1, I32:$op2);
   let results = (outs I32);
Index: m

[PATCH] D124815: [libclang] Fall back to getMainExecutable when dladdr fails

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

I think the file is linked into `libclang.so`.

The resource directory is relative to`libclang.so` but may not be relative to 
the main executable... So getMainExecutable will be incorrect.




Comment at: clang/tools/libclang/CIndexer.cpp:142
+// error instead of crashing.
+llvm::report_fatal_error("Could not locate Clang resource path");
+  }

Diagnostics generally are not capitalized: 
https://llvm.org/docs/CodingStandards.html#error-and-warning-messages

You can ignore the numerous anti-examples (I know, lots of inconsistency)...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124815

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

[PATCH] D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed that this patch isn't NFC.

If I run

  clang-tidy -checks='*' empty.c --

on an empty file empty.c I get the following printouts with this patch:

  'addr=address'
  'arr=array'
  'attr=attribute'
  'buf=buffer'
  'cl=client'
  'cnt=count'
  'col=column'
  'cpy=copy'
  'dest=destination'
  'dist=distancedst=distance'
  'elem=element'
  'hght=height'
  'i=index'
  'idx=index'
  'len=length'
  'ln=line'
  'lst=list'
  'nr=number'
  'num=number'
  'pos=position'
  'ptr=pointer'
  'ref=reference'
  'src=source'
  'srv=server'
  'stmt=statement'
  'str=string'
  'val=value'
  'var=variable'
  'vec=vector'
  'wdth=width'

but without this patch it's completely silent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124341

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

[PATCH] D125203: [PowerPC] Fix PPCISD::STBRX selection issue on A2

[Ting Wang via Phabricator via cfe-commits]

tingwang added a comment.

In D125203#3502433 , @nemanjai wrote:

> Why not also fix this in the front end so that we allow the builtin on the A2 
> CPU as well (since it's supported)?

Oh I missed that. Thank you for pointing out!

Just now updated the patch. However I didn't update the SemaFeatureCheck 
message to indicate the support on a2, since if people see this error message, 
it cannot be a2, and a2 does not easily fit into the message of 
err_ppc_builtin_only_on_arch. Hope this will not create problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125203

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

[PATCH] D125203: [PowerPC] Fix PPCISD::STBRX selection issue on A2

[Ting Wang via Phabricator via cfe-commits]

tingwang updated this revision to Diff 428294.
tingwang added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update according to Nemanja's comment: add A2 to frontend isa-v206-instructions 
feature list, together with test case update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125203

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-isa-features.cpp
  llvm/lib/Target/PowerPC/PPC.td
  llvm/test/CodeGen/PowerPC/bswap-load-store.ll

Index: llvm/test/CodeGen/PowerPC/bswap-load-store.ll
===
--- llvm/test/CodeGen/PowerPC/bswap-load-store.ll
+++ llvm/test/CodeGen/PowerPC/bswap-load-store.ll
@@ -3,6 +3,7 @@
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=ppc32-- -mcpu=pwr7  | FileCheck %s --check-prefixes=X32,PWR7_32
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=ppc64 | FileCheck %s --check-prefixes=X64
 ; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=pwr7  | FileCheck %s --check-prefixes=PWR7_64
+; RUN: llc -ppc-asm-full-reg-names -verify-machineinstrs < %s -mtriple=powerpc64-- -mcpu=a2| FileCheck %s --check-prefixes=A2_64
 
 
 define void @STWBRX(i32 %i, i8* %ptr, i32 %off) {
@@ -22,6 +23,12 @@
 ; PWR7_64-NEXT:extsw r5, r5
 ; PWR7_64-NEXT:stwbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r5, r5
+; A2_64-NEXT:stwbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.1 = bitcast i8* %tmp1 to i32*
   %tmp13 = tail call i32 @llvm.bswap.i32( i32 %i )
@@ -46,6 +53,12 @@
 ; PWR7_64-NEXT:extsw r4, r4
 ; PWR7_64-NEXT:lwbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LWBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r4, r4
+; A2_64-NEXT:lwbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.2 = bitcast i8* %tmp1 to i32*
   %tmp = load i32, i32* %tmp1.upgrd.2
@@ -70,6 +83,12 @@
 ; PWR7_64-NEXT:extsw r5, r5
 ; PWR7_64-NEXT:sthbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STHBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r5, r5
+; A2_64-NEXT:sthbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.3 = bitcast i8* %tmp1 to i16*
   %tmp5 = call i16 @llvm.bswap.i16( i16 %s )
@@ -94,6 +113,12 @@
 ; PWR7_64-NEXT:extsw r4, r4
 ; PWR7_64-NEXT:lhbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LHBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:extsw r4, r4
+; A2_64-NEXT:lhbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i32 %off
   %tmp1.upgrd.4 = bitcast i8* %tmp1 to i16*
   %tmp = load i16, i16* %tmp1.upgrd.4
@@ -133,6 +158,11 @@
 ; PWR7_64:   # %bb.0:
 ; PWR7_64-NEXT:stdbrx r3, r4, r5
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: STDBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:stdbrx r3, r4, r5
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i64 %off
   %tmp1.upgrd.1 = bitcast i8* %tmp1 to i64*
   %tmp13 = tail call i64 @llvm.bswap.i64( i64 %i )
@@ -163,6 +193,11 @@
 ; PWR7_64:   # %bb.0:
 ; PWR7_64-NEXT:ldbrx r3, r3, r4
 ; PWR7_64-NEXT:blr
+;
+; A2_64-LABEL: LDBRX:
+; A2_64:   # %bb.0:
+; A2_64-NEXT:ldbrx r3, r3, r4
+; A2_64-NEXT:blr
   %tmp1 = getelementptr i8, i8* %ptr, i64 %off
   %tmp1.upgrd.2 = bitcast i8* %tmp1 to i64*
   %tmp = load i64, i64* %tmp1.upgrd.2
Index: llvm/lib/Target/PowerPC/PPC.td
===
--- llvm/lib/Target/PowerPC/PPC.td
+++ llvm/lib/Target/PowerPC/PPC.td
@@ -592,7 +592,8 @@
FeatureSTFIWX, FeatureLFIWAX,
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeatureSlowPOPCNTD, FeatureCMPB, FeatureLDBRX,
-   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB]>;
+   Feature64Bit /*, Feature64BitRegs */, FeatureMFTB,
+   FeatureISA2_06]>;
 def : ProcessorModel<"pwr3", G5Model,
   [DirectivePwr3, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE, FeatureMFOCRF,
Index: clang/test/Driver/ppc-isa-features.cpp
===
--- clang/test/Driver/ppc-isa-features.cpp
+++ clang/test/Driver/ppc-isa-features.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr6 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-PWR6
+// RUN: %clang -target powerpc64-unknown-unknown -mcpu=a2 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-A2
 // RUN: %clang -target powerpc64-unknown-unknown -mcpu=pwr7 -S -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-PWR7
 // RUN: %clang -ta

[PATCH] D121733: Clean pathnames in FileManager.

[Paul Pluzhnikov via Phabricator via cfe-commits]

ppluzhnikov updated this revision to Diff 428293.
ppluzhnikov added a comment.
Herald added subscribers: usaxena95, kadircet.

Fix FIXME in CanonicalIncludesTests.cpp (yet another Winx64 failure).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121733

Files:
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/llvmlibc/RestrictSystemLibcHeadersCheck.cpp
  clang-tools-extra/clangd/unittests/CanonicalIncludesTests.cpp
  clang-tools-extra/test/clang-apply-replacements/conflict.cpp
  clang-tools-extra/test/clang-apply-replacements/order-dependent.cpp
  clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
  clang-tools-extra/test/clang-tidy/checkers/abseil-no-namespace.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
  clang-tools-extra/test/modularize/ProblemsMissingHeader.modularize
  clang/bindings/python/tests/cindex/test_translation_unit.py
  clang/lib/Basic/FileManager.cpp
  clang/test/ClangScanDeps/header-search-pruning-transitive.c
  clang/test/Frontend/dependency-gen.c
  clang/test/Index/skip-parsed-bodies/compile_commands.json
  clang/test/Modules/cxx20-hu-04.cpp
  clang/test/Modules/cxx20-hu-05.cpp
  clang/test/Modules/cxx20-hu-06.cpp
  clang/test/Modules/filename.cpp
  clang/unittests/Lex/HeaderSearchTest.cpp
  clang/unittests/Tooling/Syntax/TokensTest.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -1622,21 +1622,22 @@
   return L.getFilePath() < R.getFilePath();
 });
 
-  ASSERT_EQ(Changes[0].getFilePath(), "./input.h");
-  EXPECT_THAT(Changes[0].getInsertedHeaders(), IsEmpty());
-  EXPECT_THAT(Changes[0].getRemovedHeaders(), IsEmpty());
+  const auto &change_h = Changes[1];
+  ASSERT_EQ(change_h.getFilePath(), "input.h");
+  EXPECT_THAT(change_h.getInsertedHeaders(), IsEmpty());
+  EXPECT_THAT(change_h.getRemovedHeaders(), IsEmpty());
   llvm::Expected UpdatedCode =
-  clang::tooling::applyAllReplacements(Header,
-   Changes[0].getReplacements());
+  clang::tooling::applyAllReplacements(Header, change_h.getReplacements());
   ASSERT_TRUE(static_cast(UpdatedCode))
   << "Could not update code: " << llvm::toString(UpdatedCode.takeError());
   EXPECT_EQ(format(*UpdatedCode), "");
 
-  ASSERT_EQ(Changes[1].getFilePath(), "input.cc");
-  EXPECT_THAT(Changes[1].getInsertedHeaders(), IsEmpty());
-  EXPECT_THAT(Changes[1].getRemovedHeaders(), IsEmpty());
-  UpdatedCode = clang::tooling::applyAllReplacements(
-  Source, Changes[1].getReplacements());
+  const auto &change_cc = Changes[0];
+  ASSERT_EQ(change_cc.getFilePath(), "input.cc");
+  EXPECT_THAT(change_cc.getInsertedHeaders(), IsEmpty());
+  EXPECT_THAT(change_cc.getRemovedHeaders(), IsEmpty());
+  UpdatedCode =
+  clang::tooling::applyAllReplacements(Source, change_cc.getReplacements());
   ASSERT_TRUE(static_cast(UpdatedCode))
   << "Could not update code: " << llvm::toString(UpdatedCode.takeError());
   EXPECT_EQ(format(*UpdatedCode), format("#include \"input.h\"\n"));
@@ -1659,7 +1660,7 @@
   {{"input.h", Header}}));
 
   ASSERT_EQ(Changes.size(), 1U);
-  ASSERT_EQ(Changes[0].getFilePath(), "./input.h");
+  ASSERT_EQ(Changes[0].getFilePath(), "input.h");
   EXPECT_THAT(Changes[0].getInsertedHeaders(), ElementsAre("header.h"));
   EXPECT_THAT(Changes[0].getRemovedHeaders(), IsEmpty());
   llvm::Expected UpdatedCode =
@@ -1708,7 +1709,7 @@
   ResultOf([](const AtomicChange &C) { return C.getFilePath(); },
"input.cc"),
   ResultOf([](const AtomicChange &C) { return C.getFilePath(); },
-   "./input.h";
+   "input.h";
 }
 
 TEST_F(TransformerTest, GeneratesMetadata) {
Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -295,7 +295,7 @@
   {"int main() {}",
R"(expanded tokens:
   int main ( ) { }
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 int main ( ) { }
   no mappings.
@@ -304,7 +304,7 @@
   {"\t\n  int\t\n  main\t\n  (\t\n  )\t\n{\t\n  }\t\n",
R"(expanded tokens:
   int main ( ) { }
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 int main ( ) { }
   no mappings.
@@ -316,7 +316,7 @@
   )cpp",
R"(expanded tokens:
   
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 # pragma GCC visibility push ( public ) # pragma GCC visibility pop
   mappings:
@@ -325,7 +325,7 @@
   // Empty files should not crash.
   

[PATCH] D121733: Clean pathnames in FileManager.

[Paul Pluzhnikov via Phabricator via cfe-commits]

ppluzhnikov updated this revision to Diff 428275.
ppluzhnikov added a comment.

Fix one more Winx64 failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121733

Files:
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/llvmlibc/RestrictSystemLibcHeadersCheck.cpp
  clang-tools-extra/test/clang-apply-replacements/conflict.cpp
  clang-tools-extra/test/clang-apply-replacements/order-dependent.cpp
  clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
  clang-tools-extra/test/clang-tidy/checkers/abseil-no-namespace.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
  clang-tools-extra/test/modularize/ProblemsMissingHeader.modularize
  clang/bindings/python/tests/cindex/test_translation_unit.py
  clang/lib/Basic/FileManager.cpp
  clang/test/ClangScanDeps/header-search-pruning-transitive.c
  clang/test/Frontend/dependency-gen.c
  clang/test/Index/skip-parsed-bodies/compile_commands.json
  clang/test/Modules/cxx20-hu-04.cpp
  clang/test/Modules/cxx20-hu-05.cpp
  clang/test/Modules/cxx20-hu-06.cpp
  clang/test/Modules/filename.cpp
  clang/unittests/Lex/HeaderSearchTest.cpp
  clang/unittests/Tooling/Syntax/TokensTest.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -1622,21 +1622,22 @@
   return L.getFilePath() < R.getFilePath();
 });
 
-  ASSERT_EQ(Changes[0].getFilePath(), "./input.h");
-  EXPECT_THAT(Changes[0].getInsertedHeaders(), IsEmpty());
-  EXPECT_THAT(Changes[0].getRemovedHeaders(), IsEmpty());
+  const auto &change_h = Changes[1];
+  ASSERT_EQ(change_h.getFilePath(), "input.h");
+  EXPECT_THAT(change_h.getInsertedHeaders(), IsEmpty());
+  EXPECT_THAT(change_h.getRemovedHeaders(), IsEmpty());
   llvm::Expected UpdatedCode =
-  clang::tooling::applyAllReplacements(Header,
-   Changes[0].getReplacements());
+  clang::tooling::applyAllReplacements(Header, change_h.getReplacements());
   ASSERT_TRUE(static_cast(UpdatedCode))
   << "Could not update code: " << llvm::toString(UpdatedCode.takeError());
   EXPECT_EQ(format(*UpdatedCode), "");
 
-  ASSERT_EQ(Changes[1].getFilePath(), "input.cc");
-  EXPECT_THAT(Changes[1].getInsertedHeaders(), IsEmpty());
-  EXPECT_THAT(Changes[1].getRemovedHeaders(), IsEmpty());
-  UpdatedCode = clang::tooling::applyAllReplacements(
-  Source, Changes[1].getReplacements());
+  const auto &change_cc = Changes[0];
+  ASSERT_EQ(change_cc.getFilePath(), "input.cc");
+  EXPECT_THAT(change_cc.getInsertedHeaders(), IsEmpty());
+  EXPECT_THAT(change_cc.getRemovedHeaders(), IsEmpty());
+  UpdatedCode =
+  clang::tooling::applyAllReplacements(Source, change_cc.getReplacements());
   ASSERT_TRUE(static_cast(UpdatedCode))
   << "Could not update code: " << llvm::toString(UpdatedCode.takeError());
   EXPECT_EQ(format(*UpdatedCode), format("#include \"input.h\"\n"));
@@ -1659,7 +1660,7 @@
   {{"input.h", Header}}));
 
   ASSERT_EQ(Changes.size(), 1U);
-  ASSERT_EQ(Changes[0].getFilePath(), "./input.h");
+  ASSERT_EQ(Changes[0].getFilePath(), "input.h");
   EXPECT_THAT(Changes[0].getInsertedHeaders(), ElementsAre("header.h"));
   EXPECT_THAT(Changes[0].getRemovedHeaders(), IsEmpty());
   llvm::Expected UpdatedCode =
@@ -1708,7 +1709,7 @@
   ResultOf([](const AtomicChange &C) { return C.getFilePath(); },
"input.cc"),
   ResultOf([](const AtomicChange &C) { return C.getFilePath(); },
-   "./input.h";
+   "input.h";
 }
 
 TEST_F(TransformerTest, GeneratesMetadata) {
Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -295,7 +295,7 @@
   {"int main() {}",
R"(expanded tokens:
   int main ( ) { }
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 int main ( ) { }
   no mappings.
@@ -304,7 +304,7 @@
   {"\t\n  int\t\n  main\t\n  (\t\n  )\t\n{\t\n  }\t\n",
R"(expanded tokens:
   int main ( ) { }
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 int main ( ) { }
   no mappings.
@@ -316,7 +316,7 @@
   )cpp",
R"(expanded tokens:
   
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 # pragma GCC visibility push ( public ) # pragma GCC visibility pop
   mappings:
@@ -325,7 +325,7 @@
   // Empty files should not crash.
   {R"cpp()cpp", R"(expanded tokens:
   
-file './input.cpp'
+file 'input.cpp'
   spelled tokens:
 
   no mappings.
@@ -339,7 +339,7 @@
 )cpp",
   

[PATCH] D27068: Improve string::find

[JianYongChan via Phabricator via cfe-commits]

Tangmou added inline comments.



Comment at: libcxx/trunk/include/__string:557
+  _CharT __f2 = *__first2;
+  while (true) {
+__len1 = __last1 - __first1;

Tangmou wrote:
> Sorry for the comment after such a long time, but I have a question about 
> this patch.
> 
> Since we have already calculated `__len1` and ensured that `__len1 < __len2` 
> before the loop,  can we just skip the length calculation and the comparison 
> in the first loop cycle?  And thus we can replace the `while` loop with 
> `do-while` or keep the `while` loop but delete the length calculation and the 
> comparison before the loop?
Sorry, I made a mistake. Please ignore it!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D27068

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

[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

[Ting Wang via Phabricator via cfe-commits]

tingwang updated this revision to Diff 428268.
tingwang added a comment.

Update the three test cases introduced in this patch to use opaque-pointer
clang/test/CodeGen/PowerPC/aix-init-ref-null.cpp
clang/test/CodeGen/PowerPC/aix-ref-static-var.cpp
clang/test/CodeGen/PowerPC/aix-ref-tls_init.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

Files:
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGen/PowerPC/aix-init-ref-null.cpp
  clang/test/CodeGen/PowerPC/aix-ref-static-var.cpp
  clang/test/CodeGen/PowerPC/aix-ref-tls_init.cpp
  clang/test/CodeGenCXX/aix-static-init-debug-info.cpp
  clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
  clang/test/CodeGenCXX/aix-static-init.cpp

Index: clang/test/CodeGenCXX/aix-static-init.cpp
===
--- clang/test/CodeGenCXX/aix-static-init.cpp
+++ clang/test/CodeGenCXX/aix-static-init.cpp
@@ -38,6 +38,10 @@
   }
 } // namespace test4
 
+// CHECK: @_ZN5test12t1E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test12t2E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test21xE = global i32 0, align {{[0-9]+}}, !associated ![[ASSOC1:[0-9]+]]
+// CHECK: @_ZN5test31tE = global %"struct.test3::Test3" undef, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
 // CHECK: @_ZGVZN5test41fEvE11staticLocal = internal global i64 0, align 8
 // CHECK: @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I__, i8* null }]
 // CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__D_a, i8* null }]
@@ -49,7 +53,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test12t1E() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test12t1E() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t1E)
 // CHECK:   ret void
@@ -80,7 +84,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test12t2E() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test12t2E() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t2E)
 // CHECK:   ret void
@@ -114,7 +118,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test31tE() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test31tE() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test35Test3D1Ev(%"struct.test3::Test3"* @_ZN5test31tE)
 // CHECK:   ret void
@@ -155,7 +159,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZZN5test41fEvE11staticLocal() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZZN5test41fEvE11staticLocal() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test45Test4D1Ev(%"struct.test4::Test4"* @_ZZN5test41fEvE11staticLocal)
 // CHECK:   ret void
@@ -192,3 +196,7 @@
 // CHECK:   call void @__finalize__ZN5test12t1E()
 // CHECK:   ret void
 // CHECK: }
+
+// CHECK: ![[ASSOC0]] = !{void ()* @{{_GLOBAL__sub_I__|_GLOBAL__D_a}}, void ()* @{{_GLOBAL__sub_I__|_GLOBAL__D_a}}}
+// CHECK: ![[ASSOC1]] = !{void ()* @_GLOBAL__sub_I__}
+// CHECK: ![[ASSOC2]] = !{void ()* @_GLOBAL__D_a}
Index: clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
===
--- clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
+++ clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
@@ -44,8 +44,13 @@
 A A::instance = bar();
 } // namespace test2
 
+// CHECK: @_ZN5test12t0E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test12t2E = linkonce_odr global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC1:[0-9]+]]
 // CHECK: @_ZGVN5test12t2E = linkonce_odr global i64 0, align 8
+// CHECK: @_ZN5test12t1IiEE = linkonce_odr global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC2:[0-9]+]]
+// CHECK: @_ZN5test21AIvE8instanceE = weak_odr global %"struct.test2::A" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC3:[0-9]+]]
 // CHECK: @_ZGVN5test21AIvE8instanceE = weak_odr global i64 0, align 8
+// CHECK: @_ZN5test21AIiE8instanceE = global %"struct.test2::A.0" zeroinitializer, align {{[0-9]+}}, !associated ![[AS

[PATCH] D125157: [clang][Driver] Add more tests for riscv

[Ben Shi via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG88c336d8eff0: [clang][Driver] Add more tests for riscv 
(authored by benshi001).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125157

Files:
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -559,3 +559,24 @@
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifdzve64d -### %s -c 
2>&1 | \
 // RUN:   FileCheck -check-prefix=RV32-ZVE64D-GOOD %s
 // RV32-ZVE64D-GOOD: "-target-feature" "+zve64d"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFINX-GOOD %s
+// RV32-ZFINX-GOOD: "-target-feature" "+zfinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izdinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZDINX-GOOD %s
+// RV32-ZDINX-GOOD: "-target-feature" "+zdinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinxmin -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINXMIN-GOOD %s
+// RV32-ZHINXMIN-GOOD: "-target-feature" "+zhinxmin"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx1p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-GOOD %s
+// RV32-ZHINX-GOOD: "-target-feature" "+zhinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx0p1 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-BADVERS %s
+// RV32-ZHINX-BADVERS: error: invalid arch name 'rv32izhinx0p1'
+// RV32-ZHINX-BADVERS: unsupported version number 0.1 for extension 'zhinx'


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -559,3 +559,24 @@
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifdzve64d -### %s -c 2>&1 | \
 // RUN:   FileCheck -check-prefix=RV32-ZVE64D-GOOD %s
 // RV32-ZVE64D-GOOD: "-target-feature" "+zve64d"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFINX-GOOD %s
+// RV32-ZFINX-GOOD: "-target-feature" "+zfinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izdinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZDINX-GOOD %s
+// RV32-ZDINX-GOOD: "-target-feature" "+zdinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinxmin -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINXMIN-GOOD %s
+// RV32-ZHINXMIN-GOOD: "-target-feature" "+zhinxmin"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx1p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-GOOD %s
+// RV32-ZHINX-GOOD: "-target-feature" "+zhinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx0p1 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-BADVERS %s
+// RV32-ZHINX-BADVERS: error: invalid arch name 'rv32izhinx0p1'
+// RV32-ZHINX-BADVERS: unsupported version number 0.1 for extension 'zhinx'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 88c336d - [clang][Driver] Add more tests for riscv

[Ben Shi via cfe-commits]

Author: Ben Shi
Date: 2022-05-10T02:27:56Z
New Revision: 88c336d8eff03fc59a669c9ae4f2e415d95ff07c

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

LOG: [clang][Driver] Add more tests for riscv

Reviewed By: benshi001

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

Added: 


Modified: 
clang/test/Driver/riscv-arch.c

Removed: 




diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 824e85eeb55fc..1a8c321e956be 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -559,3 +559,24 @@
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifdzve64d -### %s -c 
2>&1 | \
 // RUN:   FileCheck -check-prefix=RV32-ZVE64D-GOOD %s
 // RV32-ZVE64D-GOOD: "-target-feature" "+zve64d"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFINX-GOOD %s
+// RV32-ZFINX-GOOD: "-target-feature" "+zfinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izdinx -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZDINX-GOOD %s
+// RV32-ZDINX-GOOD: "-target-feature" "+zdinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinxmin -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINXMIN-GOOD %s
+// RV32-ZHINXMIN-GOOD: "-target-feature" "+zhinxmin"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx1p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-GOOD %s
+// RV32-ZHINX-GOOD: "-target-feature" "+zhinx"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izhinx0p1 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZHINX-BADVERS %s
+// RV32-ZHINX-BADVERS: error: invalid arch name 'rv32izhinx0p1'
+// RV32-ZHINX-BADVERS: unsupported version number 0.1 for extension 'zhinx'



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

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

@rsmith gentle ping~


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

https://reviews.llvm.org/D113545

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

[PATCH] D125162: [clang-format] fix alignment w/o binpacked args

[cha5on via Phabricator via cfe-commits]

cha5on marked 3 inline comments as done.
cha5on added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:17321
+
+verifyFormat(Expected, ToFormat, Alignment);
+  }

curdeius wrote:
> I don't think you need to create variables, just online the strings.
> 
> Also, could you minimize (and possibly split) as much as possible these test 
> cases?
Shrank this down and added a second testcase for direct-list-initialization.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125162

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

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu updated this revision to Diff 428263.
ChuanqiXu added a comment.

Code Cleanups


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

https://reviews.llvm.org/D113545

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/Module.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Lookup.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  
clang/test/CXX/basic/basic.lookup/basic.lookup.argdep/Inputs/Friend-in-reachable-class.cppm
  
clang/test/CXX/basic/basic.lookup/basic.lookup.argdep/p4-friend-in-reachable-class.cpp
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/CXX/module/module.import/p2.cpp
  clang/test/CXX/module/module.interface/Inputs/p7.cppm
  clang/test/CXX/module/module.interface/p2.cpp
  clang/test/CXX/module/module.interface/p7.cpp
  clang/test/CXX/module/module.reach/Inputs/p4/bar.cppm
  clang/test/CXX/module/module.reach/Inputs/p4/foo.cppm
  clang/test/CXX/module/module.reach/Inputs/p5-A.cppm
  clang/test/CXX/module/module.reach/p2.cpp
  clang/test/CXX/module/module.reach/p4/TransitiveImport.cpp
  clang/test/CXX/module/module.reach/p5.cpp
  clang/test/CXX/module/module.unit/p7/t6.cpp
  clang/test/CXX/modules-ts/basic/basic.link/p2/other.cpp
  clang/test/Modules/Inputs/Reachability-Private/Private.cppm
  clang/test/Modules/Inputs/Reachability-func-default-arg/func_default_arg.cppm
  clang/test/Modules/Inputs/Reachability-func-ret/func_ret.cppm
  
clang/test/Modules/Inputs/Reachability-template-default-arg/template_default_arg.cppm
  clang/test/Modules/Inputs/Reachability-template-instantiation/Templ.cppm
  clang/test/Modules/Inputs/Reachability-template-instantiation/Templ.h
  clang/test/Modules/Inputs/Reachability-template-instantiation/Use.cppm
  clang/test/Modules/Inputs/Reachability-using-templates/mod-templates.cppm
  clang/test/Modules/Inputs/Reachability-using/mod.cppm
  clang/test/Modules/Inputs/derived_class/bar.h
  clang/test/Modules/Inputs/derived_class/foo.cppm
  clang/test/Modules/Inputs/explicitly-specialized-template/X.cppm
  clang/test/Modules/Inputs/explicitly-specialized-template/foo.h
  clang/test/Modules/Inputs/template-function-specialization/foo.cppm
  clang/test/Modules/Inputs/template_default_argument/B.cppm
  clang/test/Modules/Inputs/template_default_argument/templ.h
  clang/test/Modules/Reachability-Private.cpp
  clang/test/Modules/Reachability-func-default-arg.cpp
  clang/test/Modules/Reachability-func-ret.cpp
  clang/test/Modules/Reachability-template-default-arg.cpp
  clang/test/Modules/Reachability-template-instantiation.cpp
  clang/test/Modules/Reachability-using-templates.cpp
  clang/test/Modules/Reachability-using.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp
  clang/test/Modules/derived_class.cpp
  clang/test/Modules/explicitly-specialized-template.cpp
  clang/test/Modules/module-private.cpp
  clang/test/Modules/template-function-specialization.cpp
  clang/test/Modules/template_default_argument.cpp

Index: clang/test/Modules/template_default_argument.cpp
===
--- /dev/null
+++ clang/test/Modules/template_default_argument.cpp
@@ -0,0 +1,9 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: %clang_cc1 -std=c++20 %S/Inputs/template_default_argument/B.cppm -emit-module-interface -o %t/B.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %s -fsyntax-only -verify
+// expected-no-diagnostics
+import B;
+auto foo() {
+  return bar();
+}
Index: clang/test/Modules/template-function-specialization.cpp
===
--- /dev/null
+++ clang/test/Modules/template-function-specialization.cpp
@@ -0,0 +1,18 @@
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %S/Inputs/template-function-specialization/foo.cppm -o %t/foo.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %s -verify -fsyntax-only
+import foo;
+void use() {
+  foo();
+  foo();
+  foo2(); // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo2();   // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo3();
+  foo3();
+
+  foo4();
+  foo4();
+}
Index: clang/test/Modules/module-private.cpp
===
--- clang/test/Modules/module-private.cpp
+++ clang/test/Modules/module-private.c

[PATCH] D125162: [clang-format] fix alignment w/o binpacked args

[cha5on via Phabricator via cfe-commits]

cha5on updated this revision to Diff 428262.
cha5on added a comment.

Update for review

- Add and link bug report.
- Remove braces per LLVM style.
- Shrink down test case and add second case for direct-list-initialization 
alignment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125162

Files:
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -17280,6 +17280,33 @@
   //  "ccc ? a : b,\n"
   //  "dd);",
   //  Alignment);
+
+  // Confirm proper handling of AlignConsecutiveAssignments with
+  // BinPackArguments.
+  // See https://github.com/llvm/llvm-project/issues/55360
+  Alignment = getLLVMStyleWithColumns(50);
+  Alignment.AlignConsecutiveAssignments.Enabled = true;
+  Alignment.BinPackArguments = false;
+  verifyFormat("int a_long_name = 1;\n"
+   "auto b  = B({a_long_name, a_long_name},\n"
+   "{a_longer_name_for_wrap,\n"
+   " a_longer_name_for_wrap});",
+   "int a_long_name = 1;\n"
+   "auto b  = B({a_long_name,\n"
+   " a_long_name},\n"
+   " {a_longer_name_for_wrap,\n"
+   "a_longer_name_for_wrap});",
+   Alignment);
+  verifyFormat("int a_long_name = 1;\n"
+   "auto b  = B{{a_long_name, a_long_name},\n"
+   "{a_longer_name_for_wrap,\n"
+   " a_longer_name_for_wrap}};",
+   "int a_long_name = 1;\n"
+   "auto b  = B{{a_long_name,\n"
+   " a_long_name},\n"
+   " {a_longer_name_for_wrap,\n"
+   "a_longer_name_for_wrap}};",
+   Alignment);
 }
 
 TEST_F(FormatTest, AlignConsecutiveBitFields) {
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -371,6 +371,9 @@
 return false;
   if (Changes[ScopeStart].NewlinesBefore > 0)
 return false;
+  if (Changes[i].Tok->is(tok::l_brace) &&
+  Changes[i].Tok->is(BK_BracedInit))
+return true;
   return Style.BinPackArguments;
 }
 
@@ -387,6 +390,14 @@
 Changes[i].Tok->Previous->is(TT_ConditionalExpr))
   return true;
 
+// Continued direct-list-initialization using braced list.
+if (ScopeStart > Start + 1 &&
+Changes[ScopeStart - 2].Tok->is(tok::identifier) &&
+Changes[ScopeStart - 1].Tok->is(tok::l_brace) &&
+Changes[i].Tok->is(tok::l_brace) &&
+Changes[i].Tok->is(BK_BracedInit))
+  return true;
+
 // Continued braced list.
 if (ScopeStart > Start + 1 &&
 Changes[ScopeStart - 2].Tok->isNot(tok::identifier) &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -17280,6 +17280,33 @@
   //  "ccc ? a : b,\n"
   //  "dd);",
   //  Alignment);
+
+  // Confirm proper handling of AlignConsecutiveAssignments with
+  // BinPackArguments.
+  // See https://github.com/llvm/llvm-project/issues/55360
+  Alignment = getLLVMStyleWithColumns(50);
+  Alignment.AlignConsecutiveAssignments.Enabled = true;
+  Alignment.BinPackArguments = false;
+  verifyFormat("int a_long_name = 1;\n"
+   "auto b  = B({a_long_name, a_long_name},\n"
+   "{a_longer_name_for_wrap,\n"
+   " a_longer_name_for_wrap});",
+   "int a_long_name = 1;\n"
+   "auto b  = B({a_long_name,\n"
+   " a_long_name},\n"
+   " {a_longer_name_for_wrap,\n"
+   "a_longer_name_for_wrap});",
+   Alignment);
+  verifyFormat("int a_long_name = 1;\n"
+   "auto b  = B{{a_long_name, a_long_name},\n"
+   "{a_longer_name_for_wrap,\n"
+   " a_longer_name_for_wrap}};",
+   "int a_long_name = 1;\n"
+   "auto b  = B{{a_long_name,\n"
+   " a_long_name},\n"
+   " {a_longer_name_for_wrap,\n"
+   "a_longer_name_for_wrap}};",
+   Alig

[PATCH] D124149: [NFC] follow up code cleanup after D123837

[Chuanqi Xu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdebd9bf3f019: [NFC] follow up code cleanup after D123837 
(authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124149

Files:
  clang/lib/Sema/SemaLookup.cpp


Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1565,27 +1565,27 @@
   if (UsableModuleUnitsCache.count(M))
 return true;
 
-  // If M is the global module fragment of a module that we've not yet finished
-  // parsing, then M should be the global module fragment in current TU. So it
+  // If M is the global module fragment of the current translation unit. So it
   // should be usable.
   // [module.global.frag]p1:
   //   The global module fragment can be used to provide declarations that are
   //   attached to the global module and usable within the module unit.
-  if ((M->isGlobalModule() && !M->Parent) ||
-  // If M is the private module fragment, it is usable only if it is within
-  // the current module unit. And it must be the current parsing module 
unit
-  // if it is within the current module unit according to the grammar of 
the
-  // private module fragment.
-  // NOTE: This is covered by the following condition. The intention of the
-  // check is to avoid string comparison as much as possible.
-  (M->isPrivateModule() && M == getCurrentModule()) ||
+  if (M == GlobalModuleFragment ||
+  // If M is the module we're parsing, it should be usable. This covers the
+  // private module fragment. The private module fragment is usable only if
+  // it is within the current module unit. And it must be the current
+  // parsing module unit if it is within the current module unit according
+  // to the grammar of the private module fragment. NOTE: This is covered 
by
+  // the following condition. The intention of the check is to avoid string
+  // comparison as much as possible.
+  M == getCurrentModule() ||
   // The module unit which is in the same module with the current module
   // unit is usable.
   //
   // FIXME: Here we judge if they are in the same module by comparing the
   // string. Is there any better solution?
-  (M->getPrimaryModuleInterfaceName() ==
-   llvm::StringRef(getLangOpts().CurrentModule).split(':').first)) {
+  M->getPrimaryModuleInterfaceName() ==
+  llvm::StringRef(getLangOpts().CurrentModule).split(':').first) {
 UsableModuleUnitsCache.insert(M);
 return true;
   }
@@ -1781,31 +1781,14 @@
 
 bool Sema::isModuleVisible(const Module *M, bool ModulePrivate) {
   // The module might be ordinarily visible. For a module-private query, that
-  // means it is part of the current module. For any other query, that means it
-  // is in our visible module set.
-  if (ModulePrivate) {
-if (isUsableModule(M))
-  return true;
-else if (M->Kind == Module::ModuleKind::ModulePartitionImplementation &&
- isModuleDirectlyImported(M))
-  // Unless a partition implementation is directly imported it is not
-  // counted as visible for lookup, although the contained decls might
-  // still be reachable.  It's a partition, so it must be part of the
-  // current module to be a valid import.
-  return true;
-else if (getLangOpts().CPlusPlusModules && !ModuleScopes.empty() &&
- ModuleScopes[0].Module->Kind ==
- Module::ModuleKind::ModulePartitionImplementation &&
- ModuleScopes[0].Module->getPrimaryModuleInterfaceName() ==
- M->Name &&
- isModuleDirectlyImported(M))
-  // We are building a module implementation partition and the TU imports
-  // the primary module interface unit.
-  return true;
-  } else {
-if (VisibleModules.isVisible(M))
-  return true;
-  }
+  // means it is part of the current module.
+  if (ModulePrivate && isUsableModule(M))
+return true;
+
+  // For a query which is not module-private, that means it is in our visible
+  // module set.
+  if (!ModulePrivate && VisibleModules.isVisible(M))
+return true;
 
   // Otherwise, it might be visible by virtue of the query being within a
   // template instantiation or similar that is permitted to look inside M.


Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1565,27 +1565,27 @@
   if (UsableModuleUnitsCache.count(M))
 return true;
 
-  // If M is the global module fragment of a module that we've not yet finished
-  // parsing, then M should be the global module fragment in current TU. So it
+  // If M is the global module fragment of the current translation unit. So it
   

[clang] debd9bf - [NFC] follow up code cleanup after D123837

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-05-10T10:01:06+08:00
New Revision: debd9bf3f0198984cb4ae66c16758e0c8eeb2e9e

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

LOG: [NFC] follow up code cleanup after D123837

Reviewed By: iains

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

Added: 


Modified: 
clang/lib/Sema/SemaLookup.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaLookup.cpp b/clang/lib/Sema/SemaLookup.cpp
index 2a378741e7aa6..9f2e1eac41be6 100644
--- a/clang/lib/Sema/SemaLookup.cpp
+++ b/clang/lib/Sema/SemaLookup.cpp
@@ -1565,27 +1565,27 @@ bool Sema::isUsableModule(const Module *M) {
   if (UsableModuleUnitsCache.count(M))
 return true;
 
-  // If M is the global module fragment of a module that we've not yet finished
-  // parsing, then M should be the global module fragment in current TU. So it
+  // If M is the global module fragment of the current translation unit. So it
   // should be usable.
   // [module.global.frag]p1:
   //   The global module fragment can be used to provide declarations that are
   //   attached to the global module and usable within the module unit.
-  if ((M->isGlobalModule() && !M->Parent) ||
-  // If M is the private module fragment, it is usable only if it is within
-  // the current module unit. And it must be the current parsing module 
unit
-  // if it is within the current module unit according to the grammar of 
the
-  // private module fragment.
-  // NOTE: This is covered by the following condition. The intention of the
-  // check is to avoid string comparison as much as possible.
-  (M->isPrivateModule() && M == getCurrentModule()) ||
+  if (M == GlobalModuleFragment ||
+  // If M is the module we're parsing, it should be usable. This covers the
+  // private module fragment. The private module fragment is usable only if
+  // it is within the current module unit. And it must be the current
+  // parsing module unit if it is within the current module unit according
+  // to the grammar of the private module fragment. NOTE: This is covered 
by
+  // the following condition. The intention of the check is to avoid string
+  // comparison as much as possible.
+  M == getCurrentModule() ||
   // The module unit which is in the same module with the current module
   // unit is usable.
   //
   // FIXME: Here we judge if they are in the same module by comparing the
   // string. Is there any better solution?
-  (M->getPrimaryModuleInterfaceName() ==
-   llvm::StringRef(getLangOpts().CurrentModule).split(':').first)) {
+  M->getPrimaryModuleInterfaceName() ==
+  llvm::StringRef(getLangOpts().CurrentModule).split(':').first) {
 UsableModuleUnitsCache.insert(M);
 return true;
   }
@@ -1781,31 +1781,14 @@ bool LookupResult::isVisibleSlow(Sema &SemaRef, 
NamedDecl *D) {
 
 bool Sema::isModuleVisible(const Module *M, bool ModulePrivate) {
   // The module might be ordinarily visible. For a module-private query, that
-  // means it is part of the current module. For any other query, that means it
-  // is in our visible module set.
-  if (ModulePrivate) {
-if (isUsableModule(M))
-  return true;
-else if (M->Kind == Module::ModuleKind::ModulePartitionImplementation &&
- isModuleDirectlyImported(M))
-  // Unless a partition implementation is directly imported it is not
-  // counted as visible for lookup, although the contained decls might
-  // still be reachable.  It's a partition, so it must be part of the
-  // current module to be a valid import.
-  return true;
-else if (getLangOpts().CPlusPlusModules && !ModuleScopes.empty() &&
- ModuleScopes[0].Module->Kind ==
- Module::ModuleKind::ModulePartitionImplementation &&
- ModuleScopes[0].Module->getPrimaryModuleInterfaceName() ==
- M->Name &&
- isModuleDirectlyImported(M))
-  // We are building a module implementation partition and the TU imports
-  // the primary module interface unit.
-  return true;
-  } else {
-if (VisibleModules.isVisible(M))
-  return true;
-  }
+  // means it is part of the current module.
+  if (ModulePrivate && isUsableModule(M))
+return true;
+
+  // For a query which is not module-private, that means it is in our visible
+  // module set.
+  if (!ModulePrivate && VisibleModules.isVisible(M))
+return true;
 
   // Otherwise, it might be visible by virtue of the query being within a
   // template instantiation or similar that is permitted to look inside M.



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

[PATCH] D124149: [NFC] follow up code cleanup after D123837

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D124149#3500423 , @iains wrote:

> sorry for being slow, concentrating on module initialisers!
>
> this LGTM (but we can still probably make the visibility code cleaner - 
> perhaps after we get the main functionality installed).

Yeah, of course we need further cleaner code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124149

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

[PATCH] D124909: Fix issues with using clangd with C++ modules

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D124909#3501896 , @sammccall wrote:

> I think first steps are pretty high level, to understand:
>
> - what the goals are (e.g. performance, easier integration with build system, 
> work with modules syntax features, ...)

I'll start by suggesting (what seems to me is) a modest goal: a C++ project 
that wishes to use / start using Modules should be able to do so without 
breaking their developers' ability to use clangd to work on the project.

That is, clangd should be able to understand Modular code //somehow//; 
performance may not be optimal (e.g. clangd may have to parse modular headers 
from source rather than consuming a compiled module artifact), and it may 
require some extra configuration (e.g. developers may have to add things to 
`.clangd` to get the setup to work) -- those are areas where we can consider 
improvements (e.g. using a compiled module artifact if one is available) in the 
future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124909

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm added a comment.

In D124750#3502295 , @mehdi_amini 
wrote:

> You're telling me "what" while I'm actually more interested in the "why" here?

I'm not sure what your question is, with a "why". Let me think about this a 
bit. I'll get back to you.

> Same as before: this does not tell me why, can you provide an example where 
> this matters?

Sure. This is a bit lengthy. I'm really sorry for that !

So, lets start with some basic understanding here. Let's say I am writing a 
`matchAndRewrite()` function, where I take the following INPUT and convert it 
to the following OUTPUT:

INPUT:
a = div b, c
d = sub e, f
g = add d, a
h = const 0
i = mul h, g

OUTPUT:
i = some_op b, c, e, f

Now, when I'm writing a C++ code to match and rewrite:

If I only sort the `i = mul h, g` op, I get my canonicalized input as follows:

CANONICALIZED INPUT #1:

a = div b, c
d = sub e, f
g = add d, a
h = const 0
i = mul g, h

So, I'm basically sorting `i = mul h, g` to `i = mul g, h` using the utility 
and then writing the if-else statements to match the CANONICALIZED INPUT #1.
So, a psuedo code will be:

  if mul.operand[0].defOp != add OR mul.operand[1].defOp != const 0
return failure
  
  if add.operand[0].defOp != sub
if add.operand[0].defOp != div OR add.operand[1].defOp != sub
  return failure
else
  get the values of b, c, e, and f
  else if add.operand[1].defOp == div
get the values of b, c, e, and f
  else
return failure
  
  rewrite(mul, b, c, e, f)

But, if I had sorted the producers as well, my canonicalized input would be:
CANONICALIZED INPUT #2:

a = div b, c
d = sub e, f
g = add a, d
h = const 0
i = mul g, h

and thus my code will reduce to:

  if mul.operand[0].defOp !=  add OR mul.operand[1].defOp != const 0
return failure
  
  if add.operand[0].defOp != div OR add.operand[1].defOp != sub
return failure
  
  get the values of b, c, e, and f
  
  rewrite(mul, b, c, e, f)

So, in essence, we can see that the effort of an end user writing a C++ pattern 
has reduced if I sort the producers as well. But, one may argue that I could 
have sorted the `add` op after seeing it and then my if-else statements would 
reduce. So, the above illustration doesn't explain why we sort the producers.

The real reason for sorting the producers is that, if such a thing is not done, 
the sorting and this entire utility will be virtually useless. A deterministic 
sorting of an op requires its producers to be sorted. Our sorting algorithm is 
based on the breadth-first traversal of backard slices. One the same level of 
DAG, the traversal looks at operands from the first to the last. That is how 
the breadth-first traversal is defined here. Now, if this traversal is 
non-deterministic, then, the whole use of sorting something will collapse. 
**Maybe, this can be BEST explained with the below example.**

If I have this IR:
d = div b, c
s = sub e, f
x = xor k, l
g = add s, d
h = add d, x
i = add g, h

Then, `i = add g, h` will be sorted to `i = add g, h` (no change).

**But**, when I have the below IR (which is functionally the same as the above 
IR):
d = div b, c
s = sub e, f
x = xor k, l
g = add d, s
h = add d, x
i = add g, h

Then, `i = add g, h` will be sorted to `i = add h, g`.

So, we have two functionally same IRs being sorted differently. This is clearly 
not useful. The sorting depends on what the input IR is. So, even after 
sorting, we still have functionally same IRs that look different. So, the 
pattern matcher (a human) still has to write an excessive number of if-else 
statements to match the input. This is exactly what this sorting was supposed 
to avoid. This is as good as not having done any sorting at all!

Is the motivation clear now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:2
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new --target=x86_64-linux-gnu -emit-llvm -S %s -o - | 
opt -S -mem2reg | FileCheck %s
+

Not sure how this doesn't need -Xclang -disable-O0-optnone to work?..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Pedro Falcato via Phabricator via cfe-commits]

heatd added inline comments.



Comment at: clang/test/Driver/clang_f_opts.c:73
 
-
 // RUN: %clang -### -S -fauto-profile=%S/Inputs/file.prof %s 2>&1 | FileCheck 
-check-prefix=CHECK-AUTO-PROFILE %s

jrtc27 wrote:
> Hmmm
Huh, running clang-format on clang_f_opts.c makes it do that. I fixed that up 
in the new revision but that should possibly be fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:1
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new --target=x86_64-linux-gnu -emit-llvm -S %s -o - | 
opt -S -mem2reg | FileCheck %s

Not sure why they were checked before, but you'll need this to actually get the 
attributes checked


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Pedro Falcato via Phabricator via cfe-commits]

heatd updated this revision to Diff 428254.
heatd added a comment.

Re-did the test, deleted redundant minus line diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenCXX/fcheck-new.cpp
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -298,7 +298,6 @@
 // RUN: -fno-reorder-blocks -freorder-blocks  \
 // RUN: -fno-schedule-insns2 -fschedule-insns2\
 // RUN: -fno-stack-check  \
-// RUN: -fno-check-new -fcheck-new\
 // RUN: -ffriend-injection\
 // RUN: -fno-implement-inlines -fimplement-inlines\
 // RUN: -fstack-check \
Index: clang/test/CodeGenCXX/fcheck-new.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fcheck-new.cpp
@@ -0,0 +1,10 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new --target=x86_64-linux-gnu -emit-llvm -S %s -o - | opt -S -mem2reg | FileCheck %s
+
+// CHECK-LABEL: @_Z5test0v(
+// CHECK-NEXT:[[TMP1:%.*]] = call noalias noundef ptr @_Znwm(i64 noundef 4) #[[ATTR2:[0-9]+]]
+// CHECK-NEXT:ret ptr [[TMP1]]
+//
+int *test0() {
+  return new int;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -3104,7 +3104,8 @@
 // Global allocation functions should always be visible.
 Alloc->setVisibleDespiteOwningModule();
 
-if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible)
+if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible &&
+!getLangOpts().CheckNew)
   Alloc->addAttr(
   ReturnsNonNullAttr::CreateImplicit(Context, Alloc->getLocation()));
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -15436,7 +15436,11 @@
   //   indicates failure by returning a null pointer value. Any other allocation
   //   function never returns a null pointer value and indicates failure only by
   //   throwing an exception [...]
-  if (!IsNothrow && !FD->hasAttr())
+  //
+  // However, -fcheck-new violates this possible assumption, so don't add
+  // NonNull when that is enabled.
+  if (!IsNothrow && !FD->hasAttr() &&
+  !getLangOpts().CheckNew)
 FD->addAttr(ReturnsNonNullAttr::CreateImplicit(Context, FD->getLocation()));
 
   // C++2a [basic.stc.dynamic.allocation]p2:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4113,6 +4113,9 @@
   if (const Arg *A = Args.getLastArg(OPT_frandomize_layout_seed_EQ))
 Opts.RandstructSeed = A->getValue(0);
 
+  if (const Arg *A = Args.getLastArg(OPT_fcheck_new))
+Opts.CheckNew = true;
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5981,6 +5981,9 @@
   options::OPT_fno_emulated_tls);
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
+  if (Args.hasFlag(options::OPT_fcheck_new, options::OPT_fno_check_new, false))
+CmdArgs.push_back("-fcheck-new");
+
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {
 // FIXME: There's no reason for this to be restricted to X86. The backend
 // code needs to be changed to include the appropriate function calls
Index: clang/lib/AST/ExprCXX.cpp
===
--- clang/lib/AST/ExprCXX.cpp
+++ clang/lib/AST/ExprCXX.cpp
@@ -275,6 +275,8 @@
 }
 
 bool CXXNewExpr::shouldNullCheckAllocation() const {
+  if (getOperatorNew()->getLangOpts().CheckNew)
+return true;
   return !getOperatorNew()->hasAttr() &&
  getOperatorNew()
  ->getType()
Index: clang/include/clang/Driver/Options.td
==

[PATCH] D125272: [clang] Add -fcheck-new support

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:2
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new -emit-llvm -S %s -o - -O2 | FileCheck %s
+

heatd wrote:
> jrtc27 wrote:
> > Do you really want -O2 or do you just want to run mem2reg to eliminate all 
> > the alloca noise?
> I added -O2 because I was testing with it, since if -fcheck-new doesn't work, 
> it's way more noticeable, as the nullptr check gets optimized out; if it 
> works, the branching is pretty visible and shows exactly what the option 
> does. Also, to eliminate all the noise :) I can definitely remove -O2 though, 
> if you want to.
Thinking about this more, I think the branching complicates matters. All that 
optimisation happens in LLVM IR land, but you're just touching Clang CodeGen. 
Is `int *foo() { return new int; }` checking the attributes on the call to 
_Znwm not enough (and with mem2reg just to clean it up so the function body is 
trivial)?

Also you should specify a target triple as this will just be 
LLVM_DEFAULT_TARGET_TRIPLE and change both the type for new (i32 vs i64) and 
its mangling (j vs m for unsigned int vs unsigned long, and *-windows-msvc is 
totally different), right?



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:9
+// CHECK:   3:
+// CHECK-NEXT:store i32 48879, ptr [[TMP1]], align 4, !tbaa 
[[TBAA5:![0-9]+]]
+// CHECK-NEXT:br label [[TMP4]]

Another advantage of not using -O2 is you lose the TBAA noise



Comment at: clang/test/Driver/clang_f_opts.c:73
 
-
 // RUN: %clang -### -S -fauto-profile=%S/Inputs/file.prof %s 2>&1 | FileCheck 
-check-prefix=CHECK-AUTO-PROFILE %s

Hmmm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Pedro Falcato via Phabricator via cfe-commits]

heatd added inline comments.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:2
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new -emit-llvm -S %s -o - -O2 | FileCheck %s
+

jrtc27 wrote:
> Do you really want -O2 or do you just want to run mem2reg to eliminate all 
> the alloca noise?
I added -O2 because I was testing with it, since if -fcheck-new doesn't work, 
it's way more noticeable, as the nullptr check gets optimized out; if it works, 
the branching is pretty visible and shows exactly what the option does. Also, 
to eliminate all the noise :) I can definitely remove -O2 though, if you want 
to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In D124750#3502228 , @srishti-pm 
wrote:

> In D124750#3500748 , @mehdi_amini 
> wrote:
>
>> Seems like this should be added to canonicalization? The "push constants to 
>> the right hand side" is there already.
>
> I think this was not added to canonicalization because we wanted it to be an 
> independent utility that can be used if needed and not be used if not needed.

You're telling me "what" while I'm actually more interested in the "why" here?

>> I also don't understand the complexity of the implementation, I may need an 
>> example to understand why you're recursively operating on the producer ops 
>> for the operands.
>> From the revision description: (1) the operands defined by non-constant-like 
>> ops come first, followed by (2) block arguments, and these are followed by 
>> (3) the operands defined by constant-like ops` which all seems like a fairly 
>> local check: a stable-sort on the operands would be deterministic and local 
>> to a single operation.
>
> I do this because, firstly, in the description, if you look below this 
> paragraph, you will see the following:
> "And, if two operands come from the same op, the function backtracks and
> looks even further to sort them. This backtracking is done over the
> backward slice of the operand, in a breadth-first traversal."

Same as before: this does not tell me why, can you provide an example where 
this matters?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm updated this revision to Diff 428240.
srishti-pm added a comment.

Within constant-like ops, removed the requirement for them being sorted 
alphabetically. Basically, all constants will be treated as equals by the 
sorting algorithm and it will not distinguish between, say, `arith.constant` 
and `tf.Const`. This is because multiple canonicalizations exist in various 
dialects that push the constants to the right but do not make any distinction 
among constants. So, since we want this utility to not clash with those 
canonicalizations, this is being done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

Files:
  clang/docs/tools/clang-formatted-files.txt
  mlir/include/mlir/Transforms/CommutativityUtils.h
  mlir/lib/Transforms/Utils/CMakeLists.txt
  mlir/lib/Transforms/Utils/CommutativityUtils.cpp
  mlir/test/Transforms/test-commutativity-utils.mlir
  mlir/test/lib/Dialect/Test/TestOps.td
  mlir/test/lib/Transforms/CMakeLists.txt
  mlir/test/lib/Transforms/TestCommutativityUtils.cpp
  mlir/tools/mlir-opt/mlir-opt.cpp

Index: mlir/tools/mlir-opt/mlir-opt.cpp
===
--- mlir/tools/mlir-opt/mlir-opt.cpp
+++ mlir/tools/mlir-opt/mlir-opt.cpp
@@ -56,6 +56,7 @@
 void registerVectorizerTestPass();
 
 namespace test {
+void registerCommutativityUtils();
 void registerConvertCallOpPass();
 void registerInliner();
 void registerMemRefBoundCheck();
@@ -146,6 +147,7 @@
   registerVectorizerTestPass();
   registerTosaTestQuantUtilAPIPass();
 
+  mlir::test::registerCommutativityUtils();
   mlir::test::registerConvertCallOpPass();
   mlir::test::registerInliner();
   mlir::test::registerMemRefBoundCheck();
Index: mlir/test/lib/Transforms/TestCommutativityUtils.cpp
===
--- /dev/null
+++ mlir/test/lib/Transforms/TestCommutativityUtils.cpp
@@ -0,0 +1,67 @@
+//===- TestCommutativityUtils.cpp - Pass to test the commutativity utility-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This pass tests the functionality of the commutativity utility.
+//
+//===--===//
+
+#include "mlir/Transforms/CommutativityUtils.h"
+
+#include "TestDialect.h"
+#include "mlir/Pass/Pass.h"
+#include "mlir/Transforms/GreedyPatternRewriteDriver.h"
+
+using namespace mlir;
+using namespace test;
+
+namespace {
+
+struct SmallPattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestCommutativeOp testCommOp,
+PatternRewriter &rewriter) const override {
+sortCommutativeOperands(testCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct LargePattern : public OpRewritePattern {
+  using OpRewritePattern::OpRewritePattern;
+  LogicalResult matchAndRewrite(TestLargeCommutativeOp testLargeCommOp,
+PatternRewriter &rewriter) const override {
+sortCommutativeOperands(testLargeCommOp.getOperation(), rewriter);
+return success();
+  }
+};
+
+struct CommutativityUtils
+: public PassWrapper> {
+  MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(CommutativityUtils)
+
+  StringRef getArgument() const final { return "test-commutativity-utils"; }
+  StringRef getDescription() const final {
+return "Test the functionality of the commutativity utility";
+  }
+
+  void runOnOperation() override {
+auto func = getOperation();
+auto *context = &getContext();
+
+RewritePatternSet patterns(context);
+patterns.add(context);
+
+(void)applyPatternsAndFoldGreedily(func, std::move(patterns));
+  }
+};
+} // namespace
+
+namespace mlir {
+namespace test {
+void registerCommutativityUtils() { PassRegistration(); }
+} // namespace test
+} // namespace mlir
Index: mlir/test/lib/Transforms/CMakeLists.txt
===
--- mlir/test/lib/Transforms/CMakeLists.txt
+++ mlir/test/lib/Transforms/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Exclude tests from libMLIR.so
 add_mlir_library(MLIRTestTransforms
+  TestCommutativityUtils.cpp
   TestConstantFold.cpp
   TestControlFlowSink.cpp
   TestInlining.cpp
Index: mlir/test/lib/Dialect/Test/TestOps.td
===
--- mlir/test/lib/Dialect/Test/TestOps.td
+++ mlir/test/lib/Dialect/Test/TestOps.td
@@ -1101,11 +1101,21 @@
   let hasFolder = 1;
 }
 
+def TestAddIOp : TEST_Op<"addi"> {
+  let arguments = (ins I32:$op1, I32:$op2);
+  let results = (outs I32);
+}
+
 def TestCommutativeOp : TEST_Op<"op_commutative", [Commutative]> {

[PATCH] D124147: [clang][cmake] correct grammar and style inconsistency

[Mohammed Keyvanzadeh via Phabricator via cfe-commits]

VoltrexMaster updated this revision to Diff 428235.
VoltrexMaster added a comment.

Rebase and add upstream changes.


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

https://reviews.llvm.org/D124147

Files:
  clang/CMakeLists.txt

Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -1,6 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
 
-# If we are not building as a part of LLVM, build Clang as an
+# If we are not building as a part of LLVM, build Clang as a
 # standalone project, using LLVM as an external library:
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   project(Clang)
@@ -11,7 +11,7 @@
 include(GNUInstallDirs)
 
 if(CLANG_BUILT_STANDALONE)
-  set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
+  set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to.")
   set(CMAKE_CXX_STANDARD_REQUIRED YES)
   set(CMAKE_CXX_EXTENSIONS NO)
 
@@ -21,7 +21,7 @@
 set (LLVM_CONFIG_FOUND 1)
 message(STATUS "Found LLVM_CONFIG as ${LLVM_CONFIG}")
 message(DEPRECATION "Using llvm-config to detect the LLVM installation is \
-  deprecated.  The installed cmake files should be used \
+  deprecated.  The installed CMake files should be used \
   instead.  CMake should be able to detect your LLVM install \
   automatically, but you can also use LLVM_DIR to specify \
   the path containing LLVMConfig.cmake.")
@@ -65,7 +65,7 @@
 
   if(NOT MSVC_IDE)
 set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
-  CACHE BOOL "Enable assertions")
+  CACHE BOOL "Enable assertions.")
 # Assertions should follow llvm-config's.
 mark_as_advanced(LLVM_ENABLE_ASSERTIONS)
   endif()
@@ -75,7 +75,7 @@
 
   # We can't check LLVM_CONFIG here, because find_package(LLVM ...) also sets
   # LLVM_CONFIG.
-  if (NOT LLVM_CONFIG_FOUND)
+  if(NOT LLVM_CONFIG_FOUND)
 # Pull values from LLVMConfig.cmake.  We can drop this once the llvm-config
 # path is removed.
 set(MAIN_INCLUDE_DIR "${LLVM_INCLUDE_DIR}")
@@ -86,11 +86,11 @@
 set(LIBRARY_DIR "${LLVM_LIBRARY_DIR}")
   endif()
 
-  set(LLVM_MAIN_INCLUDE_DIR "${MAIN_INCLUDE_DIR}" CACHE PATH "Path to llvm/include")
-  set(LLVM_BINARY_DIR "${LLVM_OBJ_ROOT}" CACHE PATH "Path to LLVM build tree")
-  set(LLVM_MAIN_SRC_DIR "${MAIN_SRC_DIR}" CACHE PATH "Path to LLVM source tree")
-  set(LLVM_TOOLS_BINARY_DIR "${TOOLS_BINARY_DIR}" CACHE PATH "Path to llvm/bin")
-  set(LLVM_LIBRARY_DIR "${LIBRARY_DIR}" CACHE PATH "Path to llvm/lib")
+  set(LLVM_MAIN_INCLUDE_DIR "${MAIN_INCLUDE_DIR}" CACHE PATH "Path to llvm/include.")
+  set(LLVM_BINARY_DIR "${LLVM_OBJ_ROOT}" CACHE PATH "Path to LLVM build tree.")
+  set(LLVM_MAIN_SRC_DIR "${MAIN_SRC_DIR}" CACHE PATH "Path to LLVM source tree.")
+  set(LLVM_TOOLS_BINARY_DIR "${TOOLS_BINARY_DIR}" CACHE PATH "Path to llvm/bin.")
+  set(LLVM_LIBRARY_DIR "${LIBRARY_DIR}" CACHE PATH "Path to llvm/lib.")
 
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
@@ -110,7 +110,7 @@
 
   option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
 "Set to ON to force using an old, unsupported host toolchain." OFF)
-  option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
+  option(CLANG_ENABLE_BOOTSTRAP "Generate the Clang bootstrap target." OFF)
   option(LLVM_ENABLE_LIBXML2 "Use libxml2 if available." ON)
 
   include(AddLLVM)
@@ -124,16 +124,16 @@
   set(BUG_REPORT_URL "${LLVM_PACKAGE_BUGREPORT}" CACHE STRING
 "Default URL where bug reports are to be submitted.")
 
-  if (NOT DEFINED LLVM_INCLUDE_TESTS)
+  if(NOT DEFINED LLVM_INCLUDE_TESTS)
 set(LLVM_INCLUDE_TESTS ON)
   endif()
 
   include_directories("${LLVM_BINARY_DIR}/include" "${LLVM_MAIN_INCLUDE_DIR}")
   link_directories("${LLVM_LIBRARY_DIR}")
 
-  set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin )
-  set( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} )
-  set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX} )
+  set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
+  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
+  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
 
   if(LLVM_INCLUDE_TESTS)
 find_package(Python3 ${LLVM_MINIMUM_PYTHON_VERSION} REQUIRED
@@ -147,7 +147,7 @@
 endif()
 
 if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
-  # Note: path not really used, except for checking if lit was found
+  # Note: path not really used, except for checking if Lit was found.
   set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/llvm-lit)
 add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit utils/llvm-lit)
@@ -170,7 +170,7 @@
   find_program(LLVM_LIT
NAMES llvm-lit lit.py lit
PATHS "${LLVM_MA

[PATCH] D124750: [MLIR] Add a utility to sort the operands of commutative ops

[Srishti Srivastava via Phabricator via cfe-commits]

srishti-pm added a comment.

In D124750#3500748 , @mehdi_amini 
wrote:

> Seems like this should be added to canonicalization? The "push constants to 
> the right hand side" is there already.

I think this was not added to canonicalization because we wanted it to be an 
independent utility that can be used if needed and not be used if not needed. 
Yes, the "push constants to the right hand side" is there already and that's 
actually the reason why this utility also pushes the constants to the right. I 
didn't want this utility to do something else and clash with the "push 
constants to the right hand side" canonicalization if and when both were being 
used together. So, when we decided what our sorting order will be, we made sure 
that this order kept constants to the right. For more context, you could refer 
to this RFC's discussion, starting from this comment: 
https://discourse.llvm.org/t/mlir-pdl-extending-pdl-pdlinterp-bytecode-to-enable-commutative-matching/60798/12?u=srishtisrivastava.

But, note this:
Right now, the code shows that I am sorting the constants alphabetically (as 
in, theoretically, we can say that `arith.constant` comes before `tf.Const`). I 
will remove this "alphabetical sorting" among the constants. It isn't 
consistent with the existing "pushing of constants" and moreover adds 
unnecessary computation too. I'll ensure that the sorting is stable and pushes 
all the constants to the right.

> I also don't understand the complexity of the implementation, I may need an 
> example to understand why you're recursively operating on the producer ops 
> for the operands.
> From the revision description: (1) the operands defined by non-constant-like 
> ops come first, followed by (2) block arguments, and these are followed by 
> (3) the operands defined by constant-like ops` which all seems like a fairly 
> local check: a stable-sort on the operands would be deterministic and local 
> to a single operation.

I do this because, firstly, in the description, if you look below this 
paragraph, you will see the following:
"And, if two operands come from the same op, the function backtracks and
looks even further to sort them. This backtracking is done over the
backward slice of the operand, in a breadth-first traversal."

So, in essence, we are looking at the entire origin of each of the operands, in 
a breadth-first fashion, to decide the ordering of the operands. Secondly, we 
need to sort the producers of the operands so that we have a deterministic 
sorting (because if the producers are not sorted, we don't know if we are doing 
the right sorting or not, even if we are looking at the entire backward slice). 
This is because since the producers are not sorted, the breadth-first traversal 
becomes non-deterministic to a user who is writing a pattern matching function 
(say, `matchAndRewrite()`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124750

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

[PATCH] D124435: [X86] Always extend the integer parameters in callee

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:3028
+extend the small integer argument in both caller and callee. Using other
+value can disable this, which may improve performance and code size.
+

> Specifies how to handle small integer arguments on i386 and x86_64
> targets that generally follow the System V ABI.  The value must be ``none``,
> ``conservative``, ``assumed``, or ``default``. The default behavior
> depends on the target and can be explicitly requested with ``default``.
> 
> In the past, on System V i386 and x86_64 targets, Clang passed promotable
> integer arguments (non-variadic arguments with types smaller than 'int')
> using a parameter convention in which the caller was assumed to have
> sign-extended or zero-extended the argument to the width of an 'int'. This
> convention did not conform to the documented ABI for these targets, which
> does not require the caller to perform this extension.  This can introduce
> incompatibilities with code generated by other compilers on these targets.
>
> On most targets using the System V ABI, Clang no longer assumes that
> callers perform this extension.  In order to maintain compatibility with
> code compiled by old versions of Clang, Clang will still perform the extension
> in the caller.  This is the ``conservative`` behavior.  If compatibility with 
> old
> Clang code is not required, extension in the caller can be disabled using
> ``none``, which may have minor performance and code-size benefits.
>
> On certain targets which use Clang as the system compiler, Clang continues
> to perform extension in the caller and assume it in in the callee.  This is 
> the
> behavior of ``assumed``.  These platforms therefore diverge from the
> standard System V ABI.  If compatibility with other compilers which do not
> recognize this divergence is required, ``conservative`` may be used.
> Using ``none`` on these targets is allowed but may lead to ABI mismatches.
> These targets include Apple and PlayStation platforms.



Comment at: clang/include/clang/Driver/Options.td:3338
+   "'none' (Pass the small integer parameter directly in caller) | "
+   "'conserative' (Always extend small integer parameter in the caller 
but do not assume "
+   "in the callee that the caller actually did the extension) | "





Comment at: clang/lib/CodeGen/TargetInfo.cpp:1938
+return IsConservativeExtend ? ABIArgInfo::getConservativeExtend(Ty)
+: ABIArgInfo::getExtend(Ty);
   }

rjmccall wrote:
> LiuChen3 wrote:
> > rjmccall wrote:
> > > LiuChen3 wrote:
> > > > rjmccall wrote:
> > > > > This looks wrong.  In non-`ConservativeExtend` mode, we don't get to 
> > > > > assume extension at all and should use `Direct`, right?
> > > > As I understand it, `Direct` means do nothing with the parameters. 
> > > > Caller won't do the extension and callee can't assume the parameter is 
> > > > correct. This makes new clang behave in the opposite way to currently 
> > > > clang behavior, which will cause incompatibility issue. e.g:
> > > > https://godbolt.org/z/d3Peq4nsG
> > > Oh, I see, you're thinking that `-mno-conservative-extend` means "do what 
> > > old versions of clang did" rather than "break compatibility with old 
> > > versions of clang and just follow the x86_64 ABI".  That's definitely 
> > > different from the documentation I suggested, so something's got to 
> > > change.
> > > 
> > > I think these are the possibilities here:
> > > 
> > > 1. Some platforms, like Apple's, are probably going to define Clang's 
> > > current behavior as the platform ABI.  So those platforms need to 
> > > continue to use `Extend`.  My previous comment about using `Direct` 
> > > wasn't paying due attention to this case.
> > > 
> > > 2. On other platforms, we need to maintain compatibility by default with 
> > > both the platform ABI and old Clang behavior.  Those platforms will need 
> > > to use `ConservativeExtend`.
> > > 
> > > 3. Some people may want to opt out of (2) and just be compatible with the 
> > > platform ABI, which has minor code-size and performance wins.  If we 
> > > support that with an option, I believe it should cause us to emit 
> > > `Direct`.  This is what I was thinking `-mno-conservative-extend` would 
> > > mean.
> > > 
> > > 4. Some people may want to force the use of (1) even on platforms where 
> > > that isn't the platform ABI.  I don't know if this is really something we 
> > > should support in the long term, but it might be valuable for people 
> > > staging this change in.  This is what you seem to be thinking 
> > > `-mno-conservative-extend` would mean.
> > > 
> > > I would suggest these spellings for the argument, instead of making it 
> > > boolean:
> > > 
> > > ```
> > > -mextend-small-integers=none// Force the use of Direct
> > > -mextend-small-integers=conser

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

[John McCall via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124736

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

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

[Daniel Bertalan via Phabricator via cfe-commits]

BertalanD updated this revision to Diff 428225.
BertalanD added a comment.

Use ABI alignment for allocating operator new as well.

Sorry for the delay.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124736

Files:
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/test/CodeGenCXX/pr54845.cpp


Index: clang/test/CodeGenCXX/pr54845.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/pr54845.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple i686-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// https://github.com/llvm/llvm-project/issues/54845
+
+void *operator new(unsigned int, void *);
+
+void test(double *d) {
+  // This store used to have an alignment of 8, which was incorrect as
+  // the i386 psABI only guarantees a 4-byte alignment for doubles.
+
+  // CHECK: store double 0.00e+00, {{.*}}, align 4
+  new (d) double(0);
+}
Index: clang/lib/CodeGen/CGExprCXX.cpp
===
--- clang/lib/CodeGen/CGExprCXX.cpp
+++ clang/lib/CodeGen/CGExprCXX.cpp
@@ -1573,7 +1573,7 @@
   llvm::Value *allocSize =
 EmitCXXNewAllocSize(*this, E, minElements, numElements,
 allocSizeWithoutCookie);
-  CharUnits allocAlign = getContext().getPreferredTypeAlignInChars(allocType);
+  CharUnits allocAlign = getContext().getTypeAlignInChars(allocType);
 
   // Emit the allocation call.  If the allocator is a global placement
   // operator, just "inline" it directly.


Index: clang/test/CodeGenCXX/pr54845.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/pr54845.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple i686-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// https://github.com/llvm/llvm-project/issues/54845
+
+void *operator new(unsigned int, void *);
+
+void test(double *d) {
+  // This store used to have an alignment of 8, which was incorrect as
+  // the i386 psABI only guarantees a 4-byte alignment for doubles.
+
+  // CHECK: store double 0.00e+00, {{.*}}, align 4
+  new (d) double(0);
+}
Index: clang/lib/CodeGen/CGExprCXX.cpp
===
--- clang/lib/CodeGen/CGExprCXX.cpp
+++ clang/lib/CodeGen/CGExprCXX.cpp
@@ -1573,7 +1573,7 @@
   llvm::Value *allocSize =
 EmitCXXNewAllocSize(*this, E, minElements, numElements,
 allocSizeWithoutCookie);
-  CharUnits allocAlign = getContext().getPreferredTypeAlignInChars(allocType);
+  CharUnits allocAlign = getContext().getTypeAlignInChars(allocType);
 
   // Emit the allocation call.  If the allocator is a global placement
   // operator, just "inline" it directly.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111548: [Clang] Add the `annotate_type` attribute

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/test/SemaCXX/annotate-type.cpp:2
+// RUN: %clang_cc1 %s -std=c++17 -fsyntax-only -verify
+
+struct S1 {

mboehme wrote:
> aaron.ballman wrote:
> > mboehme wrote:
> > > aaron.ballman wrote:
> > > > mboehme wrote:
> > > > > aaron.ballman wrote:
> > > > > > mboehme wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > mboehme wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > mboehme wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > Can you also add some test coverage for applying the 
> > > > > > > > > > > > attribute to a declaration instead of a type or not 
> > > > > > > > > > > > giving it any arguments? Also, should test arguments 
> > > > > > > > > > > > which are not a constant expression.
> > > > > > > > > > > I've added tests as you suggested, though I put most of 
> > > > > > > > > > > them in Sema/annotate-type.c, as they're not specific to 
> > > > > > > > > > > C++.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks for prompting me to do this -- the tests caused me 
> > > > > > > > > > > to notice and fix a number of bugs.
> > > > > > > > > > > 
> > > > > > > > > > > I haven't managed to diagnose the case when the attribute 
> > > > > > > > > > > appears at the beginning of the declaration. It seems to 
> > > > > > > > > > > me that, at the point where I've added the check, this 
> > > > > > > > > > > case is indistinguishable from an attribute that appears 
> > > > > > > > > > > on the type. In both cases, the `TAL` is `TAL_DeclSpec`, 
> > > > > > > > > > > and the attribute is contained in 
> > > > > > > > > > > `DeclSpec::getAttributes()`. This is because 
> > > > > > > > > > > `Parser::ParseSimpleDeclaration` forwards the declaration 
> > > > > > > > > > > attributes to the `DeclSpec`:
> > > > > > > > > > > 
> > > > > > > > > > > https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L1851
> > > > > > > > > > > 
> > > > > > > > > > > I believe if I wanted to prohibit this case, I would need 
> > > > > > > > > > > to add a check to `Parser::ParseStatementOrDeclaration` 
> > > > > > > > > > > and prohibit any occurrences of `annotate_type` there. 
> > > > > > > > > > > However, this seems the wrong place to do this because it 
> > > > > > > > > > > doesn't contain any specific processing for other 
> > > > > > > > > > > attributes.
> > > > > > > > > > > 
> > > > > > > > > > > I've noticed that Clang also doesn't prohibit other type 
> > > > > > > > > > > attributes (even ones with C++ 11 syntax) from being 
> > > > > > > > > > > applied to declarations. For example: 
> > > > > > > > > > > https://godbolt.org/z/Yj1zWY7nn
> > > > > > > > > > > 
> > > > > > > > > > > How do you think I should proceed here? I think the 
> > > > > > > > > > > underlying issue is that Clang doesn't always distinguish 
> > > > > > > > > > > cleanly between declaration attributes and type 
> > > > > > > > > > > attributes, and fixing this might be nontrivial.
> > > > > > > > > > > How do you think I should proceed here? I think the 
> > > > > > > > > > > underlying issue is that Clang doesn't always distinguish 
> > > > > > > > > > > cleanly between declaration attributes and type 
> > > > > > > > > > > attributes, and fixing this might be nontrivial.
> > > > > > > > > > 
> > > > > > > > > > This is a general issue with attribute processing. I would 
> > > > > > > > > > imagine that SemaDeclAttr.cpp should be able to diagnose 
> > > > > > > > > > that case when the attribute only applies to types and not 
> > > > > > > > > > declarations, but it'd take some investigation for me to be 
> > > > > > > > > > sure.
> > > > > > > > > > 
> > > > > > > > > > Because this issue isn't new to your situation, I'd 
> > > > > > > > > > recommend filing an issue about the general problem and 
> > > > > > > > > > then we can solve that later.
> > > > > > > > > I've done some more investigation myself, and I think I've 
> > > > > > > > > come up with a solution; actually, two potential solutions. I 
> > > > > > > > > have draft patches for both of these; I wanted to run these 
> > > > > > > > > by you here first, so I haven't opened a bug yet.
> > > > > > > > > 
> > > > > > > > > I'd appreciate your input on how you'd prefer me to proceed 
> > > > > > > > > with this. I do think it makes sense to do this work now 
> > > > > > > > > because otherwise, people will start putting `annotate_type` 
> > > > > > > > > in places where it doesn't belong, and then we'll have to 
> > > > > > > > > keep supporting that in the future.
> > > > > > > > > 
> > > > > > > > > **My preferred solution**
> > > > > > > > > 
> > > > > > > > > https://reviews.llvm.org/D124081
> > > > > > > > > 
> > > > > > > > > This adds a function `DiagnoseCXX11NonDeclAttrs()` and calls 
> > > > > > > > > it in all places where we should reject attributes that can't 
> > > > > > > > > be put on declarations. (As part of this w

[PATCH] D125272: [clang] Add -fcheck-new support

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/test/CodeGenCXX/fcheck-new.cpp:2
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new -emit-llvm -S %s -o - -O2 | FileCheck %s
+

Do you really want -O2 or do you just want to run mem2reg to eliminate all the 
alloca noise?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125272

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Kees Cook via Phabricator via cfe-commits]

kees updated this revision to Diff 428224.
kees edited the summary of this revision.
kees added a comment.

add release notes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -569,18 +569,19 @@
 
 // RUN: %clang -### -S -ftrivial-auto-var-init=uninitialized %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-UNINIT %s
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-GOOD %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-BAD %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO %s
+// RUN: %clang -### -S -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang \
+// RUN:   -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-ENABLE-DEPRECATED %s
 // CHECK-TRIVIAL-UNINIT-NOT: hasn't been enabled
 // CHECK-TRIVIAL-PATTERN-NOT: hasn't been enabled
-// CHECK-TRIVIAL-ZERO-GOOD-NOT: hasn't been enabled
-// CHECK-TRIVIAL-ZERO-BAD: hasn't been enabled
+// CHECK-TRIVIAL-ZERO-NOT: hasn't been enabled
+// CHECK-TRIVIAL-ZERO-ENABLE-DEPRECATED: has been deprecated
 
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN-STOP-AFTER %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER %s
 // RUN: %clang -### -S -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-STOP-AFTER-MISSING-DEPENDENCY %s
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN-STOP-AFTER-INVALID-VALUE %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER-INVALID-VALUE %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER-INVALID-VALUE %s
 // CHECK-TRIVIAL-PATTERN-STOP-AFTER-NOT: is used without '-ftrivial-auto-var-init'
 // CHECK-TRIVIAL-PATTERN-STOP-AFTER-NOT: only accepts positive integers
 // CHECK-TRIVIAL-ZERO-STOP-AFTER-NOT: is used without '-ftrivial-auto-var-init'
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -734,7 +734,6 @@
 // RUN: -fimplicit-modules \
 // RUN: -fno-implicit-modules \
 // RUN: -ftrivial-auto-var-init=zero \
-// RUN: -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang \
 // RUN: --version \
 // RUN: -Werror /Zs -- %s 2>&1
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3411,8 +3411,9 @@
 }
 
   if (!TrivialAutoVarInit.empty()) {
-if (TrivialAutoVarInit == "zero" && !Args.hasArg(options::OPT_enable_trivial_var_init_zero))
-  D.Diag(diag::err_drv_trivial_auto_var_init_zero_disabled);
+if (TrivialAutoVarInit == "zero" && Args.hasArg(options::OPT_enable_trivial_var_init_zero))
+  D.Diag(diag::warn_ignored_clang_option)
+  << "-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang";
 CmdArgs.push_back(
 Args.MakeArgString("-ftrivial-auto-var-init=" + TrivialAutoVarInit));
   }
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2697,9 +2697,10 @@
   NormalizedValuesScope<"LangOptions::TrivialAutoVarInitKind">,
   NormalizedValues<["Uninitial

[clang] 42915e2 - [gn build] (manually) port a2f2dfde48ac (clang-fuzzer-dictionary)

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2022-05-09T18:28:58-04:00
New Revision: 42915e2be231983a6476eabc059d114d60742ded

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

LOG: [gn build] (manually) port a2f2dfde48ac (clang-fuzzer-dictionary)

Added: 
llvm/utils/gn/secondary/clang/tools/clang-fuzzer/dictionary/BUILD.gn

Modified: 
clang/tools/clang-fuzzer/dictionary/CMakeLists.txt
llvm/utils/gn/secondary/clang/test/BUILD.gn

Removed: 




diff  --git a/clang/tools/clang-fuzzer/dictionary/CMakeLists.txt 
b/clang/tools/clang-fuzzer/dictionary/CMakeLists.txt
index 0e9a9a7bd0a37..ee4aa587ea54d 100644
--- a/clang/tools/clang-fuzzer/dictionary/CMakeLists.txt
+++ b/clang/tools/clang-fuzzer/dictionary/CMakeLists.txt
@@ -1,2 +1,4 @@
-add_clang_executable(clang-fuzzer-dictionary dictionary.c)
+add_clang_executable(clang-fuzzer-dictionary
+  dictionary.c
+  )
 

diff  --git a/llvm/utils/gn/secondary/clang/test/BUILD.gn 
b/llvm/utils/gn/secondary/clang/test/BUILD.gn
index 6651193745a1b..658e7d49f771c 100644
--- a/llvm/utils/gn/secondary/clang/test/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/test/BUILD.gn
@@ -145,6 +145,7 @@ group("test") {
 "//clang/tools/c-index-test",
 "//clang/tools/clang-
diff ",
 "//clang/tools/clang-format",
+"//clang/tools/clang-fuzzer/dictionary:clang-fuzzer-dictionary",
 "//clang/tools/clang-import-test",
 "//clang/tools/clang-offload-bundler",
 "//clang/tools/clang-refactor",

diff  --git 
a/llvm/utils/gn/secondary/clang/tools/clang-fuzzer/dictionary/BUILD.gn 
b/llvm/utils/gn/secondary/clang/tools/clang-fuzzer/dictionary/BUILD.gn
new file mode 100644
index 0..6bb9e42707fb9
--- /dev/null
+++ b/llvm/utils/gn/secondary/clang/tools/clang-fuzzer/dictionary/BUILD.gn
@@ -0,0 +1,4 @@
+executable("clang-fuzzer-dictionary") {
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  sources = [ "dictionary.c" ]
+}



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

[PATCH] D124836: [AArch64] Add support for -fzero-call-used-regs

[Bill Wendling via Phabricator via cfe-commits]

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

- Used lists of argument registers generated from AArch64CallingConv.td.
- Add more tests for floating point and SVE.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124836

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
  llvm/lib/Target/AArch64/AArch64FrameLowering.h
  llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
  llvm/lib/Target/AArch64/AArch64RegisterInfo.h
  llvm/lib/Target/AArch64/AArch64RegisterInfo.td
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/test/CodeGen/AArch64/zero-call-used-regs.ll
  llvm/utils/TableGen/CallingConvEmitter.cpp
  llvm/utils/TableGen/RegisterInfoEmitter.cpp

Index: llvm/utils/TableGen/RegisterInfoEmitter.cpp
===
--- llvm/utils/TableGen/RegisterInfoEmitter.cpp
+++ llvm/utils/TableGen/RegisterInfoEmitter.cpp
@@ -1188,6 +1188,8 @@
  << "MCRegister) const override;\n"
  << "  bool isFixedRegister(const MachineFunction &, "
  << "MCRegister) const override;\n"
+ << "  bool isArgumentRegister(const MachineFunction &, "
+ << "MCRegister) const override;\n"
  << "  /// Devirtualized TargetFrameLowering.\n"
  << "  static const " << TargetName << "FrameLowering *getFrameLowering(\n"
  << "  const MachineFunction &MF);\n"
@@ -1662,6 +1664,20 @@
   OS << "  false;\n";
   OS << "}\n\n";
 
+  OS << "bool " << ClassName << "::\n"
+ << "isArgumentRegister(const MachineFunction &MF, "
+ << "MCRegister PhysReg) const {\n"
+ << "  return\n";
+  for (const CodeGenRegisterCategory &Category : RegCategories)
+if (Category.getName() == "ArgumentRegisters") {
+  for (const CodeGenRegisterClass *RC : Category.getClasses())
+OS << "  " << RC->getQualifiedName()
+   << "RegClass.contains(PhysReg) ||\n";
+  break;
+}
+  OS << "  false;\n";
+  OS << "}\n\n";
+
   OS << "ArrayRef " << ClassName
  << "::getRegMaskNames() const {\n";
   if (!CSRSets.empty()) {
Index: llvm/utils/TableGen/CallingConvEmitter.cpp
===
--- llvm/utils/TableGen/CallingConvEmitter.cpp
+++ llvm/utils/TableGen/CallingConvEmitter.cpp
@@ -20,6 +20,14 @@
 namespace {
 class CallingConvEmitter {
   RecordKeeper &Records;
+  unsigned Counter;
+  std::string CurrentAction;
+  bool SwiftAction;
+
+  std::map> AssignedRegsMap;
+  std::map> AssignedSwiftRegsMap;
+  std::map> DelegateToMap;
+
 public:
   explicit CallingConvEmitter(RecordKeeper &R) : Records(R) {}
 
@@ -28,7 +36,7 @@
 private:
   void EmitCallingConv(Record *CC, raw_ostream &O);
   void EmitAction(Record *Action, unsigned Indent, raw_ostream &O);
-  unsigned Counter;
+  void EmitArgRegisterLists(raw_ostream &O);
 };
 } // End anonymous namespace
 
@@ -38,6 +46,7 @@
   // Emit prototypes for all of the non-custom CC's so that they can forward ref
   // each other.
   Records.startTimer("Emit prototypes");
+  O << "#ifndef GET_CC_REGISTER_LISTS\n\n";
   for (Record *CC : CCs) {
 if (!CC->getValueAsBit("Custom")) {
   unsigned Pad = CC->getName().size();
@@ -58,18 +67,25 @@
   // Emit each non-custom calling convention description in full.
   Records.startTimer("Emit full descriptions");
   for (Record *CC : CCs) {
-if (!CC->getValueAsBit("Custom"))
+if (!CC->getValueAsBit("Custom")) {
+  // Call upon the creation of a map entry from the void!
+  CurrentAction = CC->getName().str();
+  (void)AssignedRegsMap[CurrentAction];
   EmitCallingConv(CC, O);
+}
   }
-}
 
+  EmitArgRegisterLists(O);
+
+  O << "\n#endif // CC_REGISTER_LIST\n";
+}
 
 void CallingConvEmitter::EmitCallingConv(Record *CC, raw_ostream &O) {
   ListInit *CCActions = CC->getValueAsListInit("Actions");
   Counter = 0;
 
   O << "\n\n";
-  unsigned Pad = CC->getName().size();
+  unsigned Pad = CurrentAction.size();
   if (CC->getValueAsBit("Entry")) {
 O << "bool llvm::";
 Pad += 12;
@@ -77,13 +93,21 @@
 O << "static bool ";
 Pad += 13;
   }
-  O << CC->getName() << "(unsigned ValNo, MVT ValVT,\n"
+  O << CurrentAction << "(unsigned ValNo, MVT ValVT,\n"
 << std::string(Pad, ' ') << "MVT LocVT, CCValAssign::LocInfo LocInfo,\n"
 << std::string(Pad, ' ') << "ISD::ArgFlagsTy ArgFlags, CCState &State) {\n";
   // Emit all of the actions, in order.
   for (unsigned i = 0, e = CCActions->size(); i != e; ++i) {
+Record *Action = CCActions->getElementAsRecord(i);
+SwiftAction = llvm::any_of(Action->getSuperClasses(),
+   [](const std::pair &Class) {
+ std::string Name =
+ Class.first->getNameInitAsString();
+ return StringRef(Name).startswith("CCIfSwift");
+   

[PATCH] D124751: [HLSL] Support -E option for HLSL.

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 428209.
python3kgae added a comment.

Rebase to main for fix merge conflict.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124751

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TargetOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaHLSL/entry.hlsl
  clang/test/SemaHLSL/prohibit_pointer.hlsl

Index: clang/test/SemaHLSL/prohibit_pointer.hlsl
===
--- clang/test/SemaHLSL/prohibit_pointer.hlsl
+++ clang/test/SemaHLSL/prohibit_pointer.hlsl
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -o - -fsyntax-only %s -verify
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-library -x hlsl -o - -fsyntax-only %s -verify
 
 // expected-error@+1 {{pointers are unsupported in HLSL}}
 typedef int (*fn_int)(int);
Index: clang/test/SemaHLSL/entry.hlsl
===
--- /dev/null
+++ clang/test/SemaHLSL/entry.hlsl
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-compute -x hlsl -Efoo -DWITH_NUM_THREADS -ast-dump -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-compute -x hlsl -Efoo  -o - %s  -verify
+
+
+// Make sure add HLSLShaderAttr along with HLSLNumThreadsAttr.
+// CHECK:HLSLNumThreadsAttr 0x{{.*}}  1 1 1
+// CHECK:HLSLShaderAttr 0x{{.*}}  Compute
+
+#ifdef WITH_NUM_THREADS
+[numthreads(1,1,1)]
+#endif
+// expected-error@+1 {{missing numthreads attribute for Compute shader entry}}
+void foo() {
+
+}
\ No newline at end of file
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9867,6 +9867,55 @@
 }
   }
 
+  if (getLangOpts().HLSL) {
+auto &TargetInfo = getASTContext().getTargetInfo();
+if (!NewFD->isInvalidDecl() &&
+// Skip operator overload which not identifier.
+Name.isIdentifier() &&
+NewFD->getName() == TargetInfo.getTargetOpts().HLSLEntry &&
+// Make sure it is in translation-unit scope.
+S->getDepth() == 0) {
+  CheckHLSLEntryPoint(NewFD);
+  if (!NewFD->isInvalidDecl()) {
+auto TripeShaderType = TargetInfo.getTriple().getEnvironment();
+AttributeCommonInfo AL(NewFD->getBeginLoc());
+HLSLShaderAttr::ShaderType ShaderType =
+HLSLShaderAttr::ShaderType::Callable;
+switch (TripeShaderType) {
+default:
+  break;
+case llvm::Triple::EnvironmentType::Compute:
+  ShaderType = HLSLShaderAttr::ShaderType::Compute;
+  break;
+case llvm::Triple::EnvironmentType::Vertex:
+  ShaderType = HLSLShaderAttr::ShaderType::Vertex;
+  break;
+case llvm::Triple::EnvironmentType::Hull:
+  ShaderType = HLSLShaderAttr::ShaderType::Hull;
+  break;
+case llvm::Triple::EnvironmentType::Domain:
+  ShaderType = HLSLShaderAttr::ShaderType::Domain;
+  break;
+case llvm::Triple::EnvironmentType::Geometry:
+  ShaderType = HLSLShaderAttr::ShaderType::Geometry;
+  break;
+case llvm::Triple::EnvironmentType::Pixel:
+  ShaderType = HLSLShaderAttr::ShaderType::Pixel;
+  break;
+case llvm::Triple::EnvironmentType::Mesh:
+  ShaderType = HLSLShaderAttr::ShaderType::Mesh;
+  break;
+case llvm::Triple::EnvironmentType::Amplification:
+  ShaderType = HLSLShaderAttr::ShaderType::Amplification;
+  break;
+}
+// To share code with HLSLShaderAttr, add HLSLShaderAttr to entry function.
+if (HLSLShaderAttr *Attr = mergeHLSLShaderAttr(NewFD, AL, ShaderType))
+  NewFD->addAttr(Attr);
+  }
+}
+  }
+
   if (!getLangOpts().CPlusPlus) {
 // Perform semantic checking on the function declaration.
 if (!NewFD->isInvalidDecl() && NewFD->isMain())
@@ -11687,6 +11736,21 @@
   }
 }
 
+void Sema::CheckHLSLEntryPoint(FunctionDecl *FD) {
+  auto &TargetInfo = getASTContext().getTargetInfo();
+  switch (TargetInfo.getTriple().getEnvironment()) {
+  default:
+// FIXME: check all shader profiles.
+break;
+  case llvm::Triple::EnvironmentType::Compute:
+if (!FD->hasAttr()) {
+  Diag(FD->getLocation(), diag::err_hlsl_missing_numthreads) << "Compute";
+  FD->setInvalidDecl();
+}
+break;
+  }
+}
+
 bool Sema::CheckForConstantInitializer(Expr *Init, QualType DclT) {
   // FIXME: Need strict checking.  In C89, we need to check for
   // any assignment, increment, decrement, function-calls, or
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang

[PATCH] D119296: KCFI sanitizer

[Sami Tolvanen via Phabricator via cfe-commits]

samitolvanen updated this revision to Diff 428208.
samitolvanen added a comment.

- Handle FP, LR, and XZR register arguments in the AArch64 `llvm.kcfi.check` 
lowering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119296

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ControlFlowIntegrity.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/Sanitizers.def
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/test/CodeGen/kcfi.c
  clang/test/Driver/fsanitize.c
  llvm/include/llvm/CodeGen/AsmPrinter.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/lib/Target/X86/X86AsmPrinter.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/CodeGen/AArch64/kcfi.ll
  llvm/test/CodeGen/X86/kcfi.ll
  llvm/test/Transforms/InstCombine/kcfi_check.ll

Index: llvm/test/Transforms/InstCombine/kcfi_check.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/kcfi_check.ll
@@ -0,0 +1,35 @@
+; RUN: opt < %s -passes=instcombine -S | FileCheck %s
+
+define void @f1() #0 prefix i32 10 {
+  ret void
+}
+
+declare void @f2() #0 prefix i32 11
+
+define internal void @f3() {
+  ret void
+}
+
+define void @g(ptr noundef %x) {
+  ; CHECK: call void @llvm.kcfi.check(ptr %x, i32 10)
+  call void @llvm.kcfi.check(ptr %x, i32 10)
+
+  ; CHECK-NOT: call void @llvm.kcfi.check(ptr nonnull @f1, i32 10)
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f1, i32 11)
+  call void @llvm.kcfi.check(ptr nonnull @f1, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f1, i32 11)
+
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f2, i32 10)
+  ; CHECK-NOT: call void @llvm.kcfi.check(ptr nonnull @f2, i32 11)
+  call void @llvm.kcfi.check(ptr nonnull @f2, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f2, i32 11)
+
+  ; CHECK: call void @llvm.kcfi.check(ptr nonnull @f3, i32 10)
+  call void @llvm.kcfi.check(ptr nonnull @f3, i32 10)
+  ret void
+}
+
+; CHECK: declare void @llvm.kcfi.check(ptr, i32 immarg)
+declare void @llvm.kcfi.check(ptr, i32 immarg)
+
+attributes #0 = { "kcfi" }
Index: llvm/test/CodeGen/X86/kcfi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/kcfi.ll
@@ -0,0 +1,39 @@
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu -stop-before=finalize-isel < %s | FileCheck %s --check-prefix=ISEL
+
+; CHECK:   .type __cfi_f1,@function
+; CHECK-LABEL: __cfi_f1:
+; CHECK-NEXT:int3
+; CHECK-NEXT:int3
+; CHECK-NEXT:movl $12345678, %eax
+; CHECK-NEXT:int3
+; CHECK-NEXT:int3
+; CHECK-LABEL: .L__cfi_func_end0:
+; CHECK-NEXT:  .size   __cfi_f1, .L__cfi_func_end0-__cfi_f1
+define void @f1(ptr noundef %x) #0 prefix i32 12345678 {
+
+; CHECK-LABEL: f1:
+; CHECK:   # %bb.0:
+; CHECK: cmpl $12345678, -6(%rdi) # imm = 0xBC614E
+; CHECK-NEXT:je .Ltmp0
+; CHECK-NEXT:  .Ltmp1:
+; CHECK-NEXT:ud2
+; CHECK-NEXT:.section .kcfi_traps,"awo",@progbits,.text
+; CHECK-NEXT:.quad .Ltmp1
+; CHECK-NEXT:.text
+; CHECK-NEXT:  .Ltmp0:
+; CHECK-NEXT:callq *%rdi
+
+; ISEL: name: f1
+; ISEL: body:
+; ISEL: KCFI_CHECK %[[#CALL:]], 12345678, implicit-def dead $eflags
+; ISEL: CALL64r %[[#CALL]], csr_64, implicit $rsp, implicit $ssp, implicit-def $rsp, implicit-def $ssp
+
+  call void @llvm.kcfi.check(ptr %x, i32 12345678)
+  call void %x()
+  ret void
+}
+
+declare void @llvm.kcfi.check(ptr, i32 immarg)
+
+attributes #0 = { "kcfi" }
Index: llvm/test/CodeGen/AArch64/kcfi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/kcfi.ll
@@ -0,0 +1,30 @@
+; RUN: llc -mtriple=aarch64-- < %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-- -stop-before=finalize-isel < %s | FileCheck %s --check-prefix=ISEL
+
+; CHECK:   .word 12345678
+define void @f1(ptr noundef %x) #0 prefix i32 12345678 {
+
+; CHECK-LABEL: f1:
+; CHECK:   // %bb.0:
+; CHECK: ldur w16, [x0, #-4]
+; CHECK-NEXT:movk w17, #24910
+; CHECK-NEXT:movk w17, #188, lsl #16
+; CHECK-NEXT:cmp w16, w17
+; CHECK-NEXT:b.eq .Ltmp0
+; CHECK-NEXT:brk #0x8220
+; CHECK-NEXT:  .Ltmp0:
+; CHECK-NEXT:blr x0
+
+; ISEL: name: f1
+; ISEL: body:
+; ISEL: KCFI_CHECK %[[#CALL:]], 12345678, implicit-def dead $x16, implicit-def dead $x17, implicit-de

[PATCH] D125165: [Clang] Introduce clang-offload-binary tool to bundle device files

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

Thanks for the comments.




Comment at: clang/docs/ClangOffloadBinary.rst:8
+
+.. _clang-offload-binary:
+

tra wrote:
> Naming nit: `binary` may not be the best term for what we're trying to do 
> here. Perhaps something like `package`, `container` or `collection` would 
> work better.
Yeah, I would've used `bundler` but that name is taken. I think I can go with 
`clang-offload-container`



Comment at: clang/docs/ClangOffloadBinary.rst:42
+  
+  clang-offload-binary options:
+  

tra wrote:
> This appears to be a one-way process. How one would examine what's in the 
> binary and unpack/extract specific component from it?
This is done by the linker wrapper, but I think it would be good to teach 
`llvm-objdump` how to handle these. Then we could basically just treat it the 
same way as `cuobjdump`.



Comment at: clang/test/Frontend/embed-object.ll:7
+; CHECK: @[[OBJECT_1:.+]] = private constant [0 x i8] zeroinitializer, section 
".llvm.offloading", align 8
+; CHECK: @[[OBJECT_2:.+]] = private constant [0 x i8] zeroinitializer, section 
".llvm.offloading", align 8
 ; CHECK: @llvm.compiler.used = appending global [3 x ptr] [ptr @x, ptr 
@[[OBJECT_1]], ptr @[[OBJECT_2]]], section "llvm.metadata"

tra wrote:
> What will happen if an openMP file compiled this way is linked with the older 
> version of OpenMP runtime which presumably expected to see extra data in 
> `.llvm.offloading`?
> Will it provide a sensible error? Perhaps we should change the section name, 
> too.
I didn't change the actual data being embedded, only the method to do it. 
previously this command line did the work of the offload binary tool. Now it 
just embeds the file that the tool spits out. This test just makes sure that we 
run it and get the contents in the IR.



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:70
+  raw_svector_ostream OS(BinaryData);
+  for (StringRef Image : DeviceImages) {
+StringMap Args;

tra wrote:
> It would be useful to add a comment describing the 'special' keys `file` and 
> `kind`.
I think I'll add that to the help message.



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:75
+
+if (!Args.count("triple") || !Args.count("file"))
+  return reportError(createStringError(

tra wrote:
> Should `kind` also be required? If not, what's the default kind?
The default kind is filled when we default construct the `OffloadingImage` 
below, which gives `OFK_None`. This has the effect of being used for linking 
jobs, but not emitting any registration code.



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:99
+}
+std::unique_ptr Buffer = OffloadBinary::write(ImageBinary);
+OS << Buffer->getBuffer();

tra wrote:
> Nit: `write` is a rather misleading function name here. AFAICT, we're not 
> actually writing anything, but rather packing the `ImageBinary` into a memory 
> buffer, which we then return.
I read it as "write to buffer", but I can see your point. It's not related to 
this patch but I could see changing it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D125272: [clang] Add -fcheck-new support

[Pedro Falcato via Phabricator via cfe-commits]

heatd created this revision.
Herald added a project: All.
heatd requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Add -fcheck-new and -fno-check-new, from GCC, which make the compiler
not assume pointers returned from operator new are non-null.
Fixes #16931.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125272

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenCXX/fcheck-new.cpp
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -70,7 +70,6 @@
 // CHECK-CUDA-SAMPLE-PROFILE: "-cc1"
 // CHECK-CUDA-SAMPLE-PROFILE-SAME: "-fprofile-sample-use={{.*}}/file.prof"
 
-
 // RUN: %clang -### -S -fauto-profile=%S/Inputs/file.prof %s 2>&1 | FileCheck -check-prefix=CHECK-AUTO-PROFILE %s
 // CHECK-AUTO-PROFILE: "-fprofile-sample-use={{.*}}/file.prof"
 
@@ -298,7 +297,6 @@
 // RUN: -fno-reorder-blocks -freorder-blocks  \
 // RUN: -fno-schedule-insns2 -fschedule-insns2\
 // RUN: -fno-stack-check  \
-// RUN: -fno-check-new -fcheck-new\
 // RUN: -ffriend-injection\
 // RUN: -fno-implement-inlines -fimplement-inlines\
 // RUN: -fstack-check \
Index: clang/test/CodeGenCXX/fcheck-new.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fcheck-new.cpp
@@ -0,0 +1,20 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang -fcheck-new -emit-llvm -S %s -o - -O2 | FileCheck %s
+
+// CHECK-LABEL: @_Z5test0v(
+// CHECK-NEXT:[[TMP1:%.*]] = tail call noalias noundef dereferenceable_or_null(4) ptr @_Znwm(i64 noundef 4) #[[ATTR2:[0-9]+]]
+// CHECK-NEXT:[[TMP2:%.*]] = icmp eq ptr [[TMP1]], null
+// CHECK-NEXT:br i1 [[TMP2]], label [[TMP4:%.*]], label [[TMP3:%.*]]
+// CHECK:   3:
+// CHECK-NEXT:store i32 48879, ptr [[TMP1]], align 4, !tbaa [[TBAA5:![0-9]+]]
+// CHECK-NEXT:br label [[TMP4]]
+// CHECK:   4:
+// CHECK-NEXT:ret ptr [[TMP1]]
+//
+int *test0() {
+  int *ptr = new int;
+  if (!ptr)
+return (int *)0;
+  *ptr = 0xbeef;
+  return ptr;
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -3104,7 +3104,8 @@
 // Global allocation functions should always be visible.
 Alloc->setVisibleDespiteOwningModule();
 
-if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible)
+if (HasBadAllocExceptionSpec && getLangOpts().NewInfallible &&
+!getLangOpts().CheckNew)
   Alloc->addAttr(
   ReturnsNonNullAttr::CreateImplicit(Context, Alloc->getLocation()));
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -15436,7 +15436,11 @@
   //   indicates failure by returning a null pointer value. Any other allocation
   //   function never returns a null pointer value and indicates failure only by
   //   throwing an exception [...]
-  if (!IsNothrow && !FD->hasAttr())
+  //
+  // However, -fcheck-new violates this possible assumption, so don't add
+  // NonNull when that is enabled.
+  if (!IsNothrow && !FD->hasAttr() &&
+  !getLangOpts().CheckNew)
 FD->addAttr(ReturnsNonNullAttr::CreateImplicit(Context, FD->getLocation()));
 
   // C++2a [basic.stc.dynamic.allocation]p2:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -4113,6 +4113,9 @@
   if (const Arg *A = Args.getLastArg(OPT_frandomize_layout_seed_EQ))
 Opts.RandstructSeed = A->getValue(0);
 
+  if (const Arg *A = Args.getLastArg(OPT_fcheck_new))
+Opts.CheckNew = true;
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5981,6 +5981,9 @@
   options::OPT_fno_emulated_tls);
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
+  if (Args.hasFlag(options::OPT_fcheck_n

[PATCH] D125165: [Clang] Introduce clang-offload-binary tool to bundle device files

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/docs/ClangOffloadBinary.rst:8
+
+.. _clang-offload-binary:
+

Naming nit: `binary` may not be the best term for what we're trying to do here. 
Perhaps something like `package`, `container` or `collection` would work better.



Comment at: clang/docs/ClangOffloadBinary.rst:42
+  
+  clang-offload-binary options:
+  

This appears to be a one-way process. How one would examine what's in the 
binary and unpack/extract specific component from it?



Comment at: clang/test/Frontend/embed-object.ll:7
+; CHECK: @[[OBJECT_1:.+]] = private constant [0 x i8] zeroinitializer, section 
".llvm.offloading", align 8
+; CHECK: @[[OBJECT_2:.+]] = private constant [0 x i8] zeroinitializer, section 
".llvm.offloading", align 8
 ; CHECK: @llvm.compiler.used = appending global [3 x ptr] [ptr @x, ptr 
@[[OBJECT_1]], ptr @[[OBJECT_2]]], section "llvm.metadata"

What will happen if an openMP file compiled this way is linked with the older 
version of OpenMP runtime which presumably expected to see extra data in 
`.llvm.offloading`?
Will it provide a sensible error? Perhaps we should change the section name, 
too.



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:70
+  raw_svector_ostream OS(BinaryData);
+  for (StringRef Image : DeviceImages) {
+StringMap Args;

It would be useful to add a comment describing the 'special' keys `file` and 
`kind`.



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:75
+
+if (!Args.count("triple") || !Args.count("file"))
+  return reportError(createStringError(

Should `kind` also be required? If not, what's the default kind?



Comment at: clang/tools/clang-offload-binary/ClangOffloadBinary.cpp:99
+}
+std::unique_ptr Buffer = OffloadBinary::write(ImageBinary);
+OS << Buffer->getBuffer();

Nit: `write` is a rather misleading function name here. AFAICT, we're not 
actually writing anything, but rather packing the `ImageBinary` into a memory 
buffer, which we then return.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125165

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

[PATCH] D124909: Fix issues with using clangd with C++ modules

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Hi Kugan, I apologize in advance for a frustrating and long-winded answer...

There's no modules support in clangd in large part because we don't know where 
to start.

- clangd devs so far are not experts in modules and didn't have a burning use 
case, I suspect you can help a lot or both counts!
- we expect using modules to have very high implementation and maintenance 
costs, so it's a big bet:
  - they are similar to preambles, and preambles greatly constrain and 
complicate most clangd features
  - ... but they have many more permutations than preambles, so are harder to 
reason about and test, we will have more types of bugs...
  - these are being added on, unlike preambles which were added early and much 
of our infrastructure was designed around (TUScheduler, index)
- there's no established pattern for tools working with modularized build 
systems yet (c.f. compile_commands.json 5 years ago)

There's huge potential benefits here and I'm excited you're working on it! But 
because of the high costs, we need to make sure this is going to improve things 
substantially for many users. The more that a design assumes version-lock, PCMs 
are guaranteed present, host compiler flags are clang-compatible 
(clang/gcc/msvc all use diferent modules flags!), even explicitly modularized 
code, the narrower the slice of users there are.

It's tempting to start down the path of trying to fix the configuration that 
almost-works. We can/should definitely support experimentation! (The 
COMPATIBLE_LANGOPT change here seems fine to me). But even if the first steps 
are cheap, going down too far down the wrong path can be expensive. My biggest 
fear is to end up supporting increasingly costly fixes to an 
accidentally-supported mode that will never really work right. 
But I should worry less and talk more - looking forward to a video call on 
thursday, I'm sure we'll find a good way forward!

I think first steps are pretty high level, to understand:

- what the goals are (e.g. performance, easier integration with build system, 
work with modules syntax features, ...)
- environment and constraints (e.g. how your build system works, how clangd 
interacts with headers today)
- alternatives for achieving goals (externally built modules, internally built 
modules, some hybrid where modules are optionally provided, non-modules 
solutions...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124909

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

[PATCH] D124701: [clang] Honor __attribute__((no_builtin("foo"))) on functions

[Stephen Long via Phabricator via cfe-commits]

steplong updated this revision to Diff 428195.
steplong added a comment.

clang-formatted patch


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

https://reviews.llvm.org/D124701

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/no-builtin-2.c


Index: clang/test/CodeGen/no-builtin-2.c
===
--- /dev/null
+++ clang/test/CodeGen/no-builtin-2.c
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+
+typedef typeof(sizeof(0)) size_t;
+
+void bar(char *s);
+void *memset(void *s, int c, size_t n);
+void *memcpy(void *d, const void *s, size_t n);
+
+// CHECK: define{{.*}} void @foo1({{.*}}) #[[NO_NOBUILTIN:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   call void @llvm.memset
+// CHECK:   call void @llvm.memcpy
+void foo1(char *s, char *d, size_t n) {
+  bar(s);
+  memset(s, 0, n);
+  memcpy(d, s, n);
+}
+
+// CHECK: define{{.*}} void @foo2({{.*}}) #[[NOBUILTIN_MEMSET:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   {{.*}}call {{.*}} @memset
+// CHECK:   call void @llvm.memcpy
+void foo2(char *s, char *d, size_t n) __attribute__((no_builtin("memset"))) {
+  bar(s);
+  memset(s, 1, n);
+  memcpy(d, s, n);
+}
+
+// CHECK: define{{.*}} void @foo3({{.*}}) #[[NOBUILTIN_MEMSET_MEMCPY:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   {{.*}}call {{.*}} @memset
+// CHECK:   {{.*}}call {{.*}} @memcpy
+void foo3(char *s, char *d, size_t n) __attribute__((no_builtin("memset", 
"memcpy"))) {
+  bar(s);
+  memset(s, 2, n);
+  memcpy(d, s, n);
+}
+
+// CHECK-NOT: attributes #[[NO_NOBUILTIN]] = {{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK-NOT: attributes #[[NO_NOBUILTIN]] = 
{{{.*}}"no-builtin-memcpy"{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK: attributes #[[NOBUILTIN_MEMSET]] = 
{{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK: attributes #[[NOBUILTIN_MEMSET_MEMCPY]] = 
{{{.*}}"no-builtin-memcpy"{{.*}}"no-builtin-memset"{{.*}}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1142,7 +1142,8 @@
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName))
+  bool ParsedAttrIsWildCard = BuiltinName == kWildcard;
+  if (Builtin::Context::isBuiltinFunc(BuiltinName) || ParsedAttrIsWildCard)
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, 
diag::warn_attribute_no_builtin_invalid_builtin_name)
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -5034,6 +5034,7 @@
   const FunctionDecl *FD = cast(GD.getDecl());
 
   if (auto builtinID = FD->getBuiltinID()) {
+std::string AttributeNoBuiltin = "no-builtin-" + FD->getName().str();
 std::string FDInlineName = (FD->getName() + ".inline").str();
 // When directing calling an inline builtin, call it through it's mangled
 // name to make it clear it's not the actual builtin.
@@ -5054,8 +5055,9 @@
 
 // Replaceable builtins provide their own implementation of a builtin. If 
we
 // are in an inline builtin implementation, avoid trivial infinite
-// recursion.
-else
+// recursion. Honor __attribute__((no_builtin("foo"))) on the current
+// function.
+else if (!CGF.CurFn->getAttributes().hasFnAttr(AttributeNoBuiltin))
   return CGCallee::forBuiltin(builtinID, FD);
   }
 


Index: clang/test/CodeGen/no-builtin-2.c
===
--- /dev/null
+++ clang/test/CodeGen/no-builtin-2.c
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+
+typedef typeof(sizeof(0)) size_t;
+
+void bar(char *s);
+void *memset(void *s, int c, size_t n);
+void *memcpy(void *d, const void *s, size_t n);
+
+// CHECK: define{{.*}} void @foo1({{.*}}) #[[NO_NOBUILTIN:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   call void @llvm.memset
+// CHECK:   call void @llvm.memcpy
+void foo1(char *s, char *d, size_t n) {
+  bar(s);
+  memset(s, 0, n);
+  memcpy(d, s, n);
+}
+
+// CHECK: define{{.*}} void @foo2({{.*}}) #[[NOBUILTIN_MEMSET:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   {{.*}}call {{.*}} @memset
+// CHECK:   call void @llvm.memcpy
+void foo2(char *s, char *d, size_t n) __attribute__((no_builtin("memset"))) {
+  bar(s);
+  memset(s, 1, n);
+  memcpy(d, s, n);
+}
+
+// CHECK: define{{.*}} void @foo3({{.*}}) #[[NOBUILTIN_MEMSET_MEMCPY:[0-9]+]]
+// CHECK:   call void @bar
+// CHECK:   {{.*}}call {{.*}} @memset
+// CHECK:   {{.*}}call {{.*}} @memcpy
+void foo3(char *s, char *d, size_t n) __attribute__((no_builtin("memset", "memcpy"))) {
+  bar(s);
+  memset(s, 2, n);
+  memcpy(d, s, n);
+}
+
+// CHECK-NOT: attributes #[[NO_NOBUILTIN]] = {{{.*}}"no-builtin-memset"{{.*}}}
+// CHECK-NO

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:4267
+  bool IsConstant = CLETy.isConstant(Info.Ctx);
+  if (!IsConstant && CLETy->isArrayType()) {
+Info.FFDiag(Conv);

serge-sans-paille wrote:
> efriedma wrote:
> > Is the "isArrayType()" check here necessary?
> Yeah, otherwise we have an issue with
> 
> ```
> typedef __attribute__(( ext_vector_type(4) )) float float4;
> float4 foo = (float4){ 1.0, 2.0, 3.0, 4.0 };
> ```
> 
> error: cannot compile this static initializer yet
Hmm, I see... in C++, the compound literal rules are weird.  C compound 
literals are lvalues, but C++ ones are not.  So normally, we don't allow taking 
the address of a compound literal or any of its members.  But if it's an array, 
somehow different rules (what rules?) apply.

If you can add a comment explaining what's going on here, maybe it's okay?

I'm tempted to say we should reject the testcase, though.  For example, in the 
following, it doesn't really make sense to reject the first variable, but 
accept the second.

```
typedef int arr[2];
constexpr int *x = arr{1};
constexpr int *y = (arr){1};
```

--

Can you add a testcase involving an array of structs with a "mutable" member?


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

https://reviews.llvm.org/D124038

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Roy Sundahl via Phabricator via cfe-commits]

rsundahl added a comment.

Adding dialog to comments made by reviewers.




Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2443
+  // Handle poisoning the array cookie in asan
+  if (CGM.getLangOpts().Sanitize.has(SanitizerKind::Address) && AS == 0 &&
+  (expr->getOperatorNew()->isReplaceableGlobalAllocationFunction() ||

delcypher wrote:
> Why is there a restriction on the address space?
It's only there because it's also there in 
ItaniumCXXABI::InitializeArrayCookie() method and I have no reason to think 
that the ARMCXXABI version would be different. That said, this is the revision 
that introduced the notion originally: https://reviews.llvm.org/D5111



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2478
+  // run-time deal with it: if the shadow is properly poisoned return the
+  // cookie, otherwise return 0 to avoid an infinite loop calling DTORs.
+  // We can't simply ignore this load using nosanitize metadata because

delcypher wrote:
> This comment is confusing. What's returning `0`? 
> `__asan_load_cxx_array_cookie` doesn't do that and AFAICT neither does this 
> code.
(Same answer) It's only there because it's also there in 
ItaniumCXXABI::InitializeArrayCookie() method and I have no reason to think 
that the ARMCXXABI version would be different. That said, this is the revision 
that introduced the notion originally: https://reviews.llvm.org/D5111



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2479
+  // cookie, otherwise return 0 to avoid an infinite loop calling DTORs.
+  // We can't simply ignore this load using nosanitize metadata because
+  // the metadata may be lost.

delcypher wrote:
> I also don't understand what you mean by the comment. Could you elaborate?
(Same answer) It's only there because it's also there in 
ItaniumCXXABI::InitializeArrayCookie() method and I have no reason to think 
that the ARMCXXABI version would be different. That said, this is the revision 
that introduced the notion originally: https://reviews.llvm.org/D5111



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2485
+  CGM.CreateRuntimeFunction(FTy, "__asan_load_cxx_array_cookie");
+  return CGF.Builder.CreateCall(F, numElementsPtr.getRawPointer(CGF));
 }

yln wrote:
> Same here: extract common helper for the ASan stuff to be shared by ARM and 
> ItaniumCXXABI.
Was limiting my impact but yes, I agree with you and thanks for expecting it. 
FYI and FWIW: the same concern that @delcypher has in the preceding comments 
will still exist because the factored code will come from the existing Itanium 
methods and those concerns come from that existing code that was introduced by: 
https://reviews.llvm.org/D5111.



Comment at: compiler-rt/lib/asan/asan_poisoning.cpp:262
   *reinterpret_cast(s) = kAsanArrayCookieMagic;
+  // The ARM64 cookie has a second "elementSize" entry so poison it as well
+  #if SANITIZER_ARM64

yln wrote:
> yln wrote:
> > yln wrote:
> > > Nitpicking extreme:
> > > * I think the code inside `#if` shouldn't have extra indent (because 
> > > preprocessor sections don't establish code).  If in doubt, let 
> > > `clang-format` do it for you.
> > > * Let's move the comment inside the #if, just above before the line of 
> > > code.  If you ever read the pre-processed source-code, then the comment 
> > > "lives and dies" with the line of code it relates too, i.e, on x86, 
> > > currently there would be a comment without the code.
> > 
> I find this a bit confusing
> * x86_64: cookie is 1 word and passed `p` points to it
> * arm64: cookie is 2 words and passed `p` points to second half of it
> 
> Would it be worth to take the extra care in CodeGen to always pass the 
> "beginning of the cookie" to `__asan_poison_cxx_array_cookie()` and then have 
> something like that:
> ```
> size_t shadow_cookie_size = SANITIZER_ARM64 ? 2 : 1:
> internal_memset(s, kAsanArrayCookieMagic, shadow_cookie_size);
> ```
I don't think so for a collection of reasons. When the ItaniumCXXABI defines 
the "array cookie" it states: "The cookie will have size sizeof(size_t)" and it 
then describes how there may be padding preceding the cookie but makes no 
mention of a second element anywhere. 
(https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies). Now, while 
the ARMCXXABI(32) specification defines the cookie as two 4-byte (int) values 
(sizeof(element),numElements), the ARMCXXABI(64) 
(https://github.com/ARM-software/abi-aa/blob/320a56971fdcba282b7001cf4b84abb4fd993131/cppabi64/cppabi64.rst#the-generic-c-abi)
 does no such similar thing and defers to the Itanium specification of a 
single, type size_t (8 bytes) cookie which contains only (numElements). The 
initial commit creating the ARMCXXABI(64) mimicking the ARMCXXABI(32) "pair" of 
values occurred here: https://marc.info/?l=cfe-commits&m=135915714232578&w=2 
and is then (unfortunately) this 

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 428188.
jhuber6 added a comment.

Clang format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGCUDARuntime.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenCUDA/offloading-entries.cu

Index: clang/test/CodeGenCUDA/offloading-entries.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/offloading-entries.cu
@@ -0,0 +1,33 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-globals
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu \
+// RUN:   --offload-new-driver -emit-llvm -o - -x cuda  %s | FileCheck \
+// RUN:   --check-prefix=HOST %s
+
+#include "Inputs/cuda.h"
+
+//.
+// HOST: @x = internal global i32 undef, align 4
+// HOST: @.omp_offloading.entry_name = internal unnamed_addr constant [8 x i8] c"_Z3foov\00"
+// HOST: @.omp_offloading.entry._Z3foov = weak constant %struct.__tgt_offload_entry { ptr @_Z18__device_stub__foov, ptr @.omp_offloading.entry_name, i64 0, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+// HOST: @.omp_offloading.entry_name.1 = internal unnamed_addr constant [8 x i8] c"_Z3barv\00"
+// HOST: @.omp_offloading.entry._Z3barv = weak constant %struct.__tgt_offload_entry { ptr @_Z18__device_stub__barv, ptr @.omp_offloading.entry_name.1, i64 0, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+// HOST: @.omp_offloading.entry_name.2 = internal unnamed_addr constant [2 x i8] c"x\00"
+// HOST: @.omp_offloading.entry.x = weak constant %struct.__tgt_offload_entry { ptr @x, ptr @.omp_offloading.entry_name.2, i64 4, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+//.
+// HOST-LABEL: @_Z18__device_stub__foov(
+// HOST-NEXT:  entry:
+// HOST-NEXT:[[TMP0:%.*]] = call i32 @cudaLaunch(ptr @_Z18__device_stub__foov)
+// HOST-NEXT:br label [[SETUP_END:%.*]]
+// HOST:   setup.end:
+// HOST-NEXT:ret void
+//
+__global__ void foo() {}
+// HOST-LABEL: @_Z18__device_stub__barv(
+// HOST-NEXT:  entry:
+// HOST-NEXT:[[TMP0:%.*]] = call i32 @cudaLaunch(ptr @_Z18__device_stub__barv)
+// HOST-NEXT:br label [[SETUP_END:%.*]]
+// HOST:   setup.end:
+// HOST-NEXT:ret void
+//
+__global__ void bar() {}
+__device__ int x = 1;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6084,6 +6084,10 @@
options::OPT_fno_openmp_extensions);
   }
 
+  // Forward the new driver to change offloading code generation.
+  if (Args.hasArg(options::OPT_offload_new_driver))
+CmdArgs.push_back("--offload-new-driver");
+
   SanitizeArgs.addArgs(TC, Args, CmdArgs, InputType);
 
   const XRayArgs &XRay = TC.getXRayArgs();
Index: clang/lib/CodeGen/CGCUDARuntime.h
===
--- clang/lib/CodeGen/CGCUDARuntime.h
+++ clang/lib/CodeGen/CGCUDARuntime.h
@@ -52,6 +52,19 @@
   Texture,  // Builtin texture
 };
 
+/// The kind flag for an offloading entry.
+enum OffloadEntryKindFlag : uint32_t {
+  /// Mark the entry as a global entry. This indicates the presense of a
+  /// kernel if the size size field is zero and a variable otherwise.
+  OffloadGlobalEntry = 0x0,
+  /// Mark the entry as a managed global variable.
+  OffloadGlobalManagedEntry = 0x1,
+  /// Mark the entry as a surface variable.
+  OffloadGlobalSurfaceEntry = 0x2,
+  /// Mark the entry as a texture variable.
+  OffloadGlobalTextureEntry = 0x3,
+};
+
   private:
 unsigned Kind : 2;
 unsigned Extern : 1;
Index: clang/lib/CodeGen/CGCUDANV.cpp
===
--- clang/lib/CodeGen/CGCUDANV.cpp
+++ clang/lib/CodeGen/CGCUDANV.cpp
@@ -157,6 +157,8 @@
   llvm::Function *makeModuleDtorFunction();
   /// Transform managed variables for device compilation.
   void transformManagedVars();
+  /// Create offloading entries to register globals in RDC mode.
+  void createOffloadingEntries();
 
 public:
   CGNVCUDARuntime(CodeGenModule &CGM);
@@ -210,7 +212,8 @@
 CGNVCUDARuntime::CGNVCUDARuntime(CodeGenModule &CGM)
 : CGCUDARuntime(CGM), Context(CGM.getLLVMContext()),
   TheModule(CGM.getModule()),
-  RelocatableDeviceCode(CGM.getLangOpts().GPURelocatableDeviceCode),
+  RelocatableDeviceCode(CGM.getLangOpts().GPURelocatableDeviceCode ||
+CGM.getLangOpts().OffloadingNewDriver),
   DeviceMC(InitDeviceMC(CGM)) {
   CodeGen::CodeGenTypes &Types = CGM.getTypes();
   ASTContext &Ctx = CGM.getContext();
@@ -1107,6 +1110,40 @@
   }
 }
 
+// Creates

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Artem Belevich via Phabricator via cfe-commits]

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

In D124866#3501641 , @yaxunl wrote:

> If we are to add `__forceinline__` as a keyword, I feel it better be a 
> separate patch to be cleaner.

Fine with me.




Comment at: clang/lib/Parse/ParseDecl.cpp:902
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();

yaxunl wrote:
> tra wrote:
> > aaron.ballman wrote:
> > > yaxunl wrote:
> > > > aaron.ballman wrote:
> > > > > I think we should we be issuing a pedantic "this is a clang 
> > > > > extension" warning here, WDYT?
> > > > will do
> > > I'm questioning whether my advice here was good or not -- now that I see 
> > > the CUDA spec already calls these function qualifiers... it's debatable 
> > > whether this is a Clang extension or just the way in which Clang 
> > > implements the CUDA function qualifiers. @tra -- do you have opinions?
> > > 
> > > I'm sort of leaning towards dropping the extension warning, but the only 
> > > reason I can think of for keeping it is if Clang is the only CUDA 
> > > compiler that doesn't require you to include a header before using the 
> > > function qualifiers. If that's the case, there is a portability concern.
> > I'm not sure if such a warning would be useful. 
> > 
> > > the only reason I can think of for keeping it is if Clang is the only 
> > > CUDA compiler that doesn't require you to include a header before using 
> > > the function qualifiers. If that's the case, there is a portability 
> > > concern.
> > 
> > I don't think it's an issue.
> > 
> > We already have similar divergence between nvcc/clang. E.g. built-in 
> > variables like `threadIdx`. Clang implements them in a header, but NVCC 
> > provides them by compiler itself. 
> > With both compilers the variables are available by the time we get to 
> > compile user code. Virtually all CUDA compilations are done with tons of 
> > CUDA headers pre-included by compiler. Those that do not do that are 
> > already on their own and have to provide many other 'standard' CUDA things 
> > like target attributes. I don't think we need to worry about that.
> > 
> I can remove the diagnostics since it seems unnecessary.
> 
> I tend to treat it as an extension since nvcc is the de facto standard 
> implementation, which does not implement it as a keyword. Compared to that, 
> this is like an extension.
I'd argue that NVCC does implement it (as in "documents and makes it 
available"). Providing the documented functionality using a different 
implementation does not reach the point of being an extension, IMO. While there 
are observable differences between implementations, depending on them would be 
a portability error for the user.



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

https://reviews.llvm.org/D124866

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

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 428186.
jhuber6 added a comment.

Updating comments to desceibe usage of flags with zero size.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGCUDARuntime.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenCUDA/offloading-entries.cu

Index: clang/test/CodeGenCUDA/offloading-entries.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/offloading-entries.cu
@@ -0,0 +1,33 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-globals
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu \
+// RUN:   --offload-new-driver -emit-llvm -o - -x cuda  %s | FileCheck \
+// RUN:   --check-prefix=HOST %s
+
+#include "Inputs/cuda.h"
+
+//.
+// HOST: @x = internal global i32 undef, align 4
+// HOST: @.omp_offloading.entry_name = internal unnamed_addr constant [8 x i8] c"_Z3foov\00"
+// HOST: @.omp_offloading.entry._Z3foov = weak constant %struct.__tgt_offload_entry { ptr @_Z18__device_stub__foov, ptr @.omp_offloading.entry_name, i64 0, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+// HOST: @.omp_offloading.entry_name.1 = internal unnamed_addr constant [8 x i8] c"_Z3barv\00"
+// HOST: @.omp_offloading.entry._Z3barv = weak constant %struct.__tgt_offload_entry { ptr @_Z18__device_stub__barv, ptr @.omp_offloading.entry_name.1, i64 0, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+// HOST: @.omp_offloading.entry_name.2 = internal unnamed_addr constant [2 x i8] c"x\00"
+// HOST: @.omp_offloading.entry.x = weak constant %struct.__tgt_offload_entry { ptr @x, ptr @.omp_offloading.entry_name.2, i64 4, i32 0, i32 0 }, section "cuda_offloading_entries", align 1
+//.
+// HOST-LABEL: @_Z18__device_stub__foov(
+// HOST-NEXT:  entry:
+// HOST-NEXT:[[TMP0:%.*]] = call i32 @cudaLaunch(ptr @_Z18__device_stub__foov)
+// HOST-NEXT:br label [[SETUP_END:%.*]]
+// HOST:   setup.end:
+// HOST-NEXT:ret void
+//
+__global__ void foo() {}
+// HOST-LABEL: @_Z18__device_stub__barv(
+// HOST-NEXT:  entry:
+// HOST-NEXT:[[TMP0:%.*]] = call i32 @cudaLaunch(ptr @_Z18__device_stub__barv)
+// HOST-NEXT:br label [[SETUP_END:%.*]]
+// HOST:   setup.end:
+// HOST-NEXT:ret void
+//
+__global__ void bar() {}
+__device__ int x = 1;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6084,6 +6084,10 @@
options::OPT_fno_openmp_extensions);
   }
 
+  // Forward the new driver to change offloading code generation.
+  if (Args.hasArg(options::OPT_offload_new_driver))
+CmdArgs.push_back("--offload-new-driver");
+
   SanitizeArgs.addArgs(TC, Args, CmdArgs, InputType);
 
   const XRayArgs &XRay = TC.getXRayArgs();
Index: clang/lib/CodeGen/CGCUDARuntime.h
===
--- clang/lib/CodeGen/CGCUDARuntime.h
+++ clang/lib/CodeGen/CGCUDARuntime.h
@@ -52,6 +52,19 @@
   Texture,  // Builtin texture
 };
 
+/// The kind flag for an offloading entry.
+enum OffloadEntryKindFlag : uint32_t {
+  /// Mark the entry as a global entry. This indicates the presense of a
+  /// kernel if the size size field is zero and a variable otherwise.
+  OffloadGlobalEntry = 0x0,
+  /// Mark the entry as a managed global variable.
+  OffloadGlobalManagedEntry = 0x1,
+  /// Mark the entry as a surface variable.
+  OffloadGlobalSurfaceEntry = 0x2,
+  /// Mark the entry as a texture variable.
+  OffloadGlobalTextureEntry = 0x3,
+};
+
   private:
 unsigned Kind : 2;
 unsigned Extern : 1;
Index: clang/lib/CodeGen/CGCUDANV.cpp
===
--- clang/lib/CodeGen/CGCUDANV.cpp
+++ clang/lib/CodeGen/CGCUDANV.cpp
@@ -157,6 +157,8 @@
   llvm::Function *makeModuleDtorFunction();
   /// Transform managed variables for device compilation.
   void transformManagedVars();
+  /// Create offloading entries to register globals in RDC mode.
+  void createOffloadingEntries();
 
 public:
   CGNVCUDARuntime(CodeGenModule &CGM);
@@ -210,7 +212,8 @@
 CGNVCUDARuntime::CGNVCUDARuntime(CodeGenModule &CGM)
 : CGCUDARuntime(CGM), Context(CGM.getLLVMContext()),
   TheModule(CGM.getModule()),
-  RelocatableDeviceCode(CGM.getLangOpts().GPURelocatableDeviceCode),
+  RelocatableDeviceCode(CGM.getLangOpts().GPURelocatableDeviceCode ||
+CGM.getLangOpts().OffloadingNewDriver),
   DeviceMC(InitDeviceMC(CGM)) {
   CodeGen::CodeGenTypes &Types = CGM.getTypes();
   ASTContext &Ctx = CGM.getContext

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/CodeGen/CGCUDARuntime.h:58
+  /// Mark the entry as a global variable.
+  OffloadGlobalEntry = 0x0,
+  /// Mark the entry as a managed global variable.

jhuber6 wrote:
> tra wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > jhuber6 wrote:
> > > > > tra wrote:
> > > > > > We're still using the same numeric value for two different kinds of 
> > > > > > entities.
> > > > > > Considering that it's the third round we're making around this 
> > > > > > point, I'm starting to suspect that I may be missing something.
> > > > > > Is there a particular reason kernels and global unmanaged variables 
> > > > > > have to have the same 'kind'?
> > > > > > 
> > > > > > It's possible that I didn't do a good job explaining my 
> > > > > > enthusiastic nitpicking here.
> > > > > > My suggestion to have unified enum for **all** entities we register 
> > > > > > is based on a principle of separation of responsibilities. If we 
> > > > > > want to know what kind of entry we're dealing with, checking the 
> > > > > > 'kind' field should be sufficient. The 'size' field should only 
> > > > > > indicate the size of the entity. Having to consider both kind and 
> > > > > > size to determine what you're dealing with just muddies things and 
> > > > > > should not be done unless there's a good reason for that. E.g. it 
> > > > > > might be OK if we were short on flag bits.
> > > > > > 
> > > > > > 
> > > > > Ah, I see the point you're making now. This is yet another thing that 
> > > > > OpenMP did that I just copied. I wouldn't have implemented it this 
> > > > > way but I figured it would be simpler to keep them similar. I mostly 
> > > > > did it this way because I did some initial tests of registering and 
> > > > > accessing CUDA globals in OpenMP and it required using the same flags 
> > > > > for the kernels and globals. We could change it for CUDA in the 
> > > > > future and I could make that change here if it's valuable. Ideally I 
> > > > > would like to rewrite how we do all this registration with the 
> > > > > structs but breaking the ABI makes it complicated...
> > > > >  I did some initial tests of registering and accessing CUDA globals 
> > > > > in OpenMP and it required using the same flags for the kernels and 
> > > > > globals.
> > > > 
> > > > OK. So, there is something that requires this magic. If that's 
> > > > something we must have, then it must be mentioned in the comments 
> > > > around the enum.
> > > > 
> > > > Do you know where I should find the code which needs this? I'm curious 
> > > > what's going on there.
> > > > I wonder if it just checks for "flags==0" and refuses to deal with 
> > > > unknown flags. 
> > > > To think of it, we probably want to put the enum into a common header 
> > > > which defines the `__tgt_offload_entry`.We would not want OpenMP itself 
> > > > to start using the same bits for something else.
> > > Sorry, I should be more specific. The OpenMP offloading runtime currently 
> > > uses a size of zero to indicate a kernel function and the flags have a 
> > > different meaning if it's a kernel. For OpenMP, 0 is a kernel, 1 and 2 
> > > are device ctors / dtors. I'm not sure why they chose this over just 
> > > another flag but it's the current standard. You can see it used like this 
> > > here 
> > > https://github.com/llvm/llvm-project/blob/main/openmp/libomptarget/src/omptarget.cpp#L147.
> > >  I'm not sure if there's a good way to wrangle these together now that I 
> > > think about it, considering OpenMP already uses `0x1` to represent `link` 
> > > OpenMP variables so this already collides. But treating the flags 
> > > different on the size is at least consistent with what OpenMP does. It 
> > > makes it a little hard to define one enum for it since we use it two 
> > > different ways, I'm not a fan of it but it's what the current ABI uses.
> > I see.
> > 
> > Using `size=0` as the coda/data flag which changes interpretation of the 
> > flags sort of makes sense. In that case two different types for the flags 
> > field would be appropriate, with an appropriate comment describing that 
> > `size==0` determines which one is in effect.
> > 
> Personally I'm find with it landing like this, and if we wanted to improve 
> this later it would probably just go in some greater ABI break for offloading 
> entries. There might be a good reason to change them all at once when we 
> start focusing more on complete interoperability of offloading languages.
I'm fine with that. Just add a comment describing how `OffloadGlobalEntry` is 
used for both code and data and that the size is used to distinguish them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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

[PATCH] D125231: [pseudo] Compile cxx grammar.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Cool! High level thoughts:

**Motivation**
What's the win here? performance of loading/compiling the grammar? 
self-contained-ness? how much are we saving?
Doing the compilation at build time seems likely to be good for performance, 
but we should have numbers. And there are costs to doing it now vs in a few 
months, so there should be benefits too.

In terms of development, having everything grammar-related be compiled makes it 
harder to make changes to the grammar (e.g. constraints on rules, error hints, 
and whatever else we might want).
One way around this: start with a version where the public interface looks like 
this, but the impl is just compiling the strings in the background. (Probably a 
part of the generator that just embeds the lines of the grammar in a string 
array).Then opt-in the critical and stable bits at compile time, like the LR 
table build. Maybe eventually we'll have everything fully compiled, but it 
doesn't seem like the right balance yet.

**Build performance**
Compile time/ram is my biggest technical concern. We know that there's no good 
portable way to get blobs of data into the build system, and the parser is the 
bottleneck. (See the sad std::embed situation). 300KB should be manageable, 
with some work.
There are things we can do to mitigate:

- for the big lists, use simple top-level declarations of arrays with types, 
not nested expressions ending up as std::initializer_lists. Just parsing the 
elements is going to be slow, but there's no reason to involve overload 
resolution, force them to all be in memory at once, etc.
- split each big list into its own file for build-system level parallelism. In 
particular actions[] is ~half the data. This is easy once it's a top-level 
array.
- not parse-time, but related: switch the classes to holding ArrayRefs rather 
than Vectors so we don't have to copy everything. (`vector{1,2,3}` is always a 
copy, it can't share the underlying static because it's mutable).
- make the element types simpler to parse. Currently the Actions buffer is a 
`vector` which at the bottom is two numbers packed into 16 bits. 
This could instead be a `uint16_t Actions[]={...};`, with LRTable wrapping the 
uint16_ts into Action objects on demand (at zero runtime cost).
- if we just have an array of 16-bit integers, it's possible making that source 
file C would be faster to parse than C++ (fewer language features). I doubt it 
but...

**Layering**

- the generator shouldn't depend on much, to avoid creating long paths in the 
build graph. It's pretty good now. I may be missing something, but does it need 
to link against clangBasic? If this is for functions like getTokenName() we 
could consider reimplementing them. (I think clangPseudoGrammar may be a better 
name than clangPseudoBasic).
- similarly, the generated code should avoid dependencies particularly if it's 
slow to compile - maybe it doesn't need clangBasic either? (For our purposes 
it'd also be nice to avoid depending on any tablegenned headers).

**Scope/generality**
I think we're should plan to run this generator in exactly one configuration 
(i.e. for our C++ grammar), we shouldn't pay the costs of making it efficient 
to reuse.
This means we don't need to generate the whole library with complete API 
surface, just the bits that really need to be generated. Generated code is 
harder to maintain and browse.

- in the header, this is just the symbol list (and later the rule list). the 
rest of the header can be hand-written.
- we'd want a cpp file for each array (maybe group some together), but none of 
the initialization logic that uses them: we can just forward declare and use 
those arrays from hand-written C++

Maybe later we want to be able to compile a different grammar for C and we 
revisit this (but I think equally likely we work out how to express language 
options in terms of dynamically-disabling grammar rules instead).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125231

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

[PATCH] D125265: [OpenMP] Don't include the device wrappers if -nostdinc is used

[Artem Belevich via Phabricator via cfe-commits]

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

LGTM in general.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1311
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
   (getToolChain().getTriple().isNVPTX() ||

jhuber6 wrote:
> tra wrote:
> > Did you mean `nostdinc` ?
> Yes, thank you for catching that. That was an autocomplete mishap that I 
> accidentally reintroduced from undoing too many times. I'll fix it.
A test would be useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125265

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

[PATCH] D125265: [OpenMP] Don't include the device wrappers if -nostdinc is used

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 428181.
jhuber6 added a comment.

Fix using `nostdlib` instead of `nostdinc`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125265

Files:
  clang/lib/Driver/ToolChains/Clang.cpp


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1308,6 +1308,7 @@
   // If we are offloading to a target via OpenMP we need to include the
   // openmp_wrappers folder which contains alternative system headers.
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdinc) &&
   (getToolChain().getTriple().isNVPTX() ||
getToolChain().getTriple().isAMDGCN())) {
 if (!Args.hasArg(options::OPT_nobuiltininc)) {


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1308,6 +1308,7 @@
   // If we are offloading to a target via OpenMP we need to include the
   // openmp_wrappers folder which contains alternative system headers.
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdinc) &&
   (getToolChain().getTriple().isNVPTX() ||
getToolChain().getTriple().isAMDGCN())) {
 if (!Args.hasArg(options::OPT_nobuiltininc)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125265: [OpenMP] Don't include the device wrappers if -nostdinc is used

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1311
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
   (getToolChain().getTriple().isNVPTX() ||

tra wrote:
> Did you mean `nostdinc` ?
Yes, thank you for catching that. That was an autocomplete mishap that I 
accidentally reintroduced from undoing too many times. I'll fix it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125265

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

[PATCH] D125265: [OpenMP] Don't include the device wrappers if -nostdinc is used

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1311
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
   (getToolChain().getTriple().isNVPTX() ||

Did you mean `nostdinc` ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125265

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

[PATCH] D125256: [OpenMP] Add `__CUDA_ARCH__` definition when offloading with OpenMP

[Shilei Tian via Phabricator via cfe-commits]

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125256

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

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/CodeGen/CGCUDARuntime.h:58
+  /// Mark the entry as a global variable.
+  OffloadGlobalEntry = 0x0,
+  /// Mark the entry as a managed global variable.

tra wrote:
> jhuber6 wrote:
> > tra wrote:
> > > jhuber6 wrote:
> > > > tra wrote:
> > > > > We're still using the same numeric value for two different kinds of 
> > > > > entities.
> > > > > Considering that it's the third round we're making around this point, 
> > > > > I'm starting to suspect that I may be missing something.
> > > > > Is there a particular reason kernels and global unmanaged variables 
> > > > > have to have the same 'kind'?
> > > > > 
> > > > > It's possible that I didn't do a good job explaining my enthusiastic 
> > > > > nitpicking here.
> > > > > My suggestion to have unified enum for **all** entities we register 
> > > > > is based on a principle of separation of responsibilities. If we want 
> > > > > to know what kind of entry we're dealing with, checking the 'kind' 
> > > > > field should be sufficient. The 'size' field should only indicate the 
> > > > > size of the entity. Having to consider both kind and size to 
> > > > > determine what you're dealing with just muddies things and should not 
> > > > > be done unless there's a good reason for that. E.g. it might be OK if 
> > > > > we were short on flag bits.
> > > > > 
> > > > > 
> > > > Ah, I see the point you're making now. This is yet another thing that 
> > > > OpenMP did that I just copied. I wouldn't have implemented it this way 
> > > > but I figured it would be simpler to keep them similar. I mostly did it 
> > > > this way because I did some initial tests of registering and accessing 
> > > > CUDA globals in OpenMP and it required using the same flags for the 
> > > > kernels and globals. We could change it for CUDA in the future and I 
> > > > could make that change here if it's valuable. Ideally I would like to 
> > > > rewrite how we do all this registration with the structs but breaking 
> > > > the ABI makes it complicated...
> > > >  I did some initial tests of registering and accessing CUDA globals in 
> > > > OpenMP and it required using the same flags for the kernels and globals.
> > > 
> > > OK. So, there is something that requires this magic. If that's something 
> > > we must have, then it must be mentioned in the comments around the enum.
> > > 
> > > Do you know where I should find the code which needs this? I'm curious 
> > > what's going on there.
> > > I wonder if it just checks for "flags==0" and refuses to deal with 
> > > unknown flags. 
> > > To think of it, we probably want to put the enum into a common header 
> > > which defines the `__tgt_offload_entry`.We would not want OpenMP itself 
> > > to start using the same bits for something else.
> > Sorry, I should be more specific. The OpenMP offloading runtime currently 
> > uses a size of zero to indicate a kernel function and the flags have a 
> > different meaning if it's a kernel. For OpenMP, 0 is a kernel, 1 and 2 are 
> > device ctors / dtors. I'm not sure why they chose this over just another 
> > flag but it's the current standard. You can see it used like this here 
> > https://github.com/llvm/llvm-project/blob/main/openmp/libomptarget/src/omptarget.cpp#L147.
> >  I'm not sure if there's a good way to wrangle these together now that I 
> > think about it, considering OpenMP already uses `0x1` to represent `link` 
> > OpenMP variables so this already collides. But treating the flags different 
> > on the size is at least consistent with what OpenMP does. It makes it a 
> > little hard to define one enum for it since we use it two different ways, 
> > I'm not a fan of it but it's what the current ABI uses.
> I see.
> 
> Using `size=0` as the coda/data flag which changes interpretation of the 
> flags sort of makes sense. In that case two different types for the flags 
> field would be appropriate, with an appropriate comment describing that 
> `size==0` determines which one is in effect.
> 
Personally I'm find with it landing like this, and if we wanted to improve this 
later it would probably just go in some greater ABI break for offloading 
entries. There might be a good reason to change them all at once when we start 
focusing more on complete interoperability of offloading languages.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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

[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/CodeGen/CGCUDARuntime.h:58
+  /// Mark the entry as a global variable.
+  OffloadGlobalEntry = 0x0,
+  /// Mark the entry as a managed global variable.

jhuber6 wrote:
> tra wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > We're still using the same numeric value for two different kinds of 
> > > > entities.
> > > > Considering that it's the third round we're making around this point, 
> > > > I'm starting to suspect that I may be missing something.
> > > > Is there a particular reason kernels and global unmanaged variables 
> > > > have to have the same 'kind'?
> > > > 
> > > > It's possible that I didn't do a good job explaining my enthusiastic 
> > > > nitpicking here.
> > > > My suggestion to have unified enum for **all** entities we register is 
> > > > based on a principle of separation of responsibilities. If we want to 
> > > > know what kind of entry we're dealing with, checking the 'kind' field 
> > > > should be sufficient. The 'size' field should only indicate the size of 
> > > > the entity. Having to consider both kind and size to determine what 
> > > > you're dealing with just muddies things and should not be done unless 
> > > > there's a good reason for that. E.g. it might be OK if we were short on 
> > > > flag bits.
> > > > 
> > > > 
> > > Ah, I see the point you're making now. This is yet another thing that 
> > > OpenMP did that I just copied. I wouldn't have implemented it this way 
> > > but I figured it would be simpler to keep them similar. I mostly did it 
> > > this way because I did some initial tests of registering and accessing 
> > > CUDA globals in OpenMP and it required using the same flags for the 
> > > kernels and globals. We could change it for CUDA in the future and I 
> > > could make that change here if it's valuable. Ideally I would like to 
> > > rewrite how we do all this registration with the structs but breaking the 
> > > ABI makes it complicated...
> > >  I did some initial tests of registering and accessing CUDA globals in 
> > > OpenMP and it required using the same flags for the kernels and globals.
> > 
> > OK. So, there is something that requires this magic. If that's something we 
> > must have, then it must be mentioned in the comments around the enum.
> > 
> > Do you know where I should find the code which needs this? I'm curious 
> > what's going on there.
> > I wonder if it just checks for "flags==0" and refuses to deal with unknown 
> > flags. 
> > To think of it, we probably want to put the enum into a common header which 
> > defines the `__tgt_offload_entry`.We would not want OpenMP itself to start 
> > using the same bits for something else.
> Sorry, I should be more specific. The OpenMP offloading runtime currently 
> uses a size of zero to indicate a kernel function and the flags have a 
> different meaning if it's a kernel. For OpenMP, 0 is a kernel, 1 and 2 are 
> device ctors / dtors. I'm not sure why they chose this over just another flag 
> but it's the current standard. You can see it used like this here 
> https://github.com/llvm/llvm-project/blob/main/openmp/libomptarget/src/omptarget.cpp#L147.
>  I'm not sure if there's a good way to wrangle these together now that I 
> think about it, considering OpenMP already uses `0x1` to represent `link` 
> OpenMP variables so this already collides. But treating the flags different 
> on the size is at least consistent with what OpenMP does. It makes it a 
> little hard to define one enum for it since we use it two different ways, I'm 
> not a fan of it but it's what the current ABI uses.
I see.

Using `size=0` as the coda/data flag which changes interpretation of the flags 
sort of makes sense. In that case two different types for the flags field would 
be appropriate, with an appropriate comment describing that `size==0` 
determines which one is in effect.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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

[PATCH] D125265: [OpenMP] Don't include the device wrappers if -nostdinc is used

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tianshilei1992, JonChesterfield, ABataev, 
tra.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a project: clang.

OpenMP uses several wrapper hearders to provide the definitions of
needed symbols contained in the host. However, some users may use the
`-nostdinc` option to override these definitions themselves. The OpenMP
wrapper headers are stored in the same location as the clang install. If
the user passes `-nostdinc` then this include directory is never looked
at by default which means that including these wrappers will always
fail. These headers should instead be included manually if they are
needed with a `-nostdinc` build.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125265

Files:
  clang/lib/Driver/ToolChains/Clang.cpp


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1308,6 +1308,7 @@
   // If we are offloading to a target via OpenMP we need to include the
   // openmp_wrappers folder which contains alternative system headers.
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
   (getToolChain().getTriple().isNVPTX() ||
getToolChain().getTriple().isAMDGCN())) {
 if (!Args.hasArg(options::OPT_nobuiltininc)) {


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1308,6 +1308,7 @@
   // If we are offloading to a target via OpenMP we need to include the
   // openmp_wrappers folder which contains alternative system headers.
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
   (getToolChain().getTriple().isNVPTX() ||
getToolChain().getTriple().isAMDGCN())) {
 if (!Args.hasArg(options::OPT_nobuiltininc)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers accepted this revision.
nickdesaulniers added a comment.

Worth mentioning the deprecation plans in `clang/docs/ReleaseNotes.rst` and 
updaing the commit message+description on phab?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Kees Cook via Phabricator via cfe-commits]

kees updated this revision to Diff 428173.
kees added a comment.
This revision is now accepted and ready to land.

update with suggestions

- Add FIXME comment with deprecation schedule
- Report deprecation warning when -enable flag is used


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -569,18 +569,19 @@
 
 // RUN: %clang -### -S -ftrivial-auto-var-init=uninitialized %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-UNINIT %s
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-GOOD %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-BAD %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO %s
+// RUN: %clang -### -S -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang \
+// RUN:   -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-ENABLE-DEPRECATED %s
 // CHECK-TRIVIAL-UNINIT-NOT: hasn't been enabled
 // CHECK-TRIVIAL-PATTERN-NOT: hasn't been enabled
-// CHECK-TRIVIAL-ZERO-GOOD-NOT: hasn't been enabled
-// CHECK-TRIVIAL-ZERO-BAD: hasn't been enabled
+// CHECK-TRIVIAL-ZERO-NOT: hasn't been enabled
+// CHECK-TRIVIAL-ZERO-ENABLE-DEPRECATED: has been deprecated
 
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN-STOP-AFTER %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero -ftrivial-auto-var-init-stop-after=1 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER %s
 // RUN: %clang -### -S -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-STOP-AFTER-MISSING-DEPENDENCY %s
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-PATTERN-STOP-AFTER-INVALID-VALUE %s
-// RUN: %clang -### -S -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER-INVALID-VALUE %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero -ftrivial-auto-var-init-stop-after=0 %s 2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-STOP-AFTER-INVALID-VALUE %s
 // CHECK-TRIVIAL-PATTERN-STOP-AFTER-NOT: is used without '-ftrivial-auto-var-init'
 // CHECK-TRIVIAL-PATTERN-STOP-AFTER-NOT: only accepts positive integers
 // CHECK-TRIVIAL-ZERO-STOP-AFTER-NOT: is used without '-ftrivial-auto-var-init'
Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -734,7 +734,6 @@
 // RUN: -fimplicit-modules \
 // RUN: -fno-implicit-modules \
 // RUN: -ftrivial-auto-var-init=zero \
-// RUN: -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang \
 // RUN: --version \
 // RUN: -Werror /Zs -- %s 2>&1
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3411,8 +3411,9 @@
 }
 
   if (!TrivialAutoVarInit.empty()) {
-if (TrivialAutoVarInit == "zero" && !Args.hasArg(options::OPT_enable_trivial_var_init_zero))
-  D.Diag(diag::err_drv_trivial_auto_var_init_zero_disabled);
+if (TrivialAutoVarInit == "zero" && Args.hasArg(options::OPT_enable_trivial_var_init_zero))
+  D.Diag(diag::warn_ignored_clang_option)
+  << "-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang";
 CmdArgs.push_back(
 Args.MakeArgString("-ftrivial-auto-var-init=" + TrivialAutoVarInit));
   }
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2697,9 +2697,10 @@
   Normaliz

[PATCH] D125259: [C11] Diagnose unreachable generic selection associations

[Tom Honermann via Phabricator via cfe-commits]

tahonermann accepted this revision.
tahonermann added a comment.

Looks good to me!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125259

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

[PATCH] D125259: [C11] Diagnose unreachable generic selection associations

[Erich Keane via Phabricator via cfe-commits]

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

One minor preference, otherwise LGTM.




Comment at: clang/lib/Sema/SemaExpr.cpp:1702
+
+  if (Reason)
+Diag(Types[i]->getTypeLoc().getBeginLoc(),

Splitting this up into the separate line for only 2 items seems like a waste, 
would it look better to just do the diag in each 'if'?  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125259

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

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[serge via Phabricator via cfe-commits]

serge-sans-paille added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:4267
+  bool IsConstant = CLETy.isConstant(Info.Ctx);
+  if (!IsConstant && CLETy->isArrayType()) {
+Info.FFDiag(Conv);

efriedma wrote:
> Is the "isArrayType()" check here necessary?
Yeah, otherwise we have an issue with

```
typedef __attribute__(( ext_vector_type(4) )) float float4;
float4 foo = (float4){ 1.0, 2.0, 3.0, 4.0 };
```

error: cannot compile this static initializer yet


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

https://reviews.llvm.org/D124038

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 428167.
yaxunl marked 2 inline comments as done.
yaxunl added a comment.

removed diagnostics and added more tests


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

https://reviews.llvm.org/D124866

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/test/CodeGenCUDA/noinline.cu
  clang/test/Lexer/has_extension.cu
  clang/test/SemaCUDA/noinline.cu

Index: clang/test/SemaCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/noinline.cu
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=cuda %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cpp -x c++ %s
+
+// cuda-no-diagnostics
+
+__noinline__ void fun1() { } // cpp-error {{unknown type name '__noinline__'}}
+
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }
+[[gnu::__noinline__]] void fun4() { }
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ void fun5() {}
Index: clang/test/Lexer/has_extension.cu
===
--- /dev/null
+++ clang/test/Lexer/has_extension.cu
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -E -triple x86_64-linux-gnu %s -o - | FileCheck %s
+
+// CHECK: has_noinline_keyword
+#if __has_extension(cuda_noinline_keyword)
+int has_noinline_keyword();
+#else
+int no_noinine_keyword();
+#endif
Index: clang/test/CodeGenCUDA/noinline.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/noinline.cu
@@ -0,0 +1,34 @@
+// Uses -O2 since the defalt -O0 option adds noinline to all functions.
+
+// RUN: %clang_cc1 -triple nvptx-nvidia-cuda -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - -x hip %s | FileCheck %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-gnu-linux \
+// RUN: -O2 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+__noinline__ __device__ __host__ void fun1() {}
+
+__attribute__((noinline)) __device__ __host__ void fun2() {}
+
+__attribute__((__noinline__)) __device__ __host__ void fun3() {}
+
+[[gnu::__noinline__]] __device__ __host__ void fun4() {}
+
+#define __noinline__ __attribute__((__noinline__))
+__noinline__ __device__ __host__ void fun5() {}
+
+__device__ __host__ void fun6() {}
+
+// CHECK: define{{.*}}@_Z4fun1v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun2v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun3v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun4v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun5v{{.*}}#[[ATTR1:[0-9]*]]
+// CHECK: define{{.*}}@_Z4fun6v{{.*}}#[[ATTR2:[0-9]*]]
+// CHECK: attributes #[[ATTR1]] = {{.*}}noinline
+// CHECK-NOT: attributes #[[ATTR2]] = {{.*}}noinline
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -897,6 +897,15 @@
   }
 }
 
+void Parser::ParseCUDAFunctionAttributes(ParsedAttributes &attrs) {
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();
+attrs.addNew(AttrName, AttrNameLoc, nullptr, AttrNameLoc, nullptr, 0,
+ ParsedAttr::AS_Keyword);
+  }
+}
+
 void Parser::ParseOpenCLQualifiers(ParsedAttributes &Attrs) {
   IdentifierInfo *AttrName = Tok.getIdentifierInfo();
   SourceLocation AttrNameLoc = Tok.getLocation();
@@ -3690,6 +3699,11 @@
   ParseOpenCLKernelAttributes(DS.getAttributes());
   continue;
 
+// CUDA/HIP single token adornments.
+case tok::kw___noinline__:
+  ParseCUDAFunctionAttributes(DS.getAttributes());
+  continue;
+
 // Nullability type specifiers.
 case tok::kw__Nonnull:
 case tok::kw__Nullable:
Index: clang/lib/Basic/IdentifierTable.cpp
===
--- clang/lib/Basic/IdentifierTable.cpp
+++ clang/lib/Basic/IdentifierTable.cpp
@@ -108,6 +108,7 @@
 KEYOPENCLCXX  = 0x40,
 KEYMSCOMPAT   = 0x80,
 KEYSYCL   = 0x100,
+KEYCUDA   = 0x200,
 KEYALLCXX = KEYCXX | KEYCXX11 | KEYCXX20,
 KEYALL = (0x1ff & ~KEYNOMS18 &
   ~KEYNOOPENCL) // KEYNOMS18 and KEYNOOPENCL are used to exclude.
@@ -158,6 +159,8 @@
 return KS_Future;
   if (LangOpts.isSYCL() && (Flags & KEYSYCL))
 return KS_Enabled;
+  if (LangOpts.CUDA && (Flags & KEYCUDA))
+return KS_Enabled;
   return KS_Disabled;
 }
 
Index: clang/include/clang/Parse/Parser.

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked 4 inline comments as done.
yaxunl added a comment.

In D124866#3501203 , @aaron.ballman 
wrote:

>> `__forceinline__` does not have the issue as `__noinline__` has since it is 
>> not a GCC attribute. The current CUDA/HIP implementation of 
>> `__forceinline__` in header files is sufficient. I do not see the benefit of 
>> implementing `__forceinline__` as a keyword.
>
> Primarily to reduce user confusion. It's kind of weird for `__noinline__` to 
> be a keyword and `__forceinline__` to not be a keyword when they're both 
> defined the same way by the CUDA spec. This means you can #undef one of them 
> but not the other, that sort of thing.

If we are to add `__forceinline__` as a keyword, I feel it better be a separate 
patch to be cleaner.




Comment at: clang/lib/Parse/ParseDecl.cpp:902
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();

tra wrote:
> aaron.ballman wrote:
> > yaxunl wrote:
> > > aaron.ballman wrote:
> > > > I think we should we be issuing a pedantic "this is a clang extension" 
> > > > warning here, WDYT?
> > > will do
> > I'm questioning whether my advice here was good or not -- now that I see 
> > the CUDA spec already calls these function qualifiers... it's debatable 
> > whether this is a Clang extension or just the way in which Clang implements 
> > the CUDA function qualifiers. @tra -- do you have opinions?
> > 
> > I'm sort of leaning towards dropping the extension warning, but the only 
> > reason I can think of for keeping it is if Clang is the only CUDA compiler 
> > that doesn't require you to include a header before using the function 
> > qualifiers. If that's the case, there is a portability concern.
> I'm not sure if such a warning would be useful. 
> 
> > the only reason I can think of for keeping it is if Clang is the only CUDA 
> > compiler that doesn't require you to include a header before using the 
> > function qualifiers. If that's the case, there is a portability concern.
> 
> I don't think it's an issue.
> 
> We already have similar divergence between nvcc/clang. E.g. built-in 
> variables like `threadIdx`. Clang implements them in a header, but NVCC 
> provides them by compiler itself. 
> With both compilers the variables are available by the time we get to compile 
> user code. Virtually all CUDA compilations are done with tons of CUDA headers 
> pre-included by compiler. Those that do not do that are already on their own 
> and have to provide many other 'standard' CUDA things like target attributes. 
> I don't think we need to worry about that.
> 
I can remove the diagnostics since it seems unnecessary.

I tend to treat it as an extension since nvcc is the de facto standard 
implementation, which does not implement it as a keyword. Compared to that, 
this is like an extension.



Comment at: clang/test/CodeGenCUDA/noinline.cu:1
+// optimization is needed, otherwise by default all functions have noinline.
+

erichkeane wrote:
> aaron.ballman wrote:
> > I've asked @erichkeane to weigh in on whether there's a better approach 
> > here than specifying an optimization level.
> You don't need to do this, it looks like all you're trying to do is keep 
> 'clang' out of `O0` mode.  However, what you do  NOT want is the 
> optimizations to run.  The common way to do that is to combine `O1`/`O2`/etc 
> like: `-O2 -disable-llvm-passes`
> 
> This will keep clang in `O2` mode, but will keep the optimizer from running 
> anything, which might mess with the test later on.
will use -O2 -disable-llvm-passes



Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }

aaron.ballman wrote:
> yaxunl wrote:
> > aaron.ballman wrote:
> > > I think there should also be a test like:
> > > ```
> > > [[gnu::__noinline__]] void fun4() {}
> > > ```
> > > to verify that the double square bracket syntax also correctly handles 
> > > this being a keyword now (I expect the test to pass).
> > will do
> Ah, I just noticed we also have no tests for the behavior of the keyword in 
> the presence of the macro being defined. e.g.,
> ```
> #define __noinline__ __attribute__((__noinline__))
> __noinline__ void fun5() {}
> ```
will do


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

https://reviews.llvm.org/D124866

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

[PATCH] D124836: [AArch64] Add support for -fzero-call-used-regs

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

@peterwaller-arm @sdesmalen Could you comment on what is considered the 
canonical way to zero Arm registers? Is `mov x1, #0` the way or `mov x1, xzr` 
or some other way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124836

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

[PATCH] D124836: [AArch64] Add support for -fzero-call-used-regs

[Bill Wendling via Phabricator via cfe-commits]

void added inline comments.



Comment at: llvm/test/CodeGen/AArch64/zero-call-used-regs.ll:233
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone 
willreturn uwtable "frame-pointer"="non-leaf" "min-legal-vector-width"="0" 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="generic" "target-features"="+neon,+v8a" }

peterwaller-arm wrote:
> Thanks for addressing the SVE case. Please can we have `target-features=+sve` 
> tests as well?
> Thanks for addressing the SVE case. Please can we have `target-features=+sve` 
> tests as well?

Yes. :-) I'm working on a few other clean-up things so they'll be coming soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124836

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D124866#3501203 , @aaron.ballman 
wrote:

>>> Should we do `__forceinline__` at the same time so that there's consistency?
>
> Primarily to reduce user confusion. It's kind of weird for `__noinline__` to 
> be a keyword and `__forceinline__` to not be a keyword when they're both 
> defined the same way by the CUDA spec. This means you can #undef one of them 
> but not the other, that sort of thing.

I'm slightly biased towards making them both a keyword. That said, I may be 
convinced otherwise if we discover that it may break some assumptions in 
existing C++ code. I just don't know enough.




Comment at: clang/lib/Parse/ParseDecl.cpp:902
+  while (Tok.is(tok::kw___noinline__)) {
+IdentifierInfo *AttrName = Tok.getIdentifierInfo();
+SourceLocation AttrNameLoc = ConsumeToken();

aaron.ballman wrote:
> yaxunl wrote:
> > aaron.ballman wrote:
> > > I think we should we be issuing a pedantic "this is a clang extension" 
> > > warning here, WDYT?
> > will do
> I'm questioning whether my advice here was good or not -- now that I see the 
> CUDA spec already calls these function qualifiers... it's debatable whether 
> this is a Clang extension or just the way in which Clang implements the CUDA 
> function qualifiers. @tra -- do you have opinions?
> 
> I'm sort of leaning towards dropping the extension warning, but the only 
> reason I can think of for keeping it is if Clang is the only CUDA compiler 
> that doesn't require you to include a header before using the function 
> qualifiers. If that's the case, there is a portability concern.
I'm not sure if such a warning would be useful. 

> the only reason I can think of for keeping it is if Clang is the only CUDA 
> compiler that doesn't require you to include a header before using the 
> function qualifiers. If that's the case, there is a portability concern.

I don't think it's an issue.

We already have similar divergence between nvcc/clang. E.g. built-in variables 
like `threadIdx`. Clang implements them in a header, but NVCC provides them by 
compiler itself. 
With both compilers the variables are available by the time we get to compile 
user code. Virtually all CUDA compilations are done with tons of CUDA headers 
pre-included by compiler. Those that do not do that are already on their own 
and have to provide many other 'standard' CUDA things like target attributes. I 
don't think we need to worry about that.



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

https://reviews.llvm.org/D124866

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

[PATCH] D125259: [C11] Diagnose unreachable generic selection associations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: tahonermann, jyknight, eli.friedman, 
clang-language-wg.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

The controlling expression of a `_Generic` selection expression undergoes 
lvalue conversion, array conversion, and function conversion before picking the 
association. This means that array types, function types, and qualified types 
are all unreachable code if they're used as an association. I've been caught by 
this twice in the past few months and I figure that if a WG14 member can't seem 
to remember this rule, users are also likely to struggle with it. So this adds 
an on-by-default unreachable code diagnostic for generic selection expression 
associations.

Note, we don't have to worry about function types as those are already a 
constraint violation which generates an error.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125259

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/generic-selection.c


Index: clang/test/Sema/generic-selection.c
===
--- clang/test/Sema/generic-selection.c
+++ clang/test/Sema/generic-selection.c
@@ -57,3 +57,14 @@
   _Generic(n++, int : 0) // expected-error {{cannot increment value of 
type 'int ()'}} ext-warning {{'_Generic' is a C11 extension}}
 ), int : 0);
 }
+
+void unreachable_associations(const int i) {
+  _Static_assert( // ext-warning {{'_Static_assert' is a C11 extension}}
+_Generic(i, // ext-warning {{'_Generic' is a C11 extension}}
+  const int : 1,// expected-warning {{due to lvalue conversion of the 
controlling expression, association of type 'const int' will never be selected 
because it is qualified}}
+  volatile int : 2, // expected-warning {{due to lvalue conversion of the 
controlling expression, association of type 'volatile int' will never be 
selected because it is qualified}}
+  int[12] : 3,  // expected-warning {{due to lvalue conversion of the 
controlling expression, association of type 'int[12]' will never be selected 
because it is of array type}}
+  int : 4,
+  default : 5
+) == 4, "we had better pick int!");
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -1685,6 +1685,25 @@
   D = diag::err_assoc_type_nonobject;
 else if (Types[i]->getType()->isVariablyModifiedType())
   D = diag::err_assoc_type_variably_modified;
+else {
+  // Because the controlling expression undergoes lvalue conversion,
+  // array conversion, and function conversion, an association which is
+  // of array type, function type, or is qualified can never be
+  // reached. We will warn about this so users are less surprised by
+  // the unreachable association. However, we don't have to handle
+  // function types; that's not an object type, so it's handled above.
+  unsigned Reason = 0;
+  QualType QT = Types[i]->getType();
+  if (QT->isArrayType())
+Reason = 1;
+  else if (QT.hasQualifiers())
+Reason = 2;
+
+  if (Reason)
+Diag(Types[i]->getTypeLoc().getBeginLoc(),
+ diag::warn_unreachable_association)
+<< QT << (Reason - 1);
+}
 
 if (D != 0) {
   Diag(Types[i]->getTypeLoc().getBeginLoc(), D)
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -693,6 +693,10 @@
   InGroup, DefaultIgnore;
 def note_unreachable_silence : Note<
   "silence by adding parentheses to mark code as explicitly dead">;
+def warn_unreachable_association : Warning<
+  "due to lvalue conversion of the controlling expression, association of type 
"
+  "%0 will never be selected because it is %select{of array type|qualified}1">,
+  InGroup;
 
 /// Built-in functions.
 def ext_implicit_lib_function_decl : ExtWarn<
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -843,9 +843,11 @@
 //
 def UnreachableCodeLoopIncrement : 
DiagGroup<"unreachable-code-loop-increment">;
 def UnreachableCodeFallthrough : DiagGroup<"unreachable-code-fallthrough">;
+def UnreachableCodeGenericAssoc : DiagGroup<"unreachable-code-generic-assoc">;
 def UnreachableCode : DiagGroup<"unreachable-code",
 [UnreachableCodeLoopIncrement,

[PATCH] D125258: [docs][pp-trace] Remove FileNotFound callback

[Tommy Chiang via Phabricator via cfe-commits]

oToToT created this revision.
oToToT added a reviewer: jansvoboda11.
Herald added a project: All.
oToToT requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

`FileNotFound` preprocessor callback is removed in D119708 
.
We should also remove it from the documentation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125258

Files:
  clang-tools-extra/docs/pp-trace.rst


Index: clang-tools-extra/docs/pp-trace.rst
===
--- clang-tools-extra/docs/pp-trace.rst
+++ clang-tools-extra/docs/pp-trace.rst
@@ -49,7 +49,6 @@
 
   * FileChanged
   * FileSkipped
-  * FileNotFound
   * InclusionDirective
   * moduleImport
   * EndOfMainFile
@@ -200,26 +199,6 @@
 FilenameTok: "filename.h"
 FileType: C_User
 
-`FileNotFound 
`_
 Callback
-^^
-
-FileNotFound is called when an inclusion directive results in a file-not-found 
error.
-
-Argument descriptions:
-
-==   ==   
== 
=
-Argument NameArgument Value SyntaxClang 
C++ Type Description
-==   ==   
== 
=
-FileName "(file)" 
StringRef  The name of the file being included, as written 
in the source code.
-RecoveryPath (path)   
SmallVectorImpl  If this client indicates that it can recover 
from this missing file, the client should set this as an additional header 
search patch.
-==   ==   
== 
=
-
-Example:::
-
-  - Callback: FileNotFound
-FileName: "/path/filename.h"
-RecoveryPath:
-
 `InclusionDirective 
`_
 Callback
 

 


Index: clang-tools-extra/docs/pp-trace.rst
===
--- clang-tools-extra/docs/pp-trace.rst
+++ clang-tools-extra/docs/pp-trace.rst
@@ -49,7 +49,6 @@
 
   * FileChanged
   * FileSkipped
-  * FileNotFound
   * InclusionDirective
   * moduleImport
   * EndOfMainFile
@@ -200,26 +199,6 @@
 FilenameTok: "filename.h"
 FileType: C_User
 
-`FileNotFound `_ Callback
-^^
-
-FileNotFound is called when an inclusion directive results in a file-not-found error.
-
-Argument descriptions:
-
-==   ==   == =
-Argument NameArgument Value SyntaxClang C++ Type Description
-==   ==   == =
-FileName "(file)" StringRef  The name of the file being included, as written in the source code.
-RecoveryPath (path)   SmallVectorImpl  If this client indicates that it can recover from this missing file, the client should set this as an additional header search patch.
-==   ==   == =
-
-Example:::
-
-  - Callback: FileNotFound
-FileName: "/path/filename.h"
-RecoveryPath:
-
 `InclusionDirective 

[PATCH] D125006: [pseudo] Support parsing variant target symbols.

[Sam McCall via Phabricator via cfe-commits]

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

Very nice!
And change to compiled grammar size is small.
Would including *every* nonterminal as a start symbol would blow the size up a 
bit?
This would eliminate some complexity in the interface.




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:125
 };
-// Parse the given token stream with the GLR algorithm, and return a forest 
node
-// of the start symbol.

From the caller's perspective, is "target symbol" really a clearer name than 
"start symbol"? The latter seems like more common terminology.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:126
+// Parses the given token stream as the Target symbol with the GLR algorithm,
+// and returns a forest node of the target symbol.
 //

// A rule `_ := Target` must exist for the chosen target symbol.



Comment at: clang-tools-extra/pseudo/lib/LRGraph.cpp:163
 LRGraph LRGraph::buildLR0(const Grammar &G) {
+  std::vector> StartStates;
   class Builder {

might be clearer just to make this a member of the builder, and add a 
`addStartState(SymbolID, StateID)` method?



Comment at: clang-tools-extra/pseudo/lib/LRTableBuild.cpp:43
 public:
+  Builder(std::vector> StartStates)
+  : StartStates(std::move(StartStates)) {}

nit: since we're ultimately copying this array to call the constructor, maybe 
just take ArrayRef here?



Comment at: clang-tools-extra/pseudo/lib/cxx.bnf:28
 #
-# _ serves as a "fake" start symbol, coming with real grammar symbols.
+# _ serves as a "fake" start symbol, coming with real grammar symbols which we
+# target to parse.

Maybe "_ lists all the start-symbols which we support parsing".



Comment at: clang-tools-extra/pseudo/tool/ClangPseudo.cpp:41
 static opt PrintForest("print-forest", desc("Print parse forest"));
+static opt ParseSymbol("parse-symbol",
+desc("specify the target symbol to parse"),

-start-symbol might be more common



Comment at: clang-tools-extra/pseudo/tool/ClangPseudo.cpp:57
+static clang::pseudo::SymbolID
+findNonterminalID(llvm::StringRef Name, const clang::pseudo::Grammar &G) {
+  for (clang::pseudo::SymbolID ID = 0; ID < G.table().Nonterminals.size(); 
++ID)

nit: just findNonterminal()? rather than echoing the type


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125006

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

[PATCH] D125256: [OpenMP] Add __CUDA_ARCH__ definition when offloading with OpenMP

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tra, tianshilei1992.
Herald added subscribers: mattd, gchakrabarti, asavonic, guansong, yaxunl, 
jholewinski.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Currently we define the __CUDA_ARCH__ macro only in CUDA mode. This
patch allows us to use this macro in OpenMP-offloading mode when
targeting NVPTX.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125256

Files:
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/test/OpenMP/driver-openmp-target.c


Index: clang/test/OpenMP/driver-openmp-target.c
===
--- clang/test/OpenMP/driver-openmp-target.c
+++ clang/test/OpenMP/driver-openmp-target.c
@@ -1,4 +1,8 @@
 // REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
 // REQUIRES: clang-target-64-bits
+
 // RUN: %clang %s -c -E -dM -fopenmp=libomp -fopenmp-version=45 
-fopenmp-targets=x86_64-unknown-unknown -o - | FileCheck 
--check-prefix=CHECK-45-VERSION %s
 // CHECK-45-VERSION: #define _OPENMP 201511
+// RUN: %clang %s -c -E -dM -fopenmp=libomp -nogpulib --offload-arch=sm_70 
--offload-device-only -o - | FileCheck --check-prefix=CHECK-CUDA-ARCH %s
+// CHECK-CUDA-ARCH: #define __CUDA_ARCH__ 700
Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -179,7 +179,7 @@
MacroBuilder &Builder) const {
   Builder.defineMacro("__PTX__");
   Builder.defineMacro("__NVPTX__");
-  if (Opts.CUDAIsDevice) {
+  if (Opts.CUDAIsDevice || Opts.OpenMPIsDevice) {
 // Set __CUDA_ARCH__ for the GPU specified.
 std::string CUDAArchCode = [this] {
   switch (GPU) {


Index: clang/test/OpenMP/driver-openmp-target.c
===
--- clang/test/OpenMP/driver-openmp-target.c
+++ clang/test/OpenMP/driver-openmp-target.c
@@ -1,4 +1,8 @@
 // REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
 // REQUIRES: clang-target-64-bits
+
 // RUN: %clang %s -c -E -dM -fopenmp=libomp -fopenmp-version=45 -fopenmp-targets=x86_64-unknown-unknown -o - | FileCheck --check-prefix=CHECK-45-VERSION %s
 // CHECK-45-VERSION: #define _OPENMP 201511
+// RUN: %clang %s -c -E -dM -fopenmp=libomp -nogpulib --offload-arch=sm_70 --offload-device-only -o - | FileCheck --check-prefix=CHECK-CUDA-ARCH %s
+// CHECK-CUDA-ARCH: #define __CUDA_ARCH__ 700
Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -179,7 +179,7 @@
MacroBuilder &Builder) const {
   Builder.defineMacro("__PTX__");
   Builder.defineMacro("__NVPTX__");
-  if (Opts.CUDAIsDevice) {
+  if (Opts.CUDAIsDevice || Opts.OpenMPIsDevice) {
 // Set __CUDA_ARCH__ for the GPU specified.
 std::string CUDAArchCode = [this] {
   switch (GPU) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125167: [WIP] Fix member access of anonymous struct/union fields in C

[Nick Desaulniers via Phabricator via cfe-commits]

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

Consider adding an AST test; that was something that came up in my patch 
https://reviews.llvm.org/D95408.

> I'm pushing back on the WG14 lists to see if this is a good opportunity to 
> clarify the other direction and be compatible with C++ in the process.

It would really be good to have some clarification from WG14 added to the spec; 
as is, code is being written in the Linux kernel that uses this functionality 
to avoid marking all members of an anonymous aggregate as `const`. This is 
resulting in code being submitted where clang doesn't error on modification of 
such members, while GCC errors, so such patches are rejected.  So developers 
using clang are getting caught off guard for a code base that needs to be 
compiler portable.

Kernel developers were of the opinion that it is nice syntactic sugar. For that 
reason, I agree with them. But I'm also fine leaving this out of clang until 
the spec is amended to clarify.  That said, if WG14 doesn't pursue this (but 
doesn't reject or accept), I'd like to have this in clang sooner for better 
compatibility with GCC.  It is too bad though if WG14 chooses to further 
diverge C from C++ over this...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125167

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

[PATCH] D124790: [HLSL] Enable half type for hlsl.

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 428153.
python3kgae added a comment.

Add Sema test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124790

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/LangOptions.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HLSL.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenHLSL/half.hlsl
  clang/test/SemaHLSL/half.hlsl

Index: clang/test/SemaHLSL/half.hlsl
===
--- /dev/null
+++ clang/test/SemaHLSL/half.hlsl
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -xhlsl -triple dxil-pc-shadermodel6.7-compute -validator-version 1.0 -fnative-half-arguments-and-returns -ast-dump -fnative-half-type -o - %s | FileCheck %s --check-prefix=F16
+// RUN: %clang_cc1 -xhlsl -triple dxil-pc-shadermodel6.7-compute -validator-version 1.0 -fnative-half-arguments-and-returns -ast-dump -o - %s | FileCheck %s --check-prefix=F32
+
+// Make sure when -fnative-half-type is enabled, half is half in ast.
+// F16:FunctionDecl 0x{{.*}} <{{.*}}\half.hlsl:27:1, line:29:1> line:27:6 foo 'half (half, float)'
+// F16:ParmVarDecl 0x{{.*}}  col:15 used a 'half'
+// F16:ImplicitCastExpr 0x{{.*}}  'half' 
+// F16:BinaryOperator 0x{{.*}}  'float' '+'
+// F16:VarDecl 0x{{.*}}  col:19 used h 'const half' static cinit
+// F16:ImplicitCastExpr 0x{{.*}}  'const half' 
+// F16:VarDecl 0x{{.*}}  col:20 used f 'const float' static cinit
+// F16:VarDecl 0x{{.*}}  col:19 h2 'const half' static cinit
+// F16:ImplicitCastExpr 0x{{.*}}  'const half' 
+
+// Make sure when -fnative-half-type is disabled, half is float in ast.
+// F32:FunctionDecl 0x{{.*}} <{{.*}}\half.hlsl:27:1, line:29:1> line:27:6 foo 'float (float, float)'
+// F32:ParmVarDecl 0x{{.*}}  col:15 used a 'float'
+// F32-NOT:FloatingCast
+// F32:BinaryOperator 0x{{.*}}  'float' '+'
+// F32:VarDecl 0x{{.*}}  col:19 used h 'const float' static cinit
+// F32-NOT:FloatingCast
+// F32:VarDecl 0x{{.*}}  col:20 used f 'const float' static cinit
+// F32-NOT:FloatingCast
+// F32:VarDecl 0x{{.*}}  col:19 h2 'const float' static cinit
+// F32:BinaryOperator 0x{{.*}}  'float' '+'
+
+half foo(half a, float b) {
+  return a+b;
+}
+
+static const half h = 1.0f;
+static const float f = 2.0f;
+static const half h2 = h + f;
+
+
Index: clang/test/CodeGenHLSL/half.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/half.hlsl
@@ -0,0 +1,15 @@
+// RUN: %clang_dxc -Tlib_6_7 -fcgl  -Fo - %s | FileCheck %s --check-prefix=FLOAT
+// RUN: %clang_dxc -Tlib_6_7 -enable-16bit-types -fcgl  -Fo - %s | FileCheck %s --check-prefix=HALF
+
+// Make sure use float when not enable-16bit-types.
+// FLOAT:define {{.*}}float @_Z3fooff(float{{[^,]+}}, float{{[^,)]+}})
+// FLOAT-NOT:half
+// FLOAT:ret float %
+
+// Make sure use half when enable-16bit-types.
+// HALF:define {{.*}}half @_Z3fooDhDh(half{{[^,]+}}, half{{[^,)]+}})
+// HALF-NOT:float
+// HALF:ret half %
+half foo(half a, half b) {
+  return a+b;
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1508,7 +1508,13 @@
 << "_Float16";
 Result = Context.Float16Ty;
 break;
-  case DeclSpec::TST_half:Result = Context.HalfTy; break;
+  case DeclSpec::TST_half:
+// For HLSL, when not enable native half type, half will be treat as float.
+if (S.getLangOpts().HLSL && !S.getLangOpts().NativeHalfType)
+  Result = Context.FloatTy;
+else
+  Result = Context.HalfTy;
+break;
   case DeclSpec::TST_BFloat16:
 if (!S.Context.getTargetInfo().hasBFloat16Type())
   S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported)
Index: clang/lib/Driver/ToolChains/HLSL.cpp
===
--- clang/lib/Driver/ToolChains/HLSL.cpp
+++ clang/lib/Driver/ToolChains/HLSL.cpp
@@ -188,5 +188,7 @@
 Opts.getOption(options::OPT_dxil_validator_version),
 DefaultValidatorVer);
   }
+  // FIXME: add validation for enable_16bit_types should be after HLSL 2018 and
+  // shader model 6.2.
   return DAL;
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3473,11 +3473,13 @@
   types::ID InputType) {
   const unsigned ForwardedArguments[] = {options::OPT_dxil_validator_version,
  options::OPT_S, options::OPT_emit_llvm,
- options::OPT_disable_llvm_passes};
+ options::OPT_disable_llvm_passes,
+ options::OPT_fna

[PATCH] D95408: [Sema][C] members of anonymous struct inherit QualType

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers abandoned this revision.
nickdesaulniers added a comment.
Herald added a project: All.

Prefer https://reviews.llvm.org/D125167.




Comment at: clang/test/AST/ast-dump-decl.c:132
 
+// CHECK: IndirectFieldDecl{{.*}} Test48755Const 'int'
+// CHECK-NEXT: Field{{.*}} 'const struct testIndirectFieldDecl::{{.*}}'

aaron.ballman wrote:
> This looks wrong to me -- I would have assumed the type would be `const int` 
> and not `int`, which would match the behavior if the type was directly 
> qualified: https://godbolt.org/
Sorry, that godbolt link appears to be malformed (missing unique link)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95408

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

[PATCH] D125254: [clang] Allow all string types for all attribute(format) styles

[Félix Cloutier via Phabricator via cfe-commits]

fcloutier created this revision.
fcloutier added reviewers: NoQ, ahatanak, aaron.ballman.
Herald added a project: All.
fcloutier requested review of this revision.
Herald added a project: clang.

It's not unusual to see functions like this:

  void log(const char *fmt, ...) {
  va_list ap;
  va_start(ap, fmt);
  NSLogv([NSString stringWithCString:fmt], ap);
  va_end(ap);
  }

Currently, such a function can't be annotated with `__attribute__((format))`. 
It can't do `__attribute__((format(printf)))` because `printf` does not accept 
the `%@` format specifier (while this function does support it) and it can't do 
`__attribute__((format(NSString)))` because the format argument is not a 
`NSString *`. It's not always reasonable to ask the owners of these functions 
to change the type of the format argument as it can be an ABI-breaking change. 
The only viable thing to do is to not annotate `log` at all, which precludes 
using `-Wformat-nonliteral` (as it will trigger on the `NSLogv` line) and may 
hide format bugs in users of `log`.

This patch allows all string types for all format kinds and leaves it up to the 
user to convert the format string with a function that has the correct 
`__attribute__((format_arg))` annotation. The example above can now be 
annotated with `__attribute__((format(NSString, 1, 2)))` and pass 
`-Wformat-nonliteral`, provided that `[NSString stringWithCString:]` is 
modified to have `__attribute__((format_arg(1)))`.

It is still a diagnostic to mix format strings with different format styles, so 
for instance you can't pass a `printf`-style format string to `[NSString 
stringWithFormat:]` even if you've converted it to a `NSString *`:

  void log(const char *fmt, ...) __attribute__((format(printf, 1, 2))) {
  va_list ap;
  va_start(ap, fmt);
  NSLogv([NSString stringWithCString:fmt], ap); // warning: format string 
is not a string literal [-Wformat-nonliteral]
  va_end(ap);
  }

rdar://89060618


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125254

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/SemaObjC/format-strings-objc.m


Index: clang/test/SemaObjC/format-strings-objc.m
===
--- clang/test/SemaObjC/format-strings-objc.m
+++ clang/test/SemaObjC/format-strings-objc.m
@@ -60,8 +60,23 @@
 }
 
 // Check type validation
-extern void NSLog2(int format, ...) __attribute__((format(__NSString__, 1, 
2))); // expected-error {{format argument not an NSString}}
-extern void CFStringCreateWithFormat2(int *format, ...) 
__attribute__((format(CFString, 1, 2))); // expected-error {{format argument 
not a CFString}}
+extern void NSLog2(int format, ...) __attribute__((format(__NSString__, 1, 
2))); // expected-error {{format argument not a string type}}
+extern void CFStringCreateWithFormat2(int *format, ...) 
__attribute__((format(CFString, 1, 2))); // expected-error {{format argument 
not a string type}}
+
+// Check interoperability of strings
+extern void NSLog3(const char *, ...) __attribute__((format(__NSString__, 1, 
2)));
+extern void CFStringCreateWithFormat3(const char *, ...) 
__attribute__((format(__NSString__, 1, 2)));
+extern void printf2(NSString *format, ...) __attribute__((format(printf, 1, 
2)));
+
+extern NSString *CStringToNSString(const char *) 
__attribute__((format_arg(1)));
+
+void NSLog3(const char *fmt, ...) {
+  NSString *const nsFmt = CStringToNSString(fmt);
+  va_list ap;
+  va_start(ap, fmt);
+  NSLogv(nsFmt, ap);
+  va_end(ap);
+}
 
 //  - Catch use of long long with int arguments.
 void rdar_7068334(void) {
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3661,8 +3661,7 @@
   (!Ty->isPointerType() ||
!Ty->castAs()->getPointeeType()->isCharType())) {
 S.Diag(AL.getLoc(), diag::err_format_attribute_not)
-<< "a string type" << IdxExpr->getSourceRange()
-<< getFunctionOrMethodParamRange(D, 0);
+<< IdxExpr->getSourceRange() << getFunctionOrMethodParamRange(D, 0);
 return;
   }
   Ty = getFunctionOrMethodResultType(D);
@@ -3862,27 +3861,13 @@
   // make sure the format string is really a string
   QualType Ty = getFunctionOrMethodParamType(D, ArgIdx);
 
-  if (Kind == CFStringFormat) {
-if (!isCFStringType(Ty, S.Context)) {
-  S.Diag(AL.getLoc(), diag::err_format_attribute_not)
-<< "a CFString" << IdxExpr->getSourceRange()
-<< getFunctionOrMethodParamRange(D, ArgIdx);
-  return;
-}
-  } else if (Kind == NSStringFormat) {
-// FIXME: do we need to check if the type is NSString*?  What are the
-// semantics?
-if (!isNSStringType(Ty, S.Context, /*AllowNSAttributedString=*/true)) {
-  S.Diag(AL.getLoc(), diag::err_format_attribute_not)
-<< "an NSString" << IdxExpr->getSourceRange

[PATCH] D120301: clang-tools-extra: Make test dependency on LLVMHello optional

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: clang-tools-extra/test/CMakeLists.txt:107
+  if (TARGET  LLVMHello)
+list(APPEND CLANG_TOOLS_TEST_DEPS CTTestTidyModule)
+  endif()

Shouldn't this be LLVMHello?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120301

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

[PATCH] D122766: [clang] Add the flag -ffile-reproducible

[Alan Zhao via Phabricator via cfe-commits]

ayzhao updated this revision to Diff 428139.
ayzhao added a comment.

Clarify --fno-file-reproducible HelpText


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122766

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/AST/Expr.cpp
  clang/lib/Basic/LangOptions.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/test/CodeGenCXX/builtin-source-location.cpp
  clang/test/Preprocessor/file_test.c
  clang/test/Preprocessor/file_test_windows.c

Index: clang/test/Preprocessor/file_test_windows.c
===
--- clang/test/Preprocessor/file_test_windows.c
+++ clang/test/Preprocessor/file_test_windows.c
@@ -1,9 +1,25 @@
 // REQUIRES: system-windows
-// RUN: %clang -E -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
-// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
-// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
-// RUN: %clang -E -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE
-// RUN: %clang -E -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -fno-file-reproducible -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// RUN: %clang -E -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s --check-prefix CHECK-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s --check-prefix CHECK-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE-REPRODUCIBLE
+
+// RUN: %clang -E -target x86_64-pc-linux-gnu -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -target x86_64-pc-linux-gnu -ffile-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// Clang defaults to forward slashes for the non-prefix portion of the path even if the build environment is Windows.
+// RUN: %clang -E -fno-file-reproducible -target x86_64-pc-linux-gnu -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -fno-file-reproducible -target x86_64-pc-linux-gnu -ffile-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// RUN: %clang -E -ffile-reproducible -target x86_64-pc-win32 -c -o - %s | FileCheck %s --check-prefix CHECK-WINDOWS-FULL
+// RUN: %clang -E -ffile-reproducible -target x86_64-pc-linux-gnu -c -o - %s | FileCheck %s --check-prefix CHECK-LINUX-FULL
 
 filename: __FILE__
 #include "Inputs/include-file-test/file_test.h"
@@ -27,3 +43,34 @@
 // CHECK-REMOVE: filename: "Inputs/include-file-test/file_test.h"
 // CHECK-REMOVE: basefile: "file_test_windows.c"
 // CHECK-REMOVE-NOT: filename:
+
+// CHECK-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH\\empty\\file_test_windows.c"
+// CHECK-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH\\empty\\Inputs\\include-file-test\\file_test.h"
+// CHECK-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH\\empty\\file_test_windows.c"
+// CHECK-REPRODUCIBLE-NOT: filename:
+
+// CHECK-EVIL-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH=empty\\file_test_windows.c"
+// CHECK-EVIL-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH=empty\\Inputs\\include-file-test\\file_test.h"
+// CHECK-EVIL-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH=empty\\file_test_windows.c"
+// CHECK-EVIL-REPRODUCIBLE-NOT: filename:
+
+// CHECK-CASE-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH_BASE\\file_test_windows.c"
+// CHECK-CASE-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH_INC\\include-file-test\\file_test.h"
+// CHECK-CASE-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH_BASE\\file_test_windows.c"
+// CHECK-CASE-REPRODUCIBLE-NOT: filename:
+
+// CHECK-REMOVE-REPRODUCIBLE: filename: "

[PATCH] D122766: [clang] Add the flag -ffile-reproducible

[Hans Wennborg via Phabricator via cfe-commits]

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

I still wish this could just be the default behavior, but this flag seems a 
good compromise.

LGTM (but please wait for Aaron too)




Comment at: clang/include/clang/Driver/Options.td:1516
+  Group, Flags<[CoreOption, CC1Option]>,
+  HelpText<"Use the build environment's platform-specific path separator "
+   "character when expanding the __FILE__ macro">;

I think "build environment" is maybe confusing, and "host" might be the better 
word.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122766

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

[PATCH] D124974: [clang] Include clang config.h in LangStandards.cpp

[Cassie Jones via Phabricator via cfe-commits]

porglezomp added a comment.

Unless anyone has an idea about how to test this, I'm going to commit this 
without adding a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124974

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Julian Lettner via Phabricator via cfe-commits]

yln added inline comments.



Comment at: compiler-rt/lib/asan/asan_poisoning.cpp:262
   *reinterpret_cast(s) = kAsanArrayCookieMagic;
+  // The ARM64 cookie has a second "elementSize" entry so poison it as well
+  #if SANITIZER_ARM64

yln wrote:
> yln wrote:
> > Nitpicking extreme:
> > * I think the code inside `#if` shouldn't have extra indent (because 
> > preprocessor sections don't establish code).  If in doubt, let 
> > `clang-format` do it for you.
> > * Let's move the comment inside the #if, just above before the line of 
> > code.  If you ever read the pre-processed source-code, then the comment 
> > "lives and dies" with the line of code it relates too, i.e, on x86, 
> > currently there would be a comment without the code.
> 
I find this a bit confusing
* x86_64: cookie is 1 word and passed `p` points to it
* arm64: cookie is 2 words and passed `p` points to second half of it

Would it be worth to take the extra care in CodeGen to always pass the 
"beginning of the cookie" to `__asan_poison_cxx_array_cookie()` and then have 
something like that:
```
size_t shadow_cookie_size = SANITIZER_ARM64 ? 2 : 1:
internal_memset(s, kAsanArrayCookieMagic, shadow_cookie_size);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125195

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Julian Lettner via Phabricator via cfe-commits]

yln added inline comments.



Comment at: compiler-rt/lib/asan/asan_poisoning.cpp:262
   *reinterpret_cast(s) = kAsanArrayCookieMagic;
+  // The ARM64 cookie has a second "elementSize" entry so poison it as well
+  #if SANITIZER_ARM64

yln wrote:
> Nitpicking extreme:
> * I think the code inside `#if` shouldn't have extra indent (because 
> preprocessor sections don't establish code).  If in doubt, let `clang-format` 
> do it for you.
> * Let's move the comment inside the #if, just above before the line of code.  
> If you ever read the pre-processed source-code, then the comment "lives and 
> dies" with the line of code it relates too, i.e, on x86, currently there 
> would be a comment without the code.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125195

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Julian Lettner via Phabricator via cfe-commits]

yln added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2453
+CGF.Builder.CreateCall(F, cookie.getRawPointer(CGF));
+  }
 

This code is very similar to what we have in 
`ItaniumCXXABI::InitializeArrayCookie()`.  Can we try to extract a local 
`handleASanArrayCookiePoisoning()` helper?



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2485
+  CGM.CreateRuntimeFunction(FTy, "__asan_load_cxx_array_cookie");
+  return CGF.Builder.CreateCall(F, numElementsPtr.getRawPointer(CGF));
 }

Same here: extract common helper for the ASan stuff to be shared by ARM and 
ItaniumCXXABI.



Comment at: compiler-rt/lib/asan/asan_poisoning.cpp:262-265
+  // The ARM64 cookie has a second "elementSize" entry so poison it as well
+  #if SANITIZER_ARM64
+*(reinterpret_cast(s)-1) = kAsanArrayCookieMagic;
+  #endif

Nitpicking extreme:
* I think the code inside `#if` shouldn't have extra indent (because 
preprocessor sections don't establish code).  If in doubt, let `clang-format` 
do it for you.
* Let's move the comment inside the #if, just above before the line of code.  
If you ever read the pre-processed source-code, then the comment "lives and 
dies" with the line of code it relates too, i.e, on x86, currently there would 
be a comment without the code.



Comment at: compiler-rt/test/asan/TestCases/Posix/new_array_cookie_test.cpp:3
 // RUN: %clangxx_asan -O3 %s -o %t
-// RUN:not %run %t 2>&1  | FileCheck %s
+// RUN:  not %run %t 2>&1  | FileCheck %s
 // RUN: %env_asan_opts=poison_array_cookie=1 not %run %t 2>&1  | FileCheck %s

❤  The boy scouts rule:
> Always leave the campground cleaner than you found it.



Comment at: compiler-rt/test/asan/TestCases/Posix/new_array_cookie_test.cpp:19
   C *buffer = new C[argc];
-  buffer[-2].x = 10;
+  buffer[-1].x = 10;
 // CHECK: AddressSanitizer: heap-buffer-overflow

Can we try to simulate a 1-byte buffer-underflow (and leave the definition of 
`struct C` as-is)?  This would show that ASan still reports the smallest 
possible infraction.



Comment at: 
compiler-rt/test/asan/TestCases/Posix/new_array_cookie_uaf_test.cpp:20
 __attribute__((no_sanitize_address)) void Write42ToCookie(C *c) {
-  long *p = reinterpret_cast(c);
+  size_t *p = reinterpret_cast(c);
   p[-1] = 42;

Can we try to simulate a 1-byte buffer-underflow (and leave the definition of 
struct C as-is)? This would show that ASan still reports the smallest possible 
infraction.



Comment at: 
compiler-rt/test/asan/TestCases/Posix/new_array_cookie_with_new_from_class.cpp:5
+// Here we test that:
+//   1) w/o sanitizer, the array cookie location IS writable
+//   2) w/sanitizer, the array cookie location IS writeable by default

sanitizer -> ASan



Comment at: 
compiler-rt/test/asan/TestCases/Posix/new_array_cookie_with_new_from_class.cpp:12
 //
-// XFAIL: arm
-
-// UNSUPPORTED: ios
+// RUN: %clangxx   %s -o 
%t && %run %t 2>&1 | FileCheck %s --check-prefix=SANITIZE_NOT
+// RUN: %clangxx_asan  %s -o 
%t && %run %t 2>&1 | FileCheck %s --check-prefix=SANITIZE_NOT

Avoid `NOT` in FileCheck prefix names, because `-NOT` is the directive to do a 
"negative match", that is, "make sure this text does not appear".

How about:
`--check-prefix=COOKIE` for the cookie case and just skip `--check-prefix` for 
the "no cookie" (it's the default after all)



Comment at: 
compiler-rt/test/asan/TestCases/Posix/new_array_cookie_with_new_from_class.cpp:35
-  fprintf(stderr, "foo  : %p\n", foo);
-  fprintf(stderr, "alloc: %p\n", Foo::allocated);
-  assert(reinterpret_cast(foo) ==

Why remove this debug output?  It might be useful...



Comment at: 
compiler-rt/test/asan/TestCases/Posix/new_array_cookie_with_new_from_class.cpp:43-47
+// SANITIZE_YES: AddressSanitizer: heap-buffer-overflow
+// SANITIZE_YES: in main 
{{.*}}new_array_cookie_with_new_from_class.cpp:[[@LINE-2]]
+// SANITIZE_YES: is located 0 bytes inside of {{18|26}}-byte region
+  printf("Unsurprisingly, we were able to write to the array cookie\n");
+// SANITIZE_NOT: Unsurprisingly, we were able to write to the array cookie




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125195

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Roy Sundahl via Phabricator via cfe-commits]

rsundahl added reviewers: vitalybuka, kcc.
rsundahl added a comment.

Adding Vitaly Buka and Kostya Serebryany (sanitizer maintainers).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125195

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

[PATCH] D125195: [asan][ARMCXXABI] Added missing asan poison array cookie hooks.

[Dan Liew via Phabricator via cfe-commits]

delcypher added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2443
+  // Handle poisoning the array cookie in asan
+  if (CGM.getLangOpts().Sanitize.has(SanitizerKind::Address) && AS == 0 &&
+  (expr->getOperatorNew()->isReplaceableGlobalAllocationFunction() ||

Why is there a restriction on the address space?



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2478
+  // run-time deal with it: if the shadow is properly poisoned return the
+  // cookie, otherwise return 0 to avoid an infinite loop calling DTORs.
+  // We can't simply ignore this load using nosanitize metadata because

This comment is confusing. What's returning `0`? `__asan_load_cxx_array_cookie` 
doesn't do that and AFAICT neither does this code.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2479
+  // cookie, otherwise return 0 to avoid an infinite loop calling DTORs.
+  // We can't simply ignore this load using nosanitize metadata because
+  // the metadata may be lost.

I also don't understand what you mean by the comment. Could you elaborate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125195

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

[PATCH] D124038: [clang] Prevent folding of non-const compound expr

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:4267
+  bool IsConstant = CLETy.isConstant(Info.Ctx);
+  if (!IsConstant && CLETy->isArrayType()) {
+Info.FFDiag(Conv);

Is the "isArrayType()" check here necessary?


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

https://reviews.llvm.org/D124038

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/test/CodeGenCUDA/noinline.cu:1
+// optimization is needed, otherwise by default all functions have noinline.
+

aaron.ballman wrote:
> I've asked @erichkeane to weigh in on whether there's a better approach here 
> than specifying an optimization level.
You don't need to do this, it looks like all you're trying to do is keep 
'clang' out of `O0` mode.  However, what you do  NOT want is the optimizations 
to run.  The common way to do that is to combine `O1`/`O2`/etc like: `-O2 
-disable-llvm-passes`

This will keep clang in `O2` mode, but will keep the optimizer from running 
anything, which might mess with the test later on.


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

https://reviews.llvm.org/D124866

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a subscriber: erichkeane.
aaron.ballman added a comment.

In D124866#3501181 , @yaxunl wrote:

> In D124866#3500761 , @aaron.ballman 
> wrote:
>
>> Should we do `__forceinline__` at the same time so that there's consistency?
>
> `__forceinline__` does not have the issue as `__noinline__` has since it is 
> not a GCC attribute. The current CUDA/HIP implementation of `__forceinline__` 
> in header files is sufficient. I do not see the benefit of implementing 
> `__forceinline__` as a keyword.

Primarily to reduce user confusion. It's kind of weird for `__noinline__` to be 
a keyword and `__forceinline__` to not be a keyword when they're both defined 
the same way by the CUDA spec. This means you can #undef one of them but not 
the other, that sort of thing.




Comment at: clang/test/CodeGenCUDA/noinline.cu:1
+// optimization is needed, otherwise by default all functions have noinline.
+

I've asked @erichkeane to weigh in on whether there's a better approach here 
than specifying an optimization level.



Comment at: clang/test/SemaCUDA/noinline.cu:8
+__attribute__((noinline)) void fun2() { }
+__attribute__((__noinline__)) void fun3() { }

yaxunl wrote:
> aaron.ballman wrote:
> > I think there should also be a test like:
> > ```
> > [[gnu::__noinline__]] void fun4() {}
> > ```
> > to verify that the double square bracket syntax also correctly handles this 
> > being a keyword now (I expect the test to pass).
> will do
Ah, I just noticed we also have no tests for the behavior of the keyword in the 
presence of the macro being defined. e.g.,
```
#define __noinline__ __attribute__((__noinline__))
__noinline__ void fun5() {}
```


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

https://reviews.llvm.org/D124866

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

[PATCH] D122766: [clang] Add the flag -ffile-reproducible

[Alan Zhao via Phabricator via cfe-commits]

ayzhao updated this revision to Diff 428121.
ayzhao marked 4 inline comments as done.
ayzhao added a comment.

code review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122766

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/AST/Expr.cpp
  clang/lib/Basic/LangOptions.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/test/CodeGenCXX/builtin-source-location.cpp
  clang/test/Preprocessor/file_test.c
  clang/test/Preprocessor/file_test_windows.c

Index: clang/test/Preprocessor/file_test_windows.c
===
--- clang/test/Preprocessor/file_test_windows.c
+++ clang/test/Preprocessor/file_test_windows.c
@@ -1,9 +1,25 @@
 // REQUIRES: system-windows
-// RUN: %clang -E -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
-// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
-// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
-// RUN: %clang -E -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE
-// RUN: %clang -E -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -fno-file-reproducible -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE
+// RUN: %clang -E -fno-file-reproducible -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// RUN: %clang -E -ffile-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s --check-prefix CHECK-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH\empty -c -o - %s | FileCheck %s --check-prefix CHECK-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p=A:\UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p/iNPUTS\=A:\UNLIKELY_PATH_INC\ -fmacro-prefix-map=%p/=A:\UNLIKELY_PATH_BASE\ -c -o - %s | FileCheck %s -check-prefix CHECK-CASE-REPRODUCIBLE
+// RUN: %clang -E -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE-REPRODUCIBLE
+
+// RUN: %clang -E -target x86_64-pc-linux-gnu -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -target x86_64-pc-linux-gnu -ffile-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// Clang defaults to forward slashes for the non-prefix portion of the path even if the build environment is Windows.
+// RUN: %clang -E -fno-file-reproducible -target x86_64-pc-linux-gnu -fmacro-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -fno-file-reproducible -target x86_64-pc-linux-gnu -ffile-prefix-map=%p\= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+// RUN: %clang -E -ffile-reproducible -target x86_64-pc-win32 -c -o - %s | FileCheck %s --check-prefix CHECK-WINDOWS-FULL
+// RUN: %clang -E -ffile-reproducible -target x86_64-pc-linux-gnu -c -o - %s | FileCheck %s --check-prefix CHECK-LINUX-FULL
 
 filename: __FILE__
 #include "Inputs/include-file-test/file_test.h"
@@ -27,3 +43,34 @@
 // CHECK-REMOVE: filename: "Inputs/include-file-test/file_test.h"
 // CHECK-REMOVE: basefile: "file_test_windows.c"
 // CHECK-REMOVE-NOT: filename:
+
+// CHECK-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH\\empty\\file_test_windows.c"
+// CHECK-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH\\empty\\Inputs\\include-file-test\\file_test.h"
+// CHECK-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH\\empty\\file_test_windows.c"
+// CHECK-REPRODUCIBLE-NOT: filename:
+
+// CHECK-EVIL-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH=empty\\file_test_windows.c"
+// CHECK-EVIL-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH=empty\\Inputs\\include-file-test\\file_test.h"
+// CHECK-EVIL-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH=empty\\file_test_windows.c"
+// CHECK-EVIL-REPRODUCIBLE-NOT: filename:
+
+// CHECK-CASE-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH_BASE\\file_test_windows.c"
+// CHECK-CASE-REPRODUCIBLE: filename: "A:\\UNLIKELY_PATH_INC\\include-file-test\\file_test.h"
+// CHECK-CASE-REPRODUCIBLE: basefile: "A:\\UNLIKELY_PATH_BASE\\file_test_windows.c"
+// CHECK-CASE-REPRODUCIBLE-NOT: filename:
+
+// CHECK-REMOVE-REPR

[PATCH] D125078: Implement a feature to show line numbers in diagnostics

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

In D125078#3501061 , @cjdb wrote:

> I'm in favour of this, but @rsmith warned me a little while ago that we 
> mightn't be able to have stuff like this on by default because scripts 
> probably depend on specific compiler output. Hyrum's Law 
>  strikes again :(
>
> (I personally think we should have it on by default and give a way to opt 
> out, rather than opt in.)

I believe even more tools depend on gcc and gcc devs were able to turn it on by 
default, so kinda bad excuse, especially with opt out flag.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125078

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

[PATCH] D124776: [SPIR-V] Allow setting SPIR-V version via target triple

[Thorsten via Phabricator via cfe-commits]

tschuett added inline comments.



Comment at: llvm/docs/SPIRVUsage.rst:14
+
+The SPIR-V target provides code generation for the SPIR-V binary format 
desribed
+in  `the official SPIR-V specification 
`_.

described


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

https://reviews.llvm.org/D124776

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

[PATCH] D124866: [CUDA][HIP] support __noinline__ as keyword

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D124866#3500761 , @aaron.ballman 
wrote:

> Should we do `__forceinline__` at the same time so that there's consistency?

`__forceinline__` does not have the issue as `__noinline__` has since it is not 
a GCC attribute. The current CUDA/HIP implementation of `__forceinline__` in 
header files is sufficient. I do not see the benefit of implementing 
`__forceinline__` as a keyword.


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

https://reviews.llvm.org/D124866

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Nick Desaulniers via Phabricator via cfe-commits]

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

It looks like clang still produces meaningful diagnostics from 
`-Wuninitialized` and `-Wsometimes-uninitialized` even with 
`-ftrivial-auto-var-init=zero`.  Same for 
`[clang-diagnostic-sometimes-uninitialized]`, 
`[clang-analyzer-core.uninitialized.UndefReturn]`,  and 
`[clang-diagnostic-uninitialized]`.

Looks like GCC now even does a better job with `-Wuninitialized` on

  void init (int *x) {}
  
  int x (int z) {
  int y;
  init(&y);
  return y;
  }




Comment at: clang/test/Driver/clang_f_opts.c:573
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero %s 2>&1 | FileCheck 
-check-prefix=CHECK-TRIVIAL-ZERO %s
+// RUN: %clang -### -S -ftrivial-auto-var-init=zero 
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIVIAL-ZERO-UNUSED %s
 // CHECK-TRIVIAL-UNINIT-NOT: hasn't been enabled

consider breaking long run lines into 2 with `\`.  Example:

```
// RUN: %clang -### ... -S \
// RUN:   -ftrivial-auto-var-init=zero ...
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

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

[PATCH] D125142: [clang][auto-init] Remove -enable flag for "zero" mode

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Also, you should definitely add some release notes for this change.




Comment at: clang/include/clang/Driver/Options.td:2700-2701
   MarshallingInfoEnum, "Uninitialized">;
 def enable_trivial_var_init_zero : Flag<["-"], 
"enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang">,
-  Flags<[CC1Option, CoreOption, NoArgumentUnused]>,
-  HelpText<"Trivial automatic variable initialization to zero is only here for 
benchmarks, it'll eventually be removed, and I'm OK with that because I'm only 
using it to benchmark">;
+  Flags<[CC1Option, CoreOption, Ignored]>;
 def ftrivial_auto_var_init_stop_after : Joined<["-"], 
"ftrivial-auto-var-init-stop-after=">, Group,

We might as well comment on when we expect to remove it; I took a stab in the 
dark and figured two releases of deprecation should be enough for most folks 
(so it's deprecated in Clang 15 and 16, then removed in Clang 17).

I don't think we want this option to be ignored though; I think we still want 
to accept the option, but then be loud about it being deprecated when 
translating it to `-ftrivial-auto-var-init=zero`. You can emit 
`diag::warn_drv_deprecated_arg` for the diagnostic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125142

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

[PATCH] D124776: [SPIR-V] Allow setting SPIR-V version via target triple

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 428118.
Anastasia added a comment.

- Added v1.5.
- Changed wording in documentation.


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

https://reviews.llvm.org/D124776

Files:
  llvm/docs/SPIRVUsage.rst
  llvm/docs/UserGuides.rst
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -243,11 +243,85 @@
 
   T = Triple("spirv32-unknown-unknown");
   EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.0-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v10, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.1-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v11, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.2-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v12, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.3-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v13, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.4-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v14, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv32v1.5-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v15, T.getSubArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
 
   T = Triple("spirv64-unknown-unknown");
   EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::NoSubArch, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.0-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v10, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.1-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v11, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.2-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v12, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.3-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v13, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.4-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v14, T.getSubArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64v1.5-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::SPIRVSubArch_v15, T.getSubArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
 
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -495,8 +495,10 @@
 .Case("hsail64", Triple::hsail64)
 .Case("spir", Triple::spir)
 .Case("spir64", Triple::spir64)
-.Case("spirv32", Triple::spirv32)
-.Case("spirv64", Triple::spirv64)
+.Cases("spirv32", "spirv32v1.0", "spirv32v1.1", "spirv32v1.2",
+   "spirv32v1.3", "spirv32v1.4", "spirv32v1.5", Triple::spirv32)
+.Cases("spirv64", "spirv64v1.0", "spirv64v1.1", "spirv64v1.2",
+   "spirv64v1.3", "spirv64v1.4", "spirv64v1.5", Triple::spirv64)
 .StartsWith("kalimba", Triple::kalimba)
 .Case("lanai", Triple::lanai)
 .Case("renderscript32", Triple::renderscript32)
@@ -654,6 +656,16 @@
   if (SubArchName == "arm64e")
 return Triple::AArch64SubArch_arm64e;
 
+  if (SubArchName.startswith("spirv"))
+return StringSwitch(SubArchName)
+.EndsWith("v1.0", Triple::SPI

[PATCH] D125243: [OpenCL] Make -cl-ext a driver option

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia created this revision.
Anastasia added a reviewer: svenvh.
Herald added subscribers: Naghasan, ebevhan, yaxunl.
Herald added a project: All.
Anastasia requested review of this revision.
Herald added a subscriber: MaskRay.

For generic targets such as SPIR-V clang sets all OpenCL extensions/features as 
supported by default. However targets are unlikely to support all 
extensions/features which creates a problem when such generic SPIR-V binary is 
compiled for a specific target later on.

For SPIR-V we will likely provide control of extensions via vendor components 
in the target triple: 
https://discourse.llvm.org/t/setting-version-environment-and-extensions-for-spir-v-target,
 however this doesn't eliminate the need of finer-grained control of extensions 
for example to support some specific or emerging target architectures.

Therefore this patch exposes `-cl-ext` flag for finer-grained control of 
extensions and features being targeted in the OpenCL kernels to improve error 
reporting and control of features generated in generic binaries like SPIR-V.


https://reviews.llvm.org/D125243

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/opencl.cl

Index: clang/test/Driver/opencl.cl
===
--- clang/test/Driver/opencl.cl
+++ clang/test/Driver/opencl.cl
@@ -21,6 +21,7 @@
 // RUN: not %clang -cl-std=invalid -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID %s
 // RUN: %clang -S -### -target spir-unknown-unknown %s 2>&1 | FileCheck --check-prefix=CHECK-W-SPIR-COMPAT %s
 // RUN: %clang -S -### -target amdgcn-amd-amdhsa-opencl %s 2>&1 | FileCheck --check-prefix=CHECK-NO-W-SPIR-COMPAT %s
+// RUN: %clang -S -### -cl-ext="+test_ext" %s 2>&1 | FileCheck --check-prefix=CHECK-EXT %s
 
 // CHECK-CL: "-cc1" {{.*}} "-cl-std=CL"
 // CHECK-CL10: "-cc1" {{.*}} "-cl-std=CL1.0"
@@ -50,4 +51,6 @@
 // CHECK-W-SPIR-COMPAT: "-Wspir-compat"
 // CHECK-NO-W-SPIR-COMPAT-NOT: "-Wspir-compat"
 
+// CHECK-EXT: "-cc1" {{.*}} "-cl-ext=+test_ext"
+
 kernel void func(void);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3453,6 +3453,9 @@
   if (Arg *A = Args.getLastArg(options::OPT_cl_std_EQ)) {
 std::string CLStdStr = std::string("-cl-std=") + A->getValue();
 CmdArgs.push_back(Args.MakeArgString(CLStdStr));
+  } else if (Arg *A = Args.getLastArg(options::OPT_cl_ext_EQ)) {
+std::string CLExtStr = std::string("-cl-ext=") + A->getValue();
+CmdArgs.push_back(Args.MakeArgString(CLExtStr));
   }
 
   for (const auto &Arg : ForwardedArguments)
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -844,6 +844,7 @@
 def b : JoinedOrSeparate<["-"], "b">, Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass -b  to the linker on AIX (only).">, MetaVarName<"">,
   Group;
+// OpenCL-only Options
 def cl_opt_disable : Flag<["-"], "cl-opt-disable">, Group, Flags<[CC1Option]>,
   HelpText<"OpenCL only. This option disables all optimizations. By default optimizations are enabled.">;
 def cl_strict_aliasing : Flag<["-"], "cl-strict-aliasing">, Group, Flags<[CC1Option]>,
@@ -883,6 +884,11 @@
   MarshallingInfoFlag>;
 def cl_no_stdinc : Flag<["-"], "cl-no-stdinc">, Group,
   HelpText<"OpenCL only. Disables all standard includes containing non-native compiler types and functions.">;
+def cl_ext_EQ : CommaJoined<["-"], "cl-ext=">, Group, Flags<[CC1Option]>,
+  HelpText<"OpenCL only. Enable or disable OpenCL extensions/optional features. The argument is a comma-separated "
+   "sequence of one or more extension names, each prefixed by '+' or '-'.">,
+  MarshallingInfoStringVector>;
+
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
@@ -6106,15 +6112,6 @@
 
 } // let Flags = [CC1Option, NoDriverOption]
 
-//===--===//
-// OpenCL Options
-//===--===//
-
-def cl_ext_EQ : CommaJoined<["-"], "cl-ext=">,
-  HelpText<"OpenCL only. Enable or disable OpenCL extensions. The argument is a comma-separated sequence of one or more extension names, each prefixed by '+' or '-'.">,
-  Flags<[CC1Option, NoDriverOption]>,
-  MarshallingInfoStringVector>;
-
 //===--===//
 // CUDA Options
 //===--===//
Index: clang/docs/UsersManual.rst