* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
@ 2007-11-27 19:02 ` matz at gcc dot gnu dot org
2007-11-27 19:05 ` matz at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: matz at gcc dot gnu dot org @ 2007-11-27 19:02 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
2007-11-27 19:02 ` [Bug target/34250] " matz at gcc dot gnu dot org
@ 2007-11-27 19:05 ` matz at gcc dot gnu dot org
2007-11-28 13:36 ` uweigand at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: matz at gcc dot gnu dot org @ 2007-11-27 19:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
2007-11-27 19:02 ` [Bug target/34250] " matz at gcc dot gnu dot org
2007-11-27 19:05 ` matz at gcc dot gnu dot org
@ 2007-11-28 13:36 ` uweigand at gcc dot gnu dot org
2007-11-28 15:29 ` matz at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: uweigand at gcc dot gnu dot org @ 2007-11-28 13:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-11-28 13:36 ` uweigand at gcc dot gnu dot org
@ 2007-11-28 15:29 ` matz at gcc dot gnu dot org
2007-11-28 15:41 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: matz at gcc dot gnu dot org @ 2007-11-28 15:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
` (3 preceding siblings ...)
2007-11-28 15:29 ` matz at gcc dot gnu dot org
@ 2007-11-28 15:41 ` rguenth at gcc dot gnu dot org
2007-11-28 15:59 ` matz at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2007-11-28 15:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
` (4 preceding siblings ...)
2007-11-28 15:41 ` rguenth at gcc dot gnu dot org
@ 2007-11-28 15:59 ` matz at gcc dot gnu dot org
2007-11-28 17:12 ` uweigand at gcc dot gnu dot org
2007-12-08 22:36 ` pinskia at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: matz at gcc dot gnu dot org @ 2007-11-28 15:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
` (5 preceding siblings ...)
2007-11-28 15:59 ` matz at gcc dot gnu dot org
@ 2007-11-28 17:12 ` uweigand at gcc dot gnu dot org
2007-12-08 22:36 ` pinskia at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: uweigand at gcc dot gnu dot org @ 2007-11-28 17:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/34250] ICE in find_constant_pool_ref
2007-11-27 18:27 [Bug target/34250] New: ICE in find_constant_pool_ref matz at gcc dot gnu dot org
` (6 preceding siblings ...)
2007-11-28 17:12 ` uweigand at gcc dot gnu dot org
@ 2007-12-08 22:36 ` pinskia at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-12-08 22:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread