Threaded Mode | Linear Mode

Thomas Okken · 10-01-2022, 10:20 AM

I just noticed that Free42 and Plus42, on iOS and Android, have a bug in BASE÷ with WSIZE 64, signed mode, not wrapped: it always returns Out of Range. It looks like the issue is ARM-specific, in that it doesn't appear to affect the app running in the iOS and Android emulators, where it runs as x64 code. The Mac version on Intel, and the Windows and Linux versions, are not affected by this.

I'm working on a fix, but I'm interested if this bug also affects Free42 and Plus42 on ARM-based Macs, and the DM42. My DM42 is in storage at the moment and I don't own an ARM-based Mac (yet), so if someone could check, I would be grateful. Testing is simple, e.g. BRESET 64 WSIZE 1 ENTER BASE÷.

Thomas Okken · 10-01-2022, 11:14 AM

The root cause appears to be a weird optimizer bug in the clang ARM back-end. Bah.

Who knows what else might be affected by this. I guess I'll have to build all ARM versions with optimizations turned off now, until this gets fixed.

mfleming · 10-01-2022, 11:46 AM

I'm not seeing an error on DM42 v3.21, Free42 v3.0.9

Anyone else?

TomC · 10-01-2022, 12:30 PM

No error here.

DM42 3.22, Free42 3.0.5, SN03961

Regards,
TomC

Thomas Okken · 10-01-2022, 12:53 PM

Thanks guys! Good to know.

I'm turning off optimization in the Android, iOS, and MacOS builds for now. At some point, I'll see if I can create a nice minimal test case, and report this bug to the clang developers. It must have been there since quite some time ago, since the existing Android release build is affected, and it's built using a fairly old compiler, while the iOS build shows the same bug when built with the very latest Xcode.

I don't know for sure yet whether or not the MacOS ARM build is affected, but it seems a pretty safe bet that it is, so I'm disabling optimization for it as well, unless someone with an M1 Mac can confirm that it is not affected.

xmehq · 10-01-2022, 01:35 PM

I have an M1 Mac so I downloaded Plus42 to see if I could help (I don't normally use it on my Mac). Also, I am unfamiliar with what the correct response is when using the commands you specified so I don't know that this will help. BRESET was accepted but did nothing noticeable. I entered 64 on the stack and WSIZE returned "Invalid Data" in Plus42 Binary and seems to do nothing in Plus42 Decimal. The remaining commands appear to have done nothing but leave me with 64 and 1 on the stack.

Thomas Okken · (This post was last modified: 10-01-2022 02:50 PM by Thomas Okken.)

The commands BRESET and 64 WSIZE are meant to put BASE in the state where the bug can occur, i.e. 64-bit word size, signed, not wrapped. When you enter the BASE menu after applying those settings, you should see "WS: 64 S" in the top right corner of the display. (Free42 Binary and Plus42 Binary can only handle word sizes up to 53 bits, so the error can't occur there.)

The test case itself is to just exercise BASE÷ with inputs that shouldn't return an error. Free42 3.0.14 and Plus42 1.0.10 on iOS and Android return "Out of Range" with this test case.

It sounds like the optimizer bug does not affect the MacOS/ARM code after all. That's surprising, but good to know. Thank you for checking!

agarza · 10-01-2022, 02:50 PM

(10-01-2022 10:20 AM)Thomas Okken Wrote: Testing is simple, e.g. BRESET 64 WSIZE 1 ENTER BASE÷.

I just tried Plus 42 Decimal on a MacBook Pro M1.
I get "Out of Range".

xmehq · 10-01-2022, 03:05 PM

Thank you for explaining, Thomas.
I do get the out of range error on Plus42 Decimal on my Mac but the word size annunciator does not appear.
On my iPad, I see both the annunciator and the out of range error as you've described.

Thomas Okken · 10-01-2022, 03:22 PM

Thank you both for checking! I will keep optimization disabled for the Mac version, then.

@xmehq: The header line will be hidden if the display has fewer than 4 lines, or if the header has been disabled explicitly. You can toggle the header using the HDR setting in the third row of the DISP menu.

Thomas Okken · 10-01-2022, 03:25 PM

...and the word size / signed / wrap indicators are only shown if the BASE menu is active, or if you're in the third row of the MODES menu.

Thomas Okken · 10-01-2022, 04:15 PM

Free42 3.0.15 and Plus42 1.0.11 are out now, with this fix, and a few other minor fixes and improvements as well.

johanw · (This post was last modified: 10-01-2022 04:27 PM by johanw.)

Can we xpect new versions for Android and iOS shortly?

Edit: I just see them comming in. I should have checked before asking.

Is it sufficient to stop some optimizations or should they al be removed? And how does this affect the performance?

Thomas Okken · 10-01-2022, 05:00 PM

(10-01-2022 04:26 PM)johanw Wrote: Is it sufficient to stop some optimizations or should they al be removed?

Only disabling all optimizations (-O0) makes the bug go away.

(10-01-2022 04:26 PM)johanw Wrote: And how does this affect the performance?

Not a lot, I suspect, but I haven't performed any measurements. Correctness trumps performance, so...

Didier Lachieze · 10-02-2022, 01:19 PM

(10-01-2022 04:15 PM)Thomas Okken Wrote: Free42 3.0.15 and Plus42 1.0.11 are out now, with this fix, and a few other minor fixes and improvements as well.

There is a new A...F function in this release but it is located in CATALOG>MISC, and not in CATALOG>BASE, any reason for that?

Thomas Okken · 10-02-2022, 02:26 PM

No

I'll move it

Thomas Okken · 10-02-2022, 03:48 PM

It actually doesn't look very likely that the ARM optimization bug may affect anything other than the BASE range check, since it appears to be a very specific interaction between a shift and an inequality check. I can work around the range check issue by simply adding a special case (basically, if (wsize == 64 && signed && !wrapped) do_nothing;). So, I'm adding that work-around, and turning optimization back on for the next release.