LGTM.
Thanks for this.
When I originally used ifdef __clang__ we knew it was a hack because we
should be checking the linker and not the compiler but at the time clang
didn’t work well as a drop in replacement for gcc so it was used to specify
one toolchain combination or another.
Glad to see wh
No worries :)
Just wanted to make sure you knew who you were talking to.
On Mon 12 Mar 2018 at 13:55, David Grayson wrote:
> Sorry to both of you. My brain just messed up there and I only
> realized when it was too late.
>
> --David
>
> On Mon, Mar 12, 2018 at 1:37 PM, Marte
Just so you are aware that is Martin not Martell.
Not sure if that was just an autocorrect or a typo but Martin is the one
doing this work here.
On Mon 12 Mar 2018 at 12:20, Martin Storsjö wrote:
> On Mon, 12 Mar 2018, Martin Storsjö wrote:
>
> > On Sun, 11 Mar 2018, David Grayson wrote:
> >
> >
LGTM.
This is exactly how I was working around it also.
On Fri 9 Feb 2018 at 01:11, Martin Storsjö wrote:
> There is no local wrapper function named _onexit in libmsvcrt.a
> or libmingwex.a, and the declaration in headers don't include
> any dllimport declaration.
>
> This makes i386 match the o
Hey Martin,
When I first wrote this I only considered letters and not numbers for
ctor/dtor names.
If there any special characters ordered after numbers we should use them
instead.
Otherwise LGTM.
Martell
On Sun 26 Nov 2017 at 23:58, Martin Storsjö wrote:
> On Mon, 27 Nov 2017, Martin Storsjö
ping. :)
I think this is being lost between all the different patches being
submitted atm.
On Sun, Nov 5, 2017 at 3:07 AM, Martell Malone
wrote:
> different variations of -march can be passed to the compiler.
> this fixes mingw-w64 when __i686__ is not present.
>
> Please Review.
&g
LGTM
On Sun, Nov 5, 2017 at 7:49 PM, Martin Storsjö wrote:
> Since clang 3.4, __debugbreak is limited to -fms-extensions
> and thus not available by default when targeting mingw.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/_mingw.h.in | 7 ++-
> 1 file changed, 6 insert
different variations of -march can be passed to the compiler.
this fixes mingw-w64 when __i686__ is not present.
Please Review.
diff --git a/mingw-w64-headers/crt/_mingw_mac.h
b/mingw-w64-headers/crt/_mingw_mac.h
index eeb59c69..115e58a5 100644
--- a/mingw-w64-headers/crt/_mingw_mac.h
+++ b/mingw
I figured this would be a good point to revive this discussion.
LLVM/Clang progress for mingw-w64 has come on quite a lot since I brought
this up.
The last time we had an issue around libcxx needing 0x600 for c++ threads
without winpthreads.
Now libunwind is in the same situation.
Martin has been
The winpthreads patch LGTM.
Will need someone else to approve/comment on the gendef patch.
On Fri 6 Oct 2017 at 06:54, JonY via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:
> Patches OK?
>
>
> --
> Ch
Hi Ihsan,
there are no patches attached, probably the mailing list filtered it.
but more importantly we get our directx headers from wine so you need to
submit them to the wine project and once they are merged we will sync them
here.
Kind Regards
MArtell
On Sun, Sep 10, 2017 at 7:09 AM, Ihsan
note.
Martin we might have to add an exception in LLD for the 4 variables being
optimised out for the COFF linker with LTO.
(This is because there is no such thing as linker scripts for COFF)
Best,
Martell
On Tue, Aug 22, 2017 at 9:23 PM, Martin Storsjö wrote:
> On Tue, 22 Aug 2017, Mart
pushed to master.
Thanks Martin.
On Fri, Aug 18, 2017 at 9:01 PM, Martin Storsjö wrote:
> On Fri, 18 Aug 2017, Martell Malone wrote:
>
> Can I land this in master?
>>
>
> Ok with me at least. Since it's all within clang ifdefs, it shouldn't hurt
> for any ot
Can I land this in master?
Best,
Martell
On Fri, Aug 18, 2017 at 8:53 PM, Martell Malone
wrote:
> I'm not so sure; a normal C struct or array would never have a global
>> symbol defined in the middle or at the end, so a smart compiler might
>> some day assume that if y
at new pass or addition of
an exception for __*_END__ or all those toolchains will have to be changed.
It is highly unlikely we will ever face this problem and we won't face it
alone regardless.
On Fri, Aug 18, 2017 at 8:46 PM, Martell Malone
wrote:
> Attached updated patch.
>
> I wa
.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
From 32525c92b4c94e404834b680bef4c131b0d10ab6 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Fri, 18 Aug 2017 19:59:20 +0100
Subject: [PATCH] crt: Handle .ctors and .dtors within mingw-w64
When building with clang
> On Fri, 18 Aug 2017, Martell Malone wrote:
>
> Marin, please review :)
>>
>> commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
>> Author: Martell Malone
>> Date: Fri Aug 18 19:59:20 2017 +0100
>>
>>crt: Handle .ctors and .dtors within mingw-w64
>
I typed too fast *martin :)
On Fri, Aug 18, 2017 at 8:04 PM, Martell Malone wrote:
> Marin, please review :)
>
> commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
> Author: Martell Malone
> Date: Fri Aug 18 19:59:20 2017 +0100
>
> crt: Handle .ctors and .dtors within m
Marin, please review :)
commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
Author: Martell Malone
Date: Fri Aug 18 19:59:20 2017 +0100
crt: Handle .ctors and .dtors within mingw-w64
When building with clang we currently assume you will be
linking with llvm's lld or a bleeding
In that case I will be back with a patch shortly for you to review.
It might look ugly because of a large __clang__ ifdef block but should work.
On Fri, Aug 18, 2017 at 7:50 PM, Martin Storsjö wrote:
> On Fri, 18 Aug 2017, Martell Malone wrote:
>
> David, I also want to remove KEEP
David, Sorry the previous email was to the thread, this link is to the
exact email where I detail the problem.
https://sourceware.org/ml/binutils/2017-08/msg00123.html
On Fri, Aug 18, 2017 at 7:46 PM, Martell Malone
wrote:
> David, I also want to remove KEEP (*(.ctors)); which seems to caus
017, Martell Malone wrote:
>
> suddenly requiring the absolutely latest binutils, right?
>>>>
>>>
>> Correct we will need the next binutils release as a min version.
>> I don't think we need a condition we should just specify a new min
>> binutils
>&
should wait until all your
crt patch changes land in tree first though incase someone wanted to make a
v6 branch before this hits master.
On Thu, Aug 17, 2017 at 9:00 PM, Martin Storsjö wrote:
> On Mon, 14 Aug 2017, Martell Malone wrote:
>
> Can you briefly summarize what change th
LGTM
On Fri, Aug 18, 2017 at 2:51 PM, Martin Storsjö wrote:
> Use -undef to avoid any compiler specific predefined definitions,
> and use -P to skip the line markers - removing the need for the extra
> sed command.
>
> The -w command to silence warnings is necessary, since otherwise
> there are
xe happy.
On Mon, Aug 14, 2017 at 12:49 PM, Martin Storsjö wrote:
> On Mon, 14 Aug 2017, Martell Malone wrote:
>
> Hey Martin,
>>
>> I had a discussion with Nick and CC'd kai on getting the binutils patch in
>> tree a week ago.
>> https://sourceware.org/ml/
Hey Martin,
I had a discussion with Nick and CC'd kai on getting the binutils patch in
tree a week ago.
https://sourceware.org/ml/binutils/2017-08/msg00123.html
It seems to be moving along.
Best,
Martell
On Mon, Aug 14, 2017 at 8:49 AM, Martin Storsjö wrote:
> On Sat, 5 Aug 2017, David Grays
tly to
_InitializeCriticalSection when the short library is created, given the
fact we do not need the @4 this is directly equivalent to
_InitializeCriticalSection@4 in the old format.
Best,
Martell
On Wed, Aug 9, 2017 at 2:37 PM, Martell Malone
wrote:
> Nevertheless llvm-dlltool should learn at least the '==&
w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:
> 2017-08-09 15:11 GMT+02:00 Martell Malone :
> >>
> >> Just out of curiosity - the 800 def files that only are available for
> >> x86_64 but not for i686, are they something that somebody practically
&g
>
> Just out of curiosity - the 800 def files that only are available for
> x86_64 but not for i686, are they something that somebody practically care
> about? Should we try to add them to i686 as well (given that they probably
> actually exist there as well)? Do they serve any real purpose?
I do
t
> would know we are doing undefined behavior and would have a license to
> do whatever it wants, including removing that code. The way the loop
> is written right now is probably safer than anything that uses a
> symbol at the end of the constructors.
>
> --David
>
tirely sure
> > it would be a good patch to use though, since I'm not sure how GCC
> > picks names for its global constructor and destructor sections, and
> > how it sorts those names, so I'm not sure that the symbols we are
> > defining would really be in the right
got
> >> it to work. It looks pretty dangerous to me because you removed the
> >> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
> >> you're using .ctors and .dtors in your other patch, and other code
> >> might use them too I suppose.
&
ngw-w64/mingw-w
> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__'
> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b
> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__'
>
chain and confirm.
I haven't built a mingw-w64 with gcc and binutils in so long.
Best,
Martell
On Fri, Aug 4, 2017 at 7:53 PM, Martin Storsjö wrote:
> On Fri, 4 Aug 2017, Ruben Van Boxem wrote:
>
> Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" > >:
>>
>
n linker
>>> scrpt instead? That is actually the way used in ld for it.
>>>
>>> Thanlks,
>>> Kai
>>>
>>> 2016-08-06 5:14 GMT+02:00 Martell Malone :
>>>
>>>> This patch should be the last piece of the puzzle.
>>>
Can I apply this to master?
I have pigged this 3 times
On Sun, Jun 4, 2017 at 1:21 AM, Martell Malone
wrote:
> ping, don't let this one die on me please :)
>
> On Sun, May 21, 2017 at 7:05 PM, Martell Malone
> wrote:
>
>> ping :)
>>
>> On Thu, May 11, 201
Hey ardi,
I am the one implementing this support.
The current status is you can build mingw-w64 with llvm, clang and lld
without binutils or gcc.
libc++, libc++abi and compiler-rt work.
libunwind support is missing so we have no exception handling currently.
There were some 20+ patches merged in t
d require us to end that support. When we surveyed last year,
> >> several
> >> > percent of our users still used XP, and we don't really want to leave
> >> them
> >> > out in the cold without good reason. Building our own mingw just to
> >
In this thread https://sourceforge.net/p/mingw-w64/bugs/459/
there is a suggested fix for print with whole numbers
The builtin __mingw_printf is inconsistent with printf on %a format.
> I think __mingw_printf is wrong, because obviously 1.0 != 0x0p-63.
vacaboja opened an issue on msys2 for this
is already on the
> > way to die ...
> > Nevertheless, IMHO we should do that increase just for our master.
> >
> > Regards,
> > Kai
> >
> > 2017-06-04 1:33 GMT+02:00 Martell Malone :
> > > Thanks for that clarification Ricardo.
> > > It
ping, don't let this one die on me please :)
On Sun, May 21, 2017 at 7:05 PM, Martell Malone
wrote:
> ping :)
>
> On Thu, May 11, 2017 at 2:10 PM, Martell Malone
> wrote:
>
>> Thanks Kai,
>>
>> We probably don't need to push and pop because this is no
Hi,
I am currently looking at emulating
_locale_t _get_current_locale(void);
We were previously hacking around this by just returning 0 cast as
_locale_t in msys2
This is obviously incorrect and any sane c++ tries to check multiple times
with that result.
What would be the correct way to emulate
D_SEC_WARN;
_SECIMP errno_t __cdecl _strdate_s (char *_Buf,size_t _SizeInBytes);
_CRTIMP char *__cdecl _strtime(char *_Buffer)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
On Mon, May 22, 2017 at 12:18 PM, Martell Malone
wrote:
> Thanks for spotting that strangely MSDN seems to think it does e
n too low?
> > Date: Sat, 3 Jun 2017 18:27:40 +0100
> > To: Mingw-w64-public
> > From: Martell Malone
> > > Hey,
> > >
> > > As per my discussion with LLVM devs here.
> > > 0x600 is the min version required to support libc++ win32 threading.
> &g
Hey,
As per my discussion with LLVM devs here.
0x600 is the min version required to support libc++ win32 threading.
https://reviews.llvm.org/D33384
I'm not quite sure why we currently have 0x502 as the default.
It seems to be a number sitting between Windows XP and Vista.
I would like to propose
on, May 22, 2017 at 12:14 PM, Liu Hao wrote:
> On 2017/5/22 18:43, JonY wrote:
> > On 05/22/2017 07:57 AM, Liu Hao wrote:
> >> On 2017/5/22 2:05, Martell Malone wrote:
> >>> Context: libc++ uses strftime_l now
> >>>
> >>> Please Review
> >
hmm okay.
It does have strftime however so that should at least be fine right?
On Mon, May 22, 2017 at 11:43 AM, JonY wrote:
> On 05/22/2017 07:57 AM, Liu Hao wrote:
> > On 2017/5/22 2:05, Martell Malone wrote:
> >> Context: libc++ uses strftime_l now
> >>
> >
ping :)
On Thu, May 11, 2017 at 2:10 PM, Martell Malone
wrote:
> Thanks Kai,
>
> We probably don't need to push and pop because this is not a header to be
> installed
>
> Updated diff
>
> diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/
> rd
Context: libc++ uses strftime_l now
Please Review
Kind Regards
Martell
diff --git a/mingw-w64-crt/lib32/msvcrt.def.in b/mingw-w64-crt/lib32/
msvcrt.def.in
index 51f62cb6..f22a79a9 100644
--- a/mingw-w64-crt/lib32/msvcrt.def.in
+++ b/mingw-w64-crt/lib32/msvcrt.def.in
@@ -1210,6 +1210,8 @@ mbstowc
PM, Kai Tietz wrote:
> Hmm, where is the corresponding pop_macro pragma?
>
> Regards,
> Kai
>
> 2017-05-11 14:09 GMT+02:00 Martell Malone :
> >>
> >> While it's not "good form" to have the prototype
> >> in multiple places...
> >
__int64)val2) << 32);
}
-
+#endif
On Sun, Apr 16, 2017 at 3:06 AM, David Wohlferd
wrote:
> On 4/14/2017 7:14 AM, Martell Malone wrote:
> > Updated clang no longer defines __IA32INTRIN_H so lets do this properly.
>
> It appears that the only use for in that file is the
Updated clang no longer defines __IA32INTRIN_H so lets do this properly.
I assume intrin-impl.h is only ever included by intrin.h?
If not I will have to find a way to deal with __has_builtin in both files
Please Review
Kind Regards
Martell
diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-
Hey guys,
> Thanks, but I'd be more interested in documentation how to get cross
> compilation setup with clang + mingw-w64. I did one in the past, but it
> required patching clang and llvm and working around misc problems I
> don't quite remember in details.
> I haven't tried but I doubt it will
Apart from the thread hijack on if we should drop xp support. :)
I believe this patch is good to apply yes?
On Mon, Oct 31, 2016 at 2:22 AM, Martell Malone
wrote:
> Hey guys,
>
> This has been brought up both on the mailing list and the bug tracker.
> https://sourceforge.net/p/mi
.aspx
MSDN has a doc version from VS2005.
I don't see anything about a min windows version there.
We already have this in the lib64 variant.
So all indicators are good.
>From 0d5e9e8f1f3f3cbcca86471174057edcaf3382d9 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Mon, 31 Oct 2016 02:17:
Jon_y beat me to it. :)
I had modified it to fit within a reasonable line character limit with this
adjustment.
Author: mati865
Date: Mon Oct 17 12:08:24 2016 +
fix uchar.h for Clang
Clang defines itself as GCC 4.2.1 and triggers check for GCC lower than
4.4.0.
This patch
Hey,
Are you sure this is correct?
It seems to be for libarm32 but the xbox1 is x64.
Best,
Martell
On Tue, Sep 6, 2016 at 8:27 AM, Hugo Beauzée-Luyssen
wrote:
> Hi,
>
> When building apps for Xbox1 (at least), this lib must be used instead
> of kernel32.lib, since kernel32.dll isn't shipped on
}
On Thu, Aug 18, 2016 at 4:21 AM, Martell Malone
wrote:
> mingw_pformat.patch - Don't use feature (__attribute__((gcc_struct))) that
>> isn't supported on clang when compiling on clang.
>
> I have the very same patch applied locally, can confirm this is a good
> ch
>
> mingw_pformat.patch - Don't use feature (__attribute__((gcc_struct))) that
> isn't supported on clang when compiling on clang.
I have the very same patch applied locally, can confirm this is a good
change.
The typo was a good catch.
On Thu, Aug 18, 2016 at 3:33 AM, David Wohlferd
wrote:
>
>
This patch should be the last piece of the puzzle.
Now c++ works, it relied heavily on ctors which was broken with clang and
lld.
please review
From 077f2318a219db191588d0ab00df58bb694c2931 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Fri, 5 Aug 2016 20:09:41 -0700
Subject: [PATCH] Handle
You have my go ahead to apply.
There is a header setting for when building gcc or rather libgcc to specify
that ctors and dtors are provided by the c runtime.
This is usually enabled for some embedded targets.
Alternatively I could only enable that when we build the crt with clang and
not gcc.
Th
n use compiler-rt instead of
libgcc with clang.
Other then that every patch should be in tree for armv7 support.
On Mon, Feb 22, 2016 at 9:28 PM, Martell Malone
wrote:
> Hey JonY,
>
> I think I have a few arm patches that I submitted that should be merged
> before the branch.
> I'
Hey JonY,
I think I have a few arm patches that I submitted that should be merged
before the branch.
I'll check and commit them it if they weren't committed already.
If not I will submit in the morning.
They are only small changes but would be great to not miss the branch.
Kind Regards
Martell
O
ls for this, so we can piggy back in future and never
fall behind and new windows target.
We will still need to put in the assembly work on the mingw-w64 side but
that seems to be something you do very early on because of wine :)
On Thu, Dec 24, 2015 at 9:54 AM, André Hentschel wrote:
>
>
> [PATCH] CRT_fp10: Protect ARM implementation against compiler optimizations
I take it the clang based toolchain I sent you works ?
I'm going to move onto fixing i686 and then do a personal builds release
for xmas.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64
ping! :)
On Tue, Dec 15, 2015 at 11:06 PM, Martell Malone
wrote:
> Please ignore patch 003 which adds __initenv to msvcrt
> This is not available on arm.
> Please review this along with the NtCurrentTeb patch.
>
> Apologies for the noise
>
> Kind Regards
> Martell
>
&
Please ignore patch 003 which adds __initenv to msvcrt
This is not available on arm.
Please review this along with the NtCurrentTeb patch.
Apologies for the noise
Kind Regards
Martell
On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone
wrote:
> Forgot: Please Review. :)
>
> On Tue, Dec
Add the final 2 functions need to run are executables via mingw-w64.
From 5288e84f375a5abdca6276586fe581872a88bfe8 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Tue, 15 Dec 2015 20:57:52 -0800
Subject: [PATCH 2/2] Add support for NTCurrentTeb for ARMNT
diff --git a/mingw-w64-headers
Forgot: Please Review. :)
On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone
wrote:
> Add the final 2 functions need to run are executables via mingw-w64.
>
--
___
Min
Please review :)
From 71c1392f4562f7abc4f15ac6acc124e0d2d09de1 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Tue, 1 Dec 2015 00:28:32 -0800
Subject: [PATCH] crt: fix _MINGW_UDERSCORE_PREFIX for arm
diff --git a/mingw-w64-headers/crt/_mingw_mac.h
b/mingw-w64-headers/crt/_mingw_mac.h
index
r you.
Please review.
I was not quite sure how ld would react to __CTOR_LIST__ being defined in
both libgcc and libmingw32 so I opted to change the name to
__MINGW_CTOR_LIST__ to keep the peace :)
From a0aaf41fa802e171c82a1f956c600c7aa36c2eda Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Sa
Applied to HEAD :)
On Fri, Nov 13, 2015 at 4:27 AM, Nakai Yuta wrote:
>
> This patch is already reviewed by martell at irc.
>
> If anyone does not have any objection, please commit this.
>
> --
>
> __
Ping?
On Tuesday, November 10, 2015, Martell Malone
wrote:
> You changed from --enable to --with, but left the conditional name as
>> ENABLE_GENLIB. Change to WITH_GENLIB.
>> Makefile.am:
>> Don't test WITH_GENLIB twice. Test it once and set all the
ut-delaylib $@.delayimp.a
> endif
>
> after the WITH_GENLIB conditional.
>
>
> Send patches as .txt, as google screws up the encoding / mime type.
>
>
> On Tue, Nov 10, 2015 at 2:08 AM, Martell Malone
> wrote:
> > Thanks for your input and help on this
> option, not enable. genlib is an external tool for the crt, not an
> > internal feature that is getting compiled in. You should just have to
> > change to AC_ARG_WITH and from enable_ to with_.
> >
> > On Mon, Nov 9, 2015 at 12:46 AM, Martell Malone
> wrote:
&
Here is the final patch after running autoreconf -fi and only applying
relevant changes.
I would like to apply this if there are no objections ?
Kind Regards
Martell
On Fri, Nov 6, 2015 at 3:39 PM, Martell Malone
wrote:
> Updated to reflect Nightstrike's feedback
>
> On Wed, No
Updated to reflect Nightstrike's feedback
On Wed, Nov 4, 2015 at 2:00 PM, NightStrike wrote:
> Use AM_CONDITIONAL, not DEFINE_UNQUOTED
>
> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone
> wrote:
> > Be warned I am no autotools expert.
> > A review would be very h
Be warned I am no autotools expert.
A review would be very helpful. :)
CC+ alexey for help on that :)
From cd7023eb40a970e3a8293cdbcb0639450cf4d223 Mon Sep 17 00:00:00 2001
From: Martell Malone
Date: Wed, 4 Nov 2015 18:47:54 +
Subject: [PATCH] configure.ac: add support for --enable-genlib
>
> Great work. Please go ahead and merge new tool to master.
Kai I have pushed, hopefully I can get some feedback on building and
running for the community :)
Thanks again guys.
Exciting times :D
On Wed, Nov 4, 2015 at 2:17 PM, Martell Malone
wrote:
> The difference I see is that bi
d be
possible.
I have been dealing with clang and not gcc though so I haven't specifically
been to worried about this setup
On Wed, Nov 4, 2015 at 7:44 AM, Adrien Nader wrote:
> On Tue, Nov 03, 2015, Martell Malone wrote:
> > Just to clear things up here.
> >
> >
ad and merge new tool to master.
> I agree to Adrien's comment that this tool should be also buildable by
> different hosts. So we shouldn't bind its build on Windows-targets
> only.
>
> Thanks,
> Kai
>
> 2015-11-03 22:33 GMT+01:00 Adrien Nader :
> > Hi,
>
ping!
Kai is there any objections to committing this and getting an option in
configure?
It's holding me up simplifying the build process for a clang based
toolchain :(
On Thu, Oct 29, 2015 at 4:47 PM, Martell Malone
wrote:
> You have a functional Clang/libc++ toolchain? That's awe
created mingw-w64 packages for msys2 for this.
I'm currently wrapping up a full portable toolchain for jb from videolan.
Once I'm done I will share my scripts with you to build it yourself
Kind Regards
Martell
On Thu, Oct 29, 2015 at 9:51 AM, Ruben Van Boxem
wrote:
> 2015-10-29 3:54 GMT+
ote:
> Did you consider just sending dlltool patches upstream?
> On Oct 28, 2015 8:51 PM, "Martell Malone" wrote:
>
>> Hi,
>>
>> Kai and I discussed this previously but I would like to present to
>> everyone a tool to generate import libs based on layout a
, Martell Malone
wrote:
> Hi,
>
> Kai and I discussed this previously but I would like to present to
> everyone a tool to generate import libs based on layout and code structure
> of gendef.
>
> I would like propose
> https://github.com/martell/genlib
> to be merged as pa
Hi,
Kai and I discussed this previously but I would like to present to everyone
a tool to generate import libs based on layout and code structure of gendef.
I would like propose
https://github.com/martell/genlib
to be merged as part of the mingw-w64 project.
There are a couple of advantages over
For the most part clang is now fully usable with mingw-w64 now.
Also I have built the crt with clang several times now with great success
on HEAD.
I now would like to move for merging genlib into mingw-w64-tools.
On Thu, Oct 22, 2015 at 4:39 PM, Kai Tietz wrote:
> 2015-10-22 15:30 GMT+02:0
The reason I am asking is because there is a calling convention bug for
mingw-w64 and clang that is only present on x86_64.
Are you sure there are no differences from a Linux target?
On Thursday, October 22, 2015, Kai Tietz wrote:
> Hi guys,
>
> 2015-10-22 12:54 GMT+02:00 Marte
Hi guys,
Can someone confirm the format of long double for the x86_x64 target of
mingw-w64.
Under i686 it is x87 80 bit precision
But under x86_64?
Is it sse2 128 or 80 bit or is it still x87
Kind regards
Martell
--
___
Hi thanks for the contribution.
Could you do this for arm also :)
Kind Regards
Martell
On Sunday, September 20, 2015, Zachary Greve wrote:
> Here are MSVC 14 Runtime Def files (x86 and x64, Debug and Release)
>
--
It never built before :)
I assume whoever tested the armv7 target under gcc never knew that ARMNT is
thumb mode only.
On 7 Aug 2015 21:43, "JonY" wrote:
> On 8/7/2015 08:51, Martell Malone wrote:
> > The scanf functions don't specify thumb mode which makes
Please Review
diff --git a/mingw-w64-headers/crt/math.h b/mingw-w64-headers/crt/math.h
index 069e734..0d27e85 100644
--- a/mingw-w64-headers/crt/math.h
+++ b/mingw-w64-headers/crt/math.h
@@ -207,7 +207,7 @@ extern "C" {
#if !defined (__ia64__)
__CRT_INLINE float __cdecl fabsf (float x)
{
-#
The scanf functions don't specify thumb mode which makes them fail to
compile.
Please Review
diff --git a/mingw-w64-crt/stdio/vfscanf2.S b/mingw-w64-crt/stdio/vfscanf2.S
index f6ba5d6..97807a9 100644
--- a/mingw-w64-crt/stdio/vfscanf2.S
+++ b/mingw-w64-crt/stdio/vfscanf2.S
@@ -9,6 +9,9 @@
#defi
5 at 11:35 PM, JonY wrote:
> On 8/5/2015 04:59, Martell Malone wrote:
> > Hi
> >
> > I currently apply this to clang when building mingw-w64-crt for x64 when
> > building with clang.
> > This is not exactly a blocker for me because my focus is x86 and arm but
:00 2001
From: Martell Malone
Date: Tue, 4 Aug 2015 21:56:45 +0100
Subject: [PATCH] crt: crtexe avoid seh because of .rva when using clang
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index ade4124..6a2e2c7 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/
what it represents ?
This would be much cleaner then having #ifdef's in the code
Thoughts ?
On Tue, Aug 4, 2015 at 12:04 AM, JonY wrote:
> On 8/4/2015 02:20, Martell Malone wrote:
> > I would like to not that I sent something into the LLVM mailing list on
> >
Clang defines __rdtsc as inline in intrin.h
mingw-w64-crt/intrincs/rdtsc.c:9:18: error: redefinition of '__rdtsc'
unsigned __int64 __rdtsc(void)
^
clang\3.7.0\include\ia32intrin.h:89:1: note: previous definition is here
__rdtsc(void) {
This bypasses that inline when building the
Kind Regards
Martell
On Mon, Aug 3, 2015 at 7:05 PM, Martell Malone
wrote:
> I'd like some feedback on this patch if possible
>
> Kind Regards
> Martell
>
> diff --git a/mingw-w64-crt/math/log1pl.S b/mingw-w64-crt/math/log1pl.S
> index 7ff0f5b..5c17ae4 100644
> ---
I'd like some feedback on this patch if possible
Kind Regards
Martell
diff --git a/mingw-w64-crt/math/log1pl.S b/mingw-w64-crt/math/log1pl.S
index 7ff0f5b..5c17ae4 100644
--- a/mingw-w64-crt/math/log1pl.S
+++ b/mingw-w64-crt/math/log1pl.S
@@ -16,7 +16,11 @@
-1 + sqrt(2) / 2 <= x <= 1 - sqrt(2
>
> For consistency with the existing multilib dirs, IMHO LIBARM32SUFFIXDIR
> should be lib only if hostcpu is arm*, it should be libarm32 otherwise.
Yes this makes sense so I changed it to that with this updated patch.
Also when the host is arm x86 libs should also not be lib and should be
libx8
1 - 100 of 180 matches
Mail list logo
