Date: Sat, 13 Feb 2016 02:19:21 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ruslan Bukin <br@bsdpad.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r295561 - in head: include sys/mips/include sys/powerpc/include sys/sparc64/include sys/sys sys/x86/include Message-ID: <20160213020648.U1340@besplex.bde.org> In-Reply-To: <20160212141353.GR91220@kib.kiev.ua> References: <201602120738.u1C7cKpq093956@repo.freebsd.org> <20160212132204.GA33648@bsdpad.com> <20160212141353.GR91220@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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.
> P.S. Does it also mean that the tinderbox machines (AKA universe11*)
> do not have riscv toolchain installed ? I did run make tinderbox
> before the commit.
Well, I missed it and only saw __uint128_t in the arm header since
riscv is too new for freefall to have it checked out, and I didn't
rememeber that so I didn't look at another checkout.
Looking at another checkout now shows the following namespace errors
in riscv/include/ucontext.h (mostly the same as arm64):
grpregs, gp_*
fp_regs, fp_*
pad (not the usual __spare__ bogusness. Such fields are closer to
being padding than spares. Of course, padding can be used as
spares.)
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160213020648.U1340>