Rtc fix

[fp64]

This should fix #17119 (it does on, my machine). Only briefly tested in actual emulator (outside autotests) - the date/time in saves seems sensible.

The code is also simplified, and less dependent on library functions. Some of the uses of time_t are still not purged. It should be possible to express rtc_timegm entirely in terms of days_from_civil (but change return type to s64), which is also more portable. Same for all uses of gmtime. All local/timezone stiff still needs standard library.

Not quite sure what the license for http://howardhinnant.github.io/date_algorithms.html is (the accompanying https://howardhinnant.github.io/date/date.html library is MIT). The text does say

But the formulas are good. Consider these donated to the public domain.

So I hope a single-line comment attribution is enough.

[fp64]

As an aside, I now get different pspautotests failures on my machine:

pspautotests/tests/cpu/vfpu/convert.prx:
O vus2i.p pattern 3: 007F8000, 7E678000, 7FC88000, 08800000
E vus2i.p pattern 3: 007F8000, 7E678000, 7F888000, 08800000
pspautotests/tests/gpu/bounding/viewport.prx:
O [x]   Y inside scissor negative: outside
E [x]   Y inside scissor negative: inside
O [x]   Y inside region negative: outside
E [x]   Y inside region negative: inside

Everything else passes.

[hrydgard]

That's curious, do those start with this commit, or some other recent one?

[fp64]

Well, I can tell that they were not happening in dc4190e, but are happening in
d87f03f.

The pspautotests/tests/cpu/vfpu/convert.prx seems like sNaN being quieted, which is finicky regardless - it depends on whether compiler decides to inline functions and/or spill variables.

Not sure about pspautotests/tests/gpu/bounding/viewport.prx.

[hrydgard]

OK so here's the range:

dc4190e...d87f03f

Mostly texture replacement and high level emulator framework stuff in there... Maybe an accidental change of FPU rounding mode or something? hm

[fp64]

d97790e explicitly affects vi2us/vi2s.

[hrydgard]

Yeah, but only in the IR interpreter - which I don't think the tests run? or do they?

[fp64]

Yes, fa1a4d2 (i.e. d97790e~1) also has these failing on my machine.

[hrydgard]

Could you maybe do a quick gtt bisect then?

If you've never used it, do, it's awesome. basically:

• checkout the earliest known bad commit
• git bisect start ; git bisect bad
• checkout the latest known good commit
• git bisect good
• Then it'll automatically check out commits, and all you gotta do is tell it good or bad until the breaking one is found.

[fp64]

Sorry, it seems I remembered wrong. Both dc4190e and even earlier 4b73672 do have these failures. #16984 does not, however.
If I simply add -mfpmath=sse (as I did in #16984) to 4b73672, they are fixed.

That's not surprising for pspautotests/tests/cpu/vfpu/convert.prx, but a bit strange for pspautotests/tests/gpu/bounding/viewport.prx.

[hrydgard]

Ah, interesting. Do add -mfpmath=sse, I don't see any reason to use traditional FPU as we require SSE anyway.