------- 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
