Hi,

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
better way.

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...

Cheers, Steve