Re: [Mingw-w64-public] [PATCH v11] crt: Recognize cygwin ptys in isatty
On Thu, Jan 19, 2017 at 12:54:33AM +0500, Mihail Konev wrote: > On Sat, Jan 07, 2017 at 10:52:40AM +0500, Mihail Konev wrote: > > Signed-off-by: Mihail Konev > > Moved-from: https://github.com/Alexpux/mingw-w64/pull/3 > > Reference: https://cygwin.com/ml/cygwin-developers/2016-11/msg2.html > > --- > > v11: const the exported isatty > > > > mingw-w64-crt/Makefile.am | 1 + > > mingw-w64-crt/def-include/msvcrt-common.def.in | 2 +- > > mingw-w64-crt/lib64/moldname-msvcrt.def| 2 +- > > mingw-w64-crt/stdio/isatty.c | 111 > > + > > mingw-w64-headers/crt/io.h | 1 + > > 5 files changed, 115 insertions(+), 2 deletions(-) > > create mode 100644 mingw-w64-crt/stdio/isatty.c > > > > Maybe making Cygwin present Win32 applications with a Windows Console > (which mirrors pty stdout and drives pty stdin) would be more correct > (as it allows smoother interoperability)? > That is, this should be solvable without having to touch MinGW. (By instead improving winpty and/or its support on Cygwin/MSYS). -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Align thread entry point stack
Hi, I've recently re-stumbled upon this. As far as I can tell it hasn't been commited. Was there some more discussion on the topic or did it simply get forgotten? -- Adrien Nader On Mon, Aug 22, 2016, Kai Tietz wrote: > Hello Aleksey, > > 2016-08-22 13:52 GMT+02:00 Aleksey Vasenev : > > __attribute__((aligned)) don't work for stack variables in threads created > > with _beginthreadex without alignment. > > > > Signed-off-by: Aleksey Vasenev > > --- > > send it again > > github: https://github.com/Ratio2/mingw-w64/tree/align > > fix crash: ffmpeg -f lavfi -i testsrc -vcodec libvpx -threads 2 -f null - > > problem discuss: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2236 > > > > _beginthreadex does not align the stack on 16-byte boundary as expected > > by gcc. > > > > On x86 targets, the force_align_arg_pointer attribute may be applied to > > individual function definitions, generating an alternate prologue and > > epilogue that realigns the run-time stack if necessary. This supports > > mixing legacy codes that run with a 4-byte aligned stack with modern > > codes that keep a 16-byte stack for SSE compatibility. > > https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html > > > > mingw-w64-libraries/winpthreads/src/thread.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/mingw-w64-libraries/winpthreads/src/thread.c > > b/mingw-w64-libraries/winpthreads/src/thread.c > > index 565ea48..c771daf 100644 > > --- a/mingw-w64-libraries/winpthreads/src/thread.c > > +++ b/mingw-w64-libraries/winpthreads/src/thread.c > > @@ -1454,6 +1454,9 @@ pthread_setcanceltype (int type, int *oldtype) > >return 0; > > } > > > > +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2) > > +__attribute__((force_align_arg_pointer)) > > +#endif > > int > > pthread_create_wrapper (void *args) > > { > > -- > > 2.9.1 > > I guess you have tested your suggested patch? Over all it looks > reasonable to me. > > Regards, > Kai > > -- > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Implement fused multiply-add (FMA) funcitons for x86 families properly
Hmm. It seems a bit backwards to have the function that takes a 'long double' calling the function that takes a 'double.' Yes, they are both the same size on ARM, but I think I would have gone the other way. Plus I kinda like having all the implementations in one file (fmal.c). Other than that, this looks ok to me. Building for ARM with clang seems to work (although I have no way to run it). dw On 1/20/2017 1:57 AM, lhmouse wrote: > The mail has been being rejected for spamming for a few hours. > Hope it wouldn't be this time. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Implement fused multiply-add (FMA) funcitons for x86 families properly
On 2017/1/23 9:08, David Wohlferd wrote: > Hmm. > > It seems a bit backwards to have the function that takes a 'long double' > calling the function that takes a 'double.' Yes, they are both the same > size on ARM, but I think I would have gone the other way. Plus I kinda > like having all the implementations in one file (fmal.c). I prefer that too. At the moment I have to follow what mingw-w64 has been doing. That is, keeping separated functions for {f,,l} in different files. > Other than that, this looks ok to me. Building for ARM with clang seems > to work (although I have no way to run it). Thanks for testing. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public