Closed spenczar closed 1 year ago
If I naively change from __float128
to _Float128
, everything Just Works, and I get no errors:
--- a/lsquare.cpp
+++ b/lsquare.cpp
@@ -45,7 +45,7 @@ idea for nearly-singular matrices. */
with a mere 52 bits of precision. */
#if ((__GNUC__ * 100) + __GNUC_MINOR__) >= 406 && !defined( __arm__)
-#define ldouble __float128
+#define ldouble _Float128
#else
#define ldouble long double
#endif
I don't know anything about what this change really means, or whether this would break builds on other platforms (presumably yes?), but it resolves it for my particular machine.
I'm afraid _Float128
doesn't work on x64. And it sounds as if even though the M1 is an ARM device, __arm__
isn't being defined. Will look tomorrow for a suitable predefined constant so we can say
#if defined( __M1__)
#define ldouble _Float128
#else
(define ldouble to be _float128 or long double in the existing way)
#endif
As with issue #36, I expect you may find other issues of which I knew not (I lack a machine with an M1, sadly... not a Mac fan in general, but these do sound quite nice.) Please continue letting me know what you see.
That makes sense. I suspect the right macro might be "aarch64", which is the label used for 64-bit ARM in quite a few places.
It's a nice machine, but I find that architecture compatibility issues come up about once a week for me. We all sure got used to that x86 monopoly!
Yes, I should probably at least get a Raspberry Pi for testing purposes.
This link suggests we should be using __aarch64__
. If you find that revising lsquare.cpp
to say
#if defined( __aarch64__)
#define ldouble _Float128
#elif ((__GNUC__ * 100) + __GNUC_MINOR__) >= 406 && !defined( __arm__)
#define ldouble __float128
#else
#define ldouble long double
#endif
then I'll modify the code accordingly. Seems to be the only place in my code where I've resorted to quad float math.
Thanks for the report on this. I expect others are either already trying to run this code on M1 and M2 devices, or they will be trying to do so. So it'll be good to get these problems fixed.
Ping @spenczar : wondered if you'd found a fix, either the above or something else? I'm reasonably sure the above would work, but thought I'd ask you before just blindly committing a patch. Any other M1/M2 issues that I should know about? Thanks!
Oh, thanks for the reminder, and sorry for the long silence!
I haven't looked at this much since about March, but I believe your recommendation worked. I didn't hit any other issues compiling the code. Of course, correctness issues may lurk in there, much trickier to discover, but I don't believe I found any other problems.
Excellent. I've committed the fix in question. Thanks!
Hi Bill- unfortunately that fix is causing errors for me (M2 chip, Ventura 13) with lsquare.cpp. There's a string of errors, such as: lsquare.cpp:60:4: error: unknown type name '_Float128' I'm looking into it, will update if I find a fix.
Hi Carrie - well, that's interesting... guess this isn't as simple as it looked. Things rarely are, of course.
I'll guess that we'll have to add some sort of #ifdef __M2__
option that then gets ldouble
properly #defined. If so, it shouldn't be too tricky.
I'm working on an Apple Macbook M1 ("Apple Silicon") which is an ARM platform.
After resolving #36,
g++
hits many errors in compilinglsquare.cpp
:This is after using same setup that I described in #36.