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

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 li

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

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. Th

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

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.or

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

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 A

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

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 LA

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

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

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

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/D57

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

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 __

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

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

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

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/D1388

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

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

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

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/platfo

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

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: > >

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

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_

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

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 >

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

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

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

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 _

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

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?

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

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

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

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

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

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://rev

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

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?

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

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. Re

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

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 i

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

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

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

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.ll

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

glandium added a comment. In D106585#3122726 , @glandium wrote: > It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8 > . Actually, there are some remaining cases

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

glandium added a comment. In D106585#3125280 , @rnk wrote: > In D106585#3122726 , @glandium > wrote: > >> It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8 >>

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

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

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

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, nsHTMLFramesetBorderFr

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

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=l

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

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

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

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

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

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-

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

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(); ^~

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

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/ ht

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

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;

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

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 ver

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

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::g

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

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 i

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

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

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

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/D

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

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 ma

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

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

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

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

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

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

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

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 _

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

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 ACT

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

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

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

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 th

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

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::Selectio

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

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++ cod

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

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

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

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 lo

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

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-pr

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

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://re

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

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 _

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

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/D

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

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", "T

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

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-proje

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

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-plugi

[PATCH] D39717: Always use prctl(PR_SET_PTRACER)

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 F

[PATCH] D39717: Always use prctl(PR_SET_PTRACER)

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 =

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

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 runt

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

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 includ

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

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 _

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

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,nocheck

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

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:3

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

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_pa

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

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

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

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 _

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

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

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

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 l

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

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. Reposi

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

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 _

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

glandium added a comment. In D144509#4349051 , @hans wrote: > In D144509#4347562 , @glandium > wrote: > >> FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c >>

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

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 generate

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

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/cpu

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

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/2

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

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

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

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(i

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

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. T

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

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:

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

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.llv