Kars de Jong <[EMAIL PROTECTED]> writes: > Adding a "memory" constraint to the assembly in ip_fast_csum() solved > it. I don't really understand why it's needed, since the code in > ip_fast_csum() does not modify memory...
The problem is that gcc only sees that the assembly uses the _pointer_, but it has no clue that the _contents_ are being read. So it assumes that the first store is dead. > There was also a problem with the constraints of csum_tcpudp_nofold(), > they were inconsistent (I think). I also noticed a rather strange > difference between us and other big-endian arches: they all use len + > (proto<<16) as an input, we use len + proto. I don't really understand > why. Both result in the same (16-bit) sum, but the latter saves a shift. > I propose the following changes, but I'd like someone else to look at > them first before committing them. Apart from the point above your changes look ok. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstra�e 5, 90409 N�rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
