The 'use -fPIC' hack I've been using to avoid this problem doesn't help with the newest gcc in sid.
< https://buildd.debian.org/fetch.cgi?pkg=mlton&arch=mips&ver=20100504~svn-r7459&stamp=1273006902&file=log&as=raw > gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include \ -I/usr/lib/mlton/include -O1 -fno-common -fno-strict-aliasing \ -fomit-frame-pointer -w -fPIC -o /tmp/fileTmKIAk.o \ /tmp/file6ErB3L.257.c /tmp/cc0HroCk.s: Assembler messages: /tmp/cc0HroCk.s:58809: Error: Branch out of range I suppose I should be grateful that the bug no longer causes invalid code to be generated. Can someone please look into this problem? From reports I've found with google, mips has had this problem on and off for over five years. Wouldn't it be sensible to just add a bit of wiggle room to the test which determines whether a near or far branch instruction is appropriate? Maybe a simple heuristic like 'within 10 instructions of being outside of short reach means use a far instruction'?
