[PATCH] D51204: [COFF, ARM64] Add MS intrinsics: __getReg, _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D51204#1271564 , @dmajor wrote:

> In D51204#1253230 , @mgrang wrote:
>
> > Will abandon this patch since I have implementations of these which I will 
> > upstream soon.
>
>
> Just to link up the reviews: these landed in D52838 
>  and D53115 
> . (Thanks @mgrang!)


Except not really...  D53115  got the types 
wrong, and used int instead of __int64.


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

https://reviews.llvm.org/D51204



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

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium created this revision.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

r344765 added those intrinsics, but used the wrong types.

I /think/ the code in EmitAArch64BuiltinExpr does the right thing, though, but 
I'm not familiar with it.

This affects the release_80 branch.


Repository:
  rC Clang

https://reviews.llvm.org/D57636

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/Headers/intrin.h


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -564,8 +564,8 @@
 #if defined(__aarch64__)
 unsigned __int64 __getReg(int);
 long _InterlockedAdd(long volatile *Addend, long Value);
-int _ReadStatusReg(int);
-void _WriteStatusReg(int, int);
+__int64 _ReadStatusReg(int);
+void _WriteStatusReg(int, __int64);
 
 static inline unsigned short _byteswap_ushort (unsigned short val) {
   return __builtin_bswap16(val);
Index: include/clang/Basic/BuiltinsAArch64.def
===
--- include/clang/Basic/BuiltinsAArch64.def
+++ include/clang/Basic/BuiltinsAArch64.def
@@ -204,8 +204,8 @@
 
 TARGET_HEADER_BUILTIN(_ReadWriteBarrier, "v", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(__getReg, "ULLii", "nh", "intrin.h", ALL_MS_LANGUAGES, 
"")
-TARGET_HEADER_BUILTIN(_ReadStatusReg,  "ii",  "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_WriteStatusReg, "vii", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_ReadStatusReg,  "LLii",  "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_WriteStatusReg, "viLLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_AddressOfReturnAddress, "v*", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 
 #undef BUILTIN


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -564,8 +564,8 @@
 #if defined(__aarch64__)
 unsigned __int64 __getReg(int);
 long _InterlockedAdd(long volatile *Addend, long Value);
-int _ReadStatusReg(int);
-void _WriteStatusReg(int, int);
+__int64 _ReadStatusReg(int);
+void _WriteStatusReg(int, __int64);
 
 static inline unsigned short _byteswap_ushort (unsigned short val) {
   return __builtin_bswap16(val);
Index: include/clang/Basic/BuiltinsAArch64.def
===
--- include/clang/Basic/BuiltinsAArch64.def
+++ include/clang/Basic/BuiltinsAArch64.def
@@ -204,8 +204,8 @@
 
 TARGET_HEADER_BUILTIN(_ReadWriteBarrier, "v", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(__getReg, "ULLii", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_ReadStatusReg,  "ii",  "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_WriteStatusReg, "vii", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_ReadStatusReg,  "LLii",  "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_WriteStatusReg, "viLLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_AddressOfReturnAddress, "v*", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 
 #undef BUILTIN
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D51204: [COFF, ARM64] Add MS intrinsics: __getReg, _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Opened D57636 


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

https://reviews.llvm.org/D51204



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

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D57636#1383566 , @efriedma wrote:

> (It should be possible to check that we aren't inserting incorrect 
> truncation/extension operations in the IR.)


I don't know how to do that.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57636



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

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium updated this revision to Diff 185218.
glandium edited the summary of this revision.
glandium added a comment.

Updated EmitAArch64BuiltinExpr per https://reviews.llvm.org/D57636#1383751 and 
the testcase per https://reviews.llvm.org/D57636#1384348


Repository:
  rC Clang

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

https://reviews.llvm.org/D57636

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/CodeGen/CGBuiltin.cpp
  lib/Headers/intrin.h
  test/CodeGen/arm64-microsoft-status-reg.cpp

Index: test/CodeGen/arm64-microsoft-status-reg.cpp
===
--- test/CodeGen/arm64-microsoft-status-reg.cpp
+++ test/CodeGen/arm64-microsoft-status-reg.cpp
@@ -23,87 +23,101 @@
 #define ARM64_TPIDRRO_EL0   ARM64_SYSREG(3,3,13, 0,3)  // Thread ID Register, User Read Only [CP15_TPIDRURO]
 #define ARM64_TPIDR_EL1 ARM64_SYSREG(3,0,13, 0,4)  // Thread ID Register, Privileged Only [CP15_TPIDRPRW]
 
-void check_ReadWriteStatusReg(int v) {
-  int ret;
+// From intrin.h
+__int64 _ReadStatusReg(int);
+void _WriteStatusReg(int, __int64);
+
+void check_ReadWriteStatusReg(__int64 v) {
+  __int64 ret;
   ret = _ReadStatusReg(ARM64_CNTVCT);
-// CHECK-ASM: mrs x8, CNTVCT_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD2:.*]])
+// CHECK-ASM: mrs x0, CNTVCT_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD2:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMCCNTR_EL0);
-// CHECK-ASM: mrs x8, PMCCNTR_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD3:.*]])
+// CHECK-ASM: mrs x0, PMCCNTR_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD3:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMSELR_EL0);
-// CHECK-ASM: mrs x8, PMSELR_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD4:.*]])
+// CHECK-ASM: mrs x0, PMSELR_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD4:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMXEVCNTR_EL0);
-// CHECK-ASM: mrs x8, PMXEVCNTR_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD5:.*]])
+// CHECK-ASM: mrs x0, PMXEVCNTR_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD5:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(0));
-// CHECK-ASM: mrs x8, PMEVCNTR0_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD6:.*]])
+// CHECK-ASM: mrs x0, PMEVCNTR0_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD6:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(1));
-// CHECK-ASM: mrs x8, PMEVCNTR1_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD7:.*]])
+// CHECK-ASM: mrs x0, PMEVCNTR1_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD7:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_PMXEVCNTRn_EL0(30));
-// CHECK-ASM: mrs x8, PMEVCNTR30_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD8:.*]])
+// CHECK-ASM: mrs x0, PMEVCNTR30_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD8:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_TPIDR_EL0);
-// CHECK-ASM: mrs x8, TPIDR_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD9:.*]])
+// CHECK-ASM: mrs x0, TPIDR_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD9:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_TPIDRRO_EL0);
-// CHECK-ASM: mrs x8, TPIDRRO_EL0
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD10:.*]])
+// CHECK-ASM: mrs x0, TPIDRRO_EL0
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD10:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
   ret = _ReadStatusReg(ARM64_TPIDR_EL1);
-// CHECK-ASM: mrs x8, TPIDR_EL1
-// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD11:.*]])
+// CHECK-ASM: mrs x0, TPIDR_EL1
+// CHECK-IR: %[[VAR:.*]] = call i64 @llvm.read_register.i64(metadata ![[MD11:.*]])
+// CHECK-IR-NEXT: store i64 %[[VAR]]
 
 
   _WriteStatusReg(ARM64_CNTVCT, v);
-// CHECK-ASM: msr S3_3_C14_C0_2, x8
+// CHECK-ASM: msr S3_3_C14_C0_2, x0
 // CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD2:.*]], i64 {{%.*}})
 
   _WriteStatusReg(ARM64_PMCCNTR_EL0, v);
-// CHECK-ASM: msr PMCCNTR_EL0, x8
+// CHECK-ASM: msr PMCCNTR_EL0, x0
 // CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD3:.*]], i64 {{%.*}})
 
   _WriteStatusReg(ARM64_PMSELR_EL0, v);
-// CHECK-ASM: msr PMSELR_EL0, x8
+// CHECK-ASM: msr PMSELR_EL0, x0
 // CHECK-IR: call void @llvm.write_register.i64(metadata ![[MD4:.*]], i64 {{%.*}})
 
   _WriteStatusReg(ARM64_PM

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

@efriedma can you take another look? Ideally, this should be backported to the 
release_80 branch, so that would need to be landed asap.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57636



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

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D57636#1389971 , @efriedma wrote:

> LGTM. Do you want me to commit this for you?


Yes, please. Thank you.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57636



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

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Code built with older versions of LLVM (e.g. rust) and running with the updated 
runtime crash at startup with this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138846

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

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D138846#4656607 , @glandium wrote:

> Code built with older versions of LLVM (e.g. rust) and running with the 
> updated runtime crash at startup with this change.

FWIW, neither followups fixed this issue. The crash happens in 
__llvm_profile_instrument_target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138846

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

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

FWIW, it's the first time for as long as I remember that mixing LLVM versions 
causes a runtime crash (that looks like a null deref).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138846

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

[PATCH] D138846: MC/DC in LLVM Source-Based Code Coverage: LLVM back-end and compiler-rt

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

There is a check already, but it's not enough: 
https://github.com/llvm/llvm-project/issues/52683


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138846

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

[PATCH] D130689: [LLVM] Update C++ standard to 17

[Mike Hommey via Phabricator via cfe-commits]

glandium added inline comments.



Comment at: llvm/cmake/modules/CheckCompilerVersion.cmake:16
 # _MSC_VER == 1927 MSVC++ 14.27 Visual Studio 2019 Version 16.7
-set(MSVC_MIN 19.20)
+set(MSVC_MIN 19.27)
 set(MSVC_SOFT_ERROR 19.27)

You didn't update llvm/cmake/platforms/WinMsvc.cmake accordingly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[PATCH] D130689: [LLVM] Update C++ standard to 17

[Mike Hommey via Phabricator via cfe-commits]

glandium added inline comments.



Comment at: llvm/cmake/modules/CheckCompilerVersion.cmake:16
 # _MSC_VER == 1927 MSVC++ 14.27 Visual Studio 2019 Version 16.7
-set(MSVC_MIN 19.20)
+set(MSVC_MIN 19.27)
 set(MSVC_SOFT_ERROR 19.27)

thieta wrote:
> glandium wrote:
> > You didn't update llvm/cmake/platforms/WinMsvc.cmake accordingly
> AHA! That explains the fms-compatibility issue. Will you push a NFC commit or 
> do you want me to do that?
I don't have push access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This catches 
https://searchfox.org/mozilla-central/rev/c77834ec635c523f2ba0092fcd1728c9b1c3005b/third_party/rust/glslopt/glsl-optimizer/src/compiler/glsl/ir_reader.cpp#732
 but not 
https://searchfox.org/mozilla-central/rev/c77834ec635c523f2ba0092fcd1728c9b1c3005b/third_party/rust/glslopt/glsl-optimizer/src/compiler/glsl/ir.cpp#654.
 Is that expected?


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

https://reviews.llvm.org/D130058

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

[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D130058#3714672 , @glandium wrote:

> This catches 
> https://searchfox.org/mozilla-central/rev/c77834ec635c523f2ba0092fcd1728c9b1c3005b/third_party/rust/glslopt/glsl-optimizer/src/compiler/glsl/ir_reader.cpp#732
>  but not 
> https://searchfox.org/mozilla-central/rev/c77834ec635c523f2ba0092fcd1728c9b1c3005b/third_party/rust/glslopt/glsl-optimizer/src/compiler/glsl/ir.cpp#654.
>  Is that expected?

Maybe something changed? A couple days ago it was catching 
https://searchfox.org/mozilla-central/rev/c77834ec635c523f2ba0092fcd1728c9b1c3005b/gfx/cairo/cairo/src/win32/cairo-dwrite-font.cpp#238
 but apparently not anymore.


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

https://reviews.llvm.org/D130058

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

[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Also not caught: a cast of 0 when 0 is not a valid value in the enum.


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

https://reviews.llvm.org/D130058

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

[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

Is it expected that `__FLT_EVAL_METHOD__` is not set at all anymore by default 
after this change?


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

https://reviews.llvm.org/D109239

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

[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D109239#3454084 , @zahiraam wrote:

> In D109239#3453770 , @glandium 
> wrote:
>
>> Is it expected that `__FLT_EVAL_METHOD__` is not set at all anymore by 
>> default after this change?
>
> @glandium would you mind giving a reproducer. We might have missed a flow 
> path where the macro is undefined.

`clang -dM -E - < /dev/null | grep __FLT_EVAL_METHOD__`


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

https://reviews.llvm.org/D109239

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

[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

The updates in `clang/test/Preprocessor` kind of suggest this was an expected 
change, though...


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

https://reviews.llvm.org/D109239

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

[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

From the commit message:

> This patch adds deprecation warnings for the usage of those builtins, except 
> for __has_trivial_destructor which doesn't have a GCC alternative.

This doesn't seem to be true, FWIW.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129170

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

[PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

FWIW, this change also broke this check in Firefox's clang plugin: 
https://searchfox.org/mozilla-central/rev/0d11f3660945ce35c49501bb44bc4f82bb2b503c/build/clang-plugin/NoPrincipalGetURI.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D112374#3651218 , @mizvekov wrote:

> Can you confirm that this `NoPrincipalGetURI` matcher would, in clang version 
> without this patch here, fail to match if you had rewritten the `GetUri` 
> method to use a qualified name?

I can confirm it's the case, and your fix works. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[PATCH] D95166: Disable rosegment for old Android versions.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

"Android only supports lld" might be true now, but it hasn't always been true, 
which means the change is not backwards compatible with versions of the NDK 
that don't use lld. Also, `-fuse-ld` is still a valid flag that can allow to 
use a different linker than lld.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95166

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

[PATCH] D95166: Disable rosegment for old Android versions.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Firefox CI is using a custom clang, but uses a NDK otherwise (an old-ish one, 
clearly older than r22 which is the first that defaults to lld). And we do pass 
-fuse-ld=bfd at the moment for $reasons.
If clang _really_ wants to assume lld as the linker for android, then it should 
make using -fuse-ld=somethingelse an error and invoke ld.lld rather than ld, if 
it doesn't already do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95166

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke determinism when building Firefox.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D106585#3122726 , @glandium wrote:

> It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8 
> .

Actually, there are some remaining cases not covered by that. I'm trying to 
produce a small reproducer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D106585#3125280 , @rnk wrote:

> In D106585#3122726 , @glandium 
> wrote:
>
>> It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8 
>> .
>
> Are you sure you've arrived at the right code review? This change, D106585 
> , modified type information, which is 
> unrelated to the change you linked to. We have also noticed *other* 
> determinism issues (follow up with @hans to learn more), but they aren't 
> related to this change, which is from July.

Yes, cherry-picking rG3c47c5ca13b8a502de3272e8105548715947b7a8 
, 
rGbadcd585897253e94b7b2d4e6f9f430a2020d642 
 and 
reverting the changes to clang/lib/CodeGen/CGDebugInfo.cpp from 
rG323049329939becf690adbeeff9f5f7e219075ec 
 and 
rGf9f56488e02d1c09a9cd4acde61ce1c712e71405 
 fixes the 
non-determinism in Firefox with clang 13.0.0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

So far, what I've found is that in some cases, DIEnumerator::get returns the 
same node for similar enumerator values in different enums that happen to have 
the same name and value (even if their bitwidth differs), but sometimes not.
For example, in one compilation I see:

  DIEnumerator::get (Name={Data@0x5575ee17ea38="nsNumberControlFrame_id", 
Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, 
BitWidth=8}, Context@0x5575e8305da0.pImpl=0x5575e8307230) = 0x55760563a708
  DIEnumerator::get (Name={Data@0x5575ee17ea38="nsNumberControlFrame_id", 
Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, 
BitWidth=32}, Context@0x5575e8305da0.pImpl=0x5575e8307230) = 0x5576067e7148

In another compilation of the same file with the same flags:

  DIEnumerator::get (Name={Data@0x561c659e0cc8="nsNumberControlFrame_id", 
Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, 
BitWidth=8}, Context@0x561c5fb68da0.pImpl=0x561c5fb6a230) = 0x561c7ce9dbf8
  DIEnumerator::get (Name={Data@0x561c659e0cc8="nsNumberControlFrame_id", 
Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, 
BitWidth=32}, Context@0x561c5fb68da0.pImpl=0x561c5fb6a230) = 0x561c7ce9dbf8


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D106585: Fix clang debug info irgen of i128 enums

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Reduced testcase:

  enum FrameIID {
nsBox_id,
nsIFrame_id,
nsHTMLFramesetBlankFrame_id,
nsHTMLFramesetBorderFrame_id,
  };
  
  enum class ClassID : unsigned char {
nsBox_id,
nsIFrame_id,
nsHTMLFramesetBlankFrame_id,
nsHTMLFramesetBorderFrame_id,
  };
  
  extern void foo(FrameIID, ClassID);
  
  void bar(FrameIID f, ClassID c) { foo(f, c); }

Compile with `clang++ -o test.ll -S -emit-llvm -g test.cpp` a number of times, 
and observe that sometimes the output is different. Add items to the enums to 
make it more frequent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This breaks compiling many things on macOS, including compiler-rt:

  /tmp/llvm2/obj/bin/clang++ --target=aarch64-apple-darwin  
-I/tmp/llvm2/compiler-rt/lib/fuzzer/../../include -Wall -Wno-unused-parameter 
-O3 -DNDEBUG -arch arm64 -isysroot /tmp/MacOSX11.3.sdk -stdlib=libc++ 
-mmacosx-version-min=10.10 -isysroot /tmp/MacOSX11.3.sdk -fPIC -fno-builtin 
-fno-exceptions -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack 
-fvisibility=hidden -fno-lto -Wthread-safety -Wthread-safety-reference 
-Wthread-safety-beta -O3 -g -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions 
-fno-omit-frame-pointer -std=c++17 -MD -MT 
lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o -MF 
lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o.d -o 
lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o -c 
/tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerFork.cpp
  In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerFork.cpp:11:
  In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerCommand.h:15:
  In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerDefs.h:18:
  In file included from /tmp/MacOSX11.3.sdk/usr/include/c++/v1/memory:667:
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:1672:66: error: 'type' is 
unavailable: introduced in macOS 10.15
  typedef _LIBCPP_NODEBUG_TYPE typename remove_reference<_Tp>::type _Up;
   ^
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:603:47: note: in 
instantiation of template class 'std::decay' requested 
here
  template ::type,
^
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:648:31: note: in 
instantiation of default argument for 
'__is_pathable_char_array' required here
bool _IsCharIterT = __is_pathable_char_array<_Tp>::value,
^
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:741:26: note: in 
instantiation of default argument for '__is_pathable' required here
typename enable_if<__is_pathable<_SourceOrIter>::value, _Tp>::type;
   ^~~~
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:861:29: note: in 
instantiation of template type alias '_EnableIfPathable' requested here
_LIBCPP_INLINE_VISIBILITY _EnableIfPathable<_Source>
  ^
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:965:19: note: while 
substituting deduced template arguments into function template 'operator/=' 
[with _Source = path]
  return (*this /= __replacement);
^
  /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:738:24: note: 'path' has 
been explicitly marked unavailable here
  class _LIBCPP_TYPE_VIS path {
 ^

etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

> In either case, this seems to be an issue with libc++ that is out there in 
> the wild.

I don't think it is, actually. I think it's doing something legitimate. That 
is, it's declaring in its headers that some things are only available on some 
versions of macos, which is fine if you don't use them, or if you use them in a 
block guarded with `__builtin_available`. The problem this patch introduces is 
that it makes it an error to even have those declarations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

(And specifically, FuzzerFork.cpp doesn't use any of those declared things. Its 
only sin is to `#include `, which happens to have /some/ methods 
(std::filesystem-related) only available on macos 10.15+.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D133874: [clang] Changes to produce sugared converted template arguments

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke building Firefox with:

  In file included from Unified_cpp_editor_txmgr0.cpp:2:
  In file included from /tmp/gecko/editor/txmgr/TransactionItem.cpp:6:
  In file included from /tmp/gecko/editor/txmgr/TransactionItem.h:9:
  In file included from 
/tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:31:
  In file included from 
/tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsUtils.h:16:
  /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:238:31: 
error: definition with same mangled name 
'_ZN27nsCycleCollectingAutoRefCnt4incrIXadL_Z25NS_CycleCollectorSuspect3mPvP28nsCycleCollectionParticipant'
 as another definition
MOZ_ALWAYS_INLINE uintptr_t incr(void* aOwner,
^
  /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:238:31: 
note: previous definition is here
  /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:266:31: 
error: definition with same mangled name 
'_ZN27nsCycleCollectingAutoRefCnt4decrIXadL_Z25NS_CycleCollectorSuspect3mPvP28nsCycleCollectionParticipantPb'
 as another definition
MOZ_ALWAYS_INLINE uintptr_t decr(void* aOwner,
^
  /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:266:31: 
note: previous definition is here
  2 errors generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133874

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

[PATCH] D136564: [clang] Instantiate NTTPs and template default arguments with sugar

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke building Firefox with:

  In file included from Unified_cpp_dom_canvas0.cpp:65:
  /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:355:19: error: call to deleted 
function 'IdByMethod'
const auto id = IdByMethod();
^~
  /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:438:3: note: in instantiation of 
function template specialization 'mozilla::ClientWebGLContext::Run' requested here
Run(xrFb ? xrFb->mId : 0, type, webvr, asyncOptions);
^
  /tmp/gecko/dom/canvas/WebGLMethodDispatcher.h:20:8: note: candidate function 
[with MethodT = void (mozilla::HostWebGLContext::*)(unsigned long, 
mozilla::layers::TextureType, bool, const mozilla::webgl::SwapChainOptions &) 
const, Method = &mozilla::HostWebGLContext::Present] has been explicitly deleted
  size_t IdByMethod() = delete;
 ^
  In file included from Unified_cpp_dom_canvas0.cpp:65:
  /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:355:19: error: call to deleted 
function 'IdByMethod'
const auto id = IdByMethod();
^~
  /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:447:3: note: in instantiation of 
function template specialization 'mozilla::ClientWebGLContext::Run' requested 
here
Run(fb ? fb->mId : 0, texType, asyncOptions);
^
  /tmp/gecko/dom/canvas/WebGLMethodDispatcher.h:20:8: note: candidate function 
[with MethodT = void (mozilla::HostWebGLContext::*)(unsigned long, 
mozilla::layers::TextureType, const mozilla::webgl::SwapChainOptions &) const, 
Method = &mozilla::HostWebGLContext::CopyToSwapChain] has been explicitly 
deleted
  size_t IdByMethod() = delete;
 ^

(etc.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136564

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

[PATCH] D133874: [clang] Changes to produce sugared converted template arguments

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

I'm running it through creduce (as well as the one for D136564 
. It's going to take a little while. Thank 
you for the revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133874

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

[PATCH] D133874: [clang] Changes to produce sugared converted template arguments

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Reduced testcase:
cc1 command line: `clang-16 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -o 
Unified_cpp_editor_txmgr0.o -x c++-cpp-output Unified_cpp_editor_txmgr0.ii`
source file content:

  class nsCycleCollectionParticipant;
  class nsCycleCollectingAutoRefCnt;
  extern "C" void NS_CycleCollectorSuspect3(void *,
nsCycleCollectionParticipant *,
nsCycleCollectingAutoRefCnt *,
bool *);
  class nsCycleCollectingAutoRefCnt {
  public:
typedef void Suspect(void *, nsCycleCollectionParticipant *,
 nsCycleCollectingAutoRefCnt *, bool *);
template 
void incr(int *aOwner) {
  incr(aOwner, nullptr);
}
template 
unsigned long incr(void *, nsCycleCollectionParticipant *) {}
  };
  class TransactionItem {
int Release();
nsCycleCollectingAutoRefCnt mRefCnt;
  };
  int TransactionItem::Release() {
mRefCnt.incr(this, 0);
mRefCnt.incr(0);
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133874

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

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D136533#3885302 , @mizvekov wrote:

> Nonetheless, it seems libc++ uses a deprecated declaration from it's own 
> headers.

It's the opposite of deprecated, it's (optionally) using something that is only 
available in newer versions of macos.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D133874: [clang] Changes to produce sugared converted template arguments

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

I can confirm that applying the following:

  diff --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
  index a8585a6d84ad..f07c40cb6c5d 100644
  --- a/clang/lib/AST/ASTContext.cpp
  +++ b/clang/lib/AST/ASTContext.cpp
  @@ -6774,7 +6774,7 @@ ASTContext::getCanonicalTemplateArgument(const 
TemplateArgument &Arg) const {
   
   case TemplateArgument::Declaration: {
 auto *D = cast(Arg.getAsDecl()->getCanonicalDecl());
  -  return TemplateArgument(D, Arg.getParamTypeForDecl());
  +  return TemplateArgument(D, 
getCanonicalType(Arg.getParamTypeForDecl()));
   }
   
   case TemplateArgument::NullPtr:
  diff --git a/clang/lib/AST/TemplateBase.cpp b/clang/lib/AST/TemplateBase.cpp
  index 6d9ab2b8ca71..579684c94f80 100644
  --- a/clang/lib/AST/TemplateBase.cpp
  +++ b/clang/lib/AST/TemplateBase.cpp
  @@ -363,7 +363,8 @@ bool TemplateArgument::structurallyEquals(const 
TemplateArgument &Other) const {
  TemplateArg.NumExpansions == Other.TemplateArg.NumExpansions;
   
 case Declaration:
  -return getAsDecl() == Other.getAsDecl();
  +return getAsDecl() == Other.getAsDecl() &&
  +   getParamTypeForDecl() == Other.getParamTypeForDecl();
   
 case Integral:
   return getIntegralType() == Other.getIntegralType() &&

on top of the commit right before your reverts, fixes both the issue I reported 
here as well as the one in D136564 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133874

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

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

> you're using the SDK libc++ with a ToT clang, which is technically not a 
> supported combination.

Where is it specified that it's not a supported combination? Why should it not 
be supported? You don't even get libc++ from the llvm tree unless you 
explicitly enable it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D130058: [Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Having looked around in the Firefox codebase for cases that now fail to build 
because of this, and looking at the clarification in DR2338, I wonder if enums 
in `extern "C"` sections should be treated as if they had an explicit type of 
`int` as if it were e.g. `enum Foo: int { ... }`.


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

https://reviews.llvm.org/D130058

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

[PATCH] D131714: [compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

FWIW, it also broke compiler-rt standalone builds:

  CMake Error at lib/builtins/CMakeLists.txt:702 (add_security_warnings):
Unknown CMake command "add_security_warnings".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131714

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This didn't change the default for msvc targets, was that expected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D131465#3812424 , @rnk wrote:

> I think both driver share the logic for MSVC version detection, which checks 
> for cl.exe on PATH and looks at the registry if that fails.
>
> I think we should try to lean towards making this policy easy to document and 
> communicate to users, and that means our rules need to be concise. I worry 
> that different defaults will surprise cross-platform projects ("hey, my code 
> built with on clang Linux, but not Windows with clang-cl, why is that, let's 
> debug..."). A simple rule like "clang 16.0 raised the default C++ standard 
> version to 17, except on PS4" seems preferable.

If it's based on installed MSVC version, there's even the risk of "clang-cl on 
windows doesn't behave the same whether MSVC is installed or not" or "clang-cl 
on windows doesn't behave the same when MSVC is not registered in the registry 
(e.g. a zip unpack)" or "clang-cl on Linux (cross-compile) doesn't behave the 
same as clang-cl on windows". None of which are desirable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke our mac builds with errors like:

  ld64.lld: error: undefined symbol: CFRunLoopRun
  >>> referenced by 
tools/clang/tools/clang-stat-cache/CMakeFiles/clang-stat-cache.dir/clang-stat-cache.cpp.o:(symbol
 main+0x11be)

(and many more symbols)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136651

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

[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D136651#4064260 , @glandium wrote:

> This broke our mac builds with errors like:
>
>   ld64.lld: error: undefined symbol: CFRunLoopRun
>   >>> referenced by 
> tools/clang/tools/clang-stat-cache/CMakeFiles/clang-stat-cache.dir/clang-stat-cache.cpp.o:(symbol
>  main+0x11be)
>
> (and many more symbols)

Additional information: those are cross-compiled, and for some reason the 
`-framework CoreServices` in the CMakeLists.txt doesn't seem to make it to the 
command line, which is surprising because something similar works fine for e.g. 
dsymutil.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136651

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

[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Oh yes, we're using `-DLLVM_LINK_LLVM_DYLIB=ON` too, so that would be the main 
trigger.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136651

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

[PATCH] D140875: [clangd] prototype: Implement unused include warnings with include-cleaner library.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

I'm still seeing the build error on clangd-fuzzer on a commit that clearly has 
e84d69f52d9a9fab9162128d8fe8ebec99ea60da 
 in its 
history.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140875

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

[PATCH] D140875: [clangd] prototype: Implement unused include warnings with include-cleaner library.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

with `-DLLVM_LINK_LLVM_DYLIB=ON`, in case it matters.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140875

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

[PATCH] D152604: [Driver] Default -fsanitize-address-globals-dead-stripping to true for ELF

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In the realm of unintended consequences, this broke ODR violation detection 
when linking a rust static library with asan enabled because, while 
__asan_globals_registered is COMDAT in clang, for some reason, it's not in 
rust... So you end up with two asan.module_ctor that call 
__asan_register_elf_globals, each with their own __asan_globals_registered, but 
both using the same range of globals, so all globals are registered twice. 
(That's probably a bug in the rust compiler. I thought I'd mention this here in 
case someone follows the same path as I did)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152604

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

[PATCH] D145302: [clangd] Add library for clangd main function

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke building with `-DLLVM_LINK_LLVM_DYLIB=ON`:

  /usr/bin/ld: 
tools/clang/tools/extra/clangd/refactor/tweaks/CMakeFiles/obj.clangDaemonTweaks.dir/AddUsing.cpp.o:
 in function `clang::clangd::(anonymous 
namespace)::AddUsing::prepare(clang::clangd::Tweak::Selection const&)':
  
AddUsing.cpp:(.text._ZN5clang6clangd12_GLOBAL__N_18AddUsing7prepareERKNS0_5Tweak9SelectionE+0x1c):
 undefined reference to `clang::clangd::ParsedAST::getASTContext()'
  /usr/bin/ld: 
AddUsing.cpp:(.text._ZN5clang6clangd12_GLOBAL__N_18AddUsing7prepareERKNS0_5Tweak9SelectionE+0x6d):
 undefined reference to `clang::clangd::ParsedAST::getASTContext() const'
  /usr/bin/ld: 
AddUsing.cpp:(.text._ZN5clang6clangd12_GLOBAL__N_18AddUsing7prepareERKNS0_5Tweak9SelectionE+0x9a):
 undefined reference to `clang::clangd::isHeaderFile(llvm::StringRef, 
std::optional)'
  /usr/bin/ld: 
AddUsing.cpp:(.text._ZN5clang6clangd12_GLOBAL__N_18AddUsing7prepareERKNS0_5Tweak9SelectionE+0xcc):
 undefined reference to `clang::clangd::SelectionTree::commonAncestor() const'
  /usr/bin/ld: 
AddUsing.cpp:(.text._ZN5clang6clangd12_GLOBAL__N_18AddUsing7prepareERKNS0_5Tweak9SelectionE+0x391):
 undefined reference to 
`clang::clangd::printNamespaceScope[abi:cxx11](clang::DeclContext const&)'

etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145302

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

[PATCH] D152604: [Driver] Default -fsanitize-address-globals-dead-stripping to true for ELF

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D152604#4494975 , @rnk wrote:

> It sounds like two users have hit this now: Chromium and Rust folks.

s/Rust/Firefox/. And it looks like we're hitting it for the same reason: 
linking a static rust (LTOed) library with C++ code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152604

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

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This conflicts with D146664 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158475

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

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D158475#4623842 , @smeenai wrote:

> In D158475#4623471 , @glandium 
> wrote:
>
>> This conflicts with D146664 
>
> It sounds like you want the same logic as D158476 
>  to apply to the stdlib search as well as 
> the runtimes search, right?

Sounds about right.

> I can make both be consistent.

That would be much appreciated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158475

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

[PATCH] D158475: [driver] Refactor getRuntimePaths. NFC

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D158475#4626636 , @smeenai wrote:

> I'm halfway through an implementation of this, but I just realized that on 
> Android, Clang never searches for C++ headers installed alongside the driver: 
> https://github.com/llvm/llvm-project/blob/7af0eff5405bb88dc96c0b19892da0fbb44db433/clang/lib/Driver/ToolChains/Gnu.cpp#L3116-L3118.
>  Are you using the C++ headers from the NDK but a library that you built 
> locally, or are you manually specifying the path to your C++ headers?

At the moment, we're only really using libunwind from the clang stdlib 
directory. So we don't really have the problem with headers. It will eventually 
be a problem when we get to use libc++, which we'll want at some point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158475

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

[PATCH] D159292: [driver] Conditionally include installed libc++ headers for Android

[Mike Hommey via Phabricator via cfe-commits]

glandium resigned from this revision.
glandium added a comment.

This + D159293  works great for me. Thanks a 
bunch. (I'm not a reviewer, though)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159292

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

[PATCH] D159293: [driver] Perform fallback target searches for stdlib

[Mike Hommey via Phabricator via cfe-commits]

glandium resigned from this revision.
glandium added a comment.

This replaces D146664  quite nicely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159293

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

[PATCH] D146664: Apply the same fallbacks as runtimes search for stdlib search

[Mike Hommey via Phabricator via cfe-commits]

glandium abandoned this revision.
glandium added a comment.

Superseded by D159292  + D159293 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146664

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

[PATCH] D137217: [LTO][COFF] Use bitcode file names in lto native object file names.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This broke the gold plugin:

  [task 2022-11-22T21:03:29.486Z] 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1108:19: 
error: no matching function for call to 'localCache'
  [task 2022-11-22T21:03:29.486Z] Cache = check(localCache("ThinLTO", 
"Thin", options::cache_dir, AddBuffer));
  [task 2022-11-22T21:03:29.487Z]   ^~
  [task 2022-11-22T21:03:29.487Z] 
/builds/worker/fetches/llvm-project/llvm/include/llvm/Support/Caching.h:72:21: 
note: candidate function not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1102:20)' 
to 'llvm::AddBufferFn' (aka 'function)>') for 4th argument
  [task 2022-11-22T21:03:29.487Z] Expected localCache(
  [task 2022-11-22T21:03:29.488Z] ^
  [task 2022-11-22T21:03:29.488Z] 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1110:18: 
error: no viable conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'llvm::AddStreamFn' (aka 
'function> (unsigned int, const 
llvm::Twine &)>')
  [task 2022-11-22T21:03:29.488Z]   check(Lto->run(AddStream, Cache));
  [task 2022-11-22T21:03:29.488Z]  ^
  [task 2022-11-22T21:03:29.488Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:421:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument
  [task 2022-11-22T21:03:29.488Z]   function(nullptr_t) noexcept
  [task 2022-11-22T21:03:29.488Z]   ^
  [task 2022-11-22T21:03:29.489Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:432:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'const std::function>> (unsigned int, const llvm::Twine 
&)> &' for 1st argument
  [task 2022-11-22T21:03:29.489Z]   function(const function& __x);
  [task 2022-11-22T21:03:29.489Z]   ^
  [task 2022-11-22T21:03:29.489Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:441:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'std::function>> (unsigned int, const llvm::Twine 
&)> &&' for 1st argument
  [task 2022-11-22T21:03:29.489Z]   function(function&& __x) noexcept : 
_Function_base()
  [task 2022-11-22T21:03:29.489Z]   ^
  [task 2022-11-22T21:03:29.489Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:465:2:
 note: candidate template ignored: substitution failure [with _Functor = 
(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), 
$1 = void]: no type named 'type' in 'std::result_of<(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) 
&(unsigned int, const llvm::Twine &)>'
  [task 2022-11-22T21:03:29.489Z] function(_Functor);
  [task 2022-11-22T21:03:29.489Z] ^
  [task 2022-11-22T21:03:29.489Z] 
/builds/worker/fetches/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: 
passing argument to parameter 'AddStream' here
  [task 2022-11-22T21:03:29.489Z]   Error run(AddStreamFn AddStream, FileCache 
Cache = nullptr);
  [task 2022-11-22T21:03:29.489Z] ^
  [task 2022-11-22T21:03:29.489Z] 2 errors generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137217

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

[PATCH] D137217: [LTO][COFF] Use bitcode file names in lto native object file names.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Still broken:

  task 2022-11-22T22:09:00.912Z] /usr/lib/llvm-11/bin/clang++ 
--sysroot=/builds/worker/fetches/sysroot -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/gold -I/builds/worker/fetches/llvm-project/llvm/tools/gold -Iinclude 
-I/builds/worker/fetches/llvm-project/llvm/include -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -O3 -DNDEBUG -fPIC  -fno-exceptions 
-fno-rtti -std=c++17 -MD -MT 
tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o -MF 
tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o.d -o 
tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o -c 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp
  [task 2022-11-22T22:09:00.912Z] 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp::18: 
error: no viable conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'llvm::AddStreamFn' (aka 
'function> (unsigned int, const 
llvm::Twine &)>')
  [task 2022-11-22T22:09:00.912Z]   check(Lto->run(AddStream, Cache));
  [task 2022-11-22T22:09:00.912Z]  ^
  [task 2022-11-22T22:09:00.912Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:421:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument
  [task 2022-11-22T22:09:00.912Z]   function(nullptr_t) noexcept
  [task 2022-11-22T22:09:00.912Z]   ^
  [task 2022-11-22T22:09:00.912Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:432:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'const std::function>> (unsigned int, const llvm::Twine 
&)> &' for 1st argument
  [task 2022-11-22T22:09:00.912Z]   function(const function& __x);
  [task 2022-11-22T22:09:00.912Z]   ^
  [task 2022-11-22T22:09:00.912Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:441:7:
 note: candidate constructor not viable: no known conversion from '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' 
to 'std::function>> (unsigned int, const llvm::Twine 
&)> &&' for 1st argument
  [task 2022-11-22T22:09:00.912Z]   function(function&& __x) noexcept : 
_Function_base()
  [task 2022-11-22T22:09:00.913Z]   ^
  [task 2022-11-22T22:09:00.913Z] 
/builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:465:2:
 note: candidate template ignored: substitution failure [with _Functor = 
(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), 
$1 = void]: no type named 'type' in 'std::result_of<(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) 
&(unsigned int, const llvm::Twine &)>'
  [task 2022-11-22T22:09:00.913Z] function(_Functor);
  [task 2022-11-22T22:09:00.913Z] ^
  [task 2022-11-22T22:09:00.913Z] 
/builds/worker/fetches/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: 
passing argument to parameter 'AddStream' here
  [task 2022-11-22T22:09:00.913Z]   Error run(AddStreamFn AddStream, FileCache 
Cache = nullptr);
  [task 2022-11-22T22:09:00.913Z] ^
  [task 2022-11-22T22:09:00.913Z] 1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137217

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

[PATCH] D137217: [LTO][COFF] Use bitcode file names in lto native object file names.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Almost there, but not quite:

  [task 2022-11-22T23:55:36.341Z] 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1106:6: 
error: no matching function for call to object of type '(lambda at 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1095:7)'
  [task 2022-11-22T23:55:36.341Z] *AddStream(Task)->OS << MB->getBuffer();
  [task 2022-11-22T23:55:36.341Z]  ^
  [task 2022-11-22T23:55:36.341Z] 
/builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1095:7: 
note: candidate function not viable: requires 2 arguments, but 1 was provided
  [task 2022-11-22T23:55:36.341Z]   [&](size_t Task,
  [task 2022-11-22T23:55:36.341Z]   ^
  [task 2022-11-22T23:55:36.341Z] 1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137217

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

[PATCH] D39717: Always use prctl(PR_SET_PTRACER)

[Mike Hommey via Phabricator via cfe-commits]

glandium created this revision.
Herald added a subscriber: kubamracek.

Sufficiently old Linux kernel headers don't provide the PR_SET_PTRACER, but we 
can still call prctl with it if the runtime kernel is newer. Even if it's not, 
prctl will only return EINVAL.


https://reviews.llvm.org/D39717

Files:
  lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc


Index: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
===
--- lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+++ lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
@@ -57,6 +57,13 @@
 #include "sanitizer_mutex.h"
 #include "sanitizer_placement_new.h"
 
+// Sufficiently old kernel header don't provide this value, but we can still
+// call prctl with it if the runtime kernel is newer. Even if it's not, prctl
+// will only return EINVAL.
+#ifndef PR_SET_PTRACER
+#define PR_SET_PTRACER 0x59616d61
+#endif
+
 // This module works by spawning a Linux task which then attaches to every
 // thread in the caller process with ptrace. This suspends the threads, and
 // PTRACE_GETREGS can then be used to obtain their register state. The callback
@@ -433,9 +440,7 @@
 ScopedSetTracerPID scoped_set_tracer_pid(tracer_pid);
 // On some systems we have to explicitly declare that we want to be traced
 // by the tracer thread.
-#ifdef PR_SET_PTRACER
 internal_prctl(PR_SET_PTRACER, tracer_pid, 0, 0, 0);
-#endif
 // Allow the tracer thread to start.
 tracer_thread_argument.mutex.Unlock();
 // NOTE: errno is shared between this thread and the tracer thread.


Index: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
===
--- lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+++ lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
@@ -57,6 +57,13 @@
 #include "sanitizer_mutex.h"
 #include "sanitizer_placement_new.h"
 
+// Sufficiently old kernel header don't provide this value, but we can still
+// call prctl with it if the runtime kernel is newer. Even if it's not, prctl
+// will only return EINVAL.
+#ifndef PR_SET_PTRACER
+#define PR_SET_PTRACER 0x59616d61
+#endif
+
 // This module works by spawning a Linux task which then attaches to every
 // thread in the caller process with ptrace. This suspends the threads, and
 // PTRACE_GETREGS can then be used to obtain their register state. The callback
@@ -433,9 +440,7 @@
 ScopedSetTracerPID scoped_set_tracer_pid(tracer_pid);
 // On some systems we have to explicitly declare that we want to be traced
 // by the tracer thread.
-#ifdef PR_SET_PTRACER
 internal_prctl(PR_SET_PTRACER, tracer_pid, 0, 0, 0);
-#endif
 // Allow the tracer thread to start.
 tracer_thread_argument.mutex.Unlock();
 // NOTE: errno is shared between this thread and the tracer thread.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39717: Always use prctl(PR_SET_PTRACER)

[Mike Hommey via Phabricator via cfe-commits]

glandium updated this revision to Diff 121983.
glandium added a comment.

Updated wording.


https://reviews.llvm.org/D39717

Files:
  lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc


Index: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
===
--- lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+++ lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
@@ -57,6 +57,14 @@
 #include "sanitizer_mutex.h"
 #include "sanitizer_placement_new.h"
 
+// Sufficiently old kernel headers don't provide this value, but we can still
+// call prctl with it. If the runtime kernel is new enough, the prctl call will
+// have the desired effect; if the kernel is too old, the call will error and 
we
+// can ignore said error.
+#ifndef PR_SET_PTRACER
+#define PR_SET_PTRACER 0x59616d61
+#endif
+
 // This module works by spawning a Linux task which then attaches to every
 // thread in the caller process with ptrace. This suspends the threads, and
 // PTRACE_GETREGS can then be used to obtain their register state. The callback
@@ -433,9 +441,7 @@
 ScopedSetTracerPID scoped_set_tracer_pid(tracer_pid);
 // On some systems we have to explicitly declare that we want to be traced
 // by the tracer thread.
-#ifdef PR_SET_PTRACER
 internal_prctl(PR_SET_PTRACER, tracer_pid, 0, 0, 0);
-#endif
 // Allow the tracer thread to start.
 tracer_thread_argument.mutex.Unlock();
 // NOTE: errno is shared between this thread and the tracer thread.


Index: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
===
--- lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
+++ lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc
@@ -57,6 +57,14 @@
 #include "sanitizer_mutex.h"
 #include "sanitizer_placement_new.h"
 
+// Sufficiently old kernel headers don't provide this value, but we can still
+// call prctl with it. If the runtime kernel is new enough, the prctl call will
+// have the desired effect; if the kernel is too old, the call will error and we
+// can ignore said error.
+#ifndef PR_SET_PTRACER
+#define PR_SET_PTRACER 0x59616d61
+#endif
+
 // This module works by spawning a Linux task which then attaches to every
 // thread in the caller process with ptrace. This suspends the threads, and
 // PTRACE_GETREGS can then be used to obtain their register state. The callback
@@ -433,9 +441,7 @@
 ScopedSetTracerPID scoped_set_tracer_pid(tracer_pid);
 // On some systems we have to explicitly declare that we want to be traced
 // by the tracer thread.
-#ifdef PR_SET_PTRACER
 internal_prctl(PR_SET_PTRACER, tracer_pid, 0, 0, 0);
-#endif
 // Allow the tracer thread to start.
 tracer_thread_argument.mutex.Unlock();
 // NOTE: errno is shared between this thread and the tracer thread.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146664: Apply the same fallbacks as runtimes search for stdlib search

[Mike Hommey via Phabricator via cfe-commits]

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

When building clang with e.g. LLVM_ENABLE_RUNTIMES=libcxx;libunwind,
those runtimes end up in the stdlib search directory, and when
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is set, that ends up in a
target-specific subdirectory. The stdlib search does handle the
situation, but when the target in question is Android, the same issues
as those that required fallbacks for runtimes search apply.

Traditionally, those libraries are shipped as part of the Android NDK,
but when one builds their own clang for Android, they may want to use
the runtimes from the same version rather than the ones from the NDK.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146664

Files:
  clang/lib/Driver/ToolChain.cpp


Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -569,15 +569,9 @@
   return Args.MakeArgString(getCompilerRT(Args, Component, Type));
 }
 
-ToolChain::path_list ToolChain::getRuntimePaths() const {
-  path_list Paths;
-  auto addPathForTriple = [this, &Paths](const llvm::Triple &Triple) {
-SmallString<128> P(D.ResourceDir);
-llvm::sys::path::append(P, "lib", Triple.str());
-Paths.push_back(std::string(P.str()));
-  };
-
-  addPathForTriple(getTriple());
+template 
+static void fillPaths(const ToolChain &TC, F addPathForTriple) {
+  addPathForTriple(TC.getTriple());
 
   // When building with per target runtime directories, various ways of naming
   // the Arm architecture may have been normalised to simply "arm".
@@ -594,30 +588,42 @@
   //
   // M profile Arm is bare metal and we know they will not be using the per
   // target runtime directory layout.
-  if (getTriple().getArch() == Triple::arm && !getTriple().isArmMClass()) {
-llvm::Triple ArmTriple = getTriple();
+  if (TC.getTriple().getArch() == Triple::arm &&
+  !TC.getTriple().isArmMClass()) {
+llvm::Triple ArmTriple = TC.getTriple();
 ArmTriple.setArch(Triple::arm);
 addPathForTriple(ArmTriple);
   }
 
   // Android targets may include an API level at the end. We still want to fall
   // back on a path without the API level.
-  if (getTriple().isAndroid() &&
-  getTriple().getEnvironmentName() != "android") {
-llvm::Triple TripleWithoutLevel = getTriple();
+  if (TC.getTriple().isAndroid() &&
+  TC.getTriple().getEnvironmentName() != "android") {
+llvm::Triple TripleWithoutLevel = TC.getTriple();
 TripleWithoutLevel.setEnvironmentName("android");
 addPathForTriple(TripleWithoutLevel);
   }
+}
 
+ToolChain::path_list ToolChain::getRuntimePaths() const {
+  path_list Paths;
+  auto addPathForTriple = [this, &Paths](const llvm::Triple &Triple) {
+SmallString<128> P(D.ResourceDir);
+llvm::sys::path::append(P, "lib", Triple.str());
+Paths.push_back(std::string(P.str()));
+  };
+  fillPaths(*this, addPathForTriple);
   return Paths;
 }
 
 ToolChain::path_list ToolChain::getStdlibPaths() const {
   path_list Paths;
-  SmallString<128> P(D.Dir);
-  llvm::sys::path::append(P, "..", "lib", getTripleString());
-  Paths.push_back(std::string(P.str()));
-
+  auto addPathForTriple = [this, &Paths](const llvm::Triple &Triple) {
+SmallString<128> P(D.Dir);
+llvm::sys::path::append(P, "..", "lib", Triple.str());
+Paths.push_back(std::string(P.str()));
+  };
+  fillPaths(*this, addPathForTriple);
   return Paths;
 }
 


Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -569,15 +569,9 @@
   return Args.MakeArgString(getCompilerRT(Args, Component, Type));
 }
 
-ToolChain::path_list ToolChain::getRuntimePaths() const {
-  path_list Paths;
-  auto addPathForTriple = [this, &Paths](const llvm::Triple &Triple) {
-SmallString<128> P(D.ResourceDir);
-llvm::sys::path::append(P, "lib", Triple.str());
-Paths.push_back(std::string(P.str()));
-  };
-
-  addPathForTriple(getTriple());
+template 
+static void fillPaths(const ToolChain &TC, F addPathForTriple) {
+  addPathForTriple(TC.getTriple());
 
   // When building with per target runtime directories, various ways of naming
   // the Arm architecture may have been normalised to simply "arm".
@@ -594,30 +588,42 @@
   //
   // M profile Arm is bare metal and we know they will not be using the per
   // target runtime directory layout.
-  if (getTriple().getArch() == Triple::arm && !getTriple().isArmMClass()) {
-llvm::Triple ArmTriple = getTriple();
+  if (TC.getTriple().getArch() == Triple::arm &&
+  !TC.getTriple().isArmMClass()) {
+llvm::Triple ArmTriple = TC.getTriple();
 ArmTriple.setArch(Triple::arm);
 addPathForTriple(ArmTriple);
   }
 

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D150646#4382763 , @aidengrossman 
wrote:

> Interesting. I would've thought `-fms-extensions` by itself would've declared 
> that macro (which is what I gathered reading what caused the MSVC compatible 
> builtins to get included in clang), but apparently not. For whatever reason, 
> `LangOpts.MicrosoftExt` only seems to be set to true if 
> `-fms-compaitilibty-version` (maybe on top of `-fms-compatibility`) are also 
> passed (not 100% on this though). I'll have to do some more digging soon.

Did you find something?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D151344: Reland "[CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

I haven't tested this patch, but it looks like it contains everything that 
unbreaks our builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151344

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

[PATCH] D150645: [Driver] Support multi /guard: options

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D150645#4351266 , @aeubanks wrote:

> this causes `./build/rel/bin/clang-cl /c /tmp/a.cc /Fo/tmp/a 
> /guard:cf,nochecks` to go from no warnings to
>
>   clang-cl: warning: argument unused during compilation: '/guard:cf,nochecks' 
> [-Wunused-command-line-argument]

This affects 16.0.4


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150645

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

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

There seem to still be two problems with this change, with mingw:

- with `-fms-extensions`:

  echo '#include "cpuid.h"' | ./clang/bin/clang++ 
--target=x86_64-w64-windows-gnu -xc++ - -fms-extensions
  In file included from :1:
  /tmp/clang/lib/clang/17/include/cpuid.h:334:22: error: definition of builtin 
function '__cpuidex'
  static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
   ^
  1 error generated.

- conflict with mingw headers without the extensions:

  $ echo '#include "intrin.h"' | ./clang/bin/x86_64-w64-mingw32-clang++ -xc++ -
  In file included from :1:
  In file included from /tmp/clang/lib/clang/17/include/intrin.h:12:
  In file included from 
/tmp/clang/bin/../x86_64-w64-mingw32/include/intrin.h:70:
  /tmp/clang/lib/clang/17/include/cpuid.h:334:22: error: static declaration of 
'__cpuidex' follows non-static declaration
  static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
   ^
  /tmp/clang/bin/../x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:2031:6: 
note: previous definition is here
  void __cpuidex(int CPUInfo[4], int function_id, int subfunction_id) {
   ^
  1 error generated.

Although, for the latter, this was "fixed" in 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/2b6c9247613aa830374e3686e09d3b8d582a92a6/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D148827: -fsanitize=function: support C

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This breaks sqlite:

  /builds/worker/checkouts/gecko/third_party/sqlite3/src/sqlite3.c:137791:5: 
runtime error: call to function sqlite3DeleteTable through pointer to incorrect 
function type 'void (*)(struct sqlite3 *, void *)'
  /builds/worker/checkouts/gecko/third_party/sqlite3/src/sqlite3.c:118360: 
note: sqlite3DeleteTable defined here

The function is declared as `void sqlite3DeleteTable(sqlite3 *db, Table 
*pTable)` so technically, it's not wrong, but is it really a problem that needs 
to be caught? (when the difference is between `type*` and `void*`)

This also breaks NSS:

  /builds/worker/checkouts/gecko/security/nss/lib/freebl/loader.c:95:12: 
runtime error: call to function BL_Init through pointer to incorrect function 
type 'enum _SECStatus (*)(void)'
  /builds/worker/checkouts/gecko/security/nss/lib/freebl/blinit.c:557: note: 
BL_Init defined here

Pointer type is:

  SECStatus (*p_BL_Init)(void);

and BL_Init is declared as:

  SECStatus BL_Init()

I guess it's tripping on the missing `void`... should that be an error?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148827

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

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D150646#4380058 , @mstorsjo wrote:

> Regarding "fixed" - do you see any better way of fixing it there? As it's a 
> static inline function, there's no simple way of knowing whether it was 
> already defined or not; I went with the same pattern used for the existing 
> version check for GCC.

I mean, it fixes the issue if you apply the patch or update mingw headers. 
Whether that should be required or not is a good question.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D146664: Apply the same fallbacks as runtimes search for stdlib search

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D146664#4352695 , @thakis wrote:

> Is it possible to test this?

I don't know how.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146664

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

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.
Herald added subscribers: bviyer, ekilmer, jplehr.

FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c 
 is 
causing problems on Windows compiler-rt for some reason I haven't identified 
yet (with cmake 3.25.1). Which suggests for a same version of cmake, this is 
actually altering its behavior, which I wouldn't have expected...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144509

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

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D144509#4347604 , @mstorsjo wrote:

> See D150688  - I believe that might fix the 
> issue you're seeing, as that one mentions compiler-rt.

Unfortunately, it doesn't.

FWIW, the errors looks like:

  lld-link: error: undefined symbol: __declspec(dllimport) _getpid
  >>> referenced by 
clang_rt.profile-i386.lib(InstrProfilingFile.c.obj):(_getCurFilename)
  >>> referenced by 
clang_rt.profile-i386.lib(InstrProfilingFile.c.obj):(_parseAndSetFilename)
  >>> referenced by oldnames.lib(getpid.obi)

etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144509

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

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

It's related, though, because now that I look at my build logs, the difference 
between when it works and when it doesn't is `/MT` vs `-MD` when compiler-rt is 
compiled. The main peculiarity on our end, though, is that the Windows 
compiler-rt is cross-compiled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144509

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

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

So the problem is that `CMakePolicy.cmake` is not included in 
`compiler-rt/CMakeLists.txt`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144509

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

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D144509#4349051 , @hans wrote:

> In D144509#4347562 , @glandium 
> wrote:
>
>> FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c 
>>  is 
>> causing problems on Windows compiler-rt for some reason I haven't identified 
>> yet (with cmake 3.25.1). Which suggests for a same version of cmake, this is 
>> actually altering its behavior, which I wouldn't have expected...
>
> It is indeed unfortunate that this seems to come with such a fundamental 
> behavior change. (we already have 
> https://github.com/llvm/llvm-project/issues/62719) Do you have a repro for 
> the issue you're seeing?

The Chromium issue that is discussed there is essentially the same thing I was 
seeing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144509

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

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This causes errors like:

  /builds/worker/fetches/clang/lib/clang/17/include/cpuid.h(331,22): error: 
definition of builtin function '__cpuidex'
   static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
^
   1 error generated.

when building Firefox.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

Repro:

  $ echo '#include "cpuid.h"' | ./clang/bin/clang-cl  -Tp -
  clang-cl: warning: unable to find a Visual Studio installation; try running 
Clang from a developer command prompt [-Wmsvc-not-found]
  In file included from :1:
  /tmp/ct/clang/lib/clang/17/include/cpuid.h(331,22): error: definition of 
builtin function '__cpuidex'
  static __inline void __cpuidex (int __cpu_info[4], int __leaf, int __subleaf)
   ^
  1 error generated.

(interestingly doesn't happen in C mode (with `-Tc` instead of `-Tp`))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This is at least one of the spots where it happens: 
https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/third_party/highway/hwy/targets.cc#42
 (HWY_COMPILER_MSVC is explicitly 0 with clang-cl per 
https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/third_party/highway/hwy/detect_compiler_arch.h#36-40)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150646

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

[PATCH] D148827: -fsanitize=function: support C

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D148827#4379764 , @MaskRay wrote:

> These cases are UB and should be caught. It's not an excuse that they use C.

Are they really though?

  struct A {
int a;
  };
  
  int foo(struct A *a) { return 42; }
  
  int bar(void *a) { return foo(a); }
  
  int main(void) {
struct A a;
bar(&a);
int (*qux)(void *) = (int (*)(void *))foo;
qux(&a); // If this is UB, why isn't the call to foo from bar?
return 0;
  }

Likewise for `int foo()` and `int bar(void)`/`int (*qux)(void)`.
Likewise for `struct A* foo(void)` and `void *bar(void)`/`void *(*qux)(void)` 
(surprisingly, clang doesn't emit this error for `struct A* foo()` and `void* 
bar()`/`void*(*qux)()`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148827

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

[PATCH] D148827: -fsanitize=function: support C

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

OTOH. 6.2.7.3:

> A composite type can be constructed from two types that are compatible; it is 
> a type that is compatible with both of the two types (...)

6.2.7.5:

> EXAMPLE Given the following two file scope declarations:
> int f(int (*)(), double (*)[3]);
> int f(int (*)(char *), double (*)[]);
> The resulting composite type for the function is:
> int f(int (*)(char *), double (*)[3]);

This suggests that `int(*)()` and `int(*)(char*)` are compatible.

6.2.7.2:

> All declarations that refer to the same object or function shall have 
> compatible type; otherwise, the behavior is undefined.

6.3.2.3.1:

> A pointer to void may be converted to or from a pointer to any object type. A 
> pointer to any object type may be converted to a pointer to void and back 
> again; the result shall compare equal to the original pointer.

These are either contradicting, making 6.3.2.3.1 UB, or void* is compatible 
with other pointer types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148827

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

[PATCH] D148827: -fsanitize=function: support C

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

In D148827#4422794 , @MaskRay wrote:

> 6.3.2.3.1 is about a pointer casting rule, which is different from type 
> compatibility.

Pointer _conversion_ rule. Specifically, these are implicit conversions that 
require no casting. That doesn't invalidate that the rule from 6.2.7.2 still 
applies, and I don't see how the conversions can be non-UB without the types 
being compatible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148827

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

[PATCH] D118211: Add missing namespace to PPCLinux.cpp

[Mike Hommey via Phabricator via cfe-commits]

glandium created this revision.
Herald added subscribers: shchenz, kbarton, nemanjai.
glandium requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes a build failure with MSVC introduced in
https://reviews.llvm.org/D112906


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D118211

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


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;


Index: clang/lib/Driver/ToolChains/PPCLinux.cpp
===
--- clang/lib/Driver/ToolChains/PPCLinux.cpp
+++ clang/lib/Driver/ToolChains/PPCLinux.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
+using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace llvm::opt;
 using namespace llvm::sys;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D117611: [Sema] Warn about printf %n on Android and Fuchsia

[Mike Hommey via Phabricator via cfe-commits]

glandium added a comment.

This doesn't leave much room to use `__attribute__((format(printf)))` on custom 
printf implementations that do support `%n` on Android does it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117611

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