[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) mstors

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

mstorsjo added inline comments. Comment at: lib/CodeGen/ItaniumCXXABI.cpp:2990-2993 + bool IsMinGW = + CGM.getContext().getTargetInfo().getTriple().getEnvironment() == + llvm::Triple::GNU && + CGM.getContext().getTargetInfo().getTriple().isOSWi

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL312224: [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37206?vs=113309&id=113367#toc Repository: rL

[PATCH] D37327: Reland r312224 - [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. The prev

[PATCH] D37327: Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW

This revision was automatically updated to reflect the committed changes. Closed by commit rL312306: Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data… (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37327?vs=113380&id=113511#toc Reposito

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

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

[PATCH] D37134: [libc++] Rerun ranlib manually after merging the static libraries

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

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

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

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL312498: Add MINGW_LIBRARIES to the linker flags (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37207?vs=112873&id=113787#toc Repository: rL LLVM https://reviews.llvm.org/

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo added a comment. Do you have any pointers on how to do it with CMake? https://reviews.llvm.org/D37133 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo added a comment. In https://reviews.llvm.org/D37133#860563, @compnerd wrote: > `$` should give you the `.o` or `.obj` > files used to construct the library. I guess that would only work if they're built all as part of the same CMake invocation? In the setup where I'm trying this (for

[PATCH] D37468: [libc++] Redirect strftime_l to the locale-ignorant strftime on mingw

mstorsjo created this revision. _strftime_l is only available in the numbered msvcrt versions (starting from msvcr80.dll). In the default configuration, mingw targets the unversioned msvcrt.dll - and there, _strftime_l is not available (not even on windows 10). If __MSVCRT_VERSION__ is set to a

[PATCH] D37468: [libc++] Redirect strftime_l to the locale-ignorant strftime on mingw

This revision was automatically updated to reflect the committed changes. Closed by commit rL312617: Redirect strftime_l to the locale-ignorant strftime on mingw (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37468?vs=113838&id=113956#toc Repository: rL LLVM http

[PATCH] D37530: [MinGW] Allow overriding which version of msvcrt to link to

mstorsjo created this revision. This allows linking to e.g. msvcr120.dll or ucrtbase.dll instead of the unversioned (and officially unsupported) msvcrt.dll. In GCC setups, this can be overridden by using custom spec files, but this isn't supported in clang. This is just an initial attempt at im

[PATCH] D37530: [MinGW] Allow overriding which version of msvcrt to link to

mstorsjo added a comment. In https://reviews.llvm.org/D37530#862644, @rnk wrote: > What do you think of letting people spell this as `-lmsvcrt120`? We could > forward those options and suppress our implicit addition of `-lmsvcrt` if we > see `-lmsvcr*` anywhere. That might work and would prob

[PATCH] D37530: [MinGW] Don't link -lmsvcrt if a different msvcrt version is to be linked

mstorsjo updated this revision to Diff 114429. mstorsjo retitled this revision from "[MinGW] Allow overriding which version of msvcrt to link to" to "[MinGW] Don't link -lmsvcrt if a different msvcrt version is to be linked". mstorsjo edited the summary of this revision. mstorsjo added a comment.

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo added a comment. Ping @EricWF, who added this script https://reviews.llvm.org/D37133 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37134: [libc++] Rerun ranlib manually after merging the static libraries

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

[PATCH] D37727: Driver: Remove custom MinGW linker detection

mstorsjo added a comment. I'm not sure I like this direction. In my setups, a build-time default isn't right since I'm using the same clang builds for both native-on-linux building (with the default `ld` as linker) and cross-building targeting windows (using `ldd`), and keeping the code that re

[PATCH] D37727: Driver: Remove custom MinGW linker detection

mstorsjo added a comment. Actually, after testing this a bit more and looking at it, I withdraw my earlier complaints - this does indeed seem to work fine with my test setup. The generic `TC.GetLinkerPath()` picks up `-fuse-ld=lld` correctly and converts it into `ld.lld` which should be equival

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

mstorsjo added a comment. Does this break things for current users of clang as a drop-in replacement for gcc in mingw setups, while using e.g. a gcc provided `libstdc++-6.dll`? OTOH, removing dllimport usually isn't too much of an issue - the calls go via thunks which is non-ideal and theoretic

[PATCH] D37727: Driver: Remove custom MinGW linker detection

mstorsjo added a comment. In https://reviews.llvm.org/D37727#867753, @martell wrote: > In https://reviews.llvm.org/D37727#867627, @mstorsjo wrote: > > > I'm not sure I like this direction. In my setups, a build-time default > > isn't right since I'm using the same clang builds for both native-on

[PATCH] D37727: Driver: Remove custom MinGW linker detection

mstorsjo added a comment. Looks good to me (but maybe someone else should approve it as well) Repository: rL LLVM https://reviews.llvm.org/D37727 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listin

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo added inline comments. Comment at: utils/merge_archives.py:121 files = glob.glob(os.path.join(temp_directory_root, '*.o')) if not files: EricWF wrote: > How about simply using `*.o*`? Sure, that would probably work as well. https://reviews.

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

mstorsjo updated this revision to Diff 114893. mstorsjo added a comment. Using `*.o*` instead of checking `*.obj` separately. https://reviews.llvm.org/D37133 Files: utils/merge_archives.py Index: utils/merge_archives.py === ---

[PATCH] D37134: [libc++] Rerun ranlib manually after merging the static libraries

mstorsjo added a comment. In https://reviews.llvm.org/D37134#868497, @EricWF wrote: > Ironically I think parts of this change should be moved into > `merge_archives.py`. > > > the ar used in merge_archives.py might not be the right one for the target > > OK, then we should modify `merge_archives

[PATCH] D37133: [libc++] Handle object files named *.obj in merge_archives.py

This revision was automatically updated to reflect the committed changes. Closed by commit rL313072: Handle object files named *.obj in merge_archives.py (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37133?vs=114893&id=114906#toc Repository: rL LLVM https://revi

[PATCH] D37134: [libc++] Use CMAKE_AR for merging static libraries

mstorsjo updated this revision to Diff 114907. mstorsjo retitled this revision from "[libc++] Rerun ranlib manually after merging the static libraries" to "[libc++] Use CMAKE_AR for merging static libraries". mstorsjo edited the summary of this revision. https://reviews.llvm.org/D37134 Files:

[PATCH] D37134: [libc++] Use CMAKE_AR for merging static libraries

mstorsjo updated this revision to Diff 114908. mstorsjo added a comment. The previous patch actually lacked the 's' option that the summary talked about https://reviews.llvm.org/D37134 Files: lib/CMakeLists.txt utils/merge_archives.py Index: utils/merge_archives.py ===

[PATCH] D37134: [libc++] Use CMAKE_AR for merging static libraries

This revision was automatically updated to reflect the committed changes. Closed by commit rL313122: Use CMAKE_AR instead of the system default 'ar' for merging static libraries (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D37134?vs=114908&id=114981#toc Repository:

[PATCH] D62435: Add Attribute NoThrow as an Exception Specifier Type

mstorsjo added a comment. This change broke compiling Qt on MinGW, see https://bugs.llvm.org/show_bug.cgi?id=42089. Trivially reproducible by trying to compile a snippet that looks like this: class Foo { public: __attribute__((nothrow)) void __attribute__((__stdcall__)) Bar(); }

[PATCH] D62435: Add Attribute NoThrow as an Exception Specifier Type

mstorsjo added a comment. This change had another breaking effect as well, for the MinGW target. Code that implements a COM interface easily ends up overriding a `__declspec(nothrow)` function with a method that in most cases (at least in cases that follow the microsoft sample code) lacks the s

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

mstorsjo added a comment. This caused a regression when including mingw-w64 headers (in a case where they happen to include redundant/duplicate attribute specifications), triggering asserts. See https://bugs.llvm.org/show_bug.cgi?id=41852 for details. Repository: rC Clang CHANGES SINCE LAST

[PATCH] D62034: compiler-rt/lib/builtins: s/#include /#include /g to match proper case.

mstorsjo requested changes to this revision. mstorsjo added a comment. This revision now requires changes to proceed. No, I don't think this is a good idea. Like I said, the Windows SDK is not self-consistent, so you cannot use it on a case sensitive file system without other case insensitivity

[PATCH] D55698: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function

mstorsjo created this revision. mstorsjo added reviewers: rnk, majnemer. This matches what GCC does in these situations. This fixes compiling Qt in debug mode. In release mode, references to the vtable of this particular class ends up optimized away, but in debug mode, the compiler creates refe

[PATCH] D55698: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function

mstorsjo updated this revision to Diff 178222. mstorsjo added a comment. Fixed wrapping of the RUN line in the test. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55698/new/ https://reviews.llvm.org/D55698 Files: lib/Sema/SemaDeclCXX.cpp test/CodeGenCXX/dllexport-missing-key.cpp

[PATCH] D55698: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function

mstorsjo marked 2 inline comments as done. mstorsjo added inline comments. Comment at: lib/Sema/SemaDeclCXX.cpp:5754-5756 + if (ClassExported && + Context.getTargetInfo().getTriple().isWindowsGNUEnvironment()) +MarkVTableUsed(Class->getLocation(), Class, true);

[PATCH] D55698: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function

mstorsjo updated this revision to Diff 178275. mstorsjo added a comment. Moved the code to work on DelayedDllExportClasses instead, as suggested, which still works for the testcase. (I've yet to test that approach on a larger codebase though.) CHANGES SINCE LAST ACTION https://reviews.llvm.o

[PATCH] D55698: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function

This revision was automatically updated to reflect the committed changes. Closed by commit rL349256: [MinGW] Produce a vtable and RTTI for dllexported classes without a key function (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://

[PATCH] D55749: [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabled

mstorsjo created this revision. mstorsjo added reviewers: rnk, mgrang, ssijaric. Herald added subscribers: JDevlieghere, kristof.beyls, javed.absar, aprantl. For targets where SEH exceptions are used by default (on MinGW, only x86_64 so far), -munwind-tables are added automatically. If -fseh-exep

[PATCH] D55749: [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabled

mstorsjo marked 2 inline comments as done. mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/Clang.cpp:3929 + options::OPT_fno_asynchronous_unwind_tables, + (TC.IsUnwindTablesDefault(Args) || + (ExceptionArg && rnk wrote: > Can you

[PATCH] D55749: [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabled

mstorsjo updated this revision to Diff 178513. mstorsjo marked an inline comment as done. mstorsjo added a comment. Moved the added code to `toolchains::MinGW::IsUnwindTablesDefault`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55749/new/ https://reviews.llvm.org/D55749 Files: lib/

[PATCH] D55749: [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabled

This revision was automatically updated to reflect the committed changes. Closed by commit rC349452: [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabled (authored by mstorsjo, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55

[PATCH] D56044: [Driver] Support object files in addition to static and shared libraries in compiler-rt

mstorsjo added inline comments. Comment at: clang/lib/Driver/ToolChain.cpp:376 + case ToolChain::FT_Object: +Suffix = Triple.isOSWindows() ? ".obj" : ".o"; +break; For mingw (Triple.isWindowsGNUEnvironment) the natural extension is `.o` as well. So mayb

[PATCH] D56466: [CodeGen] Clarify comment about COFF common symbol alignment

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/D56466/new/ https://reviews.llvm.org/D56466 ___ cfe-commit

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo created this revision. mstorsjo added reviewers: dblaikie, pcc, efriedma. Herald added a project: clang. This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl. The previous behaviour of gnu_inline in C++, without the extern keyword, can be traced back to the origina

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo marked 2 inline comments as done. mstorsjo added inline comments. Comment at: lib/AST/Decl.cpp:3283 if (Context.getLangOpts().CPlusPlus) return false; nickdesaulniers wrote: > I would have thought the existing case here would handle your change

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo added a comment. In D67414#1668443 , @rsmith wrote: > Seems very surprising to me that the `gnu_inline` attribute has different > behavior in their C and C++ frontends. That said, it looks like it's a > behavior that they document; their documen

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo added a comment. In D67414#1668579 , @rsmith wrote: > OK. If this is causing compatibility pain in practice, following GCC here > seems reasonable. We should at least produce a warning on `gnu_inline` > without `extern` in C++ mode, though. Ye

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo updated this revision to Diff 220053. mstorsjo added a comment. Adapted based on the feedback so far, suggestions on naming and grouping the warning are welcome. The warning did trigger in an existing CUDA test as well - I'm not familiar with cuda and how it relates to other languages,

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/lib/AST/Decl.cpp:3334 /// For an inline function definition in C, or for a gnu_inline function /// in C++, determine whether the definition will be externally visible. ///

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: clang/test/SemaCUDA/gnu-inline.cu:8 void foo(); -inline __attribute__((gnu_inline)) void bar() { foo(); } +inline __attribute__((gnu_inline)) void bar() { foo(); } // expected-warning {{'gnu_

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

mstorsjo updated this revision to Diff 221086. mstorsjo added a comment. Updated the CUDA test based on the suggestion. @rsmith - What do you think of this version, the warning message, and the invariants for the `isInlineDefinitionExternallyVisible` method? CHANGES SINCE LAST ACTION https:/

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

This revision was automatically updated to reflect the committed changes. Closed by commit rL373078: [clang] [AST] Treat "inline gnu_inline" the same way as "extern inline… (authored by mstorsjo, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior

[PATCH] D65543: [Windows] Autolink with basenames and add libdir to libpath

mstorsjo added a comment. Another slightly related thread, regarding libs from the clang resource dir and how they are specified to the linker (regarding the builtins library): https://reviews.llvm.org/D51440 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.ll

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

mstorsjo added a comment. Ping, any comments on the change itself, or tips on how to create a test for it? https://reviews.llvm.org/D45504 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com

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

This revision was automatically updated to reflect the committed changes. Closed by commit rC329946: [MinGW] Look for libc++ headers in a triplet prefixed path as well (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D45500?vs=141894&id=142243#toc Reposi

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL329946: [MinGW] Look for libc++ headers in a triplet prefixed path as well (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.o

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

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

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

mstorsjo added a comment. In https://reviews.llvm.org/D45504#1070198, @rnk wrote: > Sorry, I skipped over the message and looked at the code, which seems pretty > straightforward. > > > Tests still are TBD, but posting this early to see if there's comments. > > (How do I easily do a test that c

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL330244: [MinGW] Look for a cross sysroot relative to the clang binary (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D4

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

mstorsjo abandoned this revision. mstorsjo added a comment. https://reviews.llvm.org/D45504 fixed the same issue in a better way. Repository: rC Clang https://reviews.llvm.org/D45152 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://

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

mstorsjo added a comment. In https://reviews.llvm.org/D45505#1074744, @chandlerc wrote: > Definitely need tests here. Do you have any suggestion on where to create them and what kind? Just a normal test with a fake directory tree, or some sort of unit test for the gcc version number matching

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

mstorsjo updated this revision to Diff 143558. mstorsjo retitled this revision from "[WIP] [GCC] Match a GCC version with a patch suffix without a third version component" to "[GCC] Match a GCC version with a patch suffix without a third version component". mstorsjo edited the summary of this rev

[PATCH] D45964: [Driver] Fix implicit config files from prefixed symlinks

mstorsjo created this revision. mstorsjo added reviewers: sepavloff, hfinkel, hans, rnk. If -no-canonical-prefixes isn't used, the clang executable name used is the one of the actual executable, not the name of the symlink that the user invoked. In these cases, the target prefix was overridden

[PATCH] D45985: [test] Add a testcase for MinGW sysroot detections from SVN r330244. NFC.

mstorsjo created this revision. mstorsjo added reviewers: rnk, compnerd, martell. After having a look at some similar tests, adding a proper testcase for this feature didn't turn out to be all that bad after all. Repository: rC Clang https://reviews.llvm.org/D45985 Files: test/Driver/ming

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

This revision was automatically updated to reflect the committed changes. Closed by commit rC330696: [GCC] Match a GCC version with a patch suffix without a third version component (authored by mstorsjo, committed by ). Repository: rC Clang https://reviews.llvm.org/D45505 Files: lib/Driver/

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

mstorsjo added a comment. Herald added a subscriber: chrib. Ping @joerg and @rnk - what's a sensible path forward with respect to this? @rnk thinks this change is correct, while @joerg disagrees, but hasn't had time to look into it yet. Is it acceptable to apply this now and then revert later o

[PATCH] D45964: [Driver] Fix implicit config files from prefixed symlinks

mstorsjo updated this revision to Diff 143794. mstorsjo added a comment. Added an isEmpty() method. Btw, did you see https://bugs.llvm.org/show_bug.cgi?id=37196? That one feels quite a bit more convolved so I don't really know (so far) how to approach fixing that. https://reviews.llvm.org/D45

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

mstorsjo added a comment. In https://reviews.llvm.org/D38680#1077262, @joerg wrote: > I'm back to the point where I can't reproduce the problem :( Can we start > providing an actual failing test case? It's annoying to debug a problem when > you can't reproduce it. My testcase that triggers th

[PATCH] D45985: [test] Add a testcase for MinGW sysroot detections from SVN r330244. NFC.

This revision was automatically updated to reflect the committed changes. Closed by commit rL330872: [test] Add a testcase for MinGW sysroot detections from SVN r330244. NFC. (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews

[PATCH] D45964: [Driver] Fix implicit config files from prefixed symlinks

This revision was automatically updated to reflect the committed changes. Closed by commit rL330871: [Driver] Fix implicit config files from prefixed symlinks (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D45964

[PATCH] D46286: [Driver] Don't warn about unused inputs in config files

mstorsjo created this revision. mstorsjo added reviewers: sepavloff, hans, rnk, hfinkel. This avoids warnings about unused linker parameters, just like other flags are ignored if they're from config files. Repository: rC Clang https://reviews.llvm.org/D46286 Files: lib/Driver/Driver.cpp

[PATCH] D46287: [Driver] Don't add -dwarf-column-info when using -gcodeview on non-msvc targets

mstorsjo created this revision. mstorsjo added reviewers: zturner, rnk, smeenai. Herald added subscribers: JDevlieghere, aprantl. -dwarf-column-info is omitted if -gcodeview is specified for msvc targets at the moment, but since -gcodeview is an option that can be specified for any target, there

[PATCH] D46286: [Driver] Don't warn about unused inputs in config files

mstorsjo updated this revision to Diff 144839. mstorsjo added a comment. In order not to break test/Driver/cl-pch.cpp (I hadn't run the full testsuite for this change before submitting the patch), I had to do another tweak, in order not to claim any input argument after `--`. Does it still sound

[PATCH] D46286: [Driver] Don't warn about unused inputs in config files

mstorsjo added a comment. @sepavloff - does the additional change to this one also look fine to you? https://reviews.llvm.org/D46286 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46286: [Driver] Don't warn about unused inputs in config files

This revision was automatically updated to reflect the committed changes. Closed by commit rC331504: [Driver] Don't warn about unused inputs in config files (authored by mstorsjo, committed by ). Repository: rC Clang https://reviews.llvm.org/D46286 Files: lib/Driver/Driver.cpp test/Driver

[PATCH] D46520: [Driver] Use -fuse-line-directives by default in MSVC mode

mstorsjo created this revision. mstorsjo added reviewers: rnk, hans, thakis. Don't use the GNU extension form of line markers in MSVC mode. Repository: rC Clang https://reviews.llvm.org/D46520 Files: lib/Driver/ToolChains/Clang.cpp test/Driver/cl-options.c Index: test/Driver/cl

[PATCH] D46520: [Driver] Use -fuse-line-directives by default in MSVC mode

mstorsjo added inline comments. Comment at: lib/Driver/ToolChains/Clang.cpp:4218 // -fno-use-line-directives is default. if (Args.hasFlag(options::OPT_fuse_line_directives, hans wrote: > The comment needs an update I think. Thanks, will change into "-fno-

[PATCH] D46520: [Driver] Use -fuse-line-directives by default in MSVC mode

This revision was automatically updated to reflect the committed changes. Closed by commit rC331666: [Driver] Use -fuse-line-directives by default in MSVC mode (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D46520?vs=145446&id=145528#toc Repository:

[PATCH] D46520: [Driver] Use -fuse-line-directives by default in MSVC mode

This revision was automatically updated to reflect the committed changes. Closed by commit rL331666: [Driver] Use -fuse-line-directives by default in MSVC mode (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D4652

[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

mstorsjo added a comment. FWIW, I'm also interested in this. I wasn't aware of the other ways of achieving this used by chromium, but although neat, I'd prefer something that doesn't require that kind of setup. As for performance - although I haven't studied how the code works - wouldn't it be

[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

mstorsjo added a comment. In https://reviews.llvm.org/D48626#1146282, @simon_tatham wrote: > Although, come to think of it, that's not good enough, because if you have > multiple directories on your include //path// then you expect a lot of > lookups to fail for reasons that have nothing to do

[PATCH] D48731: Configure ELAST for MinGW

mstorsjo accepted this revision. mstorsjo added a comment. LGTM, test built it and it seems to work fine. Repository: rCXX libc++ https://reviews.llvm.org/D48731 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bi

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

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

[PATCH] D49054: [MinGW] Treat any -lucrt* as replacing -lmsvcrt

mstorsjo created this revision. mstorsjo added reviewers: rnk, martell, compnerd, smeenai. Since SVN r314138, we check if the user has specified any particular alternative msvcrt/ucrt version, and skip the default -lmsvcrt in those cases. In addition to the existing names checked, we should also

[PATCH] D49059: [MinGW] Skip adding default win32 api libraries if -lwindowsapp is specified

mstorsjo created this revision. mstorsjo added reviewers: rnk, martell, compnerd, smeenai. In this setup, skip adding all the default windows import libraries, if linking to windowsapp (which replaces them, when targeting the windows store/UWP api subset). With GCC, the same is achieved by usin

[PATCH] D49059: [MinGW] Skip adding default win32 api libraries if -lwindowsapp is specified

mstorsjo added a comment. In https://reviews.llvm.org/D49059#1156453, @smeenai wrote: > LGTM, particularly given r314138. > > There are other umbrella libraries as well, e.g. OneCore and OneCoreUAP. Do > you care about those as well or just WindowsApp? I guess we would care, but there's nothin

[PATCH] D49054: [MinGW] Treat any -lucrt* as replacing -lmsvcrt

This revision was automatically updated to reflect the committed changes. Closed by commit rL336654: [MinGW] Treat any -lucrt* as replacing -lmsvcrt (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D49054?vs=154502

[PATCH] D49059: [MinGW] Skip adding default win32 api libraries if -lwindowsapp is specified

This revision was automatically updated to reflect the committed changes. Closed by commit rC336655: [MinGW] Skip adding default win32 api libraries if -lwindowsapp is specified (authored by mstorsjo, committed by ). Changed prior to commit: https://reviews.llvm.org/D49059?vs=154524&id=154773#t

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

mstorsjo abandoned this revision. mstorsjo added a comment. Herald added a subscriber: chrib. I choose not to commit this one after all, I managed to work around the issue with Windows Store apps in a much simpler way by providing a Windows Store compatible version of EnumProcessModules, see ht

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

mstorsjo abandoned this revision. mstorsjo added a comment. Herald added a subscriber: chrib. FWIW, I'm not going to put any more effort into this one at the moment, I managed to fix my use case in a much simpler way by providing a Windows Store compatible version of EnumProcessModules, see htt

[PATCH] D49354: [MinGW] Automatically mangle Windows-specific entry points as C

mstorsjo created this revision. mstorsjo added reviewers: majnemer, zturner, pcc, rnk, hans, compnerd, smeenai. This mangles entry points wmain, WinMain, wWinMain or DllMain as C functions, to match the ABI for these functions. We already did the same for these functions in MSVC mode, but we als

[PATCH] D49354: [MinGW] Automatically mangle Windows-specific entry points as C

This revision was automatically updated to reflect the committed changes. Closed by commit rL337146: [MinGW] Automatically mangle Windows-specific entry points as C (authored by mstorsjo, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/

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

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 rGcbd73574e43e: Reapply: [Driver] Use forward slashes in most linker arguments (authored by mstorsjo). Herald added a projec

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

mstorsjo added a comment. Super-nitpick: If you want to capitalize mingw, it's MinGW (minimalist gnu for windows) 😛 But as that's rather annoying to type, the all-lowercase version is quite fine as well. Comment at: clang/tools/libclang/CMakeLists.txt:71 + list(APPEND LIBS $

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

mstorsjo added inline comments. Comment at: clang/tools/libclang/CMakeLists.txt:71 + list(APPEND LIBS ${CMAKE_DL_LIBS}) endif() mati865 wrote: > thieta wrote: > > mstorsjo wrote: > > > If you say this is the same way it's done elsewhere, then sure - although

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

mstorsjo added inline comments. Comment at: llvm/cmake/modules/HandleLLVMOptions.cmake:967 CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) - elseif(LINKER_IS_LLD_LINK) + elseif(LINKER_IS_LLD_LINK AND NOT MINGW) append("/lldltocache:${PROJECT_BINARY_DIR}/lto.c

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

mstorsjo added a comment. In D80425#2052607 , @thieta wrote: > I am planning to revise this one now that we have thinlto-cache-dir option > landed here are my plans: > > - Keep the libdl patch as is (seems like there are no more comments on this). > - Rem

[PATCH] D80492: Avoid linking libdl unless needed

mstorsjo added a reviewer: beanz. mstorsjo added a subscriber: beanz. mstorsjo added a comment. I think this is ok, but adding @beanz who knows the cmake conventions better than me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80492/new/ https://

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