Support for ieee_arithmetic in gcc12-gfortran for Darwin PPC? #40
barracuda156
started this conversation in
General
Replies: 18 comments 42 replies
-
|
I changed source like this: And got a different error: |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
PowerPC Hardware uses IEEE float and double - but there could be some unimplemented support in the runtimes/OS. If the faults reported relate to For |
Beta Was this translation helpful? Give feedback.
-
|
FreeBSD added the following for all powerpc* and aarch64 for
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
@fxcoudert - FX would you be able to comment on the scope of what would be needed to get the IEEE module working on powerpc-darwin9?
[I'm presuming here that we'd be limited to |
Beta Was this translation helpful? Give feedback.
-
|
The IEEE support in libgfortran is determined by
powerpc-apple is not on that list, and it will not be added, since that architecture has been unsupported since October 2014. If you want to do it, add your configuration to configure.host, create a config/fpu-ppc.h file with the right functions defined. You need to be able to add function calls or assembly (more likely assembly) to:
|
Beta Was this translation helpful? Give feedback.
8 replies
-
@fxcoudert Is this something related/usable potentially for Darwin PPC case: https://gcc.gnu.org/legacy-ml/gcc-patches/2012-05/msg01456.html UPD. Tagging the author of the patch: @rbmj |
Beta Was this translation helpful? Give feedback.
-
|
It could form a basis for some of the stuff, but:
|
Beta Was this translation helpful? Give feedback.
-
@fxcoudert It looks like some are there: https://opensource.apple.com/source/Libm/Libm-315/Source/PowerPC/fenv.h.auto.html |
Beta Was this translation helpful? Give feedback.
-
|
@fxcoudert I began reading and comparing the code, and now it is a bit clearer: Apple |
Beta Was this translation helpful? Give feedback.
-
|
@fxcoudert This is potentially usable, together with |
Beta Was this translation helpful? Give feedback.
-
|
it looks like there are already builtins to support manipulation the fp status, to it's a question of doing something similar to aarch64/x86 (still not time here - I just happened to look at the builtins in passing). |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@iains @fxcoudert I checked symbols in |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
you have to remember that ppc on 10.6.8 is not so new features added to x86 on 10.6 are not usually present for ppc (i.e. if it was not there in 10.5.8 probably you should not expect to see it in 10.6.8) |
Beta Was this translation helpful? Give feedback.
-
I refer to 10.6.8 simply because I’m away from PPC hardware so cannot check there, but from Libm code and fenv.h header it appears that those functions were present on PPC for quite a while (fenv.h explicitly has PPC version). Missing are two functions if I remember correctly, feenableexcept and fedisableexcept. |
Beta Was this translation helpful? Give feedback.
-
|
UPD. Probably because those functions are inside macro |
Beta Was this translation helpful? Give feedback.
-
|
@iains @fxcoudert This at least builds: How should I test it to see if it works correctly – or if not, to find out what should be fixed? |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
Run the testsuite ( |
Beta Was this translation helpful? Give feedback.
-
Thank you. I will try and update here. |
Beta Was this translation helpful? Give feedback.
-
|
@fxcoudert Inside the build directory? I.e. P. S. I will return to this after some sleep. I have rebuilt GCC thrice today: to update in Macports prefix and then to run these tests outside Macports. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure what setup you have, so maybe run the full tests: Running |
Beta Was this translation helpful? Give feedback.
-
|
@fxcoudert I have rebuilt GCC anew, from @iains It is super-slow in Rosetta, gonna finish by tomorrow, it seems. So far the following failed (I assume unmentioned pass?): It compiled about 700 objects so far in test folder – there are 6000+ of them in sources. I will try doing the same on the Quad in a day or two. It will be faster, just hope it does not get cooked LOL P. S. I can confirm that P. P. S. We should fix Go, it is ridiculous it is broken on Darwin. |
Beta Was this translation helpful? Give feedback.
-
|
@iains @fxcoudert Could you take a look now? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Parts of the log for IEEE: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
2 replies
-
|
please can you push a branch with whatever patches you have applied and/or post the patch(es) - I have v litttle free time at the moment .. but perhaps can set a build running on the G5. |
Beta Was this translation helpful? Give feedback.
-
|
@iains That would be awesome. Branch is here: https://github.com/barracuda156/gcc-git/tree/gfortran |
Beta Was this translation helpful? Give feedback.
-
|
Feedback about your patch:
About the test results: there are enough failures that probably some fundamental things are not handled well. Try to look at gfortran.dg/ieee/ieee_1.F90 and identify where the failure comes from. Before the call to |
Beta Was this translation helpful? Give feedback.
8 replies
-
|
Beta Was this translation helpful? Give feedback.
-
|
JFTR from the top-level build directory |
Beta Was this translation helpful? Give feedback.
-
|
on the patch from your branch:
(so it's not DoA but there's work still to do .. I have not done any analysis, and will not have a chance until after the next WG21 meeting) |
Beta Was this translation helpful? Give feedback.
-
|
that was tested on the QG5 and summary is for m32 + m64 (Darwin9, obviously because of 64b) |
Beta Was this translation helpful? Give feedback.
-
|
@iains Thank you very much for checking! I will deal with this in coming couple of weeks. Since it is not hopeless, apparently, makes sense to invest some time to finally fix it. I will update the branch once I have some results (and include fixes which @fxcoudert pointed out above). |
Beta Was this translation helpful? Give feedback.
-
|
@iains @fxcoudert A quick update (more today after a while):
UPD. No, changing defines to enable invalid sqrt had no effect on results. It may be unsupported on Darwin in fact: |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
@iains @fxcoudert Darwin I guess we should use a GCC builtin in the test instead. |
Beta Was this translation helpful? Give feedback.
-
|
If there are builtins available for testing these things then, yes, we can use them. If there is some way to implement the functionality in assembler (which means you would need to check the ppc970 ISA) that is also possible (we can actually add builtins or make a CRT to do the necessary work). If the functionality requires OS (kernel-level) support .. then that is realistically unfixable and we should just skip any affected failing test. |
Beta Was this translation helpful? Give feedback.
-
|
addendum: |
Beta Was this translation helpful? Give feedback.
-
AFAIU, GCC has elsewhere P. S. Change log has: @fxcoudert I guess, we could get rid of it for |
Beta Was this translation helpful? Give feedback.
-
|
P. S. Yeah,
|
Beta Was this translation helpful? Give feedback.
-
|
@fxcoudert @iains More on failing tests. Test This corresponds to: Do we actually have REAL_16 support on 32-bit PPC in Fortran? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Yes. we should have (it's implemented as on other 32b and most current 64b BE PPC machines using |
Beta Was this translation helpful? Give feedback.
-
|
perhaps there's some defined __GFC_xxxx that tell we have IBM long double - I don't know. |
Beta Was this translation helpful? Give feedback.
-
@iains Thank you. Then probably tests should be adjusted for IBM long doubles, like it is done in Elsewhere no such a differentiation is made, AFAICT. @fxcoudert It is just that no one bothered to add cases for PPC BE? If mostly everywhere implicit assumption is of IEEE long double, and precision thresholds are set accordingly, no surprise some tests gonna fail. |
Beta Was this translation helpful? Give feedback.
-
|
Well, here we go, in |
Beta Was this translation helpful? Give feedback.
-
|
This is just for the record, re some other test failures. (To be updated.) Another [non-IEEE-specific] gfortran test, Corresponds to:
Possibly an archaic bug never fixed: https://gcc.gnu.org/pipermail/gcc-testresults/2008-January/116411.html
Several of our failing tests also fail on |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@iains @fxcoudert I could not find any info on this: does the following re IBM long double apply to Darwin as well? (I.e. rounding mode, NaNs.)
https://www.ibm.com/docs/en/aix/7.2?topic=sepl-128-bit-long-double-floating-point-data-type Rounding mode issue with IBM long double seems to exist on powerpc-linux as well: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@iains @fxcoudert This is a native run on 10A190 (ppc32) from barracuda156/gcc-git@4932b5b (as Iain knows, 10A190 needs to fall back to 10.5 settings in If I read correctly, overall it is an improvement over what we had (only errors summary below): Several test which failed earlier now pass. I will look into detailed results to a) see if something which worked earlier got broken or became worse and b) if failures may be fixed further. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
@iains @fxcoudert By the way, why could some tests fail only at UPD. It seems that latest changes did some damage to 1 test – At the same time a number of tests are fixed. Will find out what broke |
Beta Was this translation helpful? Give feedback.
-
|
I am clueless, tbh. First of all, this What it prints out upon error are these three values: So when degrees get converted to radians (trivially), it fails. There are no tiny or huge values here, what goes wrong? |
Beta Was this translation helpful? Give feedback.
-
|
Tests on 12.3.0 with These are not directly comparable though with those above, since above was gcc-git (so there are more tests in total than in 12.3.0). Perhaps some change has to be reverted to v. 1 (but not all, since overall results seem to have improved). @iains If you get a chance to run tests with this patch, it would be awesome. P. S. At what stage it is appropriate to submit a PR to GCC? While I think this can still be improved, and I will work on that, getting 100% of tests passing may not be feasible (well, not for me at least). If we can be sure that fixing IEEE module does not break anything else (or does it?), maybe rather get it merged before 14 release? |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
If you mean "Pull Request" - that is not the way that GCC works; Instead we submit patches to the gcc-patches mailing list for review. This has the relevant information. Incremental improvements are fine - providing, of course, that they do not regress any other target. For Darwin-specific changes, you can CC me on the posting; if there are changes that impact (potentially) upon other parts of the RS6000 port, then they will likely also need review by Segher. I guess you do not have access to non-Darwin PPC hardware to test? It is unlikely that I will be able to try this (or give it serious review) during June (WG21 meeting + other commitments). |
Beta Was this translation helpful? Give feedback.
-
|
@iains Thank you, sounds perfect. I wanna give myself a couple of weeks to see if I can fix a couple of unpleasing errors in tests anyway, so I can plan to submit a patch in late June, and you may review whenever you get time, I guess next month.
Unfortunately, no. Talos is out of budget :) P. S. I thought to get FreeBSD running as a second system on the Quad, but turned out it is essentially broken for multiprocessor machines: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@iains I was building
OpenCoarraysfor ppc32, and got the following error:Changing source code syntax slightly as advised elsewhere in some tickets had no effect:
There is a claim that IEEE module support has been implemented since
gcc-5: https://gcc.gnu.org/gcc-5/changes.htmlApparently that is not the case.
A quick search led to tickets with failures for ppc and aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
Do you have these fixed in your Darwin branches? Or if not, can it be fixed with a reasonable effort?
Beta Was this translation helpful? Give feedback.
All reactions