[Bug target/34250] New: ICE in find_constant_pool_ref

[Bug target/34250] New: ICE in find_constant_pool_ref

[matz at gcc dot gnu dot org]

This was triggered by a patch of ours on the SLES10 compiler, which is 4.1.2
based.  But it can be seen without any patches, for 4.1.x and trunk at least.
I'm sure the other compilers in between have the same problem, as the code
in the s390 backend is designed to error in these cases.  Anyway, do this:

% cat try.c
void func2(void)
{
  __asm__ ("#bla" : : "g" ("consta"), "g" ("constb") );
}

% ./gcc/cc1 -quiet -m31 -O try.c
try.c: In function ‘func2’:
try.c:4: internal compiler error: in find_constant_pool_ref, at
config/s390/s390.c:5171

You need 31bit mode, otherwise this code path doesn't trigger.  The problem
is, that find_constant_pool_ref is designed to handle only max one reference
to the constant pool per instruction (multiple ones to the same constant are
allowed, but not multiple different ones).  For normal instructions this is
okay, but as can be seen above it's trivial to trigger this with asm 
instructions.

The only fix I can imagine is to actually deal with this situation and iterate
over possibly many literal pool refs.


-- 
           Summary: ICE in find_constant_pool_ref
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: matz at gcc dot gnu dot org
GCC target triplet: s390-linux


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

[Bug target/34250] ICE in find_constant_pool_ref

[matz at gcc dot gnu dot org]

------- Comment #1 from matz at gcc dot gnu dot org  2007-11-27 19:02 -------
Created an attachment (id=14648)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14648&action=view)
fix for this

A potential fix for this problem, iterating over possibly multiple constant
refs.  Shouldn't have much overhead over the old solution as the variable
length buffer required for it is reused and resized only if necessary.  Fixes
also our internal problem.


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[matz at gcc dot gnu dot org]

------- Comment #2 from matz at gcc dot gnu dot org  2007-11-27 19:05 -------
For reference, the internal one is at
  https://bugzilla.novell.com/show_bug.cgi?id=344299


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[uweigand at gcc dot gnu dot org]

------- Comment #3 from uweigand at gcc dot gnu dot org  2007-11-28 13:36 -------
Hi Michael,

the problem is that there is an implicit assumption throughout the code
that you can have at most one pool constant per instruction.  For example,
the pool size / splitting heuristics assume that.  I think with your patch
as is, you can find examples where it will attempt to add 2 constants to
the current pool chunk even though it only has room for 1 left.

This could probably be fixed by reworking some of the heuristics (e.g. 
check *first* how many constants an insn will require, and start up a
new pool early if required).  But that can be a bit tricky ...

What fundamentally cannot be fixed is the extreme case where the single
instruction uses so many constants that they don't fit into a pool chunk
even by themselves.  We can only reload the base register to point to a
different chunk once before every insn.

Can you elaborate why this occurs in "normal" code (without inline asm)?


-- 

uweigand at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uweigand at gcc dot gnu dot
                   |                            |org


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

[Bug target/34250] ICE in find_constant_pool_ref

[matz at gcc dot gnu dot org]

------- Comment #4 from matz at gcc dot gnu dot org  2007-11-28 15:28 -------
What I meant with "normal" code is by using inline asms.  As it stands it's
impossible to write inline asm instructions having more than one literal pool
operand.  I consider this normal use of the capabilities GCC gives you.

However with one of our internal patches (which enforces arguments live) we
use inline asms internally, which then happens to hit this problem fairly
easily.  That's how we triggered this and why I investigated there.

For reference, our hacky approach to enforce liveness of arguments is by
using them as operands of an inline asm, which we insert as first instruction
in every function.  When those are inlined and arguments seen as constant
(e.g. function names, __func__) it quickly happens that there are more than
one constant pool ref in one inline asm.

But I see what you are saying regarding the possibility of overflowing the
pool inside one instruction.  Will the compiler ICE in that situation or
will it silently generate wrong code?  If the former I'm willing to accept
that risk for now, after all split constant pools are relatively new anyway,
IIRC.


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2007-11-28 15:41 -------
We could generate multiple asms instead, one for each parameter...


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[matz at gcc dot gnu dot org]

------- Comment #6 from matz at gcc dot gnu dot org  2007-11-28 15:59 -------
Yes, that would be a viable workaround.  Perhaps even correct, given that
GCC can handle only MAX_RECOG_OPERANDS, which is only 30 at a minimum.


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[uweigand at gcc dot gnu dot org]

------- Comment #7 from uweigand at gcc dot gnu dot org  2007-11-28 17:11 -------
(In reply to comment #4)
> For reference, our hacky approach to enforce liveness of arguments is by
> using them as operands of an inline asm, which we insert as first instruction
> in every function.  When those are inlined and arguments seen as constant
> (e.g. function names, __func__) it quickly happens that there are more than
> one constant pool ref in one inline asm.

I'm not sure I see what the point of this is ...

> But I see what you are saying regarding the possibility of overflowing the
> pool inside one instruction.  Will the compiler ICE in that situation or
> will it silently generate wrong code?  If the former I'm willing to accept
> that risk for now, after all split constant pools are relatively new anyway,
> IIRC.

Not really, they've always been required on s390.  (Note that on s390x,
and even on s390 with -march=z900 or higher, split constant pool are no
longer necessary.)

I expect that what will happen when the pool overflows is that you get a
linker error because the 12-bit relocation in the displacement field
overflows.  (But maybe this is only a warning, I'm not completely sure
this hasn't changed across different linker versions ...)

Note that if I understand your usage correctly, this should in fact never
occur as you do not generate any code that actually references those
literal pool entries.


-- 


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

[Bug target/34250] ICE in find_constant_pool_ref

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-12-08 22:36 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-08 22:36:22
               date|                            |


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