On Mon, Dec 13, 2010 at 8:06 AM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: >> >> I think the way to avoid this in the kernel is to stick a "nop" in >> >> the memory barrier. =A0That will avoid a zero length asm and branching >> >> into the delay slot. > > This adds about 17000 odd nops ;( > >> > A further reason is GCC does not know the length of asm insns. =A0So, >> > using a zero length asm on parisc is asking for trouble. >> >> The problem is that many applications (including glibc IIRC) expect a >> zero length asm volatile to work correctly. Althought it's asking for >> trouble, I think it's one of these expected things that just has to >> work :-) > > Most targets don't have to deal with delay branch sequences and the > fact that the hardware can't deal with a branch to the delay slot. > > As I have learned this morning, the length calculated for asms is just > an estimate. It can be confused by comments, etc. So, gcc is going to > have to add a nop when it finds an asm after a branch because the size > estimate is unreliable. > > I had tried to fix this before but missed the asm_operands case. The > branch type selection (useskip) also needs to check for asms ;( For the record I have noticed at least 3 failures in branch delay slots over the past few years, all fixed by -fno-dbr (sp?), so it's quite possible these were the same problem? Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
