Hans,
I think this commit should be merged to the 7.0 release branch; the first
half of the GCC workaround made it in before the branch happened, but
there was another identical case missing.
// Martin
On Thu, 2 Aug 2018, Martin Storsjo via cfe-commits wrote:
Author: mstorsjo
Date: Thu Aug
On Thu, 2 Aug 2018, Richard Smith via cfe-commits wrote:
On Thu, 2 Aug 2018, 06:10 Martin Storsjö via Phabricator via cfe-commits,
wrote:
mstorsjo added a comment.
This change made clang to start trigger failed asserts for me
(although they seem to not be reproducible with al
On Tue, 5 Jun 2018, Reid Kleckner via cfe-commits wrote:
Author: rnk
Date: Mon Jun 4 18:33:40 2018
New Revision: 333978
URL: http://llvm.org/viewvc/llvm-project?rev=333978&view=rev
Log:
Reimplement the bittest intrinsic family as builtins with inline asm
We need to implement _interlockedbitte
On Thu, 7 Jun 2018, Craig Topper via cfe-commits wrote:
Author: ctopper
Date: Thu Jun 7 10:28:03 2018
New Revision: 334208
URL: http://llvm.org/viewvc/llvm-project?rev=334208&view=rev
Log:
[X86] Add back builtins for _mm_slli_si128/_mm_srli_si128 and similar
intrinsics.
We still lower them
It broke on the first commit and is broken even after all of them.
// Martin
On Fri, 15 Feb 2019, Yitzhak Mandelbaum wrote:
Was it the complete diff or one of the intermediate commits? I accidentally
committed the diff as a series of commits rather than one (squashed)
commit.
On Fri, Feb 15,
FWIW, this was fixed by SVN r354201. Thanks David!
// Martin
On Sat, 16 Feb 2019, Martin Storsjö via cfe-commits wrote:
It broke on the first commit and is broken even after all
of them.
// Martin
On Fri, 15 Feb 2019, Yitzhak Mandelbaum wrote:
Was it the complete diff or one of the
This broke building of Qt when using PCH. Selfcontained repro is a bit
hard to make though...
// Martin
On Tue, 4 Jun 2019, Richard Smith via cfe-commits wrote:
Author: rsmith
Date: Tue Jun 4 14:29:28 2019
New Revision: 362551
URL: http://llvm.org/viewvc/llvm-project?rev=362551&view=rev
Log
This change broke compiling Qt.
A repro case looks like this:
mkdir -p fake-qtincl/5.13.1/QtCore/private
touch fake-qtincl/5.13.1/QtCore/private/qglobal_p.h
touch fake-qtincl/QtCore
echo "#include " > qtincl.cpp
bin/clang++ -c qtincl.cpp -Ifake-qtincl -Ifake-qtincl/5.13.1
Previously this igno
Thanks for the fix, Qt does seem to build correctly now again.
// Martin
On Fri, 9 Aug 2019, Reid Kleckner wrote:
Let me know if the problem persists after r368475. Someone else filed
https://bugs.llvm.org/show_bug.cgi?id=42948 as well.
On Thu, Aug 8, 2019 at 11:34 PM Martin Storsjö wrote:
Hi Douglas,
Yes, I saw it - trying to look into it right now.
// Martin
On Wed, 18 Apr 2018, douglas.y...@sony.com wrote:
Hi Martin,
Your commit is causing a few test failures on the PS4 Windows bot, can you take
a look?
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-wind
Hi Douglas,
I wasn't able to reproducd the issue myself, but I think I know what the
issue was, and I committed a fix attempt.
// Martin
On Wed, 18 Apr 2018, Martin Storsjö via cfe-commits wrote:
Hi Douglas,
Yes, I saw it - trying to look into it right now.
// Martin
On Wed, 18 Apr
Hej Henrik,
On Thu, 19 Apr 2018, Henrik Gramner via cfe-commits wrote:
The force_align_arg_pointer attribute was using a hardcoded 16-byte
alignment value which in combination with -mstack-alignment=32 (or
larger) would produce a misaligned stack which could result in crashes
when accessing sta
Author: Tobias Hieta
Date: 2020-05-28T21:08:00+03:00
New Revision: 0073c293a401774ac96b4b3d27f05e13f379f98e
URL:
https://github.com/llvm/llvm-project/commit/0073c293a401774ac96b4b3d27f05e13f379f98e
DIFF:
https://github.com/llvm/llvm-project/commit/0073c293a401774ac96b4b3d27f05e13f379f98e.diff
Author: Martin Storsjö
Date: 2020-05-29T15:23:14+03:00
New Revision: ac1f7ab007e347dc4a542aa3415e6378289480f4
URL:
https://github.com/llvm/llvm-project/commit/ac1f7ab007e347dc4a542aa3415e6378289480f4
DIFF:
https://github.com/llvm/llvm-project/commit/ac1f7ab007e347dc4a542aa3415e6378289480f4.diff
Author: Mateusz Mikuła
Date: 2020-05-29T15:23:14+03:00
New Revision: ab4d02cf265982d4c03123d2f52b9d5ee8df575d
URL:
https://github.com/llvm/llvm-project/commit/ab4d02cf265982d4c03123d2f52b9d5ee8df575d
DIFF:
https://github.com/llvm/llvm-project/commit/ab4d02cf265982d4c03123d2f52b9d5ee8df575d.diff
Author: Tobias Hieta
Date: 2020-07-24T00:10:22+03:00
New Revision: a41af6e41e6fcf3e7030feaf24057cbe8291b748
URL:
https://github.com/llvm/llvm-project/commit/a41af6e41e6fcf3e7030feaf24057cbe8291b748
DIFF:
https://github.com/llvm/llvm-project/commit/a41af6e41e6fcf3e7030feaf24057cbe8291b748.diff
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: e3fd9dc9734c5775dc6824d0a839702e8d43e7f6
URL:
https://github.com/llvm/llvm-project/commit/e3fd9dc9734c5775dc6824d0a839702e8d43e7f6
DIFF:
https://github.com/llvm/llvm-project/commit/e3fd9dc9734c5775dc6824d0a839702e8d43e7f6.diff
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: beeed368b60252178f66ab117d8a96ecdc35f60e
URL:
https://github.com/llvm/llvm-project/commit/beeed368b60252178f66ab117d8a96ecdc35f60e
DIFF:
https://github.com/llvm/llvm-project/commit/beeed368b60252178f66ab117d8a96ecdc35f60e.diff
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: 7b3fe969927731c69ba4d8a428442e1e191f49b5
URL:
https://github.com/llvm/llvm-project/commit/7b3fe969927731c69ba4d8a428442e1e191f49b5
DIFF:
https://github.com/llvm/llvm-project/commit/7b3fe969927731c69ba4d8a428442e1e191f49b5.diff
Author: Cristian Adam
Date: 2020-04-25T20:19:17+03:00
New Revision: 6fb80d9383e415c35204b62569972f70ae7dcb0a
URL:
https://github.com/llvm/llvm-project/commit/6fb80d9383e415c35204b62569972f70ae7dcb0a
DIFF:
https://github.com/llvm/llvm-project/commit/6fb80d9383e415c35204b62569972f70ae7dcb0a.diff
Author: Martin Storsjö
Date: 2020-04-29T20:35:50+03:00
New Revision: a0e53de472c5b9538884f23eb8f47c3bc734b345
URL:
https://github.com/llvm/llvm-project/commit/a0e53de472c5b9538884f23eb8f47c3bc734b345
DIFF:
https://github.com/llvm/llvm-project/commit/a0e53de472c5b9538884f23eb8f47c3bc734b345.diff
On Sun, 9 Aug 2020, Richard Smith via cfe-commits wrote:
Author: Richard Smith
Date: 2020-08-09T23:22:26-07:00
New Revision: 617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9
URL:
https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9
DIFF:
https://github.com/llvm/llvm-p
On Tue, 11 Aug 2020, Richard Smith wrote:
On Tue, 11 Aug 2020 at 00:29, Martin Storsjö wrote:
On Sun, 9 Aug 2020, Richard Smith via cfe-commits wrote:
>
> Author: Richard Smith
> Date: 2020-08-09T23:22:26-07:00
> New Revision: 617007240cbfb97c8ccf6d61b0c4ca0bb62d4
Author: Martin Storsjö
Date: 2020-05-11T23:51:14+03:00
New Revision: 609ef948387ba40e3693c2bd693d82ca34dcdc02
URL:
https://github.com/llvm/llvm-project/commit/609ef948387ba40e3693c2bd693d82ca34dcdc02
DIFF:
https://github.com/llvm/llvm-project/commit/609ef948387ba40e3693c2bd693d82ca34dcdc02.diff
mstorsjo added inline comments.
Comment at: lib/Headers/intrin.h:504
@@ +503,3 @@
+_interlockedbittestandset_acq(long volatile *_BitBase, long _BitPos) {
+ long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_ACQUIRE);
+ return (_PrevVal >> _BitPos) & 1;
-
mstorsjo added a comment.
Thanks! Can you/someone commit it?
https://reviews.llvm.org/D24609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo updated the summary for this revision.
mstorsjo updated this revision to Diff 72025.
mstorsjo added a comment.
Rebased on top of the latest master
https://reviews.llvm.org/D24609
Files:
lib/Headers/intrin.h
Index: lib/Headers/intrin.h
mstorsjo added a comment.
Can someone commit this patch now after it has been rebased?
https://reviews.llvm.org/D24609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo added a comment.
Ping, can someone commit this one now?
https://reviews.llvm.org/D24609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo created this revision.
mstorsjo added a reviewer: majnemer.
mstorsjo added a subscriber: cfe-commits.
Herald added a subscriber: aemerson.
This implements what is missing for PR30394, making it possible to compile C++
for ARM in MSVC mode with MSVC headers.
https://reviews.llvm.org/D249
mstorsjo retitled this revision from "Headers: Add iso_volatile load/store
intrinsics" to "[MS] Implement __iso_volatile loads/stores as builtins".
mstorsjo updated the summary for this revision.
mstorsjo updated this revision to Diff 72782.
mstorsjo added a comment.
Changed to implement it as bu
mstorsjo updated this revision to Diff 72988.
mstorsjo added a comment.
Implemented using `CreateAlignedStore` and `CreateAlignedLoad` instead.
I'm less confident in what this actually does though - e.g. is the
`CreateBitCast` part necessary at all? I just based this on code I found in the
same
mstorsjo added inline comments.
> majnemer wrote in ms-volatile-arm.c:2
> You don't need -fms-volatile.
Well, originally, the point was to clarify that these volatile stores end up
without atomic semantics, regardless of whether -volatile:ms has been
specified. The original version of this pat
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282900: [MS] Implement __iso_volatile loads/stores as
builtins (authored by mstorsjo).
Changed prior to commit:
https://reviews.llvm.org/D24986?vs=72988&id=73113#toc
Repository:
rL LLVM
https://revi
mstorsjo added a comment.
> (should they be also on AArch64? I had problems with testing it for AArch64,
> so I left it)
Technically, I think they should be on AArch64 as well. But clang/LLVM probably
doesn't support AArch64/Windows yet (I guess?), so testing it probably is
impossible. When/if
On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
Thanks for letting me know Reid.
I’ll in work and won’t be able to access the repo until lunch time. (~3
hours)
Feel free to revert if it is not trivial.
The easy fix might be to change to == x86_64 from != x86 For is Windows in
the def
On Wed, 29 Nov 2017, Reid Kleckner wrote:
On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö wrote:
On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
Thanks for letting me know Reid.
I’ll in work and won’t be able to access the repo
until lunch t
On Wed, 29 Nov 2017, Martin Storsjö via cfe-commits wrote:
On Wed, 29 Nov 2017, Reid Kleckner wrote:
On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö wrote:
On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
Thanks for letting me know Reid.
I’ll in work
Author: Alvin Wong
Date: 2022-08-29T11:30:44+03:00
New Revision: 00d648bdb5a8b71785269b4851b651c883de2cd9
URL:
https://github.com/llvm/llvm-project/commit/00d648bdb5a8b71785269b4851b651c883de2cd9
DIFF:
https://github.com/llvm/llvm-project/commit/00d648bdb5a8b71785269b4851b651c883de2cd9.diff
LO
Author: Martin Storsjö
Date: 2022-08-29T13:26:13+03:00
New Revision: efc76a1ac5f910776091a48947ca1e90e9068845
URL:
https://github.com/llvm/llvm-project/commit/efc76a1ac5f910776091a48947ca1e90e9068845
DIFF:
https://github.com/llvm/llvm-project/commit/efc76a1ac5f910776091a48947ca1e90e9068845.diff
Author: Martin Storsjö
Date: 2022-08-31T14:55:44+03:00
New Revision: ce4c7a987fa3f255fa49570da4be1b9739815369
URL:
https://github.com/llvm/llvm-project/commit/ce4c7a987fa3f255fa49570da4be1b9739815369
DIFF:
https://github.com/llvm/llvm-project/commit/ce4c7a987fa3f255fa49570da4be1b9739815369.diff
Author: Alvin Wong
Date: 2022-09-09T09:55:40+03:00
New Revision: a3a8bd00c8f1e094967a80e56485c421e312dd2e
URL:
https://github.com/llvm/llvm-project/commit/a3a8bd00c8f1e094967a80e56485c421e312dd2e
DIFF:
https://github.com/llvm/llvm-project/commit/a3a8bd00c8f1e094967a80e56485c421e312dd2e.diff
LO
Author: Martin Storsjö
Date: 2022-09-13T10:40:54+03:00
New Revision: fbfe1db4a95a73ed6a0767db0ab7d449fc03405e
URL:
https://github.com/llvm/llvm-project/commit/fbfe1db4a95a73ed6a0767db0ab7d449fc03405e
DIFF:
https://github.com/llvm/llvm-project/commit/fbfe1db4a95a73ed6a0767db0ab7d449fc03405e.diff
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71393
A few symbols within libclangInterpreter have got explicit dllexport
attributes, in order to make them exported (and thus visible at runtime) in any
build, not only when they are part of e.g. a DLL libclang-cpp
mstorsjo wrote:
CC @brechtsanders, this is an alternative to #66881.
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, I wasn't aware of this issue (I don't routinely try building with
`-DBUILD_SHARED_LIBS=ON`, which I presume is what you've done to trigger this).
See 592e935e115ffb451eb9b782376711dab6558fe0 for earlier context on this issue;
therefore I'd prefer to fix this as I do in
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
This is superseded by #71393 which was merged now.
https://github.com/llvm/llvm-project/pull/66881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Hi Phoebe, starting seeing this error on rather old codes after this patch
> landed . is there a particular flag you recommend i should compile with to
> get previous behavior ?
>
> error: always_inline function '_mm_setzero_pd' requires target feature
> 'evex512', but would
mstorsjo wrote:
Could we please land this now?
https://github.com/llvm/llvm-project/pull/74580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Right, I'd just like to make sure that we're not deepening a divergence here.
> It would be good to get agreement from the GCC devs that they think
> `ms_struct` probably ought to do something on e.g. ARM MinGW targets and that
> they consider this a bug (in a feature that th
https://github.com/mstorsjo requested changes to this pull request.
This is not necessary.
Since 514b4e191d5f46de8e142fe216e677a35fa9c4bb in binutils
(https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb),
dynamicbase is enabled by default. Als
mstorsjo wrote:
This breaks bootstrapping llvm-mingw.
Not all mingw environments use or require pthreads; llvm-mingw is one such
environment, and the clang64 environment in msys2 is another one.
While llvm-mingw does contain winpthreads, it is built later in the build
process, and if this pat
mstorsjo wrote:
@carlo-bramini has spent some effort on using Clang in Cygwin environments
before, so as far as I know, it does work in general from before. So this
change, which adds an entirely new driver for Cygwin environments, would need
to be explained why it does that (I don't disagree,
mstorsjo wrote:
I don't know what issue/regression you're referring to. Please explain, in
detail, what the issue is and all the relevant aspects of your configuration.
Also explain what the suggested fix does, and how it handles the various cases
(I just tested building latest llvm-project ma
https://github.com/mstorsjo approved this pull request.
LGTM, thanks! (I have no idea how I botched that previous fix commit...)
https://github.com/llvm/llvm-project/pull/72314
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
@@ -53,3 +53,26 @@ add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN
binary-to-decimal.cpp
decimal-to-binary.cpp
)
+
+if (DEFINED MSVC)
+ set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
mstorsjo wrote:
Instead of redefining `CMAKE_MSVC_RUNTIME_LIBRARY
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/70991
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this
mstorsjo wrote:
> Very interesting... See also #68092, now I understand even less what the
> problem is...
No idea actually, but I tested passing `-Xcc --target=x86_64-w64-mingw32` to an
MSVC-built clang-repl, and then it outputs the expected things.
Not sure at what level some JIT deduplicat
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
This broke on PS5 bots, like
https://lab.llvm.org/buildbot/#/builders/216/builds/29677; those are configured
with a triple like `x86_64-sie-ps5`, which seems to use an MSVC like C++ ABI
behaviour, so I pushed a revert.
Not sure whom to CC to pull in Sony people to discuss this
Author: Martin Storsjö
Date: 2023-11-02T10:49:55+02:00
New Revision: b73d7390732b48014983aa9569e68c139f61bfcb
URL:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb
DIFF:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb.diff
mstorsjo wrote:
> FTR, the "Worker" tab on that buildbot page will point you to the maintainer.
Ah, there it is, I tried looking around, but overlooked that one...
> But tagging me is also fine in general.
Ok, thanks!
> I'm unable to repro the problem locally because my local build doesn't se
mstorsjo wrote:
> If you still need help reproducing or debugging the issue on our bot, please
> let me know.
Thanks, much appreciated. Can you test if
https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail seems to run
correctly in this environment? Otherwise I'll try to push it to
mstorsjo wrote:
> > > > If you still need help reproducing or debugging the issue on our bot,
> > > > please let me know.
> > >
> > >
> > > Thanks, much appreciated. Can you test if
> > > [mstorsjo@clang-repl-xfail](https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail)
> > > seem
Author: Martin Storsjö
Date: 2023-11-03T11:30:08+02:00
New Revision: e9db60c05e2fb96ff40cbb1f78790abc5de9237e
URL:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e
DIFF:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e.diff
Author: Martin Storsjö
Date: 2023-11-03T11:55:33+02:00
New Revision: 89a336add722f57f61c99b3eafab1c89f943db5e
URL:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e
DIFF:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e.diff
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71168
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this
mstorsjo wrote:
Posting for a second review instead of just relanding the patch as is; in order
to check the host triple, I had to add the `host=triple` string; it was
previously only available for tests under `llvm/test`, but let's move it to the
common llvm test configuration just like the `
https://github.com/mstorsjo requested changes to this pull request.
No, you do not need to do this. There's no need to add `--dynamicbase` manually
in Clang. As I already posted, both ld.bfd and ld.lld default to
`--dynamicbase` enabled since 2020.
https://github.com/llvm/llvm-project/pull/749
mstorsjo wrote:
> I have build scripts and patches at: https://github.com/xu-chiheng/Note
This does not answer the question. You need to explain what is broken, and why,
and how this fixes it. And address the concern that this actually breaks
functionality in some cases. I guess this partially
mstorsjo wrote:
> > Also
>
> In Cygwin with binutils 2.41, --dynamicbase make a difference, so I thought
> MinGW also need it.
No, MinGW does not need it, as it has been enabled by default since binutils
2.36.
Apparently that change,
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdi
mstorsjo wrote:
> > @carlo-bramini has spent some effort on using Clang in Cygwin environments
> > before, so as far as I know, it does work in general from before. So this
> > change, which adds an entirely new driver for Cygwin environments, would
> > need to be explained why it does that (I
mstorsjo wrote:
This commit broken building compiler-rt builtins for Windows on aarch64;
building now hits these errors:
```
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1192:2: error: No support for
checking for lse atomics on this platfrom yet.
1192 | #error No support for checking for
mstorsjo wrote:
> > BTW, when compiling the file I also get a bunch of warnings in this style:
>
> @mstorsjo maybe `unsigned long` is 32 bits on that platform... what's the
> target triple?
Ah, indeed - yes, Windows has 32 bit `long`s. The triples are
`aarch64-windows-gnu` or `aarch64-windows
mstorsjo wrote:
> `-mms-bitfields` is a GCC x86 specific option (`aarch64-linux-gnu-gcc
> -mms-bitfields -xc /dev/null -E` => `error: unrecognized command-line option
> ‘-mms-bitfields’`).
While it is implemented as an x86 specific option in GCC right now, that
doesn't mean that it only is su
mstorsjo wrote:
> Microsoft bit-field layout didn't break an overly-specific regression test
> but rendered unusable double to string conversion. The culprit was the
> following snippet:
>
> ```c++
> union Extractor {
> double value;
> struct {
> bool sign : 1;
> u32 exponent : 11;
mstorsjo wrote:
> One more thing. Re binary compatibility concerns: `-mno-ms-bitfields` on
> MinGW is an equally-sized footgun as on MSVC. Without proper header
> annotation with `#pragma ms_struct on`, either of them will silently make an
> ABI mismatch. However, for some reason, supporting `
mstorsjo wrote:
> Okay, @mstorsjo @MaskRay, what is the way forward?
I'm totally not authoritative for these things, but...
> Am I right that, as for the user-facing changes, `[[gcc_struct]]` cancelling
> implicit `-mms-bitfilds` on MinGW is fine
Sounds quite fine for me
> and silently ignor
Author: Martin Storsjö
Date: 2024-01-04T15:01:17+02:00
New Revision: 71b3ead870107e39e998f6480e545eb01d9d28be
URL:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be
DIFF:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be.diff
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/76949
This fixes uses of the MSYS2 clang64 environment compilers, if another set of
GCC based compilers are available further back in PATH (which may be explicitly
added, or inherited unintentionally from other softw
mstorsjo wrote:
CC @mati865 @jeremyd2019 @huangqinjin
https://github.com/llvm/llvm-project/pull/76949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From c67187043168b79e57c0e4f3261293d799852e90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path
mstorsjo wrote:
> > Looks mostly good to me, but I wonder if we should change testTriple as
> > well.
>
> I thought so too based on the comment, but reviewing the code it seems
> `testTriple` is trying to find evidence that a given triple (and more
> specifically arch for things like `i386` v
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From ce2a49c1a052b30fb1df91f3a7293e89e0a8726d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path
mstorsjo wrote:
> > Although, on a second thought, it might actually still be good to adjust it
> > in sync. If we're invoking Clang with `-m32` and deciding on whether to use
> > i386/i586/i686, and we end up using the install base as sysroot, without
> > inferring any triple from there, we s
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/76949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77534
This applies the same change as in
760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi
and libcxx) to libunwind as well.
These options can reasonably be set either as an absolute or r
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77536
If using multiarch directories with musl, the multiarch directory still uses
*-linux-gnu triples - which may or may not be intentional, while it is somewhat
consistent at least.
However, for musl armhf targets
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/77534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> `bool isEABIHF` from clang/lib/CodeGen/Targets/ARM.cpp can probably be
> factored.
Yep - any suggestion on where we could move it? Up to the `Triple` class?
https://github.com/llvm/llvm-project/pull/77536
___
cfe-commits mailing lis
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/77536
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Mark Harmstone
Date: 2022-07-08T00:37:08+03:00
New Revision: 8e218026f8d5eabfdef9141ae5e26aa91d1933e6
URL:
https://github.com/llvm/llvm-project/commit/8e218026f8d5eabfdef9141ae5e26aa91d1933e6
DIFF:
https://github.com/llvm/llvm-project/commit/8e218026f8d5eabfdef9141ae5e26aa91d1933e6.diff
Author: Martin Storsjö
Date: 2022-07-09T00:11:45+03:00
New Revision: b069801ffb6d11143c2b611a220827120113c7a1
URL:
https://github.com/llvm/llvm-project/commit/b069801ffb6d11143c2b611a220827120113c7a1
DIFF:
https://github.com/llvm/llvm-project/commit/b069801ffb6d11143c2b611a220827120113c7a1.diff
Author: Martin Storsjö
Date: 2022-03-25T21:22:46+02:00
New Revision: 9a3eeae3218f0f8a082d8aabdf4f26e30a86170d
URL:
https://github.com/llvm/llvm-project/commit/9a3eeae3218f0f8a082d8aabdf4f26e30a86170d
DIFF:
https://github.com/llvm/llvm-project/commit/9a3eeae3218f0f8a082d8aabdf4f26e30a86170d.diff
Author: Martin Storsjö
Date: 2022-07-28T12:00:20+03:00
New Revision: 18b4a8bcf3553174f770f09528c9bd01c8cebfe7
URL:
https://github.com/llvm/llvm-project/commit/18b4a8bcf3553174f770f09528c9bd01c8cebfe7
DIFF:
https://github.com/llvm/llvm-project/commit/18b4a8bcf3553174f770f09528c9bd01c8cebfe7.diff
Author: Martin Storsjö
Date: 2022-07-28T12:00:21+03:00
New Revision: dc95d0c525636aed53a3b38258efa2dff4c83edf
URL:
https://github.com/llvm/llvm-project/commit/dc95d0c525636aed53a3b38258efa2dff4c83edf
DIFF:
https://github.com/llvm/llvm-project/commit/dc95d0c525636aed53a3b38258efa2dff4c83edf.diff
1 - 100 of 542 matches
Mail list logo
