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

mstorsjo added a comment. In MSVC, these ones seem to be declared in intrin.h, not in the arm64intr.h subheader, so to match closely perhaps we should declare them there as well? The test, arm64-microsoft-intrinsics.c, doesn't actually include intrin.h nor arm64intr.h, so this test doesn't actu

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo abandoned this revision. mstorsjo added a comment. This isn't needed now any longer, when https://reviews.llvm.org/D50917 has landed. Repository: rC Clang https://reviews.llvm.org/D43184 ___ cfe-commits mailing list cfe-commits@lists.ll

[PATCH] D51382: [MinGW] Don't mark external variables as DSO local

mstorsjo created this revision. mstorsjo added reviewers: rnk, pcc. Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local va

[PATCH] D51382: [MinGW] Don't mark external variables as DSO local

mstorsjo added inline comments. Comment at: lib/CodeGen/CodeGenModule.cpp:737 +// potentially could come from another DLL as DSO local. +if (GV->hasExternalLinkage() && GV->isDeclaration() && +isa(GV) && !GV->isThreadLocal()) rnk wrote: > I think

[PATCH] D51382: [MinGW] Don't mark external variables as DSO local

mstorsjo updated this revision to Diff 163033. mstorsjo added a comment. Changed the condition to GV->isDeclarationForLinker(), updated tests accordingly (weak_bar in CodeGen/dso-local-executable.c lost the dso_local flag) and added more tests in CodeGenCXX/dso-local-executable.cpp as requested.

[PATCH] D51382: [MinGW] Don't mark external variables as DSO local

mstorsjo added inline comments. Comment at: test/CodeGen/dso-local-executable.c:14 +// MINGW-DAG: @bar = external global i32 +// MINGW-DAG: @weak_bar = extern_weak global i32 +// MINGW-DAG: declare dso_local void @foo() rnk wrote: > I take it that was a side effe

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

mstorsjo created this revision. mstorsjo added reviewers: manojgupta, chandlerc, beanz. Herald added subscribers: aheejin, sbc100, dberris, srhines. Herald added a reviewer: javed.absar. This avoids a libtool issue (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866), where libtool fails to pic

[PATCH] D51382: [MinGW] Don't mark external variables as DSO local

This revision was automatically updated to reflect the committed changes. Closed by commit rC340941: [MinGW] Don't mark external variables as DSO local (authored by mstorsjo, committed by ). Repository: rC Clang https://reviews.llvm.org/D51382 Files: lib/CodeGen/CodeGenModule.cpp test/Cod

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

mstorsjo added a comment. In https://reviews.llvm.org/D51440#1217839, @manojgupta wrote: > Just a minor comment regarding test cases: Since you are adding both -L/path/ > and -l, the test cases should be updated to check for the -L/path/ > argument as well. I guess I could do that, although

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

mstorsjo added a comment. In https://reviews.llvm.org/D51440#1218817, @phosek wrote: > What about other compiler-rt runtimes? Shouldn't we use the same approach for > those? Yes, I guess so. > In case of multiarch runtime layout, we already add >

[PATCH] D51530: [libunwind] Fix existing code for SEH on ARM to compile correctly

mstorsjo created this revision. mstorsjo added reviewers: cdavis5x, rnk. Herald added a reviewer: javed.absar. Herald added subscribers: chrib, kristof.beyls. Even though SEH for ARM is incomplete, make what code already exists at least compile correctly. The _LIBUNWIND_CURSOR_SIZE wasn't correc

[PATCH] D51530: [libunwind] Fix existing code for SEH on ARM to compile correctly

This revision was automatically updated to reflect the committed changes. Closed by commit rL341217: Fix existing code for SEH on ARM to compile correctly (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://reviews.llvm.org/D

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

mstorsjo added a comment. In https://reviews.llvm.org/D51440#1220925, @phosek wrote: > In https://reviews.llvm.org/D51440#1218859, @mstorsjo wrote: > > > I'll see if I can get to looking at that sometime soon. I had this patch > > lying around as an attempt to work around the libtool issue in >

[PATCH] D51644: [CMake] Remove variable reference that isn't used.

mstorsjo added inline comments. Comment at: src/CMakeLists.txt:54 # Generate library list. -set(libraries ${LIBUNWINDCXX_ABI_LIBRARIES}) +set(libraries) append_if(libraries LIBUNWIND_HAS_C_LIB c) Is there any point in this line at all now, or can it be removed

[PATCH] D51644: [CMake] Remove variable reference that isn't used.

mstorsjo accepted this revision. mstorsjo added inline comments. This revision is now accepted and ready to land. Comment at: src/CMakeLists.txt:54 # Generate library list. -set(libraries ${LIBUNWINDCXX_ABI_LIBRARIES}) +set(libraries) append_if(libraries LIBUNWIND_HAS_C_LIB c)

[PATCH] D51645: [CMake] Don't use -rtlib=compiler-rt with -nodefaultlibs.

mstorsjo added a subscriber: beanz. mstorsjo added a comment. Sounds sensible to me, although it might be good with a second opinion I think. @beanz? Repository: rUNW libunwind https://reviews.llvm.org/D51645 ___ cfe-commits mailing list cfe-com

[PATCH] D49638: [libcxxabi] Implement a GCC compatible SEH unwinding personality, __gxx_personality_seh0

mstorsjo created this revision. mstorsjo added reviewers: compnerd, smeenai, rnk, zturner, majnemer, EricWF. Herald added subscribers: ldionne, chrib. This allows handling SEH based exceptions, with unwind functions provided by libgcc. Repository: rCXXA libc++abi https://reviews.llvm.org/D49

[PATCH] D49638: [libcxxabi] Implement a GCC compatible SEH unwinding personality, __gxx_personality_seh0

This revision was automatically updated to reflect the committed changes. Closed by commit rL337754: Implement a GCC compatible SEH unwinding personality, __gxx_personality_seh0 (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: htt

[PATCH] D49770: [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structs

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. This seems to be another case of all other arches being the same while x86_32 is different. The thumb case (with same actual code as x86_64) has a comment about a corner case where this do

[PATCH] D49782: [libcxx] [windows] Fix warning about comparing ints of different signs

mstorsjo created this revision. mstorsjo added reviewers: pirama, pcc, compnerd, srhines. Herald added a reviewer: EricWF. Herald added a subscriber: ldionne. This fixes a warning like this: warning: comparison of integers of different signs: 'std::__1::__libcpp_tls_key' (aka 'long') and '

[PATCH] D49782: [libcxx] [windows] Fix warning about comparing ints of different signs

This revision was automatically updated to reflect the committed changes. Closed by commit rL337946: [windows] Fix warning about comparing ints of different signs (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://reviews.ll

[PATCH] D49770: [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structs

mstorsjo accepted this revision. mstorsjo added a comment. LGTM. Should the same tweak also be done for arm/thumb? Repository: rC Clang https://reviews.llvm.org/D49770 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/

[PATCH] D50135: [libunwind] [CMake] Allow building standalone without any llvm-config available

mstorsjo created this revision. mstorsjo added reviewers: phosek, beanz, compnerd, smeenai. Herald added subscribers: chrib, mgorny. This is the same as libcxxabi/libcxx do. Repository: rUNW libunwind https://reviews.llvm.org/D50135 Files: CMakeLists.txt Index: CMakeLists.txt ===

[PATCH] D49922: [P0936R0] add [[clang::lifetimebound]] attribute

mstorsjo added a comment. This change made clang to start trigger failed asserts for me (although they seem to not be reproducible with all compilers building clang), see https://bugs.llvm.org/show_bug.cgi?id=38421 for full description. Repository: rC Clang https://reviews.llvm.org/D49922

[PATCH] D50199: [MinGW] Predefine UNICODE if -municode is specified during compilation

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd, pcc, pirama. Repository: rC Clang https://reviews.llvm.org/D50199 Files: include/clang/Basic/LangOptions.def include/clang/Driver/Options.td lib/Basic/Targets.cpp lib/Driver/ToolChains/Clang.cpp lib/Frontend/Com

[PATCH] D50199: [MinGW] Predefine UNICODE if -municode is specified during compilation

mstorsjo added a comment. In https://reviews.llvm.org/D50199#1186164, @rnk wrote: > Does this do anything other than -DUNICODE? Maybe just translate it at the > driver level and skip the -cc1 flag? Yes, that also works. Initially I looked at where to place that in lib/Driver/ToolChains/MinGW.

[PATCH] D50199: [MinGW] Predefine UNICODE if -municode is specified during compilation

mstorsjo updated this revision to Diff 158827. mstorsjo added a comment. Simplified the patch to just handle the flag within the driver, without making it a flag to cc1. https://reviews.llvm.org/D50199 Files: lib/Driver/ToolChains/Clang.cpp test/Driver/mingw.cpp Index: test/Driver/mingw.

[PATCH] D50135: [libunwind] [CMake] Allow building standalone without any llvm-config available

mstorsjo added inline comments. Comment at: CMakeLists.txt:363 -add_subdirectory(test) +if (EXISTS ${LLVM_CMAKE_PATH}) + add_subdirectory(test) phosek wrote: > libcxx seems to be using a different condition: `IS_DIRECTORY > "${CMAKE_CURRENT_SOURCE_DIR}/test"`

[PATCH] D50199: [MinGW] Predefine UNICODE if -municode is specified during compilation

mstorsjo added a comment. In https://reviews.llvm.org/D50199#1186282, @cdavis5x wrote: > I actually believe this is supposed to have one other effect: it sets the > entry point to `wmainCRTStartup()`/`wWinMainCRTStartup()`, making the user > entry point `wmain()`/`wWinMain()`, which take wide a

[PATCH] D50135: [libunwind] [CMake] Allow building standalone without any llvm-config available

This revision was automatically updated to reflect the committed changes. Closed by commit rL338819: [CMake] Allow building standalone without any llvm-config available (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://revi

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo created this revision. mstorsjo added reviewers: rnk, majnemer, smeenai, compnerd. The first member of the type info structs/objects is a pointer to the vtable of the type info class. If the standard C++ library that provides this vtable is linked as a DLL, this field of the struct need

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1005281, @smeenai wrote: > FYI, binutils auto-import actually creates a fake IAT entry rather than using > a dynamic initializer. I think it's actually a pretty cute trick. > http://blog.omega-prime.co.uk/2011/07/04/everything-you-nev

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1005258, @rnk wrote: > Do you think we should do something like local vftables for itanium instead? > Can we assume all methods in the vtable will be exported by the DLL exporting > the class? Will this actually ever be needed for o

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1009355, @rnk wrote: > The Qt bug is interesting, but I think we're doing the right thing here. C++ > doesn't define any semantics for partially initialized objects. It's unclear > if clang or GCC's way of doing things is better or no

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. Ping @rnk Repository: rC Clang https://reviews.llvm.org/D43184 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

mstorsjo created this revision. mstorsjo added reviewers: compnerd, rnk, majnemer. When targeting GNU/MinGW for i386, the size of the "long double" data type is 12 bytes (while it is 8 bytes in MSVC). When building with -mms-bitfields to have struct layouts match MSVC, data types are laid out in

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

mstorsjo updated this revision to Diff 135813. mstorsjo added a comment. Asserting that non power of 2 only occurs in gnu mode. https://reviews.llvm.org/D43734 Files: lib/AST/RecordLayoutBuilder.cpp test/CodeGen/mingw-long-double.c Index: test/CodeGen/mingw-long-double.c =

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

mstorsjo added inline comments. Comment at: lib/AST/RecordLayoutBuilder.cpp:1755 CharUnits TypeSize = Context.getTypeSizeInChars(BTy); -if (TypeSize > FieldAlign) +if (TypeSize > FieldAlign && +llvm::isPowerOf2_64(TypeSize.getQuantity()))

[PATCH] D34475: [RFC] [AArch64] Add support for __builtin_ms_va_list on aarch64

mstorsjo created this revision. Herald added subscribers: kristof.beyls, javed.absar, rengolin, aemerson. This behaves mostly the same as __builtin_ms_va_list on x86_64; a va_list on windows on aarch64 is a single pointer. In order to signal the kind of va_list to llvm for handling of va_start,

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

mstorsjo added inline comments. Comment at: include/__libunwind_config.h:46 +# define _LIBUNWIND_CURSOR_SIZE 148 +# define _LIBUNWIND_HIGHEST_DWARF_REGISTER 110 # elif defined(__ppc__) Don't hardcode a number here; add a define `_LIBUNWIND_HIGHEST_DWARF_REGIS

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

mstorsjo added a comment. No further comments from my side, but it'd be good if @compnerd could have a look as well. https://reviews.llvm.org/D41386 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listi

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

This revision was automatically updated to reflect the committed changes. Closed by commit rL321667: [PPC64] Port to ppc64le - initial version (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D41386?vs=127516&id=128445#toc Repository: rL LLVM https://

[PATCH] D41386: [libunwind][PPC64] Port to ppc64le - initial version

mstorsjo added a comment. In https://reviews.llvm.org/D41386#966187, @timshen wrote: > The static_assert on line 1189 fails with the following build on x86: > > cmake -GNinja -DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON > -DLLVM_PATH=$PATH_TO_LLVM $PATH_TO_LIBUNWIND && ninja libunwind.a > > > It s

[PATCH] D41711: [docs] Mention support for Windows/ARM64 in the release notes

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd, mgrang. Herald added subscribers: kristof.beyls, aemerson. Repository: rC Clang https://reviews.llvm.org/D41711 Files: docs/ReleaseNotes.rst Index: docs/ReleaseNotes.rst ===

[PATCH] D41711: [docs] Mention support for Windows/ARM64 in the release notes

This revision was automatically updated to reflect the committed changes. Closed by commit rL321788: [docs] Mention support for Windows/ARM64 in the release notes (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D41711?vs=128555&id=128596#toc Repository:

[PATCH] D41764: [libcxx] [cmake] Add a config option LIBCXX_HAS_WIN32_THREADS for enforcing win32 threads

mstorsjo created this revision. mstorsjo added reviewers: compnerd, EricWF. Herald added a subscriber: mgorny. This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Repository: rCXX libc++ ht

[PATCH] D41764: [libcxx] [cmake] Add a config option LIBCXX_HAS_WIN32_THREADS for enforcing win32 threads

mstorsjo added a comment. In https://reviews.llvm.org/D41764#968318, @smeenai wrote: > I think `LIBCXX_HAS_WIN32_THREAD_API` would be more consistent with the > existing configuration define names? That sounds good to me too. I can update the patch later, or before committing if it's otherwis

[PATCH] D41764: [libcxx] [cmake] Add a config option LIBCXX_HAS_WIN32_THREADS for enforcing win32 threads

This revision was automatically updated to reflect the committed changes. Closed by commit rL321896: [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32… (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D41764?vs=128734&id=128786#

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

This revision was automatically updated to reflect the committed changes. Closed by commit rL326173: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://revi

[PATCH] D43811: [MinGW, CrossWindows] Allow passing -static together with -shared

mstorsjo created this revision. mstorsjo added reviewers: compnerd, smeenai, rnk. In these combinations, link a DLL as usual, but pass -Bstatic instead of -Bdynamic to indicate prefering static libraries. Repository: rC Clang https://reviews.llvm.org/D43811 Files: lib/Driver/ToolChains/Cr

[PATCH] D43811: [MinGW, CrossWindows] Allow passing -static together with -shared

mstorsjo added a comment. In https://reviews.llvm.org/D43811#1020847, @rnk wrote: > This means, link the CRT and other default libraries statically, but give me > a DLL, right? Just confirming. Exactly - for all libraries linked where you have the choice of both dynamic and static, pick the s

[PATCH] D43811: [MinGW, CrossWindows] Allow passing -static together with -shared

This revision was automatically updated to reflect the committed changes. Closed by commit rC326235: [MinGW, CrossWindows] Allow passing -static together with -shared (authored by mstorsjo, committed by ). Repository: rL LLVM https://reviews.llvm.org/D43811 Files: lib/Driver/ToolChains/Cros

[PATCH] D43811: [MinGW, CrossWindows] Allow passing -static together with -shared

This revision was automatically updated to reflect the committed changes. Closed by commit rL326235: [MinGW, CrossWindows] Allow passing -static together with -shared (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.or

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

mstorsjo added inline comments. Comment at: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp:1758 + Context.getTargetInfo().getTriple().isWindowsGNUEnvironment()) && +"Non PowerOf2 size outside of GNU mode"); +if (TypeSize > FieldAlign &&

[PATCH] D43908: [RecordLayout] Only assert that fundamental type sizes are power of two on MSVC

mstorsjo created this revision. mstorsjo added reviewers: efriedma, compnerd. This fixes using the ms_struct attribute together with long double on e.g. x86-32 linux. Repository: rC Clang https://reviews.llvm.org/D43908 Files: lib/AST/RecordLayoutBuilder.cpp test/CodeGen/ms_struct-long-

[PATCH] D43908: [RecordLayout] Only assert that fundamental type sizes are power of two on MSVC

mstorsjo updated this revision to Diff 136471. mstorsjo edited the summary of this revision. mstorsjo added a comment. Added an error-by-default diagnostic (just like the existing warn_cxx_ms_struct) for this case, trigger it on all targets other than mingw (where the situation is quite likely t

[PATCH] D43908: [RecordLayout] Only assert that fundamental type sizes are power of two on MSVC

This revision was automatically updated to reflect the committed changes. Closed by commit rL326476: [RecordLayout] Only assert that fundamental type sizes are power of two on MSVC (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://r

[PATCH] D43965: [CodeGen] Force the backend to follow clang's EmulatedTLS flag

mstorsjo created this revision. mstorsjo added reviewers: chh, jyknight. Since LLVM r326341, this is needed for the backend to actually respect the EmulatedTLS flag that is set, otherwise it just uses the target default flag instead. Repository: rC Clang https://reviews.llvm.org/D43965 Fil

[PATCH] D43965: [CodeGen] Force the backend to follow clang's EmulatedTLS flag

mstorsjo added a comment. Ok, thanks. Yes, this should probably only set it if some of those flags are set here. FWIW, clang also has got a list of targets where emulated TLS is enabled by default - could this be omitted somehow, now that LLVM can handle that on its own? Repository: rC Cla

[PATCH] D43965: [Driver] Pass -f[no-]emulated-tls and set up ExplicitEmulatedTLS

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM (although I didn't test run it). https://reviews.llvm.org/D43965 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.ll

[PATCH] D43965: [Driver] Pass -f[no-]emulated-tls and set up ExplicitEmulatedTLS

mstorsjo added a comment. Tested on the case that was broken before, and seems to work fine. Thanks! https://reviews.llvm.org/D43965 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. Ping @rnk - let me reiterate the questions that are open: In https://reviews.llvm.org/D43184#1009355, @rnk wrote: > Here's a case where a local vtable would help: > > struct __declspec(dllimport) A { virtual void a(); }; > struct __declspec(dllimport) B { virtual vo

[PATCH] D43650: [ARM] Add ARMv8.2-A FP16 vector intrinsics

mstorsjo added a comment. This change broke building Qt for armv7, see PR36683 for details. https://reviews.llvm.org/D43650 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43650: [ARM] Add ARMv8.2-A FP16 vector intrinsics

mstorsjo added a comment. In https://reviews.llvm.org/D43650#1034009, @mstorsjo wrote: > This change broke building Qt for armv7, see PR36683 for details. Ping - any update on looking into this? Should we revert this change for now, until the breakage is handled? https://reviews.llvm.org/D43

[PATCH] D44493: [libunwind] Add a cmake option for disabling the use of the dynamic linker

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd. Herald added a subscriber: mgorny. On windows, the psapi function for querying the dynamic linker for loaded modules (EnumProcessModules) are unavailable when targeting the UWP/"Windows Store" api subsets. Such a build rel

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

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd. Previously, the __register_frame function supported registering an FDE for one individual function at a time. The function could also be used registering a full .eh_frame section of a module (which is how libgcc sets up unw

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

mstorsjo added inline comments. Comment at: src/UnwindCursor.hpp:53 unw_word_t fde, unw_word_t mh)); + static void iterateSections(std::function func); rnk wrote: > I'm concerned that std::function might introduc

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

mstorsjo updated this revision to Diff 138451. mstorsjo added a comment. Avoid using the C++ header. https://reviews.llvm.org/D44494 Files: src/UnwindCursor.hpp src/libunwind.cpp Index: src/libunwind.cpp === --- src/libunwind

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1038129, @rnk wrote: > In https://reviews.llvm.org/D43184#1031831, @mstorsjo wrote: > > > So in case this approach as my hacky PoC does is the only feasible way > > left, I obviously need to fix it up. Any directions and suggestions on

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. (Accidentally pressed submit too soon) This was my conclusion at some point as well - but there's also a few issues with that approach which makes me quite hesitant: - doing fixups in the code segment requires making it writable temporarily at runtime, which is disall

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1039278, @rnk wrote: > In https://reviews.llvm.org/D43184#1038396, @mstorsjo wrote: > > > (Accidentally pressed submit too soon) > > > > This was my conclusion at some point as well - but there's also a few > > issues with that approac

[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

mstorsjo added a comment. In https://reviews.llvm.org/D43184#1039385, @rnk wrote: > In https://reviews.llvm.org/D43184#1039354, @mstorsjo wrote: > > > Ok - I'll put it on the backburner, and maybe see if I'd try implementing > > the linker part of fixing unannotated data imports at some point. >

[PATCH] D44582: [Builtins] Fix calling long double math functions on x86_64 mingw

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd. On x86_64 mingw, long doubles are passed as arguments and returned as if they were a struct. For normal functions, this calling convention detail is handled within clang when generating the IR. When a math function is handl

[PATCH] D44582: [Builtins] Fix calling long double math functions on x86_64 mingw

mstorsjo added a comment. In https://reviews.llvm.org/D44582#1040578, @efriedma wrote: > Can we just fix the bug in the backend, rather than trying to hack around it > in clang? That'd obviously be ideal - but I don't know how easy that'd be (not familiar enough with that aspect of LLVM); if

[PATCH] D44582: [Builtins] Fix calling long double math functions on x86_64 mingw

mstorsjo added a comment. In https://reviews.llvm.org/D44582#1040643, @efriedma wrote: > The backend has code to generate SRet returns, which is used when > TargetLowering::CanLowerReturn returns false. Probably a tiny change to > X86CallingConv.td to use that codepath on Windows. Thanks, I

[PATCH] D44582: [Builtins] Fix calling long double math functions on x86_64 mingw

mstorsjo abandoned this revision. mstorsjo added a comment. Fixed the issue via https://reviews.llvm.org/D44592 instead, thanks @efriedma for the pointers! Repository: rC Clang https://reviews.llvm.org/D44582 ___ cfe-commits mailing list cfe-com

[PATCH] D38680: [libunwind] Fix handling of DW_CFA_GNU_args_size

mstorsjo accepted this revision. mstorsjo added a comment. Sounds sensible to me; I've tested the patch in the setup that showed the issue this original patch tried to fix, and it seems to work fine there. https://reviews.llvm.org/D38680 ___ cfe-co

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

mstorsjo added inline comments. Comment at: test/CodeGen/personality.c:10 -// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -D __SEH_EXCEPTIONS__ -fms-extensions -fexceptions -fblocks -fseh-exceptions -S -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-WIN-SEH -check

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, thanks! Comment at: test/CodeGenCXX/personality.cpp:9 -// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -fexceptions -fseh-exceptions -fcxx-exceptions -S -emit

[PATCH] D48132: [COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM Repository: rC Clang https://reviews.llvm.org/D48132 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cg

[PATCH] D48355: [libcxxabi] [CMake] Convert paths to the right form in standalone builds on Windows

mstorsjo created this revision. mstorsjo added reviewers: mgorny, compnerd. Herald added a reviewer: EricWF. The paths output from llvm-config --cmakedir and from clang --print-libgcc-file-name can contain backslashes, while CMake can't handle the paths in this form. This matches what compiler-

[PATCH] D48353: [libunwind] [CMake] Convert paths to the right form in standalone builds on Windows

mstorsjo created this revision. mstorsjo added reviewers: mgorny, compnerd. Herald added a subscriber: chrib. The paths output from llvm-config --cmakedir and from clang --print-libgcc-file-name can contain backslashes, while CMake can't handle the paths in this form. This matches what compiler

[PATCH] D48356: [libcxx] [CMake] Convert paths to the right form in standalone builds on Windows

mstorsjo created this revision. mstorsjo added reviewers: mgorny, compnerd. Herald added a reviewer: EricWF. The paths output from llvm-config --cmakedir and from clang --print-libgcc-file-name can contain backslashes, while CMake can't handle the paths in this form. This matches what compiler-

[PATCH] D48356: [libcxx] [CMake] Convert paths to the right form in standalone builds on Windows

mstorsjo added inline comments. Comment at: cmake/Modules/HandleCompilerRT.cmake:17 string(STRIP "${LIBRARY_FILE}" LIBRARY_FILE) + file(TO_CMAKE_PATH ${LIBRARY_FILE} LIBRARY_FILE) string(REPLACE "builtins" "${name}" LIBRARY_FILE "${LIBRARY_FILE}") smeenai

[PATCH] D48353: [libunwind] [CMake] Convert paths to the right form in standalone builds on Windows

This revision was automatically updated to reflect the committed changes. Closed by commit rL335169: [CMake] Convert paths to the right form in standalone builds on Windows (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://

[PATCH] D48355: [libcxxabi] [CMake] Convert paths to the right form in standalone builds on Windows

This revision was automatically updated to reflect the committed changes. Closed by commit rL335171: [CMake] Convert paths to the right form in standalone builds on Windows (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://

[PATCH] D48356: [libcxx] [CMake] Convert paths to the right form in standalone builds on Windows

This revision was automatically updated to reflect the committed changes. Closed by commit rL335172: [CMake] Convert paths to the right form in standalone builds on Windows (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://

[PATCH] D52990: [MinGW] Allow using ubsan

mstorsjo updated this revision to Diff 168848. mstorsjo added a comment. Relying on a linker pragma in sanitizers and mingw lib name logic in lld. https://reviews.llvm.org/D52990 Files: lib/CodeGen/TargetInfo.cpp test/Driver/fsanitize.c Index: test/Driver/fsanitize.c =

[PATCH] D53013: [MinGW] Support MinGW style library names for default library pragmas

mstorsjo added a comment. If relying on logic in lld, this one can be discarded. Repository: rC Clang https://reviews.llvm.org/D53013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi

[PATCH] D52990: [MinGW] Fix passing a sanitizer lib name as dependent lib

This revision was automatically updated to reflect the committed changes. Closed by commit rC344125: [MinGW] Fix passing a sanitizer lib name as dependent lib (authored by mstorsjo, committed by ). Repository: rC Clang https://reviews.llvm.org/D52990 Files: lib/CodeGen/TargetInfo.cpp test

[PATCH] D53013: [MinGW] Support MinGW style library names for default library pragmas

mstorsjo abandoned this revision. mstorsjo added a comment. Not needed as we placed this logic in lld, in https://reviews.llvm.org/D53017, for now. Repository: rC Clang https://reviews.llvm.org/D53013 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D53066: [RFC] [MinGW] Print paths with forward slashes in commands printed with -v

mstorsjo created this revision. mstorsjo added reviewers: rnk, smeenai, compnerd, phosek, rupprecht. libtool inspects the output of `$CC -v` to detect what object files and libraries are linked in by default. When clang is built as a native windows executable, all paths are formatted with backsl

[PATCH] D53195: [MinGW] Allow using LTO when lld is used as linker

mstorsjo created this revision. mstorsjo added reviewers: rnk, ruiu, smeenai, compnerd. Herald added subscribers: dexonsmith, inglorion. Repository: rC Clang https://reviews.llvm.org/D53195 Files: lib/Driver/ToolChains/MinGW.cpp lib/Driver/ToolChains/MinGW.h Index: lib/Driver/ToolChains/

[PATCH] D53195: [MinGW] Allow using LTO when lld is used as linker

mstorsjo updated this revision to Diff 169387. mstorsjo added a comment. Herald added subscribers: steven_wu, mehdi_amini. Added a minimal testcase. https://reviews.llvm.org/D53195 Files: lib/Driver/ToolChains/MinGW.cpp lib/Driver/ToolChains/MinGW.h test/Driver/mingw-lto.c Index: test/D

[PATCH] D53195: [MinGW] Allow using LTO when lld is used as linker

mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/MinGW.cpp:383 + Args.getLastArgValue(options::OPT_fuse_ld_EQ, CLANG_DEFAULT_LINKER) + .equals_lower("lld"); } rnk wrote: > I thought we supported putting paths in this option, but I

[PATCH] D53195: [MinGW] Allow using LTO when lld is used as linker

This revision was automatically updated to reflect the committed changes. Closed by commit rL344412: [MinGW] Allow using LTO when lld is used as linker (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D53195?vs=169

[PATCH] D53066: [RFC] [MinGW] Print paths with forward slashes in commands printed with -v

mstorsjo added a comment. Ping @rnk or others with good ideas Repository: rC Clang https://reviews.llvm.org/D53066 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53066: [RFC] [MinGW] Print paths with forward slashes in commands printed with -v

mstorsjo added inline comments. Comment at: lib/Driver/Job.cpp:104-105 + std::string Buf; + if (PathStyle == llvm::sys::path::Style::posix) { +Buf = llvm::sys::path::convert_to_slash(Arg); +Arg = Buf; rnk wrote: > This is blindly treating every argument

[PATCH] D53066: [RFC] [MinGW] Print paths with forward slashes in commands printed with -v

mstorsjo added inline comments. Comment at: lib/Driver/Job.cpp:104-105 + std::string Buf; + if (PathStyle == llvm::sys::path::Style::posix) { +Buf = llvm::sys::path::convert_to_slash(Arg); +Arg = Buf; rnk wrote: > mstorsjo wrote: > > rnk wrote: > > > Th

[PATCH] D53066: [RFC] [Driver] Use forward slashes in most linker arguments

mstorsjo updated this revision to Diff 169579. mstorsjo retitled this revision from "[RFC] [MinGW] Print paths with forward slashes in commands printed with -v" to "[RFC] [Driver] Use forward slashes in most linker arguments". mstorsjo edited the summary of this revision. mstorsjo added a comment

<    1   2   3   4   5   6   7   8   9   10   >