-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixup architecture woes #151
Conversation
#else | ||
#define __rfs(__fpsr) | ||
#define __rfs(__fpsr) (*__fpsr = 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory this should be (*(__fpsr) = 0)
=)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And in theory if __wfs
is called with non-zero in sf buid the functions below should return non-zero to indicate a failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're not targeting softfloat, I don't think we should bother with too much work to fix it. I'm happy to let it compile and make __rfs()
reasonable.
1513a93
to
5171e95
Compare
I tested building a snapshot of the sf/archmageddon branch on the Ubuntu PPA builders. Unfortunately, the arm64 (aarch64) build now fails while linking the tests. |
@ginggs could you share the error that you get on |
|
@staticfloat there you go. |
What are the |
|
Can you please post the full build log somewhere? Or link to where the build logs are available on the build service you're using to compile? Also the output of |
I tried attaching the gzipped build log but got the message:
|
* Previously, behavior differed if the same value of `ARCH` was defined within `Make.inc` or defined on the command line. Don't do that. * Provide saner defaults for `ARCH` and `MARCH`, and more importantly, allow for the proper overriding of both. * Split `AArch64` code further away from the other `arm` code.
* Use an actual compiler definition to determine whether we have a floating-point unit or not. * Use a modern (VFPU) assembly instruction to get/set the fpsr * If we don't have an fpsr, at least zero out the return value
5171e95
to
d6c4935
Compare
Thank you @ginggs, you found a place in |
@staticfloat thanks! Builds and tests are now successful across the board on amd64, i386, ppc64el, armhf and arm64 (aarch64). |
Good to merge? |
Yes, I think so. |
Update to ba43b3616c59bdce38bb1138dbb507b73b2148a4 to get JuliaMath/openlibm#151, needed for aarch64.
This is to include JuliaMath/openlibm#151 and JuliaMath/openlibm#158 for arm64 support. (was Merge commit '16ca29e08c1d4821498ff33f628d3a51bfea4ade' into arm64)
Significantly cleanup
ARCH
handling. Previously, behavior differed if the same value ofARCH
was defined withinMake.inc
or defined on the command line. This made me very sad.Fix
arm
floating-point status register code so that the tests actually work.Add testing for
ppc64le
andarm
architectures on Travis through the magic ofbinfmt-support
andqemu
.I would like to publicly thank @yuyichao for his help in debugging the arm code.