[PATCH] D53397: [MinGW] Link to correct openmp library

mstorsjo added a comment. Please add a testcase in test/Driver/, it looks like fopenmp.c there might be a good target to add a few lines in. Repository: rC Clang https://reviews.llvm.org/D53397 ___ cfe-commits mailing list cfe-commits@lists.llvm

[PATCH] D53397: [MinGW] Link to correct openmp library

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, I can commit it for you on Monday, after giving others a chance to comment. Repository: rC Clang https://reviews.llvm.org/D53397 __

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

mstorsjo added a comment. Ping @rnk 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] D53397: [MinGW] Link to correct openmp library

This revision was automatically updated to reflect the committed changes. Closed by commit rL345003: [MinGW] Link to correct openmp library (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Repository: rL LLVM https://reviews.llvm.org/D53397 Files: cfe/trunk/li

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL345004: [Driver] Use forward slashes in most linker arguments (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D53066?vs=

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

mstorsjo reopened this revision. mstorsjo added a comment. This revision is now accepted and ready to land. So, this failed due to some tests expecting to find the exact same path substring in different parts of the output (used with FileCheck captured variables): http://lab.llvm.org:8011/builde

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

mstorsjo updated this revision to Diff 170755. mstorsjo retitled this revision from "[RFC] [Driver] Use forward slashes in most linker arguments" to "[Driver] Use forward slashes in most linker arguments". mstorsjo added a comment. Converting more path instances, enough to fix the tests that fai

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

mstorsjo added inline comments. Comment at: lib/Driver/Driver.cpp:1013-1014 } + for (auto *Str : {&Dir, &InstalledDir, &SysRoot, &DyldPrefix, &ResourceDir}) +*Str = llvm::sys::path::convert_to_slash(*Str); rnk wrote: > zturner wrote: > > Is this going t

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

mstorsjo added a comment. In https://reviews.llvm.org/D53066#1274288, @zturner wrote: > It seems like some combination of checking the target triple, host triple, > and driver mode and putting the conversions behind those checks could work? Sounds ok, I can give it a shot. There's probably no

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

mstorsjo updated this revision to Diff 170989. mstorsjo added a comment. Changed so that we only rewrite paths if targeting a non-windows OS, or cygwin/mingw. Since convert_to_slash is a no-op when running on anything else than windows, this should hit exactly the cases where converting to forwa

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL345370: Reapply: [Driver] Use forward slashes in most linker arguments (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D53066?vs=170989&id=171253#toc Repository

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

mstorsjo reopened this revision. mstorsjo added a comment. This revision is now accepted and ready to land. Nope, still no really working properly with all the tests out there (I had only run the Driver subdirectory since I'm only testing in a very underpowered VM, and it had skipped the cuda/hi

[PATCH] D53684: [COFF, ARM64] Change setjmp for AArch64 Windows to use Intrinsic.sponentry

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. Looks good to me, once the dependency patch is done. Repository: rC Clang https://reviews.llvm.org/D53684 ___ cfe-commits mailing list cfe

[PATCH] D56905: [libunwind] [SjLj] Don't use __declspec(thread) in MinGW mode

mstorsjo created this revision. mstorsjo added reviewers: mclow.lists, EricWF, ldionne, compnerd, smeenai, rnk. Herald added a subscriber: libcxx-commits. mstorsjo edited the summary of this revision. GCC and Clang in MinGW mode don't support `__declspec(thread)`, which after expanding macros end

[PATCH] D56905: [libunwind] [SjLj] Don't use __declspec(thread) in MinGW mode

This revision was automatically updated to reflect the committed changes. Closed by commit rL351587: [SjLj] Don't use __declspec(thread) in MinGW mode (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://reviews.llvm.org/D5690

[PATCH] D56981: [libunwind] Enable LLVM_ENABLE_WARNINGS when building standalone out of tree

mstorsjo created this revision. mstorsjo added reviewers: mclow.lists, EricWF, ldionne. Herald added subscribers: libcxx-commits, mgorny. When built within the llvm runtimes directory, the runtimes CMakeLists.txt adds the same. This would have helped catch the issue behind D56905

[PATCH] D56982: [libunwind] Fix warnings about printf format strings

mstorsjo created this revision. mstorsjo added reviewers: mclow.lists, EricWF, ldionne. Herald added a subscriber: libcxx-commits. Either adjust the format string to use a more exact type, or add casts (for cases when printing pointers to structs/objects with a `%p` format specifier). Repositor

[PATCH] D56984: [libunwind] Silence warnings about unused parameters

mstorsjo created this revision. mstorsjo added reviewers: mclow.lists, EricWF, ldionne. Herald added a subscriber: libcxx-commits. Repository: rUNW libunwind https://reviews.llvm.org/D56984 Files: src/AddressSpace.hpp src/Unwind-seh.cpp src/UnwindCursor.hpp Index: src/UnwindCursor.hpp

[PATCH] D56985: [libunwind] Remove an unused variable

mstorsjo created this revision. mstorsjo added reviewers: mclow.lists, EricWF, ldionne. Herald added a subscriber: libcxx-commits. Repository: rUNW libunwind https://reviews.llvm.org/D56985 Files: src/Unwind-seh.cpp Index: src/Unwind-seh.cpp

[PATCH] D57001: [libunwind] Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__

mstorsjo created this revision. mstorsjo added reviewers: joerg, compnerd, mclow.lists, EricWF, ldionne. Herald added subscribers: libcxx-commits, kristof.beyls, krytarowski, javed.absar, aprantl. The existing typedef of unw_fpreg_t to uint64_t might work and be correct for the ARM_EHABI case, b

[PATCH] D57004: [docs] Add release notes for notable things I've contributed since last release

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans. Repository: rC Clang https://reviews.llvm.org/D57004 Files: docs/ReleaseNotes.rst Index: docs/ReleaseNotes.rst === --- docs/ReleaseNotes.rst +++ docs/Release

[PATCH] D57004: [docs] Add release notes for notable things I've contributed since last release

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: docs/ReleaseNotes.rst:190 +- For MinGW, clang now produces vtables and RTTI for dllexported classes + without key functions. + This comment doesn't really say much for the cas

[PATCH] D57004: [docs] Add release notes for notable things I've contributed since last release

This revision was automatically updated to reflect the committed changes. Closed by commit rL351872: [docs] Add release notes for notable things I've contributed since last release (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://r

[PATCH] D56984: [libunwind] Silence warnings about unused parameters

mstorsjo added a comment. In D56984#1366297 , @ldionne wrote: > LGTM, but would it make sense to have a macro like > `_LIBUNWIND_MAYBE_UNUSED(var)` instead? I guess some macro like that could be ok as well, although I think the `(void)var` is a rather

[PATCH] D56982: [libunwind] Fix warnings about printf format strings

This revision was automatically updated to reflect the committed changes. Closed by commit rL351876: Fix warnings about printf format strings (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://reviews.llvm.org/D56982?vs=1827

[PATCH] D56985: [libunwind] Remove an unused variable

This revision was automatically updated to reflect the committed changes. Closed by commit rUNW351878: Remove an unused variable (authored by mstorsjo, committed by ). Repository: rUNW libunwind CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56985/new/ https://reviews.llvm.org/D56985

[PATCH] D56981: [libunwind] Enable LLVM_ENABLE_WARNINGS when building standalone out of tree

This revision was automatically updated to reflect the committed changes. Closed by commit rL351875: Enable LLVM_ENABLE_WARNINGS when building standalone out of tree (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Changed prior to commit: https://reviews

[PATCH] D56984: [libunwind] Silence warnings about unused parameters

This revision was automatically updated to reflect the committed changes. Closed by commit rUNW351888: Silence warnings about unused parameters (authored by mstorsjo, committed by ). Repository: rUNW libunwind CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56984/new/ https://reviews.ll

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

mstorsjo added a comment. In D57209#1370608 , @rnk wrote: > and I don't think anyone has set up a continuous Windows ARM64 build with ToT > clang anywhere in the world yet. Not sure if it qualifies as a proper continuous Windows ARM64 build, but I buil

[PATCH] D57001: [libunwind] Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__

mstorsjo updated this revision to Diff 183776. mstorsjo added a comment. I had to update the signature of assembly functions which have got the concrete type of unw_fpreg_t in the mangled name. I chose to use void* for these functions, as I believe the same functions also are used for ARM EHABI,

[PATCH] D57001: [libunwind] Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__

This revision was automatically updated to reflect the committed changes. Closed by commit rUNW352461: Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__ (authored by mstorsjo, committed by ). Repository: rUNW libunwind CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57001/new/ h

[PATCH] D55229: [COFF, ARM64] Make -flto-visibility-public-std a driver and cc1 flag

mstorsjo added a comment. FWIW, I don't see how this patch is related to ARM64 (the subject/tag of the patch). Using that for the test probably is fine as it can use any architecture, although an x86 one probably would increase the chances of it getting run by everyone. I don't have much input

[PATCH] D60094: [MSVC] If unable to find link.exe relative to MSVC, look for link.exe in the path

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Herald added a project: clang. Previously, if this is encountered, clang will later just fail to execute link.exe. Or is this intentional, to avoid executing msys based link.exe accidentally, if the MSVC installation isn't found?

[PATCH] D60094: [MSVC] If unable to find link.exe relative to MSVC, look for link.exe in the path

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/MSVC.cpp:493 C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found); + linkPath = TC.GetProgramPath("link.exe"); +} rnk wrote: > amccart

[PATCH] D60094: [MSVC] If unable to find link.exe relative to MSVC, look for link.exe in the path

mstorsjo added a comment. FWIW, to add a bit of context about why (since normally, few people actually do link via the `(clang-)cl` interface); CMake does during some of its tests. I'd like to bring it to a point so that `CC=clang-cl CXX=clang-cl cmake ...` would work, while I currently either

[PATCH] D60417: [libunwind] Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)

mstorsjo added reviewers: ldionne, EricWF, mclow.lists. mstorsjo added a comment. Herald added a subscriber: dexonsmith. The change looks sensible to me, but should we maybe even skip the `#if` altogether? If the files uses unified syntax and can't be parsed in thumb mode otherwise, there's mayb

[PATCH] D60417: [libunwind] Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)

mstorsjo added a comment. In D60417#1459128 , @jeremfg wrote: > In D60417#1458778 , @mstorsjo wrote: > > > The change looks sensible to me, but should we maybe even skip the `#if` > > altogether? If the files uses

[PATCH] D60417: [libunwind] Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)

mstorsjo added a comment. In D60417#1459249 , @mstorsjo wrote: > Given that, the suggested form of this patch is indeed correct - sorry for > the noise. > > I can commit the patch for you, but I'd need approval by either of @EricWF, > @ldionne or @mclow.

[PATCH] D60094: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe

mstorsjo updated this revision to Diff 194926. mstorsjo retitled this revision from "[MSVC] If unable to find link.exe relative to MSVC, look for link.exe in the path" to "[MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe". mstorsjo edited the summary of

[PATCH] D60094: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe

mstorsjo updated this revision to Diff 194928. mstorsjo added a comment. Removed other local experiments from the patch context. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60094/new/ https://reviews.llvm.org/D60094 Files: lib/Driver/ToolChains/MSVC.cpp Index: lib/Driver/ToolChai

[PATCH] D60627: [MSVC] Use the correct casing of HostX64/HostX86

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Herald added a project: clang. If accessing the MSVC installation root directly on a case sensitive filesystem, these details matter. Repository: rC Clang https://reviews.llvm.org/D60627 Files: lib/Driver/ToolChains/MSVC.cpp

[PATCH] D60417: [libunwind] Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)

mstorsjo added a comment. In D60417#1464070 , @mstorsjo wrote: > In D60417#1459249 , @mstorsjo wrote: > > > Given that, the suggested form of this patch is indeed correct - sorry for > > the noise. > > > > I can co

[PATCH] D60417: [libunwind] Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax)

This revision was automatically updated to reflect the committed changes. Closed by commit rL358642: Add support for ARMv7-M architecture which uses the Thumb 2 ISA (unified syntax) (authored by mstorsjo, committed by ). Herald added subscribers: llvm-commits, christof. Herald added a project: LLV

[PATCH] D60627: [MSVC] Use the correct casing of HostX64/HostX86

This revision was automatically updated to reflect the committed changes. Closed by commit rL358662: [MSVC] Use the correct casing of HostX64/HostX86 (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https://re

[PATCH] D60094: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe

This revision was automatically updated to reflect the committed changes. Closed by commit rC358778: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe… (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D

[PATCH] D61118: [MinGW] Fix dllexport of explicit template instantiation

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, smeenai. Herald added a project: clang. Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instant

[PATCH] D61121: [Windows] Separate elements in -print-search-dirs with semicolons

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, smeenai, thakis. Herald added a project: clang. Path lists on windows should always be separated by semicolons, not colons. Reuse llvm::sys::EnvPathSeparator for this purpose (as that's also a path list that is separated in the

[PATCH] D61118: [MinGW] Fix dllexport of explicit template instantiation

mstorsjo updated this revision to Diff 196704. mstorsjo edited the summary of this revision. mstorsjo added a comment. Adjusted the patch to not warn if there is no previous declaration of the instantiation, allowing the dllexport attribute on the definition in that case. CHANGES SINCE LAST ACT

[PATCH] D61121: [Windows] Separate elements in -print-search-dirs with semicolons

This revision was automatically updated to reflect the committed changes. Closed by commit rL359233: [Windows] Separate elements in -print-search-dirs with semicolons (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to com

[PATCH] D61175: [MinGW] Don't let template instantiation declarations cover nested classes

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, smeenai. Herald added a project: clang. An explicit template instantiation declaration used to let callers assume both outer and nested classes instantiations were defined in a different translation unit. If the instantiation

[PATCH] D61176: [MinGW] Do dllexport inline methods in template instantiation

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, smeenai. Herald added a project: clang. Normally, in MinGW mode, inline methods aren't dllexported. However, in the case of a dllimported template instantiation, the inline methods aren't instantiated locally, but referenced fr

[PATCH] D61177: [MinGW] Always emit local typeinfo

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, smeenai. Herald added a project: clang. This makes sure that code built with headers for a statically linked libc++ also works when linking to the DLL version, when the DLL hasn't been built with --export-all-symbols. This mat

[PATCH] D61118: [MinGW] Fix dllexport of explicit template instantiation

This revision was automatically updated to reflect the committed changes. Closed by commit rL359285: [MinGW] Fix dllexport of explicit template instantiation (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: ht

[PATCH] D61175: [MinGW] Don't let template instantiation declarations cover nested classes

This revision was automatically updated to reflect the committed changes. Closed by commit rC359342: [MinGW] Don't let template instantiation declarations cover nested classes (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D6117

[PATCH] D61176: [MinGW] Do dllexport inline methods in template instantiation

This revision was automatically updated to reflect the committed changes. Closed by commit rC359343: [MinGW] Do dllexport inline methods in template instantiation (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61176/new/ https

[PATCH] D61177: [MinGW] Always emit local typeinfo

This revision was automatically updated to reflect the committed changes. Closed by commit rC359345: [MinGW] Always emit local typeinfo (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61177/new/ https://reviews.llvm.org/D61177

[PATCH] D61175: [MinGW] Don't let template instantiation declarations cover nested classes

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: lib/Sema/SemaTemplateInstantiate.cpp:2687-2689 if ((Context.getTargetInfo().getCXXABI().isMicrosoft() || - Context.getTargetInfo().getTriple().isWindowsItaniumEnvironment()) &

[PATCH] D61278: Simplify exclusion of nested classes from extern template instantiation, NFC

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61278/new/ https://reviews.llvm.org/D61278 ___

[PATCH] D61591: [MinGW] Use SEH by default on AArch64

mstorsjo created this revision. mstorsjo added reviewers: rnk, efriedma, mgrang, ssijaric. Herald added subscribers: kristof.beyls, javed.absar. Herald added a project: clang. The implementation of SEH is pretty mature at this point. Repository: rC Clang https://reviews.llvm.org/D61591 Files

[PATCH] D61592: [AArch64] Add __builtin_sponentry, for calling setjmp in MinGW

mstorsjo created this revision. mstorsjo added reviewers: rnk, efriedma, mgrang, ssijaric. Herald added subscribers: kristina, kristof.beyls, javed.absar. Herald added a project: clang. In MinGW, setjmp isn't expanded as a builtin in the compiler (like it is for MSVC), but manually hooked up as c

[PATCH] D61592: [AArch64] Add __builtin_sponentry, for calling setjmp in MinGW

This revision was automatically updated to reflect the committed changes. Closed by commit rC360082: [AArch64] Add __builtin_sponentry, for calling setjmp in MinGW (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61592/new/ http

[PATCH] D61591: [MinGW] Use SEH by default on AArch64

This revision was automatically updated to reflect the committed changes. Closed by commit rL360081: [MinGW] Use SEH by default on AArch64 (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.

[PATCH] D61615: [COFF] Use COFF stubs for extern_weak functions

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, it's nice if this mechanism comes in handy in other cases than the one it was originally made for. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews

[PATCH] D61615: [COFF] Use COFF stubs for extern_weak functions

mstorsjo added a comment. Ideally it'd be nice to have this consistent on arm and aarch64 as well, but it's not a blocker (it's not something I'm running into so far). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61615/new/ https://reviews.llvm.o

[PATCH] D61670: [RFC] [MinGW] Allow opting out from .refptr stubs

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Herald added a project: clang. In GCC, the .refptr stubs are only generated for x86_64, and only for code models medium and larger (and medium is the default for x86_64 since this was introduced). They can be omitted (for projects t

[PATCH] D61670: [RFC] [MinGW] Allow opting out from .refptr stubs

mstorsjo added a comment. Fair enough. On GCC, where the mingw x86_64 default code model is medium, switching it to small gave a small but not insignificant save in code size (around 9KB on a 1,3 MB DLL). On clang, where the default code model is small, getting rid of the extra refptrs didn't

[PATCH] D61670: [RFC] [MinGW] Allow opting out from .refptr stubs

mstorsjo added a comment. In D61670#1495535 , @rnk wrote: > Well, I'm curious what meaning GCC ascribes to a medium code model for COFF. > Do they generate code to allow PE images larger than 2GB, or is it more like > the ELF small code model, where they

[PATCH] D51657: [CMake] Link to compiler-rt if LIBUNWIND_USE_COMPILER_RT is ON.

mstorsjo added inline comments. Comment at: src/CMakeLists.txt:60 + append_if(libraries LIBUNWIND_HAS_GCC_S_LIB gcc_s) + list(APPEND libraries gcc) +endif() I'm a little suspicious of this line, of forcibly linking against libgcc here, even if we might not hav

[PATCH] D52533: [test] Use --sysroot instead of -B in print-multi-directory.c

mstorsjo created this revision. mstorsjo added reviewers: chrib, dyung. This avoids finding a similar matching GCC installation outside of the test directory tree in the surrounding environment, which would make the test fail. Repository: rC Clang https://reviews.llvm.org/D52533 Files: te

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Linking to ASan for MinGW is similar to MSVC, but MinGW always links the CRT dynamically, so there is only one of the MSVC cases to consider. When linking to a shared compiler runtime library on MinGW, the suffix of the import libr

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo added a comment. Also, I notice that ubsan also is built for windows, but in the MSVC toolchain, only asan (and libfuzzer) can be enabled, not ubsan. Is there something else missing for ubsan, or what's the matter with that one? Repository: rC Clang https://reviews.llvm.org/D52538

[PATCH] D52571: [Sema] Handle __va_start for Windows/ARM64 in the same way as for ARM

mstorsjo created this revision. mstorsjo added reviewers: dmajor, mgrang, ssijaric, rnk, compnerd. Herald added subscribers: chrib, kristof.beyls. This fixes PR39090. Repository: rC Clang https://reviews.llvm.org/D52571 Files: lib/Sema/SemaChecking.cpp test/SemaCXX/microsoft-varargs.cpp

[PATCH] D45045: [DebugInfo] Generate debug information for labels.

mstorsjo added a comment. The latest reland of this change still causes compilation crashes, see PR 39094. I'll revert this change for now to fix compilation again. Repository: rL LLVM https://reviews.llvm.org/D45045 ___ cfe-commits mailing list

[PATCH] D52571: [Sema] Handle __va_start for Windows/ARM64 in the same way as for ARM

This revision was automatically updated to reflect the committed changes. Closed by commit rL343184: [Sema] Handle __va_start for Windows/ARM64 in the same way as for ARM (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llv

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo added a comment. Ping @rnk in case you have time to look at it despite CppCon Repository: rC Clang https://reviews.llvm.org/D52538 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

[PATCH] D52538: [MinGW] Allow using ASan

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

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo added inline comments. Comment at: lib/Driver/ToolChain.cpp:370-373 + const char *Suffix = Shared ? (Triple.isWindowsGNUEnvironment() + ? ".dll.a" + : Triple.isOSWindows() ? ".lib" : ".so")

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo updated this revision to Diff 167817. mstorsjo added a comment. Clarified the comment about shared MSVCRT, moved handling of `.dll.a` into a separate condition afterwards. https://reviews.llvm.org/D52538 Files: lib/Driver/ToolChain.cpp lib/Driver/ToolChains/MinGW.cpp lib/Driver/

[PATCH] D52538: [MinGW] Allow using ASan

mstorsjo added a comment. In https://reviews.llvm.org/D52538#1251620, @rnk wrote: > Regarding ubsan, it probably works, I haven't tested it though. Ok, thanks. I guess ubsan doesn't need quite as intricate integration with the platform as asan does anyway. https://reviews.llvm.org/D52538

[PATCH] D52538: [MinGW] Allow using ASan

This revision was automatically updated to reflect the committed changes. Closed by commit rL343537: [MinGW] Allow using ASan (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D52538?vs=167817&id=167823#toc Reposit

[PATCH] D52533: [test] Use --sysroot instead of -B in print-multi-directory.c

mstorsjo added a comment. Ping @jroelofs or someone else willing to have a look Repository: rC Clang https://reviews.llvm.org/D52533 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[PATCH] D52533: [test] Use --sysroot instead of -B in print-multi-directory.c

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rC343702: [test] Use --sysroot instead of -B in print-multi-directory.c (authored by mstorsjo, committed by ). Changed prio

[PATCH] D52811: [COFF, ARM64] Add _InterlockedAdd intrinsic

mstorsjo added a comment. None of this seems to be ARM64 specific - if I read it correctly, this adds the _InterlockedAdd intrinsic for ARM and X64 as well. How come this hasn't been an issue for those targets up until now? Do those targets have any other code somewhere handling it, that might

[PATCH] D52838: [COFF, ARM64] Add __getReg intrinsic

mstorsjo added subscribers: efriedma, peter.smith. mstorsjo added a comment. In https://reviews.llvm.org/D52838#1253998, @mgrang wrote: > I have some questions about the behavior of getReg: > > __getReg ultimately invokes getRegisterByName in > http://llvm.org/doxygen/AArch64ISelLowering_8cpp_so

[PATCH] D52811: [COFF, ARM64] Add _InterlockedAdd intrinsic

mstorsjo added a comment. In https://reviews.llvm.org/D52811#1254162, @efriedma wrote: > > How come this hasn't been an issue for those targets up until now? > > MSVC doesn't define _InterlockedAdd for x64. Ok - but judging from the context here, this would make clang define it there - which p

[PATCH] D52990: [MinGW] Allow using ubsan

mstorsjo created this revision. mstorsjo added a reviewer: rnk. Turns out that ubsan actually already was supported for msvc mode as well; it just didn't require any code in lib/Driver/ToolChains/MSVC.cpp, Repository: rC Clang https://reviews.llvm.org/D52990 Files: lib/CodeGen/TargetInfo.

[PATCH] D52990: [MinGW] Allow using ubsan

mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/MinGW.cpp:266 + // directives in the object files, but the static library needs + // -lpsapi unless the sanitizer was built targeting >= win7. + CmdArgs.push_back("-lpsapi");

[PATCH] D52990: [MinGW] Allow using ubsan

mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/MinGW.cpp:266 + // directives in the object files, but the static library needs + // -lpsapi unless the sanitizer was built targeting >= win7. + CmdArgs.push_back("-lpsapi");

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

mstorsjo created this revision. mstorsjo added reviewers: rnk, smeenai. This assumes that the library is an import library for a system dll (named e.g. libkernel32.a) or a static library; it won't work for import libraries for normal user dlls named e.g. libfoo.dll.a). Since ld.bfd doesn't suppo

[PATCH] D57838: [clang-cl] support /Oy- on aarch64

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57838/new/ https://reviews.llvm.org/D57838 ___ cfe-commit

[PATCH] D57838: [clang-cl] support /Oy- on aarch64

This revision was automatically updated to reflect the committed changes. Closed by commit rC353402: [clang-cl] support /Oy- on aarch64 (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57838/new/ https://reviews.llvm.org/D57838

[PATCH] D58106: [compiler-rt] [profile] Provide lprofGetHostName for all windows environments

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd. Herald added subscribers: Sanitizers, llvm-commits, jdoerfert, dberris. Herald added projects: LLVM, Sanitizers. This function doesn't use anything MSVC specific but works fine for any `_WIN32` target. Repository: rCRT C

[PATCH] D58106: [compiler-rt] [profile] Provide lprofGetHostName for all windows environments

This revision was automatically updated to reflect the committed changes. Closed by commit rL353918: [profile] Provide lprofGetHostName for all windows environments (authored by mstorsjo, committed by ). Herald added a subscriber: delcypher. Changed prior to commit: https://reviews.llvm.org/D58

[PATCH] D58107: [MinGW] Add the profiling library when necessary

This revision was automatically updated to reflect the committed changes. Closed by commit rL353917: [MinGW] Add the profiling library when necessary (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https://re

[PATCH] D58107: [MinGW] Add the profiling library when necessary

mstorsjo added a comment. In D58107#1396063 , @davezarzycki wrote: > This change breaks building/testing the compiler with `CLANG_DEFAULT_LINKER` > set to `lld`. Was this intentional? What should people do if they want to use > `CLANG_DEFAULT_LINKER` an

[PATCH] D56850: [ASTMatchers][NFC] Add tests for assorted `CXXMemberCallExpr` matchers.

mstorsjo added a comment. This broke compilation with GCC 5.4 on Ubuntu 16.04: ../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:243: warning: missing terminating " character ../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:3: error: missing terminat

[PATCH] D37206: [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW

mstorsjo created this revision. This fixes cases where dynamic classes produced RTTI data with external linkage, producing linker errors about duplicate symbols. This touches code close to what was changed in SVN r244266, but this change doesn't break the tests added in that revision. I have t

[PATCH] D37207: [libc++] Add MINGW_LIBRARIES to the linker flags

mstorsjo created this revision. Herald added a subscriber: mgorny. This is essential when building with -nodefaultlibs. This is similar to what already is done in libcxxabi in SVN r302760. https://reviews.llvm.org/D37207 Files: lib/CMakeLists.txt Index: lib/CMakeLists.txt =

[PATCH] D37206: [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW

mstorsjo updated this revision to Diff 113309. mstorsjo added a comment. The previous diff lacked the extra context around the diff - fixed. https://reviews.llvm.org/D37206 Files: lib/CodeGen/ItaniumCXXABI.cpp test/CodeGenCXX/rtti-mingw64.cpp Index: test/CodeGenCXX/rtti-mingw64.cpp ==

[PATCH] D37206: [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW

mstorsjo added inline comments. Comment at: lib/CodeGen/ItaniumCXXABI.cpp:2994 + CGM.getContext().getTargetInfo().getTriple().isOSWindows(); + // MinGW always uses LinkOnceODRLinkage for type info. + if (RD->isDynamicClass() && !IsMinGW) Thanks

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