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

mstorsjo added a comment. In https://reviews.llvm.org/D39534#915938, @jroelofs wrote: > i.e. should this be keyed off of `__ARM_EABI__` instead? I'm not really sure. As I quoted earlier, the exact case for enabling these directives in the LLVM codebase right now is `(!IsMachO && !IsCOFF)`. We

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

mstorsjo added a comment. In https://reviews.llvm.org/D39631#915943, @craig.topper wrote: > Can we just add -Werror to test/CodeGen/3dnow-builtins.c to test this? That file actually already has got `-Werror` > I believe it should be throwing a warning currently. It doesn't. That test enable

[PATCH] D39631: [X86] Fix the spelling of 3dnow and 3dnowa in isValidFeatureName

mstorsjo updated this revision to Diff 121623. mstorsjo retitled this revision from "[X86] Add 3dnow and 3dnowa to the list of valid target features" to "[X86] Fix the spelling of 3dnow and 3dnowa in isValidFeatureName". mstorsjo edited the summary of this revision. mstorsjo added a comment. Upd

[PATCH] D39631: [X86] Fix the spelling of 3dnow and 3dnowa in isValidFeatureName

This revision was automatically updated to reflect the committed changes. Closed by commit rL317504: [X86] Add 3dnow and 3dnowa to the list of valid target features (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39631?vs=121623&id=121766#toc Repository: rL LLVM h

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

mstorsjo added a comment. In https://reviews.llvm.org/D38680#903203, @joerg wrote: > I've looked at this in some detail now. I'm not exactly sure yet why it is > broken. The patch seems quite wrong to me. DW_CFA_GNU_args_size should be > applied only when unwinding a call instruction and that r

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. In https://reviews.llvm.org/D39673#917506, @martell wrote: > @mstorsjo I think this should help with issues like having to set the default > for ARM to DWARF. > If you can set it at run time then it should be a lot easier to just set > that in the clang wrapper script

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. In https://reviews.llvm.org/D39673#917506, @martell wrote: > @mstorsjo I think this should help with issues like having to set the default > for ARM to DWARF. Btw, in addition to making setting `__SEH__` conditional, it should also instead set `__ARM_DWARF_EH__` on A

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. In https://reviews.llvm.org/D39673#917524, @martell wrote: > I mostly expect this to be useful where environment has builds all 3 versions > of the libunwind. where the library is named differently based on the eh > model. > e.g. `libunwind-sjlj.a` `libunwind-seh.a` a

[PATCH] D39918: [libunwind] Remove a FIXME about truncated section names

mstorsjo created this revision. Herald added a subscriber: aprantl. If the linker chose to store the full section name instead of truncating it, this field doesn't contain a truncated name, but an offset into the string table of the binary. The string table isn't loaded/mapped into memory during

[PATCH] D39918: [libunwind] Remove a FIXME about truncated section names

mstorsjo added a comment. In https://reviews.llvm.org/D39918#923059, @ruiu wrote: > I think this is the right thing to do, but I'd defer it to libunwind's owner > to approve the patch. Removing the comment that is? Yes, since it's probably impossible to implement. Do you have any suggestion o

[PATCH] D39918: [libunwind] Remove a FIXME about truncated section names

mstorsjo added a comment. In https://reviews.llvm.org/D39918#923070, @ruiu wrote: > Actually I don't have a strong opinion on that topic. It seems like just > truncating the section name to ".eh_fram" at the linker is good enough, but > how much important is the compatibility with GNU ld? It'

[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] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added inline comments. Comment at: lib/Frontend/InitPreprocessor.cpp:683 + if (LangOpts.SEHExceptions) +Builder.defineMacro("__SEH__"); Please define `__ARM_DWARF_EH__` if dwarf is enabled on arm, see D39533, as I commented earlier. (Sorry, I for

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL318383: [docs] Mention that dwarf unwinding should be supported on arm64/windows (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39632?vs=121601&id=123130#toc Repository: r

[PATCH] D39918: [libunwind] Remove a FIXME about truncated section names

mstorsjo added a comment. @rnk I guess this is ok now as https://reviews.llvm.org/D40025 is committed and done? https://reviews.llvm.org/D39918 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/c

[PATCH] D39918: [libunwind] Remove a FIXME about truncated section names

This revision was automatically updated to reflect the committed changes. Closed by commit rL318446: Remove a FIXME about truncated section names (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39918?vs=122498&id=123223#toc Repository: rL LLVM https://reviews.llvm

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

This revision was automatically updated to reflect the committed changes. Closed by commit rL318511: [MinGW] Define __ARM_DWARF_EH__ for MinGW/ARM (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D39533?vs=121244&id=123298#toc Repository: rL LLVM https://reviews.llv

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. https://reviews.llvm.org/D39533 was committed now, so before committing, make sure that the `__ARM_DWARF_EH__` (that was added in that commit) only gets set while dwarf is enabled (which now is the default for mingw/arm but not msvc/arm). Repository: rL LLVM https

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added inline comments. Comment at: lib/Frontend/InitPreprocessor.cpp:684 +else if (TI.getTriple().isThumb() || TI.getTriple().isARM()) + Builder.defineMacro("__ARM_DWARF_EH__"); + } Won't this start setting this define also on platforms where A

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. In https://reviews.llvm.org/D39673#929536, @martell wrote: > When doing that I noticed there is something really strange about the > existing macro defines. I assume they should only be defined when exceptions > is enabled. > This is by default in c++ mode of with -fe

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added inline comments. Comment at: lib/Frontend/InitPreprocessor.cpp:684 +else if (TI.getTriple().isThumb() || TI.getTriple().isARM()) + Builder.defineMacro("__ARM_DWARF_EH__"); + } martell wrote: > mstorsjo wrote: > > Won't this start setting

[PATCH] D40181: [libcxx] Allow to set locale on Windows.

mstorsjo added a comment. In https://reviews.llvm.org/D40181#930602, @EricWF wrote: > This LGTM. I would love if another party interested in Windows could review > it though. I can test this in a MinGW context and see if what it uses happens to be available there or not. https://reviews.llv

[PATCH] D40181: [libcxx] Allow to set locale on Windows.

mstorsjo added a comment. In order to make this work with MinGW (more or less), I had to change the `_LIBCPP_MSVCRT` into `_LIBCPP_MSVCRT_LIKE` both in `include/__locale` and in `include/__config` (where `_LIBCPP_LOCALE__L_EXTENSIONS` is defined). Normal mingw that uses msvcrt.dll doesn't have

[PATCH] D40285: [MS] AARCH64 cleanup default WIN macros

mstorsjo added a comment. > WIN32 and WIN64 are not real definitions they are typically defined by the > system headers, _WIN32 and _WIN64 are the compiler definitions. Almost. In MSVC, WIN32 and WIN64 are never defined by the compiler, neither by system headers. Project files created by the I

[PATCH] D40285: [MS] AARCH64 cleanup default WIN macros

mstorsjo added a comment. ... so in general I wouldn't mind doing a change like this, but I'd like to make it consistent on ARM, i386 and x86_64 at the same time in that case, instead of just changing aarch64. Repository: rL LLVM https://reviews.llvm.org/D40285 __

[PATCH] D40285: [MS] AARCH64 cleanup default WIN macros

mstorsjo added a comment. In https://reviews.llvm.org/D40285#931242, @martell wrote: > The easy one is to get rid of WIN64 because gcc doesn't even do that for > mingw. Yes it does, it behaves just the same as WIN32: $ x86_64-w64-mingw32-gcc -E -dM - < /dev/null | grep WIN64 #define _WIN6

[PATCH] D40285: [MINGW] normalize WIN32 macros

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM Comment at: test/Preprocessor/predefined-macros.c:200 +// CHECK-X86-WIN: #define _WIN32 1 +// CHECK-X86-WIN-NOT: #define _WIN64 1 +// CHECK-X86-WIN-NOT: #define WINN

[PATCH] D40285: [MINGW] normalize WIN32 macros

mstorsjo accepted this revision. mstorsjo added a comment. LGTM Repository: rL LLVM https://reviews.llvm.org/D40285 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39673: Toolchain: Normalize dwarf, sjlj and seh eh

mstorsjo added a comment. No objection from me about committing this now, although I have some minor comments (that possibly can be taken care of without reposting and re-reviewing). Still ok with @rnk? Comment at: lib/Frontend/InitPreprocessor.cpp:686 + else if ((TI.getTrip

[PATCH] D40323: [libcxx] Remove a broken win32 locale function redirection

mstorsjo created this revision. One can't replace vsscanf(_l) with a sscanf(_l) that doesn't take a va_list. This has been untouched since it was added in SVN r140728, so apparently it hasn't been used since. One reason for this mistake originally might have been that there was no _vsscanf_l un

[PATCH] D40323: [libcxx] Remove a broken win32 locale function redirection

This revision was automatically updated to reflect the committed changes. Closed by commit rL318810: Remove a broken win32 locale function redirection (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D40323?vs=123851&id=123852#toc Repository: rL LLVM https://reviews

[PATCH] D146165: docs: add some documentation on Windows SDK search

mstorsjo added a comment. Looks reasonable I guess - but I think it would be good to mention the env variables `INCLUDE` and `LIB` too, for alternative ways of finding the same things - even if it's not strictly the same as what this new section talks about. Repository: rG LLVM Github Monor

[PATCH] D146490: [Support] On Windows, ensure that UniqueID is really stable

mstorsjo added a comment. In D146490#4209495 , @aganea wrote: > Fair enough. There are several choices forward: either we mark the issue as > "Will Not Fix" or I can try only scoping this patch to only keep the handle > for network drives/paths. Any oth

[PATCH] D146764: [clang] Make predefined expressions string literals under -fms-extensions

mstorsjo added a comment. In D146764#4219278 , @hans wrote: > +mstorsjo is this okay for mingw mode too? I believe the current form of the patch is fine - i.e. disabled by default in mingw mode, but enabled if the extra MS language extensions are enable

[PATCH] D146908: [clang][MinGW] Add asan link flags before other libs and objects

mstorsjo added a comment. I tested this, and this does fix the repro from the linked issue. I wonder if we do want to move all of these before the app itself, or if it's enough to just move the reference to `asan_dynamic-.dll.a` earlier, and keep the rest as it was? Especially the whole-archive

[PATCH] D146908: [clang][MinGW] Add asan link flags before other libs and objects

mstorsjo added inline comments. Comment at: clang/test/Driver/mingw-sanitizers.c:1 -// RUN: %clang -target i686-windows-gnu %s -### -fsanitize=address 2>&1 | FileCheck --check-prefix=ASAN-I686 %s -// ASAN-I686: "{{.*}}libclang_rt.asan_dynamic-i386.dll.a" -// ASAN-I686: "{{[^"]*}

[PATCH] D146908: [clang][MinGW] Add asan link flags before other libs and objects

mstorsjo added inline comments. Comment at: clang/test/Driver/mingw-sanitizers.c:1 -// RUN: %clang -target i686-windows-gnu %s -### -fsanitize=address 2>&1 | FileCheck --check-prefix=ASAN-I686 %s -// ASAN-I686: "{{.*}}libclang_rt.asan_dynamic-i386.dll.a" -// ASAN-I686: "{{[^"]*}

[PATCH] D146908: [clang][MinGW] Add asan DLL lib before other libs and objects

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM overall. I wondered if the modified test runs correctly on Windows (any test that touches paths is prone to break) but I see that it seems to have run successfully on both Windows an

[PATCH] D146908: [clang][MinGW] Add asan DLL lib before other libs and objects

mstorsjo added inline comments. Comment at: clang/test/Driver/mingw-sanitizers.c:2 +// RUN: touch %t.a +// RUN: %clang -target i686-windows-gnu %s -### -fsanitize=address -lcomponent %/t.a 2>&1 | FileCheck --check-prefixes=ASAN-ALL,ASAN-I686 -DINPUT=%/t.a %s +// RUN: %clang -tar

[PATCH] D142224: [Support] Emulate SIGPIPE handling in raw_fd_ostream write for Windows

mstorsjo added inline comments. Comment at: llvm/lib/Support/Windows/Signals.inc:834 + int RetCode = (int)EP->ExceptionRecord->ExceptionCode; + if (RetCode == (0xE000 | EX_IOERR)) +return; erichkeane wrote: > aganea wrote: > > erichkeane wrote: > > > Th

[PATCH] D145007: Driver: introduce GNU spellings to control MSVC paths

mstorsjo added reviewers: akhuang, hans, thakis, zahen, pkasting. mstorsjo added a comment. Looks reasonable to me, adding a few others for opinions. Should we have some tests for this? I guess testing these is somewhat environment reliant though, so it's probably not so easy... Repository:

[PATCH] D145007: Driver: introduce GNU spellings to control MSVC paths

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. If others don't have anything to add on this matter, I guess this is fine. The new option names feel rather wordy and unwieldy (especially compared to the clang-cl forms they're aliases fo

[PATCH] D144651: [Serialization] Place command line defines in the correct file

mstorsjo added a reviewer: aaron.ballman. mstorsjo added a subscriber: aaron.ballman. mstorsjo added a comment. Adding @aaron.ballman as fallback Clang reviewer here. While I did touch code in the vicinity of this area recently, I'm not familiar enough with the whole area to take on reviewing it

[PATCH] D144006: [DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

mstorsjo added a comment. This change triggers failed asserts when compiling code for at least arm and aarch64. It is reproducible with this reduced testcase: $ cat repro.c typedef long long a; typedef int b(); int c, d; long e, f; short g, j; void *h; short i[]; char k; a l,

[PATCH] D152785: [COFF] Support -gsplit-dwarf for COFF on Windows

mstorsjo added a comment. In D152785#4438544 , @MaskRay wrote: > CodeView is the default debug info format for COFF. Perhaps `-gsplit-dwarf` > should be rejected when the default `-gcodeview` is used, with a test. IIRC some users do generate both CodeVi

[PATCH] D154070: [lld/COFF] Add /dwodir to enable DWARF fission with LTO

mstorsjo added a comment. No objection from me here, this seems straightforward. We should probably add a corresponding option in the lld mingw frontend too (as a separate patch later). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154070/new/ htt

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

mstorsjo added a comment. Is this a NFC change, as a preparation for a separate change? In that case, please add an NFC tag to the subject - if not, please explain (and test) the expected behaviour change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.

[PATCH] D151344: Reland "[CMake] Bumps minimum version to 3.20.0.

mstorsjo added inline comments. Comment at: libunwind/src/CMakeLists.txt:28-35 # See add_asm_sources() in compiler-rt for explanation of this workaround. # CMake doesn't work correctly with assembly on AIX. Workaround by compiling # as C files as well. if((APPLE AND CMAKE_V

[PATCH] D151620: [clang-repl] Fix REPL_EXTERNAL_VISIBILITY and building libclang-cpp.dll for MinGW configurations

mstorsjo created this revision. mstorsjo added reviewers: junaire, alvinhochun, mati865. Herald added a project: All. mstorsjo requested review of this revision. Herald added a subscriber: bd1976llvm. Herald added a project: clang. This fixes two issues that are observed after 5111286f06e1e10f2474

[PATCH] D151620: [clang-repl] Fix REPL_EXTERNAL_VISIBILITY and building libclang-cpp.dll for MinGW configurations

This revision was automatically updated to reflect the committed changes. Closed by commit rG592e935e115f: [clang-repl] Fix REPL_EXTERNAL_VISIBILITY and building libclang-cpp.dll for… (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.o

[PATCH] D151661: [clang] [test] Narrow down an MSVC specific behaviour to only not covever MinGW

mstorsjo created this revision. mstorsjo added reviewers: Endill, hans, aaron.ballman. Herald added a project: All. mstorsjo requested review of this revision. Herald added a project: clang. This uses the same logic as in c2b256a990590dc8b69930259650cfeb085add03

[PATCH] D151662: [clang] [test] Fix test failures due to -Wbuiltin-macro-redefined in MinGW mode

mstorsjo created this revision. mstorsjo added reviewers: john.brawn, aaron.ballman. Herald added a project: All. mstorsjo requested review of this revision. Herald added a project: clang. These tests undefine __declspec or __stdcall, both which are builtin macros in MinGW mode. Therefore, build t

[PATCH] D150646: [clang][X86] Add __cpuidex function to cpuid.h

mstorsjo added a comment. In D150646#4379543 , @glandium wrote: > There seem to still be two problems with this change, with mingw: > > - with `-fms-extensions`: > > echo '#include "cpuid.h"' | ./clang/bin/clang++ > --target=x86_64-w64-windows-gnu -xc+

[PATCH] D151661: [clang] [test] Narrow down an MSVC specific behaviour to only not covever MinGW

mstorsjo added a comment. In D151661#4379958 , @Endill wrote: > Thank you! > I've asked Aaron what is the best way to check for MSVC-like triple before > relanding this test. So today we both learned. Generally, the canonical way to check for it is `#if

[PATCH] D148723: [clang] Restrict Inline Builtin to non-static, non-odr linkage

mstorsjo added a comment. This causes failed asserts with `_FORTIFY_SOURCE` with the mingw-w64 headers. Here's a reduced reproducer: $ cat reduced.c typedef unsigned int size_t; void *memcpy(void *_Dst, const void *_Src, size_t _Size); extern __inline__ __attribute__((__always_inli

[PATCH] D144654: [Lex] Warn when defining or undefining any builtin macro

mstorsjo added a comment. FWIW, I've also run into noisy warnings caused by this, in a few places. D151662 fixes a bunch of clang's tests when run in MinGW configurations, and https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230526104837.20594-1-mar...@mart

[PATCH] D148723: [clang] Restrict Inline Builtin to non-static, non-odr linkage

mstorsjo added a comment. In D148723#4381414 , @serge-sans-paille wrote: > In D148723#4380165 , @mstorsjo > wrote: > >> This causes failed asserts with `_FORTIFY_SOURCE` with the mingw-w64 >> headers. Here's a

[PATCH] D151661: [clang] [test] Narrow down an MSVC specific behaviour to only not covever MinGW

This revision was automatically updated to reflect the committed changes. Closed by commit rG28b26b161c2f: [clang] [test] Narrow down an MSVC specific behaviour to only not covever MinGW (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D151741: [Lex] Only warn on defining or undefining language-defined builtins

mstorsjo added a comment. Thanks! +1 from me, this does clear up all the issues I've had - it supersedes D151662 and makes the external patch to avoid doing `-U__STRICT_ANSI__` unnecessary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION ht

[PATCH] D151783: [clang] Use the appropriate definition when checking FunctionDecl::isInlineBuiltinDeclaration

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM, thanks! I'm not familiar with the code in question to know whether this really is the right thing to do etc, but this fixes my testcase (both the reduced one and the full one). Re

[PATCH] D151662: [clang] [test] Fix test failures due to -Wbuiltin-macro-redefined in MinGW mode

mstorsjo abandoned this revision. mstorsjo added a comment. Superseded by D151741 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151662/new/ https://reviews.llvm.org/D151662 __

[PATCH] D148793: [clang-tidy] Implement an include-cleaner check.

mstorsjo added a comment. In D148793#4392788 , @mgorny wrote: > I'm getting completely incomprehensible build errors on Gentoo from this I'm also hitting this; it only seems to happen if building with `-DLLVM_LINK_LLVM_DYLIB=ON`. Repository: rG LLVM

[PATCH] D148793: [clang-tidy] Implement an include-cleaner check.

mstorsjo added a comment. In D148793#4393385 , @mgorny wrote: > My educated guess would be that `clangIncludeCleaner` is being linked via > `clang_target_link_libraries` while it's not part of `libclang-cpp`, so it > should go into regular `target_link_

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

mstorsjo created this revision. mstorsjo added reviewers: aaron.ballman, hans. Herald added a project: All. mstorsjo requested review of this revision. Herald added a project: clang. This fixes running tests with a toolchain that defaults to a MinGW target. Repository: rG LLVM Github Monorepo

[PATCH] D149999: [clang-tidy] [test] Narrow down a special case to MSVC mode

mstorsjo created this revision. mstorsjo added reviewers: alvinhochun, aaron.ballman, hans. Herald added subscribers: PiotrZSL, carlosgalvezp, xazax.hun. Herald added a project: All. mstorsjo requested review of this revision. Herald added a project: clang-tools-extra. For MinGW targets, size_t is

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG7f037e5645bd: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only… (authored by mstorsjo). Repository: rG LLVM Github M

[PATCH] D149999: [clang-tidy] [test] Narrow down a special case to MSVC mode

This revision was automatically updated to reflect the committed changes. Closed by commit rGb80febdf43d3: [clang-tidy] [test] Narrow down a special case to MSVC mode (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D14/new/

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

mstorsjo added a comment. In D149997#4331937 , @thakis wrote: > This broke check-clang on windows: http://45.33.8.238/win/78359/step_7.txt > > (The Driver/split-debug.c failure is something else and since fixed, but the > other two tests are due to this

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

mstorsjo added a subscriber: rnk. mstorsjo added a comment. So, the reason why this failed, is that when invoked as `%clang_cc1` in a MSVC/clang-cl style build, `_MSC_VER` isn't predefined, while `_WIN32` is. When invoked via the Clang driver instead of directly going at `-cc1`, `_MSC_VER` does

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

mstorsjo added a comment. In D149997#4338304 , @rnk wrote: > I think `_MSC_EXTENSIONS` will work, but it's kind of gross. `_MSC_VER` is > controlled by `-fms-compatibility-verson=`, which I think is off by default > or unset at the cc1 level: > https://

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

mstorsjo updated this revision to Diff 521781. mstorsjo added a comment. Updated to check for `defined(_WIN32) && !defined(__MINGW32__)`. It's a kinda ugly way of checking for an MSVC-like environment specifically (when the MSVC mode is the exception compared with the rest), but neither `_MSC_VE

[PATCH] D149997: [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

This revision was automatically updated to reflect the committed changes. Closed by commit rGc2b256a99059: Reapply [clang] [test] Narrow down MSVC specific behaviours from "any windows"… (authored by mstorsjo). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

mstorsjo added a comment. In D144509#4347562 , @glandium wrote: > FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c > is > causing problems on Windows compiler-rt for some reason I haven'

[PATCH] D144509: [CMake] Bumps minimum version to 3.20.0.

mstorsjo added a comment. In D144509#4349051 , @hans wrote: > In D144509#4347562 , @glandium > wrote: > >> FYI, 65429b9af6a2c99d340ab2dcddd41dab201f399c >>

[PATCH] D148751: [CMake] Add llvm-lib to Clang bootstrap dependency for LTO builds on Windows

mstorsjo added inline comments. Comment at: clang/CMakeLists.txt:616 -DDYLD_LIBRARY_PATH=${LLVM_LIBRARY_OUTPUT_INTDIR}) -elseif(NOT WIN32) +elseif(WIN32) + add_dependencies(clang-bootstrap-deps llvm-lib) I think I’d prefer to have the condit

[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

mstorsjo added a comment. FYI, I'm seeing occasional spurious build breakage from this change. The issue is that even if we've got `add_dependencies(clangAnalysisFlowSensitive clangAnalysisFlowSensitiveResources)`, it looks like `clangAnalysisFlowSensitiveResources` only is considered a depend

[PATCH] D146987: [Assignment Tracking] Enable by default

mstorsjo added a comment. I'm also running into issues due to this commit. Unfortunately, the issues don't seem to be entirely deterministic. They can be reproduced with https://martin.st/temp/python-preproc.c: $ clang -target i686-w64-mingw32 -c -g -O3 python-preproc.c Assertion failed: (!

[PATCH] D146987: [Assignment Tracking] Enable by default

mstorsjo added a comment. In D146987#4286797 , @jmorse wrote: > /me grumbles about all the world being a VAX, > > @mstorsjo I can't replicate the crash, but can replicate the valgrind > jump-on-uninitialized-value with a small reproducer [0] that doesn't

[PATCH] D149119: [CMake] Use llvm-nm to extract symbols for staged LTO builds on Windows

mstorsjo added a comment. In D149119#4298024 , @phosek wrote: > Supporting only a single tool and simplifying the script would be my > preference as well. I see that the script already supports `llvm-readobj`, do > we need the `llvm-nm` support in that

[PATCH] D148944: [clang][Driver] Fix crash with unsupported architectures in MinGW and CrossWindows.

mstorsjo added a comment. I think the code changes make sense; these are trivial to hit by a user, so they shouldn't be `llvm_unreachable`. Comment at: clang/test/Driver/unsupported-target-arch.c:33 +// RUN: FileCheck --input-file=%t.err --check-prefix=CHECK-NOARCH-CROSSWINDOW

[PATCH] D146490: [Support] On Windows, ensure that UniqueID is really stable

mstorsjo added a comment. In D146490#4307269 , @falhumai96 wrote: > I would like to follow up on this issue whether or not there has been an > update on it. There's no update currently; I think there's some amount of consensus that this approach, whil

[PATCH] D148944: [clang][Driver] Fix crash with unsupported architectures in MinGW and CrossWindows.

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. LGTM. If you don’t have commit access, please say your preferred git author name for the commit, i.e. `Real Name `. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION http

[PATCH] D148944: [clang][Driver] Fix crash with unsupported architectures in MinGW and CrossWindows.

mstorsjo added inline comments. Comment at: clang/test/Driver/unsupported-target-arch.c:33 +// RUN: FileCheck --input-file=%t.err --check-prefix=CHECK-NOARCH-CROSSWINDOWS %s +// CHECK-NOARCH-CROSSWINDOWS: error: unknown target triple 'noarch-unknown-windows-itanium', please use

[PATCH] D152318: [Fuchsia] Add llvm-strings to Fuchsia clang build

mstorsjo added a comment. FWIW, I'm curious about where you need `llvm-strings` in a MinGW setting. While it does match a GNU binutils tool, I'm kinda curious where it is needed. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152318/new/ https://re

[PATCH] D152318: [Fuchsia] Add llvm-strings to Fuchsia clang build

mstorsjo added a comment. In D152318#4402493 , @haowei wrote: > In D152318#4402234 , @mstorsjo > wrote: > >> FWIW, I'm curious about where you need `llvm-strings` in a MinGW setting. >> While it does match a GNU

[PATCH] D152856: [Driver] Allow warning for unclaimed TargetSpecific options

mstorsjo accepted this revision. mstorsjo added a comment. This revision is now accepted and ready to land. Looks great to me, thanks! (Didn't test it myself yet though.) Just one small nit. Comment at: llvm/include/llvm/Option/Arg.h:53 + /// This is used for generating an "a

[PATCH] D152856: [Driver] Allow warning for unclaimed TargetSpecific options

mstorsjo added inline comments. Comment at: llvm/include/llvm/Option/Arg.h:53 + /// This is used for generating an "argument unused" warning (without + /// clang::driver::options::TargetSpecific) or "unsupported option" error + /// (with TargetSpecific). MaskR

[PATCH] D131830: [OpenMP] Clang Support for taskwait nowait clause

mstorsjo added inline comments. Comment at: openmp/runtime/src/dllexports:348 __kmpc_omp_wait_deps243 +__kmpc_omp_taskwait_deps_51 292 __kmpc_cancel 244 This is missing a similar export of `_

[PATCH] D131830: [OpenMP] Clang Support for taskwait nowait clause

mstorsjo added a comment. In D131830#3985449 , @koops wrote: > Martin Storsjö (or anybody who works on windows) I have uploaded a new patch > which has __kmpc_omp_taskwait_51 in dllexports. Can you please check the > patch on windows? Thanks, now this

[PATCH] D131830: [OpenMP] Clang Support for taskwait nowait clause

mstorsjo added a comment. In D131830#3986436 , @koops wrote: >> (There seems to be another unrelated regression at the same time though, >> regarding the symbol __kmpc_fork_call_if.) > > I do not know about this regression. I have not touched this functi

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

mstorsjo updated this revision to Diff 105200. mstorsjo added a comment. Did a minor adjustment, to make sure a plain va_arg produces the right kind of output, when targeting windows directly (while the rest of the patch mostly is about supporting the MS ABI while targeting a different OS). ht

[PATCH] D35008: [AArch64] Produce the right kind of va_arg for windows

mstorsjo created this revision. Herald added subscribers: kristof.beyls, rengolin, aemerson. On windows on arm64, the va_list is a plain pointer. https://reviews.llvm.org/D35008 Files: lib/CodeGen/TargetInfo.cpp Index: lib/CodeGen/TargetInfo.cpp =

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

mstorsjo updated this revision to Diff 105254. mstorsjo edited the summary of this revision. mstorsjo added reviewers: mgrang, t.p.northover. mstorsjo added a comment. Split the patch into two; one for generic handling of va_arg for win/arm64, and one for using the same functionality while target

[PATCH] D35008: [AArch64] Produce the right kind of va_arg for windows

mstorsjo marked an inline comment as done. mstorsjo added inline comments. Comment at: lib/CodeGen/TargetInfo.cpp:4769 DarwinPCS }; efriedma wrote: > Can we extend ABIKind rather than adding a separate boolean? Sure. I was afraid there was a lot of chec

[PATCH] D35008: [AArch64] Produce the right kind of va_arg for windows

mstorsjo updated this revision to Diff 105392. mstorsjo marked an inline comment as done. mstorsjo added a comment. Herald added a subscriber: javed.absar. Added a testcase, using a different Kind instead of adding a separate bool. https://reviews.llvm.org/D35008 Files: lib/CodeGen/TargetInfo

[PATCH] D35008: [AArch64] Produce the right kind of va_arg for windows

mstorsjo added a comment. Ping - the dependency, https://reviews.llvm.org/D35006, has now been committed. https://reviews.llvm.org/D35008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm

[PATCH] D35008: [AArch64] Produce the right kind of va_arg for windows

This revision was automatically updated to reflect the committed changes. Closed by commit rL307933: [AArch64] Produce the right kind of va_arg for windows (authored by mstorsjo). Changed prior to commit: https://reviews.llvm.org/D35008?vs=105392&id=106471#toc Repository: rL LLVM https://re

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

mstorsjo updated this revision to Diff 106489. mstorsjo retitled this revision from "[RFC] [AArch64] Add support for __builtin_ms_va_list on aarch64" to "[AArch64] Add support for __builtin_ms_va_list on aarch64". mstorsjo edited the summary of this revision. mstorsjo added a comment. Added test

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

mstorsjo added inline comments. Comment at: include/clang/Basic/BuiltinsAArch64.def:65 +// Win64-compatible va_list functions +BUILTIN(__builtin_ms_va_start, "vc*&.", "nt") +BUILTIN(__builtin_ms_va_end, "vc*&", "n") rnk wrote: > I strongly suspect that Microsoft

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

mstorsjo updated this revision to Diff 106690. mstorsjo edited the summary of this revision. mstorsjo added a comment. Initial attempt at unifying the use of __builtin_ms_va_list and calling conventions between x86_64 and aarch64. This goes with the current (un-unified) version of https://review

<    6   7   8   9   10   11   12   13   >