[PATCH] D107893: [clang] [MinGW] Consider the per-target libc++ include directory too

mstorsjo created this revision. mstorsjo added reviewers: phosek, MaskRay. mstorsjo requested review of this revision. Herald added a project: clang. The existing logic for per-target libc++ include directories only seem to exist for the Gnu and Fuchsia drivers, added in ea12d779bc238c387511fe7462

[PATCH] D102693: Do not create LLVM IR `constant`s for objects with dynamic initialisation

mstorsjo added a comment. I ran into a regression caused by this change, see https://bugs.llvm.org/show_bug.cgi?id=51442. This breaks building Qt tests with LLVM 13. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102693/new/ https://reviews.llvm.o

[PATCH] D107893: [clang] [MinGW] Consider the per-target libc++ include directory too

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5ed9e5c2c0ee: [clang] [MinGW] Consider the per-target libc++ include directory too (authored by mstorsjo). Changed prior to commit: https://review

[PATCH] D107893: [clang] [MinGW] Consider the per-target libc++ include directory too

mstorsjo added a subscriber: tstellar. mstorsjo added a comment. In D107893#2943679 , @zero9178 wrote: > Any chance this patch could be backported onto the LLVM 13 branch? I have > been using a per target runtime builds for a few versions now but the >

[PATCH] D107893: [clang] [MinGW] Consider the per-target libc++ include directory too

mstorsjo added a comment. In D107893#2944193 , @mstorsjo wrote: > In D107893#2943679 , @zero9178 > wrote: > >> Any chance this patch could be backported onto the LLVM 13 branch? I have >> been using a per target

[PATCH] D106721: [AArch64] Implemnt MSVC __mulh and __umulh builtins and corresponding IR level intrinsics

mstorsjo updated this revision to Diff 366839. mstorsjo added a comment. Reimplemented the builtins by expanding to the corresponding i128 multiplication in IR, just like the corresponding existing `__mulh` and `__umulh` builtins on x86. Repository: rG LLVM Github Monorepo CHANGES SINCE LAS

[PATCH] D106721: [AArch64] Implemnt MSVC __mulh and __umulh builtins and corresponding IR level intrinsics

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGcc3affd8b020: [clang] [MSVC] Implement __mulh and __umulh builtins for aarch64 (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGE

[PATCH] D105148: [CMake] Don't use -Bsymbolic-functions for MinGW targets

mstorsjo created this revision. mstorsjo added reviewers: MaskRay, phosek. Herald added subscribers: fedor.sergeev, mgorny. mstorsjo requested review of this revision. Herald added projects: clang, LLVM. Herald added a subscriber: cfe-commits. This is an ELF specific option which isn't supported f

[PATCH] D105148: [CMake] Don't use -Bsymbolic-functions for MinGW targets

This revision was automatically updated to reflect the committed changes. Closed by commit rGbf6770f9bd60: [CMake] Don't use -Bsymbolic-functions for MinGW targets (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105148/new/ htt

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

mstorsjo added a comment. In D100756#3088035 , @nickdesaulniers wrote: > thanks for this patch @mstorsjo ! This is help AOSP LLVM move our windows > builds of LLVM away from MinGW to LLVM! > https://android-review.googlesource.com/c/toolchain/llvm_andr

[PATCH] D112387: [clang] [MinGW] Rename the 'Arch' member to 'SysrootName'. NFC.

mstorsjo added a comment. In D112387#3090707 , @MaskRay wrote: > How is this different from `clang::driver::Driver::SysRoot`? > > From `SysrootName + "/sys-root"` looks like the `sys-root` directory is the > sysroot? Perhaps there is a better way describ

[PATCH] D112387: [clang] [MinGW] Rename the 'Arch' member to 'SysrootName'. NFC.

mstorsjo updated this revision to Diff 382798. mstorsjo added a comment. Renamed the variable to `SubdirName`. Will push tomorrow. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112387/new/ https://reviews.llvm.org/D112387 Files: clang/lib/Driver

[PATCH] D111952: [clang] [MinGW] Guess the right ix86 arch name spelling as sysroot

mstorsjo updated this revision to Diff 382801. mstorsjo added a comment. Rebased after renaming `SysrootName` to `SubdirName`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111952/new/ https://reviews.llvm.org/D111952 Files: clang/lib/Driver/Dri

[PATCH] D112387: [clang] [MinGW] Rename the 'Arch' member to 'SysrootName'. NFC.

This revision was automatically updated to reflect the committed changes. Closed by commit rG897c86dec5af: [clang] [MinGW] Rename the 'Arch' member to 'SubdirName'. NFC. (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112387/new

[PATCH] D111952: [clang] [MinGW] Guess the right ix86 arch name spelling as sysroot

mstorsjo updated this revision to Diff 382946. mstorsjo marked an inline comment as done. mstorsjo added a comment. Fixed the naming of the new function, using `--target=` in the newly added test lines, fixed a case of missed clang-format. Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D111952: [clang] [MinGW] Guess the right ix86 arch name spelling as sysroot

mstorsjo added inline comments. Comment at: clang/lib/Driver/ToolChains/MinGW.h:63 + static void FixTripleArch(const Driver &D, llvm::Triple &Triple, +const llvm::opt::ArgList &Args); MaskRay wrote: > Use `functionName` for newer fu

[PATCH] D111952: [clang] [MinGW] Guess the right ix86 arch name spelling as sysroot

This revision was automatically updated to reflect the committed changes. Closed by commit rGd758069f5e0d: [clang] [MinGW] Guess the right ix86 arch name spelling as sysroot (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111952

[PATCH] D112289: Support: Use sys::path::is_style_{posix,windows}() in a few places

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, too. D112786 does a couple more things that do pretty much the same - I don't mind if you want to fold them into this, or keep it as-is, with the b

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

mstorsjo added a comment. I went ahead and reverted this, as it caused crashes when compiling a number of projects. The most reduced testcase is this: $ cat reduced.c void a(*); void a() {} $ clang -c reduced.c -O2 -g A full case (which reduces into this) is this, https://martin.st/te

[PATCH] D113254: [clang] Fix a misadjusted path style comparison in a unittest

mstorsjo created this revision. mstorsjo added a reviewer: dexonsmith. mstorsjo requested review of this revision. Herald added a project: clang. This was changed incorrectly by accident in 99023627010bbfefb71e25a2b4d056de1cbd354e

[PATCH] D113264: [clang] [DirectoryWatcher] Remove leading \\?\ from GetFinalPathNameByHandleW

mstorsjo created this revision. mstorsjo added a reviewer: aaron.ballman. mstorsjo requested review of this revision. Herald added a project: clang. This is needed for the paths to work when using forward slashes; this fixes the DirectoryWatcherTests unit tests. Also allocate missing space for th

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo created this revision. mstorsjo added reviewers: sammccall, aaron.ballman. Herald added subscribers: usaxena95, kadircet, arphaman. mstorsjo requested review of this revision. Herald added subscribers: MaskRay, ilya-biryukov. Herald added a project: clang-tools-extra. If running on Window

[PATCH] D113269: [clang-move] Fix unit tests with forward slash as separator on windows

mstorsjo created this revision. mstorsjo added reviewers: aaron.ballman, sammccall. mstorsjo requested review of this revision. Herald added a project: clang-tools-extra. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D113269 Files: clang-tools-extra/unittests/clang-move/ClangM

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added a subscriber: rnk. mstorsjo added a comment. FWIW, this change is not about mingw, it's about making the windows-with-forward-slashes configuration usable. The windows-with-forward-slashes configuration works just as fine in MSVC configurations, and that's where I've tested it. A

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added a comment. I forgot to add - I agree with the general sentiment though, that it’s not worth bending over backwards to make tests pass in a setup that’s known not to work in real use though. Then again, if someone were to want to actually step up to make it work in mingw setups,

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added a comment. Oh, I realized that issues relating to “mingw” probably are from msys (which often is used together, but is an entirely different thing) - yeah I can see that there’d be lots of unfixable issues with that, and I’m not signing up for looking into that… Msys is the unix

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added a comment. In D113268#3111798 , @sammccall wrote: > In D113268#3111709 , @mstorsjo > wrote: > >> FWIW, this change is not about mingw, it's about making the >> windows-with-forward-slashes configu

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added inline comments. Comment at: clang-tools-extra/clangd/tool/ClangdMain.cpp:546 fs::make_absolute(TestScheme::TestDir, Path); +path::native(Path); return std::string(Path); mstorsjo wrote: > sammccall wrote: > > This change is an exampl

[PATCH] D113269: [clang-move] Fix unit tests with forward slash as separator on windows

mstorsjo added inline comments. Comment at: clang-tools-extra/unittests/clang-move/ClangMoveTests.cpp:235 - // std::string IncludeArg = Twine("-I" + WorkingDir; + // std::string IncludeArg = Twine("-I" + Dir; tooling::runToolOnCodeWithArgs( aaron.ballman wro

[PATCH] D113264: [clang] [DirectoryWatcher] Remove leading \\?\ from GetFinalPathNameByHandleW

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG2ca6fc34fc08: [clang] [DirectoryWatcher] Remove leading \\?\ from GetFinalPathNameByHandleW (authored by mstorsjo). Changed prior to commit: https

[PATCH] D113269: [clang-move] Fix unit tests with forward slash as separator on windows

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG98f0bf74ca6d: [clang-move] Fix unit tests with forward slash as separator on windows (authored by mstorsjo). Changed prior to commit: https://revi

[PATCH] D96120: [scudo] Port scudo sanitizer to Windows

mstorsjo added a comment. In D96120#2590587 , @russell.gallop wrote: > Hi @mstorsjo. Thanks for the suggestions. I tried running up an mingw > environment with msys but had trouble getting it working (running into cmake > issues). Would you be able to h

[PATCH] D98022: [clang] Fix typos in the default logic for CLANG_DEFAULT_UNWINDLIB

mstorsjo created this revision. mstorsjo added reviewers: saugustine, MaskRay, phosek. Herald added a subscriber: mgorny. mstorsjo requested review of this revision. Herald added a project: clang. CLANG_DEFAULT_RTLIB had a typo, and libunwind isn't a valid option for it. This keeps the practical

[PATCH] D98023: [clang] Don't make the g++ driver imply an explicitly shared libunwind

mstorsjo created this revision. mstorsjo added reviewers: mati865, rnk, saugustine, phosek. mstorsjo requested review of this revision. Herald added a project: clang. The logic in getLibGccType, to have the g++ driver mode imply a shared libgcc, originally was to match GCC driver behaviour for li

[PATCH] D98023: [clang] Don't make the g++ driver imply an explicitly shared libunwind

mstorsjo added a subscriber: MaskRay. mstorsjo added a comment. In D98023#2606973 , @mati865 wrote: > I'm a bit worried about this code though: > > bool AsNeeded = LGT == LibGccType::UnspecifiedLibGcc && > !TC.getTriple().isAndroid() &&

[PATCH] D98023: [clang] Don't make the g++ driver imply an explicitly shared libunwind

mstorsjo added a comment. In D98023#2607854 , @MaskRay wrote: > I have tested the following configurations on x86_64-linux-gnu and I don't > find a difference. > > CC=/tmp/RelA/bin/clang > CXX=/tmp/RelA/bin/clang++ > $CC -c a.c > $CC a.o '-###' &>

[PATCH] D98023: [clang] Don't default to a specifically shared libunwind on mingw with a g++ driver

mstorsjo updated this revision to Diff 328657. mstorsjo retitled this revision from "[clang] Don't make the g++ driver imply an explicitly shared libunwind" to "[clang] Don't default to a specifically shared libunwind on mingw with a g++ driver". mstorsjo added a comment. Changed the condition t

[PATCH] D98022: [clang] Fix typos in the default logic for CLANG_DEFAULT_UNWINDLIB

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG002dd47bdd67: [clang] Fix typos in the default logic for CLANG_DEFAULT_UNWINDLIB (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHAN

[PATCH] D98023: [clang] Don't default to a specifically shared libunwind on mingw with a g++ driver

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGebe6d3be0f73: [clang] Don't default to a specifically shared libunwind on mingw with a g++… (authored by mstorsjo). Repository: rG LLVM Github Mon

[PATCH] D98023: [clang] Don't default to a specifically shared libunwind on mingw with a g++ driver

mstorsjo added a comment. In D98023#2609318 , @phosek wrote: > We see two test failures that appear to have been introduced by this change: Hmm - I'm pretty surprised about that, because the change literally added an `&& !TC.getTriple().isOSCygMing()`, w

[PATCH] D98022: [clang] Fix typos in the default logic for CLANG_DEFAULT_UNWINDLIB

mstorsjo added a comment. In D98022#2609374 , @phosek wrote: > We use `CLANG_DEFAULT_RTLIB=compiler-rt` for our toolchain and it looks like > after this change, two tests started failing: > [...] > This is presumably because both of these tests assume tha

[PATCH] D98022: [clang] Fix typos in the default logic for CLANG_DEFAULT_UNWINDLIB

mstorsjo added a comment. In D98022#2609380 , @MaskRay wrote: > The test should be fixable with explicit `--unwindlib=platform`. Sure, but this change also was meant to be a NFC, which it wasn't... so either we make this case set the unwindlib to `""`, o

[PATCH] D98142: [clang] Don't set CLANG_DEFAULT_UNWINDLIB to none if rtlib is set to compiler-rt

mstorsjo created this revision. mstorsjo added reviewers: phosek, MaskRay, saugustine. Herald added subscribers: mgorny, dberris. mstorsjo requested review of this revision. Herald added a project: clang. 002dd47bdd674fad8186650f07458b1e062545df

[PATCH] D98142: [clang] Don't set CLANG_DEFAULT_UNWINDLIB to none if rtlib is set to compiler-rt

This revision was automatically updated to reflect the committed changes. Closed by commit rGe81d813717b2: [clang] Don't set CLANG_DEFAULT_UNWINDLIB to none if rtlib is set to compiler-rt (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.ll

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

mstorsjo added a comment. This broke building ANGLE as part of Qt 5.15 for a mingw target, with the following error: ../../../3rdparty/angle/src/libANGLE/renderer/d3d/d3d11/ResourceManager11.cpp:532:38: error: explicit instantiation of 'allocate' does not refer to a function template, varia

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

mstorsjo added a comment. In D110216#3130193 , @mizvekov wrote: > In D110216#3130184 , @mstorsjo > wrote: > >> Do you happen to know what's going on here? The files mentioned are >> https://code.qt.io/cgit/qt/qt

[PATCH] D114064: [clang] [MinGW] Pass --no-demangle through to the mingw linker

mstorsjo created this revision. mstorsjo added a reviewer: rnk. mstorsjo requested review of this revision. Herald added a project: clang. Clang has custom handling of --no-demangle, where it is removed from the input -Wl and -Xlinker options, and readded specifically by the drivers where it's kno

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo updated this revision to Diff 388857. mstorsjo added a comment. Added a comment about the surprising change where the order of append and native is switched. Made the modification to `testRoot()` less hacky. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://rev

[PATCH] D113268: [clangd] Fix tests with forward slash as separator on windows

mstorsjo added a comment. Sorry for taking so long to get back to you on this matter... In D113268#3112026 , @sammccall wrote: >> For someone unfamiliar with the tool, is there a simple "smoke test >> procedure" I could try out with it to kick the tyres

[PATCH] D112430: [ARM][libunwind] add PACBTI-M support for libunwind

mstorsjo added a comment. Looks overall ok, without diving in very deep, except for this one change that seemed unrelated. Comment at: libunwind/src/Unwind-EHABI.cpp:312 uint8_t registers = getByte(data, offset++); - if (registers & 0xf0 || !registe

[PATCH] D114576: [PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

mstorsjo added a comment. Would it be possible to move setting of this flag to somewhere else (e.g. somewhere in Driver/ToolChains/MSVC.cpp), so that it would be picked up also when building with the gcc-style driver with `--target=*-windows-msvc`? Overall in earlier discussions, there's been m

[PATCH] D114576: [PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. Thanks! This LGTM - but maybe wait a while if someone else has something to say. (Although I guess americans are on holiday today, so there's probably not many that will see and care today

[PATCH] D112430: [ARM][libunwind] add PACBTI-M support for libunwind

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. I guess this is ok then. I can't say I've followed every bit in detail, but it looks sensible overall. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.l

[PATCH] D109856: [libunwind][ARM] Handle end of stack during unwind

mstorsjo added a comment. Looks reasonable I think. Is this a deficiency in the EHABI implementation only, i.e. this aspect works as it should in the regular dwarf implementation? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109856/new/ https://reviews.llvm.org/D109856 __

[PATCH] D109856: [libunwind][ARM] Handle end of stack during unwind

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. In D109856#3155235 , @danielkiss wrote: > In D109856#3154763 , @mstorsjo > wrote: > >> Looks reasonable

[PATCH] D114651: [clang-cl] Expose -Wall to clang-cl by unaliasing -Wall, keeping /Wall as alias to -Weverything

mstorsjo added a comment. In D114651#3156374 , @zero9178 wrote: > Is the deviation from MSVC behaviour here intentional? MSVC flags allow both > using a `/` as well as `-` as prefix. That means Both `-Wall` and `/Wall` are > accepted by MSVC as well as

[PATCH] D114651: [clang-cl] Expose -Wall to clang-cl by unaliasing -Wall, keeping /Wall as alias to -Weverything

mstorsjo added a comment. In D114651#3158807 , @rnk wrote: > I will add that multiple users have run into this problem, and I think it > might be more practical to consider unaliasing Wall altogether. Clang doesn't > emit the same set of warnings as MSV

[PATCH] D113254: [clang] Fix a misadjusted path style comparison in a unittest

mstorsjo added a comment. Ping @dexonsmith Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113254/new/ https://reviews.llvm.org/D113254 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[PATCH] D134637: clang-tblgen build: avoid duplicate inclusion of libLLVMSupport

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, this looks reasonable to me. (Although wait a little bit more if someone else responds to the ping this time...) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION h

[PATCH] D136776: [clang codegen] Fix __try/__finally blocks in C++ constructors.

mstorsjo resigned from this revision. mstorsjo added a comment. Sorry, I know essentially nothing about this area... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136776/new/ https://reviews.llvm.org/D136776 ___

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

mstorsjo added a comment. Herald added subscribers: JDevlieghere, jdoerfert. This broke builds where clang/lld/lldb are symlinked into `llvm/tools` instead of specified via `LLVM_ENABLE_PROJECTS` - since `${CMAKE_CURRENT_SOURCE_DIR}/../cmake` doesn't find anything in that context. (The reason f

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

mstorsjo added a comment. In D136572#3888177 , @mstorsjo wrote: > This broke builds where clang/lld/lldb are symlinked into `llvm/tools` > instead of specified via `LLVM_ENABLE_PROJECTS` - since > `${CMAKE_CURRENT_SOURCE_DIR}/../cmake` doesn't find anyt

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

mstorsjo accepted this revision. mstorsjo added a comment. In D136572#3888630 , @mgorny wrote: > @mstorsjo, could you check this version? LGTM, this seems to work for my usecase (with lld,lldb,clang enabled this way). Thanks for the quick revert and fix

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

mstorsjo added a comment. Also for the record, I'd love to get rid of this symlink based setup, if I could make cmake produce project files where caching works in the same way. The main requirement for that would be to have the whole cmake build started from the toplevel llvm-project directory

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

mstorsjo added a comment. In D136572#3890835 , @mgorny wrote: > In D136572#3889317 , @mstorsjo > wrote: > >> Also for the record, I'd love to get rid of this symlink based setup, if I >> could make cmake produce

[PATCH] D137073: [clang] Fix inline builtin functions of an __asm__ renamed function with symbol prefixes

mstorsjo created this revision. mstorsjo added reviewers: aaron.ballman, rnk. Herald added a project: All. mstorsjo requested review of this revision. Herald added a project: clang. If a function is renamed with `__asm__`, the name provided is the exact symbol name, without any extra implicit symb

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

mstorsjo added a comment. In D137107#3897326 , @rnk wrote: > Unless I'm missing something, I think Clang's behavior here is preferable to > MSVC's. MSVC produces code which will not link. Clang turns the linker error > into a compiler error, which is ge

[PATCH] D137073: [clang] Fix inline builtin functions of an __asm__ renamed function with symbol prefixes

mstorsjo added inline comments. Comment at: clang/lib/CodeGen/CGExpr.cpp:5020 +std::string AsmName; +if (auto *A = FD->getAttr()) { + StringRef UserLabelPrefix = rnk wrote: > I think you can call CGM.getMangledName, but I might be wrong. It's worth

[PATCH] D137073: [clang] Fix inline builtin functions of an __asm__ renamed function with symbol prefixes

mstorsjo updated this revision to Diff 472257. mstorsjo added a comment. Use `CGM.getMangledName()`, simplifying the code instead of complicating it further. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137073/new/ https://reviews.llvm.org/D13707

[PATCH] D137073: [clang] Fix inline builtin functions of an __asm__ renamed function with symbol prefixes

mstorsjo added reviewers: serge-sans-paille, nickdesaulniers. mstorsjo added a comment. This seems like a followup to D134362 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137073/new/ https://reviews.llvm.org/D13

[PATCH] D130894: [clang] Print more information about failed static assertions

mstorsjo added a comment. This broke building with GCC (also noted by buildbot mails): ../tools/clang/lib/Sema/SemaDeclCXX.cpp: In member function ‘void clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*)’: ../tools/clang/lib/Sema/SemaDeclCXX.cpp:1:19: error: declaration of ‘co

[PATCH] D130969: [clang] [HLSL] Fix GCC warnings about virtual methods that are hidden

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5d89f9044392: [clang] [HLSL] Fix GCC warnings about virtual methods that are hidden (authored by mstorsjo). Repository: rG LLVM Github Monorepo C

[PATCH] D131528: [Clang] Restrict non fixed enum to a value outside the range of the enumeration values warning to context requiring a constant expression

mstorsjo added a comment. There are still some cases that were broken by D131307 , that aren't fixed by this patch. Building https://martin.st/temp/qt-enum.cpp with `clang -target i686-w64-mingw32 -c -std=c++17 qt-enum.cpp -Wno-ignored-attributes -Wno-user-defi

[PATCH] D130701: [clang-tidy] Rename a local cmake variables to match the new tool name. NFC.

mstorsjo added a comment. Ping @sammccall (although I guess I could just go ahead and commit this as it is quite trivial, but as I sent it out for review in the first place...) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130701/new/ https://rev

[PATCH] D130894: [clang] Print more information about failed static assertions

mstorsjo added a comment. In D130894#3715709 , @aaron.ballman wrote: > In D130894#3715143 , @xbolva00 > wrote: > >> In D130894#3715124 , @mstorsjo >> wrote: >> >>> This

[PATCH] D131528: [Clang] Restrict non fixed enum to a value outside the range of the enumeration values warning to context requiring a constant expression

mstorsjo added a comment. In D131528#3716876 , @shafik wrote: > In D131528#3715841 , @thakis wrote: > >> We're also still seeing the diag fire after this: >> https://ci.chromium.org/p/chromium/builders/ci/ToTLinu

[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

mstorsjo added a comment. I found another case of this warning, which is kinda borderline whether it really is an error not: #include static _Noreturn void my_exit(void) { exit(42); } __attribute__((noreturn)) void (*handler)(void) = my_exit; The fix is simple though, just be consi

[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

mstorsjo added a comment. In D131351#3718725 , @aaron.ballman wrote: > In D131351#3718421 , @mstorsjo > wrote: > >> I found another case of this warning, which is kinda borderline whether it >> really is an err

[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

mstorsjo added a comment. A different but slightly similar case, where I've run into these errors too, FWIW: On ARM, when compiling with a hardfloat target, Clang does consider a function pointer with `__attribute__((pcs("aapcs-vfp")))` different from one without, even if the default still in t

[PATCH] D131528: [Clang] Restrict non fixed enum to a value outside the range of the enumeration values warning to context requiring a constant expression

mstorsjo added a comment. In D131528#3719414 , @shafik wrote: > In D131528#3718405 , @mstorsjo > wrote: > >> In D131528#3716876 , @shafik wrote: >> >>> In D131528#3715841

[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

mstorsjo added a comment. This also broke building with GCC 9 on Ubuntu 20.04: [5/225] ASTNodeAPI.json FAILED: tools/clang/lib/Tooling/ASTNodeAPI.json cd /home/martin/code/llvm-project/llvm/build/tools/clang/lib/Tooling && /home/martin/code/llvm-project/llvm/build/bin/clang-ast-dump --ski

[PATCH] D131874: [Clang] Tighten restrictions on enum out of range diagnostic to avoid constant initialization

mstorsjo added a comment. Thanks! With this, I think all my cases (that built before D131307 ) now build successfully again! (Can't say much about the code change itself, but I think it looks reasonable.) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D1

[PATCH] D130701: [clang-tidy] Rename a local cmake variables to match the new tool name. NFC.

This revision was automatically updated to reflect the committed changes. Closed by commit rG9ad0ace2ba52: [clang-tidy] Rename a local cmake variables to match the new tool name. NFC. (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.o

[PATCH] D131874: [Clang] Tighten restrictions on enum out of range diagnostic to avoid constant initialization

mstorsjo added a comment. Thanks! It seems like this now finally works as it should again, with the code I regularly build. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131874/new/ https://reviews.llvm.org/D131874 ___

[PATCH] D131052: [CMake] Allow setting the location of host tools with LLVM_NATIVE_TOOL_DIR

mstorsjo added a comment. Ping - is there any interest in this - a single flag for pointing towards existing prebuilt native executables instead of having to name every one (llvm-tblgen, clang-tblgen, lldb-tblgen, clang-pseudo-gen, clang-tidy-confusable-chars-gen) individually? Repository:

[PATCH] D131052: [CMake] Allow setting the location of host tools with LLVM_NATIVE_TOOL_DIR

mstorsjo added a comment. In D131052#3731894 , @sammccall wrote: > FWIW I have no idea: in principle this makes sense, but I don't use such a > configuration and don't have a clear idea of what people who do use it want. Thanks for having a look and dis

[PATCH] D126183: Implement soft reset of the diagnostics engine.

mstorsjo added a comment. FYI, this change caused warnings when built with GCC: [1/1] Building CXX object tools/clang/unittests/Basic/CMakeFiles/BasicTests.dir/DiagnosticTest.cpp.o ../tools/clang/unittests/Basic/DiagnosticTest.cpp:17:6: warning: ‘void clang::DiagnosticsTestHelper(clang::Dia

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

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM. (Should we have a testcase for this, or is it trivial enough to just go as is?) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132440/n

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

mstorsjo created this revision. mstorsjo added reviewers: phosek, thakis, hans. Herald added a project: All. mstorsjo requested review of this revision. Herald added a subscriber: MaskRay. Herald added a project: clang. Normally, passing -rtlib=platform overrides any earlier -rtlib options, and ov

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

mstorsjo added a comment. In D132444#3742295 , @thakis wrote: > Do we have precedent for "platform" for this? For fuse-ld=, one is supposed > to use `-fuse-ld=` (without anything after the `=`) to get the default ld. > That's not great (...but it can't

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

mstorsjo added a comment. In D132444#3742305 , @mstorsjo wrote: > In D132444#3742295 , @thakis wrote: > >> Do we have precedent for "platform" for this? For fuse-ld=, one is supposed >> to use `-fuse-ld=` (withou

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

mstorsjo added a comment. In D132444#3743020 , @thakis wrote: > Makes sense to me. Maybe @hans has an opinion too. > > WDYT about accepting the same string for -fuse-ld= to mean "platform linker" > there as well? Sounds reasonable to me - requiring the

[PATCH] D132302: [clang] Add support for __attribute__((guard(nocf)))

This revision was automatically updated to reflect the committed changes. Closed by commit rG94778692ad25: [clang] Add support for __attribute__((guard(nocf))) (authored by alvinhochun, committed by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D132302?vs=454798&id=454944#toc Re

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

mstorsjo added a comment. > This reverts commit eca29d4a37b8d1c93fe99be6289a60bb11cf789d > since > the test fails in the per-target-runtime-dir layout. Does that mean that the testcase ended up looking at other libraries next

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

This revision was automatically updated to reflect the committed changes. Closed by commit rG0a4c6c9f98a6: [clang] Allow using -rtlib=platform to switching to the default rtlib on all… (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.

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

mstorsjo added a comment. This triggers failed asserts for me: $ cat repro.c static float strtof(char *, char *) {} void a() { strtof(a, 0); } $ clang -target x86_64-w64-mingw32 -w -c repro.c -O3 clang: ../lib/Analysis/CGSCCPassManager.cpp:958: updateCGAndAnalysisManagerForPass(llvm::

[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.

mstorsjo added a comment. I think this looks reasonable to me, but I don't think I'm knowledgeable enough to give this a proper review, sorry. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125418/new/ https://reviews.llvm.org/D125418

[PATCH] D125419: [Arm64EC 7/?] clang side of Arm64EC varargs ABI.

mstorsjo added a comment. I think this looks reasonable to me - if noone else has time to approve it, I guess I could, but I'd rather have the more authoritative reviewers complete their reviews. Comment at: llvm/utils/UpdateTestChecks/common.py:330 OPT_FUNCTION_RE = re.comp

[PATCH] D133959: Add clang flag equivalent to clang-cl /Zl flag

mstorsjo added inline comments. Comment at: clang/test/Driver/cl-runtime-flags.c:101 +// RUN: %clang -### --target=x86_64-windows-msvc -fms-runtime-lib=static \ +// RUN: -fms-omit-default-lib-name -- %s 2>&1 | FileCheck \ +// RUN: -check-prefix=CHECK-MTZl %s

[PATCH] D133959: Add clang flag equivalent to clang-cl /Zl flag

mstorsjo accepted this revision. mstorsjo added a comment. LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133959/new/ https://reviews.llvm.org/D133959 ___ cfe-commits mailing list cfe-commit

<    3   4   5   6   7   8   9   10   11   12   >