search

davidgiven / ack

The Amsterdam Compiler Kit
http://tack.sf.net
Other
416 stars 59 forks source link

Test case failures when building for Debian (& Ubuntu) on AArch64 #287

Closed tkchia closed 1 year ago

tkchia commented 1 year ago

When I try building ACK for Debian GNU/Linux host on AArch64, I get the following test case failures:

**** /<<PKGBUILDDIR>>/build1/obj/plat/linuxppc/tests/tests/linuxppc-from_d_to_si_e-testlog.txt
@@FAIL 0x12
@@FAIL 0x14
@@FINISHED

**** /<<PKGBUILDDIR>>/build1/obj/plat/linuxppc/tests/tests/linuxppc-from_d_to_ui_e-testlog.txt
@@FAIL 0xc
@@FAIL 0xd
@@FINISHED

205 tests passed
2 tests failed to pass
0 were skipped (see build log for details)
0 timed out
2 failed

Failing test logs:
/<<PKGBUILDDIR>>/build1/obj/plat/linuxppc/tests/tests/linuxppc-from_d_to_si_e-testlog.txt
/<<PKGBUILDDIR>>/build1/obj/plat/linuxppc/tests/tests/linuxppc-from_d_to_ui_e-testlog.txt
Test status: SAD FACE (tests are failing)
ninja: build stopped: subcommand failed.
make[2]: *** [Makefile:104: build-plus-goals] Error 1

(https://launchpadlibrarian.net/674940994/buildlog_ubuntu-lunar-arm64.ack-compiler_1%3A6.1~pre1-20230214-build20230701-1~lunar_BUILDING.txt.gz)

For some reason, it seems that the test programs actually pass, when I run them under QEMU's qemu-ppc rather than ACK's emuppc. I am not sure what exactly the cause of the failure is.

Thank you!

davidgiven commented 1 year ago

That sounds like an emuppc bug, unfortunately... it's probably worth upgrading to the latest CPU emulator core.

I have, BTW, found a bunch of issues with the test cases as part of other work. (But not that specific test.)

tkchia commented 1 year ago

Hello @davidgiven,

Thank you. I believe I am already on the latest version of ACK and emuppc (https://github.com/davidgiven/ack/commit/6aa3fef91f2662372247cc20abfb1410b26d436a). That is, unless there is another later version of emuppc which I am unaware of.

Thank you!

tkchia commented 1 year ago

Hello @davidgiven,

It seems the bug was because AArch64 handles casts from double/float to uint32_t differently from x86-64 — and for emulating the fctiw and fctiwz instructions, what we probably want is the x86-64 behaviour. I have submitted a proposed fix.

On an AArch64 host, (uint32_t) -1.0 basically truncates the negative -1.0 value to 0.

Thank you!

davidgiven commented 1 year ago

Oops, I thought that emuppc was using a third party emulator library --- turns out I wrote the emulator myself... thank you for the fix!