HP Forums

Full Version: Free42 / Plus42 BASE÷ bug
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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÷.
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.
I'm not seeing an error on DM42 v3.21, Free42 v3.0.9

Anyone else?
No error here.

DM42 3.22, Free42 3.0.5, SN03961

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.
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.
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!
(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".
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.
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.
...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.
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.
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?
(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...
(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?
No Big Grin
I'll move it
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.
Reference URL's