[Bug regression/20973] [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-12 17:34 -------
Here some mails we exchanged:  
  
Adding something complex seems to change how  
things are allocated or REG_DEAD notes distributed or something like this.  
If we add 'kdDebug( 6080 ) << "applying property " << id << endl;' at the  
very start, it seems to work.  If we comment it out, and add a  
  
+       printf ("apply %d id %d\n", apply, id);  
        if(!apply) return;  
        switch(id)  
            {  
            case CSS_PROP_MAX_WIDTH:  
  
at line 2834, one can see where it goes wrong.  The printf will show id  
being 0 every time.  In the debugger printing 'id' (which refers to the  
stack position) shows the correct value.  At that point the compiler has  
placed id into %esi, which indeed contains 0 here.  
  
This $esi is loaded at the beginning of the function with the argument,  
and the first time it changes (when setting a watchpoint on $esi in gdb)  
is at line 2823:  
                l = Length(primitiveValue->computeLength(style,  
paintDeviceMetrics), Fixed,  
                           primitiveValue->isQuirkValue());  
  
This corresponds to this insn:  
0x4028a449 : and    $0xf0000000,%esi  
  
After that, until the printf $esi is not correctly loaded back from the  
parameter stack slot, and remains 0.  The above insn corresponds to this  
RTL:  
(insn 12371 55063 12368  
/usr/src/packages/BUILD/kdelibs-3.4.0/khtml/misc/khtmllayout.h:49 (parallel [  
            (set (reg:SI 4 si [orig:3843 D.83927 ] [3843])  
                (and:SI (reg:SI 4 si [orig:3843 D.83927 ] [3843])  
                    (const_int -268435456 [0xf0000000])))  
            (clobber (reg:CC 17 flags))  
        ]) 200 {*andsi_1} (nil)  
  
(I think, there are multiple insns masking the high 4 bit out of %esi, and  
I've not yet traced through all paths).  So somehow I think GCC put  
something into %esi while it still was live.  Wasn't there some error in  
placing REG_DEAD notes just a few days ago?  
  

-- 


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