target/7493: [SPRAC] Possible instruction jump too large for assembler.

[Marcus MacWilliam]

The following reply was made to PR target/7493; it has been noted by GNATS.

From: Marcus MacWilliam <marcusma@lsl.co.uk>
To: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org,
 	gcc-prs@gcc.gnu.org, marcusma@lsl.co.uk, nobody@gcc.gnu.org,
 	gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/7493: [SPRAC] Possible instruction jump too large for 
 assembler.
Date: Tue, 10 Dec 2002 17:28:19 +0000

 ehrhardt@mathematik.uni-ulm.de wrote:
 
 > Old Synopsis: Possible instruction jump too large for assembler.
 > New Synopsis: [SPRAC] Possible instruction jump too large for assembler.
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: cae
 > State-Changed-When: Tue Dec 10 08:52:59 2002
 > State-Changed-Why:
 >     The problem in the assembler output is an instructions sequence
 >     like this on sparc:
 >     call        f,0
 >     add %o7,(.LL100-.-4),%o7
 >
 >     which is compiled by GNU as without a warning even if the result
 >     of .LL100-.-4 is larger than 4095, SUN as complains about the error though.
 >     However, I can't get gcc to produce such assemble code. I did a few tests
 >     with 3.3. and 2.95.3 but gcc always detected that the jump distance is
 >     more than what can be added to o7 with a single add instruction and
 >     replaced the add with a ``nop; b,a .LL100'' sequence.
 >     To debug this further we'll need a self contained testcase, i.e.
 >     preprocessed source (see -save-temps option, the .i file is what we're
 >     interested in). Due to the nature of the bug a single function (with
 >     everything it needs to compile!) will probably suffice as a useful testcase.
 >
 >         regards   Christian Ehrhardt
 >
 >
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7493
 
 I was using gcc v3.1, when the error occured.
 The assembler code produced, was contained in the original defect.
 The original error message was included in the defect.
 The error is there.
 
 However, we re-wrote the function to be smaller, to get rid of the
 problem, so it is not as much of an issue now, as it was then.
 
 Thanks anyway,
 --
  Marcus A.T MacWilliam, MSc, CEng, MBCS, BSc(Hons).
  Senior Software Engineer, Laser-Scan Ltd, Cambridge, CB4 0FY.
  Tel: +44 (0)1223 420414 x220. Mobile: +44 (0)7803 706597.
  Fax: +44 (0)1223 420044. Web: http://www.laser-scan.co.uk/