[PATCH] D132486: SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

2022-08-24 Thread Tobias Hieta via Phabricator via cfe-commits
thieta updated this revision to Diff 455088.
thieta added a comment.

Fixed variable name


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132486

Files:
  clang/CMakeLists.txt
  clang/docs/ReleaseNotes.rst
  clang/tools/libclang/CMakeLists.txt
  clang/tools/libclang/libclang.exports
  clang/tools/libclang/libclang.map
  clang/tools/libclang/linker-script-to-export-list.py

Index: clang/tools/libclang/linker-script-to-export-list.py
===
--- /dev/null
+++ clang/tools/libclang/linker-script-to-export-list.py
@@ -0,0 +1,11 @@
+import re
+import os
+import sys
+
+input_file = open(sys.argv[1])
+output_file = open(sys.argv[2], 'w')
+
+for line in input_file:
+m = re.search('^\s+(clang_[^;]+)', line)
+if m:
+output_file.write(m.group(1) + "\n")
Index: clang/tools/libclang/libclang.map
===
--- /dev/null
+++ clang/tools/libclang/libclang.map
@@ -0,0 +1,413 @@
+# If you add a symbol to this file, make sure to add it with the correct
+# version.  For example, if the LLVM main branch is LLVM 14.0.0, add new
+# symbols with the version LLVM_14.
+# On platforms where versions scripts are not used, this file will be used to
+# generate a list of exports for libclang.so
+
+LLVM_13 {
+  global:
+clang_BlockCommandComment_getArgText;
+clang_BlockCommandComment_getCommandName;
+clang_BlockCommandComment_getNumArgs;
+clang_BlockCommandComment_getParagraph;
+clang_CXCursorSet_contains;
+clang_CXCursorSet_insert;
+clang_CXIndex_getGlobalOptions;
+clang_CXIndex_setGlobalOptions;
+clang_CXIndex_setInvocationEmissionPathOption;
+clang_CXRewriter_create;
+clang_CXRewriter_dispose;
+clang_CXRewriter_insertTextBefore;
+clang_CXRewriter_overwriteChangedFiles;
+clang_CXRewriter_removeText;
+clang_CXRewriter_replaceText;
+clang_CXRewriter_writeMainFileToStdOut;
+clang_CXXConstructor_isConvertingConstructor;
+clang_CXXConstructor_isCopyConstructor;
+clang_CXXConstructor_isDefaultConstructor;
+clang_CXXConstructor_isMoveConstructor;
+clang_CXXField_isMutable;
+clang_CXXMethod_isConst;
+clang_CXXMethod_isDefaulted;
+clang_CXXMethod_isPureVirtual;
+clang_CXXMethod_isStatic;
+clang_CXXMethod_isVirtual;
+clang_CXXRecord_isAbstract;
+clang_Comment_getChild;
+clang_Comment_getKind;
+clang_Comment_getNumChildren;
+clang_Comment_isWhitespace;
+clang_CompilationDatabase_dispose;
+clang_CompilationDatabase_fromDirectory;
+clang_CompilationDatabase_getAllCompileCommands;
+clang_CompilationDatabase_getCompileCommands;
+clang_CompileCommand_getArg;
+clang_CompileCommand_getDirectory;
+clang_CompileCommand_getFilename;
+clang_CompileCommand_getMappedSourceContent;
+clang_CompileCommand_getMappedSourcePath;
+clang_CompileCommand_getNumArgs;
+clang_CompileCommand_getNumMappedSources;
+clang_CompileCommands_dispose;
+clang_CompileCommands_getCommand;
+clang_CompileCommands_getSize;
+clang_Cursor_Evaluate;
+clang_Cursor_getArgument;
+clang_Cursor_getBriefCommentText;
+clang_Cursor_getCXXManglings;
+clang_Cursor_getCommentRange;
+clang_Cursor_getMangling;
+clang_Cursor_getModule;
+clang_Cursor_getNumArguments;
+clang_Cursor_getNumTemplateArguments;
+clang_Cursor_getObjCDeclQualifiers;
+clang_Cursor_getObjCManglings;
+clang_Cursor_getObjCPropertyAttributes;
+clang_Cursor_getObjCPropertyGetterName;
+clang_Cursor_getObjCPropertySetterName;
+clang_Cursor_getObjCSelectorIndex;
+clang_Cursor_getOffsetOfField;
+clang_Cursor_getParsedComment;
+clang_Cursor_getRawCommentText;
+clang_Cursor_getReceiverType;
+clang_Cursor_getSpellingNameRange;
+clang_Cursor_getStorageClass;
+clang_Cursor_getTemplateArgumentKind;
+clang_Cursor_getTemplateArgumentType;
+clang_Cursor_getTemplateArgumentUnsignedValue;
+clang_Cursor_getTemplateArgumentValue;
+clang_Cursor_getTranslationUnit;
+clang_Cursor_getVarDeclInitializer;
+clang_Cursor_hasAttrs;
+clang_Cursor_hasVarDeclExternalStorage;
+clang_Cursor_hasVarDeclGlobalStorage;
+clang_Cursor_isAnonymous;
+clang_Cursor_isAnonymousRecordDecl;
+clang_Cursor_isBitField;
+clang_Cursor_isDynamicCall;
+clang_Cursor_isExternalSymbol;
+clang_Cursor_isFunctionInlined;
+clang_Cursor_isInlineNamespace;
+clang_Cursor_isMacroBuiltin;
+clang_Cursor_isMacroFunctionLike;
+clang_Cursor_isNull;
+clang_Cursor_isObjCOptional;
+clang_Cursor_isVariadic;
+clang_EnumDecl_isScoped;
+clang_EvalResult_dispose;
+clang_EvalResult_getAsDouble;
+clang_EvalResult_getAsInt;
+clang_EvalResult_getAsLongLong;
+clang_EvalResult_getAsStr;
+clang_EvalResult_getAsUnsigned;
+clang

[PATCH] D132531: [AArch64] Reserve more physical registers

2022-08-24 Thread Guozhi Wei via Phabricator via cfe-commits
Carrot added a comment.

A reserved physical register doesn't mean it can't be used by compiler/linker, 
it just means it can't be used by register allocator, see the comments in 
TargetRegisterInfo::getReservedRegs(). The most common example is the stack 
pointer. So when we reserve X8, X16, X17 and X19, it means we can't allocate 
them to virtual registers, compiler/linker can still use X8 to pass return 
address, and use X16 and X17 in a veneer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132531

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


[PATCH] D132444: [clang] Allow using -rtlib=platform to switching to the default rtlib on all targets

2022-08-24 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.
This revision is now accepted and ready to land.

LGTM

In D132444#3743051 , @mstorsjo wrote:

> In D132444#3743020 , @thakis wrote:
>
>> Makes sense to me. Maybe @hans has an opinion too.
>>
>> WDYT about accepting the same string for -fuse-ld= to mean "platform linker" 
>> there as well?
>
> Sounds reasonable to me - requiring the user to set an option to the empty 
> string is kinda awkward.

We currently support `-fuse-ld=` and `-fuse-ld=ld`, see 
https://github.com/llvm/llvm-project/blob/e29f9f7572d75c25cf06b080dce6bda9ebcf5008/clang/lib/Driver/ToolChain.cpp#L644.
 I think that `-fuse-ld=platform` would be less confusing (to distinguish from 
`ld` as the linker name) and it's also more consistent with other flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132444

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


[clang] 3f20dcb - [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Pavel Samolysov via cfe-commits

Author: Pavel Samolysov
Date: 2022-08-24T10:36:12+03:00
New Revision: 3f20dcbf708cb23f79c4866d8285a8ae7bd885de

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

LOG: [Pipelines] Introduce DAE after ArgumentPromotion

The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.

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

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Passes/PassBuilderPipelines.cpp
llvm/test/Other/new-pm-defaults.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
llvm/test/Transforms/InstCombine/unused-nonnull.ll
llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index 463fc522c6a28..64ac49420cbdc 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -34,7 +34,6 @@
 ; CHECK-O: Running pass: CalledValuePropagationPass
 ; CHECK-O: Running pass: GlobalOptPass
 ; CHECK-O: Running pass: PromotePass
-; CHECK-O: Running pass: DeadArgumentEliminationPass
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main
 ; CHECK-O: Running pass: InlinerPass on (main)
@@ -74,6 +73,7 @@
 ; CHECK-O: Running pass: LCSSAPass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
+; CHECK-O: Running pass: DeadArgumentEliminationPass
 ; CHECK-O: Running pass: GlobalOptPass
 ; CHECK-O: Running pass: GlobalDCEPass
 ; CHECK-O: Running pass: EliminateAvailableExternallyPass

diff  --git a/llvm/lib/Passes/PassBuilderPipelines.cpp 
b/llvm/lib/Passes/PassBuilderPipelines.cpp
index bd07638b37617..2587c8ce900b9 100644
--- a/llvm/lib/Passes/PassBuilderPipelines.cpp
+++ b/llvm/lib/Passes/PassBuilderPipelines.cpp
@@ -639,7 +639,7 @@ void PassBuilder::addPGOInstrPasses(ModulePassManager &MPM,
 
 FunctionPassManager FPM;
 FPM.addPass(SROAPass());
-FPM.addPass(EarlyCSEPass());// Catch trivial redundancies.
+FPM.addPass(EarlyCSEPass()); // Catch trivial redundancies.
 FPM.addPass(SimplifyCFGPass(SimplifyCFGOptions().convertSwitchRangeToICmp(
 true)));// Merge & remove basic blocks.
 FPM.addPass(InstCombinePass()); // Combine silly sequences.
@@ -734,10 +734,9 @@ PassBuilder::buildInlinerPipeline(OptimizationLevel Level,
   if (PGOOpt)
 IP.EnableDeferral = EnablePGOInlineDeferral;
 
-  ModuleInlinerWrapperPass MIWP(
-  IP, PerformMandatoryInliningsFirst,
-  InlineContext{Phase, InlinePass::CGSCCInliner},
-  UseInlineAdvisor, MaxDevirtIterations);
+  ModuleInlinerWrapperPass MIWP(IP, PerformMandatoryInliningsFirst,
+InlineContext{Phase, InlinePass::CGSCCInliner},
+UseInlineAdvisor, MaxDevirtIterations);
 
   // Require the GlobalsAA analysis for the module so we can query it within
   // the CGSCC pipeline.
@@ -961,10 +960,6 @@ 
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
   // constants.
   MPM.addPass(createModuleToFunctionPassAdaptor(PromotePass()));
 
-  // Remove any dead arguments exposed by cleanups and constant folding
-  // globals.
-  MPM.addPass(DeadArgumentEliminationPass());
-
   // Create a small function pass pipeline to cleanup after all the global
   // optimizations.
   FunctionPassManager GlobalCleanupPM;
@@ -999,6 +994,10 @@ 
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
   else
 MPM.addPass(buildInlinerPipeline(Level, Phase));
 
+  // Remove any dead arguments exposed by cleanups, constant folding globals,
+  // and argument promotion.
+  MPM.addPass(DeadArgumentEliminationPass());
+
   MPM.addPass(CoroCleanupPass());
 
   if (EnableMemProfiler && Phase != ThinOrFullLTOPhase::ThinLTOPreLink) {
@@ -1596,9 +1595,6 @@ PassBuilder::buildLTODefaultPipeline(OptimizationLevel 
Level,
   // keep one copy of each constant.
   MPM.addPass(ConstantMergePass());
 
-  // Remove unused arguments fro

[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Pavel Samolysov 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 rG3f20dcbf708c: [Pipelines] Introduce DAE after 
ArgumentPromotion (authored by psamolysov).

Changed prior to commit:
  https://reviews.llvm.org/D128830?vs=443860&id=455093#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Passes/PassBuilderPipelines.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
  llvm/test/Transforms/InstCombine/unused-nonnull.ll
  llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll

Index: llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll
===
--- llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll
+++ llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll
@@ -9,7 +9,7 @@
 
 define internal void @f(%struct.ss* byval(%struct.ss) align 8 %b, i32* byval(i32) align 4 %X) noinline nounwind  {
 ; CHECK-LABEL: define {{[^@]+}}@f
-; CHECK-SAME: (i32 [[B_0:%.*]], i32 [[X:%.*]]){{[^#]*}} #[[ATTR0:[0-9]+]] {
+; CHECK-SAME: (i32 [[B_0:%.*]]){{[^#]*}} #[[ATTR0:[0-9]+]] {
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[TEMP:%.*]] = add i32 [[B_0]], 1
 ; CHECK-NEXT:store i32 [[TEMP]], i32* [[DUMMY]], align 4
@@ -28,8 +28,7 @@
 ; CHECK-LABEL: define {{[^@]+}}@test
 ; CHECK-SAME: (i32* {{[^%]*}} [[X:%.*]]){{[^#]*}} #[[ATTR1:[0-9]+]] {
 ; CHECK-NEXT:  entry:
-; CHECK-NEXT:[[X_VAL:%.*]] = load i32, i32* [[X]], align 4
-; CHECK-NEXT:tail call {{.*}}void @f(i32 1, i32 [[X_VAL]])
+; CHECK-NEXT:tail call {{.*}}void @f(i32 1)
 ; CHECK-NEXT:ret i32 0
 ;
 entry:
Index: llvm/test/Transforms/InstCombine/unused-nonnull.ll
===
--- llvm/test/Transforms/InstCombine/unused-nonnull.ll
+++ llvm/test/Transforms/InstCombine/unused-nonnull.ll
@@ -9,7 +9,7 @@
 
 define i32 @main(i32 %argc, i8** %argv) #0 {
 ; CHECK-LABEL: define {{[^@]+}}@main
-; CHECK-SAME: (i32 [[ARGC:%.*]], i8** nocapture readnone [[ARGV:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
+; CHECK-SAME: (i32 [[ARGC:%.*]], i8** nocapture readonly [[ARGV:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[TMP0:%.*]] = icmp slt i32 [[ARGC]], 2
 ; CHECK-NEXT:[[SPEC_SELECT:%.*]] = select i1 [[TMP0]], i32 0, i32 [[ARGC]]
@@ -37,7 +37,8 @@
 
 define i32 @compute(i8* noundef nonnull %ptr, i32 %x) #1 {
 ; CHECK-LABEL: define {{[^@]+}}@compute
-; CHECK-SAME: (i8* nocapture nonnull readnone [[PTR:%.*]], i32 returned [[X:%.*]]) local_unnamed_addr #[[ATTR1:[0-9]+]] {
+; CHECK-SAME: (i8* nocapture noundef nonnull readnone [[PTR:%.*]], i32 returned [[X:%.*]])
+; CHECK-SAME:  local_unnamed_addr #[[ATTR1:[0-9]+]] {
 ; CHECK-NEXT:ret i32 [[X]]
 ;
   ret i32 %x
Index: llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
@@ -58,7 +58,6 @@
 ; CHECK-O-NEXT: Running pass: CalledValuePropagationPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: PromotePass
-; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis on foo
 ; These next two can appear in any order since they are accessed as parameters
@@ -166,6 +165,7 @@
 ; CHECK-O-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: InlineAdvisorAnalysis
+; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: CoroCleanupPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: AnnotationRemarksPass on foo
Index: llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
@@ -48,7 +48,6 @@
 ; CHECK-O-NEXT: Running pass: CalledValuePropagationPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: PromotePass
-; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O-NEXT: Running an

[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Pavel Samolysov via Phabricator via cfe-commits
psamolysov added a comment.

@aeubanks Thank you very much for the benchmark results and review. I've landed 
the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D113107: Support of expression granularity for _Float16.

2022-08-24 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added a comment.

In D113107#3744782 , @rjmccall wrote:

> In D113107#3744505 , @pengfei wrote:
>
>>> I'm not sure what optimization you mean. Because the ABI returns 16-bit and 
>>> 32-bit FP values differently, there really isn't a way that we can return a 
>>> value without going through a truncation/extension cycle.
>>
>> I explained it to Zahira offline. I forgot we have different expectation for 
>> the patch, thus we were talking different optimization to each other. I 
>> expected each backend has the ability to lower half operations. So I 
>> emphasized not to do the promotion or eliminate unnecessary promotion at the 
>> begining. While I see your point, we can only eliminate or combine 
>> unpromotion to the following promotion, so that we don't leave half 
>> operations to backends.
>>
>>> There's potential to eliminate those with IPO, but we should definitely 
>>> leave that for a different patch, for two reasons:
>>
>> I agree with you, IPO is the only chance to do elimination.
>>
>>> Somehow we've taken a huge step back on unpromotion, and I'm worried you're 
>>> now doing the exact thing I didn't want us doing and forcing all the 
>>> downstream clients to handle the possibility of a promoted result.
>>
>> However, I am still not persuaded we need to consider the backends not 
>> supporting half operations (if I understand your downstream clients 
>> correctly).
>
> Oh, no, LLVM is not what I mean by downstream clients.  That comment was 
> meant for Zahira and is about a purely internal matter to IRGen; the 
> downstream clients I meant are just the call sites within IRGen of e.g. 
> EmitScalarExpr.  We've been having some kind of persistent disconnect 
> throughout this review about IRGen's postconditions on expression emission.  
> Unfortunately, IRGen doesn't have good assertions in place for its 
> postconditions, so breaking the postconditions can silently turn into 
> miscompiles instead of assertion failures.  For example, Clang's IR emission 
> for `return` statements has some well-meaning code that tries to handle minor 
> type mismatches between the ABI-dictated IR return type and the IR type that 
> expression-emission produces by coercing the value through memory.  
> Unfortunately, that code is also triggered when expression emission just has 
> a bug and returns the wrong type, and so you can see a bunch of code in the 
> tests that's doing stuff like storing a pair of `float`s into memory and then 
> loading a pair of `half`s out, which is obviously incorrect.  None of this 
> has anything to do with our conversation about avoiding fptrunc/fpext pairs 
> over return boundaries.

Thanks @rjmccall for the explanation. I understand it a bit more now. So my 
proposal is still valid, though it doesn't solve the problem you described.
I don't know any details of the front-end, but I can see the problem in the 
test case. Assumably we don't do fpext then fptrunc for unary and binary 
expression, the problem still exists in, e.g.,

  _Float16 foo(_Float16 a, _Float16 b, _Float16 c) {
return a + b + c;
  }

Can we always split it into two expressions, e.g.,

  _Float16 t = a + b + c;
  return t;

I think they are constant equivalent in C and C++ semantics. And it may solve 
the returning problem you descributes.


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

https://reviews.llvm.org/D113107

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


[PATCH] D131686: [clang-tidy] Add test to cert-dcl58-cpp (NFC).

2022-08-24 Thread Nathan James via Phabricator via cfe-commits
njames93 accepted this revision.
njames93 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/D131686/new/

https://reviews.llvm.org/D131686

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


[PATCH] D132531: [AArch64] Reserve more physical registers

2022-08-24 Thread Kristof Beyls via Phabricator via cfe-commits
kristof.beyls added a comment.

See https://reviews.llvm.org/D56305 and https://reviews.llvm.org/D48580 for 
previous related discussions.
I think it would be helpful to understand the use case for being able to 
reserve x8, x16, x17 and x19 better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132531

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


[clang] d3b14cc - Revert "[Clang] Avoid using unwind library in the MSVC environment"

2022-08-24 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2022-08-24T08:24:18Z
New Revision: d3b14ccafb198ac02109dae16e966ba70a6058b7

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

LOG: Revert "[Clang] Avoid using unwind library in the MSVC environment"

This reverts commit eca29d4a37b8d1c93fe99be6289a60bb11cf789d since
the test fails in the per-target-runtime-dir layout.

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/compiler-rt-unwind.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index f270a5763806b..d5b437ceed63c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1529,7 +1529,7 @@ static void AddUnwindLibrary(const ToolChain &TC, const 
Driver &D,
   // Targets that don't use unwind libraries.
   if ((TC.getTriple().isAndroid() && UNW == ToolChain::UNW_Libgcc) ||
   TC.getTriple().isOSIAMCU() || TC.getTriple().isOSBinFormatWasm() ||
-  TC.getTriple().isWindowsMSVCEnvironment() || UNW == ToolChain::UNW_None)
+  UNW == ToolChain::UNW_None)
 return;
 
   LibGccType LGT = getLibGccType(TC, D, Args);

diff  --git a/clang/test/Driver/compiler-rt-unwind.c 
b/clang/test/Driver/compiler-rt-unwind.c
index 88e2705029032..c5f63fba065e0 100644
--- a/clang/test/Driver/compiler-rt-unwind.c
+++ b/clang/test/Driver/compiler-rt-unwind.c
@@ -88,12 +88,6 @@
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires 
--unwindlib=libgcc"
 //
 // RUN: %clang -### %s 2>&1 \
-// RUN: --target=x86_64-pc-windows-msvc -rtlib=compiler-rt 
--unwindlib=libunwind \
-// RUN:   | FileCheck 
--check-prefix=MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT %s
-// MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: 
"{{.*}}clang_rt.builtins-x86_64.lib"
-// MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT-NOT: "{{.*}}unwind.lib"
-//
-// RUN: %clang -### %s 2>&1 \
 // RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
 // RUN: -shared-libgcc \
 // RUN: --gcc-toolchain="" \



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


[PATCH] D132538: [AArch64] Filter out invalid code model in frontend.

2022-08-24 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai created this revision.
HsiangKai added reviewers: aemerson, paquette.
Herald added subscribers: StephenFan, kristof.beyls.
Herald added a project: All.
HsiangKai requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

AArch64 only supports tiny, small, and large code model. Show error
messages when users specify other code model.

Fix https://github.com/llvm/llvm-project/issues/53402


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132538

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/mcmodel.c


Index: clang/test/Driver/mcmodel.c
===
--- clang/test/Driver/mcmodel.c
+++ clang/test/Driver/mcmodel.c
@@ -6,6 +6,8 @@
 // RUN: %clang -target powerpc-unknown-aix -### -S -mcmodel=medium %s 2> %t.log
 // RUN: FileCheck --check-prefix=AIX-MCMEDIUM-OVERRIDE %s < %t.log
 // RUN: not %clang -c -mcmodel=lager %s 2>&1 | FileCheck 
--check-prefix=INVALID %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=medium %s 2>&1 | FileCheck 
--check-prefix=AARCH64-MEDIUM %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=kernel %s 2>&1 | FileCheck 
--check-prefix=AARCH64-KERNEL %s
 
 // TINY: "-mcmodel=tiny"
 // SMALL: "-mcmodel=small"
@@ -15,3 +17,6 @@
 // AIX-MCMEDIUM-OVERRIDE: "-mcmodel=large"
 
 // INVALID: error: invalid argument 'lager' to -mcmodel=
+
+// AARCH64-MEDIUM: error: invalid argument 'medium' to -mcmodel=
+// AARCH64-KERNEL: error: invalid argument 'kernel' to -mcmodel=
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5421,6 +5421,9 @@
 CM == "tiny") {
   if (Triple.isOSAIX() && CM == "medium")
 CmdArgs.push_back("-mcmodel=large");
+  else if (Triple.isAArch64() && (CM == "kernel" || CM == "medium"))
+D.Diag(diag::err_drv_invalid_argument_to_option)
+<< CM << A->getOption().getName();
   else
 A->render(Args, CmdArgs);
 } else {


Index: clang/test/Driver/mcmodel.c
===
--- clang/test/Driver/mcmodel.c
+++ clang/test/Driver/mcmodel.c
@@ -6,6 +6,8 @@
 // RUN: %clang -target powerpc-unknown-aix -### -S -mcmodel=medium %s 2> %t.log
 // RUN: FileCheck --check-prefix=AIX-MCMEDIUM-OVERRIDE %s < %t.log
 // RUN: not %clang -c -mcmodel=lager %s 2>&1 | FileCheck --check-prefix=INVALID %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=medium %s 2>&1 | FileCheck --check-prefix=AARCH64-MEDIUM %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=kernel %s 2>&1 | FileCheck --check-prefix=AARCH64-KERNEL %s
 
 // TINY: "-mcmodel=tiny"
 // SMALL: "-mcmodel=small"
@@ -15,3 +17,6 @@
 // AIX-MCMEDIUM-OVERRIDE: "-mcmodel=large"
 
 // INVALID: error: invalid argument 'lager' to -mcmodel=
+
+// AARCH64-MEDIUM: error: invalid argument 'medium' to -mcmodel=
+// AARCH64-KERNEL: error: invalid argument 'kernel' to -mcmodel=
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5421,6 +5421,9 @@
 CM == "tiny") {
   if (Triple.isOSAIX() && CM == "medium")
 CmdArgs.push_back("-mcmodel=large");
+  else if (Triple.isAArch64() && (CM == "kernel" || CM == "medium"))
+D.Diag(diag::err_drv_invalid_argument_to_option)
+<< CM << A->getOption().getName();
   else
 A->render(Args, CmdArgs);
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132440: [Clang] Avoid using unwind library in the MSVC environment

2022-08-24 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

> This reverts commit eca29d4a37b8d1c93fe99be6289a60bb11cf789d 
>  since 
> the test fails in the per-target-runtime-dir layout.

Does that mean that the testcase ended up looking at other libraries next to 
clang, in the build dir where the tests are run? That's rather annoying... I 
guess it could be fixed by adding `-resource-dir` in the testcase? (And ideally 
in the future, by making a harder switch between the two runtime install 
layouts in clang, as discussed on Discourse.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132440

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


[PATCH] D132444: [clang] Allow using -rtlib=platform to switching to the default rtlib on all targets

2022-08-24 Thread Martin Storsjö via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0a4c6c9f98a6: [clang] Allow using -rtlib=platform to 
switching to the default rtlib on all… (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132444

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/msvc-compiler-rt.c
  clang/test/Driver/rtlib-darwin.c


Index: clang/test/Driver/rtlib-darwin.c
===
--- /dev/null
+++ clang/test/Driver/rtlib-darwin.c
@@ -0,0 +1,6 @@
+// RUN: %clang -target x86_64-apple-darwin 
-resource-dir=%S/Inputs/resource_dir --rtlib=compiler-rt -### %s 2>&1 | 
FileCheck %s -check-prefix DARWIN-COMPILER-RT
+// RUN: %clang -target x86_64-apple-darwin 
-resource-dir=%S/Inputs/resource_dir --rtlib=platform -### %s 2>&1 | FileCheck 
%s -check-prefix DARWIN-COMPILER-RT
+// RUN: not %clang %s -target x86_64-apple-darwin --rtlib=libgcc 2>&1 | 
FileCheck %s -check-prefix CHECK-ERROR
+
+// DARWIN-COMPILER-RT: "{{.*}}clang_rt.osx{{.*}}"
+// CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'darwin'
Index: clang/test/Driver/msvc-compiler-rt.c
===
--- clang/test/Driver/msvc-compiler-rt.c
+++ clang/test/Driver/msvc-compiler-rt.c
@@ -1,5 +1,7 @@
 // RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt -### %s 2>&1 
| FileCheck %s -check-prefix MSVC-COMPILER-RT
+// RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt 
--rtlib=platform -### %s 2>&1 | FileCheck %s -check-prefix MSVC-DEFAULT
 // RUN: not %clang %s -target x86_64-pc-windows-msvc --rtlib=libgcc 2>&1 | 
FileCheck %s -check-prefix CHECK-ERROR
 
 // MSVC-COMPILER-RT: "{{.*}}clang_rt.builtins{{.*}}"
+// MSVC-DEFAULT-NOT: "{{.*}}clang_rt.builtins{{.*}}"
 // CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'MSVC'
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1385,7 +1385,7 @@
 const ArgList &Args) const {
   if (Arg* A = Args.getLastArg(options::OPT_rtlib_EQ)) {
 StringRef Value = A->getValue();
-if (Value != "compiler-rt")
+if (Value != "compiler-rt" && Value != "platform")
   getDriver().Diag(clang::diag::err_drv_unsupported_rtlib_for_platform)
   << Value << "darwin";
   }
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1602,9 +1602,10 @@
 if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
   // Issue error diagnostic if libgcc is explicitly specified
   // through command line as --rtlib option argument.
-  if (Args.hasArg(options::OPT_rtlib_EQ)) {
+  Arg *A = Args.getLastArg(options::OPT_rtlib_EQ);
+  if (A && A->getValue() != StringRef("platform")) {
 TC.getDriver().Diag(diag::err_drv_unsupported_rtlib_for_platform)
-<< Args.getLastArg(options::OPT_rtlib_EQ)->getValue() << "MSVC";
+<< A->getValue() << "MSVC";
   }
 } else
   AddLibgcc(TC, D, CmdArgs, Args);


Index: clang/test/Driver/rtlib-darwin.c
===
--- /dev/null
+++ clang/test/Driver/rtlib-darwin.c
@@ -0,0 +1,6 @@
+// RUN: %clang -target x86_64-apple-darwin -resource-dir=%S/Inputs/resource_dir --rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix DARWIN-COMPILER-RT
+// RUN: %clang -target x86_64-apple-darwin -resource-dir=%S/Inputs/resource_dir --rtlib=platform -### %s 2>&1 | FileCheck %s -check-prefix DARWIN-COMPILER-RT
+// RUN: not %clang %s -target x86_64-apple-darwin --rtlib=libgcc 2>&1 | FileCheck %s -check-prefix CHECK-ERROR
+
+// DARWIN-COMPILER-RT: "{{.*}}clang_rt.osx{{.*}}"
+// CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'darwin'
Index: clang/test/Driver/msvc-compiler-rt.c
===
--- clang/test/Driver/msvc-compiler-rt.c
+++ clang/test/Driver/msvc-compiler-rt.c
@@ -1,5 +1,7 @@
 // RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix MSVC-COMPILER-RT
+// RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt --rtlib=platform -### %s 2>&1 | FileCheck %s -check-prefix MSVC-DEFAULT
 // RUN: not %clang %s -target x86_64-pc-windows-msvc --rtlib=libgcc 2>&1 | FileCheck %s -check-prefix CHECK-ERROR
 
 // MSVC-COMPILER-RT: "{{.*}}clang_rt.builtins{{.*}}"
+// MSVC-DEFAULT-NOT: "{{.*}}clang_rt.builtins{{.*}}"
 // CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'MSVC'
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===

[clang] 0a4c6c9 - [clang] Allow using -rtlib=platform to switching to the default rtlib on all targets

2022-08-24 Thread Martin Storsjö via cfe-commits

Author: Martin Storsjö
Date: 2022-08-24T11:39:03+03:00
New Revision: 0a4c6c9f98a6dd5f12b8ff55c60f446b75958ac7

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

LOG: [clang] Allow using -rtlib=platform to switching to the default rtlib on 
all targets

Normally, passing -rtlib=platform overrides any earlier -rtlib
options, and overrides any hardcoded CLANG_DEFAULT_RTLIB option.
However, some targets, MSVC and Darwin, have custom logic for
disallowing specific -rtlib= option values; amend these checks for
allowing the -rtlib=platform option.

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

Added: 
clang/test/Driver/rtlib-darwin.c

Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/msvc-compiler-rt.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index d5b437ceed63c..b48dd40760ccd 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1602,9 +1602,10 @@ void tools::AddRunTimeLibs(const ToolChain &TC, const 
Driver &D,
 if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
   // Issue error diagnostic if libgcc is explicitly specified
   // through command line as --rtlib option argument.
-  if (Args.hasArg(options::OPT_rtlib_EQ)) {
+  Arg *A = Args.getLastArg(options::OPT_rtlib_EQ);
+  if (A && A->getValue() != StringRef("platform")) {
 TC.getDriver().Diag(diag::err_drv_unsupported_rtlib_for_platform)
-<< Args.getLastArg(options::OPT_rtlib_EQ)->getValue() << "MSVC";
+<< A->getValue() << "MSVC";
   }
 } else
   AddLibgcc(TC, D, CmdArgs, Args);

diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index c2a344d241a9f..4482a55a05019 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1385,7 +1385,7 @@ ToolChain::RuntimeLibType DarwinClang::GetRuntimeLibType(
 const ArgList &Args) const {
   if (Arg* A = Args.getLastArg(options::OPT_rtlib_EQ)) {
 StringRef Value = A->getValue();
-if (Value != "compiler-rt")
+if (Value != "compiler-rt" && Value != "platform")
   getDriver().Diag(clang::diag::err_drv_unsupported_rtlib_for_platform)
   << Value << "darwin";
   }

diff  --git a/clang/test/Driver/msvc-compiler-rt.c 
b/clang/test/Driver/msvc-compiler-rt.c
index abbca507ae7f4..9651662aa703e 100644
--- a/clang/test/Driver/msvc-compiler-rt.c
+++ b/clang/test/Driver/msvc-compiler-rt.c
@@ -1,5 +1,7 @@
 // RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt -### %s 2>&1 
| FileCheck %s -check-prefix MSVC-COMPILER-RT
+// RUN: %clang -target x86_64-pc-windows-msvc --rtlib=compiler-rt 
--rtlib=platform -### %s 2>&1 | FileCheck %s -check-prefix MSVC-DEFAULT
 // RUN: not %clang %s -target x86_64-pc-windows-msvc --rtlib=libgcc 2>&1 | 
FileCheck %s -check-prefix CHECK-ERROR
 
 // MSVC-COMPILER-RT: "{{.*}}clang_rt.builtins{{.*}}"
+// MSVC-DEFAULT-NOT: "{{.*}}clang_rt.builtins{{.*}}"
 // CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'MSVC'

diff  --git a/clang/test/Driver/rtlib-darwin.c 
b/clang/test/Driver/rtlib-darwin.c
new file mode 100644
index 0..cee8a80a5d266
--- /dev/null
+++ b/clang/test/Driver/rtlib-darwin.c
@@ -0,0 +1,6 @@
+// RUN: %clang -target x86_64-apple-darwin 
-resource-dir=%S/Inputs/resource_dir --rtlib=compiler-rt -### %s 2>&1 | 
FileCheck %s -check-prefix DARWIN-COMPILER-RT
+// RUN: %clang -target x86_64-apple-darwin 
-resource-dir=%S/Inputs/resource_dir --rtlib=platform -### %s 2>&1 | FileCheck 
%s -check-prefix DARWIN-COMPILER-RT
+// RUN: not %clang %s -target x86_64-apple-darwin --rtlib=libgcc 2>&1 | 
FileCheck %s -check-prefix CHECK-ERROR
+
+// DARWIN-COMPILER-RT: "{{.*}}clang_rt.osx{{.*}}"
+// CHECK-ERROR: unsupported runtime library 'libgcc' for platform 'darwin'



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


[PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-24 Thread Adrian Vogelsgesang via Phabricator via cfe-commits
avogelsgesang updated this revision to Diff 455111.
avogelsgesang marked an inline comment as done.

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

https://reviews.llvm.org/D132415

Files:
  clang/docs/tools/clang-formatted-files.txt
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
@@ -0,0 +1,40 @@
+#include 
+
+// `int_generator` is a stripped down, minimal coroutine generator
+// type.
+struct int_generator {
+  struct promise_type {
+int current_value = -1;
+
+auto get_return_object() {
+  return std::coroutine_handle::from_promise(*this);
+}
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+auto return_void() { return std::suspend_always(); }
+void unhandled_exception() { __builtin_unreachable(); }
+auto yield_value(int v) {
+  current_value = v;
+  return std::suspend_always();
+}
+  };
+
+  std::coroutine_handle hdl;
+
+  int_generator(std::coroutine_handle h) : hdl(h) {}
+  ~int_generator() { hdl.destroy(); }
+};
+
+int_generator my_generator_func() { co_yield 42; }
+
+// This is an empty function which we call just so the debugger has
+// a place to reliably set a breakpoint on.
+void empty_function_so_we_can_set_a_breakpoint() {}
+
+int main() {
+  int_generator gen = my_generator_func();
+  std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  gen.hdl.resume();// Break at initial_suspend
+  gen.hdl.resume();// Break after co_yield
+  empty_function_so_we_can_set_a_breakpoint(); // Break at final_suspend
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
@@ -0,0 +1,79 @@
+"""
+Test lldb data formatter subsystem.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):
+"""Test std::coroutine_handle is displayed correctly."""
+self.build(dictionary={stdlib_type: "1"})
+
+test_generator_func_ptr_re = re.compile(
+r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
+
+# Run until the initial suspension point
+lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
+lldb.SBFileSpec("main.cpp", False))
+# Check that we show the correct function pointers and the `promise`. 
+self.expect_expr("gen.hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "-1"),
+])
+])
+# For type-erased `coroutine_handle<>` we are missing the `promise`
+# but still show `resume` and `destroy`.
+self.expect_expr("type_erased_hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+])
+
+# Run until after the `co_yield`
+process = self.process()
+lldbutil.continue_to_source_breakpoint(self, process,
+'// Break after co_yield', lldb.SBFileSpec("main.cpp", False))
+# We correctly show the updated value inside `prommise.current_value`.
+self.expect_expr("gen.hdl",
+result_children=[
+ValueCh

[PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-24 Thread Adrian Vogelsgesang via Phabricator via cfe-commits
avogelsgesang added inline comments.



Comment at: lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp:39
+  CompilerType coro_func_type = ast_ctx.CreateFunctionType(
+  /*result_type*/ void_type, /*args*/ &void_type, /*num_args*/ 1,
+  /*is_variadic*/ false, /*qualifiers*/ 0);

shafik wrote:
> `/*result_type=*/` see 
> https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argument-comment.html
> 
> applies to the rest of them as well.
done


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

https://reviews.llvm.org/D132415

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


[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Michael Buch via Phabricator via cfe-commits
Michael137 added a comment.

FYI, this broke the LLDB build bot: 
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/46324/execution/node/74/log/

Looks like we're testing that unused parameters optimise out but that's not the 
case anymore

`AssertionError: '(void *) unused1 = ' not found in '(void *) unused1 = 0x00016fdff4d0\n'`

Looks like with this patch DWARF contains this extra entry for the unused 
parameter:

  0x0045: DW_TAG_formal_parameter   
  
DW_AT_location(0x:  
  
   [0x00013f1c, 0x00013f20): DW_OP_reg0 W0  
  
   [0x00013f20, 0x00013f24): 
DW_OP_entry_value(DW_OP_reg0 W0), DW_OP_stack_value) 

whereas previously it was,

  0x0045: DW_TAG_formal_parameter   
DW_AT_abstract_origin (0x0061 "unused1")


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[clang] 6703ad1 - Revert "[Pipelines] Introduce DAE after ArgumentPromotion"

2022-08-24 Thread Pavel Samolysov via cfe-commits

Author: Pavel Samolysov
Date: 2022-08-24T12:44:13+03:00
New Revision: 6703ad1e0c2a30153c75139764672d2ad16069c8

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

LOG: Revert "[Pipelines] Introduce DAE after ArgumentPromotion"

This reverts commit 3f20dcbf708cb23f79c4866d8285a8ae7bd885de.

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Passes/PassBuilderPipelines.cpp
llvm/test/Other/new-pm-defaults.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
llvm/test/Transforms/InstCombine/unused-nonnull.ll
llvm/test/Transforms/PhaseOrdering/dce-after-argument-promotion.ll

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index 64ac49420cbdc..463fc522c6a28 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -34,6 +34,7 @@
 ; CHECK-O: Running pass: CalledValuePropagationPass
 ; CHECK-O: Running pass: GlobalOptPass
 ; CHECK-O: Running pass: PromotePass
+; CHECK-O: Running pass: DeadArgumentEliminationPass
 ; CHECK-O: Running pass: InstCombinePass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main
 ; CHECK-O: Running pass: InlinerPass on (main)
@@ -73,7 +74,6 @@
 ; CHECK-O: Running pass: LCSSAPass on main
 ; CHECK-O: Running pass: SimplifyCFGPass on main
 ; CHECK-O: Running pass: InstCombinePass on main
-; CHECK-O: Running pass: DeadArgumentEliminationPass
 ; CHECK-O: Running pass: GlobalOptPass
 ; CHECK-O: Running pass: GlobalDCEPass
 ; CHECK-O: Running pass: EliminateAvailableExternallyPass

diff  --git a/llvm/lib/Passes/PassBuilderPipelines.cpp 
b/llvm/lib/Passes/PassBuilderPipelines.cpp
index 2587c8ce900b9..bd07638b37617 100644
--- a/llvm/lib/Passes/PassBuilderPipelines.cpp
+++ b/llvm/lib/Passes/PassBuilderPipelines.cpp
@@ -639,7 +639,7 @@ void PassBuilder::addPGOInstrPasses(ModulePassManager &MPM,
 
 FunctionPassManager FPM;
 FPM.addPass(SROAPass());
-FPM.addPass(EarlyCSEPass()); // Catch trivial redundancies.
+FPM.addPass(EarlyCSEPass());// Catch trivial redundancies.
 FPM.addPass(SimplifyCFGPass(SimplifyCFGOptions().convertSwitchRangeToICmp(
 true)));// Merge & remove basic blocks.
 FPM.addPass(InstCombinePass()); // Combine silly sequences.
@@ -734,9 +734,10 @@ PassBuilder::buildInlinerPipeline(OptimizationLevel Level,
   if (PGOOpt)
 IP.EnableDeferral = EnablePGOInlineDeferral;
 
-  ModuleInlinerWrapperPass MIWP(IP, PerformMandatoryInliningsFirst,
-InlineContext{Phase, InlinePass::CGSCCInliner},
-UseInlineAdvisor, MaxDevirtIterations);
+  ModuleInlinerWrapperPass MIWP(
+  IP, PerformMandatoryInliningsFirst,
+  InlineContext{Phase, InlinePass::CGSCCInliner},
+  UseInlineAdvisor, MaxDevirtIterations);
 
   // Require the GlobalsAA analysis for the module so we can query it within
   // the CGSCC pipeline.
@@ -960,6 +961,10 @@ 
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
   // constants.
   MPM.addPass(createModuleToFunctionPassAdaptor(PromotePass()));
 
+  // Remove any dead arguments exposed by cleanups and constant folding
+  // globals.
+  MPM.addPass(DeadArgumentEliminationPass());
+
   // Create a small function pass pipeline to cleanup after all the global
   // optimizations.
   FunctionPassManager GlobalCleanupPM;
@@ -994,10 +999,6 @@ 
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
   else
 MPM.addPass(buildInlinerPipeline(Level, Phase));
 
-  // Remove any dead arguments exposed by cleanups, constant folding globals,
-  // and argument promotion.
-  MPM.addPass(DeadArgumentEliminationPass());
-
   MPM.addPass(CoroCleanupPass());
 
   if (EnableMemProfiler && Phase != ThinOrFullLTOPhase::ThinLTOPreLink) {
@@ -1595,6 +1596,9 @@ PassBuilder::buildLTODefaultPipeline(OptimizationLevel 
Level,
   // keep one copy of each constant.
   MPM.addPass(ConstantMergePass());
 
+  // Remove unused arguments from functions.
+  MPM.addPass(DeadArgumentEliminationPass());
+
   // Reduce the code after globalopt and ipsccp.  Both can open up significant
   // simplification opportunities, and both can propagate functions through
   // function pointers.  When this happens, we often have to resolve varargs
@@ -1617,7 +1621,7 @@ PassBuilder::buildLTODefaultPipeline(OptimizationLevel 
Level,
   getInlineParamsFromOptLevel(L

[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Pavel Samolysov via Phabricator via cfe-commits
psamolysov added a comment.

@Michael137 Thank you very much for the information!

I'm not sure, but it looks like the introduced change of the `readnone` 
attribute to `readonly` might make impact on DWARF. Unfortunately, I have no 
idea should this changes in DWARF be fixed or just it is enough to actualize 
the test.

I've reverted the patch to give our time to make the decision about DWARF 
generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Michael Buch via Phabricator via cfe-commits
Michael137 added subscribers: aprantl, dblaikie.
Michael137 added a comment.

In D128830#3745069 , @psamolysov 
wrote:

> @Michael137 Thank you very much for the information!
>
> I'm not sure, but it looks like the introduced change of the `readnone` 
> attribute to `readonly` might make impact on DWARF. Unfortunately, I have no 
> idea should this changes in DWARF be fixed or just it is enough to actualize 
> the test.
>
> I've reverted the patch to give our time to make the decision about DWARF 
> generation.

Thanks!

@aprantl @dblaikie Looks like this needs to accommodate existing DWARF 
generation behaviour?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Pavel Samolysov via Phabricator via cfe-commits
psamolysov added a comment.

I tried to triage a bit. The test 
`lldb\test\API\functionalities\unused-inlined-parameters\TestUnusedInlinedParameters.py`
 compiles the code in `main.c` with `-O1` and generates the following IR for 
the `@f` function:

  ; Function Attrs: alwaysinline nounwind uwtable
  define dso_local void @f(ptr nocapture noundef readnone %unused1, i32 noundef 
%used, i32 noundef %unused2) local_unnamed_addr #1 {
  entry:
tail call void @use(i32 noundef %used)
ret void
  }

With the reverted patch, the IR looks like the follow:

  ; Function Attrs: alwaysinline nounwind uwtable
  define dso_local void @f(ptr nocapture readnone %unused1, i32 noundef %used, 
i32 %unused2) local_unnamed_addr #1 {
  entry:
tail call void @use(i32 noundef %used)
ret void
  }

So, as we can see, the attribute `readnone` is present for the first unused 
argument for which an additional piece of the DWARF code is generated in both 
IRs but the `noundef` attribute is omitted in the second case (so, this 
attribute is introduces by some changes in the patch and this is "documented" 
by the changes in the `llvm/test/Transforms/InstCombine/unused-nonnull.ll` 
test).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D132473: [Docs][OpenCL][SPIR-V] Release 15 notes for Clang

2022-08-24 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 455139.
Anastasia added a comment.

- Added clarification about the opaque pointers in SPIR-V.


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

https://reviews.llvm.org/D132473

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -566,10 +566,18 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
-
-...
+OpenCL Kernel Language Changes in Clang
+---
+
+- Improved/fixed misc issues in the builtin function support and diagnostics.
+- Improved diagnostics for unknown extension pragma, subgroup functions and
+  implicit function prototype.
+- Added ``-cl-ext`` flag to the Clang driver to toggle extensions/features
+  compiled for.
+- Added ``cl_khr_subgroup_rotate`` extension.
+- Removed some ``printf`` and ``hostcall`` related diagnostics when compiling
+  for AMDGPU.
+- Fixed alignment of pointer types in kernel arguments.
 
 ABI Changes in Clang
 
@@ -660,6 +668,14 @@
   Operations found in the :ref:`Clang Language Extensions `
   document.
 
+SPIR-V Support in Clang
+---
+
+- Added flag ``-fintegrated-objemitter`` to enable use of experimental
+  integrated LLVM backend when generating SPIR-V binary.
+- The SPIR-V generation continues to produce typed pointers in this release
+  despite the general switch of LLVM to opaque pointers.
+
 Floating Point Support in Clang
 ---
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -566,10 +566,18 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
-
-...
+OpenCL Kernel Language Changes in Clang
+---
+
+- Improved/fixed misc issues in the builtin function support and diagnostics.
+- Improved diagnostics for unknown extension pragma, subgroup functions and
+  implicit function prototype.
+- Added ``-cl-ext`` flag to the Clang driver to toggle extensions/features
+  compiled for.
+- Added ``cl_khr_subgroup_rotate`` extension.
+- Removed some ``printf`` and ``hostcall`` related diagnostics when compiling
+  for AMDGPU.
+- Fixed alignment of pointer types in kernel arguments.
 
 ABI Changes in Clang
 
@@ -660,6 +668,14 @@
   Operations found in the :ref:`Clang Language Extensions `
   document.
 
+SPIR-V Support in Clang
+---
+
+- Added flag ``-fintegrated-objemitter`` to enable use of experimental
+  integrated LLVM backend when generating SPIR-V binary.
+- The SPIR-V generation continues to produce typed pointers in this release
+  despite the general switch of LLVM to opaque pointers.
+
 Floating Point Support in Clang
 ---
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132473: [Docs][OpenCL][SPIR-V] Release 15 notes for Clang

2022-08-24 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:676
+  LLVM backend when generating SPIR-V binary.
+
 Floating Point Support in Clang

svenvh wrote:
> Should we say anything about opaque pointers?  Something like:
> 
> ```
>  - Although LLVM has switched to opaque pointers with this release, SPIR-V 
> generation still relies on typed pointers in this release.
> ```
Sure, good point! I have added an item to clarify this. Does it look ok to you?


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

https://reviews.llvm.org/D132473

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


[PATCH] D131683: Diagnosing the Future Keywords

2022-08-24 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman updated this revision to Diff 455141.
Codesbyusman added a comment.

updated with suggestions and test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131683

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/Lexer/keywords_test.c
  clang/test/Lexer/keywords_test.cpp
  clang/test/Parser/static_assert.c

Index: clang/test/Parser/static_assert.c
===
--- clang/test/Parser/static_assert.c
+++ clang/test/Parser/static_assert.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -verify=c2x %s
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -fms-compatibility -verify=c2x-ms %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -Weverything -verify=c17 %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -fms-compatibility -verify=c17-ms %s
 // RUN: %clang_cc1 -fsyntax-only -std=c2x -Wpre-c2x-compat -verify=c2x-compat %s
 // RUN: %clang_cc1 -fsyntax-only -std=c99 -verify=c99 %s
 // RUN: %clang_cc1 -fsyntax-only -std=c99 -pedantic -verify=c99-pedantic %s
@@ -15,11 +15,15 @@
 // Only test the C++ spelling in C mode in some of the tests, to reduce the
 // amount of diagnostics to have to check. This spelling is allowed in MS-
 // compatibility mode in C, but otherwise produces errors.
-static_assert(1, ""); // c2x-error {{expected parameter declarator}} \
-  // c2x-error {{expected ')'}} \
-  // c2x-note {{to match this '('}} \
-  // c2x-error {{a type specifier is required for all declarations}} \
-  // c2x-ms-warning {{use of 'static_assert' without inclusion of  is a Microsoft extension}}
+static_assert(1, ""); // c17-warning {{'static_assert' is a keyword in C2x}} \
+  // c17-error {{expected parameter declarator}} \
+  // c17-error {{expected ')'}} \
+  // c17-note {{to match this '('}} \
+  // c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}} \
+  // c17-warning {{ function declaration without a prototype is deprecated in all versions of C}} \
+  // c17-ms-warning {{use of 'static_assert' without inclusion of  is a Microsoft extension}} 
+ 
+
 #endif
 
 // We support _Static_assert as an extension in older C modes and in all C++
@@ -42,4 +46,7 @@
// cxx17-compat-warning {{'static_assert' with no message is incompatible with C++ standards before C++17}} \
// c99-pedantic-warning {{'_Static_assert' is a C11 extension}} \
// cxx17-pedantic-warning {{'_Static_assert' is a C11 extension}} \
-   // cxx98-pedantic-warning {{'_Static_assert' is a C11 extension}}
+   // cxx98-pedantic-warning {{'_Static_assert' is a C11 extension}} \
+   // c17-warning {{'_Static_assert' with no message is a C2x extension}} \
+   // c17-ms-warning {{'_Static_assert' with no message is a C2x extension}} 
+
Index: clang/test/Lexer/keywords_test.cpp
===
--- clang/test/Lexer/keywords_test.cpp
+++ clang/test/Lexer/keywords_test.cpp
@@ -15,6 +15,8 @@
 // RUN: %clang -std=c++03 -target i686-windows-msvc -DMS -fno-declspec -fsyntax-only %s
 // RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
+// RUN: %clang_cc1 -std=c++98 -DFutureKeyword -fsyntax-only -Wc++11-compat -Wc++20-compat -verify=cxx98 %s
+
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
 #define IS_TYPE(NAME) void is_##NAME##_type() { int f(NAME); }
@@ -50,17 +52,24 @@
 CXX11_TYPE(char32_t);
 CXX11_KEYWORD(constexpr);
 CXX11_KEYWORD(noexcept);
+
 #ifndef MS
 CXX11_KEYWORD(static_assert);
 #else
 // MS compiler recognizes static_assert in all modes. So should we.
 IS_KEYWORD(static_assert);
 #endif
+
 CXX11_KEYWORD(thread_local);
 
 // Concepts keywords
 CXX20_KEYWORD(concept);
 CXX20_KEYWORD(requires);
+CXX20_KEYWORD(consteval);
+CXX20_KEYWORD(constinit);
+CXX20_KEYWORD(co_await);
+CXX20_KEYWORD(co_return);
+CXX20_KEYWORD(co_yield);
 
 // __declspec extension
 DECLSPEC_KEYWORD(__declspec);
@@ -70,3 +79,26 @@
 IS_TYPE(__char16_t);
 IS_KEYWORD(__char32_t);
 IS_TYPE(__char32_t);
+
+#ifdef FutureKeyword
+
+int nullptr; // cxx98-warning {{'nullptr' is a keyword in C++11}}
+int decltype;  // cxx98-warning {{'decltype' is a keyword in C++1

[PATCH] D131683: Diagnosing the Future Keywords

2022-08-24 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman updated this revision to Diff 455147.
Codesbyusman added a comment.

updated test cases and suggestions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131683

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/Lexer/keywords_test.c
  clang/test/Lexer/keywords_test.cpp
  clang/test/Parser/static_assert.c

Index: clang/test/Parser/static_assert.c
===
--- clang/test/Parser/static_assert.c
+++ clang/test/Parser/static_assert.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -verify=c2x %s
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -fms-compatibility -verify=c2x-ms %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -Weverything -verify=c17 %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -fms-compatibility -verify=c17-ms %s
 // RUN: %clang_cc1 -fsyntax-only -std=c2x -Wpre-c2x-compat -verify=c2x-compat %s
 // RUN: %clang_cc1 -fsyntax-only -std=c99 -verify=c99 %s
 // RUN: %clang_cc1 -fsyntax-only -std=c99 -pedantic -verify=c99-pedantic %s
@@ -15,11 +15,15 @@
 // Only test the C++ spelling in C mode in some of the tests, to reduce the
 // amount of diagnostics to have to check. This spelling is allowed in MS-
 // compatibility mode in C, but otherwise produces errors.
-static_assert(1, ""); // c2x-error {{expected parameter declarator}} \
-  // c2x-error {{expected ')'}} \
-  // c2x-note {{to match this '('}} \
-  // c2x-error {{a type specifier is required for all declarations}} \
-  // c2x-ms-warning {{use of 'static_assert' without inclusion of  is a Microsoft extension}}
+static_assert(1, ""); // c17-warning {{'static_assert' is a keyword in C2x}} \
+  // c17-error {{expected parameter declarator}} \
+  // c17-error {{expected ')'}} \
+  // c17-note {{to match this '('}} \
+  // c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}} \
+  // c17-warning {{ function declaration without a prototype is deprecated in all versions of C}} \
+  // c17-ms-warning {{use of 'static_assert' without inclusion of  is a Microsoft extension}} 
+ 
+
 #endif
 
 // We support _Static_assert as an extension in older C modes and in all C++
@@ -42,4 +46,7 @@
// cxx17-compat-warning {{'static_assert' with no message is incompatible with C++ standards before C++17}} \
// c99-pedantic-warning {{'_Static_assert' is a C11 extension}} \
// cxx17-pedantic-warning {{'_Static_assert' is a C11 extension}} \
-   // cxx98-pedantic-warning {{'_Static_assert' is a C11 extension}}
+   // cxx98-pedantic-warning {{'_Static_assert' is a C11 extension}} \
+   // c17-warning {{'_Static_assert' with no message is a C2x extension}} \
+   // c17-ms-warning {{'_Static_assert' with no message is a C2x extension}} 
+
Index: clang/test/Lexer/keywords_test.cpp
===
--- clang/test/Lexer/keywords_test.cpp
+++ clang/test/Lexer/keywords_test.cpp
@@ -15,6 +15,8 @@
 // RUN: %clang -std=c++03 -target i686-windows-msvc -DMS -fno-declspec -fsyntax-only %s
 // RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
+// RUN: %clang_cc1 -std=c++98 -DFutureKeyword -fsyntax-only -Wc++11-compat -Wc++20-compat -verify=cxx98 %s
+
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
 #define IS_TYPE(NAME) void is_##NAME##_type() { int f(NAME); }
@@ -50,17 +52,24 @@
 CXX11_TYPE(char32_t);
 CXX11_KEYWORD(constexpr);
 CXX11_KEYWORD(noexcept);
+
 #ifndef MS
 CXX11_KEYWORD(static_assert);
 #else
 // MS compiler recognizes static_assert in all modes. So should we.
 IS_KEYWORD(static_assert);
 #endif
+
 CXX11_KEYWORD(thread_local);
 
 // Concepts keywords
 CXX20_KEYWORD(concept);
 CXX20_KEYWORD(requires);
+CXX20_KEYWORD(consteval);
+CXX20_KEYWORD(constinit);
+CXX20_KEYWORD(co_await);
+CXX20_KEYWORD(co_return);
+CXX20_KEYWORD(co_yield);
 
 // __declspec extension
 DECLSPEC_KEYWORD(__declspec);
@@ -70,3 +79,26 @@
 IS_TYPE(__char16_t);
 IS_KEYWORD(__char32_t);
 IS_TYPE(__char32_t);
+
+#ifdef FutureKeyword
+
+int nullptr; // cxx98-warning {{'nullptr' is a keyword in C++11}}
+int decltype;  // cxx98-warning {{'decltype' is a keyword in C++11}}
+

[PATCH] D131683: Diagnosing the Future Keywords

2022-08-24 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.def:384
+C2X_KEYWORD(true, BOOLSUPPORT)
+C2X_KEYWORD(remove_quals, KEYC2X)
+

aaron.ballman wrote:
> This is technically correct, but I think we should remove it until we go to 
> implement that paper instead of introducing the keyword out of thin air here.
> 
> Btw, I think that should be `, 0` instead of `, KEYC2X` given the use of 
> `C2X_KEYWORD`, right?
> This is technically correct, but I think we should remove it until we go to 
> implement that paper instead of introducing the keyword out of thin air here.
> 
> Btw, I think that should be `, 0` instead of `, KEYC2X` given the use of 
> `C2X_KEYWORD`, right?

Don't know much but what I understand that this is a keyword but not published 
officially by language but will be in future. so I think will be good to remove 
it or can add Fixme?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131683

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


[PATCH] D132521: [AST] Reuse PrintingPolicy from ASTContext

2022-08-24 Thread Youngsuk Kim via Phabricator via cfe-commits
JOE1994 updated this revision to Diff 455157.
JOE1994 added a comment.

Add missed out 'const'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132521

Files:
  clang/lib/Frontend/ASTConsumers.cpp


Index: clang/lib/Frontend/ASTConsumers.cpp
===
--- clang/lib/Frontend/ASTConsumers.cpp
+++ clang/lib/Frontend/ASTConsumers.cpp
@@ -92,7 +92,7 @@
 } else
   Out << "Not a DeclContext\n";
   } else if (OutputKind == Print) {
-PrintingPolicy Policy(D->getASTContext().getLangOpts());
+const PrintingPolicy &Policy = D->getASTContext().getPrintingPolicy();
 D->print(Out, Policy, /*Indentation=*/0, /*PrintInstantiation=*/true);
   } else if (OutputKind != None) {
 D->dump(Out, OutputKind == DumpFull, OutputFormat);


Index: clang/lib/Frontend/ASTConsumers.cpp
===
--- clang/lib/Frontend/ASTConsumers.cpp
+++ clang/lib/Frontend/ASTConsumers.cpp
@@ -92,7 +92,7 @@
 } else
   Out << "Not a DeclContext\n";
   } else if (OutputKind == Print) {
-PrintingPolicy Policy(D->getASTContext().getLangOpts());
+const PrintingPolicy &Policy = D->getASTContext().getPrintingPolicy();
 D->print(Out, Policy, /*Indentation=*/0, /*PrintInstantiation=*/true);
   } else if (OutputKind != None) {
 D->dump(Out, OutputKind == DumpFull, OutputFormat);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131763: [OpenMP] Add lit test for metadirective device arch inspired from sollve

2022-08-24 Thread Animesh Kumar via Phabricator via cfe-commits
animeshk-amd updated this revision to Diff 455161.
animeshk-amd added a comment.

The second function was testing the `implementation` trait set for
the `vendor` trait with respect to the `metadirective` directive.
After Johannes's comment, on further searching it turns out that 
this trait and trait set are already being tested in other tests.
Therfore second function need not be there. Also, the ast_print 
test for the first function is added.

Updating D131763: [OpenMP] Add lit test for metadirective device arch inspired
==

from sollve


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131763

Files:
  clang/test/OpenMP/metadirective_ast_print.c
  clang/test/OpenMP/metadirective_device_arch_codegen.cpp

Index: clang/test/OpenMP/metadirective_device_arch_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/metadirective_device_arch_codegen.cpp
@@ -0,0 +1,65 @@
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple amdgcn-amd-amdhsa -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -target-cpu gfx906 -o - | FileCheck %s
+// expected-no-diagnostics
+
+
+/*===---=== 
+
+Inspired from SOLLVE tests:
+ - 5.0/metadirective/test_metadirective_arch_is_nvidia.c
+
+
+======*/
+
+
+#define N 1024
+
+int metadirective1() {
+   
+   int v1[N], v2[N], v3[N];
+
+   int target_device_num, host_device_num, default_device;
+   int errors = 0;
+
+   #pragma omp target map(to:v1,v2) map(from:v3, target_device_num) device(default_device)
+   {
+  #pragma omp metadirective \
+   when(device={arch("amdgcn")}: teams distribute parallel for) \
+   default(parallel for)
+
+ for (int i = 0; i < N; i++) {
+	#pragma omp atomic write
+v3[i] = v1[i] * v2[i];
+ }
+   }
+
+   return errors;
+}
+
+// CHECK-LABEL: define weak_odr amdgpu_kernel void {{.+}}metadirective1
+// CHECK: entry:
+// CHECK: %{{[0-9]}} = call i32 @__kmpc_target_init
+// CHECK: user_code.entry:
+// CHECK: call void @__omp_outlined__
+// CHECK-NOT: call void @__kmpc_parallel_51
+// CHECK: ret void
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__
+// CHECK: entry:
+// CHECK: call void @__kmpc_distribute_static_init
+// CHECK: omp.loop.exit:  
+// CHECK: call void @__kmpc_distribute_static_fini
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__.{{[0-9]+}}
+// CHECK: entry:
+// CHECK: call void @__kmpc_for_static_init_4
+// CHECK: omp.inner.for.body:
+// CHECK: store atomic {{.*}} monotonic
+// CHECK: omp.loop.exit:
+// CHECK-NEXT: call void @__kmpc_distribute_static_fini
+// CHECK-NEXT: ret void
+
Index: clang/test/OpenMP/metadirective_ast_print.c
===
--- clang/test/OpenMP/metadirective_ast_print.c
+++ clang/test/OpenMP/metadirective_ast_print.c
@@ -1,6 +1,10 @@
 // RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-linux-gnu -x c -std=c99 -ast-print %s -o - | FileCheck %s
 
 // RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-linux-gnu -x c -std=c99 -ast-print %s -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp -triple amdgcn-amd-amdhsa -x c -std=c99 -ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -triple amdgcn-amd-amdhsa -x c -std=c99 -ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
 // expected-no-diagnostics
 
 #ifndef HEADER
@@ -57,6 +61,12 @@
 for (int j = 0; j < 16; j++)
   array[i] = i;
   }
+
+#pragma omp metadirective when(device={arch("amdgcn")}: \
+teams distribute parallel for)\
+default(parallel for)
+  for (int i = 0; i < 100; i++)
+  ;
 }
 
 // CHECK: void bar(void);
@@ -83,5 +93,7 @@
 // CHECK-NEXT: for (int i = 0; i < 16; i++) {
 // CHECK-NEXT: #pragma omp simd
 // CHECK-NEXT: for (int j = 0; j < 16; j++)
+// CHECK-AMDGCN: #pragma omp teams distribute parallel for
+// CHECK-AMDGCN-NEXT: for (int i = 0; i < 100; i++)
 
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132550: Changes to code ownership in clang and clang-tidy

2022-08-24 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
Herald added a subscriber: yaxunl.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added projects: clang, clang-tools-extra.

This corresponds to the RFC posted to Discourse proposing changes for code 
ownership in both Clang and clang-tidy, which can be found at: .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132550

Files:
  clang-tools-extra/CODE_OWNERS.TXT
  clang/CODE_OWNERS.TXT

Index: clang/CODE_OWNERS.TXT
===
--- clang/CODE_OWNERS.TXT
+++ clang/CODE_OWNERS.TXT
@@ -4,9 +4,8 @@
 what goes in or not.
 
 The list is sorted by surname and formatted to allow easy grepping and
-beautification by scripts.  The fields are: name (N), email (E), web-address
-(W), PGP key ID and fingerprint (P), description (D), and snail-mail address
-(S).
+beautification by scripts.  The fields are: name (N), email (E), Phabricator
+handle (H), and description (D).
 
 N: Alexey Bader
 E: alexey.ba...@intel.com
@@ -14,29 +13,71 @@
 
 N: Aaron Ballman
 E: aa...@aaronballman.com
-D: Clang attributes
+H: aaron.ballman
+D: All parts of Clang not covered by someone else, C standards conformance
 
 N: Alexey Bataev
 E: a.bat...@hotmail.com
 D: OpenMP support
 
-N: Chandler Carruth
-E: chandl...@gmail.com
-E: chandl...@google.com
-D: CMake, library layering
-
 N: Eric Christopher
 E: echri...@gmail.com
 D: Debug Information, inline assembly
 
-N: Devin Coughlin
-E: dcough...@apple.com
+N: Artem Dergachev
+E: adergac...@apple.com
+H: NoQ
 D: Clang Static Analyzer
 
+N: John Ericson
+E: g...@johnericson.me
+H: Ericson2314
+D: CMake integration
+
+N: Eli Friedman
+E: efrie...@quicinc.com
+H: efriedma
+D: Clang LLVM IR generation
+
+N: Stanislav Gatev
+E: sga...@google.com
+H: sgatev
+D: Analysis & CFG
+
 N: Doug Gregor
 E: dgre...@apple.com
 D: Emeritus owner
 
+N: Dmitri Gribenko
+E: griboz...@gmail.com
+H: gribozavr
+D: Analysis & CFG
+
+N: Tom Honermann
+E: t...@honermann.net
+H: tahonermann
+D: Text encodings
+
+N: Gábor Horváth
+E: xazax@gmail.com
+H: xazax.hun
+D: Clang Static Analyzer
+
+N: Petr Hosek
+E: pho...@google.com
+H: phosek
+D: CMake integration
+
+N: Corentin Jabot
+E: corentin.ja...@gmail.com
+H: cor3ntin
+D: Text encodings
+
+N: Erich Keane
+E: erich.ke...@intel.com
+H: ErichKeane
+D: Attributes, Templates
+
 N: Reid Kleckner
 E: r...@google.com
 D: Microsoft C++ ABI compatibility and general Windows support
@@ -49,9 +90,24 @@
 E: an...@korobeynikov.info
 D: Exception handling, Windows codegen, ARM EABI
 
+N: Yitzhak Mandelbaum
+E: yitzh...@google.com
+H: ymandel
+D: Analysis & CFG
+
 N: John McCall
 E: rjmcc...@apple.com
-D: Clang LLVM IR generation
+D: Clang LLVM IR generation, Itanium ABI, Objective-C conformance
+
+N: MyDeveloperDay
+E: mydeveloper...@gmail.com
+H: MyDeveloperDay
+D: clang-format
+
+N: Owen Pan
+E: owenpi...@gmail.com
+H: owenpan
+D: clang-format
 
 N: Brad Smith
 E: b...@comstyle.com
@@ -59,8 +115,33 @@
 
 N: Richard Smith
 E: rich...@metafoo.co.uk
-D: All parts of Clang not covered by someone else
+D: Emeritus owner
+
+N: Fangrui Song
+E: mask...@google.com
+H: MaskRay
+D: Clang Driver parts not covered by someone else
+
+N: Michael Spencer
+E: bigchees...@gmail.com
+H: Bigcheese
+D: Modules & Serialization
 
 N: Anastasia Stulova
 E: anastasia.stul...@arm.com
 D: OpenCL support
+
+N: Jan Svoboda
+E: jan_svob...@apple.com
+H: jansvoboda11
+D: Compiler Options
+
+N: Hubert Tong
+E: hubert.reinterpretc...@gmail.com
+H: hubert.reinterpretcast
+D: C++ standards conformance
+
+N: Chuanqi Xu
+E: yedeng...@linux.alibaba.com
+H: ChuanqiXu
+D: Modules & Serialization
Index: clang-tools-extra/CODE_OWNERS.TXT
===
--- clang-tools-extra/CODE_OWNERS.TXT
+++ clang-tools-extra/CODE_OWNERS.TXT
@@ -4,26 +4,27 @@
 in or not.
 
 The list is sorted by surname and formatted to allow easy grepping and
-beautification by scripts.  The fields are: name (N), email (E), web-address
-(W), PGP key ID and fingerprint (P), description (D), and snail-mail address
-(S).
+beautification by scripts.  The fields are: name (N), email (E), Phabricator
+handle (H), and description (D).
 
 N: Aaron Ballman
 E: aa...@aaronballman.com
+H: aaron.ballman
 D: clang-query
 
-N: Manuel Klimek
-E: kli...@google.com
-D: clang-rename, all parts of clang-tools-extra not covered by someone else
-
-N: Alexander Kornienko
-E: ale...@google.com
-D: clang-tidy
-
 N: Julie Hockett
 E: juliehock...@google.com
 D: clang-doc
 
+N: Nathan James
+E: n.jame...@hotmail.co.uk
+H: njames93
+D: clang-tidy
+
+N: Manuel Klimek
+E: kli...@google.com
+D: clang-rename, all parts of clang-tools-extra not covered by someone else
+
 N: Sam McCall
 E: sammcc...@google.com
 D: clangd
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2022-08-24 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added a comment.

I looked at this a bit about a week ago and got it down to 3-4 tests failing, 
but I'm not sure how much time I'll have to continue working on it. If one of 
you wants to take over I'll be happy to send you what I've currently got. 
@erichkeane @ilya-biryukov

Also, do you know if having posted this patch is agreement for licensing this 
code? Or do we need to get explicit agreement from the original author before 
committing a version of this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D53847

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


[clang] 3e84cdb - [NFC] Colocate cache values for controling libc++ headers build in stage 2

2022-08-24 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2022-08-24T08:50:52-04:00
New Revision: 3e84cdbee467f97026f1ad421abcaf9b862c1ff4

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

LOG: [NFC] Colocate cache values for controling libc++ headers build in stage 2

Added: 


Modified: 
clang/cmake/caches/Apple-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Apple-stage2.cmake 
b/clang/cmake/caches/Apple-stage2.cmake
index 63f92eab8c1e5..3ed725132cabd 100644
--- a/clang/cmake/caches/Apple-stage2.cmake
+++ b/clang/cmake/caches/Apple-stage2.cmake
@@ -36,10 +36,6 @@ if(LLVM_ENABLE_LTO AND NOT LLVM_ENABLE_LTO STREQUAL "THIN")
 endif()
 set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
 
-set(LIBCXX_INSTALL_LIBRARY OFF CACHE BOOL "")
-set(LIBCXX_INSTALL_HEADERS ON CACHE BOOL "")
-set(LIBCXX_INCLUDE_TESTS OFF CACHE BOOL "")
-set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
 set(LLVM_LTO_VERSION_OFFSET 3000 CACHE STRING "")
 
 # Generating Xcode toolchains is useful for developers wanting to build and use
@@ -79,9 +75,13 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   ${LLVM_TOOLCHAIN_UTILITIES}
   CACHE STRING "")
 
-set(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS
-  cxx-headers
-  CACHE STRING "")
+# Build the libc++ headers
+# Note that LLVM_ENABLE_RUNTIMES must be passed on the command-line.
+set(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS cxx-headers CACHE STRING "")
+set(LIBCXX_INSTALL_LIBRARY OFF CACHE BOOL "")
+set(LIBCXX_INSTALL_HEADERS ON CACHE BOOL "")
+set(LIBCXX_INCLUDE_TESTS OFF CACHE BOOL "")
+set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
 
 # test args
 



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


[PATCH] D132473: [Docs][OpenCL][SPIR-V] Release 15 notes for Clang

2022-08-24 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!




Comment at: clang/docs/ReleaseNotes.rst:676
+  LLVM backend when generating SPIR-V binary.
+
 Floating Point Support in Clang

Anastasia wrote:
> svenvh wrote:
> > Should we say anything about opaque pointers?  Something like:
> > 
> > ```
> >  - Although LLVM has switched to opaque pointers with this release, SPIR-V 
> > generation still relies on typed pointers in this release.
> > ```
> Sure, good point! I have added an item to clarify this. Does it look ok to 
> you?
generation -> generator I'd say, which you can address at commit time.  For the 
rest it looks good!


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

https://reviews.llvm.org/D132473

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


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

2022-08-24 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a subscriber: tstellar.
erichkeane added a comment.

In D53847#3745415 , @royjacobson wrote:

> I looked at this a bit about a week ago and got it down to 3-4 tests failing, 
> but I'm not sure how much time I'll have to continue working on it. If one of 
> you wants to take over I'll be happy to send you what I've currently got. 
> @erichkeane @ilya-biryukov
>
> Also, do you know if having posted this patch is agreement for licensing this 
> code? Or do we need to get explicit agreement from the original author before 
> committing a version of this?

I've never seen that be an issue before, and I don't see enough in 
https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents to be 
clear about the answer to that.  @tstellar could perhaps answer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D53847

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


[PATCH] D132550: Changes to code ownership in clang and clang-tidy

2022-08-24 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added inline comments.
This revision is now accepted and ready to land.
Herald added a subscriber: rnkovacs.



Comment at: clang-tools-extra/CODE_OWNERS.TXT:8
+beautification by scripts.  The fields are: name (N), email (E), Phabricator
+handle (H), and description (D).
 

As LLVM is officially hosted on GitHub now, I wonder whether a new field should 
be introduced for GitHub handles. This can be also handy to assign bugs to 
people, and in the future, add reviewers to PRs. But feel free to ignore this 
for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132550

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


[clang] b1320f7 - [clang] Explicitly add libcxx and libcxxabi runtimes during Stage2 builds

2022-08-24 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2022-08-24T09:13:29-04:00
New Revision: b1320f7c9b907d39c8ceca9b91d66046441f1ae3

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

LOG: [clang] Explicitly add libcxx and libcxxabi runtimes during Stage2 builds

For the time being, we are still building libc++ and libc++abi's headers
during stage 2 builds. Encode that in the cache file so that CI jobs don't
have to manually specify LLVM_ENABLE_RUNTIMES when doing a stage 2 build.

Added: 


Modified: 
clang/cmake/caches/Apple-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Apple-stage2.cmake 
b/clang/cmake/caches/Apple-stage2.cmake
index 3ed725132cab..72cdedd611bc 100644
--- a/clang/cmake/caches/Apple-stage2.cmake
+++ b/clang/cmake/caches/Apple-stage2.cmake
@@ -76,7 +76,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   CACHE STRING "")
 
 # Build the libc++ headers
-# Note that LLVM_ENABLE_RUNTIMES must be passed on the command-line.
+set(LLVM_ENABLE_RUNTIMES "libcxx;libcxxabi" CACHE STRING "")
 set(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS cxx-headers CACHE STRING "")
 set(LIBCXX_INSTALL_LIBRARY OFF CACHE BOOL "")
 set(LIBCXX_INSTALL_HEADERS ON CACHE BOOL "")



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


[PATCH] D132550: Changes to code ownership in clang and clang-tidy

2022-08-24 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked an inline comment as done.
aaron.ballman added inline comments.



Comment at: clang-tools-extra/CODE_OWNERS.TXT:8
+beautification by scripts.  The fields are: name (N), email (E), Phabricator
+handle (H), and description (D).
 

xazax.hun wrote:
> As LLVM is officially hosted on GitHub now, I wonder whether a new field 
> should be introduced for GitHub handles. This can be also handy to assign 
> bugs to people, and in the future, add reviewers to PRs. But feel free to 
> ignore this for now.
FWIW, I thought of that as well and I think it's a great idea if/when we switch 
to GitHub PRs. But for the moment, I worry that putting GH handles might 
implicitly encourage people to try filing a GH PR instead of Phab and I didn't 
want new folks to get frustrated by that. But once we're closer to switching 
(or starting to trial GH PR alongside Phab reviews), I definitely think we 
should add GitHub handles here (and if/when we drop Phab, we can drop the phab 
handles at that time).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132550

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


[PATCH] D131979: [clang][UBSan] Fix __builtin_assume_aligned crash

2022-08-24 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added a comment.

In D131979#3743127 , @rjmccall wrote:

> In D131979#3742399 , @yihanaa wrote:
>
>> As far as I know, turning on the -fsanitizer=alignment options when calling 
>> __builtin_assume_aligned in C code, if
>> the 1st arg has volatile qualifier, Clang will emit "call void 
>> @__ubsan_handle_alignment_assumption(...)" in CodeGen,
>> else Clang will emit an warning and ignore "call void 
>> @__ubsan_handle_alignment_assumption(...)". But the same situation in C++, 
>> Clang will generate an error in Sema.
>
> Honestly, that sounds like bad behavior, exactly what you'd get if Sema 
> naively tried to force a conversion to some specific pointer type like 
> `void*` instead of converting it to an r-value and then requiring it to have 
> pointer type.  This is a fairly common bug for builtins that behave as if 
> they were overloaded; the fix is to give the builtin custom type-checking so 
> that it will work correctly with unusual qualifiers like address spaces and 
> `restrict`.  I can walk you through that, but you can start by looking at 
> what `SemaBuiltinAtomicOverloaded` does for its pointer argument.
>
> If we want IRGen to not emit a check for pointers to `volatile`, that's an 
> easy check to do in IRGen if we set the AST up properly in the first place.
>
> John.
>
>> So I think, in order to keep this patch consistent with recent version of 
>> Clang and GCC behavior, when compile C code, Clang
>> should not directly emit an error and exit in Sema, but should check the 1st 
>> arg's volatile qualifier in CodeGen and decide 
>> whether to emit "call void @__ubsan_handle_alignment_assumption(...)".
>>
>> But, I agree to use other ways to replace use getSubExprAsWritten() in 
>> CodeGen to check the 1st arg 'isVolatile', what do you all think about?
>>
>> For more information about UBSan, see 
>> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html and search 
>> 'volatile' on this website.
>>
>> "The null, alignment, object-size, local-bounds, and vptr checks do not 
>> apply to pointers to types with the volatile qualifier."
>> C https://godbolt.org/z/xv35fG14r
>> C++ https://godbolt.org/z/qfje6sErE
>
> Honestly,

I'm sorry I couldn't respond sooner.
Thanks for your reply john, I agree with you, and I'd like to try it if we 
check args in Sema.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131979

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


[PATCH] D132486: SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

2022-08-24 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

@jrtc27 What do you think about this patch with the default flipped? I think 
this is how it should land personally as discussed on discourse.

I have been trying to listen in how people want to handle this and I hope this 
is a good middle ground that we can agree on for 15.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132486

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


[clang] ba57828 - [CUDA][OpenMP] Fix the new driver crashing on multiple device-only outputs

2022-08-24 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-08-24T08:47:55-05:00
New Revision: ba57828e11c52f45420f2027dae0843cf83a57bf

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

LOG: [CUDA][OpenMP] Fix the new driver crashing on multiple device-only outputs

The new driver supports device-only compilation for the offloading
device. The way this is handlded is a little different from the old
offloading driver. The old driver would put all the outputs in the final
action list akin to a linker job. The new driver however generated these
in the middle of the host's job so we instead put them all in a single
offloading action. However, we only handled these kinds of offloading
actions correctly when there was only a single input. When we had
multiple inputs we would instead attempt to get the host job, which
didn't exist, and crash.

This patch simply adds some extra logic to generate the jobs for all
dependencies if there is not host action.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/cuda-bindings.cu
clang/test/Driver/hip-binding.hip

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index d00f08d15ae5..f5b0cb85788b 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -4716,10 +4716,13 @@ void Driver::BuildJobs(Compilation &C) const {
   // we are also generating .o files. So we allow more than one output file in
   // this case as well.
   //
+  // OffloadClass of type TY_Nothing: device-only output will place many 
outputs
+  // into a single offloading action. We should count all inputs to the action
+  // as outputs.
   if (FinalOutput) {
 unsigned NumOutputs = 0;
 unsigned NumIfsOutputs = 0;
-for (const Action *A : C.getActions())
+for (const Action *A : C.getActions()) {
   if (A->getType() != types::TY_Nothing &&
   !(A->getKind() == Action::IfsMergeJobClass ||
 (A->getType() == clang::driver::types::TY_IFS_CPP &&
@@ -4728,6 +4731,10 @@ void Driver::BuildJobs(Compilation &C) const {
 (A->getKind() == Action::BindArchClass && A->getInputs().size() &&
  A->getInputs().front()->getKind() == Action::IfsMergeJobClass)))
 ++NumOutputs;
+  else if (A->getKind() == Action::OffloadClass &&
+   A->getType() == types::TY_Nothing)
+NumOutputs += A->size();
+}
 
 if (NumOutputs > 1) {
   Diag(clang::diag::err_drv_output_argument_with_multiple_files);
@@ -5265,20 +5272,21 @@ InputInfoList Driver::BuildJobsForActionNoCache(
 //  \
 //Device Action 1  ---> OffloadAction -> Device Action 2
 //
-// For a) and b), we just return the job generated for the dependence. For
+// For a) and b), we just return the job generated for the dependences. For
 // c) and d) we override the current action with the host/device dependence
 // if the current toolchain is host/device and set the offload dependences
 // info with the jobs obtained from the device/host dependence(s).
 
-// If there is a single device option, just generate the job for it.
-if (OA->hasSingleDeviceDependence()) {
+// If there is a single device option or has no host action, just generate
+// the job for it.
+if (OA->hasSingleDeviceDependence() || !OA->hasHostDependence()) {
   InputInfoList DevA;
   OA->doOnEachDeviceDependence([&](Action *DepA, const ToolChain *DepTC,
const char *DepBoundArch) {
-DevA =
-BuildJobsForAction(C, DepA, DepTC, DepBoundArch, AtTopLevel,
-   /*MultipleArchs*/ !!DepBoundArch, LinkingOutput,
-   CachedResults, DepA->getOffloadingDeviceKind());
+DevA.append(BuildJobsForAction(C, DepA, DepTC, DepBoundArch, 
AtTopLevel,
+   /*MultipleArchs*/ !!DepBoundArch,
+   LinkingOutput, CachedResults,
+   DepA->getOffloadingDeviceKind()));
   });
   return DevA;
 }

diff  --git a/clang/test/Driver/cuda-bindings.cu 
b/clang/test/Driver/cuda-bindings.cu
index 7115117e79ce..a7aa4c797885 100644
--- a/clang/test/Driver/cuda-bindings.cu
+++ b/clang/test/Driver/cuda-bindings.cu
@@ -146,3 +146,20 @@
 // RUN:--cuda-gpu-arch=sm_52 --cuda-device-only -c -o foo.o %s 2>&1 \
 // RUN: | FileCheck -check-prefix=D_ONLY %s
 // D_ONLY: "foo.o"
+
+//
+// Check to make sure we can generate multiple outputs for device-only
+// compilation and fail with '-o'.
+//
+// RUN: %clang -### -target powerpc64le-ibm-linux-gnu --offload-new-driver 
-ccc-print-bindings \

[PATCH] D132248: [CUDA][OpenMP] Fix the new driver crashing on multiple device-only outputs

2022-08-24 Thread Joseph Huber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGba57828e11c5: [CUDA][OpenMP] Fix the new driver crashing on 
multiple device-only outputs (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132248

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-bindings.cu
  clang/test/Driver/hip-binding.hip

Index: clang/test/Driver/hip-binding.hip
===
--- clang/test/Driver/hip-binding.hip
+++ clang/test/Driver/hip-binding.hip
@@ -51,3 +51,20 @@
 
 // NORDC-NOT: offload bundler
 // NORDC: # "x86_64-unknown-linux-gnu" - "GNU::Linker", inputs: ["{{.*o}}"], output: "a.out"
+
+//
+// Check to make sure we can generate multiple outputs for device-only
+// compilation and fail with '-o'.
+//
+// RUN: %clang -### -target x86_64-linux-gnu --offload-new-driver -ccc-print-bindings \
+// RUN:--offload-arch=gfx90a --offload-arch=gfx908 --offload-device-only -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix=MULTI-D-ONLY %s
+//  MULTI-D-ONLY: # "amdgcn-amd-amdhsa" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[GFX908:.+]]"
+// MULTI-D-ONLY-NEXT: # "amdgcn-amd-amdhsa" - "AMDGCN::Linker", inputs: ["[[GFX908]]"], output: "[[GFX908_OUT:.+]]"
+// MULTI-D-ONLY-NEXT: # "amdgcn-amd-amdhsa" - "clang", inputs: ["[[INPUT]]"], output: "[[GFX90a:.+]]"
+// MULTI-D-ONLY-NEXT: # "amdgcn-amd-amdhsa" - "AMDGCN::Linker", inputs: ["[[GFX90a]]"], output: "[[GFX90a_OUT:.+]]"
+//
+// RUN: %clang -### -target x86_64-linux-gnu --offload-new-driver -ccc-print-bindings \
+// RUN:--offload-arch=gfx90a --offload-arch=gfx908 --offload-device-only -c -o %t %s 2>&1 \
+// RUN: | FileCheck -check-prefix=MULTI-D-ONLY-O %s
+// MULTI-D-ONLY-O: error: cannot specify -o when generating multiple output files
Index: clang/test/Driver/cuda-bindings.cu
===
--- clang/test/Driver/cuda-bindings.cu
+++ clang/test/Driver/cuda-bindings.cu
@@ -146,3 +146,20 @@
 // RUN:--cuda-gpu-arch=sm_52 --cuda-device-only -c -o foo.o %s 2>&1 \
 // RUN: | FileCheck -check-prefix=D_ONLY %s
 // D_ONLY: "foo.o"
+
+//
+// Check to make sure we can generate multiple outputs for device-only
+// compilation and fail with '-o'.
+//
+// RUN: %clang -### -target powerpc64le-ibm-linux-gnu --offload-new-driver -ccc-print-bindings \
+// RUN:--offload-arch=sm_70 --offload-arch=sm_52 --offload-device-only -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix=MULTI-D-ONLY %s
+//  MULTI-D-ONLY: # "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_70:.+]]"
+// MULTI-D-ONLY-NEXT: # "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_70]]"], output: "[[CUBIN_70:.+]]"
+// MULTI-D-ONLY-NEXT: # "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_52:.+]]"
+// MULTI-D-ONLY-NEXT: # "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_52]]"], output: "[[CUBIN_52:.+]]"
+//
+// RUN: %clang -### -target powerpc64le-ibm-linux-gnu --offload-new-driver -ccc-print-bindings \
+// RUN:--offload-arch=sm_70 --offload-arch=sm_52 --offload-device-only -c -o %t %s 2>&1 \
+// RUN: | FileCheck -check-prefix=MULTI-D-ONLY-O %s
+// MULTI-D-ONLY-O: error: cannot specify -o when generating multiple output files
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4716,10 +4716,13 @@
   // we are also generating .o files. So we allow more than one output file in
   // this case as well.
   //
+  // OffloadClass of type TY_Nothing: device-only output will place many outputs
+  // into a single offloading action. We should count all inputs to the action
+  // as outputs.
   if (FinalOutput) {
 unsigned NumOutputs = 0;
 unsigned NumIfsOutputs = 0;
-for (const Action *A : C.getActions())
+for (const Action *A : C.getActions()) {
   if (A->getType() != types::TY_Nothing &&
   !(A->getKind() == Action::IfsMergeJobClass ||
 (A->getType() == clang::driver::types::TY_IFS_CPP &&
@@ -4728,6 +4731,10 @@
 (A->getKind() == Action::BindArchClass && A->getInputs().size() &&
  A->getInputs().front()->getKind() == Action::IfsMergeJobClass)))
 ++NumOutputs;
+  else if (A->getKind() == Action::OffloadClass &&
+   A->getType() == types::TY_Nothing)
+NumOutputs += A->size();
+}
 
 if (NumOutputs > 1) {
   Diag(clang::diag::err_drv_output_argument_with_multiple_files);
@@ -5265,20 +5272,21 @@
 //  \
 //Device Action 1  ---> OffloadAction -> Device Action 2
 //
-// For a) and b), we just return the job generated for the dependence. For
+// For a) and b), we just return the job generated for the dependences. For
 // c) a

[PATCH] D132316: [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are better-suited

2022-08-24 Thread John Ericson via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Ericson2314 marked an inline comment as done.
Closed by commit rGad8c34bc3089: [CMake] Avoid `LLVM_BINARY_DIR` when other 
more specific variable are better… (authored by Ericson2314).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

Files:
  bolt/lib/Target/AArch64/CMakeLists.txt
  bolt/lib/Target/X86/CMakeLists.txt
  bolt/unittests/Core/CMakeLists.txt
  clang/cmake/modules/CMakeLists.txt
  clang/lib/Tooling/CMakeLists.txt
  flang/cmake/modules/CMakeLists.txt
  lld/cmake/modules/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/API/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/AArch64/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/Mips/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/PowerPC/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/X86/CMakeLists.txt
  llvm/tools/llvm-shlib/CMakeLists.txt
  llvm/unittests/Target/ARM/CMakeLists.txt
  llvm/unittests/Target/DirectX/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/AArch64/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/ARM/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
  llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
  mlir/cmake/modules/CMakeLists.txt
  polly/cmake/CMakeLists.txt
  polly/test/CMakeLists.txt

Index: polly/test/CMakeLists.txt
===
--- polly/test/CMakeLists.txt
+++ polly/test/CMakeLists.txt
@@ -46,7 +46,7 @@
 
 set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
 set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}")
-set(LLVM_LIBS_DIR "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}")
+set(LLVM_LIBS_DIR "${LLVM_LIBRARY_DIR}")
 if (CMAKE_LIBRARY_OUTPUT_DIRECTORY)
   set(POLLY_LIB_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
 else()
Index: polly/cmake/CMakeLists.txt
===
--- polly/cmake/CMakeLists.txt
+++ polly/cmake/CMakeLists.txt
@@ -12,7 +12,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 if (CMAKE_CONFIGURATION_TYPES)
   set(POLLY_EXPORTS_FILE_NAME "PollyExports-$>.cmake")
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -15,7 +15,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 get_property(MLIR_EXPORTS GLOBAL PROPERTY MLIR_EXPORTS)
 export(TARGETS ${MLIR_EXPORTS} FILE ${mlir_cmake_builddir}/MLIRTargets.cmake)
Index: llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_mca_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   )
 
 add_llvm_mca_unittest_sources(
Index: llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/PowerPC
-  ${LLVM_BINARY_DIR}/lib/Target/PowerPC
+  ${LLVM_LIBRARY_DIR}/Target/PowerPC
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exe

[PATCH] D122255: Meta directive runtime support

2022-08-24 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: clang/lib/AST/OpenMPClause.cpp:1679
+  OS << ": ";
+}
+

abidmalikwaterloo wrote:
> jdoerfert wrote:
> > I'm assuming we already have a printer for trait selectors, no? Doesn't 
> > `OMPTraitInfo::print` do this already and actually handle scores?
> Looked into the function. `OMPTraitInfo::print` can be used. The function 
> needs to be extended as well to take the other traits as well.
> The function needs to be extended as well to take the other traits as well.

What traits are not handled there?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:7439
+  }
+}
+

abidmalikwaterloo wrote:
> abidmalikwaterloo wrote:
> > jdoerfert wrote:
> > > Why does this perform partial trait matching? We should have code for 
> > > this. Also, the logic for device_arch and vendor (which is most what 
> > > there is), is not what we want. Reuse the existing matching logic instead.
> > Ok. What do you mean by `existing matching logic`? 
> @jdoerfert I agree that the implementation is incomplete in terms of trait 
> matching. It can be completed. However, I am not clear about your comments 
> about the `existing matching logic`.  I checked OMPContext.CPP and other 
> files. There are functions that can be used to match the traits. But, I could 
> not find any existing logic that can be used here.
I mean `getBestVariantMatchForContext` and similar functions in 
`llvm/lib/Frontend/OpenMP/OMPContext.cpp`.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122255

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


[PATCH] D130020: [OpenMP] Deprecate the old driver for OpenMP offloading

2022-08-24 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG, as discussed over many weeks in our calls.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130020

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


[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

2022-08-24 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu updated this revision to Diff 455209.
ChuanqiXu added a comment.

Address comments.


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

https://reviews.llvm.org/D132352

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/Transforms/Scalar/EarlyCSE.cpp
  llvm/lib/Transforms/Scalar/GVN.cpp
  llvm/lib/Transforms/Scalar/NewGVN.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Transforms/Coroutines/coro-readnone-01.ll
  llvm/test/Transforms/Coroutines/coro-readnone-02.ll
  llvm/test/Transforms/Coroutines/coro-readnone-03.ll

Index: llvm/test/Transforms/Coroutines/coro-readnone-03.ll
===
--- /dev/null
+++ llvm/test/Transforms/Coroutines/coro-readnone-03.ll
@@ -0,0 +1,64 @@
+; Tests that the readnone and noread_thread_id function which cross suspend points would be optimized expectedly.
+; RUN: opt < %s -S -passes='default' | FileCheck %s --check-prefixes=CHECK-O3
+; RUN: opt < %s -S -passes='early-cse' | FileCheck %s --check-prefixes=CHECK
+; RUN: opt < %s -S -passes='gvn' | FileCheck %s --check-prefixes=CHECK
+; RUN: opt < %s -S -passes='newgvn' | FileCheck %s --check-prefixes=CHECK
+
+define ptr @f() presplitcoroutine {
+entry:
+  %id = call token @llvm.coro.id(i32 0, ptr null, ptr null, ptr null)
+  %size = call i32 @llvm.coro.size.i32()
+  %alloc = call ptr @malloc(i32 %size)
+  %hdl = call ptr @llvm.coro.begin(token %id, ptr %alloc)
+  %j = call i32 @readnone_func() readnone noread_thread_id
+  %sus_result = call i8 @llvm.coro.suspend(token none, i1 false)
+  switch i8 %sus_result, label %suspend [i8 0, label %resume
+ i8 1, label %cleanup]
+resume:
+  %i = call i32 @readnone_func() readnone noread_thread_id
+  %cmp = icmp eq i32 %i, %j
+  br i1 %cmp, label %same, label %diff
+
+same:
+  call void @print_same()
+  br label %cleanup
+
+diff:
+  call void @print_diff()
+  br label %cleanup
+
+cleanup:
+  %mem = call ptr @llvm.coro.free(token %id, ptr %hdl)
+  call void @free(ptr %mem)
+  br label %suspend
+
+suspend:
+  call i1 @llvm.coro.end(ptr %hdl, i1 0)
+  ret ptr %hdl
+}
+
+; CHECK-O3: define{{.*}}@f.resume(
+; CHECK-O3-NEXT : CoroEnd:
+; CHECK-O3-NEXT :   tail call void @print_same()
+; CHECK-O3-NEXT :   tail call void @free(ptr nonnull %hdl)
+; CHECK-O3-NEXT :   ret void
+
+; CHECK-LABEL: @f(
+; CHECK: resume:
+; CHECK: br i1 true, label %same, label %diff
+
+declare i32 @readnone_func() readnone noread_thread_id
+
+declare void @print_same()
+declare void @print_diff()
+declare ptr @llvm.coro.free(token, ptr)
+declare i32 @llvm.coro.size.i32()
+declare i8  @llvm.coro.suspend(token, i1)
+
+declare token @llvm.coro.id(i32, ptr, ptr, ptr)
+declare i1 @llvm.coro.alloc(token)
+declare ptr @llvm.coro.begin(token, ptr)
+declare i1 @llvm.coro.end(ptr, i1)
+
+declare noalias ptr @malloc(i32)
+declare void @free(ptr)
Index: llvm/test/Transforms/Coroutines/coro-readnone-02.ll
===
--- /dev/null
+++ llvm/test/Transforms/Coroutines/coro-readnone-02.ll
@@ -0,0 +1,81 @@
+; Tests that the readnone function which don't cross suspend points could be optimized expectly after split.
+;
+; RUN: opt < %s -S -passes='default' | FileCheck %s --check-prefixes=CHECK_SPLITTED
+; RUN: opt < %s -S -passes='coro-split,early-cse,simplifycfg' | FileCheck %s --check-prefixes=CHECK_SPLITTED
+; RUN: opt < %s -S -passes='coro-split,gvn,simplifycfg' | FileCheck %s --check-prefixes=CHECK_SPLITTED
+; RUN: opt < %s -S -passes='coro-split,newgvn,simplifycfg' | FileCheck %s --check-prefixes=CHECK_SPLITTED
+; RUN: opt < %s -S -passes='early-cse' | FileCheck %s --check-prefixes=CHECK_UNSPLITTED
+; RUN: opt < %s -S -passes='gvn' | FileCheck %s --check-prefixes=CHECK_UNSPLITTED
+; RUN: opt < %s -S -passes='newgvn' | FileCheck %s --check-prefixes=CHECK_UNSPLITTED
+
+define ptr @f() presplitcoroutine {
+entry:
+  %id = call token @llvm.coro.id(i32 0, ptr null, ptr null, ptr null)
+  %size = call i32 @llvm.coro.size.i32()
+  %alloc = call ptr @malloc(i32 %size)
+  %hdl = call ptr @llvm.coro.begin(token %id, ptr %alloc)
+  %sus_result = call i8 @llvm.coro.suspend(token none, i1 false)
+  switch i8 %sus_result, label %suspend [i8 0, label %resume
+ i8 1, label %cleanup]
+resume:
+  %i = call i32 @readnone_func() readnone
+  ; noop call to break optimization to combine two consecutive readonly calls.
+  call void @nop()
+  %j = call i32 @readnone_func() readnone
+  %cmp = icmp eq i32 %i, %j
+  br i1 %cmp, label %same, label %diff
+
+same:
+  call void @print_same()
+  br label %cleanup
+
+diff:
+  call void @print_diff()
+  br label %cleanup
+
+cleanup:
+  %mem = call ptr @llvm.coro.free(token %id, ptr %hdl)
+  call vo

[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

2022-08-24 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu marked an inline comment as done.
ChuanqiXu added inline comments.



Comment at: llvm/include/llvm/IR/InstrTypes.h:1863
+  /// not access or only reads memory.
+  bool doesNotReadThreadIDNorLivesInPresplitCoroutine() const {
+return doesNoReadThreadID() || !getFunction() ||

rjmccall wrote:
> rjmccall wrote:
> > This is an odd use of "nor".  Maybe take a different approach — 
> > `canReadDifferentThreadIDIfMoved()`?
> Oh, I didn't notice this last night — `canReadDifferentThreadIDIfMoved` has 
> the opposite sense of the old method, so either you need to negate the logic 
> in the method and all its call sites, or you need to rename it something like 
> `cannotReadDifferentThreadIDIfMoved`.
Oh, my bad. I should check that. Thanks for double checking!


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

https://reviews.llvm.org/D132352

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


[PATCH] D132503: Add cxx scope if needed for requires clause.

2022-08-24 Thread Luke Nihlen via Phabricator via cfe-commits
luken-google updated this revision to Diff 455217.
luken-google added a comment.

Fix clang-format errors


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132503

Files:
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp


Index: clang/test/Parser/cxx-concepts-requires-clause.cpp
===
--- clang/test/Parser/cxx-concepts-requires-clause.cpp
+++ clang/test/Parser/cxx-concepts-requires-clause.cpp
@@ -12,6 +12,7 @@
   struct AA;
   enum E : int;
   static int x;
+  static constexpr int z = 16;
 
   template  requires true
   void Mfoo();
@@ -24,6 +25,8 @@
 
   template  requires true
   using MQ = M;
+
+  constexpr int bazz() requires (z == 16);
 };
 
 template  requires (!0)
@@ -56,6 +59,9 @@
 template  requires true
 using Q = A;
 
+template requires (!0)
+constexpr int A::bazz() requires (z == 16) { return z; }
+
 struct C {
   template  requires true
   void Mfoo();
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -289,8 +289,16 @@
 
   LateParsedAttrList LateParsedAttrs(true);
   if (DeclaratorInfo.isFunctionDeclarator()) {
-if (Tok.is(tok::kw_requires))
+if (Tok.is(tok::kw_requires)) {
+  DeclaratorScopeObj DeclScopeObj(*this, DeclaratorInfo.getCXXScopeSpec());
+  if (DeclaratorInfo.getCXXScopeSpec().isValid()) {
+if (Actions.ShouldEnterDeclaratorScope(
+getCurScope(), DeclaratorInfo.getCXXScopeSpec())) {
+  DeclScopeObj.EnterDeclaratorScope();
+}
+  }
   ParseTrailingRequiresClause(DeclaratorInfo);
+}
 
 MaybeParseGNUAttributes(DeclaratorInfo, &LateParsedAttrs);
   }


Index: clang/test/Parser/cxx-concepts-requires-clause.cpp
===
--- clang/test/Parser/cxx-concepts-requires-clause.cpp
+++ clang/test/Parser/cxx-concepts-requires-clause.cpp
@@ -12,6 +12,7 @@
   struct AA;
   enum E : int;
   static int x;
+  static constexpr int z = 16;
 
   template  requires true
   void Mfoo();
@@ -24,6 +25,8 @@
 
   template  requires true
   using MQ = M;
+
+  constexpr int bazz() requires (z == 16);
 };
 
 template  requires (!0)
@@ -56,6 +59,9 @@
 template  requires true
 using Q = A;
 
+template requires (!0)
+constexpr int A::bazz() requires (z == 16) { return z; }
+
 struct C {
   template  requires true
   void Mfoo();
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -289,8 +289,16 @@
 
   LateParsedAttrList LateParsedAttrs(true);
   if (DeclaratorInfo.isFunctionDeclarator()) {
-if (Tok.is(tok::kw_requires))
+if (Tok.is(tok::kw_requires)) {
+  DeclaratorScopeObj DeclScopeObj(*this, DeclaratorInfo.getCXXScopeSpec());
+  if (DeclaratorInfo.getCXXScopeSpec().isValid()) {
+if (Actions.ShouldEnterDeclaratorScope(
+getCurScope(), DeclaratorInfo.getCXXScopeSpec())) {
+  DeclScopeObj.EnterDeclaratorScope();
+}
+  }
   ParseTrailingRequiresClause(DeclaratorInfo);
+}
 
 MaybeParseGNUAttributes(DeclaratorInfo, &LateParsedAttrs);
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130020: [OpenMP] Deprecate the old driver for OpenMP offloading

2022-08-24 Thread Ye Luo via Phabricator via cfe-commits
ye-luo accepted this revision.
ye-luo added a comment.

The new driver remains failing offload to x86 in certain scenarios when linking 
static libraries. Once I link object files directly there is no issue. This not 
worse than old driver that only supports linking object files directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130020

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


[PATCH] D128113: Clang: fix AST representation of expanded template arguments.

2022-08-24 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

In D128113#3744353 , @mizvekov wrote:

> In D128113#3744315 , @alexfh wrote:
>
>> The whole project seems like a great improvement in clang diagnostics, but I 
>> don't yet see how template parameter pack substitution indices fit into the 
>> whole picture. If different type parameters in a parameter pack differ only 
>> by some other type of suraring, would they be distinguishable in the current 
>> state? How do substitution indices affect this?
>
> We need the pack index just as much as the index.
>
> When we are resugaring some type and we find a SubstTemplateParmType, first 
> we try to find a template specialization in the current naming context (ie a 
> nested name specifier) which refers to the same template as the Subst node.
>
> Then we have to rebuild that Subst node using, as the new underlying type, 
> the template argument which appears in the template specialization we found. 
> To find that argument, first we use the index, which already was available in 
> the AST prior to this patch. But in case that index refers to an argument 
> pack, then we need the pack index to be able to find the argument inside that.

I more or less understand the general direction, but it would be interesting to 
look at the specific code that uses this.

The main questions we need to answer here are:

1. is the cost of storing parameter pack substitution indices while building 
AST worth the benefits?
2. is there an alternative solution that would shift the cost to the moment 
when this information is about to be used (when formatting diagnostic, I 
suppose)?
3. is there a good way to make this cost optional (using a flag or somehow 
else)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128113

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


[PATCH] D132568: [clang][Sema] check default argument promotions for printf

2022-08-24 Thread YingChi Long via Phabricator via cfe-commits
inclyc created this revision.
inclyc added a reviewer: aaron.ballman.
Herald added a subscriber: emaste.
Herald added a project: All.
inclyc published this revision for review.
inclyc added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

https://reviews.llvm.org/D132266

This patch seems to ignore this scenario:

  printf("%hhf", [int])

Where we have length modifier `h`, and the argument type is `int`. Causes clang 
to suppress warnings about type mismatches between floats and integers.




Comment at: clang/test/FixIt/format.mm:10
 
   const wchar_t wchar_data = L'a';
   NSLog(@"%C", wchar_data);  // expected-warning{{format specifies type 
'unichar' (aka 'unsigned short') but the argument has type 'wchar_t'}}

The language built-in `wchar_t` will be properly diagnosed.



Comment at: clang/test/SemaObjC/format-strings-objc.m:194
   const wchar_t wchar_data = L'a';
-  NSLog(@"%C", wchar_data);  // expected-warning{{format specifies type 
'unichar' (aka 'unsigned short') but the argument has type 'wchar_t'}}
 }

This `wchar_t` is defined as `typedef __WCHAR_TYPE__ wchar_t;`. Actually it is 
`int` on my machine, I'm not sure if we should still report this warning as 
before, because it is just `int`, not a real `"wchar_t"`.


The main focus of this patch is to make ArgType::matchesType check for
possible default parameter promotions when the argType is not a pointer.
If so, no warning will be given for `int`, `unsigned int` types as
corresponding arguments to %hhd and %hd. However, the usage of %hhd
corresponding to short is relatively rare, and it is more likely to be a
misuse. This patch keeps the original behavior of clang like this as
much as possible, while making it more convenient to consider the
default arguments promotion.

Fixes https://github.com/llvm/llvm-project/issues/57102


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132568

Files:
  clang/include/clang/AST/FormatString.h
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/FixIt/format.m
  clang/test/FixIt/format.mm
  clang/test/Sema/format-strings-freebsd.c
  clang/test/Sema/format-strings-scanf.c
  clang/test/Sema/format-strings.c
  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
@@ -80,7 +80,7 @@
 
 //  - Catch use of long long with int arguments.
 void rdar_7068334(void) {
-  long long test = 500;  
+  long long test = 500;
   printf("%i ",test); // expected-warning{{format specifies type 'int' but the argument has type 'long long'}}
   NSLog(@"%i ",test); // expected-warning{{format specifies type 'int' but the argument has type 'long long'}}
   CFStringCreateWithFormat(CFSTR("%i"),test); // expected-warning{{format specifies type 'int' but the argument has type 'long long'}}
@@ -191,7 +191,7 @@
   NSLog(@"%C", data);  // no-warning
 
   const wchar_t wchar_data = L'a';
-  NSLog(@"%C", wchar_data);  // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'wchar_t'}}
+  NSLog(@"%C", wchar_data);  // no-warning
 }
 
 // Test that %@ works with toll-free bridging ().
@@ -273,7 +273,7 @@
 
 void testUnicode(void) {
   NSLog(@"%C", 0x2022); // no-warning
-  NSLog(@"%C", 0x202200); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'int'}}
+  NSLog(@"%C", 0x202200); // no-warning
 }
 
 // Test Objective-C modifier flags.
Index: clang/test/Sema/format-strings.c
===
--- clang/test/Sema/format-strings.c
+++ clang/test/Sema/format-strings.c
@@ -830,3 +830,28 @@
   printf_arg2("foo", "%s string %i\n", "aaa", 123);
   printf_arg2("%s string\n", "foo", "bar"); // expected-warning{{data argument not used by format string}}
 }
+
+void test_promotion(void) {
+  // Default argument promotions for *printf in N2562
+  // https://github.com/llvm/llvm-project/issues/57102
+  // N2562: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf
+  int i;
+  signed char sc;
+  unsigned char uc;
+  char c;
+
+  printf("%hhd %hd %d %hhd %hd %d", i, i, i, sc, sc, sc); // no-warning
+  printf("%hhd %hd %d %hhd %hd %d", uc, uc, uc, c, c, c); // no-warning
+
+  printf("%ld", i); // expected-warning{{format specifies type 'long' but the argument has type 'int'}}
+  printf("%lld", i); // expected-warning{{format specifies type 'long long' but the argument has type 'int'}}
+  printf("%ld", sc); // expected-warning{{format specifies type 'long' but the argument has type 'signed char'}}
+  printf("%lld", sc); // expected-warning{{format specifies type 'long long' but the argument has type 'signed char'}}
+  printf("%ld", uc); // expected-warning{{format specifies typ

[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

I'd try compiling with `clang -g2` to see the effects of this patch on the 
debug info in the IR


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D130020: [OpenMP] Deprecate the old driver for OpenMP offloading

2022-08-24 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.

This is "remove" instead of "deprecate"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130020

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


[PATCH] D132316: [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are better-suited

2022-08-24 Thread John Ericson via Phabricator via cfe-commits
Ericson2314 added a comment.

https://lab.llvm.org/buildbot#builders/13/builds/24958 I am worried this 
failure is not spurious?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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


[PATCH] D130020: [OpenMP] Deprecate the old driver for OpenMP offloading

2022-08-24 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D130020#3746076 , @MaskRay wrote:

> This is "remove" instead of "deprecate"?

Yes, "remove" is probably more appropriate as this completely removes support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130020

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


[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D128830#3745031 , @Michael137 
wrote:

> FYI, this broke the LLDB build bot: 
> https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/46324/execution/node/74/log/
>
> Looks like we're testing that inlined unused parameters display correctly...
>
>   AssertionError: '(void *) unused1 =  optimized out>' not found in '(void *) unused1 = 0x00016fdff4d0\n'
>
> But with this patch DWARF contains this extra entry for the unused parameter:
>
>   0x0045: DW_TAG_formal_parameter 
> 
> DW_AT_location(0x:
> 
>[0x00013f1c, 0x00013f20): DW_OP_reg0 
> W0
>[0x00013f20, 0x00013f24): 
> DW_OP_entry_value(DW_OP_reg0 W0), DW_OP_stack_value) 
> DW_AT_abstract_origin (0x0067 "unused1")
>
> whereas previously it was,
>
>   0x0045: DW_TAG_formal_parameter   
> DW_AT_abstract_origin (0x0061 "unused1")

Based on that debug info it looks like the patch might've improved things - the 
'previous' description has no location, the new one has a location (if it's 
correct - is there evidence it's incorrect?)

What was the expected behavior of the test? What's the new behavior? Oh, I can 
read the assertion now.

The assertion was that there is no location - but now there is a location. That 
looks like a good thing?

> Maybe a flaw in the test? Any idea if this is a debug-info regression?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D128830: [Pipelines] Introduce DAE after ArgumentPromotion

2022-08-24 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl added a comment.

I think we can "fix" the test with the following patch:

  diff --git a/lldb/test/API/functionalities/unused-inlined-parameters/main.c 
b/lldb/test/API/functionalities/unused-inlined-parameters/main.c
  index f2ef5dcc213d..9b9f95f6c946 100644
  --- a/lldb/test/API/functionalities/unused-inlined-parameters/main.c
  +++ b/lldb/test/API/functionalities/unused-inlined-parameters/main.c
  @@ -7,6 +7,7 @@ __attribute__((always_inline)) void f(void *unused1, int 
used, int unused2) {
   }
   
   int main(int argc, char **argv) {
  -  f(argv, 42, 1);
  +  char *undefined;
  +  f(undefined, 42, 1);
 return 0;
  -}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128830

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


[PATCH] D132316: [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are better-suited

2022-08-24 Thread Sebastian Neubauer via Phabricator via cfe-commits
sebastian-ne added a comment.

The build afterwards succeeded again. Seems like every ~20th build on that 
windows machine fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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


[PATCH] D108211: Emit sizeof/alignof values as notes when a static_assert fails

2022-08-24 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson updated this revision to Diff 455258.
arichardson marked 2 inline comments as done.
arichardson added a comment.
Herald added a project: All.

rebase and address feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108211

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CXX/dcl.decl/dcl.meaning/dcl.array/p3.cpp
  clang/test/Parser/objc-static-assert.mm
  clang/test/Sema/static-assert.c
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/static-assert-cxx17.cpp
  clang/test/SemaCXX/static-assert.cpp
  clang/test/SemaTemplate/overload-candidates.cpp

Index: clang/test/SemaTemplate/overload-candidates.cpp
===
--- clang/test/SemaTemplate/overload-candidates.cpp
+++ clang/test/SemaTemplate/overload-candidates.cpp
@@ -62,6 +62,8 @@
 
 template struct NonTemplateFunction {
   typename boost::enable_if::type f(); // expected-error{{failed requirement 'sizeof(char) == 4'; 'enable_if' cannot be used to disable this declaration}}
+  // expected-note@-1{{expression evaluates to '1 == 4'}}
+  // expected-note@-2{{with 'sizeof(char)' equal to 1}}
 };
 NonTemplateFunction NTFC; // expected-note{{here}}
 
Index: clang/test/SemaCXX/static-assert.cpp
===
--- clang/test/SemaCXX/static-assert.cpp
+++ clang/test/SemaCXX/static-assert.cpp
@@ -23,7 +23,9 @@
 
 template struct S {
 static_assert(sizeof(T) > sizeof(char), "Type not big enough!"); // expected-error {{static assertion failed due to requirement 'sizeof(char) > sizeof(char)': Type not big enough!}} \
- // expected-note {{1 > 1}}
+ // expected-note {{1 > 1}} \
+ // expected-note {{with 'sizeof(char)' equal to 1}} \
+ // expected-note {{with 'sizeof(char)' equal to 1}}
 };
 
 S s1; // expected-note {{in instantiation of template class 'S' requested here}}
@@ -264,3 +266,30 @@
 
 
 }
+
+struct IntAndPointer {
+  int i;
+  void *p;
+};
+static_assert(sizeof(IntAndPointer) == 4, "message");
+// expected-error@-1{{static assertion failed}} \
+// expected-note@-1{{expression evaluates to '16 == 4'}} \
+// expected-note@-1{{with 'sizeof(IntAndPointer)' equal to 16}}
+static_assert(alignof(IntAndPointer) == 4, "message");
+// expected-error@-1{{static assertion failed}} \
+// expected-note@-1{{expression evaluates to '8 == 4'}} \
+// expected-note@-1{{with 'alignof(IntAndPointer)' equal to 8}}
+static_assert(alignof(IntAndPointer) == sizeof(IntAndPointer), "message");
+// expected-error@-1{{static assertion failed}} \
+// expected-note@-1{{expression evaluates to '8 == 16'}} \
+// expected-note@-1{{with 'alignof(IntAndPointer)' equal to 8}} \
+// expected-note@-1{{with 'sizeof(IntAndPointer)' equal to 16}}
+static_assert(alignof(IntAndPointer) + sizeof(int) == sizeof(IntAndPointer), "message");
+// expected-error@-1{{static assertion failed}} \
+// expected-note@-1{{expression evaluates to '12 == 16'}} \
+// expected-note@-1{{with 'alignof(IntAndPointer)' equal to 8}} \
+// expected-note@-1{{with 'sizeof(int)' equal to 4}} \
+// expected-note@-1{{with 'sizeof(IntAndPointer)' equal to 16}}
+/// Should not print the sizeof(int) value here since it's not evaluated.
+static_assert(std::is_same::value, "message");
+// expected-error@-1{{static assertion failed}}
Index: clang/test/SemaCXX/static-assert-cxx17.cpp
===
--- clang/test/SemaCXX/static-assert-cxx17.cpp
+++ clang/test/SemaCXX/static-assert-cxx17.cpp
@@ -89,7 +89,8 @@
   // expected-error@-1{{static assertion failed due to requirement 'int(0)'}}
   static_assert(sizeof(X) == 0);
   // expected-error@-1{{static assertion failed due to requirement 'sizeof(X) == 0'}} \
-  // expected-note@-1 {{evaluates to '8 == 0'}}
+  // expected-note@-1 {{evaluates to '8 == 0'}} \
+  // expected-note@-1 {{with 'sizeof(X)' equal to 8}}
   static_assert((const X *)nullptr);
   // expected-error@-1{{static assertion failed due to requirement '(const X *)nullptr'}}
   static_assert(static_cast *>(nullptr));
@@ -98,7 +99,8 @@
   // expected-error@-1{{static assertion failed due to requirement '(const X[0]){} == nullptr'}}
   static_assert(sizeof(X().X::~X())>) == 0);
   // expected-error@-1{{static assertion failed due to requirement 'sizeof(X) == 0'}} \
-  // expected-note@-1 {{evaluates to '8 == 0'}}
+  // expected-note@-1 {{evaluates to '8 == 0'}} \
+  // expected-note@-1 {{with 'sizeof(X)' equal to 8}}
   static_assert(constexpr_return_false(

[PATCH] D108211: Emit sizeof/alignof values as notes when a static_assert fails

2022-08-24 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added a reviewer: tbaeder.
arichardson added a comment.

This is less useful now that 09117b21890c652994f7ada0229d309b35b44259 
 / D130894 
 has landed, but it might still be worth 
including (e.g. for expressions that include multiple sizeof() values?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108211

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


[PATCH] D131718: [HLSL] Add abs library function

2022-08-24 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 added inline comments.



Comment at: clang/test/CodeGenHLSL/builtins/abs.hlsl:20
+
+// CHECK: define noundef double @"?abs_double@@YANN@Z"(
+// CHECK: call double @llvm.fabs.f64(double %0)

Is there a reason why we don't check the function parameter here, but we do 
check for function parameters when actually calling the builtin intrinsic on 
the next call line? 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131718

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


[PATCH] D131718: [HLSL] Add abs library function

2022-08-24 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 added inline comments.



Comment at: clang/include/clang/Driver/Options.td:6130
   MarshallingInfoFlag>,
   ImpliedByAnyOf<[fnative_half_arguments_and_returns.KeyPath]>;
 def fdefault_calling_conv_EQ : Joined<["-"], "fdefault-calling-conv=">,

In Clang.cpp, you removed 
CmdArgs.push_back("-fallow-half-arguments-and-returns");
But here, you add an extra condition to imply fnative-half-arguments-and-returns
Wouldn't this change the behavior? or is it really alright for the definition  
below, fallow_half_arguments_and_returns , to be missing hlsl.KeyPath in the 
implication list?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131718

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


[PATCH] D132316: [CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are better-suited

2022-08-24 Thread John Ericson via Phabricator via cfe-commits
Ericson2314 added a comment.

Whew, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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


[PATCH] D131718: [HLSL] Add abs library function

2022-08-24 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/include/clang/Driver/Options.td:6130
   MarshallingInfoFlag>,
   ImpliedByAnyOf<[fnative_half_arguments_and_returns.KeyPath]>;
 def fdefault_calling_conv_EQ : Joined<["-"], "fdefault-calling-conv=">,

bob80905 wrote:
> In Clang.cpp, you removed 
> CmdArgs.push_back("-fallow-half-arguments-and-returns");
> But here, you add an extra condition to imply 
> fnative-half-arguments-and-returns
> Wouldn't this change the behavior? or is it really alright for the definition 
>  below, fallow_half_arguments_and_returns , to be missing hlsl.KeyPath in the 
> implication list?
The big issue with the change in Clang.cpp is that it only works if you invoke 
clang-dxc, not if you invoke clang directly with an hlsl source. That has the 
undesirable effect of making clang HLSL support only work through the clang-dxc 
driver, which isn't what we want.

There is also a subtle difference between native and non-native half arguments 
and returns, where non-native half arguments and returns are actually passed as 
larger float types. Which also isn't correct for HLSL.

This change follows how OpenCL works, and enables 
`-fnative-half-arguments-and-returns` whenever the HLSL language mode is 
enabled, and that option also implies `-fhalf-arguments-and-returns`.

The big functional change here is that you don't need to ever manually pass 
these flags to clang if your language is HLSL, so you can use any clang driver 
entry and get the correct behavior for the language.



Comment at: clang/test/CodeGenHLSL/builtins/abs.hlsl:20
+
+// CHECK: define noundef double @"?abs_double@@YANN@Z"(
+// CHECK: call double @llvm.fabs.f64(double %0)

bob80905 wrote:
> Is there a reason why we don't check the function parameter here, but we do 
> check for function parameters when actually calling the builtin intrinsic on 
> the next call line? 
> 
The check lines on the function declarations are really just to make sure that 
the next match occurs in the function body. The real test is to make sure the 
body gets generated correctly.

That said, matching the full mangled name has the same impact as matching the 
parameters too because the name mangling encodes the parameters too. The `NN` 
specifies the return and first argument parameters are doubles.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131718

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


[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

2022-08-24 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D126907#3740249 , @erichkeane 
wrote:

> FWIW, while I wasn't able to reproduce the problem that @Mordante reported, I 
> found that the test suite as given has a large number of asserts in debug 
> mode while trying to compare parameter-mappings during constraint 
> normalization(assert is `clang-15: 
> /iusers/ekeane1/workspaces/delayed-concepts/clang/lib/AST/ASTContext.cpp:4753:
>  clang::QualType clang::ASTContext::getSubstTemplateTypeParmType(const 
> clang::TemplateTypeParmType*, clang::QualType, llvm::Optional) 
> const: Assertion ```Replacement.isCanonical() && "replacement types must 
> always be canonical"' failed.```).`
>
> One Reproducer is:
>
>   #pragma clang module import std.array
>   template
>   struct iter_value_or_void { using type = void; };
> 
>   template
>   struct iter_value_or_void {
>   using type = std::iter_value_t;
>
> BUT debugging seems to show a lot of 'imported' symbols that I'm not 
> particularly sure how they work, so I suspect they are coming from the 
> clang-module-import.
>
> So I'm going to have to try to figure out what is going on here with the 
> clang modules.

Fixing the assert was pretty easy, and fixing it revealed the same 8 failures 
from the buildbot above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126907

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


[clang] 74af56c - [Clang] Avoid using unwind library in the MSVC environment

2022-08-24 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2022-08-24T17:34:47Z
New Revision: 74af56c1c342038d385134add13cd2a7db7f0a70

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

LOG: [Clang] Avoid using unwind library in the MSVC environment

We're seeing the following warnings with --rtlib=compiler-rt:

  lld-link: warning: ignoring unknown argument '--as-needed'
  lld-link: warning: ignoring unknown argument '-lunwind'
  lld-link: warning: ignoring unknown argument '--no-as-needed'

MSVC doesn't use the unwind library, so just omit it.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/compiler-rt-unwind.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index b48dd40760ccd..3b084dfdbfa2c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1529,7 +1529,7 @@ static void AddUnwindLibrary(const ToolChain &TC, const 
Driver &D,
   // Targets that don't use unwind libraries.
   if ((TC.getTriple().isAndroid() && UNW == ToolChain::UNW_Libgcc) ||
   TC.getTriple().isOSIAMCU() || TC.getTriple().isOSBinFormatWasm() ||
-  UNW == ToolChain::UNW_None)
+  TC.getTriple().isWindowsMSVCEnvironment() || UNW == ToolChain::UNW_None)
 return;
 
   LibGccType LGT = getLibGccType(TC, D, Args);

diff  --git a/clang/test/Driver/compiler-rt-unwind.c 
b/clang/test/Driver/compiler-rt-unwind.c
index c5f63fba065e0..af36382a9b58a 100644
--- a/clang/test/Driver/compiler-rt-unwind.c
+++ b/clang/test/Driver/compiler-rt-unwind.c
@@ -88,6 +88,13 @@
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires 
--unwindlib=libgcc"
 //
 // RUN: %clang -### %s 2>&1 \
+// RUN: --target=x86_64-pc-windows-msvc -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN:   | FileCheck 
--check-prefix=MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT %s
+// MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: 
"{{.*}}clang_rt.builtins-x86_64.lib"
+// MSVC-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT-NOT: "{{.*}}unwind.lib"
+//
+// RUN: %clang -### %s 2>&1 \
 // RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
 // RUN: -shared-libgcc \
 // RUN: --gcc-toolchain="" \



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


[PATCH] D132440: [Clang] Avoid using unwind library in the MSVC environment

2022-08-24 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

In D132440#3744960 , @mstorsjo wrote:

>> This reverts commit eca29d4a37b8d1c93fe99be6289a60bb11cf789d 
>>  since 
>> the test fails in the per-target-runtime-dir layout.
>
> Does that mean that the testcase ended up looking at other libraries next to 
> clang, in the build dir where the tests are run? That's rather annoying... I 
> guess it could be fixed by adding `-resource-dir` in the testcase? (And 
> ideally in the future, by making a harder switch between the two runtime 
> install layouts in clang, as discussed on Discourse.)

Yes, that's the issue, I added `-resource-dir` which is the solution we use in 
other tests as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132440

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


[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

2022-08-24 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Seems okay to me, but like I said, it'd be good to get AA eyes on it.


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

https://reviews.llvm.org/D132352

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


[PATCH] D132531: [AArch64] Reserve more physical registers

2022-08-24 Thread Guozhi Wei via Phabricator via cfe-commits
Carrot added a comment.

I want to reserve most of the physical registers, so only a small number of 
registers can be used by register allocator. Then I can write small test cases 
to simulate high register pressure situation, it will be much easier to test 
and debug register allocation changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132531

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


[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

2022-08-24 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

In D126907#3740536 , @erichkeane 
wrote:

> For example, this enable-modules flag isn't covered by my local check-cxx, 
> which I went out of my way to run on this patch locally.

Unfortunately there are a lot of different options and combination of options 
to test libc++.
So it's indeed not possible to test all options with once check-cxx invocation.

In D126907#3746408 , @erichkeane 
wrote:

> Fixing the assert was pretty easy, and fixing it revealed the same 8 failures 
> from the buildbot above.

Great to hear you can reproduce the issue!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126907

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


[PATCH] D131683: Diagnosing the Future Keywords

2022-08-24 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.def:384
+C2X_KEYWORD(true, BOOLSUPPORT)
+C2X_KEYWORD(remove_quals, KEYC2X)
+

Codesbyusman wrote:
> aaron.ballman wrote:
> > This is technically correct, but I think we should remove it until we go to 
> > implement that paper instead of introducing the keyword out of thin air 
> > here.
> > 
> > Btw, I think that should be `, 0` instead of `, KEYC2X` given the use of 
> > `C2X_KEYWORD`, right?
> > This is technically correct, but I think we should remove it until we go to 
> > implement that paper instead of introducing the keyword out of thin air 
> > here.
> > 
> > Btw, I think that should be `, 0` instead of `, KEYC2X` given the use of 
> > `C2X_KEYWORD`, right?
> 
> Don't know much but what I understand that this is a keyword but not 
> published officially by language but will be in future. so I think will be 
> good to remove it or can add Fixme?
> Don't know much but what I understand that this is a keyword but not 
> published officially by language but will be in future. so I think will be 
> good to remove it or can add Fixme?

Close -- the issue is more that we have no support for `remove_quals` in the 
compiler and it's easier for someone to add the keyword when implementing that 
feature. So you should remove the line entirely -- someone else will add it in 
the future.



Comment at: clang/lib/Basic/IdentifierTable.cpp:852
+
+//===--===//
+// IdentifierTable Implementation

erichkeane wrote:
> This comment block shouldn't be here at all.
It looks like you might have missed this comment.



Comment at: clang/lib/Basic/IdentifierTable.cpp:863
+
+  // Getting the flag value. i.e bool keyword passing it name to the function
+  // and will return the flag value that which keys are used then will use for

erichkeane wrote:
> This comment doesn't really make any sense here.  I dont understand what 
> you're trying to say.
It looks like you might have missed this comment (it's about `Checking the 
Language mode and then for the diagnostics.`)



Comment at: clang/test/Parser/static_assert.c:1
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -verify=c2x %s
-// RUN: %clang_cc1 -fsyntax-only -std=c2x -DTEST_SPELLING -fms-compatibility 
-verify=c2x-ms %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -Weverything 
-verify=c17 %s
+// RUN: %clang_cc1 -fsyntax-only -std=c17 -DTEST_SPELLING -fms-compatibility 
-verify=c17-ms %s

Why did you add `-Weverything` here? That seems odd.



Comment at: clang/test/Parser/static_assert.c:23
+  // c17-error {{type specifier missing, defaults to 
'int'; ISO C99 and later do not support implicit int}} \
+  // c17-warning {{ function declaration without a 
prototype is deprecated in all versions of C}} \
+  // c17-ms-warning {{use of 'static_assert' without 
inclusion of  is a Microsoft extension}} 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131683

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


[clang] 002bfdd - [clang][modules] Track affecting modules

2022-08-24 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2022-08-24T11:09:50-07:00
New Revision: 002bfdd6b119e3543415971fbb219768fd96f86f

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

LOG: [clang][modules] Track affecting modules

When compiling a module, its semantics and Clang's behavior are affected by 
other modules. These modules are typically the **imported** ones. However, 
during implicit build, some modules end up being compiled and read without 
being actually imported. This patch starts tracking such modules and 
serializing them into `.pcm` files. This enables the dependency scanner to 
construct explicit compilations that mimic implicit build.

Reviewed By: benlangmuir

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

Added: 
clang/test/ClangScanDeps/modules-incomplete-umbrella.c

Modified: 
clang/include/clang/Basic/Module.h
clang/include/clang/Lex/ModuleLoader.h
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Serialization/ASTBitCodes.h
clang/include/clang/Serialization/ASTReader.h
clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Lex/HeaderSearch.cpp
clang/lib/Lex/PPDirectives.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Module.h 
b/clang/include/clang/Basic/Module.h
index 8ef1c5991c56e..a2309f5d7faeb 100644
--- a/clang/include/clang/Basic/Module.h
+++ b/clang/include/clang/Basic/Module.h
@@ -345,6 +345,10 @@ class Module {
   /// module depends.
   llvm::SmallSetVector Imports;
 
+  /// The set of top-level modules that affected the compilation of this 
module,
+  /// but were not imported.
+  llvm::SmallSetVector AffectingModules;
+
   /// Describes an exported module.
   ///
   /// The pointer is the module being re-exported, while the bit will be true

diff  --git a/clang/include/clang/Lex/ModuleLoader.h 
b/clang/include/clang/Lex/ModuleLoader.h
index bf044e0e5f506..f880a9091a2ed 100644
--- a/clang/include/clang/Lex/ModuleLoader.h
+++ b/clang/include/clang/Lex/ModuleLoader.h
@@ -51,6 +51,11 @@ class ModuleLoadResult {
   ModuleLoadResult() = default;
   ModuleLoadResult(Module *M) : Storage(M, Normal) {}
   ModuleLoadResult(LoadResultKind Kind) : Storage(nullptr, Kind) {}
+  ModuleLoadResult(Module *M, LoadResultKind Kind) : Storage(M, Kind) {}
+
+  operator bool() const {
+return Storage.getInt() == Normal && Storage.getPointer();
+  }
 
   operator Module *() const { return Storage.getPointer(); }
 

diff  --git a/clang/include/clang/Lex/Preprocessor.h 
b/clang/include/clang/Lex/Preprocessor.h
index 6e2517632717f..5f54a44e604e2 100644
--- a/clang/include/clang/Lex/Preprocessor.h
+++ b/clang/include/clang/Lex/Preprocessor.h
@@ -860,6 +860,10 @@ class Preprocessor {
   /// The files that have been included.
   IncludedFilesSet IncludedFiles;
 
+  /// The set of top-level modules that affected preprocessing, but were not
+  /// imported.
+  llvm::SmallSetVector AffectingModules;
+
   /// The set of known macros exported from modules.
   llvm::FoldingSet ModuleMacros;
 
@@ -1331,6 +1335,12 @@ class Preprocessor {
 
   /// \}
 
+  /// Get the set of top-level modules that affected preprocessing, but were 
not
+  /// imported.
+  const llvm::SmallSetVector &getAffectingModules() const {
+return AffectingModules;
+  }
+
   /// Mark the file as included.
   /// Returns true if this is the first time the file was included.
   bool markIncluded(const FileEntry *File) {

diff  --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 297af86d0203d..8b0d2c0de1fe5 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -829,6 +829,9 @@ enum SubmoduleRecordTypes {
   /// Specifies the name of the module that will eventually
   /// re-export the entities in this module.
   SUBMODULE_EXPORT_AS = 17,
+
+  /// Specifies affecting modules that were not imported.
+  SUBMODULE_AFFECTING_MODULES = 18,
 };
 
 /// Record types used within a comments block.

diff  --git a/clang/include/clang/Serialization/ASTReader.h 
b/clang/include/clang/Serialization/ASTReader.h
index 25b14f4dfa422..19a18a2ef4030 100644
--- a/clang/include/clang/Serialization/ASTReader.h
+++ b/clang/include/clang/Serialization/ASTReader.h
@@ -689,7 +689,7 @@ class ASTReader
 Module *Mod;
 
 /// The kind of module reference.
-enum { Import, Export, Conflict } Kind;
+enum { Import, Export, Conflict, Affecting } Kind;
 
 /// The local ID of the module that is being exported.
 unsigned ID;

diff  --git 
a/clang/include/

[PATCH] D132430: [clang][modules] Track affecting modules

2022-08-24 Thread Jan Svoboda 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 rG002bfdd6b119: [clang][modules] Track affecting modules 
(authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D132430?vs=454979&id=455298#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132430

Files:
  clang/include/clang/Basic/Module.h
  clang/include/clang/Lex/ModuleLoader.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/modules-incomplete-umbrella.c

Index: clang/test/ClangScanDeps/modules-incomplete-umbrella.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-incomplete-umbrella.c
@@ -0,0 +1,202 @@
+// This test checks that modules loaded during compilation (but not imported)
+// are still reported as dependencies.
+
+// RUN: rm -rf %t && mkdir %t
+// RUN: split-file %s %t
+
+//--- frameworks/FW.framework/Modules/module.modulemap
+framework module FW {
+  umbrella header "FW.h"
+  module * { export * }
+}
+//--- frameworks/FW.framework/Headers/FW.h
+//--- frameworks/FW.framework/Modules/module.private.modulemap
+framework module FW_Private {
+  umbrella header "FW_Private.h"
+  module * { export * }
+}
+//--- frameworks/FW.framework/PrivateHeaders/FW_Private.h
+#include "One.h"
+//--- frameworks/FW.framework/PrivateHeaders/One.h
+//--- frameworks/FW.framework/PrivateHeaders/Two.h
+
+// Let's check we report the non-imported modular dependencies for a translation unit.
+
+//--- from_tu.cdb.json.template
+[{
+  "file": "DIR/from_tu.m",
+  "directory": "DIR",
+  "command": "clang -fmodules -fmodules-cache-path=DIR/cache -iframework DIR/frameworks -c DIR/from_tu.m -o DIR/from_tu.o"
+}]
+//--- from_tu.m
+#include "FW/FW.h"
+#include "FW/Two.h"
+
+// RUN: sed -e "s|DIR|%/t|g" %t/from_tu.cdb.json.template > %t/from_tu.cdb.json
+// RUN: clang-scan-deps -compilation-database %t/from_tu.cdb.json -format experimental-full > %t/from_tu_result.json
+// RUN: cat %t/from_tu_result.json | sed 's:\?:/:g' | FileCheck %s -DPREFIX=%/t --check-prefixes=CHECK_TU
+// CHECK_TU:  {
+// CHECK_TU-NEXT:   "modules": [
+// CHECK_TU-NEXT: {
+// CHECK_TU-NEXT:   "clang-module-deps": [],
+// CHECK_TU-NEXT:   "clang-modulemap-file": "[[PREFIX]]/frameworks/FW.framework/Modules/module.modulemap",
+// CHECK_TU-NEXT:   "command-line": [
+// CHECK_TU:],
+// CHECK_TU-NEXT:   "context-hash": "{{.*}}",
+// CHECK_TU-NEXT:   "file-deps": [
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/Headers/FW.h",
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/Modules/module.modulemap",
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/Modules/module.private.modulemap"
+// CHECK_TU-NEXT:   ],
+// CHECK_TU-NEXT:   "name": "FW"
+// CHECK_TU-NEXT: },
+// CHECK_TU-NEXT: {
+// CHECK_TU-NEXT:   "clang-module-deps": [],
+// CHECK_TU-NEXT:   "clang-modulemap-file": "[[PREFIX]]/frameworks/FW.framework/Modules/module.private.modulemap",
+// CHECK_TU-NEXT:   "command-line": [
+// CHECK_TU:],
+// CHECK_TU-NEXT:   "context-hash": "{{.*}}",
+// CHECK_TU-NEXT:   "file-deps": [
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/Modules/module.modulemap",
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/Modules/module.private.modulemap",
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/PrivateHeaders/FW_Private.h",
+// CHECK_TU-NEXT: "[[PREFIX]]/frameworks/FW.framework/PrivateHeaders/One.h"
+// CHECK_TU-NEXT:   ],
+// CHECK_TU-NEXT:   "name": "FW_Private"
+// CHECK_TU-NEXT: }
+// CHECK_TU-NEXT:   ],
+// CHECK_TU-NEXT:   "translation-units": [
+// CHECK_TU-NEXT: {
+// CHECK_TU-NEXT:   "clang-context-hash": "{{.*}}",
+// CHECK_TU-NEXT:   "clang-module-deps": [
+// CHECK_TU-NEXT: {
+// CHECK_TU-NEXT:   "context-hash": "{{.*}}",
+// CHECK_TU-NEXT:   "module-name": "FW"
+// CHECK_TU-NEXT: },
+// CHECK_TU-NEXT: {
+// CHECK_TU-NEXT:   "context-hash": "{{.*}}",
+// CHECK_TU-NEXT:   "module-name": "FW_Private"
+// CHECK_TU-NEXT: }
+// CHECK_TU-NEXT:   ],
+// CHECK_TU-NEXT:   "command-line": [
+// CHECK_TU:  "-fmodule-file={{.*}}/FW-{{.*}}.pcm"
+// CHECK_TU:  "-fmodule-file={{.*}}/FW_Private-{{.*}}.pcm"
+// CHECK_TU:  

[PATCH] D132502: [clang][modules] Consider M affecting after mapping M.Private to M_Private

2022-08-24 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:2017
 // migrate off of Foo.Private syntax.
-if (!Sub && PP->getLangOpts().ImplicitModules && Name == "Private" &&
-Module == Module->getTopLevelModule()) {
+if (!Sub && Name == "Private" && Module == Module->getTopLevelModule()) {
   SmallString<128> PrivateModule(Module->Name);

Not sure if this is a good idea, but have you considered having the scanner 
provide the module with `Foo.Private=` syntax instead? It would be nice to keep 
this hack contained to implicit builds if we can.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132502

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


[PATCH] D132568: [clang][Sema] check default argument promotions for printf

2022-08-24 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a subscriber: nickdesaulniers.
aaron.ballman added a comment.

Thank you for the patch, but it'd be really helpful to me as a reviewer if you 
and @nickdesaulniers could coordinate so there's only one patch trying to 
address #57102 instead of two competing patches (I'm happy to review whichever 
patch comes out). From a quick look over the test case changes, this patch 
looks like it's more in line with how I'd expect to resolve that issue compared 
to D132266 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132568

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


[PATCH] D132531: [AArch64] Reserve more physical registers

2022-08-24 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

> A reserved physical register doesn't mean it can't be used by 
> compiler/linker, it just means it can't be used by register allocator, see 
> the comments in TargetRegisterInfo::getReservedRegs().

The target feature to "reserve" a register is meant to be "don't use this 
register for anything".  For some registers, making sure the register isn't 
used by the register allocator is sufficient because the compiler/linker won't 
use them in any other way... but if the compiler uses a register outside 
register allocation, that doesn't work.

If you want a target feature to simulate high register pressure without any 
expectation that the resulting code actually works, please add a separate 
"regalloc-test-reserve-all-regs" feature or something like that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132531

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


[PATCH] D132538: [AArch64] Filter out invalid code model in frontend.

2022-08-24 Thread Jessica Paquette via Phabricator via cfe-commits
paquette accepted this revision.
paquette added a comment.
This revision is now accepted and ready to land.

Looks reasonable to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132538

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


[PATCH] D132538: [AArch64] Filter out invalid code model in frontend.

2022-08-24 Thread Jessica Paquette via Phabricator via cfe-commits
paquette added inline comments.



Comment at: clang/test/Driver/mcmodel.c:9
 // RUN: not %clang -c -mcmodel=lager %s 2>&1 | FileCheck 
--check-prefix=INVALID %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=medium %s 2>&1 | FileCheck 
--check-prefix=AARCH64-MEDIUM %s
+// RUN: %clang -target aarch64 -### -c -mcmodel=kernel %s 2>&1 | FileCheck 
--check-prefix=AARCH64-KERNEL %s

Do you need `not` in front of this? Can't remember.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132538

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


[PATCH] D132502: [clang][modules] Consider M affecting after mapping M.Private to M_Private

2022-08-24 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:2017
 // migrate off of Foo.Private syntax.
-if (!Sub && PP->getLangOpts().ImplicitModules && Name == "Private" &&
-Module == Module->getTopLevelModule()) {
+if (!Sub && Name == "Private" && Module == Module->getTopLevelModule()) {
   SmallString<128> PrivateModule(Module->Name);

benlangmuir wrote:
> Not sure if this is a good idea, but have you considered having the scanner 
> provide the module with `Foo.Private=` syntax instead? It would be nice to 
> keep this hack contained to implicit builds if we can.
Interesting idea, that didn't occur to me. What implementation strategy are you 
thinking of?

If we want to avoid this hack, it seems like we'd need to pass `ModuleIdPath 
ImportPath` instead of `StringRef ModuleName` to 
`findOrCompileModuleAndReadAST()` and friends. That would allow us to look up 
the most specific `-fmodule-file=` argument. I'm not convinced changing 
multiple functions (and then changing them back when we don't need the hack) is 
better than extending the hack to explicit modules.

The upside is that we wouldn't need to report `M` as a dependency. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132502

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


[PATCH] D132502: [clang][modules] Consider M affecting after mapping M.Private to M_Private

2022-08-24 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:2017
 // migrate off of Foo.Private syntax.
-if (!Sub && PP->getLangOpts().ImplicitModules && Name == "Private" &&
-Module == Module->getTopLevelModule()) {
+if (!Sub && Name == "Private" && Module == Module->getTopLevelModule()) {
   SmallString<128> PrivateModule(Module->Name);

jansvoboda11 wrote:
> benlangmuir wrote:
> > Not sure if this is a good idea, but have you considered having the scanner 
> > provide the module with `Foo.Private=` syntax instead? It would be nice to 
> > keep this hack contained to implicit builds if we can.
> Interesting idea, that didn't occur to me. What implementation strategy are 
> you thinking of?
> 
> If we want to avoid this hack, it seems like we'd need to pass `ModuleIdPath 
> ImportPath` instead of `StringRef ModuleName` to 
> `findOrCompileModuleAndReadAST()` and friends. That would allow us to look up 
> the most specific `-fmodule-file=` argument. I'm not convinced changing 
> multiple functions (and then changing them back when we don't need the hack) 
> is better than extending the hack to explicit modules.
> 
> The upside is that we wouldn't need to report `M` as a dependency. WDYT?
Another thing to consider: implicit build would need to propagate the 
information that module `Foo_Private` needs to be spelled on the command-line 
as `Foo.Private` to the scanner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132502

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


[PATCH] D128113: Clang: fix AST representation of expanded template arguments.

2022-08-24 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D128113#3745888 , @alexfh wrote:

> The main questions we need to answer here are:
>
> 1. is the cost of storing parameter pack substitution indices while building 
> AST worth the benefits?
> 2. is there an alternative solution that would shift the cost to the moment 
> when this information is about to be used (when formatting diagnostic, I 
> suppose)?
> 3. is there a good way to make this cost optional (using a flag or somehow 
> else)?



1. For me yes, this was a fairly simple patch that got reviewed quickly and got 
the job done. But it seems it was not good for your use case :)
2. I think there is a chance the approach I mentioned earlier could work. It's 
hard for me to tell without spending some time trying. This could though end up 
being a much more complicated patch, which hits my projects bottleneck: it's 
pretty hard to find reviewers for this sort of stuff.
3. That has the advantage of change simplicity, but not user simplicity. It 
could provide a escape hatch in allowing us to have a simple solution now, but 
then iterate to something better later. But since this is an externally visible 
change to the AST, it does seem far from ideal to be changing this twice. It 
would be pretty unfortunate if someone else started using this feature and then 
we decided to take it away.

I would be fine though reverting this, and then doing some more investigation, 
and also perhaps waiting for a second opinion from @rsmith.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128113

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


[PATCH] D113107: Support of expression granularity for _Float16.

2022-08-24 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Thank you!  I think all the invariants look right here; just some minor 
comments now, and then it should be ready to commit.




Comment at: clang/lib/CodeGen/CGExprComplex.cpp:403
+  Builder.CreateStore(Val.second, ImagPtr, isVolatile);
+}
+

This looks to be dead code now, right?



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:2860
+  result = Builder.CreateFPTrunc(result, ConvertType(E->getType()),
+ "unpromotion");
+  return result;

Please use your `EmitUnPromotedValue` function here (and in the similar 
functions below).


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

https://reviews.llvm.org/D113107

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


[PATCH] D132405: [clang][deps] Split translation units into individual -cc1 or other commands

2022-08-24 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir updated this revision to Diff 455315.
benlangmuir added a comment.

- Remove CompilerInvocation from Command and ModuleDeps. Only the arg strings 
are exposed now.
- Simplify Command, which is now just a simple struct.
- Move the logic for mutating the CompilerInvocation for the TU into the 
scanner.
- Minor refactoring to reduce nesting in DependencyScanningWorker.
- Rebase


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

https://reviews.llvm.org/D132405

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/include/clang/Tooling/Tooling.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/test/ClangScanDeps/deprecated-driver-api.c
  clang/test/ClangScanDeps/diagnostics.c
  clang/test/ClangScanDeps/header-search-pruning-transitive.c
  clang/test/ClangScanDeps/modules-context-hash-ignore-macros.c
  clang/test/ClangScanDeps/modules-context-hash-outputs.c
  clang/test/ClangScanDeps/modules-context-hash-warnings.c
  clang/test/ClangScanDeps/modules-context-hash.c
  clang/test/ClangScanDeps/modules-dep-args.c
  clang/test/ClangScanDeps/modules-fmodule-name-no-module-built.m
  clang/test/ClangScanDeps/modules-full.cpp
  clang/test/ClangScanDeps/modules-inferred.m
  clang/test/ClangScanDeps/modules-no-undeclared-includes.c
  clang/test/ClangScanDeps/modules-pch-common-submodule.c
  clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
  clang/test/ClangScanDeps/modules-pch.c
  clang/test/ClangScanDeps/multiple-commands.c
  clang/test/ClangScanDeps/removed-args.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp
  clang/unittests/Tooling/ToolingTest.cpp
  clang/utils/module-deps-to-rsp.py

Index: clang/utils/module-deps-to-rsp.py
===
--- clang/utils/module-deps-to-rsp.py
+++ clang/utils/module-deps-to-rsp.py
@@ -48,6 +48,9 @@
   type=str)
   action.add_argument("--tu-index", help="The index of the translation unit to get arguments for",
   type=int)
+  parser.add_argument("--tu-cmd-index",
+  help="The index of the command within the translation unit (default=0)",
+  type=int, default=0)
   args = parser.parse_args()
 
   full_deps = parseFullDeps(json.load(open(args.full_deps_file, 'r')))
@@ -58,7 +61,8 @@
 if args.module_name:
   cmd = findModule(args.module_name, full_deps)['command-line']
 elif args.tu_index != None:
-  cmd = full_deps.translation_units[args.tu_index]['command-line']
+  tu = full_deps.translation_units[args.tu_index]
+  cmd = tu['commands'][args.tu_cmd_index]['command-line']
 
 print(" ".join(map(quote, cmd)))
   except:
Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -326,6 +326,46 @@
   EXPECT_TRUE(Consumer.SawSourceManager);
 }
 
+TEST(ToolInvocation, CC1Args) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-cc1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("void foo(void);\n"));
+  EXPECT_TRUE(Invocation.run());
+}
+
+TEST(ToolInvocation, CC1ArgsInvalid) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-cc1");
+  Args.push_back("-invalid-arg");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("void foo(void);\n"));
+  EXPECT_FALSE(Invocation.run());
+}
+
 namespace {
 /// Overlays the real filesystem with the given VFS and returns

[PATCH] D132531: [AArch64] Reserve more physical registers

2022-08-24 Thread Guozhi Wei via Phabricator via cfe-commits
Carrot abandoned this revision.
Carrot added a comment.

Thanks for the clarification, I will propose another patch for my purpose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132531

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


[PATCH] D132405: [clang][deps] Split translation units into individual -cc1 or other commands

2022-08-24 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir marked 11 inline comments as done.
benlangmuir added inline comments.



Comment at: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h:44
+
+  enum CommandKind {
+CK_CC1,

tschuett wrote:
> Why is this not an enum class?
Removed in latest change.



Comment at: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h:80
+
+  static bool classof(const Command *C) { return C->getKind() == CK_Simple; }
+};

tschuett wrote:
> Why are all members public?
Latest change simplifies this to a struct.



Comment at: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp:155
+void FullDependencyConsumer::handleInvocation(CompilerInvocation CI) {
+  clearImplicitModuleBuildOptions(CI);
+  Commands.push_back(std::make_unique(std::move(CI)));

jansvoboda11 wrote:
> benlangmuir wrote:
> > jansvoboda11 wrote:
> > > Shouldn't this be a responsibility of the dependency scanner?
> > Good question! I was mirroring how it works for modules where we do this in 
> > the `ModuleDepCollector` and store the whole invocation in the 
> > `ModuleDeps`.  But I guess that's "inside" the dep scanner, and this is 
> > "outside".  Happy to shuffle things around.
> > 
> > What is your opinion of  `takeFullDependencies()` adding to 
> > `FrontendOpts.ModuleFiles`, ? That is also arguably the scanner's 
> > responsibility.
> > 
> > Another thing we could do here is remove `BuildInvocation` from 
> > `FullDependencies` and `ModuleDeps` and only expose the serialized `-cc1` 
> > arguments.  It would simplify the new code a bit since there'd only be one 
> > kind of "command".   On the other hand, I could also see it being 
> > potentially useful to have the whole invocation available if you were 
> > writing a C++ tool that used the scanner API rather than just 
> > clang-scan-deps itself.
> > Good question! I was mirroring how it works for modules where we do this in 
> > the `ModuleDepCollector` and store the whole invocation in the 
> > `ModuleDeps`. But I guess that's "inside" the dep scanner, and this is 
> > "outside". Happy to shuffle things around.
> As discussed offline, I'd prefer keeping `CompilerInvocation` internal to the 
> dependency scanner and exposing simple types (`std::vector` for 
> the command line) unless clients need more flexibility.
> 
> > What is your opinion of `takeFullDependencies()` adding to 
> > `FrontendOpts.ModuleFiles`, ? That is also arguably the scanner's 
> > responsibility.
> I'd prefer adding to `FrontendOpts.ModuleFiles` earlier, before the consumer.
> 
> > Another thing we could do here is remove `BuildInvocation` from 
> > `FullDependencies` and `ModuleDeps` and only expose the serialized `-cc1` 
> > arguments. It would simplify the new code a bit since there'd only be one 
> > kind of "command". On the other hand, I could also see it being potentially 
> > useful to have the whole invocation available if you were writing a C++ 
> > tool that used the scanner API rather than just clang-scan-deps itself.
> +1
Done in latest changes. The logic for mutating the compiler invocation is now 
contained in the ModuleDepCollector, alongside the existing logic for doing the 
same kind of changes to module build commands.


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

https://reviews.llvm.org/D132405

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


[PATCH] D132589: [HLSL] Add acos library function This change exposes the acos library function for HLSL scalar types, excluding long long doubles. Acos is supported for all scalar, vector, and matri

2022-08-24 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 created this revision.
bob80905 added reviewers: beanz, pow2clk.
Herald added a subscriber: Anastasia.
Herald added a project: All.
bob80905 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

...rt.

Long long double support is missing in this patch because that type
doesn't exist in HLSL.

The full documentation of the HLSL acos function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-acos


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132589

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h
  clang/test/CodeGenHLSL/builtins/acos.hlsl


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -0,0 +1,34 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -o - | FileCheck %s
+
+double acos_d(double x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef double @"?acos_d@@YANN@Z"(
+// CHECK: call noundef double @acos(double noundef %0) #2
+
+float acos_f(float x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef float @"?acos_f@@YAMM@Z"(
+// CHECK: call noundef float @acosf(float noundef %0)
+
+long double acos_ld(long double x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
+// CHECK: call noundef double @acosl(double noundef %0)
+
+/*
+long long double acos_lld(long long double x)
+{
+  return acos(x);
+}
+*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -12,4 +12,12 @@
 __attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) 
uint
 WaveActiveCountBits(bool bBit);
 
+
+__attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
+__attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
+__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long 
double In);
+//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 
acos(__float128 In);
+
+
+
 #endif //_HLSL_HLSL_INTRINSICS_H_


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -0,0 +1,34 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -o - | FileCheck %s
+
+double acos_d(double x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef double @"?acos_d@@YANN@Z"(
+// CHECK: call noundef double @acos(double noundef %0) #2
+
+float acos_f(float x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef float @"?acos_f@@YAMM@Z"(
+// CHECK: call noundef float @acosf(float noundef %0)
+
+long double acos_ld(long double x)
+{
+  return acos(x);
+}
+
+// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
+// CHECK: call noundef double @acosl(double noundef %0)
+
+/*
+long long double acos_lld(long long double x)
+{
+  return acos(x);
+}
+*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -12,4 +12,12 @@
 __attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits))) uint
 WaveActiveCountBits(bool bBit);
 
+
+__attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
+__attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
+__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long double In);
+//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 acos(__float128 In);
+
+
+
 #endif //_HLSL_HLSL_INTRINSICS_H_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D118511: Add a warning for not packing non-POD members in packed structs

2022-08-24 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D118511#3732200 , @tstellar wrote:

> @dblaikie Can you file a bug and add the 15.0.0 Release Milestone, so we 
> don't forget to fix this in the release branch.

Yeah, sorry about the delay on this, last week was a lot on my side. Filed 
https://github.com/llvm/llvm-project/issues/57346 - happy to edit/change/have 
that changed in whatever way you were thinking.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118511

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


[PATCH] D132592: Clang] Implement function attribute nouwtable

2022-08-24 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen created this revision.
ychen added reviewers: aaron.ballman, rnk, rsmith.
Herald added a project: All.
ychen requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

To have finer control of IR uwtable attribute generation. For target code 
generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there 
are
no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 
1".


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/attr-nouwtable.c


Index: clang/test/CodeGen/attr-nouwtable.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-nouwtable.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -funwind-tables=2 -S -emit-llvm %s -o - | FileCheck %s
+
+__attribute__((nouwtable))
+int test1(void) { return 0; }
+
+// CHECK: @test1{{.*}}[[ATTR1:#[0-9]+]]
+// CHECK: attributes [[ATTR1]] = {
+// CHECK-NOT: uwtable
+// CHECK: }
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1942,7 +1942,7 @@
llvm::Function *F) {
   llvm::AttrBuilder B(F->getContext());
 
-  if (CodeGenOpts.UnwindTables)
+  if ((!D || !D->hasAttr()) && CodeGenOpts.UnwindTables)
 B.addUWTableAttr(llvm::UWTableKind(CodeGenOpts.UnwindTables));
 
   if (CodeGenOpts.StackClashProtector)
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -4537,6 +4537,16 @@
 }];
 }
 
+def NoUwtableDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``nouwtable`` attribute which skips emitting
+the unwind table entry for the specified function. This attribute is useful for
+selectively emitting the unwind table entry on some functions when building 
with
+``-funwind-tables`` compiler option.
+}];
+}
+
 def InternalLinkageDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -2086,6 +2086,13 @@
   let Documentation = [NoThrowDocs];
 }
 
+def NoUwtable : InheritableAttr {
+  let Spellings = [Clang<"nouwtable">];
+  let Subjects = SubjectList<[FunctionLike]>;
+  let Documentation = [NoUwtableDocs];
+  let SimpleHandler = 1;
+}
+
 def NvWeak : IgnoredAttr {
   // No Declspec spelling of this attribute; the CUDA headers use
   // __attribute__((nv_weak)) unconditionally. Does not receive an [[]]


Index: clang/test/CodeGen/attr-nouwtable.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-nouwtable.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -funwind-tables=2 -S -emit-llvm %s -o - | FileCheck %s
+
+__attribute__((nouwtable))
+int test1(void) { return 0; }
+
+// CHECK: @test1{{.*}}[[ATTR1:#[0-9]+]]
+// CHECK: attributes [[ATTR1]] = {
+// CHECK-NOT: uwtable
+// CHECK: }
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1942,7 +1942,7 @@
llvm::Function *F) {
   llvm::AttrBuilder B(F->getContext());
 
-  if (CodeGenOpts.UnwindTables)
+  if ((!D || !D->hasAttr()) && CodeGenOpts.UnwindTables)
 B.addUWTableAttr(llvm::UWTableKind(CodeGenOpts.UnwindTables));
 
   if (CodeGenOpts.StackClashProtector)
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -4537,6 +4537,16 @@
 }];
 }
 
+def NoUwtableDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``nouwtable`` attribute which skips emitting
+the unwind table entry for the specified function. This attribute is useful for
+selectively emitting the unwind table entry on some functions when building with
+``-funwind-tables`` compiler option.
+}];
+}
+
 def InternalLinkageDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -2086,6 +2086,13 @@
   let Documentation = [NoThrowDocs];
 }
 
+def NoUwtable : InheritableAttr {
+  let Spellings = [Clang<"nouwtable">

[PATCH] D131632: [clang] Enable output of SARIF diagnostics

2022-08-24 Thread Christopher Di Bella via Phabricator via cfe-commits
cjdb accepted this revision.
cjdb added a comment.
This revision is now accepted and ready to land.

Open comments notwithstanding, I'm happy with this patch. Thank you for working 
on this, it's a huge step towards getting more helpful diagnostics for C++!

@aaron.ballman, @vaibhav.y, do you folks have any further concerns? (@denik has 
some commentary incoming)




Comment at: clang/include/clang/Frontend/SARIFDiagnostic.h:24-26
+  raw_ostream *OS;
+
+  SarifDocumentWriter *Writer;

These can go in the private section below.



Comment at: clang/include/clang/Frontend/SARIFDiagnosticPrinter.h:72
+
+  bool OwnsOutputStream = true;
+};

This can't ever happen, because there's no constructor that doesn't set 
`OwnsOutputStream`.



Comment at: clang/lib/Frontend/SARIFDiagnostic.cpp:86-88
+if (Range.isInvalid()) {
+  continue;
+}

It seems @aaron.ballman has finally trained me :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131632

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


[PATCH] D119296: KCFI sanitizer

2022-08-24 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen added inline comments.



Comment at: llvm/include/llvm/CodeGen/MachineInstr.h:265
+  PointerSumTypeMember,
+  PointerSumTypeMember>,
+  PointerSumTypeMember>

This fails on 32-bit architectures as `PointerEmbeddedInt` doesn't allow 
storing 32 bits in a 32-bit pointer:
```
  // Note: This '<' is correct; using '<=' would result in some shifts
  // overflowing their storage types.
  static_assert(Bits < sizeof(uintptr_t) * CHAR_BIT,
"Cannot embed more bits than we have in a pointer!")
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119296

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


[PATCH] D131625: [HLSL] Entry functions require param annotation

2022-08-24 Thread Chris Bieneman 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 rGbdf1327fea63: [HLSL] Entry functions require param 
annotation (authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131625

Files:
  clang/include/clang/AST/Attr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaHLSL/Semantics/missing_entry_annotation.hlsl
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2897,7 +2897,8 @@
   { "INHERITABLE_ATTR", "InheritableAttr" },
   { "DECL_OR_TYPE_ATTR", "DeclOrTypeAttr" },
   { "INHERITABLE_PARAM_ATTR", "InheritableParamAttr" },
-  { "PARAMETER_ABI_ATTR", "ParameterABIAttr" }
+  { "PARAMETER_ABI_ATTR", "ParameterABIAttr" },
+  { "HLSL_ANNOTATION_ATTR", "HLSLAnnotationAttr"}
 };
 
 static void emitDefaultDefine(raw_ostream &OS, StringRef name,
Index: clang/test/SemaHLSL/Semantics/missing_entry_annotation.hlsl
===
--- /dev/null
+++ clang/test/SemaHLSL/Semantics/missing_entry_annotation.hlsl
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -fsyntax-only -hlsl-entry main -verify %s
+
+[numthreads(1,1, 1)]
+void main(int GI) { } // expected-error{{semantic annotations must be present for all parameters of an entry function or patch constant function}} expected-note{{'GI' declared here}}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11894,6 +11894,16 @@
 }
 break;
   }
+
+  for (const auto *Param : FD->parameters()) {
+if (!Param->hasAttr()) {
+  // FIXME: Handle struct parameters where annotations are on struct fields.
+  Diag(FD->getLocation(), diag::err_hlsl_missing_semantic_annotation);
+  Diag(Param->getLocation(), diag::note_previous_decl) << Param;
+  FD->setInvalidDecl();
+}
+  }
+  // FIXME: Verify return type semantic annotation.
 }
 
 bool Sema::CheckForConstantInitializer(Expr *Init, QualType DclT) {
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11643,6 +11643,9 @@
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed %0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 shader entry">;
 def err_hlsl_attribute_param_mismatch : Error<"%0 attribute parameters do not match the previous declaration">;
+def err_hlsl_missing_semantic_annotation : Error<
+  "semantic annotations must be present for all parameters of an entry "
+  "function or patch constant function">;
 
 def err_hlsl_pointers_unsupported : Error<
   "%select{pointers|references}0 are unsupported in HLSL">;
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -608,6 +608,9 @@
 /// A attribute is either a declaration attribute or a statement attribute.
 class DeclOrStmtAttr : InheritableAttr;
 
+/// An attribute class for HLSL Annotations.
+class HLSLAnnotationAttr : InheritableAttr;
+
 /// A target-specific attribute.  This class is meant to be used as a mixin
 /// with InheritableAttr or Attr depending on the attribute's needs.
 class TargetSpecificAttr {
@@ -4011,7 +4014,7 @@
   let Documentation = [NumThreadsDocs];
 }
 
-def HLSLSV_GroupIndex: InheritableAttr {
+def HLSLSV_GroupIndex: HLSLAnnotationAttr {
   let Spellings = [HLSLSemantic<"SV_GroupIndex">];
   let Subjects = SubjectList<[ParmVar, GlobalVar]>;
   let LangOpts = [HLSL];
Index: clang/include/clang/AST/Attr.h
===
--- clang/include/clang/AST/Attr.h
+++ clang/include/clang/AST/Attr.h
@@ -190,6 +190,22 @@
   }
 };
 
+class HLSLAnnotationAttr : public InheritableAttr {
+protected:
+  HLSLAnnotationAttr(ASTContext &Context, const AttributeCommonInfo &CommonInfo,
+ attr::Kind AK, bool IsLateParsed,
+ bool InheritEvenIfAlreadyPresent)
+  : InheritableAttr(Context, CommonInfo, AK, IsLateParsed,
+InheritEvenIfAlreadyPresent) {}
+
+public:
+  // Implement isa/cast/dyncast/etc.
+  static bool classof(const Attr *A) {
+return A->getKind() >= attr::FirstHLSLAnnotationAttr &&
+   A->getKind() <= attr::LastHLSLAnnotationAttr;
+  }
+};
+
 /// A parameter 

[clang] bdf1327 - [HLSL] Entry functions require param annotation

2022-08-24 Thread Chris Bieneman via cfe-commits

Author: Chris Bieneman
Date: 2022-08-24T14:35:11-05:00
New Revision: bdf1327fea632bf9736924acf59675182b528b23

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

LOG: [HLSL] Entry functions require param annotation

HLSL entry function parameters must have parameter annotations. This
allows appropriate intrinsic values to be populated into parameters
during code generation.

This does not handle entry function return values, which will be
handled in a subsequent commit because we don't currently support any
annotations that are valid for function returns.

Reviewed By: aaron.ballman

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

Added: 
clang/test/SemaHLSL/Semantics/missing_entry_annotation.hlsl

Modified: 
clang/include/clang/AST/Attr.h
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/utils/TableGen/ClangAttrEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Attr.h b/clang/include/clang/AST/Attr.h
index 070e160d65170..4478c5fd91d4a 100644
--- a/clang/include/clang/AST/Attr.h
+++ b/clang/include/clang/AST/Attr.h
@@ -190,6 +190,22 @@ class InheritableParamAttr : public InheritableAttr {
   }
 };
 
+class HLSLAnnotationAttr : public InheritableAttr {
+protected:
+  HLSLAnnotationAttr(ASTContext &Context, const AttributeCommonInfo 
&CommonInfo,
+ attr::Kind AK, bool IsLateParsed,
+ bool InheritEvenIfAlreadyPresent)
+  : InheritableAttr(Context, CommonInfo, AK, IsLateParsed,
+InheritEvenIfAlreadyPresent) {}
+
+public:
+  // Implement isa/cast/dyncast/etc.
+  static bool classof(const Attr *A) {
+return A->getKind() >= attr::FirstHLSLAnnotationAttr &&
+   A->getKind() <= attr::LastHLSLAnnotationAttr;
+  }
+};
+
 /// A parameter attribute which changes the argument-passing ABI rule
 /// for the parameter.
 class ParameterABIAttr : public InheritableParamAttr {

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 129055982c543..f962f84f3b7a7 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -608,6 +608,9 @@ class DeclOrTypeAttr : InheritableAttr;
 /// A attribute is either a declaration attribute or a statement attribute.
 class DeclOrStmtAttr : InheritableAttr;
 
+/// An attribute class for HLSL Annotations.
+class HLSLAnnotationAttr : InheritableAttr;
+
 /// A target-specific attribute.  This class is meant to be used as a mixin
 /// with InheritableAttr or Attr depending on the attribute's needs.
 class TargetSpecificAttr {
@@ -4011,7 +4014,7 @@ def HLSLNumThreads: InheritableAttr {
   let Documentation = [NumThreadsDocs];
 }
 
-def HLSLSV_GroupIndex: InheritableAttr {
+def HLSLSV_GroupIndex: HLSLAnnotationAttr {
   let Spellings = [HLSLSemantic<"SV_GroupIndex">];
   let Subjects = SubjectList<[ParmVar, GlobalVar]>;
   let LangOpts = [HLSL];

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f544bd345a556..ae10b13c8c769 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11643,6 +11643,9 @@ def err_hlsl_numthreads_argument_oor : Error<"argument 
'%select{X|Y|Z}0' to numt
 def err_hlsl_numthreads_invalid : Error<"total number of threads cannot exceed 
%0">;
 def err_hlsl_missing_numthreads : Error<"missing numthreads attribute for %0 
shader entry">;
 def err_hlsl_attribute_param_mismatch : Error<"%0 attribute parameters do not 
match the previous declaration">;
+def err_hlsl_missing_semantic_annotation : Error<
+  "semantic annotations must be present for all parameters of an entry "
+  "function or patch constant function">;
 
 def err_hlsl_pointers_unsupported : Error<
   "%select{pointers|references}0 are unsupported in HLSL">;

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 3ca5bf3b1254c..ef59ecebb70ac 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -11894,6 +11894,16 @@ void Sema::CheckHLSLEntryPoint(FunctionDecl *FD) {
 }
 break;
   }
+
+  for (const auto *Param : FD->parameters()) {
+if (!Param->hasAttr()) {
+  // FIXME: Handle struct parameters where annotations are on struct 
fields.
+  Diag(FD->getLocation(), diag::err_hlsl_missing_semantic_annotation);
+  Diag(Param->getLocation(), diag::note_previous_decl) << Param;
+  FD->setInvalidDecl();
+}
+  }
+  // FIXME: Verify return type semantic annotation.
 }
 
 bool Sema::CheckForConstantInitializer(Expr *Init, QualType DclT) {

diff  --git a/clang/test/SemaHLSL/Semantics/missing_entry_annotation.hlsl 
b/clang/test/SemaHLSL/Semantics/m

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

2022-08-24 Thread David Blaikie via Phabricator via cfe-commits
dblaikie marked an inline comment as done.
dblaikie added a comment.

In D119051#3724121 , @rnk wrote:

> Regarding the usage of isPOD in the MSVC ABI code, we should have a routine 
> similar to `isTrivialForAArch64MSVC` that works for the other MSVC 
> architectures that we support (x86, x64, and arm32). I don't think we should 
> try to rely on definition data bits. Clang is almost always tracking 
> something slightly different than what MSVC tracks, so we should write down 
> MSVC's logic once and keep it separate from Clang's notion of POD.
>
> I think you can work out MSVC's behavior with godbolt, but if you need a 
> hand, I volunteer @hans to take a stab at refactoring 
> `MicrosoftCXXABI::classifyReturnType`. I remember making lots of comments to 
> try to simplify the code during review, but everyone is always wary of scope 
> creep.

Well, my first attempt at this - essentially using `isTrivialForAArch64MSVC` 
for everything, including x86, doesn't fail any Clang tests...

Do we still have those various fuzzers Majnemer setup? I'd guess we'd need to 
fuzz around here again to discover what the intended behavior is?

Hmm, let's compare the things that make `PlainOldData` `false`...

1. has base classes
2. any virtual member function
3. non-implicit ctor (so even user-declared-but-defaulted ctor)
4. non-implicit member function (so even user-declared-but-defaulted assignment 
operators or dtor)
5. any non-public field member
6. some ObjC thing (non-trivial ObjC lifetime)
7. any field that is of C++98 POD type... (mostly a recursive definition, when 
it comes to record types - but then there's some rules about incomplete array 
types, which couldn't be field types anyway, and some other cases)
8. non-static data member initializers

Let's compare that with `isTrivialForAArch64MSVC`...

1. checked (second)
2. checked (third) - well, it checks "is polymorphic" rather than virtual 
functions, so does that change things if you've got virtual bases but no 
virtual functions, can you have that?
3. only user-provided ctors, so it can have non-implicit (user-declared) but 
defaulted ctors
4. specifically checking non-trivial copy assignment (no restriction on move 
assignment and it could have any number of other member functions, I think?)
5. checked (first)
6. nope/not relevant?
7. Presumably tested by "hasNonTrivialDestructor" and 
"hasNonTrivialCopyAssignment"?
8. would a non-static data member initializer make the ctor user-provided? 
Presumably not, so I don't think this property is checked at all, which seems 
fair - how you pass something shouldn't be changed by how its constructed

I'll test the cases where these things differ with the godbolt-like testing 
earlier...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119051

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


[PATCH] D132502: [clang][modules] Consider M affecting after mapping M.Private to M_Private

2022-08-24 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir accepted this revision.
benlangmuir added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang/lib/Frontend/CompilerInstance.cpp:2017
 // migrate off of Foo.Private syntax.
-if (!Sub && PP->getLangOpts().ImplicitModules && Name == "Private" &&
-Module == Module->getTopLevelModule()) {
+if (!Sub && Name == "Private" && Module == Module->getTopLevelModule()) {
   SmallString<128> PrivateModule(Module->Name);

jansvoboda11 wrote:
> jansvoboda11 wrote:
> > benlangmuir wrote:
> > > Not sure if this is a good idea, but have you considered having the 
> > > scanner provide the module with `Foo.Private=` syntax instead? It would 
> > > be nice to keep this hack contained to implicit builds if we can.
> > Interesting idea, that didn't occur to me. What implementation strategy are 
> > you thinking of?
> > 
> > If we want to avoid this hack, it seems like we'd need to pass 
> > `ModuleIdPath ImportPath` instead of `StringRef ModuleName` to 
> > `findOrCompileModuleAndReadAST()` and friends. That would allow us to look 
> > up the most specific `-fmodule-file=` argument. I'm not convinced changing 
> > multiple functions (and then changing them back when we don't need the 
> > hack) is better than extending the hack to explicit modules.
> > 
> > The upside is that we wouldn't need to report `M` as a dependency. WDYT?
> Another thing to consider: implicit build would need to propagate the 
> information that module `Foo_Private` needs to be spelled on the command-line 
> as `Foo.Private` to the scanner.
Okay, it sounds like the current patch is less invasive than the alternative. 
Thanks for talking it through.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132502

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


[PATCH] D132503: Add cxx scope if needed for requires clause.

2022-08-24 Thread Luke Nihlen via Phabricator via cfe-commits
luken-google added a comment.

Note that the following tests:

  Builtins-i386-linux :: muldc3_test.c
  SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp
  SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp
  SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp
  SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp
  SanitizerCommon-ubsan-i386-Linux :: Linux/crypt_r.cpp
  SanitizerCommon-ubsan-i386-Linux :: Posix/crypt.cpp

Are failing at HEAD and at this base diff without this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132503

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


[PATCH] D131718: [HLSL] Add abs library function

2022-08-24 Thread Justin Bogner via Phabricator via cfe-commits
bogner accepted this revision.
bogner added a comment.
This revision is now accepted and ready to land.

LGTM. Make sure you update the description from saying that this doesn't handle 
half because of https://llvm.org/pr57100 to saying that it fixes the bug 
instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131718

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


[PATCH] D132597: remove scalar types lld and ld from test since hlsl won't support them

2022-08-24 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 created this revision.
Herald added a subscriber: Anastasia.
Herald added a project: All.
bob80905 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132597

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h
  clang/test/CodeGenHLSL/builtins/acos.hlsl


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- clang/test/CodeGenHLSL/builtins/acos.hlsl
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -17,18 +17,3 @@
 
 // CHECK: define noundef float @"?acos_f@@YAMM@Z"(
 // CHECK: call noundef float @acosf(float noundef %0)
-
-long double acos_ld(long double x)
-{
-  return acos(x);
-}
-
-// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
-// CHECK: call noundef double @acosl(double noundef %0)
-
-/*
-long long double acos_lld(long long double x)
-{
-  return acos(x);
-}
-*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -15,9 +15,6 @@
 
 __attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
 __attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
-__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long 
double In);
-//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 
acos(__float128 In);
-
 
 
 #endif //_HLSL_HLSL_INTRINSICS_H_


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- clang/test/CodeGenHLSL/builtins/acos.hlsl
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -17,18 +17,3 @@
 
 // CHECK: define noundef float @"?acos_f@@YAMM@Z"(
 // CHECK: call noundef float @acosf(float noundef %0)
-
-long double acos_ld(long double x)
-{
-  return acos(x);
-}
-
-// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
-// CHECK: call noundef double @acosl(double noundef %0)
-
-/*
-long long double acos_lld(long long double x)
-{
-  return acos(x);
-}
-*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -15,9 +15,6 @@
 
 __attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
 __attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
-__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long double In);
-//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 acos(__float128 In);
-
 
 
 #endif //_HLSL_HLSL_INTRINSICS_H_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132405: [clang][deps] Split translation units into individual -cc1 or other commands

2022-08-24 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir updated this revision to Diff 455338.

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

https://reviews.llvm.org/D132405

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/include/clang/Tooling/Tooling.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/test/ClangScanDeps/deprecated-driver-api.c
  clang/test/ClangScanDeps/diagnostics.c
  clang/test/ClangScanDeps/header-search-pruning-transitive.c
  clang/test/ClangScanDeps/modules-context-hash-ignore-macros.c
  clang/test/ClangScanDeps/modules-context-hash-outputs.c
  clang/test/ClangScanDeps/modules-context-hash-warnings.c
  clang/test/ClangScanDeps/modules-context-hash.c
  clang/test/ClangScanDeps/modules-dep-args.c
  clang/test/ClangScanDeps/modules-fmodule-name-no-module-built.m
  clang/test/ClangScanDeps/modules-full.cpp
  clang/test/ClangScanDeps/modules-inferred.m
  clang/test/ClangScanDeps/modules-no-undeclared-includes.c
  clang/test/ClangScanDeps/modules-pch-common-submodule.c
  clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
  clang/test/ClangScanDeps/modules-pch.c
  clang/test/ClangScanDeps/multiple-commands.c
  clang/test/ClangScanDeps/removed-args.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp
  clang/unittests/Tooling/ToolingTest.cpp
  clang/utils/module-deps-to-rsp.py

Index: clang/utils/module-deps-to-rsp.py
===
--- clang/utils/module-deps-to-rsp.py
+++ clang/utils/module-deps-to-rsp.py
@@ -48,6 +48,9 @@
   type=str)
   action.add_argument("--tu-index", help="The index of the translation unit to get arguments for",
   type=int)
+  parser.add_argument("--tu-cmd-index",
+  help="The index of the command within the translation unit (default=0)",
+  type=int, default=0)
   args = parser.parse_args()
 
   full_deps = parseFullDeps(json.load(open(args.full_deps_file, 'r')))
@@ -58,7 +61,8 @@
 if args.module_name:
   cmd = findModule(args.module_name, full_deps)['command-line']
 elif args.tu_index != None:
-  cmd = full_deps.translation_units[args.tu_index]['command-line']
+  tu = full_deps.translation_units[args.tu_index]
+  cmd = tu['commands'][args.tu_cmd_index]['command-line']
 
 print(" ".join(map(quote, cmd)))
   except:
Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -326,6 +326,46 @@
   EXPECT_TRUE(Consumer.SawSourceManager);
 }
 
+TEST(ToolInvocation, CC1Args) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-cc1");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("void foo(void);\n"));
+  EXPECT_TRUE(Invocation.run());
+}
+
+TEST(ToolInvocation, CC1ArgsInvalid) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-cc1");
+  Args.push_back("-invalid-arg");
+  Args.push_back("test.cpp");
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("void foo(void);\n"));
+  EXPECT_FALSE(Invocation.run());
+}
+
 namespace {
 /// Overlays the real filesystem with the given VFS and returns the result.
 llvm::IntrusiveRefCntPtr
Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -182,6 +182,11 @@
 llvm::cl::desc("The names of dependency targets for the

[PATCH] D131009: [analyzer] Fixing a bug raising false positives of stack block object leaking under ARC

2022-08-24 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 added a comment.

In D131009#3744416 , @NoQ wrote:

> Aha perfect, now the entire static analyzer knows how to work with these 
> regions!
>
> I have one tiny remark and I think we can commit.

Thank you!  I will make the change then directly commit.


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

https://reviews.llvm.org/D131009

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


[PATCH] D132589: [HLSL] Add acos library function

2022-08-24 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 updated this revision to Diff 455343.
bob80905 added a comment.

remove scalar types lld and ld from test since hlsl won't support them


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132589

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h
  clang/test/CodeGenHLSL/builtins/acos.hlsl


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- clang/test/CodeGenHLSL/builtins/acos.hlsl
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -17,18 +17,3 @@
 
 // CHECK: define noundef float @"?acos_f@@YAMM@Z"(
 // CHECK: call noundef float @acosf(float noundef %0)
-
-long double acos_ld(long double x)
-{
-  return acos(x);
-}
-
-// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
-// CHECK: call noundef double @acosl(double noundef %0)
-
-/*
-long long double acos_lld(long long double x)
-{
-  return acos(x);
-}
-*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -15,9 +15,6 @@
 
 __attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
 __attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
-__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long 
double In);
-//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 
acos(__float128 In);
-
 
 
 #endif //_HLSL_HLSL_INTRINSICS_H_


Index: clang/test/CodeGenHLSL/builtins/acos.hlsl
===
--- clang/test/CodeGenHLSL/builtins/acos.hlsl
+++ clang/test/CodeGenHLSL/builtins/acos.hlsl
@@ -17,18 +17,3 @@
 
 // CHECK: define noundef float @"?acos_f@@YAMM@Z"(
 // CHECK: call noundef float @acosf(float noundef %0)
-
-long double acos_ld(long double x)
-{
-  return acos(x);
-}
-
-// CHECK: define noundef double @"?acos_ld@@YAOO@Z"(
-// CHECK: call noundef double @acosl(double noundef %0)
-
-/*
-long long double acos_lld(long long double x)
-{
-  return acos(x);
-}
-*/
\ No newline at end of file
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -15,9 +15,6 @@
 
 __attribute__((clang_builtin_alias(__builtin_acos))) double acos(double In);
 __attribute__((clang_builtin_alias(__builtin_acosf))) float acos(float In);
-__attribute__((clang_builtin_alias(__builtin_acosl))) long double acos(long double In);
-//__attribute__((clang_builtin_alias(__builtin_acosf128))) __float128 acos(__float128 In);
-
 
 
 #endif //_HLSL_HLSL_INTRINSICS_H_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132600: [llvm-profdata] Handle internal linkage functions in profile supplementation

2022-08-24 Thread Rong Xu via Phabricator via cfe-commits
xur created this revision.
xur added reviewers: davidxl, tmsriram.
Herald added a subscriber: wenlei.
Herald added a project: All.
xur requested review of this revision.
Herald added a project: LLVM.

This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in FDO have a prefix of source file name, while they do not
have one in SampleFDO. Current implementation does not handle this and we are
not updating the profile for static functions. This patch fixes this.

(2) Handling of -funique-internal-linakge-symbols
Again this is for the internal linkage functions. Option
-funique-internal-linakge-symbols can now be applied to both FDO and SampleFDO
compilation. When it is used, it demangles internal linkage function names and
adds a hash value as the postfix.

When both SampleFDO and FDO profiles use this option, or both
not use this option, changes in (1) should handle this.

Here we also handle when the SampleFDO profile using this option while FDO
profile not using this option, or vice versa.

There is one case where this patch won't work: If one of the profiles used
mangled name and the other does not. For example, if the SampleFDO profile
uses clang c-compiler and without -funique-internal-linakge-symbols, while
the FDO profile uses -funique-internal-linakge-symbols. The SampleFDO profile
contains unmangled names while the FDO profile contains mangled names. If
both profiles use c++ compiler, this won't happen. We think this use case
is rare and does not justify the effort to fix.


https://reviews.llvm.org/D132600

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  llvm/include/llvm/ProfileData/SampleProf.h
  llvm/test/tools/llvm-profdata/Inputs/FUnique.afdotext
  llvm/test/tools/llvm-profdata/Inputs/FUnique.proftext
  llvm/test/tools/llvm-profdata/Inputs/NoFUnique.afdotext
  llvm/test/tools/llvm-profdata/Inputs/NoFUnique.proftext
  llvm/test/tools/llvm-profdata/suppl-instr-with-sample-static-func.test
  llvm/tools/llvm-profdata/llvm-profdata.cpp

Index: llvm/tools/llvm-profdata/llvm-profdata.cpp
===
--- llvm/tools/llvm-profdata/llvm-profdata.cpp
+++ llvm/tools/llvm-profdata/llvm-profdata.cpp
@@ -31,6 +31,7 @@
 #include "llvm/Support/Format.h"
 #include "llvm/Support/FormattedStream.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/MD5.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ThreadPool.h"
@@ -478,7 +479,7 @@
   ZeroCounterRatio = (float)ZeroCntNum / CntNum;
 }
 
-/// Either set all the counters in the instr profile entry \p IFE to -1
+// Either set all the counters in the instr profile entry \p IFE to -1
 /// in order to drop the profile or scale up the counters in \p IFP to
 /// be above hot threshold. We use the ratio of zero counters in the
 /// profile of a function to decide the profile is helpful or harmful
@@ -539,7 +540,73 @@
unsigned InstrProfColdThreshold) {
   // Function to its entry in instr profile.
   StringMap InstrProfileMap;
+  StringMap StaticFuncMap;
   InstrProfSummaryBuilder IPBuilder(ProfileSummaryBuilder::DefaultCutoffs);
+
+  auto checkSampleProfileHasFUnique = [&Reader]() {
+for (const auto &PD : Reader->getProfiles()) {
+  auto &FContext = PD.first;
+  if (FContext.toString().find(FunctionSamples::UniqSuffix) !=
+  std::string::npos) {
+return true;
+  }
+}
+return false;
+  };
+
+  bool SampleProfileHasFUnique = checkSampleProfileHasFUnique();
+
+  auto buildStaticFuncMap = [&StaticFuncMap,
+ SampleProfileHasFUnique](const StringRef &Name) {
+std::string Prefixes[] = {".cpp:", "cc:", ".c:", ".hpp:", ".h:"};
+size_t PrefixPos = StringRef::npos;
+for (auto &Prefix : Prefixes) {
+  PrefixPos = Name.find_insensitive(Prefix);
+  if (PrefixPos == StringRef::npos)
+continue;
+  PrefixPos += Prefix.size();
+  break;
+}
+
+if (PrefixPos == StringRef::npos) {
+  return;
+}
+
+StringRef NewName = Name.drop_front(PrefixPos);
+StringRef FName = Name.substr(0, PrefixPos - 1);
+if (NewName.size() == 0) {
+  return;
+}
+
+// This name should have a static linkage.
+size_t PostfixPos = NewName.find(FunctionSamples::UniqSuffix);
+bool ProfileHasFUnique = (PostfixPos != StringRef::npos);
+
+if (SampleProfileHasFUnique) {
+  // If profile also uses funqiue, nothing to do here.
+  // Otherwise, we need to build the map.
+  if (!ProfileHasFUnique) {
+std::string NStr =
+NewName.str() + getUniqueInternalLinkagePostfix(FName);
+NewName = StringRef(NStr);
+StaticFuncMap[NewName] = Name;
+return;
+  }
+} else {
+  // If profile does not use -funique-internal-linakge-symbols, nothing to
+  // do here. Otherwise, we need to trim.
+  if (ProfileHasFUnique) {
+Ne

[PATCH] D113107: Support of expression granularity for _Float16.

2022-08-24 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Thanks, LGTM


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

https://reviews.llvm.org/D113107

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


  1   2   >