* cpp /usr/include/threads.h fails; modfl segfaults [not found] <02b16d2e-9d51-de58-807b-3b31b2565b59.ref@aol.com> @ 2020-08-29 12:52 ` airplanemath 2020-08-29 17:57 ` Ken Brown 2020-08-30 13:00 ` Corinna Vinschen 0 siblings, 2 replies; 20+ messages in thread From: airplanemath @ 2020-08-29 12:52 UTC (permalink / raw) To: cygwin 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-29 12:52 ` cpp /usr/include/threads.h fails; modfl segfaults airplanemath @ 2020-08-29 17:57 ` Ken Brown 2020-08-29 21:41 ` [QUAR] " Eliot Moss 2020-08-30 1:21 ` airplanemath 2020-08-30 13:00 ` Corinna Vinschen 1 sibling, 2 replies; 20+ messages in thread From: Ken Brown @ 2020-08-29 17:57 UTC (permalink / raw) To: airplanemath, cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-29 17:57 ` Ken Brown @ 2020-08-29 21:41 ` Eliot Moss 2020-08-30 16:11 ` Ken Brown 2020-08-30 1:21 ` airplanemath 1 sibling, 1 reply; 20+ messages in thread From: Eliot Moss @ 2020-08-29 21:41 UTC (permalink / raw) To: Ken Brown, airplanemath, cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-29 21:41 ` [QUAR] " Eliot Moss @ 2020-08-30 16:11 ` Ken Brown 2020-08-30 18:21 ` Eliot Moss 0 siblings, 1 reply; 20+ messages in thread From: Ken Brown @ 2020-08-30 16:11 UTC (permalink / raw) To: moss, airplanemath, cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [QUAR] Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 16:11 ` Ken Brown @ 2020-08-30 18:21 ` Eliot Moss 0 siblings, 0 replies; 20+ messages in thread From: Eliot Moss @ 2020-08-30 18:21 UTC (permalink / raw) To: Ken Brown, airplanemath, cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-29 17:57 ` Ken Brown 2020-08-29 21:41 ` [QUAR] " Eliot Moss @ 2020-08-30 1:21 ` airplanemath 2020-08-30 2:56 ` Ken Brown 1 sibling, 1 reply; 20+ messages in thread From: airplanemath @ 2020-08-30 1:21 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 1:21 ` airplanemath @ 2020-08-30 2:56 ` Ken Brown 2020-08-30 6:23 ` ASSI 0 siblings, 1 reply; 20+ messages in thread From: Ken Brown @ 2020-08-30 2:56 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 2:56 ` Ken Brown @ 2020-08-30 6:23 ` ASSI 2020-08-30 20:07 ` Brian Inglis 0 siblings, 1 reply; 20+ messages in thread From: ASSI @ 2020-08-30 6:23 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 6:23 ` ASSI @ 2020-08-30 20:07 ` Brian Inglis 0 siblings, 0 replies; 20+ messages in thread From: Brian Inglis @ 2020-08-30 20:07 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-29 12:52 ` cpp /usr/include/threads.h fails; modfl segfaults airplanemath 2020-08-29 17:57 ` Ken Brown @ 2020-08-30 13:00 ` Corinna Vinschen 2020-08-30 19:21 ` airplanemath 2020-08-30 20:39 ` Brian Inglis 1 sibling, 2 replies; 20+ messages in thread From: Corinna Vinschen @ 2020-08-30 13:00 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 13:00 ` Corinna Vinschen @ 2020-08-30 19:21 ` airplanemath 2020-08-31 7:33 ` Corinna Vinschen 2020-08-30 20:39 ` Brian Inglis 1 sibling, 1 reply; 20+ messages in thread From: airplanemath @ 2020-08-30 19:21 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 19:21 ` airplanemath @ 2020-08-31 7:33 ` Corinna Vinschen 0 siblings, 0 replies; 20+ messages in thread From: Corinna Vinschen @ 2020-08-31 7:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 13:00 ` Corinna Vinschen 2020-08-30 19:21 ` airplanemath @ 2020-08-30 20:39 ` Brian Inglis 2020-08-31 7:35 ` Corinna Vinschen 1 sibling, 1 reply; 20+ messages in thread From: Brian Inglis @ 2020-08-30 20:39 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-30 20:39 ` Brian Inglis @ 2020-08-31 7:35 ` Corinna Vinschen 2020-08-31 15:37 ` Brian Inglis 0 siblings, 1 reply; 20+ messages in thread From: Corinna Vinschen @ 2020-08-31 7:35 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-31 7:35 ` Corinna Vinschen @ 2020-08-31 15:37 ` Brian Inglis 2020-08-31 18:45 ` Corinna Vinschen 0 siblings, 1 reply; 20+ messages in thread From: Brian Inglis @ 2020-08-31 15:37 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-31 15:37 ` Brian Inglis @ 2020-08-31 18:45 ` Corinna Vinschen 2020-08-31 19:24 ` Brian Inglis 0 siblings, 1 reply; 20+ messages in thread From: Corinna Vinschen @ 2020-08-31 18:45 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-31 18:45 ` Corinna Vinschen @ 2020-08-31 19:24 ` Brian Inglis 2020-08-31 19:41 ` Corinna Vinschen 0 siblings, 1 reply; 20+ messages in thread From: Brian Inglis @ 2020-08-31 19:24 UTC (permalink / raw) To: cygwin [-- 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" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-31 19:24 ` Brian Inglis @ 2020-08-31 19:41 ` Corinna Vinschen 2020-09-01 17:28 ` Brian Inglis 0 siblings, 1 reply; 20+ messages in thread From: Corinna Vinschen @ 2020-08-31 19:41 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-08-31 19:41 ` Corinna Vinschen @ 2020-09-01 17:28 ` Brian Inglis 2020-09-02 7:54 ` Corinna Vinschen 0 siblings, 1 reply; 20+ messages in thread From: Brian Inglis @ 2020-09-01 17:28 UTC (permalink / raw) To: cygwin 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.] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cpp /usr/include/threads.h fails; modfl segfaults 2020-09-01 17:28 ` Brian Inglis @ 2020-09-02 7:54 ` Corinna Vinschen 0 siblings, 0 replies; 20+ messages in thread From: Corinna Vinschen @ 2020-09-02 7:54 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2020-09-02 7:54 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <02b16d2e-9d51-de58-807b-3b31b2565b59.ref@aol.com> 2020-08-29 12:52 ` cpp /usr/include/threads.h fails; modfl segfaults airplanemath 2020-08-29 17:57 ` Ken Brown 2020-08-29 21:41 ` [QUAR] " Eliot Moss 2020-08-30 16:11 ` Ken Brown 2020-08-30 18:21 ` Eliot Moss 2020-08-30 1:21 ` airplanemath 2020-08-30 2:56 ` Ken Brown 2020-08-30 6:23 ` ASSI 2020-08-30 20:07 ` Brian Inglis 2020-08-30 13:00 ` Corinna Vinschen 2020-08-30 19:21 ` airplanemath 2020-08-31 7:33 ` Corinna Vinschen 2020-08-30 20:39 ` Brian Inglis 2020-08-31 7:35 ` Corinna Vinschen 2020-08-31 15:37 ` Brian Inglis 2020-08-31 18:45 ` Corinna Vinschen 2020-08-31 19:24 ` Brian Inglis 2020-08-31 19:41 ` Corinna Vinschen 2020-09-01 17:28 ` Brian Inglis 2020-09-02 7:54 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).