[PATCH] D150221: Add option -fkeep-static-variables to emit all static variables

2023-05-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2207
+addUsedOrCompilerUsedGlobal(GV);
+  else if (CodeGenOpts.KeepStaticConsts && 
VD->getType().isConstQualified())
+addUsedOrCompilerUsedGlobal(GV);

why not fold the `if` and `else if` together given that they perform the same 
action.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3096
+return true;
+  else if (CodeGenOpts.KeepStaticConsts && 
VD->getType().isConstQualified())
+return true;

Fold to a single return.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150221

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


[PATCH] D136554: Implement CWG2631

2023-01-16 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

In D136554#4056862 , @cor3ntin wrote:

> Yes please! However the warning looks correct to me in that case. A
> constructs x which constructs A etc.

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

Please set the project/labels as appropriate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

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


[PATCH] D136554: Implement CWG2631

2023-01-16 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

I've reduced a regression on:

commit ca619613801233ef2def8c3cc7d311d5ed0033cb 
 (HEAD, 
refs/bisect/bad)
Author: Corentin Jabot 
Date:   Sun Oct 23 17:32:58 2022 +0200

  template  int f(T) { return 42; }
  
  struct A {
 int x = f(A());
 A() { }
  };
  
  void foo() { A(); }



  clang++ t2.C -c
  t2.C:4:12: warning: stack nearly exhausted; compilation time may suffer, and 
crashes due to stack overflow are likely [-Wstack-exhausted]
 int x = f(A());
 ^
  Segmentation fault (core dumped)

@cor3ntin would you like me to open a new issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

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


[PATCH] D135384: [AIX] Fix mcount name and call arguments

2023-01-10 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm closed this revision.
cebowleratibm added a comment.

I had a typo in the commit so this didn't auto close.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135384

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


[PATCH] D137375: [AIX][pg] Add Correct Search Paths for Profiled Libraries

2022-11-23 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D137375/new/

https://reviews.llvm.org/D137375

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


[PATCH] D137375: [AIX][pg] Add Correct Search Paths for Profiled Libraries

2022-11-22 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

Looks good but I just want to confirm that the profiled -L paths are appended 
in the correct order with respect to the non-profiled paths.




Comment at: clang/test/Driver/aix-ld.c:192
 // CHECK-LD32-GPROF: "-lc"
+// CHECK-LD32-GPROF: "-L[[SYSROOT]]/lib/profiled"
+// CHECK-LD32-GPROF: "-L[[SYSROOT]]/usr/lib/profiled"

I don't currently see the test checking for the usual `/lib` and `/usr/lib` 
directories.  Should we check that the new profiled -L paths are correctly 
positioned relative to the non-profiled directories, or does it matter?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137375

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


[PATCH] D128223: [clang] Cached linkage assertion for static locals of static function

2022-11-10 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

I believe the fix for a52d151f9dde7 inadvertently exposed a code path where by 
the linkage of a static local of a static function, which would otherwise 
return LinkageInfo::none() may now return VisibleNoLinkage depending on the 
incoming computation argument.

I don't think a static local of a function with no linkage should ever return 
VisibleNoLinkage so I've added the appropriate guard such that the linkage 
evaluation with return no linkage regardless of the computation argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128223

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


[PATCH] D128223: [clang] Cached linkage assertion for static locals of static function

2022-11-10 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm updated this revision to Diff 473756.
cebowleratibm retitled this revision from "[clang] Linkage computation of 
static locals may require forcing visibility computation" to "[clang] Cached 
linkage assertion for static locals of static function".
cebowleratibm edited the summary of this revision.
This revision is now accepted and ready to land.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128223

Files:
  clang/lib/AST/Decl.cpp
  clang/test/CodeGenCXX/linkage-static-local-crash.cpp


Index: clang/test/CodeGenCXX/linkage-static-local-crash.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/linkage-static-local-crash.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix 
-mdefault-visibility-export-mapping=explicit -fvisibility-inlines-hidden 
-emit-llvm %s -o - | FileCheck %s
+
+struct C {
+  template  
+  __attribute__((__visibility__("hidden"))) 
+  static int& f() {
+static int g = 42;
+return g;
+  }
+};
+
+template
+void foo(T i) { C::f(); }
+
+void bar() {
+  foo([]{});
+}
+
+// CHECK: @"_ZZN1C1fIZ3barvE3$_0EERivE1g" = internal global i32 42, align 4
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1368,7 +1368,8 @@
 // is not explicitly attributed as a hidden function,
 // we should not make static local variables in the function hidden.
 LV = getLVForDecl(FD, computation);
-if (isa(D) && useInlineVisibilityHidden(FD) &&
+if (isExternallyVisible(LV.getLinkage()) &&
+isa(D) && useInlineVisibilityHidden(FD) &&
 !LV.isVisibilityExplicit() &&
 !Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar) {
   assert(cast(D)->isStaticLocal());


Index: clang/test/CodeGenCXX/linkage-static-local-crash.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/linkage-static-local-crash.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix -mdefault-visibility-export-mapping=explicit -fvisibility-inlines-hidden -emit-llvm %s -o - | FileCheck %s
+
+struct C {
+  template  
+  __attribute__((__visibility__("hidden"))) 
+  static int& f() {
+static int g = 42;
+return g;
+  }
+};
+
+template
+void foo(T i) { C::f(); }
+
+void bar() {
+  foo([]{});
+}
+
+// CHECK: @"_ZZN1C1fIZ3barvE3$_0EERivE1g" = internal global i32 42, align 4
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1368,7 +1368,8 @@
 // is not explicitly attributed as a hidden function,
 // we should not make static local variables in the function hidden.
 LV = getLVForDecl(FD, computation);
-if (isa(D) && useInlineVisibilityHidden(FD) &&
+if (isExternallyVisible(LV.getLinkage()) &&
+isa(D) && useInlineVisibilityHidden(FD) &&
 !LV.isVisibilityExplicit() &&
 !Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar) {
   assert(cast(D)->isStaticLocal());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137373: [Test][[AIX][p] Add 64-bit linker invocation tests

2022-11-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

LGTM.

Test only patch is safe to commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137373

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


[PATCH] D137372: [Test][[AIX][pg] Add 32-bit linker invocation tests

2022-11-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

LGTM.

Test only patch is safe to commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137372

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


[PATCH] D137373: [AIX][p] Add 64-bit Test Case to Linker Tests

2022-11-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

Suggest: [Test][AIX][p] Add 64-bit driver expected output

No summary required.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137373

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


[PATCH] D137372: [AIX][pg] Add 32-bit Test Case to Linker Tests

2022-11-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

Use the [Test] tag in the abstract.

Suggest: "[Test][AIX][pg] Add 32-bit expected driver output"

No need for a summary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137372

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


[PATCH] D135384: [AIX] Enable the use of the -pg flag

2022-10-11 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: llvm/lib/Transforms/Utils/EntryExitInstrumenter.cpp:38
+const std::string  = M.getTargetTriple();
+if (targetTriple.find("powerpc-ibm-aix") == std::string::npos ||
+targetTriple.find("powerpc64-ibm-aix") == std::string::npos) {

Please use isOSAIX


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135384

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


[PATCH] D135384: [AIX] Enable the use of the -pg flag

2022-10-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:754
   : OSTargetInfo(Triple, Opts) {
+this->MCountName = "__mcount.aix";
 this->TheCXXABI.set(TargetCXXABI::XL);

Suggest sticking with the normal mcount name and remapping on the call 
insertion when the target is AIX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135384

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


[PATCH] D135384: Enable the use of the -pg flag

2022-10-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/test/CodeGen/mcount-aix.c:2
+// RUN: %clang_cc1 -pg -no-opaque-pointers -triple powerpc-ibm-aix7.2.0.0 -S 
-emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -pg -no-opaque-pointers -triple powerpc64-ibm-aix7.2.0.0 -S 
-emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK64
+

Is it necessary to specify -no-opaque-pointers for this test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135384

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


[PATCH] D128223: [clang] Linkage of static locals may require inspecting visibility

2022-06-20 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm created this revision.
cebowleratibm added a reviewer: daltenty.
Herald added a project: All.
cebowleratibm requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

An assertion failure was encountered after https://reviews.llvm.org/D126340:

llvm/clang/lib/AST/Decl.cpp:1510: clang::LinkageInfo 
clang::LinkageComputer::getLVForDecl(const clang::NamedDecl *, 
clang::LVComputationKind): Assertion `D->getCachedLinkage() == LV.getLinkage()' 
failed.

See chromium bug 
 for a 
reproducer.

Note D126340  was reverted and re-landed.  
The original problem can still be reproduced using the appropriate options as 
outlined in the new test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128223

Files:
  clang/lib/AST/Decl.cpp
  clang/test/CodeGenCXX/linkage-static-local-crash.cpp


Index: clang/test/CodeGenCXX/linkage-static-local-crash.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/linkage-static-local-crash.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix 
-mdefault-visibility-export-mapping=explicit -fvisibility-inlines-hidden 
-emit-llvm %s -o - | FileCheck %s
+
+struct C {
+  template  
+  __attribute__((__visibility__("hidden"))) 
+  static int& f() {
+static int g = 42;
+return g;
+  }
+};
+
+template
+void foo(T i) { C::f(); }
+
+void bar() {
+  foo([]{});
+}
+
+// CHECK: @"_ZZN1C1fIZ3barvE3$_0EERivE1g" = internal global i32 42, align 4
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1349,19 +1349,24 @@
 // If a function is hidden by -fvisibility-inlines-hidden option and
 // is not explicitly attributed as a hidden function,
 // we should not make static local variables in the function hidden.
-LV = getLVForDecl(FD, computation);
-if (isa(D) && useInlineVisibilityHidden(FD) &&
-!LV.isVisibilityExplicit() &&
-!Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar) {
+bool mayBeVisible = 
+isa(D) && useInlineVisibilityHidden(FD) &&
+!Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar;
+LVComputationKind nestedComputation =
+mayBeVisible
+? LVComputationKind(computation.getExplicitVisibilityKind())
+: computation;
+LV = getLVForDecl(FD, nestedComputation);
+if (mayBeVisible && !LV.isVisibilityExplicit()) {
   assert(cast(D)->isStaticLocal());
   // If this was an implicitly hidden inline method, check again for
   // explicit visibility on the parent class, and use that for static 
locals
   // if present.
   if (const auto *MD = dyn_cast(FD))
-LV = getLVForDecl(MD->getParent(), computation);
+LV = getLVForDecl(MD->getParent(), nestedComputation);
   if (!LV.isVisibilityExplicit()) {
 Visibility globalVisibility =
-computation.isValueVisibility()
+nestedComputation.isValueVisibility()
 ? Context.getLangOpts().getValueVisibilityMode()
 : Context.getLangOpts().getTypeVisibilityMode();
 return LinkageInfo(VisibleNoLinkage, globalVisibility,


Index: clang/test/CodeGenCXX/linkage-static-local-crash.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/linkage-static-local-crash.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix -mdefault-visibility-export-mapping=explicit -fvisibility-inlines-hidden -emit-llvm %s -o - | FileCheck %s
+
+struct C {
+  template  
+  __attribute__((__visibility__("hidden"))) 
+  static int& f() {
+static int g = 42;
+return g;
+  }
+};
+
+template
+void foo(T i) { C::f(); }
+
+void bar() {
+  foo([]{});
+}
+
+// CHECK: @"_ZZN1C1fIZ3barvE3$_0EERivE1g" = internal global i32 42, align 4
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1349,19 +1349,24 @@
 // If a function is hidden by -fvisibility-inlines-hidden option and
 // is not explicitly attributed as a hidden function,
 // we should not make static local variables in the function hidden.
-LV = getLVForDecl(FD, computation);
-if (isa(D) && useInlineVisibilityHidden(FD) &&
-!LV.isVisibilityExplicit() &&
-!Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar) {
+bool mayBeVisible = 
+isa(D) && useInlineVisibilityHidden(FD) &&
+!Context.getLangOpts().VisibilityInlinesHiddenStaticLocalVar;
+LVComputationKind nestedComputation =
+mayBeVisible
+? LVComputationKind(computation.getExplicitVisibilityKind())
+: computation;
+LV = getLVForDecl(FD, 

[PATCH] D122519: [AIX] XFAIL test for lack of visibility support

2022-03-28 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

The AIX default of ignoring source-level visibility is problematic.  I agree 
the test should be xfailed for AIX.

You can put [NFC] and [tests] to the commit.  Should be safe to commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122519

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


[PATCH] D122497: [clang][NFC] Add filescope array initialization test

2022-03-25 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm created this revision.
cebowleratibm added a reviewer: AaronLiu.
cebowleratibm added a project: clang.
Herald added a project: All.
cebowleratibm requested review of this revision.
Herald added a subscriber: cfe-commits.

This test is based on a customer-reported failure in an XL compiler, added here 
to improve clang regression testing.  The primary purpose of the test is to 
ensure that the array initializations can be evaluated without the need for 
runtime initialization.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122497

Files:
  clang/test/CodeGen/array-init-2.c


Index: clang/test/CodeGen/array-init-2.c
===
--- /dev/null
+++ clang/test/CodeGen/array-init-2.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
+
+typedef enum {
+   a,
+   b,
+   c,
+   d,
+   e,
+   f,
+   g,
+   h
+} E;
+
+typedef struct {
+   E c;
+   int val;
+} Entry;
+
+static const Entry entries[] = {
+   {a,},
+   {b,},
+   {c,},
+   {d,},
+   {e,},
+   {f,},
+   {g,},
+   {h,}
+};
+
+const Entry *list[] = {
+   entries,
+   entries,
+   entries
+};
+
+// CHECK: %struct.Entry = type { [[E:i[0-9]+]], i32 }
+// CHECK: @entries = internal constant [8 x %struct.Entry] [%struct.Entry 
zeroinitializer, %struct.Entry { [[E]] 1, i32 0 }, %struct.Entry { [[E]] 2, i32 
0 }, %struct.Entry { [[E]] 3, i32 0 }, %struct.Entry { [[E]] 4, i32 0 }, 
%struct.Entry { [[E]] 5, i32 0 }, %struct.Entry { [[E]] 6, i32 0 }, 
%struct.Entry { [[E]] 7, i32 0 }], align 4
+// CHECK: @list = global [3 x %struct.Entry*] [%struct.Entry* getelementptr 
inbounds ([8 x %struct.Entry], [8 x %struct.Entry]* @entries, i32 0, i32 0), 
%struct.Entry* getelementptr inbounds ([8 x %struct.Entry], [8 x 
%struct.Entry]* @entries, i32 0, i32 0), %struct.Entry* getelementptr inbounds 
([8 x %struct.Entry], [8 x %struct.Entry]* @entries, i32 0, i32 0)], align 8


Index: clang/test/CodeGen/array-init-2.c
===
--- /dev/null
+++ clang/test/CodeGen/array-init-2.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
+
+typedef enum {
+   a,
+   b,
+   c,
+   d,
+   e,
+   f,
+   g,
+   h
+} E;
+
+typedef struct {
+   E c;
+   int val;
+} Entry;
+
+static const Entry entries[] = {
+   {a,},
+   {b,},
+   {c,},
+   {d,},
+   {e,},
+   {f,},
+   {g,},
+   {h,}
+};
+
+const Entry *list[] = {
+   entries,
+   entries,
+   entries
+};
+
+// CHECK: %struct.Entry = type { [[E:i[0-9]+]], i32 }
+// CHECK: @entries = internal constant [8 x %struct.Entry] [%struct.Entry zeroinitializer, %struct.Entry { [[E]] 1, i32 0 }, %struct.Entry { [[E]] 2, i32 0 }, %struct.Entry { [[E]] 3, i32 0 }, %struct.Entry { [[E]] 4, i32 0 }, %struct.Entry { [[E]] 5, i32 0 }, %struct.Entry { [[E]] 6, i32 0 }, %struct.Entry { [[E]] 7, i32 0 }], align 4
+// CHECK: @list = global [3 x %struct.Entry*] [%struct.Entry* getelementptr inbounds ([8 x %struct.Entry], [8 x %struct.Entry]* @entries, i32 0, i32 0), %struct.Entry* getelementptr inbounds ([8 x %struct.Entry], [8 x %struct.Entry]* @entries, i32 0, i32 0), %struct.Entry* getelementptr inbounds ([8 x %struct.Entry], [8 x %struct.Entry]* @entries, i32 0, i32 0)], align 8
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D121927: [Clang] Work with multiple pragmas weak before definition

2022-03-18 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

Makes sense to me.




Comment at: clang/include/clang/Sema/Weak.h:35
   inline SourceLocation getLocation() const { return loc; }
-  void setUsed(bool Used=true) { used = Used; }
-  inline bool getUsed() { return used; }
-  bool operator==(WeakInfo RHS) const {
-return alias == RHS.getAlias() && loc == RHS.getLocation();
-  }
-  bool operator!=(WeakInfo RHS) const { return !(*this == RHS); }
+  void setUsed(bool Used = true) = delete;
+  inline bool getUsed() const = delete;

For my selfish education: what is the purpose of marking this deleted rather 
than actually deleting it?



Comment at: clang/test/CodeGen/pragma-weak.c:144
+/ PR28611: Try multiple aliases of same undeclared symbol or alias
+#pragma weak undecfunc_alias1 = undecfunc
+#pragma weak undecfunc_alias3 = undecfunc_alias2 // expected-warning {{alias 
will always resolve to undecfunc}}

small suggestion for test: repeat this line so that you cover the case where 
you're collecting identical WeakInfos to the same AliasName.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121927

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


[PATCH] D108917: [AIX][PowerPC] Define __powerpc and __PPC macros

2021-09-01 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D108917/new/

https://reviews.llvm.org/D108917

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


[PATCH] D108917: [AIX][PowerPC] Define __powerpc and __PPC macros

2021-09-01 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/test/Preprocessor/init-ppc.c:520
 // PPC-AIX:#define __POWERPC__ 1
+// PPC-AIX:#define __PPC 1
 // PPC-AIX:#define __PPC__ 1

I suggest adding the negative test for the non AIX target for both __PPC 
and__powerpc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108917

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


[PATCH] D108917: [PowerPC] Define __powerpc and __PPC macros

2021-09-01 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

The XL compiler only defined this weird form of the macros on AIX, but not on 
the XL Linux on Power compiler.  I think it's preferable that we define these 
macros only on AIX and in the source/commit messages indicate that we're only 
doing so for AIX XL C/C++ compatibility.  Users should prefer the __PPC__ and 
__powerpc__ macros.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108917

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


[PATCH] D108917: [AIX] Define __powerpc and __PPC macros

2021-08-31 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added a comment.
This revision now requires changes to proceed.

I'd like to see the rationale for adding these forms of the macros in the 
review and also in the extended commit message.  These forms are being added 
primarily because the AIX XL compiler documented and defined them.  The patch 
itself looks fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108917

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-10 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

> Given that we have a legacy XL macro with no legacy cross compiler I think 
> it's fine if we set this according to the target only.  It's fully redundant 
> to `_AIX ` but we'll define it for any working use-case with the current xlC 
> compiler.  If IBM has a compelling use case for a host-specific macro we can 
> always revive this discussion.  For now, you're probably making us from 
> making a mistake ;)

follow up in https://reviews.llvm.org/D107825


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

In D107242#2934611 , @joerg wrote:

> clang is fundamentally a cross-compiler only. I don't see any point for 
> having host-specific branches in this case at all. Either the macro should be 
> specified for the target all the time or not at all, but it should most 
> definitely not depend on the host. That's actually breaking a number of 
> existing use case for clang in subtle ways, e.g. partially preprocessed files 
> (`-frewrite-includes`) should behave the same on any platform given the same 
> command line.

Given that we have a legacy XL macro with no legacy cross compiler I think it's 
fine if we set this according to the target only.  It's fully redundant to 
`_AIX ` but we'll define it for any working use-case with the current xlC 
compiler.  If IBM has a compelling use case for a host-specific macro we can 
always revive this discussion.  For now, you're probably making us from making 
a mistake ;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

In D107242#2932289 , @joerg wrote:

> I'm puzzled by this change. I don't think we have any case so far where the 
> compiler behavior changes with the host OS and I don't think it should. 
> What's the point / use case of this macro?

__HOS_AIX__ is a macro defined by the XL C/C++ compilers on AIX.  Although 
there was never an AIX cross compiler offering from IBM, the intention of the 
macro was to indicate that the host is AIX.  __HOS_AIX__ is being defined to 
minimize porting pain for existing code compiled with xlc/xlC.  Given that LLVM 
has the infrastructure to be a cross-compiler, I consider it important to 
implement the macro to the original intention.  Because the macro is a "legacy" 
AIX xlc macro I don't think it's relevant to define for non-AIX targets.  If 
there's no objection to the change I can work with Jake to elaborate on the 
comments with an improved commit message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107506: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-08-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.

The new version is better than the previous.  LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107506

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-06 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D107242/new/

https://reviews.llvm.org/D107242

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


[PATCH] D107244: [AIX] Define _ARCH_PPC64 macro for 32-bit

2021-08-06 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D107244/new/

https://reviews.llvm.org/D107244

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


[PATCH] D107244: [AIX] Define _ARCH_PPC64 macro for 32-bit

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Basic/Targets/PPC.cpp:260
+  } else if (getTriple().isOSAIX()) {
+// Also define _ARCH_PPC64 for 32-bit on AIX.
+Builder.defineMacro("_ARCH_PPC64");

Suggest:

// The XL compilers on AIX define _ARCH_PPC64 for both 32 and 64-bit modes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107244

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:306
+  llvm::Triple HostTriple(llvm::sys::getProcessTriple());
+  if (HostTriple.isOSAIX() && getTriple().isOSAIX()) {
+Builder.defineMacro("__HOS_AIX__");

suggest using a temp rather than unnecessarily declaring the local var:

 if (Triple(sys::getProcessTriple()).isOSAIX() ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/test/Preprocessor/not-host-aix.c:2
+// UNSUPPORTED: system-aix
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
+// PPC-LINUX-NOT:#define __HOS_AIX__ 1

this should specify an aix triple.  The test doesn't run on an aix host and any 
other host should not define the macro even with an aix target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107506: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/test/Sema/aix-pragma-align-packed-warn.c:13
+  short a : 8;  // expected-warning {{#pragma align(packed) may not be 
compatible with objects generated with AIX XL C/C++}}
+  short b : 8;  // expected-warning {{#pragma align(packed) may not be 
compatible with objects generated with AIX XL C/C++}}
+  int c;

It's undesirable to warn for each bitfield member.  Perhaps diagnose this in 
Sema::ActOnTagFinishDefinition?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107506

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


[PATCH] D107506: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

It would be nice if the diagnostic could be deferred to layout, in case the 
struct is defined but not used in a header, but I understand that #pragma 
pack(1) and #pragma align(packed) become ambiguous at the point of layout.  I 
think this is a reasonable diagnostic given the impact of silently incompatible 
codegen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107506

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


[PATCH] D107506: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-08-05 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:238
+if (this->Context.getTargetInfo().getTriple().isOSAIX())
+  Diag(PragmaLoc, diag::warn_pragma_align_not_xl_compatible);
 Action = Sema::PSK_Push_Set;

Does this diagnostic need to be emitted for any struct or only structs that 
contain bitfield members?  As it is it will be very verbose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107506

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


[PATCH] D107242: [AIX] Define __HOS_AIX__ macro

2021-08-04 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Basic/Targets/OSTargets.h:679
 Builder.defineMacro("__TOS_AIX__");
+Builder.defineMacro("__HOS_AIX__");
 

__HOS_AIX__ should only be defined if both the host and the target OS are AIX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107242

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


[PATCH] D107241: [AIX] Define __THW_BIG_ENDIAN__ macro

2021-08-04 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D107241/new/

https://reviews.llvm.org/D107241

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


[PATCH] D107243: [AIX] Define __THW_PPC__ macro

2021-08-04 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

LGTM.  __THW_PPC__ is a macro historically defined by xlc on AIX and defining 
it may help users port to clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107243

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


[PATCH] D107244: [AIX] Define _ARCH_PPC64 macro for 32-bit

2021-08-04 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added a comment.
This revision now requires changes to proceed.

The divergence with GCC is regrettable.  Unfortunately defining _ARCH_PPC64 in 
32-bit has been a long-standing discrepancy between xlc and gcc and one I don't 
expect gcc to change.  This patch is preferable in order to retain 
preprocessing behaviour on AIX for customers porting 32-bit AIX xlc 
applications to clang.

My request for change is simply to add a brief explanation in the code, 
otherwise, it looks like a coding error.




Comment at: clang/lib/Basic/Targets/PPC.cpp:260
+  } else {
+if (getTriple().isOSAIX())
+  Builder.defineMacro("_ARCH_PPC64");

A comment is warranted here to explain that __ARCH_PPC64 is only defined in 
32-bit on AIX.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107244

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


[PATCH] D105477: [AIX] Define __LONGDOUBLE64 macro

2021-07-21 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

The decision was made to make -mlong-double-128 an error on AIX: 
https://reviews.llvm.org/D106074 [AIX] Clang's library integration support for 
128-bit long double is incomplete on AIX.

So I think your patch is ready to land.  LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105477

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


[PATCH] D106074: [AIX] Clang's library integration support for 128-bit long double is incomplete on AIX.

2021-07-20 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

LGTM.


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

https://reviews.llvm.org/D106074

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


[PATCH] D106074: [AIX] Emit unsupported 128-bit long double option for AIX

2021-07-19 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4845
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_double_128)) {
+// AIX doesn't support 128-bit long double yet.
+if (Triple.isOSAIX())

It's not that AIX doesn't support 128-bit long double.  The xlc compiler has 
-qldbl128, which links in different libraries for 128-bit.  The XL compilers 
use -lc128 and -lC128 so there are binary compatibility concerns that need to 
be investigated.

I suggest this comment be updated accordingly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106074

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


[PATCH] D105477: [AIX] Define __LONGDOUBLE64 macro

2021-07-09 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

The change made me think we should add the negative test with 
-mlong-double-128, but then I thought we should probably make that an error 
until we've sorted through the AIX binary compat implications and tested it.  
So the patch you've proposed makes sense to me and we should follow up with 
handling for mlong-double-128.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105477

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


[PATCH] D105477: [AIX] Define __LONGDOUBLE64 macro

2021-07-06 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Basic/Targets/PPC.cpp:175
 
+  if (getTriple().isOSAIX() && LongDoubleWidth == 64) {
+Builder.defineMacro("__LONGDOUBLE64");

I suggest querying the -mlong-double-64 option and asserting that the 
LongDoubleWidth is 64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105477

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


[PATCH] D103587: [AIX] Define __TOS_AIX__ predefined macro

2021-07-06 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D103587/new/

https://reviews.llvm.org/D103587

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


[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

2021-06-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm 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/D103707/new/

https://reviews.llvm.org/D103707

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


[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

2021-06-07 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added a comment.
This revision now requires changes to proceed.

Would like you to prune the new tests, then I think this will be ready to land.




Comment at: clang/test/Preprocessor/init-ppc.c:726
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c1x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s

Suggest pruning some of these.  I don't think it's necessary to test every 
visible -std level.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

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


[PATCH] D103587: [AIX] Transfer predefined macros

2021-06-04 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added a comment.
This revision now requires changes to proceed.

I think it makes sense to split the __STDC macro changes and __TOS_AIX__ into 
different patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

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


[PATCH] D103587: [AIX] Transfer predefined macros

2021-06-03 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:680
+
+if (Opts.LangStd == LangStandard::lang_c11 ||
+Opts.LangStd == LangStandard::lang_gnu11 ||

I think LangStandard::isC11() does what you want.  You wouldn't want to update 
this code every time a new C standard comes out.



Comment at: clang/test/Preprocessor/init-ppc.c:742
+
+// RUN: %clang_cc1 -x c -std=c89 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// RUN: %clang_cc1 -x c -std=c90 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s

I didn't mean to suggest adding all of them.  One negative test on c99 would 
suffice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

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


[PATCH] D103587: [AIX] Transfer predefined macros

2021-06-03 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Basic/Targets/OSTargets.h:680
+
+if (Opts.LangStd == LangStandard::lang_c11 ||
+Opts.LangStd == LangStandard::lang_gnu11) {

Should set these macros in C11 and higher levels.



Comment at: clang/test/Preprocessor/init-ppc.c:544
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-NOT:#define __STDC_NO_THREADS__ 1

I think it's sufficient to test the __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ 
only as you've added below where the -std is explicitly controlled.  I prefer 
to avoid expecting these macros for the -std default, which may change.



Comment at: clang/test/Preprocessor/init-ppc.c:729
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c1x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s

suggest adding the negative test for pre C11 modes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

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


[PATCH] D103587: [AIX] Transfer predefined macros

2021-06-03 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm requested changes to this revision.
cebowleratibm added a comment.
This revision now requires changes to proceed.

Please rework the test update into init-ppc.c




Comment at: clang/lib/Basic/Targets/PPC.cpp:95
   Builder.defineMacro("_ARCH_PPC");
+  Builder.defineMacro("__THW_PPC__");
   Builder.defineMacro("__powerpc__");

The XL compilers define this macro for Power but GCC does not.  The macro is 
redundant and I recommend we not carry it forward to Linux.  There's probably a 
case to define it on AIX where the prevalent XL compilers have always defined 
it.



Comment at: clang/test/Preprocessor/init-aix.c:1
+// RUN: %clang_cc1 -E -dM < /dev/null | FileCheck -match-full-lines 
-check-prefix AIX %s
+// AIX:#define __THW_PPC__ 1

There are some AIX macro tests already in init-ppc.c.  Note the target triple 
should be specified or this test will break when run on a non AIX host.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

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


[PATCH] D101130: [PowerPC] Provide XL-compatible builtins in altivec.h

2021-04-23 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat.c:2
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+  // RUN:   -triple powerpc64-unknown-unknown -emit-llvm %s -o - \

Suggest adding an explicit -mcpu.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101130

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


[PATCH] D94986: Remove requirement for -maltivec to be used when using -mabi=vec-extabi or -mabi=vec-default when not using vector code

2021-01-19 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added inline comments.



Comment at: clang/test/CodeGen/altivec.c:1
 // RUN: %clang_cc1 -target-feature +altivec -triple powerpc-unknown-unknown 
-emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 // RUN: %clang_cc1 -target-feature +altivec -triple powerpcle-unknown-unknown 
-emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-LE

I think it would be a good idea to explicitly specify the cpu while you're in 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94986

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


[PATCH] D94986: Remove requirement for -maltivec to be used when using -mabi=vec-extabi or -mabi=vec-default when not using vector code

2021-01-19 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm accepted this revision.
cebowleratibm added a comment.
This revision is now accepted and ready to land.

Minor suggestion to keep and remap some of the diagnostic cases.




Comment at: clang/test/CodeGen/altivec.c:13
 // RUN: not %clang -S -emit-llvm -maltivec -target powerpc64-unknown-aix %s 
2>&1 | FileCheck %s --check-prefix=AIX-ERROR 
-// RUN: not %clang -S -emit-llvm -mabi=vec-default -target powerpc-unknown-aix 
%s 2>&1  | FileCheck  %s --check-prefix=AIX-ATVER
-// RUN: not %clang -S -emit-llvm -mabi=vec-extabi -target powerpc-unknown-aix 
%s 2>&1  | FileCheck  %s --check-prefix=AIX-ATVER

You should keep the -mabi=vec-default diagnostic lines and remap them to the 
expected error.  Applies to a few below.



Comment at: clang/test/CodeGen/altivec.c:16
-// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -target 
powerpc64-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: not %clang -S -emit-llvm -mabi=vec-default -target 
powerpc64-unknown-aix %s 2>&1  | FileCheck  %s --check-prefix=AIX-ATVER
-// RUN: not %clang -S -emit-llvm -mabi=vec-extabi -target 
powerpc64-unknown-aix %s 2>&1  | FileCheck  %s --check-prefix=AIX-ATVER

d


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94986

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


[PATCH] D88105: [NFC] [PPC] Add PowerPC expected IR tests for C99 complex

2020-09-23 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm updated this revision to Diff 293917.
cebowleratibm marked 2 inline comments as done.
cebowleratibm added a comment.

Reworked the prefixes and indentation.


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

https://reviews.llvm.org/D88105

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/aix-complex.c
  clang/test/CodeGen/powerpc-c99complex.c

Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- clang/test/CodeGen/powerpc-c99complex.c
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -1,11 +1,13 @@
-// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=PPC64LNX
-// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,AIX
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,AIX
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,PPC64LNX
+// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,PPC64LNX
 // RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=PPC32LNX
 
 _Complex float foo1(_Complex float x) {
   return x;
-// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float %x.{{.*}}) #0 {
-// PPC64LNX: ret { float, float }
+// CHECK-LABEL: define { float, float } @foo1(float %x.{{.*}}, float %x.{{.*}}) #0 {
+// CHECK:   ret { float, float }
 
 // PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 %agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
 // PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, { float, float }* %agg.result, i32 0, i32 0
@@ -16,8 +18,8 @@
 
 _Complex double foo2(_Complex double x) {
   return x;
-// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, double %x.{{.*}}) #0 {
-// PPC64LNX: ret { double, double }
+// CHECK-LABEL: define { double, double } @foo2(double %x.{{.*}}, double %x.{{.*}}) #0 {
+// CHECK:   ret { double, double }
 
 // PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 %agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
 // PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double }, { double, double }* %agg.result, i32 0, i32 0
@@ -28,12 +30,15 @@
 
 _Complex long double foo3(_Complex long double x) {
   return x;
-// PPC64LNX-LDBL128-LABEL:define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 %x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
-// PPC64LNX-LDBL128:  ret { ppc_fp128, ppc_fp128 }
+// AIX-LABEL:   define { double, double } @foo3(double %x.{{.*}}, double %x.{{.*}}) #0 {
+// AIX: ret { double, double }
 
-// PPC32LNX-LABEL: define void @foo3({ ppc_fp128, ppc_fp128 }* noalias sret align 16 %agg.result, { ppc_fp128, ppc_fp128 }* byval({ ppc_fp128, ppc_fp128 }) align 16 %x) #0 {
-// PPC32LNX:   [[RETREAL:%.*]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 0
-// PPC32LNX-NEXT:  [[RETIMAG:%.*]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 1
-// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETREAL]], align 16
-// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETIMAG]], align 16
+// PPC64LNX-LABEL:  define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 %x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
+// PPC64LNX:ret { ppc_fp128, ppc_fp128 }
+
+// PPC32LNX-LABEL:  define void @foo3({ ppc_fp128, ppc_fp128 }* noalias sret align 16 %agg.result, { ppc_fp128, ppc_fp128 }* byval({ ppc_fp128, ppc_fp128 }) align 16 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store ppc_fp128 %{{.*}}, ppc_fp128* [[RETREAL]], align 16
+// PPC32LNX-NEXT:   store ppc_fp128 %{{.*}}, ppc_fp128* [[RETIMAG]], align 16
 }
Index: clang/test/CodeGen/aix-complex.c
===
--- clang/test/CodeGen/aix-complex.c
+++ /dev/null
@@ -1,10 +0,0 @@
-// REQUIRES: powerpc-registered-target
-// RUN: not %clang_cc1 -triple powerpc-unknown-aix \
-// RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
-// RUN: not %clang_cc1 -triple powerpc64-unknown-aix \
-// RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
-
-// CHECK: fatal error: error in backend: complex type is not supported on AIX yet
-_Complex float foo_float(_Complex float x) {
-  

[PATCH] D88130: [PPC] [AIX] Implement calling convention IR for C99 complex types on AIX

2020-09-22 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm created this revision.
cebowleratibm added reviewers: ZarkoCA, daltenty, sfertile.
Herald added subscribers: cfe-commits, nemanjai.
Herald added a project: clang.
cebowleratibm requested review of this revision.

Builds on D88105  to add AIX calling 
convention logic to Clang for C99 complex types on AIX.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88130

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/aix-complex.c
  clang/test/CodeGen/powerpc-c99complex.c


Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- clang/test/CodeGen/powerpc-c99complex.c
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -1,11 +1,13 @@
-// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=PPC64LNX
-// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=CHECK,CHECK-NOLDBL128
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck 
%s --check-prefixes=CHECK,CHECK-NOLDBL128
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=CHECK,CHECK-LDBL128
+// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=CHECK,CHECK-LDBL128
 // RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefix=PPC32LNX
 
 _Complex float foo1(_Complex float x) {
   return x;
-// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float 
%x.{{.*}}) #0 {
-// PPC64LNX: ret { float, float }
+// CHECK-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float 
%x.{{.*}}) #0 {
+// CHECK: ret { float, float }
 
 // PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 
%agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
 // PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, 
{ float, float }* %agg.result, i32 0, i32 0
@@ -16,8 +18,8 @@
 
 _Complex double foo2(_Complex double x) {
   return x;
-// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, 
double %x.{{.*}}) #0 {
-// PPC64LNX: ret { double, double }
+// CHECK-LABEL:   define { double, double } @foo2(double %x.{{.*}}, double 
%x.{{.*}}) #0 {
+// CHECK: ret { double, double }
 
 // PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 
%agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
 // PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double 
}, { double, double }* %agg.result, i32 0, i32 0
@@ -28,8 +30,11 @@
 
 _Complex long double foo3(_Complex long double x) {
   return x;
-// PPC64LNX-LDBL128-LABEL:define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 
%x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
-// PPC64LNX-LDBL128:  ret { ppc_fp128, ppc_fp128 }
+// CHECK-NOLDBL128-LABEL:  define { double, double } @foo3(double %x.{{.*}}, 
double %x.{{.*}}) #0 {
+// CHECK-NOLDBL128:ret { double, double }
+
+// CHECK-LDBL128-LABEL:define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 
%x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
+// CHECK-LDBL128:  ret { ppc_fp128, ppc_fp128 }
 
 // PPC32LNX-LABEL: define void @foo3({ ppc_fp128, ppc_fp128 }* noalias sret 
align 16 %agg.result, { ppc_fp128, ppc_fp128 }* byval({ ppc_fp128, ppc_fp128 }) 
align 16 %x) #0 {
 // PPC32LNX:   [[RETREAL:%.*]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 0
Index: clang/test/CodeGen/aix-complex.c
===
--- clang/test/CodeGen/aix-complex.c
+++ /dev/null
@@ -1,10 +0,0 @@
-// REQUIRES: powerpc-registered-target
-// RUN: not %clang_cc1 -triple powerpc-unknown-aix \
-// RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
-// RUN: not %clang_cc1 -triple powerpc64-unknown-aix \
-// RUN:   -emit-llvm -o - %s 2>&1 | FileCheck %s
-
-// CHECK: fatal error: error in backend: complex type is not supported on AIX 
yet
-_Complex float foo_float(_Complex float x) {
-  return x;
-}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -4504,7 +4504,7 @@
 
 ABIArgInfo AIXABIInfo::classifyReturnType(QualType RetTy) const {
   if (RetTy->isAnyComplexType())
-llvm::report_fatal_error("complex type is not supported on AIX yet");
+return ABIArgInfo::getDirect();
 
   if (RetTy->isVectorType())
 llvm::report_fatal_error("vector type is not supported on AIX yet");
@@ -4525,7 +4525,7 @@
   Ty = useFirstFieldIfTransparentUnion(Ty);
 
   if (Ty->isAnyComplexType())
-

[PATCH] D88105: [NFC] [PPC] Add PowerPC expected IR tests for C99 complex

2020-09-22 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm updated this revision to Diff 293625.
cebowleratibm marked an inline comment as done.
cebowleratibm added a comment.

Added ppc64le target.


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

https://reviews.llvm.org/D88105

Files:
  clang/test/CodeGen/powerpc-c99complex.c


Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- /dev/null
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefix=PPC32LNX
+
+_Complex float foo1(_Complex float x) {
+  return x;
+// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float 
%x.{{.*}}) #0 {
+// PPC64LNX: ret { float, float }
+
+// PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 
%agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, 
{ float, float }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { float, float }, 
{ float, float }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETREAL]], align 4
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETIMAG]], align 4
+}
+
+_Complex double foo2(_Complex double x) {
+  return x;
+// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, 
double %x.{{.*}}) #0 {
+// PPC64LNX: ret { double, double }
+
+// PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 
%agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double 
}, { double, double }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { double, double 
}, { double, double }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store double %{{.*}}, double* [[RETREAL]], align 8
+// PPC32LNX-NEXT:   store double %{{.*}}, double* [[RETIMAG]], align 8
+}
+
+_Complex long double foo3(_Complex long double x) {
+  return x;
+// PPC64LNX-LDBL128-LABEL:define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 
%x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
+// PPC64LNX-LDBL128:  ret { ppc_fp128, ppc_fp128 }
+
+// PPC32LNX-LABEL: define void @foo3({ ppc_fp128, ppc_fp128 }* noalias sret 
align 16 %agg.result, { ppc_fp128, ppc_fp128 }* byval({ ppc_fp128, ppc_fp128 }) 
align 16 %x) #0 {
+// PPC32LNX:   [[RETREAL:%.*]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:  [[RETIMAG:%.*]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETREAL]], align 16
+// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETIMAG]], align 16
+}


Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- /dev/null
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple ppc64le-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=PPC32LNX
+
+_Complex float foo1(_Complex float x) {
+  return x;
+// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float %x.{{.*}}) #0 {
+// PPC64LNX: ret { float, float }
+
+// PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 %agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, { float, float }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { float, float }, { float, float }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETREAL]], align 4
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETIMAG]], align 4
+}
+
+_Complex double foo2(_Complex double x) {
+  return x;
+// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, double %x.{{.*}}) #0 {
+// PPC64LNX: ret { double, double }
+
+// PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 %agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double }, { double, double }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   

[PATCH] D88105: [NFC] [PPC] Add PowerPC expected IR tests for C99 complex

2020-09-22 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm created this revision.
cebowleratibm added reviewers: daltenty, ZarkoCA, sfertile.
Herald added subscribers: cfe-commits, shchenz, nemanjai.
Herald added a project: clang.
cebowleratibm requested review of this revision.

Adding this test so that I can extend it in a follow on patch with expected IR 
for AIX when I implement complex handling in AIXABIInfo.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88105

Files:
  clang/test/CodeGen/powerpc-c99complex.c


Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- /dev/null
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | 
FileCheck %s --check-prefix=PPC32LNX
+
+_Complex float foo1(_Complex float x) {
+  return x;
+// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float 
%x.{{.*}}) #0 {
+// PPC64LNX: ret { float, float }
+
+// PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 
%agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, 
{ float, float }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { float, float }, 
{ float, float }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETREAL]], align 4
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETIMAG]], align 4
+}
+
+_Complex double foo2(_Complex double x) {
+  return x;
+// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, 
double %x.{{.*}}) #0 {
+// PPC64LNX: ret { double, double }
+
+// PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 
%agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double 
}, { double, double }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { double, double 
}, { double, double }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store double %{{.*}}, double* [[RETREAL]], align 8
+// PPC32LNX-NEXT:   store double %{{.*}}, double* [[RETIMAG]], align 8
+}
+
+_Complex long double foo3(_Complex long double x) {
+  return x;
+// PPC64LNX-LDBL128-LABEL:define { ppc_fp128, ppc_fp128 } @foo3(ppc_fp128 
%x.{{.*}}, ppc_fp128 %x.{{.*}}) #0 {
+// PPC64LNX-LDBL128:  ret { ppc_fp128, ppc_fp128 }
+
+// PPC32LNX-LABEL: define void @foo3({ ppc_fp128, ppc_fp128 }* noalias sret 
align 16 %agg.result, { ppc_fp128, ppc_fp128 }* byval({ ppc_fp128, ppc_fp128 }) 
align 16 %x) #0 {
+// PPC32LNX:   [[RETREAL:%.*]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:  [[RETIMAG:%.*]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETREAL]], align 16
+// PPC32LNX-NEXT:  store ppc_fp128 %{{.*}}, ppc_fp128* [[RETIMAG]], align 16
+}


Index: clang/test/CodeGen/powerpc-c99complex.c
===
--- /dev/null
+++ clang/test/CodeGen/powerpc-c99complex.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefixes=PPC64LNX
+// RUN: %clang_cc1 -triple powerpc-unknown-linux -emit-llvm %s -o - | FileCheck %s --check-prefix=PPC32LNX
+
+_Complex float foo1(_Complex float x) {
+  return x;
+// PPC64LNX-LABEL:   define { float, float } @foo1(float %x.{{.*}}, float %x.{{.*}}) #0 {
+// PPC64LNX: ret { float, float }
+
+// PPC32LNX-LABEL:  define void @foo1({ float, float }* noalias sret align 4 %agg.result, { float, float }* byval({ float, float }) align 4 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { float, float }, { float, float }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { float, float }, { float, float }* %agg.result, i32 0, i32 1
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETREAL]], align 4
+// PPC32LNX-NEXT:   store float %{{.*}}, float* [[RETIMAG]], align 4
+}
+
+_Complex double foo2(_Complex double x) {
+  return x;
+// PPC64LNX-LABEL:   define { double, double } @foo2(double %x.{{.*}}, double %x.{{.*}}) #0 {
+// PPC64LNX: ret { double, double }
+
+// PPC32LNX-LABEL:  define void @foo2({ double, double }* noalias sret align 8 %agg.result, { double, double }* byval({ double, double }) align 8 %x) #0 {
+// PPC32LNX:[[RETREAL:%.*]] = getelementptr inbounds { double, double }, { double, double }* %agg.result, i32 0, i32 0
+// PPC32LNX-NEXT:   [[RETIMAG:%.*]] = getelementptr inbounds { 

[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-20 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

In D74015#1882933 , @sfertile wrote:

> Patch LGTM as far a formatting/naming/testing etc. C++ specifics is outside 
> my wheelhouse though, so I can't confirm things like the tail padding rules 
> are correct for AIX. Because of that I'm not comfortable being the one to 
> accept the patch.


I checked the IBM xlclang source and can confirm the implementation of 
getTailPaddingUseRules is consistent with the proposed patch.  Sean, does that 
address your concern?

The only change I would like to see is an update to the "XL" enumerator comment 
to be more descriptive of what the "XL" ABI is.




Comment at: clang/include/clang/Basic/TargetCXXABI.h:116
+///   - static initialization is adjusted to use sinit and sterm functions;
+XL_Clang,
+

cebowleratibm wrote:
> cebowleratibm wrote:
> > sfertile wrote:
> > > Xiangling_L wrote:
> > > > daltenty wrote:
> > > > > Why the underscore in the name? This is a bit inconsistent with both 
> > > > > the LLVM naming convention here and the name as it appears in other 
> > > > > sources.
> > > > There are various AIX ABI. So to distinguish the one we are 
> > > > implementing, we choose `XL` and `Clang` as two parts of the abi name. 
> > > > `XL` - not g++;
> > > > `Clang` - it's a  ABI implemented in Clang;
> > > > 
> > > > And also `XLClang` is misleading because it represents our AIX XL C/C++ 
> > > > compiler itself externally.
> > > So do we need the 'Clang' part in the name? For example the ABI below is 
> > > not `Microsoft_Clang`. Or is the `_Clang` differentiating between 
> > > multiple XL ABIs?
> > I suspect the concern is that "XL" ABI is ambiguious between legacy xlC and 
> > xlclang++.  The two differ at the C++11 language level so perhaps it makes 
> > sense to have "XLC++11"?  (and theoretically just "XL" if we ever decide 
> > xlC)
> Another suggestion: "IBMXL" or "IBMXLC++11"
To summarize some off phabricator discussion: we reached consensus on "XL".  It 
was not felt that "IBM" needs to be in the name and that a comment by the 
enumerator definition is sufficient.

Note that "XL" refers to ABI compatibiliity with the AIX xlclang compiler and 
not xlC.  If we need xlC compatibility that would be yet another ABI to add at 
another time.

The comment should be updated to provide more background on what the "XL" ABI 
is.


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

https://reviews.llvm.org/D74015



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


[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-18 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

From my perspective, the only issue holding this up is settling on the name.  
I'd like to hammer that out and get this committed.




Comment at: clang/include/clang/Basic/TargetCXXABI.h:116
+///   - static initialization is adjusted to use sinit and sterm functions;
+XL_Clang,
+

cebowleratibm wrote:
> sfertile wrote:
> > Xiangling_L wrote:
> > > daltenty wrote:
> > > > Why the underscore in the name? This is a bit inconsistent with both 
> > > > the LLVM naming convention here and the name as it appears in other 
> > > > sources.
> > > There are various AIX ABI. So to distinguish the one we are implementing, 
> > > we choose `XL` and `Clang` as two parts of the abi name. 
> > > `XL` - not g++;
> > > `Clang` - it's a  ABI implemented in Clang;
> > > 
> > > And also `XLClang` is misleading because it represents our AIX XL C/C++ 
> > > compiler itself externally.
> > So do we need the 'Clang' part in the name? For example the ABI below is 
> > not `Microsoft_Clang`. Or is the `_Clang` differentiating between multiple 
> > XL ABIs?
> I suspect the concern is that "XL" ABI is ambiguious between legacy xlC and 
> xlclang++.  The two differ at the C++11 language level so perhaps it makes 
> sense to have "XLC++11"?  (and theoretically just "XL" if we ever decide xlC)
Another suggestion: "IBMXL" or "IBMXLC++11"


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

https://reviews.llvm.org/D74015



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


[PATCH] D74015: [AIX][Frontend] C++ ABI customizations for AIX boilerplate

2020-02-12 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

Looks fine, but we need to settle on the name for the ABI.  My preference would 
be "XLC++11", or perhaps "XLCXX11" (I propose the latter because of the common 
reference CXXABI.)




Comment at: clang/include/clang/Basic/TargetCXXABI.h:116
+///   - static initialization is adjusted to use sinit and sterm functions;
+XL_Clang,
+

sfertile wrote:
> Xiangling_L wrote:
> > daltenty wrote:
> > > Why the underscore in the name? This is a bit inconsistent with both the 
> > > LLVM naming convention here and the name as it appears in other sources.
> > There are various AIX ABI. So to distinguish the one we are implementing, 
> > we choose `XL` and `Clang` as two parts of the abi name. 
> > `XL` - not g++;
> > `Clang` - it's a  ABI implemented in Clang;
> > 
> > And also `XLClang` is misleading because it represents our AIX XL C/C++ 
> > compiler itself externally.
> So do we need the 'Clang' part in the name? For example the ABI below is not 
> `Microsoft_Clang`. Or is the `_Clang` differentiating between multiple XL 
> ABIs?
I suspect the concern is that "XL" ABI is ambiguious between legacy xlC and 
xlclang++.  The two differ at the C++11 language level so perhaps it makes 
sense to have "XLC++11"?  (and theoretically just "XL" if we ever decide xlC)



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:4428
+   llvm::Constant *addr) {
+  llvm::report_fatal_error("Static initialization has not been fully"
+   " implemented on XL_Clang ABI yet.");

Omit "fully".  Fix the name XL_Clang when we've settled on a name.



Comment at: clang/test/CodeGen/static-init.cpp:9
+public:
+test(int c) {a = c;}
+~test() {a = 0;}

Nit: formatting.  

The test is fine but I'd usually write this test even more briefly:
struct S { ~S(); } s;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74015



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