svn commit: r295561 - in head: include sys/mips/include sys/powerpc/include sys/sparc64/include sys/sys sys/x86/include

[Konstantin Belousov]

On Sat, Feb 13, 2016 at 02:19:21AM +1100, Bruce Evans wrote:
> On Fri, 12 Feb 2016, Konstantin Belousov wrote:
> 
> > On Fri, Feb 12, 2016 at 01:22:04PM +0000, Ruslan Bukin wrote:
> >> On RISC-V it fails with __uint128_t:
> >>
> >> struct fpregs {
> >>         __uint128_t     fp_x[32];
> >>
> >> how to fix?
> > You did not copied the error.
> >
> > If my guess is correct, the issue is that __uint128_t typedef is not
> > present in the riscv/include/_types.h.  Either add the type there, or
> > use e.g. __uint64_t fp_x[32][2]; for the member definition.
> 
> __uint128_t is defined by newer compilers.  Declaring it as a typedef
> would probably be a syntax error.
Might be,  I was more interested in the aligned spec in the commit.
And I do think that either [32][2] or even a definition of form
	struct __fp_reg {
		__uint64_t fp_lo;
		__uint64_t fp_hi; /* BTW, what endianess RISC-V has ? */
	} __aligned(16);
is better than what was committed.

> 
> > BTW, uintmax_t on riscv is defined as uint64.
> 
> Same on all arches.
> 
> Any normal use of __uintmax_t breaks uintmax_t since uintmax_t is
> supposed to be the largest integer type, but it is ony 64 bits on all
> supported arches, bu __uint128_t is larger.  printf() doesn't support
> printing __uint128_t...
> 
> Expansion of uintmax_t to make __uint128_t, __uint256_t, __uint512_t, ...
> more useful would mainly give bloat and break ABIs.
Thing is, there is no the RISC-V ABI yet, neither in the informal sense
of the unwritten set of rules followed by the FreeBSD runtime system, nor
as the psABI document.  This was the reason for my question - we can change
the type there.