This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/24823] [4.1 Regression] ICE



------- 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
needed afterwards?

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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]