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 <jjohn...@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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
