[PATCH] D154176: [Driver][MSVC] Move lld specific flags before inputs

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. In D154176#4466230 , @HaohaiWen wrote: > In D154176#4466190 , @mstorsjo > wrote: > >> In D154176#4466186

[PATCH] D154295: [Driver][MSVC] Support DWARF fission when using LTO on Windows

mstorsjo accepted this revision. mstorsjo added subscribers: hans, rnk. mstorsjo added a comment. This revision is now accepted and ready to land. I think this looks reasonable, unless e.g. @hans or @rnk would disagree. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://r

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

mstorsjo added a comment. In D145302#4491973 , @glandium wrote: > This broke building with `-DLLVM_LINK_LLVM_DYLIB=ON`: I also ran into this; I pushed a fix in a20d57e83441a69fa2bab86593b18cc0402095d2

[PATCH] D155111: [clangd] Fix build failures observed on build bots for missing libs

mstorsjo added a comment. To clarify the issue - the kind of builds that seems to be broken is builds with `BUILD_SHARED_LIBS=ON`. The reason is that these libraries are needed is because the `clangd` target includes `$`, so all the dependencies of `clangDaemonTweaks` would need to be included

[PATCH] D151188: [LLD][COFF] Add LLVM toolchain library paths by default.

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

[PATCH] D151188: [LLD][COFF] Add LLVM toolchain library paths by default.

mstorsjo added a comment. Maybe add a release note for this too? It's rather significant. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151188/new/ https://reviews.llvm.org/D151188 ___ cfe-commits mailin

[PATCH] D158411: [clang] [MinGW] Pass LTO options to the linker

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa23bf1786be7: [clang] [MinGW] Pass LTO options to the linker (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTIO

[PATCH] D61670: [clang] [MinGW] Add the option -fno-autoimport

mstorsjo added a comment. In D61670#4611790 , @aeubanks wrote: > In D61670#4607313 , @mstorsjo wrote: > >>> I expected the answer would be "yes", so I said "lgtm" and then phrased my >>> question very awkwardly. >>

[PATCH] D61670: [clang] [MinGW] Add the option -fno-autoimport

mstorsjo updated this revision to Diff 553624. mstorsjo edited the summary of this revision. mstorsjo added a comment. Updated to use the form -fno-auto-import and similar split it into two separate words everywhere. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://rev

[PATCH] D152054: [OpenMP] Codegen support for thread_limit on target directive

mstorsjo added a comment. This new test is failing on Windows, due to `__kmpc_set_thread_limit` not being exported - see e.g. https://github.com/mstorsjo/llvm-mingw/actions/runs/5994183421/job/16264501555. Can someone add it to `openmp/runtime/src/dllexports`? Repository: rG LLVM Github Mon

[PATCH] D152054: [OpenMP] Codegen support for thread_limit on target directive

mstorsjo added subscribers: vadikp-intel, natgla. mstorsjo added a comment. In D152054#4620927 , @mstorsjo wrote: > This new test is failing on Windows, due to `__kmpc_set_thread_limit` not > being exported - see e.g. > https://github.com/mstorsjo/llvm-

[PATCH] D152054: [OpenMP] Codegen support for thread_limit on target directive

mstorsjo added a comment. In D152054#4622642 , @vadikp-intel wrote: > Windows importing is now done by name, and new exports do not need to have an > ordinal specified for them i.e. you can add a line with just the API name to > dllexports. Oh, right,

[PATCH] D61670: [clang] [MinGW] Add the option -fno-autoimport

mstorsjo added a comment. In D61670#4621724 , @aeubanks wrote: > I don't have all the context here, but seems fine once the commit description > is updated with the new spelling Thanks. Yeah I've updated the commit message locally (I wonder if the `arc`

[PATCH] D152752: [MS] Fix passing aligned records by value in some cases

mstorsjo added a comment. In D152752#4626234 , @rnk wrote: > I need to get to it, my recollection is that @mstorsjo ran into the same > issue here for mingw and made some changes, I wanted to go dig those up as a > starting point. I may have completely

[PATCH] D152054: [OpenMP] Codegen support for thread_limit on target directive

mstorsjo added inline comments. Comment at: openmp/runtime/test/target/target_thread_limit.cpp:28 +// OMP51: target: parallel +// OMP51: target: parallel +// OMP51-NOT: target: parallel This test fails when running (on Windows) on GitHub Actions runners - see ht

[PATCH] D152054: [OpenMP] Codegen support for thread_limit on target directive

mstorsjo added inline comments. Comment at: openmp/runtime/test/target/target_thread_limit.cpp:28 +// OMP51: target: parallel +// OMP51: target: parallel +// OMP51-NOT: target: parallel mstorsjo wrote: > This test fails when running (on Windows) on GitHub Actions

[PATCH] D61670: [clang] [MinGW] Add the option -fno-auto-import

This revision was automatically updated to reflect the committed changes. Closed by commit rGf9f2fdcf03d9: [clang] [MinGW] Add the option -fno-auto-import (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D61670?vs=553624&id=555462#toc Repository: rG LLVM Github Monor

[PATCH] D137470: [Offloading] Initial support for registering offloading entries on COFF targets

mstorsjo added a comment. In D137470#3928870 , @jhuber6 wrote: > In D137470#3928828 , @mstorsjo > wrote: > >> Sorry, I'm not quite up to speed with exactly what is being done linker-wise >> here - can you give a

[PATCH] D138692: [clang] [MinGW] Improve/extend the gcc/sysroot detection logic

mstorsjo created this revision. mstorsjo added reviewers: rnk, mati865, alvinhochun, tstellar. Herald added a subscriber: pengfei. Herald added a project: All. mstorsjo requested review of this revision. Herald added a subscriber: MaskRay. Herald added a project: clang. There are three functions t

[PATCH] D138693: [clang] [MinGW] Improve detection of libstdc++ headers on Fedora

mstorsjo created this revision. mstorsjo added reviewers: rnk, mati865, alvinhochun, tstellar. Herald added a subscriber: pengfei. Herald added a project: All. mstorsjo requested review of this revision. Herald added a subscriber: MaskRay. Herald added a project: clang. There's some variation in w

[PATCH] D138692: [clang] [MinGW] Improve/extend the gcc/sysroot detection logic

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG02b25bd904b5: [clang] [MinGW] Improve/extend the gcc/sysroot detection logic (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D138693: [clang] [MinGW] Improve detection of libstdc++ headers on Fedora

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG98454e388500: [clang] [MinGW] Improve detection of libstdc++ headers on Fedora (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGE

[PATCH] D74564: libclang: Add static build support for Windows

This revision was automatically updated to reflect the committed changes. Closed by commit rG7ff1f55a1219: libclang: Add static build support for Windows (authored by cristian.adam, committed by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org

[PATCH] D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc

mstorsjo added a comment. I'm not familiar with where/how the CrossWindows toolchain is used, but you say (and the code seems to agree) that it's intended to be able to use ld.bfd for linking code built for the MSVC ABI with MSVC/WinSDK libs? I'm surprised that even works at all (or does it, or

[PATCH] D69769: [Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc

mstorsjo added a comment. Same thing here, no need to send a separate patch for backporting. (And in general, for cases where backporting would be relevant, you'd normally just make a patch for master, then let it be merged there, and request a backport of it from the release branch maintainer,

[PATCH] D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc

mstorsjo added a comment. In D69760#1739044 , @Ericson2314 wrote: > While I am fine making `-fuse-ld=lld` mean "use that lld driver most > appropriate for the clang driver", in principle the clang driver and lld > driver choices are orthogonal In princ

[PATCH] D69950: Reapply "Fix crash on switch conditions of non-integer types in templates"

mstorsjo added a comment. This (when reapplied in https://reviews.llvm.org/rG878a24ee244a24c39d1c57e9af2) broke compilation of code that earlier built fine. A reduced example: namespace glslang { class TPoolAllocator { void operator=(TPoolAllocator); }; template class a { TPoolA

[PATCH] D69950: Reapply "Fix crash on switch conditions of non-integer types in templates"

mstorsjo added a comment. In D69950#1771133 , @eandrews wrote: > In D69950#1770138 , @mstorsjo wrote: > > > This (when reapplied in > > https://reviews.llvm.org/rG878a24ee244a24c39d1c57e9af2) broke compilation > >

[PATCH] D69950: Reapply "Fix crash on switch conditions of non-integer types in templates"

mstorsjo added a comment. In D69950#1771515 , @rnk wrote: > I fixed this particular code upstream: > https://github.com/KhronosGroup/glslang/pull/2010 > I am not enough an expert to be sure, but I suspect this is in the area of > "invalid, no diagnostic

[PATCH] D71400: [RFC] [MinGW] Implicitly add .exe suffix if not provided

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Herald added a project: clang. GCC implicitly adds an .exe suffix if it is given an output file name, but the file name doesn't contain a suffix, and there are certain users of GCC that rely on this behaviour (and run into issues wh

[PATCH] D71400: [RFC] [MinGW] Implicitly add .exe suffix if not provided

mstorsjo updated this revision to Diff 233863. mstorsjo marked 2 inline comments as done. mstorsjo added a comment. Added a code comment, using `llvm::path::has_extension`, added testcases. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71400/new/ https://reviews.llvm.org/D71400 Files:

[PATCH] D71572: [ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows

mstorsjo created this revision. mstorsjo added reviewers: rnk, froydnj, compnerd. Herald added a project: clang. On Windows, weak_odr is a no-op, and thus a weak_odr tls wrapper function can result in linker errors due to multiply defined symbols. Therefore, use linkonce_odr instead of weak_odr

[PATCH] D71400: [RFC] [MinGW] Implicitly add .exe suffix if not provided

mstorsjo added a comment. Ping CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71400/new/ https://reviews.llvm.org/D71400 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71572: [ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows

mstorsjo added a comment. Actually, this doesn't seem to be enough for the case at hand (used with `-ffunction-sections -fdata-sections`), I'll have to continue looking into it tomorrow. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71572/new/ ht

[PATCH] D71572: [ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2519-2520 return VarLinkage; + // On Windows, WeakODR is a no-op, boiling down to the same as normal external + // linkage. + if (CGM.getTriple().

[PATCH] D71400: [RFC] [MinGW] Implicitly add .exe suffix if not provided

This revision was automatically updated to reflect the committed changes. Closed by commit rGee0a3b5c776c: [MinGW] Implicitly add .exe suffix if not provided (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71400/new/ https://re

[PATCH] D71572: [ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows

mstorsjo marked 2 inline comments as done. mstorsjo added inline comments. Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2519-2520 return VarLinkage; + // On Windows, WeakODR is a no-op, boiling down to the same as normal external + // linkage. + if (CGM.getTriple().

[PATCH] D71572: [ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2519-2520 return VarLinkage; + // On Windows, WeakODR is a no-op, boiling down to the same as normal external + // linkage. + if (CGM.getTriple().

[PATCH] D71572: [ItaniumCXXABI] Make tls wrappers comdat on Windows

mstorsjo updated this revision to Diff 234269. mstorsjo retitled this revision from "[ItaniumCXXABI] Use linkonce_odr instead of weak_odr for tls wrappers on Windows" to "[ItaniumCXXABI] Make tls wrappers comdat on Windows". mstorsjo edited the summary of this revision. mstorsjo added a reviewer:

[PATCH] D71572: [ItaniumCXXABI] Make tls wrappers comdat on Windows

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2551 + // actually handle multiple TUs defining the same wrapper. + if (CGM.getTriple().isOSWindows() && CGM.supportsCOMDAT() && + Wrapper->isWeakForL

[PATCH] D71572: [ItaniumCXXABI] Make tls wrappers comdat on Windows

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2551 + // actually handle multiple TUs defining the same wrapper. + if (CGM.getTriple().isOSWindows() && CGM.supportsCOMDAT() && + Wrapper->isWeakForL

[PATCH] D71650: [AST] Fix compilation with GCC < 8 for MinGW

mstorsjo created this revision. mstorsjo added reviewers: rsmith, rjmccall, rnk, Mordante. Herald added a project: clang. GCC 7 and earlier, when targeting MinGW, seems to have a bug in layout/size of bitfield structs if they contain a nested enum, making the size of the struct 8 bytes, while we

[PATCH] D71650: [AST] Fix compilation with GCC < 8 for MinGW

mstorsjo added a comment. In D71650#1789897 , @rjmccall wrote: > Wow, that's novel. Please add a comment explaining that this is a compiler > workaround, but otherwise LGTM. The post-patch form doesn't look that odd to me (and we wouldn't want one com

[PATCH] D71650: [AST] Fix compilation with GCC < 8 for MinGW

mstorsjo added a comment. Ok, so if you're in agreement on this one, can either of you give the stamp of approval? :-) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71650/new/ https://reviews.llvm.org/D71650

[PATCH] D71650: [AST] Fix compilation with GCC < 8 for MinGW

This revision was automatically updated to reflect the committed changes. Closed by commit rGf20fc65887e2: [clang] Fix compilation with GCC < 8 for MinGW (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71650/new/ https://review

[PATCH] D71572: [ItaniumCXXABI] Make tls wrappers comdat on Windows

mstorsjo added a comment. In D71572#1788786 , @rnk wrote: > Looks like @rsmith did this here: > > https://github.com/llvm/llvm-project/commit/fbe2369f1a514423e4c25417ab3532502fde6f2a > > I see that it was replacing a CHECK for a specific comdat group wit

[PATCH] D71716: [ItaniumCXXABI] Don't mark an extern_weak init function as dso_local on windows

mstorsjo created this revision. mstorsjo added reviewers: rnk, smeenai, rsmith. Herald added a project: clang. Since 6bf108d77a3c, we try to not mark extern_weak symbols as dso_local, to allow using COFF stubs for references to those symbols (as the symbol may be missing, resolving to an absolut

[PATCH] D71716: [ItaniumCXXABI] Don't mark an extern_weak init function as dso_local on windows

This revision was automatically updated to reflect the committed changes. Closed by commit rG86c9831bb40d: [ItaniumCXXABI] Don't mark an extern_weak init function as dso_local on windows (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D75068: libclang: Add static build support for Windows

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

[PATCH] D73534: [DebugInfo] Enable the debug entry values feature by default

mstorsjo added a comment. Herald added a subscriber: danielkiss. This broke compiling for mingw, repro.c: a(short); b() { a(1); } `clang -target x86_64-w64-mingw32 -c repro.c -g -O2`, which gives `Assertion `!MI.isMoveImmediate() && "Unexpected MoveImm instruction"' failed.` CHANGES SINCE

[PATCH] D73534: [DebugInfo] Enable the debug entry values feature by default

mstorsjo added a comment. In D73534#1918818 , @djtodoro wrote: > In D73534#1916309 , @djtodoro wrote: > > > In D73534#1916291 , @djtodoro > > wrote: > > > > > Thanks for rep

[PATCH] D75068: libclang: Add static build support for Windows

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

[PATCH] D74028: [clang] Add release notes for the 10.x branch for things I've done

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans. Herald added a project: clang. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D74028 Files: clang/docs/ReleaseNotes.rst Index: clang/docs/ReleaseNotes.rst

[PATCH] D74028: [clang] Add release notes for the 10.x branch for things I've done

mstorsjo closed this revision. mstorsjo added a comment. Committed in https://reviews.llvm.org/rG7e518f3159bd. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74028/new/ https://reviews.llvm.org/D74028 _

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

mstorsjo added a comment. FYI this caused failed builds for aarch64 (when building with `-fno-signed-zeros`), hitting unreachable statements in TargetLowering::getNegatedExpression - see https://bugs.llvm.org/show_bug.cgi?id=44892. I guess that's a bug in the aarch64 backend and not with this

[PATCH] D44494: [libunwind] Support __register_frame with a full .eh_frame section

mstorsjo added a comment. In https://reviews.llvm.org/D44494#1050783, @compnerd wrote: > I really don't like this approach. I think that we should introduce a > different entry point for this behavior rather than saying that we go through > the existing interface. Having a reference to the `.

[PATCH] D44494: [libunwind] Support __register_frame with a full .eh_frame section

mstorsjo added a comment. In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote: > This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about > registering a single FDE (which libunwind's `__register_frame` currently > does) vs registering a full `.eh_frame` section (which lib

[PATCH] D44494: [libunwind] Support __register_frame with a full .eh_frame section

mstorsjo added a comment. In https://reviews.llvm.org/D44494#1050803, @mstorsjo wrote: > In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote: > > > This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about > > registering a single FDE (which libunwind's `__register_frame` cu

[PATCH] D44494: [libunwind] Support __register_frame with a full .eh_frame section

mstorsjo added a subscriber: joerg. mstorsjo added a comment. Also, relating to this, @joerg mentioned on irc that one should rather use `__register_frame_info_bases` instead of `__register_frame`. That function is a bit tricky to call though, since it uses a libgcc internal struct `struct obje

[PATCH] D44494: [libunwind] Support __register_frame with a full .eh_frame section

mstorsjo updated this revision to Diff 140410. mstorsjo edited the summary of this revision. mstorsjo added a comment. Herald added a subscriber: JDevlieghere. Added and using a helper function `isCIE` to avoid using the error return path from `decodeFDE`. Technically, the decision between a ful

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

mstorsjo created this revision. mstorsjo added reviewers: martell, compnerd, rnk, mati865, ismail, yaron.keren. This avoids looking for a mingw gcc to use as sysroot, preferring the clang installation itself over a similar gcc found in the path. The option name, `--ignore-gcc`, might not be idea

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

mstorsjo added inline comments. Comment at: include/clang/Driver/Options.td:1735 MetaVarName<"">, Flags<[CC1Option]>; +def ignore_gcc : Joined<["--"], "ignore-gcc">, Flags<[DriverOption]>, + HelpText<"Don't look for gcc for finding a suitable sysroot">; Perha

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

mstorsjo added a comment. In https://reviews.llvm.org/D45152#1055871, @rnk wrote: > Seems reasonable, looks good. Any opinion on the wording of the option name? Repository: rC Clang https://reviews.llvm.org/D45152 ___ cfe-commits mailing list

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

mstorsjo added a comment. In https://reviews.llvm.org/D45152#1056134, @rnk wrote: > In https://reviews.llvm.org/D45152#1056122, @mstorsjo wrote: > > > In https://reviews.llvm.org/D45152#1055871, @rnk wrote: > > > > > Seems reasonable, looks good. > > > > > > Any opinion on the wording of the opti

[PATCH] D45152: [MinGW] Add option for disabling looking for a mingw gcc in PATH

mstorsjo added a comment. In https://reviews.llvm.org/D45152#1057787, @martell wrote: > @mstorsjo I would much prefer to detect the clang sysroot first and if that > exists just ignore the gcc one. > Most of the time clang and gcc will be in the same bin folder and in the > case where the clan

[PATCH] D45500: [MinGW] Look for libc++ headers in a triplet prefixed path as well

mstorsjo created this revision. mstorsjo added reviewers: martell, rnk, compnerd, mati865. Herald added a reviewer: EricWF. This makes it consistent with libstdc++ and the other default include directories. If these headers are found in both locations and one isn't a symlink to the other, this

[PATCH] D45504: [MinGW] Look for a cross sysroot relative to the clang binary

mstorsjo created this revision. mstorsjo added reviewers: martell, rnk, compnerd, mati865, ismail, yaron.keren. If found, prefer this over looking for a similar gcc later in the system path. This implements what @martell suggested in https://reviews.llvm.org/D45152 in a much neater way. Tests s

[PATCH] D45505: [WIP] [GCC] Match a GCC version with a patch suffix without a third version component

mstorsjo created this revision. mstorsjo added reviewers: chandlerc, martell, ismail, rnk, compnerd, mati865, yaron.keren. Previously it would only accept a string as a GCC version if it had either two components and no suffix, or three components with an optional suffix. Debian and ubuntu prov

[PATCH] D45504: [MinGW] Look for a cross sysroot relative to the clang binary

mstorsjo updated this revision to Diff 141909. mstorsjo added a comment. Fixed the hardcoded triplet suffix, previously I erroneously had a "-gcc" suffix there. https://reviews.llvm.org/D45504 Files: lib/Driver/ToolChains/MinGW.cpp lib/Driver/ToolChains/MinGW.h Index: lib/Driver/ToolChai

[PATCH] D45500: [MinGW] Look for libc++ headers in a triplet prefixed path as well

mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/MinGW.cpp:459 addSystemInclude(DriverArgs, CC1Args, + Base + Arch + llvm::sys::path::get_separator() + + "include" + llvm::sys::path::get_separator() + -

[PATCH] D38819: [libunwind] Add support for dwarf unwinding on windows on x86_64

mstorsjo added inline comments. Comment at: src/UnwindRegistersRestore.S:72 + movq 56(%rcx), %rax # rax holds new stack pointer + subq $16, %rax + movq %rax, 56(%rcx) mstorsjo wrote: > compnerd wrote: > > Hmm, why is this `$16`? The `$rsp` was adjusted by

[PATCH] D38819: [libunwind] Add support for dwarf unwinding on windows on x86_64

mstorsjo updated this revision to Diff 120380. mstorsjo added a comment. Simplified the assembly by sharing much more code between the unix and win64 paths, added a padding element to ensure more stable struct packing. https://reviews.llvm.org/D38819 Files: docs/index.rst include/__libunwi

[PATCH] D39281: [libunwind] Express Registers_*::lastDwarfReg using _LIBUNWIND_HIGHEST_DWARF_REGISTER

mstorsjo updated this revision to Diff 120467. mstorsjo edited the summary of this revision. mstorsjo added a comment. Herald added subscribers: JDevlieghere, aprantl. Adjusted _LIBUNWIND_HIGHEST_DWARF_REGISTER to actually have the value of the highest register, not highest+1. https://reviews.l

[PATCH] D39280: [libunwind] Use uint64_t for unw_word_t in ARM EHABI

mstorsjo added a comment. In https://reviews.llvm.org/D39280#908825, @compnerd wrote: > I dont think that this is correct. IIRC, the unwind specification expects > `unw_word_t` to match `uintptr_t` (that is, it should be 32-bits on > https://reviews.llvm.org/P32 environments). Ok, well curre

[PATCH] D39281: [libunwind] Express Registers_*::lastDwarfReg using _LIBUNWIND_HIGHEST_DWARF_REGISTER

This revision was automatically updated to reflect the committed changes. Closed by commit rL316745: Express Registers_*::lastDwarfReg using _LIBUNWIND_HIGHEST_DWARF_REGISTER (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39281?vs=120467&id=120548#toc Repository:

[PATCH] D38819: [libunwind] Add support for dwarf unwinding on windows on x86_64

This revision was automatically updated to reflect the committed changes. Closed by commit rL316747: Add support for dwarf unwinding on windows on x86_64 (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D38819?vs=120380&id=120552#toc Repository: rL LLVM https://revi

[PATCH] D39280: [libunwind] Use uint64_t for unw_word_t in ARM EHABI

mstorsjo added a comment. In https://reviews.llvm.org/D39280#908825, @compnerd wrote: > I dont think that this is correct. IIRC, the unwind specification expects > `unw_word_t` to match `uintptr_t` (that is, it should be 32-bits on > https://reviews.llvm.org/P32 environments). I checked with

[PATCH] D39365: [libunwind] Change unw_word_t to always have the same size as the pointer size

mstorsjo created this revision. Herald added subscribers: kristof.beyls, aemerson. This matches the original libunwind API. This also unifies the type between ARM EHABI and the other configurations, and allows getting rid of a number of casts in log messages. The cursor size updates for ppc and

[PATCH] D39382: [libunwind] Restore arch specific lastDwarfRegNum in builds without _LIBUNWIND_IS_NATIVE_ONLY

mstorsjo created this revision. This restores the previous behaviour of the Registers_* classes after SVN r316745. https://reviews.llvm.org/D39382 Files: include/__libunwind_config.h src/Registers.hpp Index: src/Registers.hpp ===

[PATCH] D39365: [libunwind] Change unw_word_t to always have the same size as the pointer size

mstorsjo added a comment. In https://reviews.llvm.org/D39365#909706, @rnk wrote: > Doesn't this change the ABI considerably? I suspect Apple cares about that. It does change the ABI of the lower level unw_* API yes, but it shouldn't be visible outside via the higher level APIs. > Is remotely

[PATCH] D39382: [libunwind] Restore arch specific lastDwarfRegNum in builds without _LIBUNWIND_IS_NATIVE_ONLY

mstorsjo added a comment. In https://reviews.llvm.org/D39382#909918, @compnerd wrote: > This is fine, although, how does the cross-unwinding work without the remote > address space support? No idea - I also was under the impression that it wasn't actually useful but mostly theoretical/planned

[PATCH] D39382: [libunwind] Restore arch specific lastDwarfRegNum in builds without _LIBUNWIND_IS_NATIVE_ONLY

This revision was automatically updated to reflect the committed changes. Closed by commit rL316843: Restore arch specific lastDwarfRegNum in builds without… (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39382?vs=120679&id=120736#toc Repository: rL LLVM https://

[PATCH] D38110: [libunwind][MIPS]: Add support for unwinding in O32 and N64 processes.

mstorsjo added a comment. Just a heads up WRT this patch; we're discussing changing the size of `unw_word_t` to match `uintptr_t` in https://reviews.llvm.org/D39365. Does that break anything for your case? It shouldn't affect what's stored in the Register class, only pointers in the unw_proc_in

[PATCH] D39365: [libunwind] Change unw_word_t to always have the same size as the pointer size

mstorsjo added a comment. In https://reviews.llvm.org/D39365#910590, @theraven wrote: > This makes things worse for us. On CHERI, `[u]intptr_t` is a (`typedef` for > a) built-in type that can hold a capability. Having `unw_word_t` be > `uintptr_t` For understanding, I guess you meant "Havin

[PATCH] D39365: [libunwind] Change unw_word_t to always have the same size as the pointer size

mstorsjo added a comment. In https://reviews.llvm.org/D39365#910713, @theraven wrote: > Sorry - it looks as if I read the diff back to front. I seem to be less > awake than I thought today... > > Reading the diff the correct way around, this seems like a definite > improvement. Ok, thanks! T

[PATCH] D39365: [libunwind] Change unw_word_t to always have the same size as the pointer size

This revision was automatically updated to reflect the committed changes. Closed by commit rL316942: Change unw_word_t to always have the same size as the pointer size (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39365?vs=120562&id=120860#toc Repository: rL LLVM

[PATCH] D39280: [libunwind] Use uint64_t for unw_word_t in ARM EHABI

mstorsjo abandoned this revision. mstorsjo added a comment. This was made obsolete by https://reviews.llvm.org/D39365. https://reviews.llvm.org/D39280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/list

[PATCH] D39251: [libunwind] Fix building for ARM with dwarf exception handling

mstorsjo updated this revision to Diff 120863. mstorsjo edited the summary of this revision. mstorsjo added a comment. Avoiding duplicating the highest register number, avoiding any further casts in log lines. https://reviews.llvm.org/D39251 Files: include/__libunwind_config.h include/libu

[PATCH] D33620: [CodeGenCXX] do not default to dllimport storage for mingw-w64

mstorsjo added a comment. After trying to build a bit more code with clang and a static libcxx, I agree with this change, so +1 from me. @compnerd ? Repository: rL LLVM https://reviews.llvm.org/D33620 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D39251: [libunwind] Fix building for ARM with dwarf exception handling

mstorsjo added inline comments. Comment at: src/Registers.hpp:1481 + mutable uint32_t _iwmmx_control[4]; #endif }; compnerd wrote: > Why the change to mark these as mutable? These are touched from within `getRegister`, but we need to make `getRegister` const

[PATCH] D39251: [libunwind] Fix building for ARM with dwarf exception handling

This revision was automatically updated to reflect the committed changes. Closed by commit rL317192: Fix building for ARM with dwarf exception handling (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39251?vs=120863&id=121242#toc Repository: rL LLVM https://review

[PATCH] D39533: [MinGW] Define __ARM_DWARF_EH__ on MinGW/ARM

mstorsjo created this revision. Herald added subscribers: kristof.beyls, javed.absar, aemerson. This should go together with https://reviews.llvm.org/D39532 in LLVM. https://reviews.llvm.org/D39533 Files: lib/Basic/Targets/ARM.cpp test/Preprocessor/init.c Index: test/Preprocessor/init.c =

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

mstorsjo created this revision. Herald added subscribers: kristof.beyls, aprantl, aemerson. This allows using dwarf exceptions on MinGW/ARM. This goes together with https://reviews.llvm.org/D39532 in LLVM and https://reviews.llvm.org/D39533 in clang. https://reviews.llvm.org/D39534 Files: d

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

mstorsjo added inline comments. Comment at: src/UnwindRegistersRestore.S:396 .fpu vfpv3-d16 +#endif DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreVFPWithFLDMDEPy) compnerd wrote: > This really isn't an ELF vs COFF/Mach-O thing. Does

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

mstorsjo added inline comments. Comment at: src/UnwindRegistersRestore.S:396 .fpu vfpv3-d16 +#endif DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreVFPWithFLDMDEPy) mstorsjo wrote: > compnerd wrote: > > This really isn't an ELF vs COFF

[PATCH] D39631: [X86] Add 3dnow and 3dnowa to the list of valid target features

mstorsjo created this revision. These were missed in SVN r316783, which broke compiling mingw-w64 CRT. https://reviews.llvm.org/D39631 Files: lib/Basic/Targets/X86.cpp test/Headers/mm3dnow.c Index: test/Headers/mm3dnow.c ===

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

mstorsjo added a comment. In https://reviews.llvm.org/D39534#915916, @compnerd wrote: > Very well, if thats the current implementation in the AsmParser, thats > reasonable. I don't think that the directive has anything to do with the > file format though. I can agree with that. In addition t

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

This revision was automatically updated to reflect the committed changes. Closed by commit rL317423: Add ifdefs around ELF specific parts of UnwindRegisters*.S for arm (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39534?vs=121245&id=121600#toc Repository: rL LLVM

[PATCH] D39632: [libunwind] [docs] Mention that dwarf unwinding should be supported on arm64/windows

mstorsjo created this revision. Herald added subscribers: kristof.beyls, aemerson. This didn't require any further changes to libunwind as long as win64 in general is handled correctly. https://reviews.llvm.org/D39632 Files: docs/index.rst Index: docs/index.rst

[PATCH] D39534: [libunwind] Add ifdefs around ELF specific parts of UnwindRegisters*.S for ARM

mstorsjo added a comment. In https://reviews.llvm.org/D39534#915935, @jroelofs wrote: > In https://reviews.llvm.org/D39534#915920, @mstorsjo wrote: > > > In https://reviews.llvm.org/D39534#915916, @compnerd wrote: > > > > > Very well, if thats the current implementation in the AsmParser, thats >

<    5   6   7   8   9   10   11   12   13   >