[Bug target/17224] New: relocation truncated to fit: GPREL22

[Bug target/17224] New: relocation truncated to fit: GPREL22

[tege-gcc at swox dot com]

Invalid code is generated for symbol+bigoffset.

Test case:
void *foo () { static int n; return &n - 89477598;}
main ()      { foo (); }

Compilation command end error:
gcc -Wa,-v -v -O3 foo.c
Reading specs from /usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/specs
Configured with: ../configure 
Thread model: posix
gcc version 3.4.1
 /usr/local/libexec/gcc/ia64-unknown-linux-gnu/3.4.1/cc1 -quiet -v foo.c -quiet
-dumpbase foo.c -auxbase foo -O3 -version -o /tmp/cc0nLAzc.s
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/../../../../ia64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/include
 /usr/include
End of search list.
GNU C version 3.4.1 (ia64-unknown-linux-gnu)
        compiled by GNU C version 3.4.1.
GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=16384
 as -x -v -o /tmp/ccWqLDKj.o /tmp/cc0nLAzc.s
GNU assembler version 2.12.90.0.1 (ia64-linux) using BFD version 2.12.90.0.1
20020307 Debian/GNU Linux
 /usr/local/libexec/gcc/ia64-unknown-linux-gnu/3.4.1/collect2 -dynamic-linker
/lib/ld-linux-ia64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/crtbegin.o
-L/usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1
-L/usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/../../.. /tmp/ccWqLDKj.o -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh
/usr/local/lib/gcc/ia64-unknown-linux-gnu/3.4.1/crtend.o /usr/lib/crtn.o
/tmp/ccWqLDKj.o: In function `foo':
/tmp/ccWqLDKj.o(.text+0x1): relocation truncated to fit: GPREL22 .text
collect2: ld returned 1 exit status

-- 
           Summary: relocation truncated to fit: GPREL22
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tege-gcc at swox dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-29 00:34 -------
Can you try a newer binutils than "2.12.90.0.1" because this is most likely a binutils bug rather than 
GCC bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[tege-gcc at swox dot com]

------- Additional Comments From tege-gcc at swox dot com  2004-08-29 00:37 -------
Subject: Re:  relocation truncated to fit: GPREL22

I don't think it is a binutils bug.  I verified that
the same code is rejected by HP's assembler/linker.

But I am not an expert on the IA64 ABI, so I might
be wrong.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-29 00:46 -------
but still having a 2 year old binutils is not good for ia64 really.
Also this does seem like a binutils bug, see <http://sources.redhat.com/ml/binutils/2003-04/
msg00574.html> and <http://sources.redhat.com/ml/binutils/2003-03/msg00265.html>.
There are most likely others which show that this can be a binutils bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[tege-gcc at swox dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]


------- Additional Comments From tege-gcc at swox dot com  2004-08-29 01:08 -------
Subject: Re:  relocation truncated to fit: GPREL22

There is clearly no way the large constant could be made to fit
into the 22-bit field of an ADDL.

What would you suggest that binutils should do about the code
from the compiler?  Should it inline additional code to handle
the large offset?

(I realize that my test case is not strictly valid ANSI C, since
one is not allowed to create pointers outside of objects, except
just beyond an object.  But generating invalid assembly code is
not a good answer to that...)

--
Torbjörn


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-29 01:15 -------
Ok, I think I have an handle on this now, we are not rejecting &n - 89477598 as a constant.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-29 01:15:23
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[jsm at polyomino dot org dot uk]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-29 09:32 -------
Subject: Re:  relocation truncated to fit: GPREL22

On Sun, 29 Aug 2004, pinskia at gcc dot gnu dot org wrote:

> Ok, I think I have an handle on this now, we are not rejecting &n - 
> 89477598 as a constant.

It is a constant - "an address constant for an object type plus or minus 
an integer constant expression" in the terms of ISO C.  This may only in 
the standard be intended to cover the case of one past the end of an 
array, but if the target can't handle the given example how can it handle

void *foo () { static int n[123456789]; static int *m = n + 123456788; 
return &m; }
main ()      { foo (); }

which is clearly valid (subject to implementation limits, which shouldn't 
cause a problem for this program on 64-bit targets)?

If we have problems with targets not being able to handle certain simple 
forms of constants that fall within my model (as opposed to Geoff 
Keating's wish to accept bizarre examples such as '(uintptr_t)&x * 4 + 
3141 + (&z - &t)' that some assemblers can handle) we may need to have a 
target hook that does

  sorry ("no relocation available that supports this constant");

for the case of static initializers (or, better, warns then creates a 
constructor to initialize at runtime).

The present program however doesn't involve a static initializer, so 
should cause no problems or warnings.  If the assembler doesn't accept the 
address constant as constant, and it is being used as here in a context 
where a constant expression isn't required, it should simply be evaluated 
at runtime.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] relocation truncated to fit: GPREL22

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-29 16:49 -------
I think JSM misunderstood me, in the back-end we can reject things as not being constant enough for 
the assembler which is what I was talking about, not the front-end rejecting it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-10-16 19:31 -------
This is a 3.4/4.0 regression. Gcc 3.2 generates correct code:

        .file   "foo.c"
        .pred.safe_across_calls p1-p5,p16-p63
        .sbss
        .align 4
        .type   n.0#,@object
        .size   n.0#,4
n.0:
        .skip   4
        .text
        .align 16
        .global main#
        .proc main#
main:
        .prologue
        .body
        .mib
        nop 0
        mov r8 = r14
        br.ret.sptk.many b0
        .endp main#
        .align 16
        .global foo#
        .proc foo#
foo:
        .prologue
        .body
        .mlx
        addl r2 = @gprel(n.0#), gp
        movl r3 = -357910392
        ;;
        .mib
        nop 0
        add r8 = r2, r3
        br.ret.sptk.many b0
        .endp foo#
        .ident  "GCC: (GNU) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)"


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|relocation truncated to fit:|[3.4/4.0 Regression]:
                   |GPREL22                     |relocation truncated to fit:
                   |                            |GPREL22


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-01 00:42 -------
HP's compiler (B3910B A.05.36 [Apr 18 2002]) generates a similar link-time error
when compiling this code.

Postponed until GCC 3.4.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-11-27 02:05 -------
Does the back end need a "number too big for the assembler" hook? 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-11-28 02:58 -------
I have verified that this patch

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00598.html

is the cause.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2004-11-28 05:57 -------
You *do* realize this test case is completely undefined, don't you?
Even "&n-1" is undefined; see 6.5.6/8.

I suppose I could reject symbol+constant where constant is outside
the size of the object, but at some point you're going to have to
take responsibility for your own stupidity.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
           Severity|normal                      |minor
             Status|NEW                         |ASSIGNED
           Keywords|wrong-code                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-29 18:42 -------
Subject: Bug 17224

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-11-29 18:42:27

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: predicates.md 

Log message:
	PR target/17224
	* config/ia64/predicates.md (sdata_symbolic_operand): Deny offsets
	outside the referenced object.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6624&r2=2.6625
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/predicates.md.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-29 19:19 -------
Subject: Bug 17224

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	rth@gcc.gnu.org	2004-11-29 19:19:21

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	PR target/17224
	* config/ia64/ia64.c (sdata_symbolic_operand): Deny offsets
	outside the referenced object.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.708&r2=2.2326.2.709
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.265.2.14&r2=1.265.2.15



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2004-11-29 19:19 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224

[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22

[schwab at suse dot de]

------- Additional Comments From schwab at suse dot de  2004-11-29 23:17 -------
Note that the following generates the same code, but IMHO is fully defined 
(apart of the implementation-defined behaviour of the intptr_t cast). 
 
#include <stdint.h> 
intptr_t foo () { static int n; return (intptr_t) &n - 89477598;} 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224