[Bug target/34250] ICE in find_constant_pool_ref

["uweigand at gcc dot gnu dot org" <gcc-bugzilla 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