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