cpp /usr/include/threads.h fails; modfl segfaults

cpp /usr/include/threads.h fails; modfl segfaults

[airplanemath]

Hello,

I have two reports.  A brief description of the system:
$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

The first report:

$ cpp /usr/include/threads.h
# 1 "/usr/include/threads.h"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/threads.h"
/usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
file or directory
   30 | #include <machine/_threads.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

$ cygcheck -p machine/_threads.h
Found 0 matches for machine/_threads.h

$ cygcheck -f /usr/include/threads.h
cygwin-devel-3.1.7-1

$ cygcheck -c cygwin-devel
Cygwin Package Information
Package              Version        Status
cygwin-devel         3.1.7-1        OK

I'm not sure what to do from here.  I don't remember where I ran into this,
but this feels like something that shouldn't happen

The second report:

$ cat test.c
#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  long double a, b, c;
  char *num_end = NULL;
  a = b = c = 0.0L;
  if (argc != 2) {
    fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
    exit(1);
  }
  a = strtold(argv[1], &num_end);
  b = modfl(a, &c);
  printf("%Lf %Lf %Lf\n", a, b, c);
  return 0;
}

$ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe

$ ./test.exe 123.456
Segmentation fault (core dumped)

$ gdb --args ./test.exe 123.456
GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
...
Reading symbols from ./test.exe...
(gdb) break modfl
(gdb) run
Starting program: /home/Daniel/test.exe 123.456
[New Thread 13960.0x3cf4]
[New Thread 13960.0xbdc]
[New Thread 13960.0x4028]
[New Thread 13960.0x3224]
[New Thread 13960.0x3810]
[New Thread 13960.0x1ae4]
[New Thread 13960.0x3714]
[Thread 13960.0x4028 exited with code 3697672192]
[Thread 13960.0x3714 exited with code 0]

Thread 1 "test" hit Breakpoint 1, modfl (value=<optimized out>,
iptr=iptr@entry=0xffffcbd0) at
/usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
16        asm ("subq $8, %%rsp\n"
(gdb) step
38        if (iptr)
(gdb) step
39          *iptr = int_part;
(gdb) step
40        return (isinf (value) ?  0.0L : value - int_part);
(gdb) step
      0 [main] test 28439 cygwin_exception::open_stackdumpfile: Dumping
stack trace to test.exe.stackdump
[Thread 13960.0x3b5c exited with code 35584]
[Thread 13960.0x1ae4 exited with code 35584]
[Thread 13960.0x3810 exited with code 35584]
[Thread 13960.0xbdc exited with code 35584]
[Thread 13960.0x3cf4 exited with code 35584]
[Inferior 1 (process 13960) exited with code 0105400]
(gdb)

isinf and isinfl both work just fine, so I'm not sure what's going on there.

Please let me know if you need more information.

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Ken Brown]

On 8/29/2020 8:52 AM, airplanemath via Cygwin wrote:
> Hello,
> 
> I have two reports.  A brief description of the system:
> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

In the future, please use two separate emails for two unrelated bug reports.

> The first report:
> 
> $ cpp /usr/include/threads.h
> # 1 "/usr/include/threads.h"
> # 1 "<built-in>"
> # 1 "<command-line>"
> # 1 "/usr/include/threads.h"
> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
> file or directory
>     30 | #include <machine/_threads.h>
>        |          ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> 
> $ cygcheck -p machine/_threads.h
> Found 0 matches for machine/_threads.h

It looks like /usr/include/threads.h is a Newlib header that's intended for 
RTEMS.  Here's the commit where it was introduced:

commit c98d01ee0cbc6eb7bbca8f2cde4a46b90ded3784
Author: Jeff Johnston <jjohnstn@redhat.com>
Date:   Tue Oct 13 17:52:34 2015 -0400

     Import <threads.h> from latest FreeBSD.

     - Move types and defines to
       <machine/_threads.h> so that it can be customized per target.

             * libc/include/threads.h: New.
             * libc/sys/rtems/include/machine/_threads.h: Likewise.

There's no machine/_threads.h in the repository for any platform other than 
RTEMS.  My guess is that it shouldn't be included in the Cygwin distro.

> The second report:
> 
> $ cat test.c
> #include <math.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char *argv[]) {
>    long double a, b, c;
>    char *num_end = NULL;
>    a = b = c = 0.0L;
>    if (argc != 2) {
>      fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>      exit(1);
>    }
>    a = strtold(argv[1], &num_end);
>    b = modfl(a, &c);
>    printf("%Lf %Lf %Lf\n", a, b, c);
>    return 0;
> }
> 
> $ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
> 
> $ ./test.exe 123.456
> Segmentation fault (core dumped)
> 
> $ gdb --args ./test.exe 123.456
> GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
> ...
> Reading symbols from ./test.exe...
> (gdb) break modfl
> (gdb) run
> Starting program: /home/Daniel/test.exe 123.456
> [New Thread 13960.0x3cf4]
> [New Thread 13960.0xbdc]
> [New Thread 13960.0x4028]
> [New Thread 13960.0x3224]
> [New Thread 13960.0x3810]
> [New Thread 13960.0x1ae4]
> [New Thread 13960.0x3714]
> [Thread 13960.0x4028 exited with code 3697672192]
> [Thread 13960.0x3714 exited with code 0]
> 
> Thread 1 "test" hit Breakpoint 1, modfl (value=<optimized out>,
> iptr=iptr@entry=0xffffcbd0) at
> /usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
> 16        asm ("subq $8, %%rsp\n"
> (gdb) step
> 38        if (iptr)
> (gdb) step
> 39          *iptr = int_part;
> (gdb) step
> 40        return (isinf (value) ?  0.0L : value - int_part);
> (gdb) step
>        0 [main] test 28439 cygwin_exception::open_stackdumpfile: Dumping
> stack trace to test.exe.stackdump
> [Thread 13960.0x3b5c exited with code 35584]
> [Thread 13960.0x1ae4 exited with code 35584]
> [Thread 13960.0x3810 exited with code 35584]
> [Thread 13960.0xbdc exited with code 35584]
> [Thread 13960.0x3cf4 exited with code 35584]
> [Inferior 1 (process 13960) exited with code 0105400]
> (gdb)
> 
> isinf and isinfl both work just fine, so I'm not sure what's going on there.

I built a version of cygwin1.dll without optimization in the hopes of making 
debugging easier, but the problem doesn't occur with that DLL.  So this is 
somehow tied up with optimization.  BTW, isinf is a macro that expands to 
__builtin_isinf_sign, again suggesting that optimization is involved.

That's as far as I can take it.

Ken

Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults

[Eliot Moss]

On 8/29/2020 1:57 PM, Ken Brown via Cygwin wrote:

 >> #include <math.h>
 >> #include <stdio.h>
 >> #include <stdlib.h>
 >>
 >> int main(int argc, char *argv[]) {
 >>    long double a, b, c;
 >>    char *num_end = NULL;
 >>    a = b = c = 0.0L;
 >>    if (argc != 2) {
 >>      fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
 >>      exit(1);
 >>    }
 >>    a = strtold(argv[1], &num_end);
 >>    b = modfl(a, &c);
 >>    printf("%Lf %Lf %Lf\n", a, b, c);
 >>    return 0;
 >> }

I'm using gcc 9.3, and this dies in modfl where it is trying to store the result back.  The -O level 
does not seem to matter.  modfl seems seriously broken.  It comes from winsup in
base cygwin.  I was running 3.1.6-1.  I upgraded to 3.1.7-1 and got the same thing.  This
is the 64-bit cygwin.

The 32-bit version of cygwin 3.1.6-1 processes and runs this just fine.  Same version
of gcc.

It seems the math functions in winsup were not built quite right ...

Regards - Eliot Moss

Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults

[Ken Brown]

On 8/29/2020 5:41 PM, Eliot Moss wrote:
> It seems the math functions in winsup were not built quite right ...

That's a pretty broad generalization to make based on one reported bug (which 
Corinna fixed within 24 hours of the report).

Ken

Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults

[Eliot Moss]

On 8/30/2020 12:11 PM, Ken Brown wrote:
> On 8/29/2020 5:41 PM, Eliot Moss wrote:
>> It seems the math functions in winsup were not built quite right ...
> 
> That's a pretty broad generalization to make based on one reported bug (which Corinna fixed within 
> 24 hours of the report).

I certainly did not mean to offend or demean anyone or their work.
I think what I said is true, in some sense - that particular function
was broken in certain versions.  I sing Corinna's praises all the time,
and greatly value all the volunteer work here!  (Sometimes manage to
help a little myself.)  What I was pointing to was that the issue was
not in the OP's program or gcc's compilation or optimization thereof,
but that the issue was in the (compiled version of the) mod function
itself ...

This helps indicate who might be able to diagnose and fix it ...

Regards - EM

Re: cpp /usr/include/threads.h fails; modfl segfaults

[airplanemath]

On 8/29/2020 1:57 PM, Ken Brown wrote:
> On 8/29/2020 8:52 AM, airplanemath via Cygwin wrote:
>> Hello,
>>
>> I have two reports.� A brief description of the system:
>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
>> Cygwin
>
> In the future, please use two separate emails for two unrelated bug
> reports.


Will do.

>
>> The first report:
>>
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> # 1 "<built-in>"
>> # 1 "<command-line>"
>> # 1 "/usr/include/threads.h"
>> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
>> file or directory
>> ��� 30 | #include <machine/_threads.h>
>> ������ |��������� ^~~~~~~~~~~~~~~~~~~~
>> compilation terminated.
>>
>> $ cygcheck -p machine/_threads.h
>> Found 0 matches for machine/_threads.h
>
> It looks like /usr/include/threads.h is a Newlib header that's
> intended for RTEMS.� Here's the commit where it was introduced:
>
> commit c98d01ee0cbc6eb7bbca8f2cde4a46b90ded3784
> Author: Jeff Johnston
> Date:�� Tue Oct 13 17:52:34 2015 -0400
>
> ��� Import <threads.h> from latest FreeBSD.
>
> ��� - Move types and defines to
> ����� <machine/_threads.h> so that it can be customized per target.
>
> ����������� * libc/include/threads.h: New.
> ����������� * libc/sys/rtems/include/machine/_threads.h: Likewise.
>
> There's no machine/_threads.h in the repository for any platform other
> than RTEMS.�
> My guess is that it shouldn't be included in the Cygwin distro.


Okay.� I can work on convincing whatever program wanted this that the
header doesn't
exist and see what happens, assuming I can remember which program wanted
this.

>
>> The second report:
>>
>> $ cat test.c
>> #include <math.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[]) {
>> �� long double a, b, c;
>> �� char *num_end = NULL;
>> �� a = b = c = 0.0L;
>> �� if (argc != 2) {
>> ���� fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>> ���� exit(1);
>> �� }
>> �� a = strtold(argv[1], &num_end);
>> �� b = modfl(a, &c);
>> �� printf("%Lf %Lf %Lf\n", a, b, c);
>> �� return 0;
>> }
>>
>> $ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
>>
>> $ ./test.exe 123.456
>> Segmentation fault (core dumped)
>>
>> $ gdb --args ./test.exe 123.456
>> GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
>> ...
>> Reading symbols from ./test.exe...
>> (gdb) break modfl
>> (gdb) run
>>
>> Thread 1 "test" hit Breakpoint 1, modfl (value=<optimized out>,
>> iptr=iptr@entry=0xffffcbd0) at
>> /usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
>> ...
>> 40������� return (isinf (value) ?� 0.0L : value - int_part);
>> (gdb) step
>> ������ 0 [main] test 28439 cygwin_exception::open_stackdumpfile: Dumping
>> ...
>> (gdb)
>>
>> isinf and isinfl both work just fine, so I'm not sure what's going on
>> there.
>
> I built a version of cygwin1.dll without optimization in the hopes of
> making debugging easier, but the problem doesn't occur with that DLL.�
> So this is somehow tied up with optimization.� BTW, isinf is a macro
> that expands to __builtin_isinf_sign, again suggesting that
> optimization is involved.
>
> That's as far as I can take it.

Stepping back through Cygwin releases, I find:

$ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe

$ ./test.exe 123.456
123.456000 0.456000 123.000000

$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTNAME} 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin

$ gcc --version
gcc (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.� There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


3.1.5 crashed the same way as 3.1.7.� There's nothing obvious in the
3.1.5 announcement [1],
so I'm stuck again.

>
> Ken


[1] https://cygwin.com/pipermail/cygwin-announce/2020-June/009561.html

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Ken Brown]

On 8/29/2020 9:21 PM, airplanemath via Cygwin wrote:
> Stepping back through Cygwin releases, I find:
> 
> $ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
> 
> $ ./test.exe 123.456
> 123.456000 0.456000 123.000000
> 
> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> 
> $ gcc --version
> gcc (GCC) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.� There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 3.1.5 crashed the same way as 3.1.7.� There's nothing obvious in the
> 3.1.5 announcement [1],
> so I'm stuck again.

OK, so the problem was introduced between 3.1.4 and 3.1.5.  It should be pretty 
easy to bisect and find the culprit.  I'll do that tomorrow if no one beats me 
to it.

Ken

Re: cpp /usr/include/threads.h fails; modfl segfaults

[ASSI]

Ken Brown via Cygwin writes:
> OK, so the problem was introduced between 3.1.4 and 3.1.5.  It should
> be pretty easy to bisect and find the culprit.  I'll do that tomorrow
> if no one beats me to it.

The most likely culprit would be this I think:

https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=4ad9ba42fc3dd116bad8b9cb89d434256d3431fb

If so and depending on why exactly it fails, there might be more fallout
from other similar changes.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Brian Inglis]

On 2020-08-30 00:23, ASSI wrote:
> Ken Brown via Cygwin writes:
>> OK, so the problem was introduced between 3.1.4 and 3.1.5.  It should
>> be pretty easy to bisect and find the culprit.  I'll do that tomorrow
>> if no one beats me to it.
> 
> The most likely culprit would be this I think:
> 
> https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=4ad9ba42fc3dd116bad8b9cb89d434256d3431fb
> 
> If so and depending on why exactly it fails, there might be more fallout
> from other similar changes.

OP debugged to display winsup/cygwin/math/modfl.c assembler that hasn't
changed since added, so compiler, build, or runtime environment updates may have
changed the code generated or used e.g. predefined symbols, build flags, runtime
CPU features.

Does Cygwin detect and allow GCC builtins to be used where available, keeping
the function available for fallback where the compiler can't use the builtin?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Aug 29 08:52, airplanemath via Cygwin wrote:
> Hello,
> 
> I have two reports.  A brief description of the system:
> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> 
> The first report:
> 
> $ cpp /usr/include/threads.h
> # 1 "/usr/include/threads.h"
> # 1 "<built-in>"
> # 1 "<command-line>"
> # 1 "/usr/include/threads.h"
> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
> file or directory
>    30 | #include <machine/_threads.h>
>       |          ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.

The reason for this is, as Ken already pointed out, that
machine/_threads.h only existed for RTEMS, not for any other target
supported by newlib.  Worse, Cygwin never got around to implement the
C11 threads functions yet.

I added these functions as wrappers around pthread functionality, code
taken from FreeBSD.  I ran the glibc testsuite on them, and after fixing
the bugs in the glibc testsuite (d'oh), the tests ran successfully.

> $ cat test.c
> #include <math.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char *argv[]) {
>   long double a, b, c;
>   char *num_end = NULL;
>   a = b = c = 0.0L;
>   if (argc != 2) {
>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>     exit(1);
>   }
>   a = strtold(argv[1], &num_end);
>   b = modfl(a, &c);
>   printf("%Lf %Lf %Lf\n", a, b, c);
>   return 0;
> }

This is a bug in the assembler code taken from Mingw-w64.  The bug has
been fixed upstream, so I just pulled in the upstream fixes.

Thus, both of the above problems should be fixed now.  I created a
developer snapshot and uploaed it to https://cygwin.com/snapshots/ You
need to grab the full tar file and install at least the following files
to your installation after backing up the original files from 3.1.7:

  usr/bin/cygwin1.dll	(this is pre-release 3.2.0)
  usr/lib/libcygwin.a
  usr/include/limits.h
  usr/include/pthread.h
  usr/include/machine/_threads.h

Thanks for the report.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: cpp /usr/include/threads.h fails; modfl segfaults

[airplanemath]

Corinna Vinschen writes:
> On Aug 29 08:52, airplanemath via Cygwin wrote:
>> Hello,
>> 
>> I have two reports.  A brief description of the system:
>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>> 
>> The first report:
>> 
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> # 1 "<built-in>"
>> # 1 "<command-line>"
>> # 1 "/usr/include/threads.h"
>> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
>> file or directory
>>    30 | #include <machine/_threads.h>
>>       |          ^~~~~~~~~~~~~~~~~~~~
>> compilation terminated.
>
> The reason for this is, as Ken already pointed out, that
> machine/_threads.h only existed for RTEMS, not for any other target
> supported by newlib.  Worse, Cygwin never got around to implement the
> C11 threads functions yet.
>
> I added these functions as wrappers around pthread functionality, code
> taken from FreeBSD.  I ran the glibc testsuite on them, and after fixing
> the bugs in the glibc testsuite (d'oh), the tests ran successfully.
>
The header makes it through the preprocessor for me now.  Thank you.

>> $ cat test.c
>> #include <math.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>> 
>> int main(int argc, char *argv[]) {
>>   long double a, b, c;
>>   char *num_end = NULL;
>>   a = b = c = 0.0L;
>>   if (argc != 2) {
>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>>     exit(1);
>>   }
>>   a = strtold(argv[1], &num_end);
>>   b = modfl(a, &c);
>>   printf("%Lf %Lf %Lf\n", a, b, c);
>>   return 0;
>> }
>
> This is a bug in the assembler code taken from Mingw-w64.  The bug has
> been fixed upstream, so I just pulled in the upstream fixes.

The test program now finishes without segfaulting, and gives the
expected answer.  Thanks again.
>
> Thus, both of the above problems should be fixed now.  I created a
> developer snapshot and uploaed it to https://cygwin.com/snapshots/ You
> need to grab the full tar file and install at least the following files
> to your installation after backing up the original files from 3.1.7:
>
>   usr/bin/cygwin1.dll	(this is pre-release 3.2.0)
>   usr/lib/libcygwin.a
>   usr/include/limits.h
>   usr/include/pthread.h
>   usr/include/machine/_threads.h
>
Is it okay to leave these in place to be overwritten by 3.2.0, or should
I move the old versions back?

> Thanks for the report.
>
Thanks for the prompt response.
>
> Corinna

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Aug 30 15:21, airplanemath--- via Cygwin wrote:
> Corinna Vinschen writes:
> > On Aug 29 08:52, airplanemath via Cygwin wrote:
> >> Hello,
> >> 
> >> I have two reports.  A brief description of the system:
> >> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> >> 
> >> The first report:
> >> [...]
> > I added [C11 threads] functions as wrappers around pthread functionality, code
> > taken from FreeBSD.  I ran the glibc testsuite on them, and after fixing
> > the bugs in the glibc testsuite (d'oh), the tests ran successfully.
> >
> The header makes it through the preprocessor for me now.  Thank you.
> [...]
> > This is a bug in the assembler code taken from Mingw-w64.  The bug has
> > been fixed upstream, so I just pulled in the upstream fixes.
> 
> The test program now finishes without segfaulting, and gives the
> expected answer.  Thanks again.
> >
> > Thus, both of the above problems should be fixed now.  I created a
> > developer snapshot and uploaed it to https://cygwin.com/snapshots/ You
> > need to grab the full tar file and install at least the following files
> > to your installation after backing up the original files from 3.1.7:
> >
> >   usr/bin/cygwin1.dll	(this is pre-release 3.2.0)
> >   usr/lib/libcygwin.a
> >   usr/include/limits.h
> >   usr/include/pthread.h
> >   usr/include/machine/_threads.h
> >
> Is it okay to leave these in place to be overwritten by 3.2.0, or should
> I move the old versions back?

It's ok to leave them in place, just keep in mind that executables
built with this version and using the new symbols won't run under
3.1.7 (e. g., on a collegue's machine).

> > Thanks for the report.
> >
> Thanks for the prompt response.

You're welcome.  And thanks for testing!


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Brian Inglis]

On 2020-08-30 07:00, Corinna Vinschen wrote:
> On Aug 29 08:52, airplanemath via Cygwin wrote:
>> I have two reports.  A brief description of the system:
>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
...
>> $ cat test.c
>> #include <math.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[]) {
>>   long double a, b, c;
>>   char *num_end = NULL;
>>   a = b = c = 0.0L;
>>   if (argc != 2) {
>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>>     exit(1);
>>   }
>>   a = strtold(argv[1], &num_end);
>>   b = modfl(a, &c);
>>   printf("%Lf %Lf %Lf\n", a, b, c);
>>   return 0;
>> }
> 
> This is a bug in the assembler code taken from Mingw-w64.  The bug has
> been fixed upstream, so I just pulled in the upstream fixes.

The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
to do. Is this inconsistent treatment correct?

diff --git a/winsup/cygwin/math/modfl.c b/winsup/cygwin/math/modfl.c
index af75a8b..ef1ab16 100644 (file)
--- a/winsup/cygwin/math/modfl.c
+++ b/winsup/cygwin/math/modfl.c
@@ -21,7 +21,7 @@ modfl (long double value, long double* iptr)
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"
@@ -31,7 +31,7 @@ modfl (long double value, long double* iptr)
     "fldcw (%%esp)\n"
     "frndint\n"
     "fldcw 4(%%esp)\n"
-    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value) : "eax");
/* round */
 #else
   int_part = truncl(value);
 #endif

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Aug 30 14:39, Brian Inglis wrote:
> On 2020-08-30 07:00, Corinna Vinschen wrote:
> > On Aug 29 08:52, airplanemath via Cygwin wrote:
> >> I have two reports.  A brief description of the system:
> >> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> ...
> >> $ cat test.c
> >> #include <math.h>
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >>
> >> int main(int argc, char *argv[]) {
> >>   long double a, b, c;
> >>   char *num_end = NULL;
> >>   a = b = c = 0.0L;
> >>   if (argc != 2) {
> >>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
> >>     exit(1);
> >>   }
> >>   a = strtold(argv[1], &num_end);
> >>   b = modfl(a, &c);
> >>   printf("%Lf %Lf %Lf\n", a, b, c);
> >>   return 0;
> >> }
> > 
> > This is a bug in the assembler code taken from Mingw-w64.  The bug has
> > been fixed upstream, so I just pulled in the upstream fixes.
> 
> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
> to do. Is this inconsistent treatment correct?

You may be right that this is not necessary on i686, but it doesn't
hurt either and I'd like to stick to the upstream code if possible.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Brian Inglis]

On 2020-08-31 01:35, Corinna Vinschen wrote:
> On Aug 30 14:39, Brian Inglis wrote:
>> On 2020-08-30 07:00, Corinna Vinschen wrote:
>>> On Aug 29 08:52, airplanemath via Cygwin wrote:
>>>> I have two reports.  A brief description of the system:
>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>> ...
>>>> $ cat test.c
>>>> #include <math.h>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>>
>>>> int main(int argc, char *argv[]) {
>>>>   long double a, b, c;
>>>>   char *num_end = NULL;
>>>>   a = b = c = 0.0L;
>>>>   if (argc != 2) {
>>>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>>>>     exit(1);
>>>>   }
>>>>   a = strtold(argv[1], &num_end);
>>>>   b = modfl(a, &c);
>>>>   printf("%Lf %Lf %Lf\n", a, b, c);
>>>>   return 0;
>>>> }
>>>
>>> This is a bug in the assembler code taken from Mingw-w64.  The bug has
>>> been fixed upstream, so I just pulled in the upstream fixes.
>>
>> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
>> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
>> to do. Is this inconsistent treatment correct?
> 
> You may be right that this is not necessary on i686, but it doesn't
> hurt either and I'd like to stick to the upstream code if possible.

The upstream patch changed only amd64/x86_64 code sequences for multiple modules
including modfl, and left i386/x86 untouched for those modules.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Aug 31 09:37, Brian Inglis wrote:
> On 2020-08-31 01:35, Corinna Vinschen wrote:
> > On Aug 30 14:39, Brian Inglis wrote:
> >> On 2020-08-30 07:00, Corinna Vinschen wrote:
> >>> On Aug 29 08:52, airplanemath via Cygwin wrote:
> >>>> I have two reports.  A brief description of the system:
> >>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> >> ...
> >>>> $ cat test.c
> >>>> #include <math.h>
> >>>> #include <stdio.h>
> >>>> #include <stdlib.h>
> >>>>
> >>>> int main(int argc, char *argv[]) {
> >>>>   long double a, b, c;
> >>>>   char *num_end = NULL;
> >>>>   a = b = c = 0.0L;
> >>>>   if (argc != 2) {
> >>>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
> >>>>     exit(1);
> >>>>   }
> >>>>   a = strtold(argv[1], &num_end);
> >>>>   b = modfl(a, &c);
> >>>>   printf("%Lf %Lf %Lf\n", a, b, c);
> >>>>   return 0;
> >>>> }
> >>>
> >>> This is a bug in the assembler code taken from Mingw-w64.  The bug has
> >>> been fixed upstream, so I just pulled in the upstream fixes.
> >>
> >> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
> >> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
> >> to do. Is this inconsistent treatment correct?
> > 
> > You may be right that this is not necessary on i686, but it doesn't
> > hurt either and I'd like to stick to the upstream code if possible.
> 
> The upstream patch changed only amd64/x86_64 code sequences for multiple modules
> including modfl, and left i386/x86 untouched for those modules.

$ git remote -v
origin	https://git.code.sourceforge.net/p/mingw-w64/mingw-w64 (fetch)
origin	https://git.code.sourceforge.net/p/mingw-w64/mingw-w64 (push)
$ git st
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ $ git log --oneline -2 -- mingw-w64-crt/math/modfl.c
fac3a8a6e4ca crt: Add "volatile" to all inline assembly snippets under math
9a2479858b3b mingw-w64-crt/math/modf{,f,l}.c: Fix segment faults in modf(), modff() and modfl().
$ git show 9a2479858b3b
[...]
diff --git a/mingw-w64-crt/math/modfl.c b/mingw-w64-crt/math/modfl.c
index af75a8b8cf60..ef1ab16ce256 100644
--- a/mingw-w64-crt/math/modfl.c
+++ b/mingw-w64-crt/math/modfl.c
@@ -21,7 +21,7 @@ modfl (long double value, long double* iptr)
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"
@@ -31,7 +31,7 @@ modfl (long double value, long double* iptr)
     "fldcw (%%esp)\n"
     "frndint\n"
     "fldcw 4(%%esp)\n"
-    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #else
   int_part = truncl(value);
 #endif


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 4031 bytes --]

On 2020-08-31 12:45, Corinna Vinschen wrote:
> On Aug 31 09:37, Brian Inglis wrote:
>> On 2020-08-31 01:35, Corinna Vinschen wrote:
>>> On Aug 30 14:39, Brian Inglis wrote:
>>>> On 2020-08-30 07:00, Corinna Vinschen wrote:
>>>>> On Aug 29 08:52, airplanemath via Cygwin wrote:
>>>>>> I have two reports.  A brief description of the system:
>>>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>>>> ...
>>>>>> $ cat test.c
>>>>>> #include <math.h>
>>>>>> #include <stdio.h>
>>>>>> #include <stdlib.h>
>>>>>>
>>>>>> int main(int argc, char *argv[]) {
>>>>>>   long double a, b, c;
>>>>>>   char *num_end = NULL;
>>>>>>   a = b = c = 0.0L;
>>>>>>   if (argc != 2) {
>>>>>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>>>>>>     exit(1);
>>>>>>   }
>>>>>>   a = strtold(argv[1], &num_end);
>>>>>>   b = modfl(a, &c);
>>>>>>   printf("%Lf %Lf %Lf\n", a, b, c);
>>>>>>   return 0;
>>>>>> }
>>>>>
>>>>> This is a bug in the assembler code taken from Mingw-w64.  The bug has
>>>>> been fixed upstream, so I just pulled in the upstream fixes.
>>>>
>>>> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
>>>> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
>>>> to do. Is this inconsistent treatment correct?
>>>
>>> You may be right that this is not necessary on i686, but it doesn't
>>> hurt either and I'd like to stick to the upstream code if possible.
>>
>> The upstream patch changed only amd64/x86_64 code sequences for multiple modules
>> including modfl, and left i386/x86 untouched for those modules.

Just pointing out that they only modify their amd64/x86_64 code which doesn't
push/pop rax/eax:

diff -ru mingw-w64-v4.0.2/mingw-w64-crt/math/modfl.c
mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modfl.c
--- mingw-w64-v4.0.2/mingw-w64-crt/math/modfl.c	2015-04-11 11:37:30.000000000 -0400
+++ mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modfl.c	2015-05-07
11:05:57.000000000 -0400
@@ -21,7 +21,7 @@
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"

and their other patches do exactly the same for modf.c and modff.c, and not
their i386/x86 code which pushes/pops eax; where you do (adding lines back for
context) mark eax as clobbered after a pop in x86 patch:

> diff --git a/mingw-w64-crt/math/modfl.c b/mingw-w64-crt/math/modfl.c
> index af75a8b8cf60..ef1ab16ce256 100644
> --- a/mingw-w64-crt/math/modfl.c
> +++ b/mingw-w64-crt/math/modfl.c
#if defined(_AMD64_) || defined(__x86_64__)
     asm volatile ("subq $8, %%rsp\n"
       "fnstcw 4(%%rsp)\n"
       "movzwl 4(%%rsp), %%eax\n"
       "orb $12, %%ah\n"
       "movw %%ax, (%%rsp)\n"
> @@ -21,7 +21,7 @@ modfl (long double value, long double* iptr)
>      "fldcw (%%rsp)\n"
>      "frndint\n"
>      "fldcw 4(%%rsp)\n"
> -    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
> +    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
>  #elif defined(_X86_) || defined(__i386__)
>    asm ("push %%eax\n\tsubl $8, %%esp\n"
>      "fnstcw 4(%%esp)\n"
       "movzwl 4(%%esp), %%eax\n"
       "orb $12, %%ah\n"
       "movw %%ax, (%%esp)\n"
> @@ -31,7 +31,7 @@ modfl (long double value, long double* iptr)
>      "fldcw (%%esp)\n"
>      "frndint\n"
>      "fldcw 4(%%esp)\n"
> -    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value)); /* round */
> +    "addl $8, %%esp\n\tpop %%eax\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

[-- Attachment #2: mingw-w64-v4.0.2.patch --]
[-- Type: text/plain, Size: 1856 bytes --]

diff -ru mingw-w64-v4.0.2/mingw-w64-crt/math/modfl.c mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modfl.c
--- mingw-w64-v4.0.2/mingw-w64-crt/math/modfl.c	2015-04-11 11:37:30.000000000 -0400
+++ mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modfl.c	2015-05-07 11:05:57.000000000 -0400
@@ -21,7 +21,7 @@
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"
diff -ru mingw-w64-v4.0.2/mingw-w64-crt/math/modf.c mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modf.c
--- mingw-w64-v4.0.2/mingw-w64-crt/math/modf.c	2015-04-11 11:37:30.000000000 -0400
+++ mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modf.c	2015-05-07 11:05:57.000000000 -0400
@@ -21,7 +21,7 @@
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"
diff -ru mingw-w64-v4.0.2/mingw-w64-crt/math/modff.c mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modff.c
--- mingw-w64-v4.0.2/mingw-w64-crt/math/modff.c	2015-04-11 11:37:30.000000000 -0400
+++ mingw-w64-v4.0.2-patched/mingw-w64-crt/math/modff.c	2015-05-07 11:05:57.000000000 -0400
@@ -22,7 +22,7 @@
     "fldcw (%%rsp)\n"
     "frndint\n"
     "fldcw 4(%%rsp)\n"
-    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value)); /* round */
+    "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
 #elif defined(_X86_) || defined(__i386__)
   asm ("push %%eax\n\tsubl $8, %%esp\n"
     "fnstcw 4(%%esp)\n"

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Aug 31 13:24, Brian Inglis wrote:
> On 2020-08-31 12:45, Corinna Vinschen wrote:
> > On Aug 31 09:37, Brian Inglis wrote:
> >> On 2020-08-31 01:35, Corinna Vinschen wrote:
> >>> On Aug 30 14:39, Brian Inglis wrote:
> >>>> On 2020-08-30 07:00, Corinna Vinschen wrote:
> >>>>> On Aug 29 08:52, airplanemath via Cygwin wrote:
> >>>>>> I have two reports.  A brief description of the system:
> >>>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >>>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> >>>> ...
> >>>>>> $ cat test.c
> >>>>>> #include <math.h>
> >>>>>> #include <stdio.h>
> >>>>>> #include <stdlib.h>
> >>>>>>
> >>>>>> int main(int argc, char *argv[]) {
> >>>>>>   long double a, b, c;
> >>>>>>   char *num_end = NULL;
> >>>>>>   a = b = c = 0.0L;
> >>>>>>   if (argc != 2) {
> >>>>>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
> >>>>>>     exit(1);
> >>>>>>   }
> >>>>>>   a = strtold(argv[1], &num_end);
> >>>>>>   b = modfl(a, &c);
> >>>>>>   printf("%Lf %Lf %Lf\n", a, b, c);
> >>>>>>   return 0;
> >>>>>> }
> >>>>>
> >>>>> This is a bug in the assembler code taken from Mingw-w64.  The bug has
> >>>>> been fixed upstream, so I just pulled in the upstream fixes.
> >>>>
> >>>> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
> >>>> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
> >>>> to do. Is this inconsistent treatment correct?
> >>>
> >>> You may be right that this is not necessary on i686, but it doesn't
> >>> hurt either and I'd like to stick to the upstream code if possible.
> >>
> >> The upstream patch changed only amd64/x86_64 code sequences for multiple modules
> >> including modfl, and left i386/x86 untouched for those modules.
> 
> Just pointing out that they only modify their amd64/x86_64 code which doesn't
> push/pop rax/eax:

Where are you looking at?  As you could see from my output, I was
looking at the master branch of the upstream repo.

This lengthy discussion for a minor asm snippet doesn't make any sense.
If you think this is wrong, send patches to cygwin-patches and explain
where you got it from, preferrably as a git patch from the upstream
repo.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Brian Inglis]

On 2020-08-31 13:41, Corinna Vinschen wrote:
> On Aug 31 13:24, Brian Inglis wrote:
>> On 2020-08-31 12:45, Corinna Vinschen wrote:
>>> On Aug 31 09:37, Brian Inglis wrote:
>>>> On 2020-08-31 01:35, Corinna Vinschen wrote:
>>>>> On Aug 30 14:39, Brian Inglis wrote:
>>>>>> On 2020-08-30 07:00, Corinna Vinschen wrote:
>>>>>>> On Aug 29 08:52, airplanemath via Cygwin wrote:
>>>>>>>> I have two reports.  A brief description of the system:
>>>>>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>>>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>>>>>> ...
>>>>>>>> $ cat test.c
>>>>>>>> #include <math.h>
>>>>>>>> #include <stdio.h>
>>>>>>>> #include <stdlib.h>
>>>>>>>>
>>>>>>>> int main(int argc, char *argv[]) {
>>>>>>>>   long double a, b, c;
>>>>>>>>   char *num_end = NULL;
>>>>>>>>   a = b = c = 0.0L;
>>>>>>>>   if (argc != 2) {
>>>>>>>>     fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>>>>>>>>     exit(1);
>>>>>>>>   }
>>>>>>>>   a = strtold(argv[1], &num_end);
>>>>>>>>   b = modfl(a, &c);
>>>>>>>>   printf("%Lf %Lf %Lf\n", a, b, c);
>>>>>>>>   return 0;
>>>>>>>> }
>>>>>>>
>>>>>>> This is a bug in the assembler code taken from Mingw-w64.  The bug has
>>>>>>> been fixed upstream, so I just pulled in the upstream fixes.
>>>>>>
>>>>>> The 64 bit fix doesn't pop eax but *now* flags eax as clobbered, whereas the 32
>>>>>> bit fix both pops and *now* flags eax as clobbered, which it really doesn't need
>>>>>> to do. Is this inconsistent treatment correct?
>>>>>
>>>>> You may be right that this is not necessary on i686, but it doesn't
>>>>> hurt either and I'd like to stick to the upstream code if possible.
>>>>
>>>> The upstream patch changed only amd64/x86_64 code sequences for multiple modules
>>>> including modfl, and left i386/x86 untouched for those modules.
>>
>> Just pointing out that they only modify their amd64/x86_64 code which doesn't
>> push/pop rax/eax:
> 
> Where are you looking at?  As you could see from my output, I was
> looking at the master branch of the upstream repo.

Sorry I didn't see your point there as I wasn't aware there were SF repos.

> This lengthy discussion for a minor asm snippet doesn't make any sense.
> If you think this is wrong, send patches to cygwin-patches and explain
> where you got it from, preferrably as a git patch from the upstream
> repo.

Sorry for wasting your time.
I was looking at the bug/patch content and didn't realize someone later added a
bogus clobber on their x86 code path.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Sep  1 11:28, Brian Inglis wrote:
> On 2020-08-31 13:41, Corinna Vinschen wrote:
> > On Aug 31 13:24, Brian Inglis wrote:
> >>>> The upstream patch changed only amd64/x86_64 code sequences for multiple modules
> >>>> including modfl, and left i386/x86 untouched for those modules.
> >>
> >> Just pointing out that they only modify their amd64/x86_64 code which doesn't
> >> push/pop rax/eax:
> > 
> > Where are you looking at?  As you could see from my output, I was
> > looking at the master branch of the upstream repo.
> 
> Sorry I didn't see your point there as I wasn't aware there were SF repos.
> 
> > This lengthy discussion for a minor asm snippet doesn't make any sense.
> > If you think this is wrong, send patches to cygwin-patches and explain
> > where you got it from, preferrably as a git patch from the upstream
> > repo.
> 
> Sorry for wasting your time.
> I was looking at the bug/patch content and didn't realize someone later added a
> bogus clobber on their x86 code path.

No, really, patches are super great and *I* know *you* know how it works.

Given this code is at least questionable, what about sending a patch to
upstream and a matching patch to cygwin-patches?  The upstream mailing
list is at mingw-w64-public AT lists DOT sourceforge DOT net.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer