--- 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|UNCON
--- 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 a
--- 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
--- 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
--- 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 give
--- 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 t
--- 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
--- 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 muc
