Re: gcc and 128-bit compare/exchange

2020-03-11 Thread Brian Inglis
On 2020-03-11 00:13, Eliot Moss wrote: > On 3/11/2020 1:31 AM, Brian Inglis wrote: > > A quick followup: I was able to get __sync_val_compare_and_swap_16 to work > (and its bool form).  That will do for now, though of course it's > deprecated. > > This does get me the inlined asm cod

Re: gcc and 128-bit compare/exchange

2020-03-11 Thread Achim Gratz
Eliot Moss writes: > What I am really reporting is that Cygwin is giving the pthread mutex form > when it should not be. My CPU clearly has the capability, and the compiler > clearly > knows how to emit the instruction, since the __sync form does it. What is > mysterious and tangled is why libat

Re: cygwin-3.1.0 and mintty from desktop shortcut

2020-03-11 Thread Achim Gratz
Achim Gratz writes: >>> There is some undesirable interaction when I try to start mintty from my >>> desktop shortcut. Mintty itself starts OK, but any Cygwin program that >>> mintty starts (whether a shell or something else) just goes into a >>> spinloop (Windows says it's mostly kernel time). U

Re: cygwin-3.1.0 and mintty from desktop shortcut

2020-03-11 Thread Corinna Vinschen
Hi Takashi, would you mind to take a look? The mutex is only used in fhandler_pty_master::pty_master_fwd_thread if the pseudo console is used. Unfortunately I don't see the faintest hint in the starce why this occurs. It happens pretty early at startup. Thanks, Corinna On Mar 11 18:47, Achi

Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Åke Rehnman via Cygwin
Hello all, opening a file (serial port) with O_NONBLOCK and subsequently setting termios VMIN and VTIME > 0 makes read() never ever return any data (returns EAGAIN indefinitely). Don't ask my why one would want to do something like this but apparently the "screen" program think this is a goo

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Brian Inglis
On 2020-03-11 14:48, Åke Rehnman via Cygwin wrote: > opening a file (serial port) with O_NONBLOCK and subsequently setting termios > VMIN and VTIME > 0 makes read() never ever return any data (returns EAGAIN > indefinitely). > Don't ask my why one would want to do something like this but apparently

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Norton Allen
On 3/11/2020 5:55 PM, Brian Inglis wrote: VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO delivery; see: While I agree with everything else you said there, I don't believe either of these are true, unless by 'implies' you mean that's how you usually do it. I have done a lot o

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Åke Rehnman via Cygwin
On 2020-03-11 22:55, Brian Inglis wrote: VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO delivery; see: https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf https://www.cmrr.umn.edu/~strupp/serial.html https://en.wikibooks.org/wiki/Serial_Program

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Norton Allen
On 3/11/2020 9:04 PM, Åke Rehnman via Cygwin wrote: On 2020-03-11 22:55, Brian Inglis wrote: VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO delivery; see: https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf https://www.cmrr.umn.edu/~strupp/serial.html htt

Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file

2020-03-11 Thread Åke Rehnman via Cygwin
On 2020-03-12 02:08, Norton Allen wrote: Correct me if I am wrong, but O_NDELAY is not the same as O_NONBLOCK At least for cygwin those two are exactly the same... I think... #define _FNONBLOCK  0x4000  /* non blocking I/O (POSIX style) */ #define _FNDELAY    _FNONBLOCK  /* non blo

Re: cygwin-3.1.0 and mintty from desktop shortcut

2020-03-11 Thread Rainer Emrich
Hi Corinna, Am 11.03.2020 um 20:51 schrieb Corinna Vinschen: > Hi Takashi, > > would you mind to take a look? The mutex is only used in > fhandler_pty_master::pty_master_fwd_thread if the pseudo console is > used. Unfortunately I don't see the faintest hint in the starce why > this occurs. It

Re: gcc and 128-bit compare/exchange

2020-03-11 Thread Eliot Moss
On 3/11/2020 12:30 PM, Brian Inglis wrote: On 2020-03-11 00:13, Eliot Moss wrote: On 3/11/2020 1:31 AM, Brian Inglis wrote: There are gcc bugzilla comments about requiring gcc to be built with glibc libatomic to guarantee indirect inline functions support, and presumably glibc detecting gcc i