mstorsjo added a comment.
@cdavis5x I presume the fact that this one turned out tricky is blocking
submitting the SEH unwinding patch.
Would it be worth to rework that patch to just use the basic types just like
libunwind does today, e.g. having `_Unwind_GetRegionStart` return plain
mstorsjo added a comment.
In https://reviews.llvm.org/D50564#1206370, @cdavis5x wrote:
> In https://reviews.llvm.org/D50564#1206302, @kristina wrote:
>
> > I'm all for this change except the core issue is that you're using
> > libunwind as a shim around the actual unwinding API provided by
mstorsjo created this revision.
mstorsjo added reviewers: craig.topper, erichkeane, rnk.
If using a custom stack alignment, one is expected to make sure that all
callers provide such alignment, or realign the stack in all entry points (and
callbacks).
Despite this, the compiler can assume that
mstorsjo added inline comments.
Comment at: lib/CodeGen/CodeGenFunction.cpp:989
+CGM.getCodeGenOpts().StackAlignment)
+ Fn->addFnAttr("stackrealign");
+
erichkeane wrote:
> Is there not an attribute name for this already in LLVM? I guess I'm
>
mstorsjo added a comment.
Not much more comments from me. The implementation seems reasonable, and works
for one simple test I did (with an earlier revision of the patch at least), and
further refinement can happen in-tree I guess.
I'd like to have someone else (@rnk @compnerd?) give it a more
mstorsjo added a comment.
In MSVC, these ones seem to be declared in intrin.h, not in the arm64intr.h
subheader, so to match closely perhaps we should declare them there as well?
The test, arm64-microsoft-intrinsics.c, doesn't actually include intrin.h nor
arm64intr.h, so this test doesn't
This revision was automatically updated to reflect the committed changes.
Closed by commit rL340334: [CodeGen] Implicitly set stackrealign on the main
function, if custom stack… (authored by mstorsjo, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
mstorsjo created this revision.
mstorsjo added reviewers: rnk, pcc.
Since MinGW supports automatically importing external variables from DLLs even
without the DLLImport attribute, we shouldn't mark them as DSO local unless we
actually know them to be local for sure.
Keep marking thread local
mstorsjo added inline comments.
Comment at: lib/CodeGen/CodeGenModule.cpp:737
+// potentially could come from another DLL as DSO local.
+if (GV->hasExternalLinkage() && GV->isDeclaration() &&
+isa(GV) && !GV->isThreadLocal())
rnk wrote:
> I think
mstorsjo updated this revision to Diff 163033.
mstorsjo added a comment.
Changed the condition to GV->isDeclarationForLinker(), updated tests
accordingly (weak_bar in CodeGen/dso-local-executable.c lost the dso_local
flag) and added more tests in CodeGenCXX/dso-local-executable.cpp as
mstorsjo abandoned this revision.
mstorsjo added a comment.
This isn't needed now any longer, when https://reviews.llvm.org/D50917 has
landed.
Repository:
rC Clang
https://reviews.llvm.org/D43184
___
cfe-commits mailing list
mstorsjo added inline comments.
Comment at: src/Unwind-seh.cpp:163
+#ifdef __x86_64__
+unw_get_reg(, UNW_X86_64_RAX, );
+unw_get_reg(, UNW_X86_64_RDX, >private_[3]);
Without understanding the code flow completely - is there a risk that this
tries to use
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
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:
This revision was automatically updated to reflect the committed changes.
Closed by commit rL337754: Implement a GCC compatible SEH unwinding
personality, __gxx_personality_seh0 (authored by mstorsjo, committed by ).
Herald added subscribers: llvm-commits, christof.
Changed prior to commit:
mstorsjo created this revision.
mstorsjo added reviewers: compnerd, smeenai, rnk, zturner, majnemer, EricWF.
Herald added subscribers: ldionne, chrib.
This allows handling SEH based exceptions, with unwind functions provided by
libgcc.
Repository:
rCXXA libc++abi
mstorsjo accepted this revision.
mstorsjo added a comment.
This revision is now accepted and ready to land.
This seems to be another case of all other arches being the same while x86_32
is different. The thumb case (with same actual code as x86_64) has a comment
about a corner case where this
mstorsjo created this revision.
mstorsjo added reviewers: pirama, pcc, compnerd, srhines.
Herald added a reviewer: EricWF.
Herald added a subscriber: ldionne.
This fixes a warning like this:
warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and
This revision was automatically updated to reflect the committed changes.
Closed by commit rL337946: [windows] Fix warning about comparing ints of
different signs (authored by mstorsjo, committed by ).
Herald added subscribers: llvm-commits, christof.
Changed prior to commit:
mstorsjo created this revision.
mstorsjo added reviewers: manojgupta, chandlerc, beanz.
Herald added subscribers: aheejin, sbc100, dberris, srhines.
Herald added a reviewer: javed.absar.
This avoids a libtool issue
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866), where libtool fails to
This revision was automatically updated to reflect the committed changes.
Closed by commit rC340941: [MinGW] Dont mark external variables as DSO
local (authored by mstorsjo, committed by ).
Repository:
rC Clang
https://reviews.llvm.org/D51382
Files:
lib/CodeGen/CodeGenModule.cpp
mstorsjo added inline comments.
Comment at: test/CodeGen/dso-local-executable.c:14
+// MINGW-DAG: @bar = external global i32
+// MINGW-DAG: @weak_bar = extern_weak global i32
+// MINGW-DAG: declare dso_local void @foo()
rnk wrote:
> I take it that was a side
mstorsjo added a subscriber: beanz.
mstorsjo added a comment.
Sounds sensible to me, although it might be good with a second opinion I think.
@beanz?
Repository:
rUNW libunwind
https://reviews.llvm.org/D51645
___
cfe-commits mailing list
mstorsjo added inline comments.
Comment at: src/CMakeLists.txt:54
# Generate library list.
-set(libraries ${LIBUNWINDCXX_ABI_LIBRARIES})
+set(libraries)
append_if(libraries LIBUNWIND_HAS_C_LIB c)
Is there any point in this line at all now, or can it be removed
mstorsjo accepted this revision.
mstorsjo added inline comments.
This revision is now accepted and ready to land.
Comment at: src/CMakeLists.txt:54
# Generate library list.
-set(libraries ${LIBUNWINDCXX_ABI_LIBRARIES})
+set(libraries)
append_if(libraries LIBUNWIND_HAS_C_LIB c)
mstorsjo created this revision.
mstorsjo added reviewers: cdavis5x, rnk.
Herald added a reviewer: javed.absar.
Herald added subscribers: chrib, kristof.beyls.
Even though SEH for ARM is incomplete, make what code already exists at least
compile correctly.
The _LIBUNWIND_CURSOR_SIZE wasn't
mstorsjo added a comment.
In https://reviews.llvm.org/D51440#1218817, @phosek wrote:
> What about other compiler-rt runtimes? Shouldn't we use the same approach for
> those?
Yes, I guess so.
> In case of multiarch runtime layout, we already add
>
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
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=154773#toc
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:
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
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
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
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
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
mstorsjo added inline comments.
Comment at: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp:1758
+ Context.getTargetInfo().getTriple().isWindowsGNUEnvironment()) &&
+"Non PowerOf2 size outside of GNU mode");
+if (TypeSize > FieldAlign &&
mstorsjo created this revision.
mstorsjo added reviewers: efriedma, compnerd.
This fixes using the ms_struct attribute together with long double on e.g.
x86-32 linux.
Repository:
rC Clang
https://reviews.llvm.org/D43908
Files:
lib/AST/RecordLayoutBuilder.cpp
mstorsjo added a comment.
In https://reviews.llvm.org/D43811#1020847, @rnk wrote:
> This means, link the CRT and other default libraries statically, but give me
> a DLL, right? Just confirming.
Exactly - for all libraries linked where you have the choice of both dynamic
and static, pick the
This revision was automatically updated to reflect the committed changes.
Closed by commit rL326235: [MinGW, CrossWindows] Allow passing -static together
with -shared (authored by mstorsjo, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
This revision was automatically updated to reflect the committed changes.
Closed by commit rC326235: [MinGW, CrossWindows] Allow passing -static together
with -shared (authored by mstorsjo, committed by ).
Repository:
rL LLVM
https://reviews.llvm.org/D43811
Files:
mstorsjo updated this revision to Diff 136471.
mstorsjo edited the summary of this revision.
mstorsjo added a comment.
Added an error-by-default diagnostic (just like the existing
warn_cxx_ms_struct) for this case, trigger it on all targets other than mingw
(where the situation is quite likely
mstorsjo added a comment.
In https://reviews.llvm.org/D43650#1034009, @mstorsjo wrote:
> This change broke building Qt for armv7, see PR36683 for details.
Ping - any update on looking into this? Should we revert this change for now,
until the breakage is handled?
mstorsjo added a comment.
In https://reviews.llvm.org/D43184#1039385, @rnk wrote:
> In https://reviews.llvm.org/D43184#1039354, @mstorsjo wrote:
>
> > Ok - I'll put it on the backburner, and maybe see if I'd try implementing
> > the linker part of fixing unannotated data imports at some point.
mstorsjo added a comment.
In https://reviews.llvm.org/D43184#1039278, @rnk wrote:
> In https://reviews.llvm.org/D43184#1038396, @mstorsjo wrote:
>
> > (Accidentally pressed submit too soon)
> >
> > This was my conclusion at some point as well - but there's also a few
> > issues with that
mstorsjo added a comment.
Ping @rnk - let me reiterate the questions that are open:
In https://reviews.llvm.org/D43184#1009355, @rnk wrote:
> Here's a case where a local vtable would help:
>
> struct __declspec(dllimport) A { virtual void a(); };
> struct __declspec(dllimport) B { virtual
mstorsjo added a comment.
This change broke building Qt for armv7, see PR36683 for details.
https://reviews.llvm.org/D43650
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo added a comment.
(Accidentally pressed submit too soon)
This was my conclusion at some point as well - but there's also a few issues
with that approach which makes me quite hesitant:
- doing fixups in the code segment requires making it writable temporarily at
runtime, which is
mstorsjo added a comment.
In https://reviews.llvm.org/D43184#1038129, @rnk wrote:
> In https://reviews.llvm.org/D43184#1031831, @mstorsjo wrote:
>
> > So in case this approach as my hacky PoC does is the only feasible way
> > left, I obviously need to fix it up. Any directions and suggestions
mstorsjo added inline comments.
Comment at: src/UnwindCursor.hpp:53
unw_word_t fde, unw_word_t mh));
+ static void iterateSections(std::function func);
rnk wrote:
> I'm concerned that std::function might
mstorsjo updated this revision to Diff 138451.
mstorsjo added a comment.
Avoid using the C++ header.
https://reviews.llvm.org/D44494
Files:
src/UnwindCursor.hpp
src/libunwind.cpp
Index: src/libunwind.cpp
===
---
mstorsjo created this revision.
mstorsjo added reviewers: rnk, compnerd.
Previously, the __register_frame function supported registering an FDE for one
individual function at a time. The function could also be used registering a
full .eh_frame section of a module (which is how libgcc sets up
mstorsjo created this revision.
mstorsjo added reviewers: rnk, compnerd.
Herald added a subscriber: mgorny.
On windows, the psapi function for querying the dynamic linker for loaded
modules (EnumProcessModules) are unavailable when targeting the UWP/"Windows
Store" api subsets.
Such a build
mstorsjo created this revision.
mstorsjo added reviewers: chandlerc, martell, ismail, rnk, compnerd, mati865,
yaron.keren.
Previously it would only accept a string as a GCC version if it had either two
components and no suffix, or three components with an optional suffix.
Debian and ubuntu
mstorsjo created this revision.
mstorsjo added reviewers: martell, rnk, compnerd, mati865.
Herald added a reviewer: EricWF.
This makes it consistent with libstdc++ and the other default include
directories.
If these headers are found in both locations and one isn't a symlink to the
other, this
mstorsjo created this revision.
mstorsjo added reviewers: martell, rnk, compnerd, mati865, ismail, yaron.keren.
If found, prefer this over looking for a similar gcc later in the system path.
This implements what @martell suggested in https://reviews.llvm.org/D45152 in a
much neater way.
Tests
mstorsjo updated this revision to Diff 141909.
mstorsjo added a comment.
Fixed the hardcoded triplet suffix, previously I erroneously had a "-gcc"
suffix there.
https://reviews.llvm.org/D45504
Files:
lib/Driver/ToolChains/MinGW.cpp
lib/Driver/ToolChains/MinGW.h
Index:
mstorsjo added a comment.
In https://reviews.llvm.org/D45152#1057787, @martell wrote:
> @mstorsjo I would much prefer to detect the clang sysroot first and if that
> exists just ignore the gcc one.
> Most of the time clang and gcc will be in the same bin folder and in the
> case where the
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
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=142243#toc
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:
mstorsjo added inline comments.
Comment at: lib/Driver/ToolChains/MinGW.cpp:459
addSystemInclude(DriverArgs, CC1Args,
+ Base + Arch + llvm::sys::path::get_separator() +
+ "include" + llvm::sys::path::get_separator() +
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:
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
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
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.
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
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
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
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:
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:
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
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
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
mstorsjo updated this revision to Diff 140410.
mstorsjo edited the summary of this revision.
mstorsjo added a comment.
Herald added a subscriber: JDevlieghere.
Added and using a helper function `isCIE` to avoid using the error return path
from `decodeFDE`.
Technically, the decision between a
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote:
> This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about
> registering a single FDE (which libunwind's `__register_frame` currently
> does) vs registering a full `.eh_frame` section (which
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050803, @mstorsjo wrote:
> In https://reviews.llvm.org/D44494#1050797, @mstorsjo wrote:
>
> > This else clause isn't about `.eh_frame` vs `.eh_frame_hdr`, but about
> > registering a single FDE (which libunwind's `__register_frame`
mstorsjo added a comment.
In https://reviews.llvm.org/D44494#1050783, @compnerd wrote:
> I really don't like this approach. I think that we should introduce a
> different entry point for this behavior rather than saying that we go through
> the existing interface. Having a reference to the
mstorsjo added a subscriber: joerg.
mstorsjo added a comment.
Also, relating to this, @joerg mentioned on irc that one should rather use
`__register_frame_info_bases` instead of `__register_frame`. That function is a
bit tricky to call though, since it uses a libgcc internal struct `struct
mstorsjo added inline comments.
Comment at: include/clang/Driver/Options.td:1735
MetaVarName<"">, Flags<[CC1Option]>;
+def ignore_gcc : Joined<["--"], "ignore-gcc">, Flags<[DriverOption]>,
+ HelpText<"Don't look for gcc for finding a suitable sysroot">;
mstorsjo created this revision.
mstorsjo added reviewers: martell, compnerd, rnk, mati865, ismail, yaron.keren.
This avoids looking for a mingw gcc to use as sysroot, preferring the clang
installation itself over a similar gcc found in the path.
The option name, `--ignore-gcc`, might not be
mstorsjo added a comment.
In https://reviews.llvm.org/D45152#1055871, @rnk wrote:
> Seems reasonable, looks good.
Any opinion on the wording of the option name?
Repository:
rC Clang
https://reviews.llvm.org/D45152
___
cfe-commits mailing list
mstorsjo added a comment.
In https://reviews.llvm.org/D45152#1056134, @rnk wrote:
> In https://reviews.llvm.org/D45152#1056122, @mstorsjo wrote:
>
> > In https://reviews.llvm.org/D45152#1055871, @rnk wrote:
> >
> > > Seems reasonable, looks good.
> >
> >
> > Any opinion on the wording of the
mstorsjo added a comment.
In https://reviews.llvm.org/D44582#1040578, @efriedma wrote:
> Can we just fix the bug in the backend, rather than trying to hack around it
> in clang?
That'd obviously be ideal - but I don't know how easy that'd be (not familiar
enough with that aspect of LLVM); if
mstorsjo created this revision.
mstorsjo added reviewers: rnk, compnerd.
On x86_64 mingw, long doubles are passed as arguments and returned as if they
were a struct. For normal functions, this calling convention detail is handled
within clang when generating the IR. When a math function is
mstorsjo abandoned this revision.
mstorsjo added a comment.
Fixed the issue via https://reviews.llvm.org/D44592 instead, thanks @efriedma
for the pointers!
Repository:
rC Clang
https://reviews.llvm.org/D44582
___
cfe-commits mailing list
mstorsjo added a comment.
In https://reviews.llvm.org/D44582#1040643, @efriedma wrote:
> The backend has code to generate SRet returns, which is used when
> TargetLowering::CanLowerReturn returns false. Probably a tiny change to
> X86CallingConv.td to use that codepath on Windows.
Thanks, I
mstorsjo added a comment.
Tested on the case that was broken before, and seems to work fine. Thanks!
https://reviews.llvm.org/D43965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo added a comment.
Ok, thanks. Yes, this should probably only set it if some of those flags are
set here.
FWIW, clang also has got a list of targets where emulated TLS is enabled by
default - could this be omitted somehow, now that LLVM can handle that on its
own?
Repository:
rC
mstorsjo created this revision.
mstorsjo added reviewers: chh, jyknight.
Since LLVM r326341, this is needed for the backend to actually respect the
EmulatedTLS flag that is set, otherwise it just uses the target default flag
instead.
Repository:
rC Clang
https://reviews.llvm.org/D43965
mstorsjo accepted this revision.
mstorsjo added a comment.
This revision is now accepted and ready to land.
LGTM (although I didn't test run it).
https://reviews.llvm.org/D43965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
This revision was automatically updated to reflect the committed changes.
Closed by commit rL326476: [RecordLayout] Only assert that fundamental type
sizes are power of two on MSVC (authored by mstorsjo, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
mstorsjo created this revision.
mstorsjo added reviewers: compnerd, smeenai, rnk.
In these combinations, link a DLL as usual, but pass -Bstatic instead of
-Bdynamic to indicate prefering static libraries.
Repository:
rC Clang
https://reviews.llvm.org/D43811
Files:
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:
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:
mstorsjo created this revision.
mstorsjo added reviewers: mgorny, compnerd.
Herald added a subscriber: chrib.
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake can't handle the
paths in this form.
This matches what
mstorsjo created this revision.
mstorsjo added reviewers: mgorny, compnerd.
Herald added a reviewer: EricWF.
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake can't handle the
paths in this form.
This matches what
mstorsjo created this revision.
mstorsjo added reviewers: mgorny, compnerd.
Herald added a reviewer: EricWF.
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake can't handle the
paths in this form.
This matches what
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
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
mstorsjo added a comment.
Ping @rnk or others with good ideas
Repository:
rC Clang
https://reviews.llvm.org/D53066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
301 - 400 of 1206 matches
Mail list logo
