Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__

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

Re: [Mingw-w64-public] [PATCH] crt: Add "volatile" to all inline assembly snippets under math

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

Re: [Mingw-w64-public] [PATCH] msvcrt: Remove "DATA" attributes for _onexit for i386

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

Re: [Mingw-w64-public] [PATCH] crt: Use .ctors.99999 instead of .ctors$zzz for __CTOR_END__ for clang/lld

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

Re: [Mingw-w64-public] [PATCH] normalise x86 (i686 vs i386) detection

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 <martellmal...@gmail.com> wrote: > different variations of -march can be passed to the compiler. > this fixes mingw-w64 when __i686__ is

[Mingw-w64-public] [PATCH] normalise x86 (i686 vs i386) detection

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 +++

Re: [Mingw-w64-public] [PATCH] Fix gendef fallthroughts and enable winpthreads library build

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? > > > -- >

Re: [Mingw-w64-public] headers: Add dxgi1_3, d3d11_2, d3d11_3 idl

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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

e, 22 Aug 2017, Martell Malone wrote: > > pushed to master. >> > > Fantastic, thanks! > > > // Martin > > > -- > Check out the vibrant tech community on one of the world's most >

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

Can I land this in master? Best, Martell On Fri, Aug 18, 2017 at 8:53 PM, Martell Malone <martellmal...@gmail.com> 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 >

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

on 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 <martellmal...@gmail.com> wrote: > Attached updated patch. > > I

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

artin.st> wrote: > On Fri, 18 Aug 2017, Martell Malone wrote: > > Marin, please review :) >> >> commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45 >> Author: Martell Malone <martellmal...@gmail.com> >> Date: Fri Aug 18 19:59:20 2017 +0100 >> >>

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

I typed too fast *martin :) On Fri, Aug 18, 2017 at 8:04 PM, Martell Malone <martellmal...@gmail.com> wrote: > Marin, please review :) > > commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45 > Author: Martell Malone <martellmal...@gmail.com> > Date: Fri Aug 18 19:5

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

Marin, please review :) commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45 Author: Martell Malone <martellmal...@gmail.com> 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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

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 <martellmal...@gmail.com> wrote: > David, I also want to remove KEEP

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

t; On Fri, 18 Aug 2017, 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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

d 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ö <mar...@martin.st> wrote: > On Mon, 14 Aug 2017, Martell Malone wrote: > > Can you briefly summarize

Re: [Mingw-w64-public] [PATCH] crt: Improve the cpp parameters for preprocessing def files

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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

Aug 14, 2017 at 12:49 PM, Martin Storsjö <mar...@martin.st> 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/b

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

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

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

rectly 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 <martellmal...@gmail.com> wrote: > Nevertheless llvm-dlltool should

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

w-w64-public@lists.sourceforge.net> wrote: > 2017-08-09 15:11 GMT+02:00 Martell Malone <martellmal...@gmail.com>: > >> > >> Just out of curiosity - the 800 def files that only are available for > >> x86_64 but not for i686, are they something that somebody

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

> > 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

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

t; > clash with the symbols defined by the linker script in binutils. > >> > > >> > So, attached to this email is a patch that worked for me (I was able > >> > to compile and run a Qt Widgets application). I'm not entirely sure > >> > it would be a good patch

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

on). I'm not entirely 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 reall

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

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ö <mar...@martin.st> wrote: > On Fri, 4 Aug 2017, Ruben Van Boxem wrote: > > Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" <

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

tter to have those symbols in 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 <martellmal...@gmail.com>: >>> >>>> This pat

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

Can I apply this to master? I have pigged this 3 times On Sun, Jun 4, 2017 at 1:21 AM, Martell Malone <martellmal...@gmail.com> wrote: > ping, don't let this one die on me please :) > > On Sun, May 21, 2017 at 7:05 PM, Martell Malone <martellmal...@gmail.com> > wrote: &

Re: [Mingw-w64-public] Is it possible to use clang instead of gcc with mingw64?

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

[Mingw-w64-public] [PATCH] remove cast to int from mantissa for __mingw_printf

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

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

t to Windows 7. Windows Vista 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 <martellmal...@gmail.com>: > > >

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

ping, don't let this one die on me please :) On Sun, May 21, 2017 at 7:05 PM, Martell Malone <martellmal...@gmail.com> wrote: > ping :) > > On Thu, May 11, 2017 at 2:10 PM, Martell Malone <martellmal...@gmail.com> > wrote: > >> Thanks Kai, >> >> W

[Mingw-w64-public] [HELP] Need to emulate _get_current_locale

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

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

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 <martellmal...@gmail.com> wrote: > Thanks for spotting that strangely

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

c] Default _WIN32_WINNT version 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 su

[Mingw-w64-public] Default _WIN32_WINNT version too low?

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

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

on, May 22, 2017 at 12:14 PM, Liu Hao <lh_mo...@126.com> 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 > >>> > >>

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

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 <jo...@users.sourceforge.net> wrote: > On 05/22/2017 07:57 AM, Liu Hao wrote: > > On 2017/5/22 2:05, Martell Malone wrote: > >> Context: li

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

ping :) On Thu, May 11, 2017 at 2:10 PM, Martell Malone <martellmal...@gmail.com> 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/min

[Mingw-w64-public] [Patch] normalize strftime and strftime_l

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 @@

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

1:15 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > Hmm, where is the corresponding pop_macro pragma? > > Regards, > Kai > > 2017-05-11 14:09 GMT+02:00 Martell Malone <martellmal...@gmail.com>: > >> > >> While it's not "good form" to have the prot

Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

)val2) << 32); } - +#endif On Sun, Apr 16, 2017 at 3:06 AM, David Wohlferd <d...@limegreensocks.com> 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 t

[Mingw-w64-public] [PATCH] intrincs: check for __rdtsc

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

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

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

[Mingw-w64-public] [PATCH] lib32 msvcrt add mkgmtime exports

.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 <martellmal...@gmail.com> Date

Re: [Mingw-w64-public] [PATCH] fix uchar.h for Clang

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

Re: [Mingw-w64-public] [PATCH] Add a windowsapp.lib

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

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

} On Thu, Aug 18, 2016 at 4:21 AM, Martell Malone <martellmal...@gmail.com> 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 th

[Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

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 <martellmal...@gmail.com> Date: Fri, 5 Aug 2016 20

Re: [Mingw-w64-public] Revert [ca451a] Handle __CTOR_LIST__ internally within mingw-w64

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.

Re: [Mingw-w64-public] Any more commits before v5.x branches out?

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 <martellmal...@gmail.com> wrote: > Hey JonY, > > I think I have a few arm patches that I submitted that should be merged >

Re: [Mingw-w64-public] Any more commits before v5.x branches out?

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

Re: [Mingw-w64-public] [PATCH] CRT_fp10: Protect ARM implementation against compiler optimizations

ggy 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 <n...@dawncrow.de> wrote: &

Re: [Mingw-w64-public] Lock in support in the crt for ARMNT

ping! :) On Tue, Dec 15, 2015 at 11:06 PM, Martell Malone <martellmal...@gmail.com> 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 >

Re: [Mingw-w64-public] [PATCH] CRT_fp10: Protect ARM implementation against compiler optimizations

> > [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.

Re: [Mingw-w64-public] Lock in support in the crt for ARMNT

Forgot: Please Review. :) On Tue, Dec 15, 2015 at 10:37 PM, Martell Malone <martellmal...@gmail.com> wrote: > Add the final 2 functions need to run are executables via

[Mingw-w64-public] Lock in support in the crt for ARMNT

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 <martellmal...@gmail.com> Date: Tue, 15 Dec 2015 20:57:52 -0800 Subject: [PATCH 2/2] Add support for NTCurrentTeb for ARMNT diff

Re: [Mingw-w64-public] Lock in support in the crt for ARMNT

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 <martellmal...@gmail.com> wrote: > Forgot: Plea

[Mingw-w64-public] [PATCH] So much arm... So little time

Please review :) From 71c1392f4562f7abc4f15ac6acc124e0d2d09de1 Mon Sep 17 00:00:00 2001 From: Martell Malone <martellmal...@gmail.com> 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/min

[Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ internally within mingw-w64

. 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 <martell

Re: [Mingw-w64-public] [PATCH] genlib: Fix option handling.

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. > > -- > >

Re: [Mingw-w64-public] PATCH for autootools to use genlib

Ping? On Tuesday, November 10, 2015, Martell Malone <martellmal...@gmail.com> 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 onc

Re: [Mingw-w64-public] PATCH for autootools to use genlib

DLLTOOLFLAGS += --output-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 <martellmal...@gmail.com> > wrote:

Re: [Mingw-w64-public] PATCH for autootools to use genlib

is the first time around... this should be a with- > > 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

Re: [Mingw-w64-public] PATCH for autootools to use genlib

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 <martellmal...@gmail.com> wrote: > Updated to reflect Nightstrike's

Re: [Mingw-w64-public] PATCH for autootools to use genlib

Updated to reflect Nightstrike's feedback On Wed, Nov 4, 2015 at 2:00 PM, NightStrike <nightstr...@gmail.com> wrote: > Use AM_CONDITIONAL, not DEFINE_UNQUOTED > > On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone <martellmal...@gmail.com> > wrote: > > Be w

[Mingw-w64-public] PATCH for autootools to use genlib

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 <martellmal...@gmail.com> Date: Wed, 4 Nov 2015 18:47:54 + Subject: [PATCH] configure.a

Re: [Mingw-w64-public] mingw-w64-tools: genlib - internal tool for import lib generation

> > 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 <martellmal...@gmail.com> wrote: >

Re: [Mingw-w64-public] mingw-w64-tools: genlib - internal tool for import lib generation

ble. 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 <adr...@notk.org> wrote: > On Tue, Nov 03, 2015, Martell Malone wrote: > > Just to clear things up here. > > > > I in

Re: [Mingw-w64-public] libc++ on MinGW-w64

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 <martellmal...@gmail.com> wrote: > You have a functional Clang/libc++

Re: [Mingw-w64-public] mingw-w64-tools: genlib - internal tool for import lib generation

ead 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 <adr...@notk.org>: >

Re: [Mingw-w64-public] libc++ on MinGW-w64

-10-29 3:54 GMT+01:00 Martell Malone <martellmal...@gmail.com>: > >> My second reason is clang. >> I currently have a mingw-w64 toolchain with this stack. >> clang + libc++ + compiler-rt + lld >> this equates to >> gcc + libstdc++ + libgcc + binutils. >> &

Re: [Mingw-w64-public] MSVC 14 Runtime def files

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

[Mingw-w64-public] [PATCH] Use builtins for fabs on arm rather then x86 asm which fails

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) {

[Mingw-w64-public] [PATCH fix scanf asm for thumb2

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 @@

Re: [Mingw-w64-public] Clang Support for log1pl.S

as to 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 jo...@users.sourceforge.net 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 this also

Re: [Mingw-w64-public] SEH question with clang

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 maybe someone has a better work around. jon_y? Thoughts

[Mingw-w64-public] SEH question with clang

2001 From: Martell Malone martellmal...@gmail.com 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

Re: [Mingw-w64-public] [PATCH] 2 Small Patches for ARM and Clang building

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

Re: [Mingw-w64-public] [PATCH] Add some missing Media Foundation id's

Disregard previous message Kai said that on irc but actually reviewed it afterwards :) On Mon, Jul 13, 2015 at 7:02 PM, Martell Malone martellmal...@gmail.com wrote: Kai said this patch looks good but asked could jacek have a look just to be sure :) On Sun, Jul 12, 2015 at 12:04 AM, Martell

Re: [Mingw-w64-public] [PATCH] cr8 is only available to x86_64

Thanks kai. Your last 2 emails went into my spam box so I missed the approval Quite strange On Sun, Jul 12, 2015 at 6:53 AM, Kai Tietz ktiet...@googlemail.com wrote: Hi Martell, Patch is ok. Please go ahead and apply. Thanks, Kai Am 10.07.2015 02:03 schrieb Martell Malone martellmal

Re: [Mingw-w64-public] [PATCH] cr8 is only available to x86_64

exact reason *Why is this message in Spam?* It has a from address in googlemail.com but has failed googlemail.com's required tests for authentication On Tue, Jul 14, 2015 at 7:02 PM, Martell Malone martellmal...@gmail.com wrote: Thanks kai. Your last 2 emails went into my spam box so I missed

[Mingw-w64-public] [PATCH] mingw-w64 support for compiler-rt

Greetings all, I am cross posting this to the mingw-w64 mailing list and llvm-commits list. Attached is 2 patches to enable compiler-rt to be used as a replacement libgcc for mingw-w64. I have tested this with clang and it passes simple test. I would like some input on the patch from the

Re: [Mingw-w64-public] readdir_r support

is and google didn't help much :( Also what about __forceinline for the _POSIX_C_SOURCE guard ? Many Thanks Martell On Mon, Jun 29, 2015 at 9:20 AM, Jacek Caban ja...@codeweavers.com wrote: Hi Martell, On 06/27/15 18:02, Martell Malone wrote: Attached is a patch for adding readdir_r I

[Mingw-w64-public] [PATCH] 2 Small Patches for ARM and Clang building

for jon_y :) Please Review :D From 09c1c796ce38651e10aff9bfb0676a683049bed0 Mon Sep 17 00:00:00 2001 From: Martell Malone martellmal...@gmail.com Date: Sun, 14 Jun 2015 05:43:53 +0100 Subject: [PATCH 1/2] Set a default lib suffix dir for arm diff --git a/mingw-w64-crt/configure b/mingw-w64-crt

[Mingw-w64-public] [PATCH] threadpoollegacyapiset.h: Add QueueTimer functions for WINSTORECOMPAT

Redone the previous patch without the header rename :) Thanks kai 0001-threadpoollegacyapiset.h-Add-QueueTimer-functions-fo.patch Description: Binary data -- Dive into the World of Parallel Programming The Go Parallel

[Mingw-w64-public] [PATCH] most of the netio API are Vista and up, otherwise undefined

http://sourceforge.net/p/mingw-w64/patches/76/ Is this okay for me to commit? Many Thanks Martell -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership

Re: [Mingw-w64-public] [PATCH] most of the netio API are Vista and up, otherwise undefined

for patches is the cause for this. I have found the mailing list a lot more productive to use. Just my 2 cents On Mon, Mar 9, 2015 at 6:42 PM, Martell Malone martellmal...@gmail.com wrote: http://sourceforge.net/p/mingw-w64/patches/76/ Is this okay for me to commit? Many Thanks Martell

Re: [Mingw-w64-public] [PATCH] legacythreadapi: Fixup and correct header name

-name is wrong? Kai 2015-03-05 1:33 GMT+01:00 Martell Malone martellmal...@gmail.com: The header name was incorrect :) I added WinStoreCompat support also Please Review -- Dive into the World of Parallel

Re: [Mingw-w64-public] [PATCH] legacythreadapi: Fixup and correct header name

It seems no known project actually includes them this way yet https://www.google.ie/search?q=Threadpoolapilegacyset.h It's still nice to have the correct name though :) On Sat, Mar 7, 2015 at 4:57 PM, Martell Malone martellmal...@gmail.com wrote: When I saw that these functions were implemented

Re: [Mingw-w64-public] [PATCH] update ws2 defs for wack 3.4

) check no longer necessary here? What has changed that this check isn't required anymore? AFAIR we introduced this check for vlc, so there might be the difference. Regards, Kai 2015-03-04 23:33 GMT+01:00 Martell Malone martellmal...@gmail.com: I send this is previously but it was never

Re: [Mingw-w64-public] any all-in-one Mingw-w64(for win7) to build GIMP 32/64?

Hi Lee, Can any one kindly supply an all-in-one Mingw-w64, which is running on Win7 64bits, can build 32bits and 64bits GIMP for Windows? MSYS2 has this all in one you are asking for. We even have the latest gimp prebuilt for you using the combination you mentioned above. We also provide the

[Mingw-w64-public] [PATCH] add def file for d3dcompiler_47.dll

We need this for windows 8.1 RT apps :) 0001-add-def-file-for-d3dcompiler_47.dll.patch Description: Binary data -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in

[Mingw-w64-public] [PATCH] update ws2 defs for wack 3.4

I send this is previously but it was never applied. So I redone a new one. Yes that is removing a line at the end of a file also There were 2 blank lines. 0001-update-ws2-defs-for-wack-3.4.patch Description: Binary data

[Mingw-w64-public] [PATCH] winbase.h: Add LoadLibraryW for WINSTORECOMPAT

Please Review 0001-winbase.h-Add-LoadLibraryW-for-WINSTORECOMPAT.patch Description: Binary data -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with

[Mingw-w64-public] [PATCH] shlobj.h: Add SHGetFolderPathW for WINSTORECOMPAT

Please Review :) 0001-shlobj.h-Add-SHGetFolderPathW-for-WINSTORECOMPAT.patch Description: Binary data -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in

Re: [Mingw-w64-public] [PATCH] add uuidof support for IMpeg2Demultiplexer and IAMCrossbar

Forgot to attach the patch :) On Thu, Feb 19, 2015 at 6:21 PM, Martell Malone martellmal...@gmail.com wrote: this is needed for dshow inputs Please Review. 0001-add-uuidof-support-for-IMpeg2Demultiplexer-and-IAMCr.patch Description: Binary data

Re: [Mingw-w64-public] lrotl (final)

This has ended up in my spam folder as it did not pass some yahoo checks. I assume others have the same issue which is why there was no reply. Could you give me a commit msg to go with the signed off so we can look at getting it merged On Wed, Feb 11, 2015 at 9:56 AM, dw limegreenso...@yahoo.com

[Mingw-w64-public] [PATCH] add uuidof support for IMpeg2Demultiplexer and IAMCrossbar

this is needed for dshow inputs Please Review. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing,

Re: [Mingw-w64-public] [PATCH] Fix def file for 32-bit d3d11.dll

Thanks alexey :) I've been building only 64bit vlc so I missed this :D On Wed, Feb 18, 2015 at 12:20 PM, Alexey Pavlov alex...@gmail.com wrote: -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server

  1   2   >