[Patch, libgfortran, committed] Don't use rand_s on CYGWIN
Mon Mar 13 09:01:00 GMT 2017
On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike <email@example.com> wrote:
>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>> <firstname.lastname@example.org> wrote:
>>> Don't try to use rand_s on CYGWIN
>>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>>> defined even though rand_s is not available. Thus add an extra check
>>> for __CYGWIN__.
>>> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention.
>>> Committed as r245755.
>>> 2017-02-27 Janne Blomqvist <email@example.com>
>>> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
>> 1) There was no patch attached to the email.
> Oh, sorry. Well, you can see it at
>> 2) As mentioned on IRC, I don't think this is the right fix. The real
>> problem is that time_1.h includes windows.h on CYGWIN, which it
>> shouldn't be doing. This then pollutes the translation unit with all
>> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
>> Removing the include in time_1.h and then adjusting a few ifdefs in
>> system_clock.c that also had the same bug fixes the problem. The
>> testsuite is running right now on this.
> It used to be something like that, but IIRC there were some complaints
> about SYSTEM_CLOCK on cygwin that were due to the cygwin
> clock_gettime() or something like that, and after some discussion with
> someone who knows something about cygwin/mingw (since you apparently
> have no memory of it, I guess it was Kai), it was decided to use
> GetTickCount & QPC also on cygwin.
I searched a bit, and it seems the culprit is the thread starting at
So it turned out that clock_gettime(CLOCK_MONOTONIC, ...) always
returned 0 on cygwin, hence the code was changed to use the windows
API functions GetTickCount and QPC also on cygwin at
More information about the Gcc-patches