[PATCH] D148474: [Clang] Fix ResolveConstructorOverload to not select a conversion function if we are going use copy elision

[Dimitry Andric via Phabricator via cfe-commits]

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

Yes, please. :)


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

https://reviews.llvm.org/D148474

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

[PATCH] D148474: [Clang] Fix ResolveConstructorOverload to not select a conversion function if we are going use copy elision

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D148474#4490041 , @dim wrote:

> FWIW, this fix works for the test cases I had via 
> https://bugs.freebsd.org/269067 and 
> https://github.com/llvm/llvm-project/issues/60182, but I got the following 
> failure

This was with `llvmorg-17-init-17477-ab7ef28eebf` (rG3ab7ef28eebf 
), by the 
way.


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

https://reviews.llvm.org/D148474

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

[PATCH] D148474: [Clang] Fix ResolveConstructorOverload to not select a conversion function if we are going use copy elision

[Dimitry Andric via Phabricator via cfe-commits]

dim requested changes to this revision.
dim added a comment.
This revision now requires changes to proceed.

FWIW, this fix works for the test cases I had via 
https://bugs.freebsd.org/269067 and 
https://github.com/llvm/llvm-project/issues/60182, but I got the following 
failure during check-all:

  
  FAIL: Clang :: SemaCXX/cxx1z-copy-omission.cpp (15698 of 67299)
   TEST 'Clang :: SemaCXX/cxx1z-copy-omission.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 1';   
/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang
 -cc1 -internal-isystem 
/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/lib/clang/17/include
 -nostdsysteminc -std=c++1z -verify -Wno-unused 
/home/dim/src/llvm/llvm-project/clang/test/SemaCXX/cxx1z-copy-omission.cpp
  --
  Exit Code: 134
  
  Command Output (stderr):
  --
  unexpected deduction guide in instantiation stack
  UNREACHABLE executed at 
/home/dim/src/llvm/llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp:1067!
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: 
/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang
 -cc1 -internal-isystem 
/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/lib/clang/17/include
 -nostdsysteminc -std=c++1z -verify -Wno-unused 
/home/dim/src/llvm/llvm-project/clang/test/SemaCXX/cxx1z-copy-omission.cpp
  1.  
/home/dim/src/llvm/llvm-project/clang/test/SemaCXX/cxx1z-copy-omission.cpp:198:8:
 current parser token ';'
  2.  
/home/dim/src/llvm/llvm-project/clang/test/SemaCXX/cxx1z-copy-omission.cpp:176:1:
 parsing namespace 'GH39319'
   #0 0x02ca4727 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x2ca4727)
   #1 0x02ca2508 llvm::sys::RunSignalHandlers() 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x2ca2508)
   #2 0x02ca4f00 SignalHandler(int) Signals.cpp:0:0
   #3 0x000827a15a3e handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
   #4 0x000827a14ff9 thr_sighandler 
/usr/src/lib/libthr/thread/thr_sig.c:247:1
   #5 0x000826e18903 ([vdso]+0x2d3)
   #6 0x00082dc3f97a __sys_thr_kill /usr/obj/usr/src/lib/libc/thr_kill.S:4:0
   #7 0x00082dbb8954 __raise /usr/src/lib/libc/gen/raise.c:0:10
   #8 0x00082dc693e9 abort /usr/src/lib/libc/stdlib/abort.c:73:17
   #9 0x02c23b01 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x2c23b01)
  #10 0x0590e986 clang::Sema::PrintInstantiationStack() 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x590e986)
  #11 0x0504555d clang::Sema::EmitCurrentDiagnostic(unsigned int) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x504555d)
  #12 0x050464ea 
clang::Sema::ImmediateDiagBuilder::~ImmediateDiagBuilder() Sema.cpp:0:0
  #13 0x05046668 
clang::Sema::SemaDiagnosticBuilder::~SemaDiagnosticBuilder() 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x5046668)
  #14 0x053f7c5b clang::Sema::ActOnCallExpr(clang::Scope*, 
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, 
clang::SourceLocation, clang::Expr*) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x53f7c5b)
  #15 0x05920009 clang::TreeTransform<(anonymous 
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) 
SemaTemplateInstantiate.cpp:0:0
  #16 0x0591713d clang::Sema::SubstExpr(clang::Expr*, 
clang::MultiLevelTemplateArgumentList const&) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x591713d)
  #17 0x059615e5 
clang::TemplateDeclInstantiator::VisitNonTypeTemplateParmDecl(clang::NonTypeTemplateParmDecl*)
 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x59615e5)
  #18 0x0599c9a9 void llvm::function_ref::callback_fn(long) 
SemaTemplateInstantiateDecl.cpp:0:0
  #19 0x0503ec8e 
clang::Sema::runWithSufficientStackSpace(clang::SourceLocation, 
llvm::function_ref) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x503ec8e)
  #20 0x059667a2 clang::Sema::SubstDecl(clang::Decl*, 
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) 
(/home/dim/obj/llvmorg-17-init-17477-g3ab7ef28eebf-freebsd13-amd64-ninja-clang-rel-1/bin/clang+0x59667a2)
  #21 0x057c6e6d 

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D152788#4439714 , @shafik wrote:

> Thank you for this improvement!

Well, it would still be nice to have the instantiation trace, as Aaron 
suggested. So that is probably one of those "exercise for the reader" things. :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

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

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric 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 rG69d42eef4bec: [Clang] Show type in enum out of range 
diagnostic (authored by dim).

Changed prior to commit:
  https://reviews.llvm.org/D152788?vs=531013=531441#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -900,7 +900,7 @@
 namespace GH50055 {
 enum E {e1=0, e2=1};
 consteval int testDefaultArgForParam(E eParam = (E)-1) {
-// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for this enumeration type}}
+// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for the enumeration type 'E'}}
   return (int)eParam;
 }
 
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2440,42 +2440,51 @@
 void testValueInRangeOfEnumerationValues() {
   constexpr E1 x1 = static_cast(-8);
   constexpr E1 x2 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for the enumeration type 'E1'}}
   E1 x2b = static_cast(8); // ok, not a constant expression context
 
   constexpr E2 x3 = static_cast(-8);
-  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
   constexpr E2 x4 = static_cast(0);
   constexpr E2 x5 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
 
   constexpr E3 x6 = static_cast(-2048);
   constexpr E3 x7 = static_cast(-8);
   constexpr E3 x8 = static_cast(0);
   constexpr E3 x9 = static_cast(8);
   constexpr E3 x10 = static_cast(2048);
-  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for this enumeration type}}
+  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for the enumeration type 'E3'}}
 
   constexpr E4 x11 = static_cast(0);
   constexpr E4 x12 = static_cast(1);
   constexpr E4 x13 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'E4'}}
 
   constexpr EEmpty x14 = static_cast(0);
   constexpr EEmpty x15 = static_cast(1);
   constexpr EEmpty x16 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'EEmpty'}}
 
   constexpr EFixed x17 = static_cast(100);
   constexpr EScoped x18 = static_cast(100);
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1);
-  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for the enumeration type 'EMaxInt'}}
 
   const NumberType neg_one = (NumberType) ((NumberType) 0 - (NumberType) 1); // ok, not a constant expression context
 }
 
+template struct Bitfield {
+  static constexpr T max = static_cast((1 << size) - 1); // #enum
+};
+
+void testValueInRangeOfEnumerationValuesViaTemplate() {
+  Bitfield good;
+  Bitfield bad; // cxx11-error@#enum {{integer value 15 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
+}
+
 enum SortOrder {
   AscendingOrder,
   DescendingOrder
@@ -2494,4 +2503,4 @@
 GH50055::E2 GlobalInitNotCE1 = (GH50055::E2)-1; // ok, not a constant expression context
 GH50055::E2 GlobalInitNotCE2 = GH50055::testDefaultArgForParam(); // ok, not a constant expression context
 constexpr GH50055::E2 GlobalInitCE = (GH50055::E2)-1;
-// expected-error@-1 {{integer value -1 is outside the 

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim added inline comments.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:2479-2486
+template struct Bitfield {
+  static constexpr T max = static_cast((1 << size) - 1);
+};
+
+void testValueInRangeOfEnumerationValuesViaTemplate() {
+  Bitfield good;
+  Bitfield bad;

aaron.ballman wrote:
> Equivalent but a bit easier to tell where the diagnostic is expected to 
> happen at.
> 
> Perhaps a good follow-up would be to find out why we're not printing an 
> "instantiated from here" note for this case (CC @shafik), but no need to do 
> that for this patch.
Ah, I didn't know that syntax. At first I had the `cxx11-error@` just below the 
`static_cast` in the `Bitfield` class, but it seemed clearer to do it the way I 
did.

That said, you are right that it would probably be handy to show where the 
instantiation is coming from (if there is a template involved), because 
currently it does not point you to the exact source line where the problem is: 
in this case the `bad` declaration.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

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

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 531013.
dim added a comment.

Squash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -900,7 +900,7 @@
 namespace GH50055 {
 enum E {e1=0, e2=1};
 consteval int testDefaultArgForParam(E eParam = (E)-1) {
-// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for this enumeration type}}
+// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for the enumeration type 'E'}}
   return (int)eParam;
 }
 
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2440,42 +2440,52 @@
 void testValueInRangeOfEnumerationValues() {
   constexpr E1 x1 = static_cast(-8);
   constexpr E1 x2 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for the enumeration type 'E1'}}
   E1 x2b = static_cast(8); // ok, not a constant expression context
 
   constexpr E2 x3 = static_cast(-8);
-  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
   constexpr E2 x4 = static_cast(0);
   constexpr E2 x5 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
 
   constexpr E3 x6 = static_cast(-2048);
   constexpr E3 x7 = static_cast(-8);
   constexpr E3 x8 = static_cast(0);
   constexpr E3 x9 = static_cast(8);
   constexpr E3 x10 = static_cast(2048);
-  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for this enumeration type}}
+  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for the enumeration type 'E3'}}
 
   constexpr E4 x11 = static_cast(0);
   constexpr E4 x12 = static_cast(1);
   constexpr E4 x13 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'E4'}}
 
   constexpr EEmpty x14 = static_cast(0);
   constexpr EEmpty x15 = static_cast(1);
   constexpr EEmpty x16 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'EEmpty'}}
 
   constexpr EFixed x17 = static_cast(100);
   constexpr EScoped x18 = static_cast(100);
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1);
-  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for the enumeration type 'EMaxInt'}}
 
   const NumberType neg_one = (NumberType) ((NumberType) 0 - (NumberType) 1); // ok, not a constant expression context
 }
 
+template struct Bitfield {
+  static constexpr T max = static_cast((1 << size) - 1);
+};
+
+void testValueInRangeOfEnumerationValuesViaTemplate() {
+  Bitfield good;
+  Bitfield bad;
+  // cxx11-error@-6 {{integer value 15 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
+}
+
 enum SortOrder {
   AscendingOrder,
   DescendingOrder
@@ -2494,4 +2504,4 @@
 GH50055::E2 GlobalInitNotCE1 = (GH50055::E2)-1; // ok, not a constant expression context
 GH50055::E2 GlobalInitNotCE2 = GH50055::testDefaultArgForParam(); // ok, not a constant expression context
 constexpr GH50055::E2 GlobalInitCE = (GH50055::E2)-1;
-// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 7] for this enumeration type}}
+// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
Index: clang/lib/AST/ExprConstant.cpp

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 531011.
dim added a comment.

Add release note and test with template instantiation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152788

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/SemaCXX/constant-expression-cxx11.cpp


Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2476,6 +2476,16 @@
   const NumberType neg_one = (NumberType) ((NumberType) 0 - (NumberType) 1); 
// ok, not a constant expression context
 }
 
+template struct Bitfield {
+  static constexpr T max = static_cast((1 << size) - 1);
+};
+
+void testValueInRangeOfEnumerationValuesViaTemplate() {
+  Bitfield good;
+  Bitfield bad;
+  // cxx11-error@-6 {{integer value 15 is outside the valid range of values 
[0, 7] for the enumeration type 'E2'}}
+}
+
 enum SortOrder {
   AscendingOrder,
   DescendingOrder
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -340,6 +340,9 @@
   can be controlled using ``-fcaret-diagnostics-max-lines=``.
 - Clang no longer emits ``-Wunused-variable`` warnings for variables declared
   with ``__attribute__((cleanup(...)))`` to match GCC's behavior.
+- When diagnosing a constant expression where an enum without a fixed 
underlying
+  type is set to a value outside the range of the enum's values, clang will now
+  print the name of the enum in question.
 
 Bug Fixes in This Version
 -


Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2476,6 +2476,16 @@
   const NumberType neg_one = (NumberType) ((NumberType) 0 - (NumberType) 1); // ok, not a constant expression context
 }
 
+template struct Bitfield {
+  static constexpr T max = static_cast((1 << size) - 1);
+};
+
+void testValueInRangeOfEnumerationValuesViaTemplate() {
+  Bitfield good;
+  Bitfield bad;
+  // cxx11-error@-6 {{integer value 15 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
+}
+
 enum SortOrder {
   AscendingOrder,
   DescendingOrder
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -340,6 +340,9 @@
   can be controlled using ``-fcaret-diagnostics-max-lines=``.
 - Clang no longer emits ``-Wunused-variable`` warnings for variables declared
   with ``__attribute__((cleanup(...)))`` to match GCC's behavior.
+- When diagnosing a constant expression where an enum without a fixed underlying
+  type is set to a value outside the range of the enum's values, clang will now
+  print the name of the enum in question.
 
 Bug Fixes in This Version
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D152788: [Clang] Show type in enum out of range diagnostic

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: aaron.ballman, erichkeane, shafik, thakis.
Herald added a project: All.
dim requested review of this revision.
Herald added a project: clang.

When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:

  v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid 
range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast(kNumValues - 1);
  ^

This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D152788

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -900,7 +900,7 @@
 namespace GH50055 {
 enum E {e1=0, e2=1};
 consteval int testDefaultArgForParam(E eParam = (E)-1) {
-// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for this enumeration type}}
+// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 1] for the enumeration type 'E'}}
   return (int)eParam;
 }
 
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2440,38 +2440,38 @@
 void testValueInRangeOfEnumerationValues() {
   constexpr E1 x1 = static_cast(-8);
   constexpr E1 x2 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [-8, 7] for the enumeration type 'E1'}}
   E1 x2b = static_cast(8); // ok, not a constant expression context
 
   constexpr E2 x3 = static_cast(-8);
-  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value -8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
   constexpr E2 x4 = static_cast(0);
   constexpr E2 x5 = static_cast(8);
-  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for this enumeration type}}
+  // expected-error@-1 {{integer value 8 is outside the valid range of values [0, 7] for the enumeration type 'E2'}}
 
   constexpr E3 x6 = static_cast(-2048);
   constexpr E3 x7 = static_cast(-8);
   constexpr E3 x8 = static_cast(0);
   constexpr E3 x9 = static_cast(8);
   constexpr E3 x10 = static_cast(2048);
-  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for this enumeration type}}
+  // expected-error@-1 {{integer value 2048 is outside the valid range of values [-2048, 2047] for the enumeration type 'E3'}}
 
   constexpr E4 x11 = static_cast(0);
   constexpr E4 x12 = static_cast(1);
   constexpr E4 x13 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'E4'}}
 
   constexpr EEmpty x14 = static_cast(0);
   constexpr EEmpty x15 = static_cast(1);
   constexpr EEmpty x16 = static_cast(2);
-  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for this enumeration type}}
+  // expected-error@-1 {{integer value 2 is outside the valid range of values [0, 1] for the enumeration type 'EEmpty'}}
 
   constexpr EFixed x17 = static_cast(100);
   constexpr EScoped x18 = static_cast(100);
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1);
-  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-error@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for the enumeration type 'EMaxInt'}}
 
   const NumberType neg_one = (NumberType) ((NumberType) 0 - (NumberType) 1); // ok, not a constant expression context
 }
@@ -2494,4 +2494,4 @@
 GH50055::E2 GlobalInitNotCE1 = (GH50055::E2)-1; // ok, not a constant expression context
 GH50055::E2 GlobalInitNotCE2 = GH50055::testDefaultArgForParam(); // ok, not a constant expression context
 constexpr GH50055::E2 GlobalInitCE = (GH50055::E2)-1;
-// expected-error@-1 {{integer value -1 is outside the valid range of values [0, 7] for this enumeration type}}
+// expected-error@-1 

[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

[Dimitry Andric via Phabricator via cfe-commits]

dim added a subscriber: bsdjhb.
dim added a comment.

In D150226#4353911 , @aaron.ballman 
wrote:

> One of the major selling points to `constexpr` functions in C++ is that they 
> cannot contain UB -- if your code compiles, it is correct. This bug that 
> we've fixed was another instance of us accidentally allowing UB in a constant 
> expression context when we shouldn't have. FWIW, I pointed out a reasonable 
> workaround for the freebsd issue: https://reviews.llvm.org/D150226#4342516

I tried making that work for gdb, but I failed; there are some complains about 
deleted operator~ that I didn't see before, and I'm going to have to let it 
rest for a bit. I could maybe convince @bsdjhb to submit a solution, since he's 
contributed to gdb and binutils before.


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

https://reviews.llvm.org/D150226

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

[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

I submitted a similar workaround for the FreeBSD devel/gdb port, via 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271045 that also applies 
`-Wno-enum-constexpr-conversion`. As the upstream commit message said, they 
didn't see any other good way to get rid of the warning, so if there is a 
workaround clang is OK with, that would be nice. Still, I don't really 
understand what the value is of making this warning into an error, that is not 
suppressible?


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

https://reviews.llvm.org/D150226

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

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

[Dimitry Andric 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 rGdb492316399a: [clang][BFloat] Avoid redefining bfloat16_t in 
arm_neon.h (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148822

Files:
  clang/utils/TableGen/NeonEmitter.cpp
  clang/utils/TableGen/SveEmitter.cpp


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1103,7 +1103,6 @@
   OS << "typedef __SVBFloat16_t svbfloat16_t;\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   OS << "typedef __SVFloat32_t svfloat32_t;\n";
   OS << "typedef __SVFloat64_t svfloat64_t;\n";
Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1103,7 +1103,6 @@
   OS << "typedef __SVBFloat16_t svbfloat16_t;\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   OS << "typedef __SVFloat32_t svfloat32_t;\n";
   OS << "typedef __SVFloat64_t svfloat64_t;\n";
Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D148822#4305188 , @simonbutcher 
wrote:

> I can't see anything wrong with this patch and it looks pretty 
> straightforward to me, but is it necessary?
>
> '-Wtypedef-redefinition' is documented as not applying to system headers 
> ,
>  and I couldn't reproduce the issue unless I changed the headers to not be 
> system headers.

I think this due to the way some parts of FreeBSD get compiled, where we 
definitely use -Wsystem-headers. It is likely that this warning (which was 
turned into an error because parts of the tree also get compiled with -Werror) 
came through because of that. In any case, there is no need to redefine 
bfloat16_t, at least not here. Another option is to add yet another define like 
`__bfloat_16_defined` and test for that, but it only makes things uglier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148822

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

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 515409.
dim added a comment.

Also fix up arm_sve.h.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148822

Files:
  clang/utils/TableGen/NeonEmitter.cpp
  clang/utils/TableGen/SveEmitter.cpp


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1103,7 +1103,6 @@
   OS << "typedef __SVBFloat16_t svbfloat16_t;\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   OS << "typedef __SVFloat32_t svfloat32_t;\n";
   OS << "typedef __SVFloat64_t svfloat64_t;\n";
Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1103,7 +1103,6 @@
   OS << "typedef __SVBFloat16_t svbfloat16_t;\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   OS << "typedef __SVFloat32_t svfloat32_t;\n";
   OS << "typedef __SVFloat64_t svfloat64_t;\n";
Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D148822: [clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson, 
stuij.
Herald added a project: All.
dim requested review of this revision.
Herald added a project: clang.

As of https://reviews.llvm.org/D79708, clang-tblgen generates both
`arm_neon.h` and `arm_bf16.h`, and both generated files will contain a
typedef of `bfloat16_t`. However, `arm_neon.h` includes `arm_bf16.h`
immediately before its own typedef:

  #include 
  typedef __bf16 bfloat16_t;

With a recent version of clang (I used 16.0.1) this results in warnings:

  /usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 
'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]

Since `arm_bf16.h` is very likely supposed to be the one true place
where `bfloat16_t` is defined, I propose to delete the duplicate typedef
from the generated `arm_neon.h`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148822

Files:
  clang/utils/TableGen/NeonEmitter.cpp


Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";


Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2353,7 +2353,6 @@
   OS << "#include \n\n";
 
   OS << "#include \n";
-  OS << "typedef __bf16 bfloat16_t;\n";
 
   // Emit NEON-specific scalar typedefs.
   OS << "typedef float float32_t;\n";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135171: FreeBSD: enable __float128 on x86 and powerpc64le

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

LGTM again :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135171

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

[PATCH] D144823: [Driver][FreeBSD] Simplify ARM handling

[Dimitry Andric via Phabricator via cfe-commits]

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

I think this is fine. @emaste can you think of any objections? 8 and 9 are long 
gone.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144823

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

[PATCH] D144778: [Driver][FreeBSD] Further simplify the Driver handling for older FreeBSD releases

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM, are there no test cases which are affected by this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144778

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

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D14

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

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D14#4142146 , @MaskRay wrote:

> `isPPC32SecurePlt` is probably more accurate.

I agree, good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D14

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

[PATCH] D144444: [PowerPC] Use member function to determine PowerPC Secure PLT

[Dimitry Andric via Phabricator via cfe-commits]

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

Yes, this is quite a bit nicer. Maybe run the isPPCSecurePlt() function through 
clang-format, just to be sure of the style?

(I think you can ignore the weird libFuzzer Unit Test errors, they don't seem 
to have anything to do with this change.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D14

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

[PATCH] D144341: [Driver][FreeBSD] Correct driver behavior if a triple is provided without a version

[Dimitry Andric via Phabricator via cfe-commits]

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

In D144341#4140652 , @arichardson 
wrote:

> LGTM, but I'll let @dim and @emaste decide if FreeBSD 8 code is still needed.

No, these versions are ancient now and very much unsupported. So this is a nice 
cleanup! At the moment 12.x is the oldest supported version so the >= 12 checks 
should stay for a while.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144341

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

[PATCH] D144321: [PowerPC] Correctly use ELFv2 ABI on all OS's that use the ELFv2 ABI

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

Yeah, this looks quite a bit nicer, and should be more maintainable. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144321

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

[PATCH] D144321: [PowerPC] Correctly use ELFv2 ABI on all OS's that use the ELFv2 ABI

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM, some minor clang-format nits, but these aren't critical (to me at least :)




Comment at: clang/lib/Basic/Targets/PPC.h:432
+  Triple.getOSMajorVersion() >= 13)) || Triple.isOSOpenBSD() ||
+  Triple.isMusl())
+ABI = "elfv2";

clang-format seems to want to format the `if` as:

```
  if ((Triple.isOSFreeBSD() && (Triple.getOSVersion().empty() ||
Triple.getOSMajorVersion() >= 13)) ||
  Triple.isOSOpenBSD() || Triple.isMusl())
```

E,g. it groups the whole FreeBSD expression together. I didn't know it could do 
this, but it seems relatively clear.



Comment at: llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:242
+  TT.getOSMajorVersion() >= 13)) || TT.isOSOpenBSD() || TT.isMusl())
+  return PPCTargetMachine::PPC_ABI_ELFv2;
+else

similarly for this one, clang-format likes to format it as:
```
 if ((TT.isOSFreeBSD() &&
  (TT.getOSVersion().empty() || TT.getOSMajorVersion() >= 13)) ||
 TT.isOSOpenBSD() || TT.isMusl())
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144321

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

[PATCH] D144232: [PowerPC] Correctly use ELFv2 ABI on FreeBSD/powerpc64

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D144232#4136787 , @brad wrote:

> I noticed this review. I have provided a more complete diff for review at 
> D144321 .

Yeah I think that is probably the better option, hope @pkubaj and @adalava 
agree with that?

As Brad's version covers both FreeBSD and OpenBSD, and also updates a bunch of 
unit tests, which this review appears to break (see the Unit Tests 
https://reviews.llvm.org/harbormaster/unit/214420/).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144232

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

[PATCH] D135171: FreeBSD: enable __float128 on x86

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim 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/D135171/new/

https://reviews.llvm.org/D135171

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

[PATCH] D131057: [Sema] -Wformat: support C23 printf %b %B

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

> GCC 12 -Wformat -pedantic emits a warning:
>
>   warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]
>
> The behavior is not ported (and it's unclear to me how to implement it).

If you really want this, I think it can be implemented by looking at 
`LangOpts::LangStd`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131057

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

[PATCH] D131057: [Sema] -Wformat: support C23 printf %b %B

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a subscriber: emaste.
dim 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/D131057/new/

https://reviews.llvm.org/D131057

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

[PATCH] D130063: [Driver] Enable sanitizers on FreeBSD AArch64

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM, are there any tests that need to be enabled explicitly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130063

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

[PATCH] D117388: [Driver][FreeBSD] -r: imply -nostdlib like GCC

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117388

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

[PATCH] D94355: [Passes] Add relative lookup table converter pass

[Dimitry Andric via Phabricator via cfe-commits]

dim added subscribers: emaste, jrtc27, dim.
dim added a comment.

FWIW, this commit turned out to break the FreeBSD dns/bind916 port, see 
https://bugs.freebsd.org/259921.

The short story is that the bind9 code on and after this line: 
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/log.c#L1525 gets 
changed from something like:

  .Ltmp661:
  #DEBUG_VALUE: isc_log_doit:category_channels <- $r12
  .loc3 0 58  # log.c:0:58
  xorl%eax, %eax
  testl   %r15d, %r15d
  setg%al
  movl%r15d, %ecx
  negl%ecx
  movq%rcx, -840(%rbp)# 8-byte Spill
  leaq8328(%r13), %rcx
  #DEBUG_VALUE: isc_log_doit:matched <- 0
  movq%rcx, -808(%rbp)# 8-byte Spill
  .Ltmp662:
  .loc3 1552 25 is_stmt 1 # log.c:1552:25

to using a relative lookup table:

  .Ltmp661:
  #DEBUG_VALUE: isc_log_doit:category_channels <- $r12
  .loc3 0 58  # log.c:0:58
  xorl%eax, %eax
  testl   %r15d, %r15d
  setg%al
  movl%r15d, %edx
  negl%edx
  leaqreltable.isc_log_doit(%rip), %rcx
  movq%rdx, -848(%rbp)# 8-byte Spill
  movslq  (%rcx,%rdx,4), %rdx
  addq%rcx, %rdx
  movq%rdx, -840(%rbp)# 8-byte Spill
  leaq8328(%r13), %rcx
  #DEBUG_VALUE: isc_log_doit:matched <- 0
  movq%rcx, -808(%rbp)# 8-byte Spill
  .Ltmp662:
  .loc3 1552 25 is_stmt 1 # log.c:1552:25

However, the value of `%rcx` at the `movslq (%rcx,%rdx,4), %rdx` statement 
becomes -2, so it attempts to access data before `reltable.isc_log_doit`. As 
that is in `.rodata`, this leads to a segfault.

The current working theory is that some code is hoisted out of the do-while 
loop starting at 
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/log.c#L1531, in 
particular the `[-level]` accesses on lines 1613 and 1843:

  snprintf(level_string, sizeof(level_string),
   "%s: ", log_level_strings[-level]);
  ...
  } else {
  syslog_level = syslog_map[-level];
  }

but maybe these negative offsets confuse the lookup table converter?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94355

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

[PATCH] D114677: [AArch64] Avoid crashing on invalid -Wa,-march= values

[Dimitry Andric 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 rGdf08b2fe8b35: [AArch64] Avoid crashing on invalid 
-Wa,-march= values (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114677

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-target-as-march.s


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | 
\
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -225,7 +225,7 @@
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  llvm::StringRef WaMArch = "";
+  llvm::StringRef WaMArch;
   if (ForAS)
 for (const auto *A :
  Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -235,7 +235,7 @@
   // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
   // "-Xassembler -march" is detected. Otherwise it may return false
   // and causes Clang to error out.
-  if (WaMArch.size())
+  if (!WaMArch.empty())
 success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
   else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
@@ -259,8 +259,15 @@
 success = getAArch64MicroArchFeaturesFromMcpu(
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
-  if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+  if (!success) {
+auto Diag = D.Diag(diag::err_drv_clang_unsupported);
+// If "-Wa,-march=" is used, 'WaMArch' will contain the argument's value,
+// while 'A' is uninitialized. Only dereference 'A' in the other case.
+if (!WaMArch.empty())
+  Diag << "-march=" + WaMArch.str();
+else
+  Diag << A->getAsString(Args);
+  }
 
   if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
 Features.push_back("-fp-armv8");


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -225,7 +225,7 @@
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  llvm::StringRef WaMArch = "";
+  llvm::StringRef WaMArch;
   if (ForAS)
 for (const auto *A :
  Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -235,7 +235,7 @@
   // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
   // "-Xassembler -march" is detected. Otherwise it may return false
   // and causes Clang to error out.
-  if (WaMArch.size())
+  if (!WaMArch.empty())
 success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
   else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, Features);
@@ -259,8 +259,15 @@
 success = getAArch64MicroArchFeaturesFromMcpu(
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
-  if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << 

[PATCH] D114677: [AArch64] Avoid crashing on invalid -Wa,-march= values

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 390218.
dim added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114677

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-target-as-march.s


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | 
\
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -225,7 +225,7 @@
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  llvm::StringRef WaMArch = "";
+  llvm::StringRef WaMArch;
   if (ForAS)
 for (const auto *A :
  Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -235,7 +235,7 @@
   // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
   // "-Xassembler -march" is detected. Otherwise it may return false
   // and causes Clang to error out.
-  if (WaMArch.size())
+  if (!WaMArch.empty())
 success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
   else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
@@ -259,8 +259,15 @@
 success = getAArch64MicroArchFeaturesFromMcpu(
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
-  if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+  if (!success) {
+auto Diag = D.Diag(diag::err_drv_clang_unsupported);
+// If "-Wa,-march=" is used, 'WaMArch' will contain the argument's value,
+// while 'A' is uninitialized. Only dereference 'A' in the other case.
+if (!WaMArch.empty())
+  Diag << "-march=" + WaMArch.str();
+else
+  Diag << A->getAsString(Args);
+  }
 
   if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
 Features.push_back("-fp-armv8");


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -225,7 +225,7 @@
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  llvm::StringRef WaMArch = "";
+  llvm::StringRef WaMArch;
   if (ForAS)
 for (const auto *A :
  Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -235,7 +235,7 @@
   // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
   // "-Xassembler -march" is detected. Otherwise it may return false
   // and causes Clang to error out.
-  if (WaMArch.size())
+  if (!WaMArch.empty())
 success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
   else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, Features);
@@ -259,8 +259,15 @@
 success = getAArch64MicroArchFeaturesFromMcpu(
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
-  if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+  if (!success) {
+auto Diag = D.Diag(diag::err_drv_clang_unsupported);
+// If "-Wa,-march=" is used, 'WaMArch' will contain the 

[PATCH] D114677: [AArch64] Avoid crashing on invalid -Wa,-march= values

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: jcai19, ostannard, DavidSpickett, nickdesaulniers.
Herald added subscribers: kristof.beyls, krytarowski, arichardson.
dim requested review of this revision.
Herald added a project: clang.

As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.

Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114677

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-target-as-march.s


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | 
\
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -260,7 +260,8 @@
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
   if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+D.Diag(diag::err_drv_clang_unsupported)
+<< (WaMArch.size() ? "-march=" + WaMArch.str() : A->getAsString(Args));
 
   if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
 Features.push_back("-fp-armv8");


Index: clang/test/Driver/aarch64-target-as-march.s
===
--- clang/test/Driver/aarch64-target-as-march.s
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -44,3 +44,12 @@
 // TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4: "-target-feature" "+v8.4a"
 // TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
+
+// Invalid -march settings
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=all %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=foobar %s 2>&1 | \
+// RUN: FileCheck --check-prefix=INVALID-ARCH-2 %s
+
+// INVALID-ARCH-1: error: the clang compiler does not support '-march=all'
+// INVALID-ARCH-2: error: the clang compiler does not support '-march=foobar'
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -260,7 +260,8 @@
 D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
 
   if (!success)
-D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+D.Diag(diag::err_drv_clang_unsupported)
+<< (WaMArch.size() ? "-march=" + WaMArch.str() : A->getAsString(Args));
 
   if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
 Features.push_back("-fp-armv8");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114396: [Driver] Default to current FreeBSD profiling behaviour

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D114396

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

[PATCH] D77776: [Driver] Default to libc++ on FreeBSD

[Dimitry Andric via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D6

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

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

[Dimitry Andric via Phabricator via cfe-commits]

dim added a subscriber: emaste.
dim added a comment.

In D111863#3072023 , @housel wrote:

> It's also worth noting that FreeBSD's version of libgcc exception handling is 
> actually based on the libunwind code, with a local patch 
> 
>  that implements compatibility with libgcc `__register_frame` by changing it 
> to parse an entire `.eh_frame` section (in a slightly more ad hoc fashion 
> than this code). Having this new entry point in-tree would simplify the 
> FreeBSD local changes.

Adding @emaste since he added this part in:
https://github.com/freebsd/freebsd-src/commit/77ac8927fda49722185dab219365be31daed8872


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111863

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

[PATCH] D110213: [PowerPC] Define XL-compatible macros only for AIX and Linux

[Dimitry Andric via Phabricator via cfe-commits]

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

FWIW I think this is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110213

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

[PATCH] D109800: [clang] don't mark as Elidable CXXConstruct expressions used in NRVO

[Dimitry Andric via Phabricator via cfe-commits]

dim added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:9937
+  if (E->isElidable() && !ZeroInit) {
+// FIXME: This only handles the simples case, where the source object
+//is passed directly as the first argument to the constructor.

`s/simples/simplest/`




Comment at: clang/lib/CodeGen/CGExprCXX.cpp:613
   if (getLangOpts().ElideConstructors && E->isElidable()) {
-assert(getContext().hasSameUnqualifiedType(E->getType(),
-   E->getArg(0)->getType()));
-if (E->getArg(0)->isTemporaryObject(getContext(), CD->getParent())) {
-  EmitAggExpr(E->getArg(0), Dest);
-  return;
-}
+// FIXME: This only handles the simples case, where the source object
+//is passed directly as the first argument to the constructor.

`s/simples/simplest/`



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109800

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

[PATCH] D109800: [clang] don't mark as Elidable CXXConstruct expressions used in NRVO

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

I can at least confirm that both the original test case for bug 51862 (from 
https://github.com/Macaulay2/frobby ) and the reduced test case compile 
successfully with this patch added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109800

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D104386#2977302 , @nemanjai wrote:

> The idea with putting all of these in a separate function was to:
>
> 1. Make it easy to limit it to specific targets as I suggested above
> 2. Have them all in one place to easily identify which ones are added for 
> this compatibility so we can eventually pull this support once they are no 
> longer needed
> 3. Just kind of isolate this to keep it out of the way
>
> I really think the best way forward might be to limit this to Linux and AIX. 
> I don't think IBM provided XLC/C++ on FreeBSD.

Well, glibc also uses at least some of these `__` aliases, e.g. for `__bcopy`:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/powerpc64/power7/memmove.S;h=f61949d30fa317ec487deb81b20e67ed3df05e32;hb=HEAD#l829

and

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/powerpc64/le/power10/memmove.S;h=7dfd57edeb37e8e47a31fe6e19f254bc1fcd312b;hb=HEAD#l312

but there might be more collisions...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Just encountered another similar error, apparently introduced in 
rGc8937b6cb9751807de1e69f0f0f70a9a58f8f5dc 
 (as more 
additions to the `defineXLCompatMacros` function, by @lei):

  In file included from /home/dim/src/llvm-13-update/lib/msun/powerpc/fenv.c:32:
  /home/dim/src/llvm-13-update/lib/msun/powerpc/fenv.h:114:9: error: '__mtfsf' 
macro redefined [-Werror,-Wmacro-redefined]
  #define __mtfsf(__env) \
  ^
  :375:9: note: previous definition is here
  #define __mtfsf __builtin_ppc_mtfsf
  ^
  1 error generated.

To unblock my builds, I'm just going to use `-U` to undef these macros manually 
for now...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Dimitry Andric via Phabricator via cfe-commits]

dim added subscribers: adalava, jhibbits.
dim added a comment.

In D104386#2973372 , @nemanjai wrote:

> In D104386#2973245 , @dim wrote:
>
>> Note that this unexpectedly broke FreeBSD's powerpc64 builds, as we've long 
>> used the following in our `lib/libc/powerpc64/string/bcopy.S`:

...

>> However, I think I can make do with adding `-U__bcopy` to the clang command 
>> line. It would have been nice if these aliases were behind some 
>> `--xl-compat` flag... :)
>
> I am really sorry that we broke you. Would it help if we defined this macro 
> only if compiling for Linux/AIX? If so, are there any others (or perhaps all 
> of them) that you'd like us to conditionally define only on AIX/Linux?

Well, it seems that `defineXLCompatMacros` was rather small in the beginning 
(when it was introduced in rG62b5df7fe2b3fda1772befeda15598fbef96a614 
) so there 
were not so many chances for collisions. This is probably why we've not noticed 
these definitions, and also because they're not there for clang <= 12. :)

That said, if you think there is a use case for sometimes compiling with the XL 
compiler on systems *other* than Linux/AIX, then your suggested workaround 
might not be adequate. @jhibbits @adalava did you ever use the XL compiler on 
FreeBSD?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Dimitry Andric via Phabricator via cfe-commits]

dim added subscribers: emaste, dim.
dim added a comment.

Note that this unexpectedly broke FreeBSD's powerpc64 builds, as we've long 
used the following in our `lib/libc/powerpc64/string/bcopy.S`:

  #ifndef FN_NAME
  #ifdef MEMMOVE
  #define FN_NAME __memmove
  WEAK_REFERENCE(__memmove, memmove);
  #else
  #define FN_NAME __bcopy
  WEAK_REFERENCE(__bcopy, bcopy);
  #endif
  #endif

so now we're getting:

  lib/libc/powerpc64/string/bcopy.S:51:25: error: Recursive use of 'bcopy'
  .weak bcopy; .equ bcopy,bcopy;
  ^

However, I think I can make do with adding `-U__bcopy` to the clang command 
line. It would have been nice if these aliases were behind some `--xl-compat` 
flag... :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

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

[PATCH] D105594: cmake: Allow shared libraries to customize the soname using LLVM_ABI_REVISION

[Dimitry Andric via Phabricator via cfe-commits]

dim added inline comments.



Comment at: clang/tools/clang-shlib/CMakeLists.txt:5
+set(LLVM_ABI_REVISION 0)
+
 # Building libclang-cpp.so fails if LLVM_ENABLE_PIC=Off

Is this actually needed? This CMakeLists.txt calls `add_clang_library()` in 
`clang/cmake/modules/AddClang.cmake`, which calls `add_llvm_library()` in 
`llvm/cmake/modules/AddLLVM.cmake`, which calls the confusingly named 
`llvm_add_library()` in the same file. That last function is already updated 
below to set `LLVM_ABI_REVISION` to 0 is it is unset.




Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:9
+set(LLVM_ABI_REVISION 0)
+
 set(SOURCES

Similar here, this CMakeLists.txt calls `add_llvm_library` which already sets 
the `LLVM_ABI_REVISION` to 0.




Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:78
+  PROPERTIES
+  SOVERSION ${LLVM_ABI_REVISION})
   endif()

I think this is also handled via `add_llvm_library`/`llvm_add_library`?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105594

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

[PATCH] D104753: [Driver] Stop linking _p libs for -pg on FreeBSD 14

[Dimitry Andric via Phabricator via cfe-commits]

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

I mostly agree with this, but for the "silent ignoring" of `-pg` which this 
achieves. What would be the consequence of producing an error instead, like 
`-pg not supported for FreeBSD >= 14` ?  Too many unexpected failures?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104753

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

[PATCH] D98286: [Driver] Enable kernel address and memory sanitizers on FreeBSD

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

LGTM, but this would probably need some sort of test, at least that it 
correctly accepts the flag(s) now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98286

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

[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

@sylvestre.ledru removed the minor version from the binary (on purpose, I 
think?) in rGa8b717fda42294d1c8e1f05d71280503e5839f14 
:

  commit a8b717fda42294d1c8e1f05d71280503e5839f14
  Author: Sylvestre Ledru 
  Date:   Thu Mar 29 10:05:46 2018 +
  
  Rename clang link from clang-X.Y to clang-X
  
  Summary:
  As we are only doing X.0.Z releases (not using the minor version), there 
is no need to keep -X.Y in the version.
  So, instead, I propose the following:
  Instead of having clang-7.0 in bin/, we will have clang-7
  
  Since also matches was gcc is doing.
  
  Reviewers: tstellar, dlj, dim, hans
  
  Reviewed By: dim, hans
  
  Subscribers: dim, mgorny, cfe-commits
  
  Differential Revision: https://reviews.llvm.org/D41808
  
  llvm-svn: 328769

But this seems to have been mainly about the clang executable that gets 
installed into `$prefix/bin`, i.e. `clang-11` instead of `clang-11.1`.

I think this doesn't matter for the clang executable here, since nobody uses 
its ABI. But indeed for the shared library it looks like a good solution, if 
you would want to install both versions side-by-side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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

[PATCH] D44964: Change order of libclang_rt.profile link for freebsd

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Yes, this looks pretty fine to me, but indeed needs a test.


Repository:
  rC Clang

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

https://reviews.llvm.org/D44964

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

[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D73425#2266446 , @Bdragon28 wrote:

> Any chance of a backport to 11?

I submitted https://bugs.llvm.org/show_bug.cgi?id=47485 for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

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

[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfc2dac4116df: [PPC] Fix platform definitions when compiling 
FreeBSD powerpc64 as LE (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

Files:
  clang/lib/Basic/Targets.cpp
  clang/test/CodeGen/target-data.c
  clang/test/Driver/freebsd.c
  clang/test/Driver/ppc-abi.c
  clang/test/Preprocessor/init-ppc64.c


Index: clang/test/Preprocessor/init-ppc64.c
===
--- clang/test/Preprocessor/init-ppc64.c
+++ clang/test/Preprocessor/init-ppc64.c
@@ -1067,6 +1067,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd11 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd12 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd13 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64le-unknown-freebsd13 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-openbsd 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-linux-musl 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 
@@ -1079,4 +1080,5 @@
 // PPC64LE-LINUX:#define _CALL_LINUX 1
 
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < 
/dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64le-unknown-freebsd < 
/dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
 // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
Index: clang/test/Driver/ppc-abi.c
===
--- clang/test/Driver/ppc-abi.c
+++ clang/test/Driver/ppc-abi.c
@@ -20,6 +20,7 @@
 // RUN: %clang -target powerpc64-unknown-freebsd12 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv1 %s
 // RUN: %clang -target powerpc64-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
 // RUN: %clang -target powerpc64-unknown-freebsd14 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
+// RUN: %clang -target powerpc64le-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2 %s
 // RUN: %clang -target powerpc64-unknown-openbsd %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 // RUN: %clang -target powerpc64-linux-musl %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 
Index: clang/test/Driver/freebsd.c
===
--- clang/test/Driver/freebsd.c
+++ clang/test/Driver/freebsd.c
@@ -21,7 +21,15 @@
 // CHECK-PPC64: "-cc1" "-triple" "powerpc64-pc-freebsd8"
 // CHECK-PPC64: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
 // CHECK-PPC64: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
-//
+
+// RUN: %clang -no-canonical-prefixes \
+// RUN:   -target powerpc64le-unknown-freebsd13 %s \
+// RUN:   --sysroot=%S/Inputs/basic_freebsd64_tree -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: "-cc1" "-triple" "powerpc64le-unknown-freebsd13"
+// CHECK-PPC64LE: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-PPC64LE: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
+
 //
 // Check that -m32 properly adjusts the toolchain flags.
 //
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -130,6 +130,10 @@
 // RUN: FileCheck %s -check-prefix=PPC64-FREEBSD
 // PPC64-FREEBSD: target datalayout = "E-m:e-i64:64-n32:64"
 
+// RUN: %clang_cc1 -triple powerpc64le-freebsd -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=PPC64LE-FREEBSD
+// PPC64LE-FREEBSD: target datalayout = "e-m:e-i64:64-n32:64"
+
 // RUN: %clang_cc1 -triple powerpc64-linux -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC64-LINUX
 // PPC64-LINUX: target datalayout = "E-m:e-i64:64-n32:64"
Index: clang/lib/Basic/Targets.cpp

[PATCH] D44536: Avoid segfault when destructor is not yet known

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Hm, this review's still open after two years, and even as of 2020-08-02 clang 
still crashes on the sample. :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D44536

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

[PATCH] D77776: [Driver] Default to libc++ on FreeBSD

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D6#2187334 , @myfreeweb wrote:

> In D6#2187273 , @dim wrote:
>
>>>   +#ifdef __FreeBSD__
>>>   +   return __FreeBSD_version / 10;
>>>   +#else
>>>   +   return 10;
>>>   +#endif
>>
>> No, that would hardcode something at build time. We need to respect whatever 
>> triple the user is passing in.
>
> Nobody has proposed not respecting that, this is all in the context of the 
> `if (Major == 0)` fallback

Aha, then there is no need to do arithmetic with `__FreeBSD_version`, as 
`__FreeBSD__` already contains just the major version.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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

[PATCH] D77776: [Driver] Default to libc++ on FreeBSD

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D6#1993211 , @arichardson wrote:

> I don't like the fact that this only changes one of the users of 
> `getTriple().getOSMajorVersion()`.

Why not, if this is a one-off case, it's perfectly OK to put it in here. Maybe 
add a comment as to why it is needed?

Could you add a new member function such as

>   void FreeBSD::getMajorVersion() const {
> unsigned Major = getTriple().getOSMajorVersion();
> if (Major == 0)
>return 10; 
> return Major
>   }
>
> and replace all uses of `getTriple().getOSMajorVersion()` with 
> `getMajorVersion()`.

Maybe other OSes would also have this same issue, but then you'd have to 
replace this kind of logic for *all* of them, not only FreeBSD. That said, 
maybe there aren't so many places where the major version is checked, and where 
features are enabled or disabled depending on this version?

> We could also use the host version instead of 10?
>
>   +#ifdef __FreeBSD__
>   + return __FreeBSD_version / 10;
>   +#else
>   + return 10;
>   +#endif

No, that would hardcode something at build time. We need to respect whatever 
triple the user is passing in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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

[PATCH] D83645: Bump the default target CPU for i386-freebsd to i686

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D83645#2160761 , @MaskRay wrote:

> @dim
>
> Hi, your git commit contains extra Phabricator tags. You can drop 
> `Reviewers:` `Subscribers:` `Tags:` and the text `Summary:` from the git 
> commit with the following script:
>
>   arcfilter () {
>   arc amend
>   git log -1 --pretty=%B | awk '/Reviewers:|Subscribers:/{p=1} 
> /Reviewed By:|Differential Revision:/{p=0} !p && !/^Summary:$/ 
> {sub(/^Summary: /,"");print}' | git commit --amend --date=now -F -
>   }
>   
>
> `Reviewed By: ` is considered important by some people. Please keep the tag. 
> (`--date=now` is my personal preference (author dates are usually not useful. 
> Using committer dates can make log almost monotonic in time))
>
> `llvm/utils/git/pre-push.py` can validate the message does not include 
> unneeded tags.


Hm, I think I just used `arc land` to land this revision. Does arc not do all 
that stuff? In any case, I can't change the commit message after it's been 
pushed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83645



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

[PATCH] D83645: Bump the default target CPU for i386-freebsd to i686

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG02cfa7530d9e: Bump the default target CPU for i386-freebsd 
to i686 (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83645

Files:
  clang/lib/Driver/ToolChains/Arch/X86.cpp


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -94,6 +94,7 @@
 
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
+return "i686";
   case llvm::Triple::NetBSD:
   case llvm::Triple::OpenBSD:
 return "i486";


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -94,6 +94,7 @@
 
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
+return "i686";
   case llvm::Triple::NetBSD:
   case llvm::Triple::OpenBSD:
 return "i486";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83645: Bump the default target CPU for i386-freebsd to i686

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: emaste, brooks, rsmith.
Herald added subscribers: jfb, krytarowski, arichardson.
Herald added a project: clang.

Similar to what we have done downstream, some time ago:
https://svnweb.freebsd.org/changeset/base/353936

This followed some discussions on the freebsd-arch mailing lists, and
most people agreed that it was a better default, and also it worked
around several issues where clang generated libcalls to 64 bit atomic
primitives, instead of using cmpxchg8b.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83645

Files:
  clang/lib/Driver/ToolChains/Arch/X86.cpp


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -94,6 +94,7 @@
 
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
+return "i686";
   case llvm::Triple::NetBSD:
   case llvm::Triple::OpenBSD:
 return "i486";


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -94,6 +94,7 @@
 
   switch (Triple.getOS()) {
   case llvm::Triple::FreeBSD:
+return "i686";
   case llvm::Triple::NetBSD:
   case llvm::Triple::OpenBSD:
 return "i486";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a subscriber: asbirlea.
dim added a comment.

Okay, after a long while of attempting to make a reproduction scenario, I 
finally managed one that consistently worked. As BSD make puts in different 
redirections for stderr when running in `-j` mode, it turned out that I could 
simply run the compilation twice on a terminal, first normally, then with 
stderr redirected to `/dev/null`, e.g. my test script is:

  #!/bin/sh
  
  exec /dev/tty 2>&1
  
  ulimit -c 0
  trap "rm -f testcase[12].s testcase[12].s-* testcase-*.s.tmp" EXIT
  
  ${CLANG:-clang} -fintegrated-cc1 -Werror -O2 -std=gnu99 
-fstack-protector-strong -S testcase.c -o testcase1.s || exit 1
  ${CLANG:-clang} -fintegrated-cc1 -Werror -O2 -std=gnu99 
-fstack-protector-strong -S testcase.c -o testcase2.s 2>/dev/null || exit 1
  
  cmp -s testcase1.s testcase2.s
  test $? = 1 || exit 1
  
  exit 0

(Here `testcase.c` is a copy of the .c file in 
https://www.andric.com/freebsd/clang/bug246630-repro.tar.xz)

Using this script I could finally bisect, and arrived at the following commit 
which fixes the issue, i.e. it makes the outputs of both clang runs the same 
again, and it is rG0cecafd647cc 
 
("[BasicAA] Make BasicAA a cfg pass"). @asbirlea seems to indicate in the 
commit message that it influences the way the BasicAA pass is freed/invalidaed 
or not during runs?

So is this commit fixing it as an unintended side effect, or would it be 
according to expectation?  If the latter, we should merge it into 10.0.1, and I 
will create a PR for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

For completeness sake, here are the valgrind outputs of clang rGf7f1abdb889 
 
(llvmorg-11-init-16778) built by gcc 9.3.0-10ubuntu2 (in RelWithDebInfo mode):
F12078364: llvmorg-11-init-16778-gf7f1abdb889-gcc-1.log 


And the exact same version of clang, built by clang 10.0.0-4ubuntu1: F12078366: 
llvmorg-11-init-16778-gf7f1abdb889-clang-1.log 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D69825#2071687 , @dim wrote:

> Trying to reduce this now.


Unfortunately this turned out to be a red herring, as the test case got reduced 
by `creduce` to just:

  a() { b(""); }

The valgrind warnings are also different when you build clang with clang, 
instead of gcc as I did first. In that case, you get dozens of these instead:

  ==525651== Conditional jump or move depends on uninitialised value(s)
  ==525651==at 0xBB1D71: SimplifyAndInst(llvm::Value*, llvm::Value*, 
llvm::SimplifyQuery const&, unsigned int) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0xBBF6D0: ThreadBinOpOverPHI(llvm::Instruction::BinaryOps, 
llvm::Value*, llvm::Value*, llvm::SimplifyQuery const&, unsigned int) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0xBB1F87: SimplifyAndInst(llvm::Value*, llvm::Value*, 
llvm::SimplifyQuery const&, unsigned int) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x13898E8: 
llvm::InstCombiner::visitAnd(llvm::BinaryOperator&) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x1365A6D: llvm::InstCombiner::run() (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x1367AEC: combineInstructionsOverFunction(llvm::Function&, 
llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, 
llvm::TargetLibraryInfo&, llvm::DominatorTree&, 
llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, 
llvm::ProfileSummaryInfo*, bool, unsigned int, llvm::LoopInfo*) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x1369369: 
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x121015B: 
llvm::FPPassManager::runOnFunction(llvm::Function&) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x3BA5188: (anonymous 
namespace)::CGPassManager::runOnModule(llvm::Module&) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x1210B3F: llvm::legacy::PassManagerImpl::run(llvm::Module&) 
(in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x19A503A: 
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions 
const&, clang::CodeGenOptions const&, clang::TargetOptions const&, 
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, 
clang::BackendAction, std::unique_ptr >) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)
  ==525651==by 0x2500BD4: 
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (in 
/home/dim/obj/llvm-llvmorg-10.0.0-53-gf79cd71e145-linux5-x86_64-ninja-rel-1/bin/clang-10)

I'm unsure how to continue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D69825#2070926 , @hans wrote:

> In D69825#2063979 , @dim wrote:
>
> > FWIW, this change causes 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630, see in particular 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630#c18.
> >
> > For some reason, not spawning a new process for the cc1 stage can lead to 
> > non-reproducible output. The exact cause is not known yet.
>
>
> Can you share the preprocessed source and compiler command-line for printf.c, 
> either on the bug or here?


See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630#c26, and I've also 
uploaded the repro files to 
https://www.andric.com/freebsd/clang/bug246630-repro.tar.xz.

Running rGa3220dffcb1 
 under 
valgrind (on Linux) shows:

  ==120363== Conditional jump or move depends on uninitialised value(s)
  ==120363==at 0x1634474: llvm::ConstantExpr::getGetElementPtr(llvm::Type*, 
llvm::Constant*, llvm::ArrayRef, bool, llvm::Optional, llvm::Type*) (Constants.cpp:2191)
  ==120363==by 0x112D6D9: getGetElementPtr (Constants.h:1163)
  ==120363==by 0x112D6D9: (anonymous 
namespace)::SymbolicallyEvaluateGEP(llvm::GEPOperator const*, 
llvm::ArrayRef, llvm::DataLayout const&, 
llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:1005)
  ==120363==by 0x112DF70: (anonymous 
namespace)::ConstantFoldInstOperandsImpl(llvm::Value const*, unsigned int, 
llvm::ArrayRef, llvm::DataLayout const&, 
llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:1039)
  ==120363==by 0x112C165: (anonymous 
namespace)::ConstantFoldConstantImpl(llvm::Constant const*, llvm::DataLayout 
const&, llvm::TargetLibraryInfo const*, llvm::SmallDenseMap, 
llvm::detail::DenseMapPair >&) [clone 
.part.0] (ConstantFolding.cpp:1114)
  ==120363==by 0x112C5CF: llvm::ConstantFoldConstant(llvm::Constant const*, 
llvm::DataLayout const&, llvm::TargetLibraryInfo const*) 
(ConstantFolding.cpp:1194)
  ==120363==by 0x188F410: prepareICWorklistFromFunction 
(InstructionCombining.cpp:3584)
  ==120363==by 0x188F410: combineInstructionsOverFunction(llvm::Function&, 
llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, 
llvm::TargetLibraryInfo&, llvm::DominatorTree&, 
llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, 
llvm::ProfileSummaryInfo*, unsigned int, llvm::LoopInfo*) 
(InstructionCombining.cpp:3703)
  ==120363==by 0x189205F: runOnFunction (InstructionCombining.cpp:3789)
  ==120363==by 0x189205F: 
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) 
(InstructionCombining.cpp:3768)
  ==120363==by 0x16F4352: 
llvm::FPPassManager::runOnFunction(llvm::Function&) (LegacyPassManager.cpp:1482)
  ==120363==by 0x16F4DE8: llvm::FPPassManager::runOnModule(llvm::Module&) 
(LegacyPassManager.cpp:1518)
  ==120363==by 0x16F51A2: runOnModule (LegacyPassManager.cpp:1583)
  ==120363==by 0x16F51A2: llvm::legacy::PassManagerImpl::run(llvm::Module&) 
(LegacyPassManager.cpp:1695)
  ==120363==by 0x1FF4CFE: EmitAssembly (BackendUtil.cpp:954)
  ==120363==by 0x1FF4CFE: 
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions 
const&, clang::CodeGenOptions const&, clang::TargetOptions const&, 
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, 
clang::BackendAction, std::unique_ptr >) (BackendUtil.cpp:1677)
  ==120363==by 0x2C471A8: 
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) 
(CodeGenAction.cpp:335)
  ==120363==  Uninitialised value was created by a stack allocation
  ==120363==at 0x112C653: (anonymous 
namespace)::SymbolicallyEvaluateGEP(llvm::GEPOperator const*, 
llvm::ArrayRef, llvm::DataLayout const&, 
llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:832)

Trying to reduce this now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

FWIW, this change causes 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630, see in particular 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630#c18.

For some reason, not spawning a new process for the cc1 stage can lead to 
non-reproducible output. The exact cause is not known yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D77776: [Driver] Drop support for FreeBSD < 10

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D6#1971543 , @arichardson wrote:

> Alternatively, the checks could be changed to also handle OSMajorVersion == 0 
> and translate that to 10.
>  This seems to be what NetBSD.cpp does. Darwin.cpp also infers the version 
> from the host when running on macos.


Yeah, I think that is much better. If people want to explicitly target 
foobar-freebsd9, they should be free to do so. But the default should indeed be 
either the host version, or if that cannot be determined, the lowest supported 
version, which is currently 10. For these particular features the exact version 
doesn't matter that much though, it's just about whether libc++ should  be the 
default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6



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

[PATCH] D71600: PowerPC 32-bit - forces 8 byte lock/lock_free decisions at compiled time

[Dimitry Andric via Phabricator via cfe-commits]

dim added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:11180
 
+// Avoid emiting call for runtime decision on PowerPC 32-bit
+// The lock free possibilities on this platform are covered by the lines 

`s/emiting/emitting/`



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71600



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

[PATCH] D72910: Fix a bug with clang with object destructor, while skipping object initialization - make clang crash

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Aha, which version of clang-cl are you using?  With the released version of 
clang-cl 9.0.1, I get a warning instead of an error:

  cleanup.cpp(15,5): warning: jump from this goto statement to its label is a 
Microsoft extension [-Wmicrosoft-goto]
  goto clean_up;
  ^
  cleanup.cpp(20,7): note: jump bypasses variable initialization
int i = 0;
^
  cleanup.cpp(18,4): note: jump bypasses variable initialization
  A a;
^
  1 warning generated.

So apparently another code path is activated when the target is Microsoft.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72910



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

[PATCH] D72910: Fix a bug with clang with object destructor, while skipping object initialization - make clang crash

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Eh, no it does not crash clang, at least not here?  Instead it gives you a 
compile error, as it should:

  cleanup.cpp:15:5: error: cannot jump from this goto statement to its label
  goto clean_up;
  ^
  cleanup.cpp:20:7: note: jump bypasses variable initialization
int i = 0;
^
  cleanup.cpp:18:4: note: jump bypasses variable initialization
  A a;
^
  1 error generated.

(This is with clang 9.0.1 on FreeBSD. I haven't tried on Windows.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72910



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

[PATCH] D71827: [clang] avoid strict aliasing violation in assert

[Dimitry Andric via Phabricator via cfe-commits]

dim added inline comments.



Comment at: clang/include/clang/AST/DeclContextInternals.h:102
 // at getLookupResult.
-assert(*(NamedDecl **) == ND &&
+assert(Data.getAddrOfPtr1() && *Data.getAddrOfPtr1() == ND &&
"PointerUnion mangles the NamedDecl pointer!");

Hm, I don't have much experience with the `PointerUnion` class, but from a 
cursory look at `llvm/include/llvm/ADT/PointerUnion.h`, I would rather say that 
using `dyn_cast` here would be more appropriate?  E.g. that definition 
literally says:

```
  /// Returns the current pointer if it is of the specified pointer type,
  /// otherwises returns null.
```

So something like:

```
  assert(Data.dyn_cast == ND &&
"PointerUnion mangles the NamedDecl pointer!");
```

or even using the existing `getAsDecl` member function, which does exactly the 
same:

```
  assert(Data.getAsDecl() == ND &&
"PointerUnion mangles the NamedDecl pointer!");
```

Or is this particular check about the type being *only* the base class 
`NamedDecl`, and not any derived class?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71827



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

[PATCH] D72014: [PowerPC]: Add powerpcspe target triple subarch component

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim 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/D72014/new/

https://reviews.llvm.org/D72014



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

[PATCH] D69990: Populate CUDA flags on FreeBSD too, as many other toolchains do.

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGee31adb7fa42: Populate CUDA flags on FreeBSD too, as many 
other toolchains do. (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69990

Files:
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/FreeBSD.h
  clang/test/Driver/cuda-options-freebsd.cu

Index: clang/test/Driver/cuda-options-freebsd.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-options-freebsd.cu
@@ -0,0 +1,289 @@
+// Tests CUDA compilation pipeline construction in Driver.
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Simple compilation case. Compile device-side to PTX assembly and make sure
+// we use it on the host side.
+// RUN: %clang -### -target x86_64-unknown-freebsd -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix NOLINK %s
+
+// Typical compilation + link case.
+// RUN: %clang -### -target x86_64-unknown-freebsd %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// Verify that --cuda-host-only disables device-side compilation, but doesn't
+// disable host-side compilation/linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// Verify that --cuda-device-only disables host-side compilation and linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// Check that the last of --cuda-compile-host-device, --cuda-host-only, and
+// --cuda-device-only wins.
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only \
+// RUN:   --cuda-compile-host-device %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only \
+// RUN:   --cuda-compile-host-device %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// Verify that --cuda-gpu-arch option passes the correct GPU architecture to
+// device compilation.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-gpu-arch=sm_30 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix DEVICE-SM30 -check-prefix HOST \
+// RUN:-check-prefix INCLUDES-DEVICE -check-prefix NOLINK %s
+
+// Verify that there is one device-side compilation per --cuda-gpu-arch args
+// and that all results are included on the host side.
+// RUN: %clang -### -target x86_64-unknown-freebsd \
+// RUN:   --cuda-gpu-arch=sm_35 --cuda-gpu-arch=sm_30 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefixes DEVICE,DEVICE-NOSAVE,DEVICE2 \
+// RUN: -check-prefixes DEVICE-SM30,DEVICE2-SM35 \
+// RUN: -check-prefixes INCLUDES-DEVICE,INCLUDES-DEVICE2 \
+// RUN: -check-prefixes HOST,HOST-NOSAVE,NOLINK %s
+
+// Verify that device-side results are passed to the correct tool when
+// -save-temps is used.
+// RUN: %clang -### -target x86_64-unknown-freebsd -save-temps -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-SAVE \
+// RUN:-check-prefix HOST -check-prefix HOST-SAVE -check-prefix NOLINK %s
+
+// 

[PATCH] D69990: Populate CUDA flags on FreeBSD too, as many other toolchains do.

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D69990#1750348 , @tra wrote:

> LGTM, though I'm curious if it's particularly useful. Last time I checked 
> NVIDIA didn't ship libcudart for FreeBSD and without it it's rather 
> cumbersome to use CUDA in practice.


After extracting the necessary CUDA stuff and enabling Linux emulation (for 
`ptxas`), at least a "hello world" sample program compiles to an object file:

  $ 
~/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/bin/clang
 --cuda-path=/share/dim/src/freebsd/cuda/cuda-10.1 --cuda-gpu-arch=sm_60 -c 
hello.cu -v
  clang version 10.0.0 (https://github.com/llvm/llvm-project.git 
014799db369c8e30c222c0e9d3ea143f349c3db9)
  Target: x86_64-unknown-freebsd13.0
  Thread model: posix
  InstalledDir: 
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/bin
  Found CUDA installation: /share/dim/src/freebsd/cuda/cuda-10.1, version 10.1
   
"/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/bin/clang"
 -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-unknown-freebsd13.0 -S 
-disable-free -main-file-name hello.cu -mrelocation-model static -mthread-model 
posix -mframe-pointer=all -fno-rounding-math -no-integrated-as -fuse-init-array 
-fcuda-is-device -mlink-builtin-bitcode 
/share/dim/src/freebsd/cuda/cuda-10.1/nvvm/libdevice/libdevice.10.bc 
-target-feature +ptx64 -target-sdk-version=10.1 -target-cpu sm_60 
-dwarf-column-info -debugger-tuning=gdb -v -resource-dir 
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0
 -internal-isystem 
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0/include/cuda_wrappers
 -internal-isystem /share/dim/src/freebsd/cuda/cuda-10.1/include -include 
__clang_cuda_runtime_wrapper.h -internal-isystem /usr/include/c++/v1 
-internal-isystem /usr/include/c++/v1 -fdeprecated-macro 
-fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /tmp 
-ferror-limit 19 -fmessage-length 160 -fgnuc-version=4.2.1 -fobjc-runtime=gcc 
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o 
/home/dim/tmp/hello-f032c8.s -x cuda hello.cu
  clang -cc1 version 10.0.0 based upon LLVM 10.0.0git default target 
x86_64-unknown-freebsd13.0
  ignoring duplicate directory "/usr/include/c++/v1"
  #include "..." search starts here:
  #include <...> search starts here:
   
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0/include/cuda_wrappers
   /share/dim/src/freebsd/cuda/cuda-10.1/include
   /usr/include/c++/v1
   
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0/include
   /usr/include
  End of search list.
   "/share/dim/src/freebsd/cuda/cuda-10.1/bin/ptxas" -m64 -O0 -v --gpu-name 
sm_60 --output-file /home/dim/tmp/hello-54422a.o /home/dim/tmp/hello-f032c8.s
  ptxas info: 23 bytes gmem
  ptxas info: Compiling entry function '_Z10cuda_hellov' for 'sm_60'
  ptxas info: Function properties for _Z10cuda_hellov
  0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
  ptxas info: Used 8 registers, 320 bytes cmem[0]
   "/share/dim/src/freebsd/cuda/cuda-10.1/bin/fatbinary" -64 --create 
/home/dim/tmp/hello-9cd109.fatbin 
--image=profile=sm_60,file=/home/dim/tmp/hello-54422a.o 
--image=profile=compute_60,file=/home/dim/tmp/hello-f032c8.s
   
"/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/bin/clang"
 -cc1 -triple x86_64-unknown-freebsd13.0 -target-sdk-version=10.1 -aux-triple 
nvptx64-nvidia-cuda -emit-obj -mrelax-all -disable-free -main-file-name 
hello.cu -mrelocation-model static -mthread-model posix -mframe-pointer=all 
-fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables 
-fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v 
-resource-dir 
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0
 -internal-isystem 
/home/dim/obj/llvm/llvmorg-10-init-10100-g9a5b7b785bf-freebsd13-amd64-ninja-rel-1/lib/clang/10.0.0/include/cuda_wrappers
 -internal-isystem /share/dim/src/freebsd/cuda/cuda-10.1/include -include 
__clang_cuda_runtime_wrapper.h -internal-isystem /usr/include/c++/v1 
-internal-isystem /usr/include/c++/v1 -fdeprecated-macro 
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 160 
-fgnuc-version=4.2.1 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions 
-fdiagnostics-show-option -fcolor-diagnostics -fcuda-include-gpubinary 
/home/dim/tmp/hello-9cd109.fatbin -faddrsig -o hello.o -x cuda hello.cu
  clang -cc1 version 10.0.0 based upon LLVM 10.0.0git default target 
x86_64-unknown-freebsd13.0
  ignoring duplicate directory "/usr/include/c++/v1"
  #include "..." search starts here:
  #include <...> search starts here:
   

[PATCH] D69990: Populate CUDA flags on FreeBSD too, as many other toolchains do.

[Dimitry Andric via Phabricator via cfe-commits]

dim added reviewers: tra, yaxunl, ABataev.
dim added a comment.

Adding a few people who might know a bit more about CUDA specific things. 
Please take a look if this review makes any sense, thanks. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69990



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

[PATCH] D69990: Populate CUDA flags on FreeBSD too, as many other toolchains do.

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 229883.
dim added a comment.

- Add cuda options test, copied from cuda-options.cu.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69990

Files:
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/FreeBSD.h
  clang/test/Driver/cuda-options-freebsd.cu

Index: clang/test/Driver/cuda-options-freebsd.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-options-freebsd.cu
@@ -0,0 +1,289 @@
+// Tests CUDA compilation pipeline construction in Driver.
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Simple compilation case. Compile device-side to PTX assembly and make sure
+// we use it on the host side.
+// RUN: %clang -### -target x86_64-unknown-freebsd -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix NOLINK %s
+
+// Typical compilation + link case.
+// RUN: %clang -### -target x86_64-unknown-freebsd %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// Verify that --cuda-host-only disables device-side compilation, but doesn't
+// disable host-side compilation/linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// Verify that --cuda-device-only disables host-side compilation and linking.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// Check that the last of --cuda-compile-host-device, --cuda-host-only, and
+// --cuda-device-only wins.
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-host-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix NODEVICE -check-prefix HOST \
+// RUN:-check-prefix NOINCLUDES-DEVICE -check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-compile-host-device \
+// RUN:--cuda-device-only %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix NOHOST -check-prefix NOLINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-host-only \
+// RUN:   --cuda-compile-host-device %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-device-only \
+// RUN:   --cuda-compile-host-device %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix HOST -check-prefix INCLUDES-DEVICE \
+// RUN:-check-prefix LINK %s
+
+// Verify that --cuda-gpu-arch option passes the correct GPU architecture to
+// device compilation.
+// RUN: %clang -### -target x86_64-unknown-freebsd --cuda-gpu-arch=sm_30 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-NOSAVE \
+// RUN:-check-prefix DEVICE-SM30 -check-prefix HOST \
+// RUN:-check-prefix INCLUDES-DEVICE -check-prefix NOLINK %s
+
+// Verify that there is one device-side compilation per --cuda-gpu-arch args
+// and that all results are included on the host side.
+// RUN: %clang -### -target x86_64-unknown-freebsd \
+// RUN:   --cuda-gpu-arch=sm_35 --cuda-gpu-arch=sm_30 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefixes DEVICE,DEVICE-NOSAVE,DEVICE2 \
+// RUN: -check-prefixes DEVICE-SM30,DEVICE2-SM35 \
+// RUN: -check-prefixes INCLUDES-DEVICE,INCLUDES-DEVICE2 \
+// RUN: -check-prefixes HOST,HOST-NOSAVE,NOLINK %s
+
+// Verify that device-side results are passed to the correct tool when
+// -save-temps is used.
+// RUN: %clang -### -target x86_64-unknown-freebsd -save-temps -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEVICE -check-prefix DEVICE-SAVE \
+// RUN:-check-prefix HOST -check-prefix HOST-SAVE -check-prefix NOLINK %s
+
+// Verify that device-side results are passed to the correct tool when
+// 

[PATCH] D69990: Populate CUDA flags on FreeBSD too, as many other toolchains do.

[Dimitry Andric via Phabricator via cfe-commits]

dim edited reviewers, added: dim, emaste; removed: clang.
dim added a comment.

I'll work on a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69990



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

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3db6783d8a7d: Check result of emitStrLen before passing it 
to CreateGEP (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70143

Files:
  llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
  llvm/test/Transforms/InstCombine/pr43081.ll


Index: llvm/test/Transforms/InstCombine/pr43081.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/pr43081.ll
@@ -0,0 +1,15 @@
+; RUN: opt < %s -instcombine -disable-builtin strlen -S | FileCheck %s
+
+target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+declare i8* @strchr(i8*, i32)
+
+define i8* @pr43081(i8* %a) {
+entry:
+  %a.addr = alloca i8*, align 8
+  store i8* %a, i8** %a.addr, align 8
+  %0 = load i8*, i8** %a.addr, align 8
+  %call = call i8* @strchr(i8* %0, i32 0)
+  ret i8* %call
+; CHECK: call i8* @strchr
+}
Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -364,8 +364,8 @@
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
 if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+  if (Value *StrLen = emitStrLen(SrcStr, B, DL, TLI))
+return B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr");
 return nullptr;
   }
 


Index: llvm/test/Transforms/InstCombine/pr43081.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/pr43081.ll
@@ -0,0 +1,15 @@
+; RUN: opt < %s -instcombine -disable-builtin strlen -S | FileCheck %s
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+declare i8* @strchr(i8*, i32)
+
+define i8* @pr43081(i8* %a) {
+entry:
+  %a.addr = alloca i8*, align 8
+  store i8* %a, i8** %a.addr, align 8
+  %0 = load i8*, i8** %a.addr, align 8
+  %call = call i8* @strchr(i8* %0, i32 0)
+  ret i8* %call
+; CHECK: call i8* @strchr
+}
Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -364,8 +364,8 @@
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
 if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+  if (Value *StrLen = emitStrLen(SrcStr, B, DL, TLI))
+return B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr");
 return nullptr;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 229172.
dim added a comment.

Now `opt` supports `-disable-builtin`, move the test to 
`llvm/test/Transforms/InstCombine`.

Also use code style of nearest preceding constructs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70143

Files:
  llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
  llvm/test/Transforms/InstCombine/pr43081.ll


Index: llvm/test/Transforms/InstCombine/pr43081.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/pr43081.ll
@@ -0,0 +1,15 @@
+; RUN: opt < %s -instcombine -disable-builtin strlen -S | FileCheck %s
+
+target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+declare i8* @strchr(i8*, i32)
+
+define i8* @pr43081(i8* %a) {
+entry:
+  %a.addr = alloca i8*, align 8
+  store i8* %a, i8** %a.addr, align 8
+  %0 = load i8*, i8** %a.addr, align 8
+  %call = call i8* @strchr(i8* %0, i32 0)
+  ret i8* %call
+; CHECK: call i8* @strchr
+}
Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -364,8 +364,8 @@
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
 if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+  if (Value *StrLen = emitStrLen(SrcStr, B, DL, TLI))
+return B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr");
 return nullptr;
   }
 


Index: llvm/test/Transforms/InstCombine/pr43081.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/pr43081.ll
@@ -0,0 +1,15 @@
+; RUN: opt < %s -instcombine -disable-builtin strlen -S | FileCheck %s
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+declare i8* @strchr(i8*, i32)
+
+define i8* @pr43081(i8* %a) {
+entry:
+  %a.addr = alloca i8*, align 8
+  store i8* %a, i8** %a.addr, align 8
+  %0 = load i8*, i8** %a.addr, align 8
+  %call = call i8* @strchr(i8* %0, i32 0)
+  ret i8* %call
+; CHECK: call i8* @strchr
+}
Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -364,8 +364,8 @@
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
 if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+  if (Value *StrLen = emitStrLen(SrcStr, B, DL, TLI))
+return B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr");
 return nullptr;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

I submitted D70193  for adding a 
`-disable-builtin` option to `opt`.  Once that is committed, this review can 
continue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70143



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

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

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



Comment at: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp:370
+: nullptr;
+}
 return nullptr;

jdoerfert wrote:
> Consistent style please:
> 
> ```
> if (Value *StrLen = emitStrLen(SrcStr, B, DL, TLI)
>   return B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr");
> ```
Consistent with what? :) In this same file, I see at least the following calls 
to `emitStrLen`, some of which use the `if(!x) return nullptr` spelling, others 
which use `return x ? y : nullptr`:

```
  Value *DstLen = emitStrLen(Dst, B, DL, TLI);
  if (!DstLen)
return nullptr;
```

```
  if (Dst == Src) { // stpcpy(x,x)  -> x+strlen(x)
Value *StrLen = emitStrLen(Src, B, DL, TLI);
return StrLen ? B.CreateInBoundsGEP(B.getInt8Ty(), Dst, StrLen) : nullptr;
  }
```

```
Value *StrLen = emitStrLen(CI->getArgOperand(1), B, DL, TLI);
if (!StrLen)
  return nullptr;
```

```
Value *Len = emitStrLen(CI->getArgOperand(2), B, DL, TLI);
if (!Len)
  return nullptr;
```

```
Value *StrLen = emitStrLen(Src, B, DL, TLI);
return StrLen ? B.CreateInBoundsGEP(B.getInt8Ty(), Dst, StrLen) : nullptr;
```

But I'm fine with whatever you are suggesting, obviously.  It just seems 
strange to introduce yet another spelling variant, making it less consistent, 
not more...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70143



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

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D70143#1742885 , @lebedev.ri wrote:

> This should have a llvm ir test in `llvm/test/transforms/instcombine` i 
> think, not a clang test.


Yes, I thought so too, but I could not get it to work (i.e. crash) with LLVM 
IR.  I just don't understand how `opt` works, and it does not have a 
`-fno-builtin-strlen` option either.  Therefore, I made it work with clang, as 
having a working test is better than no test at all.  But I'm fine with leaving 
out the test, it was just for completeness' sake.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70143



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

[PATCH] D70143: Check result of emitStrLen before passing it to CreateGEP

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: xbolva00, spatel, jdoerfert, efriedma.
Herald added subscribers: cfe-commits, hiraditya.
Herald added projects: clang, LLVM.

This fixes PR43081, where the transformation of `strchr(p, 0) -> p +
strlen(p)` can cause a segfault, if `-fno-builtin-strlen` is used.  In
that case, `emitStrLen` returns nullptr, which CreateGEP is not designed
to handle.  Also add the minimized code from the PR as a test case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70143

Files:
  clang/test/CodeGen/builtin-replace-strchr-with-strlen.c
  llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp


Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -363,9 +363,11 @@
   // a string literal.  If so, we can constant fold.
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
-if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+if (CharC->isZero()) { // strchr(p, 0) -> p + strlen(p)
+  Value *StrLen = emitStrLen(SrcStr, B, DL, TLI);
+  return StrLen ? B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr")
+: nullptr;
+}
 return nullptr;
   }
 
Index: clang/test/CodeGen/builtin-replace-strchr-with-strlen.c
===
--- /dev/null
+++ clang/test/CodeGen/builtin-replace-strchr-with-strlen.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple x86_64-- -S -O1 -fno-builtin-strlen %s -o - | 
FileCheck %s
+char *strchr(const char *, int);
+char *b(char *a) {
+  return strchr(a, '\0');
+// CHECK: jmp  strchr
+}


Index: llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
+++ llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
@@ -363,9 +363,11 @@
   // a string literal.  If so, we can constant fold.
   StringRef Str;
   if (!getConstantStringInfo(SrcStr, Str)) {
-if (CharC->isZero()) // strchr(p, 0) -> p + strlen(p)
-  return B.CreateGEP(B.getInt8Ty(), SrcStr, emitStrLen(SrcStr, B, DL, TLI),
- "strchr");
+if (CharC->isZero()) { // strchr(p, 0) -> p + strlen(p)
+  Value *StrLen = emitStrLen(SrcStr, B, DL, TLI);
+  return StrLen ? B.CreateGEP(B.getInt8Ty(), SrcStr, StrLen, "strchr")
+: nullptr;
+}
 return nullptr;
   }
 
Index: clang/test/CodeGen/builtin-replace-strchr-with-strlen.c
===
--- /dev/null
+++ clang/test/CodeGen/builtin-replace-strchr-with-strlen.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple x86_64-- -S -O1 -fno-builtin-strlen %s -o - | FileCheck %s
+char *strchr(const char *, int);
+char *b(char *a) {
+  return strchr(a, '\0');
+// CHECK: jmp	strchr
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70110: [Driver][FreeBSD] Enable unwind tables on !amd64

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim 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/D70110/new/

https://reviews.llvm.org/D70110



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

[PATCH] D60220: [CUDA][Windows] Final fix for bug 38811 (Step 3 of 3)

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Hm, I would really say that `__isnan` and the other `__` prefixed functions are 
Linuxisms, or more accurately, glibc-isms.  They also don't exist on e.g. macOS:

  $ cat check-isnan.cpp
  #include 
  
  int check_isnan(double d)
  {
return ::__isnan(d);
  }
  
  $ clang -v
  Apple clang version 11.0.0 (clang-1100.0.33.8)
  Target: x86_64-apple-darwin18.7.0
  Thread model: posix
  InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
  
  $ clang -c check-isnan.cpp
  check-isnan.cpp:5:12: error: no member named '__isnan' in the global 
namespace; did you mean 'isnan'?
return ::__isnan(d);
   ~~^~~
 isnan
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/math.h:519:1:
 note: 'isnan' declared here
  isnan(_A1 __lcpp_x) _NOEXCEPT
  ^
  1 error generated.

Why can't the regular `isnan` be used instead?  Or is this a CUDA-specific 
requirement?  (Apologies, but I know next to nothing about CUDA :) )


Repository:
  rC Clang

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

https://reviews.llvm.org/D60220



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

[PATCH] D47987: Provide only one declaration of __throw_runtime_error

[Dimitry Andric via Phabricator via cfe-commits]

dim abandoned this revision.
dim added a comment.
Herald added a subscriber: libcxx-commits.

Obsoleted by D58425  (and rCXX354515 
).


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D47987



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

[PATCH] D67992: [Sema] Add FunctionTypeUnwrapper

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

This works for me, and also for the original test case from 
https://bugs.freebsd.org/240764.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67992



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

[PATCH] D67119: On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372261: On PowerPC, Secure-PLT by default for FreeBSD 13 and 
higher (authored by dim, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67119

Files:
  cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp


Index: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


Index: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67119: On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: emaste, jhibbits, hfinkel.
Herald added subscribers: steven.zhang, shchenz, jsji, MaskRay, kbarton, 
krytarowski, nemanjai.
Herald added a project: clang.

In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and
higher transitioned to Secure-PLT for PowerPC.  This part contains the
changes in clang's PPC architecture defaults.


Repository:
  rC Clang

https://reviews.llvm.org/D67119

Files:
  lib/Driver/ToolChains/Arch/PPC.cpp


Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Dimitry Andric via Phabricator via cfe-commits]

dim abandoned this revision.
dim added a comment.

No longer needed after rC362328  and 
follow-ups.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: hintonda, dcoughlin, NoQ.
Herald added subscribers: dkrupp, donat.nagy, Szelethus, a.sidorin, 
baloghadamsoftware, mgorny.
Herald added a project: clang.

Attempting to build clang with CLANG_ENABLE_STATIC_ANALYZER=OFF fails
after rC362328 , because the new plugins 
under lib/Analysis/plugins are
dependent on the static analyzer libraries.

Add checks to disable building these if CLANG_ENABLE_STATIC_ANALYZER is
OFF.


Repository:
  rC Clang

https://reviews.llvm.org/D62873

Files:
  lib/Analysis/plugins/CMakeLists.txt
  test/CMakeLists.txt


Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -119,14 +119,12 @@
   endif()
 endif()
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (LLVM_ENABLE_PLUGINS)
-list(APPEND CLANG_TEST_DEPS
-  SampleAnalyzerPlugin
-  CheckerDependencyHandlingAnalyzerPlugin
-  CheckerOptionHandlingAnalyzerPlugin
-  )
-  endif()
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
+  list(APPEND CLANG_TEST_DEPS
+SampleAnalyzerPlugin
+CheckerDependencyHandlingAnalyzerPlugin
+CheckerOptionHandlingAnalyzerPlugin
+)
 endif()
 
 add_custom_target(clang-test-depends DEPENDS ${CLANG_TEST_DEPS})
Index: lib/Analysis/plugins/CMakeLists.txt
===
--- lib/Analysis/plugins/CMakeLists.txt
+++ lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)


Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -119,14 +119,12 @@
   endif()
 endif()
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (LLVM_ENABLE_PLUGINS)
-list(APPEND CLANG_TEST_DEPS
-  SampleAnalyzerPlugin
-  CheckerDependencyHandlingAnalyzerPlugin
-  CheckerOptionHandlingAnalyzerPlugin
-  )
-  endif()
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
+  list(APPEND CLANG_TEST_DEPS
+SampleAnalyzerPlugin
+CheckerDependencyHandlingAnalyzerPlugin
+CheckerOptionHandlingAnalyzerPlugin
+)
 endif()
 
 add_custom_target(clang-test-depends DEPENDS ${CLANG_TEST_DEPS})
Index: lib/Analysis/plugins/CMakeLists.txt
===
--- lib/Analysis/plugins/CMakeLists.txt
+++ lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60748: Fix i386 struct and union parameter alignment

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In fact, it is probably better to turn the OS check around, e.g. *only* 
increase the alignment for Linux, and nowhere else.


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

https://reviews.llvm.org/D60748



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

[PATCH] D60748: Fix i386 struct and union parameter alignment

[Dimitry Andric via Phabricator via cfe-commits]

dim added subscribers: emaste, dim.
dim added a comment.

Please also exclude FreeBSD from these changes, since we care a lot about 
backwards compatibility, and specifically about alignment requirements.  (We 
have run into many issues in our ports collection where upstream assumes 
everything is 16-byte aligned on i386, which is *NOT* ABI compliant.)


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

https://reviews.llvm.org/D60748



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

[PATCH] D55576: [libcxx] [test] [support] Use socket()+bind() to create unix sockets portably

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In D55576#1332370 , @mgorny wrote:

> @dim, thanks for the review. Should I also try removing the following 
> restriction?
>
>   #if !defined(__APPLE__) && !defined(__FreeBSD__) // No support for domain 
> sockets
>   {env.create_socket("socket"), file_type::socket},
>   #endif


Well, `test/support/filesystem_test_helper.hpp` also has this comment:

// OS X and FreeBSD doesn't support socket files so we shouldn't even
// allow tests to call this unguarded.
  #if !defined(__FreeBSD__) && !defined(__APPLE__)
  std::string create_socket(std::string file) {
  file = sanitize_path(std::move(file));
  fs_helper_run(fs_make_cmd("create_socket", file));
  return file;
  }
  #endif

but it looks like you now fixed it with this change to 
`filesystem_dynamic_test_helper.py`.  So I guess after this, it should be safe 
to remove the FreeBSD specific exception.  I don't know about macOS, though.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D55576



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

[PATCH] D55576: [libcxx] [test] [support] Use socket()+bind() to create unix sockets portably

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

LGTM.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D55576



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

[PATCH] D54724: [Driver] Automatically include C++ library dependencies

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In https://reviews.llvm.org/D54724#1303844, @phosek wrote:

> In https://reviews.llvm.org/D54724#1303809, @dim wrote:
>
> > I think this is the wrong direction, placing "common" code in 
> > `addCXXStdlibLinkDeps`, which then has all kinds of ugly ifs and switches 
> > for different OSes?  Let different OSes handle this in their own way, maybe.
>
>
> You mean handling this in individual `ToolChain` subclasses? I've considered 
> doing that. The reason I went with a single method is because we already use 
> this approach for other types of runtimes like sanitizers, XRay, etc. There'd 
> be still some duplication for handling different C++ libraries, but I'd be 
> fine changing the implementation to use that approach if there's a strong 
> preference for doing so.


I think I understand the motivation, it's just that the toolchain classes were 
split up specifically to avoid `if(OS==foo) ... else if(OS==bar) ... else 
if(OS==baz)` mazes.  So this feels a little like a regression in that sense, 
putting back the OS-specific ifs in a common function.  But I guess it is a 
pattern that pops up more often.

>> Until now I have not encountered an issue where I needed to add -lpthread to 
>> the link command line for a static C++ application; I think that is only 
>> needed when you actually use threading primitives?  But still, I would 
>> rather see this in the OS-dependent handling functions.
> 
> Have you been using libc++ or just libstdc++? libstdc++ is cheating a bit, 
> because it relies on threading functions that are provided by libgcc (which 
> in turn call into pthread), so -lpthread is not needed when using libstdc++, 
> even when you link it statically. libc++ doesn't rely on these functions 
> because it supports different builtin libraries (like compiler-rt) hence 
> having to specify -lpthread explicitly.

We've been using libc++ by default since FreeBSD 10.x, and all older versions 
are now EOLed.  That said, we have always used a linker script to link in 
libc++.so:

  $ cat /usr/lib/libc++.so
  /* $FreeBSD: projects/clang700-import/lib/libc++/libc++.ldscript 305102 
2016-08-31 00:11:35Z bapt $ */
  GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )

and for the static case, we've always just added the relevant .o files from 
libcxxrt into libc++.a:

  $ ar tv /usr/lib/libc++.a
  rw-r--r--   0/0 21720 Jan  1 01:00 1970 variant.o
  rw-r--r--   0/0 61648 Jan  1 01:00 1970 valarray.o
  rw-r--r--   0/0 18224 Jan  1 01:00 1970 utility.o
  rw-r--r--   0/0 10656 Jan  1 01:00 1970 typeinfo.o
  rw-r--r--   0/0198080 Jan  1 01:00 1970 strstream.o
  rw-r--r--   0/0 59264 Jan  1 01:00 1970 shared_mutex.o
  rw-r--r--   0/0231552 Jan  1 01:00 1970 regex.o
  rw-r--r--   0/0 96200 Jan  1 01:00 1970 random.o
  rw-r--r--   0/0 25240 Jan  1 01:00 1970 optional.o
  rw-r--r--   0/0239552 Jan  1 01:00 1970 iostream.o
  rw-r--r--   0/0 17728 Jan  1 01:00 1970 functional.o
  rw-r--r--   0/0219984 Jan  1 01:00 1970 debug.o
  rw-r--r--   0/0 58256 Jan  1 01:00 1970 chrono.o
  rw-r--r--   0/0 35672 Jan  1 01:00 1970 charconv.o
  rw-r--r--   0/0 21280 Jan  1 01:00 1970 bind.o
  rw-r--r--   0/0 24312 Jan  1 01:00 1970 any.o
  rw-r--r--   0/0   1010288 Jan  1 01:00 1970 algorithm.o
  rw-r--r--   0/0 42944 Jan  1 01:00 1970 hash.o
  rw-r--r--   0/0 45152 Jan  1 01:00 1970 cxxrt_typeinfo.o
  rw-r--r--   0/0278784 Jan  1 01:00 1970 cxxrt_libelftc_dem_gnu3.o
  rw-r--r--   0/0 17704 Jan  1 01:00 1970 cxxrt_stdexcept.o
  rw-r--r--   0/0224664 Jan  1 01:00 1970 thread.o
  rw-r--r--   0/0218392 Jan  1 01:00 1970 future.o
  rw-r--r--   0/0 31456 Jan  1 01:00 1970 exception.o
  rw-r--r--   0/0   4604424 Jan  1 01:00 1970 locale.o
  rw-r--r--   0/0 27216 Jan  1 01:00 1970 vector.o
  rw-r--r--   0/0102712 Jan  1 01:00 1970 mutex.o
  rw-r--r--   0/0 63872 Jan  1 01:00 1970 memory.o
  rw-r--r--   0/0   1261888 Jan  1 01:00 1970 ios.o
  rw-r--r--   0/0 69528 Jan  1 01:00 1970 condition_variable.o
  rw-r--r--   0/0181368 Jan  1 01:00 1970 system_error.o
  rw-r--r--   0/0   2006648 Jan  1 01:00 1970 string.o
  rw-r--r--   0/0105408 Jan  1 01:00 1970 stdexcept.o
  rw-r--r--   0/0 37552 Jan  1 01:00 1970 new.o
  rw-r--r--   0/0 10280 Jan  1 01:00 1970 cxxrt_memory.o
  rw-r--r--   0/0  4880 Jan  1 01:00 1970 cxxrt_auxhelper.o
  rw-r--r--   0/0  2872 Jan  1 01:00 1970 cxxrt_terminate.o
  rw-r--r--   0/0123504 Jan  1 01:00 1970 cxxrt_exception.o
  rw-r--r--   0/0 18136 Jan  1 01:00 1970 cxxrt_dynamic_cast.o
  rw-r--r--   0/0  5696 Jan  1 01:00 1970 cxxrt_guard.o

But 

[PATCH] D54724: [Driver] Automatically include C++ library dependencies

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

I think this is the wrong direction, placing "common" code in 
`addCXXStdlibLinkDeps`, which then has all kinds of ugly ifs and switches for 
different OSes?  Let different OSes handle this in their own way, maybe.

Until now I have not encountered an issue where I needed to add -lpthread to 
the link command line for a static C++ application; I think that is only needed 
when you actually use threading primitives?  But still, I would rather see this 
in the OS-dependent handling functions.


Repository:
  rC Clang

https://reviews.llvm.org/D54724



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

[PATCH] D52394: [libcxx] Fix the definition of the check-cxx-abilist target on Darwin

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Ah, sorry about that! I should have realized this, but my CMake-fu is weak. :)


Repository:
  rL LLVM

https://reviews.llvm.org/D52394



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

[PATCH] D50799: Fix for PR 38495: no longer compiles on FreeBSD, due to lack of timespec_get()

[Dimitry Andric via Phabricator via cfe-commits]

dim accepted this revision.
dim added a comment.

LGTM.


https://reviews.llvm.org/D50799



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

[PATCH] D24867: Request init/fini array on FreeBSD 12 and later

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL336008: Request init/fini array on FreeBSD 12 and later 
(authored by dim, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D24867?vs=72282=153554#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24867

Files:
  cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
  cfe/trunk/test/Driver/constructors.c


Index: cfe/trunk/test/Driver/constructors.c
===
--- cfe/trunk/test/Driver/constructors.c
+++ cfe/trunk/test/Driver/constructors.c
@@ -80,6 +80,14 @@
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target arm64-none-none-eabi \
 // RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd11 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd12 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
 //
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
 // RUN: -target sparc-sun-solaris2.11 \
Index: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
@@ -2543,6 +2543,8 @@
   bool UseInitArrayDefault =
   getTriple().getArch() == llvm::Triple::aarch64 ||
   getTriple().getArch() == llvm::Triple::aarch64_be ||
+  (getTriple().getOS() == llvm::Triple::FreeBSD &&
+   getTriple().getOSMajorVersion() >= 12) ||
   (getTriple().getOS() == llvm::Triple::Linux &&
((!GCCInstallation.isValid() || !V.isOlderThan(4, 7, 0)) ||
 getTriple().isAndroid())) ||


Index: cfe/trunk/test/Driver/constructors.c
===
--- cfe/trunk/test/Driver/constructors.c
+++ cfe/trunk/test/Driver/constructors.c
@@ -80,6 +80,14 @@
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target arm64-none-none-eabi \
 // RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd11 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-INIT-ARRAY %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
+// RUN: -target i386-unknown-freebsd12 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
 //
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
 // RUN: -target sparc-sun-solaris2.11 \
Index: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
@@ -2543,6 +2543,8 @@
   bool UseInitArrayDefault =
   getTriple().getArch() == llvm::Triple::aarch64 ||
   getTriple().getArch() == llvm::Triple::aarch64_be ||
+  (getTriple().getOS() == llvm::Triple::FreeBSD &&
+   getTriple().getOSMajorVersion() >= 12) ||
   (getTriple().getOS() == llvm::Triple::Linux &&
((!GCCInstallation.isValid() || !V.isOlderThan(4, 7, 0)) ||
 getTriple().isAndroid())) ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47987: Provide only one declaration of __throw_runtime_error

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: hiraditya, mclow.lists, EricWF.
Herald added subscribers: christof, krytarowski, emaste.

In https://reviews.llvm.org/rL279903, @hiraditya added a second declaration of
`__throw_runtime_error` to `include/__locale`.  The original declaration
was in `__locale` too, but @mclow.lists moved it from there to
`stdexcept`.

In FreeBSD we compile most things with gcc's -Wredundant-decls, which
warns about such redundant redeclations, so I would like to remove the
one in `stdexcept`, as all the other callers of the function already
include `__locale` anyway.

While here, move the declaration in `__locale` to just above its first
invocation.


Repository:
  rCXX libc++

https://reviews.llvm.org/D47987

Files:
  include/__locale
  include/stdexcept


Index: include/stdexcept
===
--- include/stdexcept
+++ include/stdexcept
@@ -182,9 +182,6 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// in the dylib
-_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
-
 _LIBCPP_NORETURN inline _LIBCPP_ALWAYS_INLINE
 void __throw_logic_error(const char*__msg)
 {
Index: include/__locale
===
--- include/__locale
+++ include/__locale
@@ -201,6 +201,8 @@
 friend class locale::__imp;
 };
 
+_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 locale::locale(const locale& __other, _Facet* __f)
@@ -1229,8 +1231,6 @@
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS 
codecvt_byname)
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS 
codecvt_byname)
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS 
codecvt_byname)
-
-_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
 
 template 
 struct __narrow_to_utf8


Index: include/stdexcept
===
--- include/stdexcept
+++ include/stdexcept
@@ -182,9 +182,6 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// in the dylib
-_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
-
 _LIBCPP_NORETURN inline _LIBCPP_ALWAYS_INLINE
 void __throw_logic_error(const char*__msg)
 {
Index: include/__locale
===
--- include/__locale
+++ include/__locale
@@ -201,6 +201,8 @@
 friend class locale::__imp;
 };
 
+_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 locale::locale(const locale& __other, _Facet* __f)
@@ -1229,8 +1231,6 @@
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS codecvt_byname)
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS codecvt_byname)
 _LIBCPP_EXTERN_TEMPLATE2(class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS codecvt_byname)
-
-_LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
 
 template 
 struct __narrow_to_utf8
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D24867: Request init/fini array on FreeBSD 12 and later

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Brooks, I can commit this if you prefer.  Maybe it can go into 6.0.2 still...


https://reviews.llvm.org/D24867



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

[PATCH] D45406: Document -std= values for different languages

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL329827: Document -std= values for different languages 
(authored by dim, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D45406?vs=141529=142042#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D45406

Files:
  cfe/trunk/docs/CommandGuide/clang.rst

Index: cfe/trunk/docs/CommandGuide/clang.rst
===
--- cfe/trunk/docs/CommandGuide/clang.rst
+++ cfe/trunk/docs/CommandGuide/clang.rst
@@ -98,10 +98,129 @@
 
  Treat subsequent input files as having type language.
 
-.. option:: -std=
+.. option:: -std=
 
  Specify the language standard to compile for.
 
+ Supported values for the C language are:
+
+  | ``c89``
+  | ``c90``
+  | ``iso9899:1990``
+
+   ISO C 1990
+
+  | ``iso9899:199409``
+
+   ISO C 1990 with amendment 1
+
+  | ``gnu89``
+  | ``gnu90``
+
+   ISO C 1990 with GNU extensions
+
+  | ``c99``
+  | ``iso9899:1999``
+
+   ISO C 1999
+
+  | ``gnu99``
+
+   ISO C 1999 with GNU extensions
+
+  | ``c11``
+  | ``iso9899:2011``
+
+   ISO C 2011
+
+  | ``gnu11``
+
+   ISO C 2011 with GNU extensions
+
+  | ``c17``
+  | ``iso9899:2017``
+
+   ISO C 2017
+
+  | ``gnu17``
+
+   ISO C 2017 with GNU extensions
+
+ The default C language standard is ``gnu11``, except on PS4, where it is
+ ``gnu99``.
+
+ Supported values for the C++ language are:
+
+  | ``c++98``
+  | ``c++03``
+
+   ISO C++ 1998 with amendments
+
+  | ``gnu++98``
+  | ``gnu++03``
+
+   ISO C++ 1998 with amendments and GNU extensions
+
+  | ``c++11``
+
+   ISO C++ 2011 with amendments
+
+  | ``gnu++11``
+
+ISO C++ 2011 with amendments and GNU extensions
+
+  | ``c++14``
+
+   ISO C++ 2014 with amendments
+
+  | ``gnu++14``
+
+   ISO C++ 2014 with amendments and GNU extensions
+
+  | ``c++17``
+
+   ISO C++ 2017 with amendments
+
+  | ``gnu++17``
+
+   ISO C++ 2017 with amendments and GNU extensions
+
+  | ``c++2a``
+
+   Working draft for ISO C++ 2020
+
+  | ``gnu++2a``
+
+   Working draft for ISO C++ 2020 with GNU extensions
+
+ The default C++ language standard is ``gnu++14``.
+
+ Supported values for the OpenCL language are:
+
+  | ``cl1.0``
+
+   OpenCL 1.0
+
+  | ``cl1.1``
+
+   OpenCL 1.1
+
+  | ``cl1.2``
+
+   OpenCL 1.2
+
+  | ``cl2.0``
+
+   OpenCL 2.0
+
+ The default OpenCL language standard is ``cl1.0``.
+
+ Supported values for the CUDA language are:
+
+  | ``cuda``
+
+   NVIDIA CUDA(tm)
+
 .. option:: -stdlib=
 
  Specify the C++ standard library to use; supported options are libstdc++ and
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45406: Document -std= values for different languages

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Ping


Repository:
  rC Clang

https://reviews.llvm.org/D45406



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