This is the mail archive of the
mailing list for the GCC project.
[Bug rtl-optimization/24823] [4.1 Regression] ICE
- From: "krebbel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Nov 2005 16:47:44 -0000
- Subject: [Bug rtl-optimization/24823] [4.1 Regression] ICE
- References: <firstname.lastname@example.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #5 from krebbel at gcc dot gnu dot org 2005-11-15 16:47 -------
The only difference my patch brought is different behaviour
of mark_set_1 if it is called under wrong! conditions. Will
say that only in case somebody calls mark_set_1 clobbering a reg which
is live afterwards - we would usually consider this a bug.
But because the different liveness analyzers used by global
alloc and flow we may have such a situation for uninitialized
quantities. But this didn't happen here. So the question is why
somebody calls mark_set_1 to clobber a reg which seem to be
The problematic mark_set_1 call comes from flow.c:1876 where
mark_set_1 is used to end the live ranges of all call clobbered
registers by pretending to have found a clobber for them. For
the testcase this is done for a 3dnow register xmm1 although
that register is live afterwards (at the end of the bb).
Due to my patch no REG_DEAD note is emitted because it is
assumed that xmm1 holds the value of an uninitialized variable.
So why xmm1 is live at bb end? I think the problem here is that
mark_used_regs doesn't handle PARALLELs as destination of a SET
properly. It shouldn't mark the destination reg USED by the call.
For single SETs this works well (flow.c:3972) but for a non BLKmode
PARALLEL we fall through to line 4099 which calls mark_used_regs
recursively for all parts of the PARALLEL and therefore lets the regs
in the following insn be live before that insn up to the entry bb:
(call_insn:HI 361 360 362 32 (set (parallel:DC [
(expr_list:REG_DEP_TRUE (reg:DF 21 xmm0)
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:DF 22 xmm1)
(const_int 8 [0x8]))
(call (mem:QI (symbol_ref:DI ("zlatm2_") [flags 0x41]
<function_decl 0xb7b43200 zlatm2>) [0 S1 A8])
Btw. it is completely unclear to me what this kind of destination
shall mean. Any explanations are welcome.