OrangeC
OrangeC copied to clipboard
LADSoft
autoconfig work
get the latest versions of libgmp and libmpfr; run the libgmp tests; use an occ-generated version of libgmp (and possibly other libraries) when running libcob and libmpfr...
i'm about to close #460 with 8 tests not working. The tests pass a FILE* object to LIBGMP and then eventually into MSVC10 runtime. Since occ FILE* is different than MSVC FILE* it crashes or it just doesn't work.
The next batch of work for these tests is here, to compile libgmp with OCC and make sure the tests do in fact work. Long term I guess we'll have to decide whether it is worth it to rework the libraries to be compatible with MSVC.
remember to check into two of the remaining issues as potentially MPFR bugs. 1) one of the tests hangs if you leave the floating point option as unselected (non-ieee) which the autoconfig currently does for OCC because OCC doesn't have a binary file format. And 2) there seems to be an issue where intmax_t is used but the size selected for the integers in the test is UINT_MAX instead of UINTMAX_MAX.
Do you happen to know which autoconfig thing or MPFR thing is doing the UINT_MAX instead of UINTMAX__MAX? I'll check it out and see what's going on if you do.
Ok so I did some digging, the only way it would "mess up" in such a way is via the AC_CHECK_TYPES([intmax_t]) failing. https://github.com/BrianGladman/mpfr/blob/master/src/mpfr-intmax.h seems to indicate that the problem lies in: Autoconf not recognizing we have intmax_t, autoconf not recognizing that we have stdint.h or autoconf not recognizing that we have inttypes.h.
As for why it's selecting UINT_MAX, I have literally no idea. But I do know that the causes listed above are the "most likely causes" that should be checked. My vote is all 3 together + a compiler-side bug that's causing this tbh.
it was the 'tfits' test program... it allocated space for uint_max_t's number of bits (in a floating point object) then initialized it to the max value then compared the result to UINT_MAX as I recall... but I don't know exactly where the offending lines of code are because they are buried in macros from what I remember.
The only thing in all that I could find to call a 'compiler bug' is if uintmax_t was not the same size as unsigned, but that wasn't a compiler bug as you pointed out... it was correct behavior.
Just checked, seems like there was a bug in some revision with tfits.c the test, specifically relating to uintmax_t and intmax_t, sometime ago revision found here, so try the newest one then, that probably will be a fixed version.
thanks for looking at it, I'll assume it is fixed unless it fails after I run tests with the new code :)
After the GC testbed issue showed a lot of progress, it may be useful to recheck this with the current (quite new) versions of GMP and MPFR; see if some (possibly new) tests are broken and if this issue can be closed.
... thinking of it, maybe there should be a set of GH actions which are only manually triggered that would check GMP, MPFR, libcob and possibly other "third party" projects, which can be executed on the finish line to a release?
maybe I will plan this for right after the C23 support... I could also finish cleaning up the libcob support as it isn't quite there yet lol...