Ticket #988 (closed defect: invalid)

Opened 22 months ago

Last modified 22 months ago

armhf: FLOATING-POINT-INVALID-OPERATION signalled when LOG called with base

Reported by: tokenrove Owned by:
Priority: normal Milestone:
Component: Compiler Version: trunk
Keywords: Cc:

Description

On Debian/armhf:

julian@ash:~% uname -a
Linux ash 2.6.31.14.27-efikamx #1 Sun Mar 18 20:13:21 EDT 2012 armv7l GNU/Linux
julian@ash:~% ccl
Welcome to Clozure Common Lisp Version 1.8-r15286M  (LinuxARM32)!
? (log 42 2)
> Error: FLOATING-POINT-INVALID-OPERATION detected
>        performing COERCE on (NIL)
> While executing: CCL::/-2, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

Change History

comment:1 Changed 22 months ago by tokenrove

Also, LOG itself returns 0.0 for any positive argument I've tried.

comment:2 Changed 22 months ago by tokenrove

This may be an FFI issue as #_logf and #_log return the same incorrect values, while a C program calling the same libm functions does not. Ditto with #_powf and #_pow.

comment:3 Changed 22 months ago by gb

  • Status changed from new to closed
  • Resolution set to invalid

If foreign function calls to (e.g. #_log) pass floating-point args in GPRs and stack locations and expect results to be returned in GPRs (following the old soft-float ABI) ... well, that isn't going to work if #_log is following hard-float conventions. I'm a little surprised that CCL 1.8 would run at all on a system that only offered armhf; on those systems that I have access to that do so (Ubuntu 12.04 and some version of Arch Linux), object files contain information about the ABI that they were compiled with and the system doesn't allow code from different ABIs to be mixed by ld or by the dynamic linker. I'd assumed that the fact that CCL 1.8 doesn't support armhf would have been obvious since the lisp kernel wouldn't be able to link against armhf libraries. (If this isn't true of the system that you're using, I hope that that won't be true of real Debian armhf releases; that's insane.)

You can of course change the -mfloat-abi option in the Makefile and produce a lisp kernel that'll link against armhf libraries (this despite the fact that the lisp kernel does very little floating-point arithmetic at all), but this doesn't affect how foreign function calls from Lisp are implemented. (LOG calls some flavor of #_log in many cases.) I'm curious as to whether you did this or whether the system that you're using just allowed you to dynamically link a soft-float executable (the lisp kernel) against hard-float libraries.

There's better support for armhf in the trunk; the lisp kernel can be built to follow either ABI and -most- FF-CALLs involving floating-point args/results will work correctly (I think that cases where more than 16 single-float or more than 8 double-float arguments aren't handled correctly.) That's implemented in a way that works under both ABIs, and until soft-float code disappears completely that seems like an important consideration. Callbacks involving FP args/results don't work yet (it'd be desirable if such callbacks also worked transparently under both ABIs, but that's complicated)

So:

  • CCL 1.8 isn't intended to support armhf. Section 2.1.5 of the CCL manual says so explicitly. As I said, I'd assumed that the lisp kernel wouldn't even run on a hard-float-only system and am curious as to whether this is true.
  • it's obviously desirable that future versions do so.
  • some work has been done in this area; more work (callbacks and some boundary cases in ff-call, that I know of) remains to be done.

Since the manual only claims that soft-float is supported, this isn't really a valid ticket; I created another one (ticket:989) to track the general issue.

comment:4 Changed 22 months ago by gb

Just to be clear: I was trying to say above that if a distribution allows you to casually mix hard-float and soft-float code, that'd be insane (it can't work and could lead to lots of possibly subtle bugs.) I wasn't trying to suggest that anyone else was insane. (At least not this time.)

Note: See TracTickets for help on using tickets.