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

[airplanemath <airplanemath@aol.com>]

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