[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2009-01-20 Thread rob1weld at aol dot com


--- Comment #9 from rob1weld at aol dot com  2009-01-20 13:54 ---
I was checking my Testsuite Results for UNSUPPORTED tests and arrived here.
I thought I would try the code on i386-pc-solaris2.11 with gcc version 4.4.0 .


When booted 32-bit and using -m64:

# gcc -O2 -m64 -fPIC test.c
(nothing printed)


When booted 32-bit and using -m32 the modern compiler objects to 
the   info[tag - 0x1 + 1] = 1; lines in the source:

# gcc -O2 -m32 -fPIC test.c
del_test.c: In function 'bug1':
del_test.c:8: warning: integer constant is too large for 'long' type
del_test.c: In function 'bug2':
del_test.c:15: warning: integer constant is too large for 'long' type
del_test.c: In function 'bug3':
del_test.c:22: warning: integer constant is too large for 'long' type


Adding ULL to the end of the constants eliminates the warnings too.

Rob


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-12-02 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2006-12-02 08:11 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.2


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-11-27 Thread krebbel at gcc dot gnu dot org


--- Comment #5 from krebbel at gcc dot gnu dot org  2006-11-27 16:20 ---
Subject: Bug 29319

Author: krebbel
Date: Mon Nov 27 16:20:24 2006
New Revision: 119254

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119254
Log:
2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* config/s390/predicates.md (larl_operand): Check addend of larl
operand to be in range of -/+2GB.
* config/s390/s390.c (legitimize_pic_address): Likewise.  
Changed type of variable even to HOST_WIDE_INT.

2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* gcc.dg/20061127-1.c: New testcase.



Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20061127-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/s390/predicates.md
branches/gcc-4_1-branch/gcc/config/s390/s390.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-11-27 Thread krebbel at gcc dot gnu dot org


--- Comment #6 from krebbel at gcc dot gnu dot org  2006-11-27 16:27 ---
Subject: Bug 29319

Author: krebbel
Date: Mon Nov 27 16:26:53 2006
New Revision: 119255

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119255
Log:
2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* config/s390/predicates.md (larl_operand): Check addend of larl
operand to be in range of -/+2GB.
* config/s390/s390.c (legitimize_pic_address): Likewise.  
Changed type of variable even to HOST_WIDE_INT.

2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* gcc.dg/20061127-1.c: New testcase.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/20061127-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/s390/predicates.md
branches/gcc-4_2-branch/gcc/config/s390/s390.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-11-27 Thread krebbel at gcc dot gnu dot org


--- Comment #7 from krebbel at gcc dot gnu dot org  2006-11-27 16:34 ---
Subject: Bug 29319

Author: krebbel
Date: Mon Nov 27 16:34:19 2006
New Revision: 119256

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119256
Log:
2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* config/s390/predicates.md (larl_operand): Check addend of larl
operand to be in range of -/+2GB.
* config/s390/s390.c (legitimize_pic_address): Likewise.  
Changed type of variable even to HOST_WIDE_INT.

2006-11-27  Michael Matz  [EMAIL PROTECTED]
Andreas Krebbel  [EMAIL PROTECTED]

PR target/29319
* gcc.dg/20061127-1.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/20061127-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/predicates.md
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-11-19 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2006-11-19 16:18 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2006-11-19 16:18:51
   date||


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-10-24 Thread uweigand at gcc dot gnu dot org


--- Comment #3 from uweigand at gcc dot gnu dot org  2006-10-24 19:03 
---
Sorry for missing that bug.  The proposed patch is OK -- thanks for 
catching this.

As to the general problem, I think you're right that we need to further
constrain the range of accepted offsets.  However, DISP_IN_RANGE is not
the right solution, we can do a lot better.

I think the right fix would be to accept any offset in the +- 2 GB
range (*not* 4 GB) as today.  Since we restrict executable / shared
object sizes to 2 GB right now, the delta between the symbol and the
pc is in the range +- 2GB.  Adding an offset in the +- 2 GB range 
will result in a total delta in the +- 4 GB range -- which is just
what larl allows.

The +- 2 GB range is also big enough to accept any (reasonable)
offset on a 31-bit system.


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-10-02 Thread matz at gcc dot gnu dot org


--- Comment #1 from matz at gcc dot gnu dot org  2006-10-02 11:24 ---
Created an attachment (id=12369)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12369action=view)
proposed patch


-- 


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



[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)

2006-10-02 Thread matz at gcc dot gnu dot org


--- Comment #2 from matz at gcc dot gnu dot org  2006-10-02 11:35 ---
Note that with this patch solves the bug for this testcase, but it still
doesn't help with the general case.  With this slightly changed testcase:

% cat large-ofs2.c
static char l_info[100];
void bug1 (unsigned long tag)
{
  char *info = l_info;
  info[tag - 0x1 + 1] = 1;
}
void bug2 (unsigned long tag)
{
  char *info = l_info;
  info[tag - 0x1 + 1] = 2;
}
extern void abort();
int main()
{
  unsigned i;
  for (i = 0; i  sizeof(l_info); i++)
l_info[i] = 0;
  bug1(0x1);
  bug2(0x1);
  if (l_info[2] != 2 || l_info[1] != 1)
abort();
  return 0;
}

% gcc -S -O2 -fPIC -march=z9-109 large-ofs2.c
% gcc large-ofs2.s
large-ofs2.s: Assembler messages:
large-ofs2.s:19: Error: value of -4294967312 too large for field of 4 bytes at
18

Note how the bodies of both functions is exactly the same, but still it
only fails in the second function.  For reference here the asm of both
functions:

 6  bug1:
 7  .LFB2:
 8  larl%r1,l_info-4294967296
 9  lhi %r3,1
10  stc %r3,1(%r2,%r1)
11  br  %r14
12  .LFE2:
13  .size   bug1, .-bug1
14  .align  4
15  .globl bug2
16  .type   bug2, @function
17  bug2:
18  .LFB3:
19  larl%r1,l_info-4294967296
20  lhi %r3,2
21  stc %r3,1(%r2,%r1)
22  br  %r14

I assume the reason is, that the assembler somehow calculates this pc
relative.  In that case it could also break later during linking if the
linker doesn't have special means to fix up too large offsets.

So, I think s390x is in the same situation as x86-64.  We can't allow
large constant offsets on objects, even though instructions might accept
them, because the object might become placed just a bit too far away,
so that it's base is still in reach, while the offset added to it is not
anymore.  On x86-64 we solve that by artificially constraining the range
of offsets.  That should perhaps be done here too.  E.g. by using
DISP_IN_RANGE instead of the /= test I copied from larl_operand.

Up to the maintainers.


-- 


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