From owner-svn-src-all@freebsd.org Fri Feb 12 15:19:25 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B69BBAA6092; Fri, 12 Feb 2016 15:19:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 81BD681A; Fri, 12 Feb 2016 15:19:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c110-21-41-193.carlnfd1.nsw.optusnet.com.au (c110-21-41-193.carlnfd1.nsw.optusnet.com.au [110.21.41.193]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id B98DCD48AAC; Sat, 13 Feb 2016 02:19:21 +1100 (AEDT) Date: Sat, 13 Feb 2016 02:19:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Ruslan Bukin , 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 In-Reply-To: <20160212141353.GR91220@kib.kiev.ua> Message-ID: <20160213020648.U1340@besplex.bde.org> References: <201602120738.u1C7cKpq093956@repo.freebsd.org> <20160212132204.GA33648@bsdpad.com> <20160212141353.GR91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=73JWPhLeruqQCjN69UNZtQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=Fm8B2VisaaHWX_q4ZgkA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:19:25 -0000 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