Subject: libc's quad support
To: None <email@example.com>
From: Steve Woodford <firstname.lastname@example.org>
Date: 10/17/2002 11:30:29
While getting SH5 running with the 64-bit ABI, I discovered that our
libc's quad support is broken on _LP64.
So what, I hear you say. Why is a 64-bit cpu using that code when it
supports 64-bt types natively?
The problem is, SH5 has no native instruction for muldi3 (it *does* have
mulsi3, with a 64-bit result) and no integer divide instruction of any
shape or form.
As a result, SH5 has to use some of libc's quad routines.
However, note the comment near the top of quad.h. vis:
* This library makes the following assumptions
* - A quad variable is exactly twice as long as `long'.
Oops. The existing code ends up recursing infinitely due to "long" being
64-bits with the _LP64 ABI.
I have hacked things up locally by replacing "long" by "int" in all the
right places, but I'm not altogether happy with this. There has to be a
Ideally, <sys/types.h> needs a "halfquad_t" type to go along with the
definition of "quad_t". I'm not altogether happy about adding this since
it would pollute the namespace.
Having said that, since <sys/types.h> hard-codes quad_t as int64_t, I
guess I could just s/int/int32_t/g in the quad routines, and let someone
else deal with the fallout should sizeof quad_t change.
Any suggestions? Particularly from the Standards Police...