Opened 2 years ago

Closed 17 months ago

#7830 closed bug (fixed)

Error: operand out of range

Reported by: erikd Owned by:
Priority: highest Milestone: 7.8.1
Component: Compiler Version: 7.8.1-rc1
Keywords: Cc: pho@…, ptrommler@…
Operating System: Linux Architecture: powerpc
Type of failure: Installing GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Compiling on linux-powerpc and linux-powerpc64 I get:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall \
   -H64m -O0    -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/.  \
   -ilibraries/time/dist-install/build -ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/dist-install/build -Ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/include   -optP-DLANGUAGE_Rank2Types -optP \
   DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP-include \
   -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \
   -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \
   -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \
   -fno-warndeprecated-flags  -no-user-package-db -rtsopts -fno-warn-unused-do-bind \
   -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities     -odir \
   libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir \ 
   libraries/time/dist-install/build  -dynamic-too -c libraries/time/./Data/Time/Format.hs \
   -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \
   libraries/time/dist-install/build/Data/Time/Format.dyn_o
/tmp/ghc2806_0/ghc2806_1.s: Assembler messages:

/tmp/ghc2806_0/ghc2806_1.s:51766:0:
     Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51798:0:
     Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51830:0:
     Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51908:0:
     Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff)

Attachments (1)

0001-PPC-Fix-loads-of-PIC-data-for-offsets-32-k.patch (2.3 KB) - added by erikd 2 years ago.
Quick and dirty hack to fix 32 bit offset limitation.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 2 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.8.1
  • Priority changed from normal to high

See also #7598

comment:2 Changed 2 years ago by erikd

Every instance of this "operand out of range" error involved the exact instruction:

  lwz     30, .Lnwa8-(1b)(31)

The target, .Lnwa8, is at the end of the file on line 65056. The instructions that are generating errors are in the range 51766 to 54954. There are no instances of that instruction before line 51766 and many in the line number range 55747 to 65045.

Obviously this instruction only works for small offsets. Need to read up on lwz and similar instructions.

comment:3 Changed 2 years ago by PHO

  • Cc pho@… added

comment:4 follow-up: Changed 2 years ago by PHO

Duplicate of #7814?

comment:5 in reply to: ↑ 4 Changed 2 years ago by heisenbug

Replying to PHO:

Duplicate of #7814?

Surely not a duplicate, but I have seen this too:

http://www.haskell.org/pipermail/ghc-devs/2013-April/000993.html

comment:6 Changed 2 years ago by erikd

The lwz instrunction only allows signed 16 bit offsets. Need to find something else.

comment:7 Changed 2 years ago by erikd

By hacking in a bunch of Show instances I've manged to find a pattern match in the PPC aseembler pretty printer for the code which pretty prints the problematic LWZ instruction:

LD II32

(RegReal (RealRegSingle 30)) (AddrRegImm (RegReal (RealRegSingle 31))

(ImmConstantDiff (ImmCLbl (AsmTempLabel _)) (ImmCLbl PicBaseLabel)))

I'm now going to try and make a temporary hack to the pprInst function to handle this special case differently and when that works, try to move the fix back into the CodeGen where it belongs.

comment:8 Changed 2 years ago by erikd

I have a rough hack work around for this but its not suitable for commiting to git yet. Basically in the pretty-printer (it really belongs in the codeGen and will be moved there) I rewrite:

    lwz     30, .label-(1b)(31)

to

    addis   30, 31, (.label-(1b))@ha
    lwz     30, (.label-(1b))@l(30)

This compiles but I then get an illegal instruction error in function cr_str. The call stack looks like this:

#0  0x0f3f3e24 in cr_str () from /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts-ghc7.7.20130623.so
#1  0x0f3df490 in stg_catchzh () from /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts-ghc7.7.20130623.so
#2  0x0f3cd01c in scheduleWaitThread () from /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts-ghc7.7.20130623.so
#3  0x0f3c73dc in rts_evalLazyIO () from /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts-ghc7.7.20130623.so
#4  0x0f3c9300 in hs_main () from /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts-ghc7.7.20130623.so
#5  0x10006ae4 in main ()

and the disassembled code looks like:

   0x0f3f3dec:  rlwimi  r1,r2,10,0,16
   0x0f3f3df0:  xoris   r2,r27,27237
   0x0f3f3df4:  ori     r20,r27,8293
   0x0f3f3df8:  xoris   r20,r19,25970
   0x0f3f3dfc:  oris    r4,r11,8448
   0x0f3f3e00:  .long 0xfffeae2c
   0x0f3f3e04:  .long 0xfffeae2c
   0x0f3f3e08:  .long 0xfffeae2c
   0x0f3f3e0c:  .long 0xfffeae2c
   0x0f3f3e10:  .long 0xfffeae2c
   0x0f3f3e14:  .long 0xfffeae2c
   0x0f3f3e18:  .long 0xfffeae2c
   0x0f3f3e1c:  .long 0xfffeae2c
   0x0f3f3e20:  .long 0xfffeae2c
=> 0x0f3f3e24:  .long 0xfffeae20
   0x0f3f3e28:  .long 0xfffeae20

with the illegal instruction indicated.

comment:9 Changed 2 years ago by erikd

I've broken my modification to the generated code into a standalone assembler program and stepped through it with gdb. I am now convinced that replacing this:

    bcl     20,31,1f
1:  mflr    31
    lwz     30, .mylabel-(1b)(31)

with this:

    bcl     20,31,1f
1:  mflr    31
    addis   30, 31, (.mylabel-(1b))@h
    lwz	    30, (.mylabel-(1b))@l(30)

is the correct thing to do which means the "illegal instruction error in function cr_str" problem in my last update is another different problem.

comment:10 Changed 2 years ago by erikd

I have applied my quick and dirty hack to allow 32 bit offsets for these load instructions to the ghc-7.6.3 release tarball and resulting compiler works.

Will attach a quick-and-dirty hack solution while I work on the illegal instruction issue.

Changed 2 years ago by erikd

Quick and dirty hack to fix 32 bit offset limitation.

comment:11 Changed 2 years ago by erikd

This patch only does anything useful when mk/build.mk has the following enabled:

GhcLibWays += dyn

comment:12 Changed 17 months ago by trommler

  • Cc ptrommler@… added

comment:13 Changed 17 months ago by erikd

I'd forgotten all about this ticket.

GHC now builds for me so I need to get back onto it.

comment:14 Changed 17 months ago by Erik de Castro Lopo <erikd@…>

In 67029f200c5512f8ba5b9b7c25a5d1131422ef8e/ghc:

PPC: Fix loads of PIC data with > 16 bit offsets (#7830).

Loads should now handle up to 32 bit offsets.

comment:15 Changed 17 months ago by erikd

  • Status changed from new to merge

comment:16 Changed 17 months ago by hvr

  • Priority changed from high to highest

comment:17 Changed 17 months ago by thoughtpolice

  • Version changed from 7.7 to 7.8.1-rc1

comment:18 Changed 17 months ago by thoughtpolice

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

Merged in 7.8 for RC2.

Note: See TracTickets for help on using tickets.