Segher Boessenkool <seg...@kernel.crashing.org> writes: > Hi! > > On Mon, Jul 10, 2017 at 09:50:06PM +1000, Michael Ellerman wrote: >> Oliver O'Halloran <ooh...@gmail.com> writes: >> >> > The workaround for the CELL timebase bug does not correctly mark cr0 as >> > being clobbered. This can result in GCC making some poor^W completely >> > broken optimisations. >> >> Fruit 'n oats, how did we never notice that? Luck I guess. Or subtle >> breakage that no one could pin down :E > > GCC does not use cr0 before it has used cr7, cr5, cr6, cr1 (unless some > instruction _requires_ cr0, like record form ("dot") instructions, which > until recently were disabled when targetting Cell), so it isn't too easy > to hit the problem here. Maybe Oliver used a very new GCC? Or he was > unlucky.
Aha. I think he actually hit the bug elsewhere and then noticed it here also? And yeah I think it was a dot instruction that triggered it. >> I'll tag it for stable. >> >> Your change log is not entirely fair, it's not GCC's fault, we changed >> register state without telling it, so it's on us :) I'll reword it a >> bit here. > > Yep, GCC works fine here, GIGO etc. It isn't feasible to make GCC warn > for most inline asm problems, either (we do not parse the mnemonics in > the asm; this is a fundamental part of the design; you must express all > constraints as, well, constraints). Ack. It's a terrible terrible interface, but that's the price we pay for wanting to insert arbitrary bits of asm inside an otherwise compiled language :) When I get the time I might go through our inline asm and convert all the cmpwi x,z to cmpwi cr0,x,z, so at least the cr0 usage is a little more obvious. cheers