Opened 6 years ago

Closed 6 years ago

#1087 closed defect (fixed)

Can't compile Maxima on a Raspberry Pi with CCL (arm architecture)

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

Description

While trying to compile the lisp-only build of Maxima, I encountered a bug which seems to be related to the ARM compiler in CCL. Here are the last lines of the compilation:

;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zlog.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zlog.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zunik.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zunik.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zunhj.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zunhj.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zuoik.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zuoik.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zuni1.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zuni1.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zkscl.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zkscl.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zshch.lisp"...
;Loading #P"binary-openmcl/numerical/slatec/zshch.lafsl"...
;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zbknu.lisp"...
> Error: PC-relative displacement can't be encoded.
> While executing: (:INTERNAL #:G5915 ARM::ARM-FINALIZE), in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 >
?

Change History (3)

comment:1 Changed 6 years ago by rme

  • Component changed from IDE to Compiler

comment:2 Changed 6 years ago by gb

  • Owner set to gb
  • Status changed from new to assigned

comment:3 Changed 6 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [15849]) Change handling of inline constants ("the constant pool") in ARM backend.

Recognize that offsets in floating-point loads are limited to 10 bits.

Don't support :DRAIN-CONSTANT-POOL vinsn directive; replace with :LOCK-CONSTANT-POOL/:UNLOCK-CONSTANT-POOL, which control the automatic draining of the constant pool when an unconditional control-transfer instruction is generated. (This is intended to "protect" things like jump tables that generate such instructions but don't want to have floating-point constants embedded in the instruction stream.)

Don't support a "force" argument to ARM-DRAIN-CONSTANT-POOL.

If a constant would be too far away from its referencing instruction if it was appended to the (current) code segment, embed it at the point of reference, e.g.

  (fldd d1,:= @x)
  (b 1f)
...
@x (:word ...) (:word)
1:

Fixes ticket:1087 in the trunk.

Note: See TracTickets for help on using tickets.