Since fdlibm uses tan(x) ~= -1/(x-pi/2) in this range, and the reciprocals of the bad results have a whole of bunch of trailing zero bits, my guess is that argument reduction (the "x-pi/2" part) is screwing up (losing bits of pi/2 beyond the long string of initial bits that cancel out).  In which case it's likely sin(x) will return a poor result too, for the same reason (while cos(x) will return 1.0).  IOW, I'd be surprised if sin(x)/cos(x) were materially better.  If so, it's not just tan() that's flawed.  That can be checked easily enough (e.g., change the Python program I posted to use sin() instead of tan()).

Regardless, assuming we don't want to write our own libm, it's highly desirable that platform experts be aware of the flaw(s) on platforms where it occurs.  Otherwise they'll never make the noise needed to get it fixed.

OTOH, it's not an error _in_ Python if we don't supply libm, so the Python test suite really shouldn't fail on these.  Spray warnings to stderr?  Create a new "platform (lack of) quality" class of soft failure?  "Pass or fail, period" misses the mark here :-(