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
