Here's a patch giving an alternative implementation of math.fsum; it's 
based on Tim Peter's suggestions, works mostly with integer arithmetic, 
and so bypasses problems with double rounding and extended precision 
floats.

The patch is experimental:  it doesn't have sufficient tests, has no 
documentation, and it adds math.fsum alongside the current math.sum, to 
make it easy to compare the two implementations.

On my MacBook, math.fsum is a factor of 2-3 times slower than math.sum.
It's also longer and distinctly less elegant.  So its only real 
advantage is that it should fix the difficulties on x86 hardware.

We *really* need to sort math.sum out, one way or another, before the 
next beta.  Georg recently discovered another problem on x86/Linux:  see 
issue 3421.

Some options:

 (1) leave math.sum as it is, skip all tests on x86/Linux, and document
     the current behaviour.

 (2) investigate a version of math.sum that plays with the FPU control 
word to force 53-bit rounding (and round-half-even)

 (3) replace math.sum with the slower but (presumably) less erratic 
math.fsum, possibly just as a temporary measure.  This would at least 
get all tests passing.

Jean, Raymond:  what do you think?