From owner-freebsd-toolchain@freebsd.org Sun Feb 14 03:03:33 2016 Return-Path: Delivered-To: freebsd-toolchain@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 390CAAA16E7 for ; Sun, 14 Feb 2016 03:03:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E294D845 for ; Sun, 14 Feb 2016 03:03:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6177 invoked from network); 14 Feb 2016 03:03:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 03:03:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 13 Feb 2016 22:03:39 -0500 (EST) Received: (qmail 14674 invoked from network); 14 Feb 2016 03:03:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 03:03:39 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6C85A1C43A0; Sat, 13 Feb 2016 19:03:24 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc Message-Id: Date: Sat, 13 Feb 2016 19:03:29 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 03:03:33 -0000 I've isolated another clang 3.8.0 TARGET_ARCH=3Dpowerpc SEGV problem = that shows up for using clang 3.8.0 to buildworld/installworld for = powerpc. > ls -l -n / gets a SEGV. As listed in = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207175 ( and = https://llvm.org/bugs/show_bug.cgi?id=3D26605 ) the following simplified = program also gets the SEGV on powerpc: > #include // for va_list, va_start, va_arg, va_end > #include // for intmax_t >=20 > intmax_t > va_test (char *s, ...) > { > va_list vap; >=20 > va_start(vap, s); >=20 > char* t0 =3D va_arg(vap, char*); > unsigned int o0 =3D va_arg(vap, unsigned int); > int c0 =3D va_arg(vap, int); > unsigned int u0 =3D va_arg(vap, unsigned int); > int c1 =3D va_arg(vap, int); > char * t1 =3D va_arg(vap, char*); > =20 > intmax_t j0 =3D va_arg(vap, intmax_t); // This spans into = overflow_arg_area. >=20 > int c2 =3D va_arg(vap, int); // A copy was put in = the=20 > // overflow_arg_area = because of the > // above. > // But this tries to = extract from the > // last 4 bytes of the = reg_save_area. > // It does not increment = the > // overflow_arg_area = position pointer > // past the copy that is = there. >=20 > char * t2 =3D va_arg(vap, char*); // The lack of = increment before makes > // this extraction off by = 4 bytes. >=20 > char t2fc =3D *t2; // <<< This gets SEGV. t2 actually got = what should be > // the c2 value. >=20 > intmax_t j1 =3D va_arg(vap, intmax_t); >=20 > va_end(vap); >=20 > return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); > // Avoid any optimize-away for lack of use. > } >=20 > int main(void) > { > char s[1025] =3D "test string for this"; >=20 > char* t0 =3D s + 5; > unsigned int o0 =3D 3; > int c0 =3D 1; > unsigned int u0 =3D 1; > int c1 =3D 3; > char * t1 =3D s + 12; > intmax_t j0 =3D 314159265358979323; > int c2 =3D 4; > char * t2 =3D s + 16; > intmax_t j1 =3D ~314159265358979323; >=20 > intmax_t result =3D va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); >=20 > return (int) (result - (intmax_t) = ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); > // Avoid any optimize-away for lack of use. > } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Feb 14 19:21:59 2016 Return-Path: Delivered-To: freebsd-toolchain@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 D7C6EAA8203 for ; Sun, 14 Feb 2016 19:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DF6D1F13 for ; Sun, 14 Feb 2016 19:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18469 invoked from network); 14 Feb 2016 19:22:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 19:22:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 14 Feb 2016 14:22:01 -0500 (EST) Received: (qmail 16495 invoked from network); 14 Feb 2016 19:22:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 19:22:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2FDEE1C43D8; Sun, 14 Feb 2016 11:21:48 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? Message-Id: Date: Sun, 14 Feb 2016 11:21:50 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 19:22:00 -0000 Is buildworld supposed to use /usr/include's area for finding files by = default? (I'm not talking of ${WORLDTMP}/usr/include but of just = /usr/include.) It does use /usr/include's area for some contexts: self-hosted builds = without a special XCC full path (e.g., an implicit TARGET_ARCH=3Dpowerpc = on a powerpc host using gcc 4.2.1 without an explicit XCC assignment = that also directs it to gcc 4.2.1 via a full path). /usr/src/Makefile.inc1 has the following sort of logic: > .if ${XCC:N${CCACHE_BIN}:M/*} . . . > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ . . . > .else . . . > .endif > XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > .else > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) > BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} > XCFLAGS+=3D ${BFLAGS} > XCXXFLAGS+=3D ${BFLAGS} > .endif > .endif # ${XCC:M/*} For contexts without the -isystem and/or --sysroot in XCFLAGS . . . Is it appropriate to submit bug reports for buildworld getting include = files from /usr/include instead of from ${WORLDTMP} or from /usr/src = areas? This tends to be noticed when something like the following. . . > # svnlite update -r295453 /usr/src > # env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel ends up with compile errors from using some older /usr/include header = files that are no longer sufficient to allow compilation. I recently had a couple of examples where the cc command in the script = output file for the failing compiles showed no -I , no -isystem , no = --sysroot , nothing that would have allowed it to even potentially avoid = /usr/include (old file) use. The Makefile*'s involved had no = CFLAGS+=3DSOMETHING_DIRECTING_INCLUDE_SEARCH . (Some types of header changes might not stop a build but might make the = build result wrong without much explicit notification. I'd prefer to = avoid such as well.) I expect that there are analogous points/questions for finding = libraries. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Feb 14 19:31:28 2016 Return-Path: Delivered-To: freebsd-toolchain@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 2EC16AA864E; Sun, 14 Feb 2016 19:31:28 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id A178539D; Sun, 14 Feb 2016 19:31:27 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id A3DC71E2106D; Sun, 14 Feb 2016 20:29:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1455478143; bh=a3HfwErfTPWIfhkKugpsAhrXGlCbCrU9Ck90wIet0+Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Mhi+zRPOREeFrs/caU6Kpm5LN4KveZl6/iM+98leyutSAYHeuGUGE2zFXzyvr6GFF zmYoK9jyL5Vp6+RTnQZHufuTYbu6MWZDTajUiXaKLkHZWCQuwcPa6zRrokF0GgSLCg XQ6bT0hU8sB8W5V7GsM5oTiPypIfY7/xYe38UqKI= Date: Sun, 14 Feb 2016 20:29:03 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc Message-ID: <20160214192903.GA96697@vlakno.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 19:31:28 -0000 Fwiw, the code to handle the vaarg is in tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg() You can take a look to see whats wrong. On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote: > I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that shows up for using clang 3.8.0 to buildworld/installworld for powerpc. > > > ls -l -n / > > gets a SEGV. As listed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175 ( and https://llvm.org/bugs/show_bug.cgi?id=26605 ) the following simplified program also gets the SEGV on powerpc: > > > #include // for va_list, va_start, va_arg, va_end > > #include // for intmax_t > > > > intmax_t > > va_test (char *s, ...) > > { > > va_list vap; > > > > va_start(vap, s); > > > > char* t0 = va_arg(vap, char*); > > unsigned int o0 = va_arg(vap, unsigned int); > > int c0 = va_arg(vap, int); > > unsigned int u0 = va_arg(vap, unsigned int); > > int c1 = va_arg(vap, int); > > char * t1 = va_arg(vap, char*); > > > > intmax_t j0 = va_arg(vap, intmax_t); // This spans into overflow_arg_area. > > > > int c2 = va_arg(vap, int); // A copy was put in the > > // overflow_arg_area because of the > > // above. > > // But this tries to extract from the > > // last 4 bytes of the reg_save_area. > > // It does not increment the > > // overflow_arg_area position pointer > > // past the copy that is there. > > > > char * t2 = va_arg(vap, char*); // The lack of increment before makes > > // this extraction off by 4 bytes. > > > > char t2fc = *t2; // <<< This gets SEGV. t2 actually got what should be > > // the c2 value. > > > > intmax_t j1 = va_arg(vap, intmax_t); > > > > va_end(vap); > > > > return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); > > // Avoid any optimize-away for lack of use. > > } > > > > int main(void) > > { > > char s[1025] = "test string for this"; > > > > char* t0 = s + 5; > > unsigned int o0 = 3; > > int c0 = 1; > > unsigned int u0 = 1; > > int c1 = 3; > > char * t1 = s + 12; > > intmax_t j0 = 314159265358979323; > > int c2 = 4; > > char * t2 = s + 16; > > intmax_t j1 = ~314159265358979323; > > > > intmax_t result = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); > > > > return (int) (result - (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); > > // Avoid any optimize-away for lack of use. > > } > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sun Feb 14 20:17:00 2016 Return-Path: Delivered-To: freebsd-toolchain@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 1C52DAA8770 for ; Sun, 14 Feb 2016 20:17:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAA0717FA for ; Sun, 14 Feb 2016 20:16:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x236.google.com with SMTP id y9so99138327qgd.3 for ; Sun, 14 Feb 2016 12:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yZgkoqeM5FhkF+24Q1MVUmBllSsqAKGEKbIXsFNy5hg=; b=nXUJA4oAP5u6IMgJkQFVb9wgL/CZATgWo8V2imd/mJFCyyXmQP1aKCgytIKb4LGQz0 o5zjOJ/EhO0z9P6iqN13k99xyPNuv1CM6Tjkq3Fbj+RufZ2ADS8WLKThiD46Lrb3/Z2F JQlmsJKpkKJUalO5jmFJILyFyzhJfgjWdqdlGpiECqnrywYzTvxFAtaJ57rYZpVqTmuZ hybpXVxbu1K4XaJwOzKUmeGdUY/8wMR9sGygbKJkE3dLi0zKl0lwcoP36UqiYLV5wRZP NtYsuvSNRayJlyZtznparWtRXGOhxhxskxgRV7T99r3o8tAy09Wy0RxwjukmIM36TKIb j9RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yZgkoqeM5FhkF+24Q1MVUmBllSsqAKGEKbIXsFNy5hg=; b=loqst4vMRiCDkemI2PRws/GOacPgYHvmIwQQxWScPFVYezbtGoqkOrmkg3KsPrkFtN tzV47vgKVD0OGUY7fzef61x5RL0E03RZP4bJTXbRih++i5BqtzBf1x09krD0WE3nT3gE tSpcJSHkADxpTDP/T2Nr6IGGKViIj9RJ2eBGM+UxF+GJXYxAx0jtwUjpEjCh5OXXlOvg xmnyHSrG76qYnIINuPDKsUtSe9DhShk0qTaHObvOo2GDe7ocCzjUoX8jVvizq6+GF2gx tbKSjexCjCUcwesi72r2SHbvFdOcLXTmO0WMxCPj+6nPxxNFMeIJ0iSfEhrqWZGcBnT/ IxBQ== X-Gm-Message-State: AG10YOSDlWu/BiBpurX5OePMRNUKt0l8E8wEsy1/aSYmX9Z4nBmXU2/27CXYAokQIOIKkwxFgRd/o6sBhOVmyA== MIME-Version: 1.0 X-Received: by 10.140.28.162 with SMTP id 31mr16270187qgz.81.1455481018888; Sun, 14 Feb 2016 12:16:58 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Sun, 14 Feb 2016 12:16:58 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Sun, 14 Feb 2016 13:16:58 -0700 X-Google-Sender-Auth: UkHE7PnABmt5GPVHTPa7XdYbTic Message-ID: Subject: Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? From: Warner Losh To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 20:17:00 -0000 On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard wrote: > Is buildworld supposed to use /usr/include's area for finding files by > default? (I'm not talking of ${WORLDTMP}/usr/include but of just > /usr/include.) > Yes, but only though the end of the bootstrap phase. > It does use /usr/include's area for some contexts: self-hosted builds > without a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a > powerpc host using gcc 4.2.1 without an explicit XCC assignment that also > directs it to gcc 4.2.1 via a full path). > > /usr/src/Makefile.inc1 has the following sort of logic: > > > .if ${XCC:N${CCACHE_BIN}:M/*} > . . . > > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc > > XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib > > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 > -L${WORLDTMP}/../lib/libc++ > . . . > > .else > . . . > > .endif > > XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > .else > > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) > > BFLAGS+= -B${CROSS_BINUTILS_PREFIX} > > XCFLAGS+= ${BFLAGS} > > XCXXFLAGS+= ${BFLAGS} > > .endif > > .endif # ${XCC:M/*} > > For contexts without the -isystem and/or --sysroot in XCFLAGS . . . > > Is it appropriate to submit bug reports for buildworld getting include > files from /usr/include instead of from ${WORLDTMP} or from /usr/src areas? > If it is during the build everything phase, yes it is a build bug. If it is during the bootstrap phase, then yes, it is expected we use the host, but there's some incompatibility in bootstrapping we need to fix. > This tends to be noticed when something like the following. . . > > > # svnlite update -r295453 /usr/src > > # env __MAKE_CONF=/root/src.configs/make.conf > SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host > MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld > buildkernel > > ends up with compile errors from using some older /usr/include header > files that are no longer sufficient to allow compilation. > > I recently had a couple of examples where the cc command in the script > output file for the failing compiles showed no -I , no -isystem , no > --sysroot , nothing that would have allowed it to even potentially avoid > /usr/include (old file) use. The Makefile*'s involved had no > CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH . > > (Some types of header changes might not stop a build but might make the > build result wrong without much explicit notification. I'd prefer to avoid > such as well.) > > I expect that there are analogous points/questions for finding libraries. > Specific examples would be most welcome. Warner From owner-freebsd-toolchain@freebsd.org Sun Feb 14 20:35:51 2016 Return-Path: Delivered-To: freebsd-toolchain@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 12BC0AA8EB7 for ; Sun, 14 Feb 2016 20:35:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBF4B1E88 for ; Sun, 14 Feb 2016 20:35:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19880 invoked from network); 14 Feb 2016 20:35:47 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 20:35:47 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 14 Feb 2016 15:35:52 -0500 (EST) Received: (qmail 17805 invoked from network); 14 Feb 2016 20:35:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 20:35:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 827E71C43E2; Sun, 14 Feb 2016 12:35:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? From: Mark Millard In-Reply-To: Date: Sun, 14 Feb 2016 12:35:47 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> References: To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 20:35:51 -0000 On 2016-Feb-14, at 12:16 PM, Warner Losh wrote: >=20 > On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard = wrote: > Is buildworld supposed to use /usr/include's area for finding files by = default? (I'm not talking of ${WORLDTMP}/usr/include but of just = /usr/include.) >=20 > Yes, but only though the end of the bootstrap phase. > =20 > It does use /usr/include's area for some contexts: self-hosted builds = without a special XCC full path (e.g., an implicit TARGET_ARCH=3Dpowerpc = on a powerpc host using gcc 4.2.1 without an explicit XCC assignment = that also directs it to gcc 4.2.1 via a full path). >=20 > /usr/src/Makefile.inc1 has the following sort of logic: >=20 > > .if ${XCC:N${CCACHE_BIN}:M/*} > . . . > > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > . . . > > .else > . . . > > .endif > > XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > > XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > > .else > > .if defined(CROSS_BINUTILS_PREFIX) && = exists(${CROSS_BINUTILS_PREFIX}) > > BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} > > XCFLAGS+=3D ${BFLAGS} > > XCXXFLAGS+=3D ${BFLAGS} > > .endif > > .endif # ${XCC:M/*} >=20 > For contexts without the -isystem and/or --sysroot in XCFLAGS . . . >=20 > Is it appropriate to submit bug reports for buildworld getting include = files from /usr/include instead of from ${WORLDTMP} or from /usr/src = areas? >=20 > If it is during the build everything phase, yes it is a build bug. If = it is during the bootstrap phase, then yes, it is expected we use the = host, but there's some incompatibility in bootstrapping we need to fix. > =20 > This tends to be noticed when something like the following. . . >=20 > > # svnlite update -r295453 /usr/src > > # env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel >=20 > ends up with compile errors from using some older /usr/include header = files that are no longer sufficient to allow compilation. >=20 > I recently had a couple of examples where the cc command in the script = output file for the failing compiles showed no -I , no -isystem , no = --sysroot , nothing that would have allowed it to even potentially avoid = /usr/include (old file) use. The Makefile*'s involved had no = CFLAGS+=3DSOMETHING_DIRECTING_INCLUDE_SEARCH . >=20 > (Some types of header changes might not stop a build but might make = the build result wrong without much explicit notification. I'd prefer to = avoid such as well.) >=20 > I expect that there are analogous points/questions for finding = libraries. >=20 > Specific examples would be most welcome. >=20 > Warner=20 I had submitted the following bug reports for the two recent examples = that prompted my question. . . https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207147 for: In file included from /usr/src/lib/libmemstat/memstat_uma.c:37: /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has = incomplete type https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207148 for: /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use = in this function) In both cases the /usr/include vintage file was in use after my update = of /usr/src to -r295453. In both cases the "cc" command had no -I , no = -sysroot , and no -isystem to direct the searching for the header file. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Feb 14 22:34:39 2016 Return-Path: Delivered-To: freebsd-toolchain@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 216FEAA83BF for ; Sun, 14 Feb 2016 22:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCD1B8D4 for ; Sun, 14 Feb 2016 22:34:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21026 invoked from network); 14 Feb 2016 22:34:30 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 22:34:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 14 Feb 2016 17:34:26 -0500 (EST) Received: (qmail 1641 invoked from network); 14 Feb 2016 22:34:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 22:34:26 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 43E731C43D8; Sun, 14 Feb 2016 14:34:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <20160214192903.GA96697@vlakno.cz> Date: Sun, 14 Feb 2016 14:34:30 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 22:34:39 -0000 On 2016-Feb-14, at 11:29 AM, Roman Divacky wrote: >=20 > Fwiw, the code to handle the vaarg is in=20 > tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg() >=20 > You can take a look to see whats wrong. >=20 > On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote: >> I've isolated another clang 3.8.0 TARGET_ARCH=3Dpowerpc SEGV problem = that shows up for using clang 3.8.0 to buildworld/installworld for = powerpc. >>=20 >>> ls -l -n / >>=20 >> gets a SEGV. As listed in = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207175 ( and = https://llvm.org/bugs/show_bug.cgi?id=3D26605 ) the following simplified = program also gets the SEGV on powerpc: >>=20 >>> #include // for va_list, va_start, va_arg, va_end >>> #include // for intmax_t >>>=20 >>> intmax_t >>> va_test (char *s, ...) >>> { >>> va_list vap; >>>=20 >>> va_start(vap, s); >>>=20 >>> char* t0 =3D va_arg(vap, char*); >>> unsigned int o0 =3D va_arg(vap, unsigned int); >>> int c0 =3D va_arg(vap, int); >>> unsigned int u0 =3D va_arg(vap, unsigned int); >>> int c1 =3D va_arg(vap, int); >>> char * t1 =3D va_arg(vap, char*); >>>=20 >>> intmax_t j0 =3D va_arg(vap, intmax_t); // This spans into = overflow_arg_area. >>>=20 >>> int c2 =3D va_arg(vap, int); // A copy was put in = the=20 >>> // overflow_arg_area = because of the >>> // above. >>> // But this tries to = extract from the >>> // last 4 bytes of the = reg_save_area. >>> // It does not increment = the >>> // overflow_arg_area = position pointer >>> // past the copy that is = there. >>>=20 >>> char * t2 =3D va_arg(vap, char*); // The lack of = increment before makes >>> // this extraction off = by 4 bytes. >>>=20 >>> char t2fc =3D *t2; // <<< This gets SEGV. t2 actually = got what should be >>> // the c2 value. >>>=20 >>> intmax_t j1 =3D va_arg(vap, intmax_t); >>>=20 >>> va_end(vap); >>>=20 >>> return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); >>> // Avoid any optimize-away for lack of use. >>> } >>>=20 >>> int main(void) >>> { >>> char s[1025] =3D "test string for this"; >>>=20 >>> char* t0 =3D s + 5; >>> unsigned int o0 =3D 3; >>> int c0 =3D 1; >>> unsigned int u0 =3D 1; >>> int c1 =3D 3; >>> char * t1 =3D s + 12; >>> intmax_t j0 =3D 314159265358979323; >>> int c2 =3D 4; >>> char * t2 =3D s + 16; >>> intmax_t j1 =3D ~314159265358979323; >>>=20 >>> intmax_t result =3D = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); >>>=20 >>> return (int) (result - (intmax_t) = ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); >>> // Avoid any optimize-away for lack of use. >>> } >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" clang's code base is not familiar material for me nor do I have solid = reference material for the FreeBSD TARGET_ARCH=3Dpowerpc ABI rules so = the below has my guess work involved. The following code appears to have hard wired a global, unvarying = constant (8) into the test for picking UsingRegs vs. UsingOverflow. > llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); . . . > llvm::Value *CC =3D > Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >=20 > llvm::BasicBlock *UsingRegs =3D CGF.createBasicBlock("using_regs"); > llvm::BasicBlock *UsingOverflow =3D = CGF.createBasicBlock("using_overflow"); > llvm::BasicBlock *Cont =3D CGF.createBasicBlock("cont"); >=20 > Builder.CreateCondBr(CC, UsingRegs, UsingOverflow); . . . > // Case 1: consume registers. > Address RegAddr =3D Address::invalid(); > { . . . > // Increase the used-register count. > NumRegs =3D > Builder.CreateAdd(NumRegs, > Builder.getInt8((isI64 || (isF64 && = IsSoftFloatABI)) ? 2 : 1)); > Builder.CreateStore(NumRegs, NumRegsAddr);. . . . . . > } >=20 > // Case 2: consume space in the overflow area. > Address MemAddr =3D Address::invalid(); > { . . . (no adjustments to NumRegs) . . . If so the means of counting NumRegs (a.k.a. gpr) then needs to take into = account an allocated but unused last UsingRegs "slot" sometimes. = Imagine. . . r3, r4, r5, r6, r7, r8, r9 in use already so r10 is the last possible = "UsingRegs" context. (0 1 2 3 4 5 6, leaving r10 as position 7, the last < 8 = value) Then the next two arguments are a 8 byte integer then a a 4 byte integer = (in that order). That results in what should be: r10 "UsingRegs" slot reserved and un-accessed In other words: counted as allocated so that the rest goes in in the = overflow area (so no position 7 usage) then overflow with the 8 byte integer then the 4 byte integer. And, in fact, the memory content reflects this in the overflow area. But the va_arg access code does not count r10's slot as allocated in = "Using Regs" after the 8 byte integer. So later it tries to use r10's = slot for the 4 byte integer that is actually in the UsingOverflow area. One fix of sorts is to have "Case 2: consume space in the overflow = area." set NumRegs (a.k.a. gpr) to the bound from the = Builder.CreateICmpULT (8 in this context). Then the first (or any/every) = use of the UsingOverflow area forces no more use of the UsingRegs area = (for the involved va_list). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Feb 14 23:40:59 2016 Return-Path: Delivered-To: freebsd-toolchain@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 75686AA905E for ; Sun, 14 Feb 2016 23:40:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B584CD7 for ; Sun, 14 Feb 2016 23:40:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5140 invoked from network); 14 Feb 2016 23:40:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 23:40:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 14 Feb 2016 18:41:00 -0500 (EST) Received: (qmail 4198 invoked from network); 14 Feb 2016 23:41:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 23:41:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 755791C43E3; Sun, 14 Feb 2016 15:40:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? From: Mark Millard In-Reply-To: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> Date: Sun, 14 Feb 2016 15:40:56 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <338854A3-DB47-4356-B63C-1901894FA1D2@dsl-only.net> References: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 23:40:59 -0000 A top post as I figured out what is going on: My original src.conf had a bad "optimization" where I had been thinking = that since I had a working compiler that was not being updated with new = source code that I could avoid the time to rebuild it during the = bootstrap: WITHOUT_GCC_BOOTSTRAP=3D But this makes the default include/library paths wrong for buildworld = and the like and so requires them to be enforced on the command line. = The build environment is not set up to automatically do that in such = cases. So I had wondered out of bounds. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-14, at 12:35 PM, Mark Millard wrote: >=20 > On 2016-Feb-14, at 12:16 PM, Warner Losh wrote: >>=20 >> On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard = wrote: >> Is buildworld supposed to use /usr/include's area for finding files = by default? (I'm not talking of ${WORLDTMP}/usr/include but of just = /usr/include.) >>=20 >> Yes, but only though the end of the bootstrap phase. >>=20 >> It does use /usr/include's area for some contexts: self-hosted builds = without a special XCC full path (e.g., an implicit TARGET_ARCH=3Dpowerpc = on a powerpc host using gcc 4.2.1 without an explicit XCC assignment = that also directs it to gcc 4.2.1 via a full path). >>=20 >> /usr/src/Makefile.inc1 has the following sort of logic: >>=20 >>> .if ${XCC:N${CCACHE_BIN}:M/*} >> . . . >>> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc >>> XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib >>> XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ >> . . . >>> .else >> . . . >>> .endif >>> XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} >>> XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} >>> .else >>> .if defined(CROSS_BINUTILS_PREFIX) && = exists(${CROSS_BINUTILS_PREFIX}) >>> BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} >>> XCFLAGS+=3D ${BFLAGS} >>> XCXXFLAGS+=3D ${BFLAGS} >>> .endif >>> .endif # ${XCC:M/*} >>=20 >> For contexts without the -isystem and/or --sysroot in XCFLAGS . . . >>=20 >> Is it appropriate to submit bug reports for buildworld getting = include files from /usr/include instead of from ${WORLDTMP} or from = /usr/src areas? >>=20 >> If it is during the build everything phase, yes it is a build bug. If = it is during the bootstrap phase, then yes, it is expected we use the = host, but there's some incompatibility in bootstrapping we need to fix. >>=20 >> This tends to be noticed when something like the following. . . >>=20 >>> # svnlite update -r295453 /usr/src >>> # env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel >>=20 >> ends up with compile errors from using some older /usr/include header = files that are no longer sufficient to allow compilation. >>=20 >> I recently had a couple of examples where the cc command in the = script output file for the failing compiles showed no -I , no -isystem , = no --sysroot , nothing that would have allowed it to even potentially = avoid /usr/include (old file) use. The Makefile*'s involved had no = CFLAGS+=3DSOMETHING_DIRECTING_INCLUDE_SEARCH . >>=20 >> (Some types of header changes might not stop a build but might make = the build result wrong without much explicit notification. I'd prefer to = avoid such as well.) >>=20 >> I expect that there are analogous points/questions for finding = libraries. >>=20 >> Specific examples would be most welcome. >>=20 >> Warner=20 >=20 > I had submitted the following bug reports for the two recent examples = that prompted my question. . . >=20 >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207147 for: >=20 > In file included from /usr/src/lib/libmemstat/memstat_uma.c:37: > /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has = incomplete type >=20 >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207148 for: >=20 > /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use = in this function) >=20 >=20 >=20 > In both cases the /usr/include vintage file was in use after my update = of /usr/src to -r295453. In both cases the "cc" command had no -I , no = -sysroot , and no -isystem to direct the searching for the header file. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-toolchain@freebsd.org Sun Feb 14 23:46:14 2016 Return-Path: Delivered-To: freebsd-toolchain@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 339E9AA92BD for ; Sun, 14 Feb 2016 23:46:14 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 228FC11C5 for ; Sun, 14 Feb 2016 23:46:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-127.airbears2.berkeley.edu [136.152.142.127]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u1ENk5ii003813 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 14 Feb 2016 15:46:06 -0800 Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc To: freebsd-toolchain@freebsd.org References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> From: Nathan Whitehorn Message-ID: <56C111BD.8090701@freebsd.org> Date: Sun, 14 Feb 2016 15:46:05 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYfzufWPjlwbio8EQWrpEFKc1Ps9wzqDxirWlky1/qiiv6qXsQiRkgH1jWFPyxASvy5XjtwBR0Zdurgs3UoIbyQEwky6a7EawI= X-Sonic-ID: C;uEc1HXXT5RGiJXFkAoajKQ== M;1GdiHXXT5RGiJXFkAoajKQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 23:46:14 -0000 On 02/14/16 14:34, Mark Millard wrote: > clang's code base is not familiar material for me nor do I have solid > reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so > the below has my guess work involved. The following code appears to > have hard wired a global, unvarying constant (8) into the test for > picking UsingRegs vs. UsingOverflow. For reference, we use the standard ELF ABI (https://uclibc.org/docs/psABI-ppc.pdf). -Nathan From owner-freebsd-toolchain@freebsd.org Mon Feb 15 08:52:18 2016 Return-Path: Delivered-To: freebsd-toolchain@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 3F032AA8D48 for ; Mon, 15 Feb 2016 08:52:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01AD51112 for ; Mon, 15 Feb 2016 08:52:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3096 invoked from network); 15 Feb 2016 08:52:30 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 08:52:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 15 Feb 2016 03:52:10 -0500 (EST) Received: (qmail 12072 invoked from network); 15 Feb 2016 08:52:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 08:52:10 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 43D921C43D8; Mon, 15 Feb 2016 00:52:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> Date: Mon, 15 Feb 2016 00:52:15 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> To: Roman Divacky , Nathan Whitehorn X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 08:52:18 -0000 I'm top posting as the following can stand on its own fairly well. On Sun Feb 14 23:46:14 UTC 2016 Nathan Whitehorn wrote: > On 02/14/16 14:34, Mark Millard wrote: > > clang's code base is not familiar material for me nor do I have = solid=20 > > reference material for the FreeBSD TARGET_ARCH=3Dpowerpc ABI rules = so=20 > > the below has my guess work involved. The following code appears to=20= > > have hard wired a global, unvarying constant (8) into the test for=20= > > picking UsingRegs vs. UsingOverflow. >=20 > For reference, we use the standard ELF ABI=20 > (https://uclibc.org/docs/psABI-ppc.pdf). > -Nathan Reviewing the Parameter Passing material in that document shows that the = problem is in the original specification. And there is a more modern specification that has a fix in its wording. = (Which shows that I'm not likely to be wrong.) I'll reference and quote = it later. First I'll explain the problem that is in psABI-ppc.pdf (the old SunSoft = 1995 document). First a numbering point: psABI-ppc.pdf uses "gr" matching the numeral in = r3, r4, . . . , r10, starting at r3 (i.e, 3). And gr indicates the next = register to be used, not the last one already used. The document splits the algorithm for placement of parameters into 3 = stages with the following structure, intended as they have it in the = document but various less interesting details for my "8byte then 4byte" = example omitted: > INITIALIZING: > Set fr=3D1, gr=3D3, and starg to the address of > parameter word 1. > SCAN: > If there are no more arguments, terminate. > Otherwise, select one of the following > depending on the type of the next argument: >=20 > DOUBLE_OR_FLOAT > If fr>8 ( . . .), go to OTHER. Otherwise, > . . . >=20 > SIMPLE_ARG > If gr>10, go to OTHER. Otherwise, load the > argument value into general register gr, > set gr to gr+1, can goto SCAN. . . . >=20 > LONG_LONG > If gr>9, go to OTHER. Otherwise, . . . >=20 > OTHER: > Arguments not otherwise handled above are > passed in the parameter words of the > caller=E2=80=99s stack frame. . . . Set starg to > starg+size, then go to SCAN. Note that gr is not incremented by LONG_LONG or by the later OTHER usage = when gr>9. (That would be my example's 8 byte integer that is later = followed by a 4 byte one.) That OTHER's "go to SCAN" would then lead to the following 4 byte = integer in my example to be put in r10 and gr then being set to 11 = instead of it being stored in a parameter word on the stack. The nasty thing about this for va_list/va_arg use is that the stored = information does not indicate which was before vs. after in the argument = order: the 4 byte r10 content or the 8 byte "OTHER" content: the two = orders produce identical results. This can not be correct. The Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf is more modern and = explicitly deals with VR and other modern things. (Its terminology = matching LONG_LONG above is DUAL_GP.) But for what I'm dealing with here = it has the following extra wording at the very end of its OTHER section: > If gr>9 and the type is DUAL_GP ,or . . ., or . . ., then set gr =3D = 11 (to prevent subsequent SINGLE_GPs from being placed in registers = after DUAL_GP, QUAD_GP, or EIGHT_GP arguments that would no longer fit = in the registers). I've left the prior information below for reference. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-14, at 2:34 PM, Mark Millard wrote: >=20 > On 2016-Feb-14, at 11:29 AM, Roman Divacky wrote: >>=20 >> Fwiw, the code to handle the vaarg is in=20 >> = tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg() >>=20 >> You can take a look to see whats wrong. >>=20 >> On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote: >>> I've isolated another clang 3.8.0 TARGET_ARCH=3Dpowerpc SEGV problem = that shows up for using clang 3.8.0 to buildworld/installworld for = powerpc. >>>=20 >>>> ls -l -n / >>>=20 >>> gets a SEGV. As listed in = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207175 ( and = https://llvm.org/bugs/show_bug.cgi?id=3D26605 ) the following simplified = program also gets the SEGV on powerpc: >>>=20 >>>> #include // for va_list, va_start, va_arg, va_end >>>> #include // for intmax_t >>>>=20 >>>> intmax_t >>>> va_test (char *s, ...) >>>> { >>>> va_list vap; >>>>=20 >>>> va_start(vap, s); >>>>=20 >>>> char* t0 =3D va_arg(vap, char*); >>>> unsigned int o0 =3D va_arg(vap, unsigned int); >>>> int c0 =3D va_arg(vap, int); >>>> unsigned int u0 =3D va_arg(vap, unsigned int); >>>> int c1 =3D va_arg(vap, int); >>>> char * t1 =3D va_arg(vap, char*); >>>>=20 >>>> intmax_t j0 =3D va_arg(vap, intmax_t); // This spans into = overflow_arg_area. >>>>=20 >>>> int c2 =3D va_arg(vap, int); // A copy was put in = the=20 >>>> // overflow_arg_area = because of the >>>> // above. >>>> // But this tries to = extract from the >>>> // last 4 bytes of the = reg_save_area. >>>> // It does not increment = the >>>> // overflow_arg_area = position pointer >>>> // past the copy that is = there. >>>>=20 >>>> char * t2 =3D va_arg(vap, char*); // The lack of = increment before makes >>>> // this extraction off = by 4 bytes. >>>>=20 >>>> char t2fc =3D *t2; // <<< This gets SEGV. t2 actually = got what should be >>>> // the c2 value. >>>>=20 >>>> intmax_t j1 =3D va_arg(vap, intmax_t); >>>>=20 >>>> va_end(vap); >>>>=20 >>>> return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); >>>> // Avoid any optimize-away for lack of use. >>>> } >>>>=20 >>>> int main(void) >>>> { >>>> char s[1025] =3D "test string for this"; >>>>=20 >>>> char* t0 =3D s + 5; >>>> unsigned int o0 =3D 3; >>>> int c0 =3D 1; >>>> unsigned int u0 =3D 1; >>>> int c1 =3D 3; >>>> char * t1 =3D s + 12; >>>> intmax_t j0 =3D 314159265358979323; >>>> int c2 =3D 4; >>>> char * t2 =3D s + 16; >>>> intmax_t j1 =3D ~314159265358979323; >>>>=20 >>>> intmax_t result =3D = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); >>>>=20 >>>> return (int) (result - (intmax_t) = ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); >>>> // Avoid any optimize-away for lack of use. >>>> } >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> _______________________________________________ >>> freebsd-toolchain@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >>> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 > clang's code base is not familiar material for me nor do I have solid = reference material for the FreeBSD TARGET_ARCH=3Dpowerpc ABI rules so = the below has my guess work involved. >=20 > The following code appears to have hard wired a global, unvarying = constant (8) into the test for picking UsingRegs vs. UsingOverflow. >=20 >=20 >> llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); > . . . >> llvm::Value *CC =3D >> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >>=20 >> llvm::BasicBlock *UsingRegs =3D CGF.createBasicBlock("using_regs"); >> llvm::BasicBlock *UsingOverflow =3D = CGF.createBasicBlock("using_overflow"); >> llvm::BasicBlock *Cont =3D CGF.createBasicBlock("cont"); >>=20 >> Builder.CreateCondBr(CC, UsingRegs, UsingOverflow); > . . . >> // Case 1: consume registers. >> Address RegAddr =3D Address::invalid(); >> { > . . . >> // Increase the used-register count. >> NumRegs =3D >> Builder.CreateAdd(NumRegs, >> Builder.getInt8((isI64 || (isF64 && = IsSoftFloatABI)) ? 2 : 1)); >> Builder.CreateStore(NumRegs, NumRegsAddr);. . . > . . . >> } >>=20 >> // Case 2: consume space in the overflow area. >> Address MemAddr =3D Address::invalid(); >> { > . . . (no adjustments to NumRegs) . . . >=20 > If so the means of counting NumRegs (a.k.a. gpr) then needs to take = into account an allocated but unused last UsingRegs "slot" sometimes. = Imagine. . . >=20 > r3, r4, r5, r6, r7, r8, r9 in use already so r10 is the last possible = "UsingRegs" context. > (0 1 2 3 4 5 6, leaving r10 as position 7, the last < 8 = value) >=20 > Then the next two arguments are a 8 byte integer then a a 4 byte = integer (in that order). That results in what should be: >=20 > r10 "UsingRegs" slot reserved and un-accessed > In other words: counted as allocated so that the rest goes in in the = overflow area > (so no position 7 usage) >=20 > then >=20 > overflow with the 8 byte integer then the 4 byte integer. >=20 >=20 > And, in fact, the memory content reflects this in the overflow area. >=20 >=20 > But the va_arg access code does not count r10's slot as allocated in = "Using Regs" after the 8 byte integer. So later it tries to use r10's = slot for the 4 byte integer that is actually in the UsingOverflow area. >=20 > One fix of sorts is to have "Case 2: consume space in the overflow = area." set NumRegs (a.k.a. gpr) to the bound from the = Builder.CreateICmpULT (8 in this context). Then the first (or any/every) = use of the UsingOverflow area forces no more use of the UsingRegs area = (for the involved va_list). >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Feb 15 19:13:19 2016 Return-Path: Delivered-To: freebsd-toolchain@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 ADB50AA924C; Mon, 15 Feb 2016 19:13:19 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3F28596B; Mon, 15 Feb 2016 19:13:18 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id D9FAC1E22EB6; Mon, 15 Feb 2016 20:11:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1455563460; bh=amKAlV+9OOHDTVVXhmExUFuA3Tia68EeeN/rkOwbvos=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=poH/ScoBbNVIDXQHRJxd2crFDE/ibsdmdmhoA+iFWPRH/VY2ZhBRZP5c4ZQyc8JCg DWx6yU0mhtIIQEPM/VvJKXGW4UVYSlmIrbRurakBFSaRJROtzEO50f/uOliPXVCagQ qJyOOROnUEW0QuGYazAykXBfRDqfsWrLZkq6umMA= Date: Mon, 15 Feb 2016 20:11:00 +0100 From: Roman Divacky To: Mark Millard Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc Message-ID: <20160215191100.GA17387@vlakno.cz> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 19:13:19 -0000 Mark, I believe you're right. What do you think about this patch? Index: tools/clang/lib/CodeGen/TargetInfo.cpp =================================================================== --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) @@ -3599,6 +3599,8 @@ { CGF.EmitBlock(UsingOverflow); + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); + // Everything in the overflow area is rounded up to a size of at least 4. CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4); Can you test it? On Mon, Feb 15, 2016 at 12:52:15AM -0800, Mark Millard wrote: > > I'm top posting as the following can stand on its own fairly well. > > On Sun Feb 14 23:46:14 UTC 2016 Nathan Whitehorn wrote: > > > On 02/14/16 14:34, Mark Millard wrote: > > > clang's code base is not familiar material for me nor do I have solid > > > reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so > > > the below has my guess work involved. The following code appears to > > > have hard wired a global, unvarying constant (8) into the test for > > > picking UsingRegs vs. UsingOverflow. > > > > For reference, we use the standard ELF ABI > > (https://uclibc.org/docs/psABI-ppc.pdf). > > -Nathan > > Reviewing the Parameter Passing material in that document shows that the problem is in the original specification. > > And there is a more modern specification that has a fix in its wording. (Which shows that I'm not likely to be wrong.) I'll reference and quote it later. > > First I'll explain the problem that is in psABI-ppc.pdf (the old SunSoft 1995 document). > > First a numbering point: psABI-ppc.pdf uses "gr" matching the numeral in r3, r4, . . . , r10, starting at r3 (i.e, 3). And gr indicates the next register to be used, not the last one already used. > > The document splits the algorithm for placement of parameters into 3 stages with the following structure, intended as they have it in the document but various less interesting details for my "8byte then 4byte" example omitted: > > > INITIALIZING: > > Set fr=1, gr=3, and starg to the address of > > parameter word 1. > > SCAN: > > If there are no more arguments, terminate. > > Otherwise, select one of the following > > depending on the type of the next argument: > > > > DOUBLE_OR_FLOAT > > If fr>8 ( . . .), go to OTHER. Otherwise, > > . . . > > > > SIMPLE_ARG > > If gr>10, go to OTHER. Otherwise, load the > > argument value into general register gr, > > set gr to gr+1, can goto SCAN. . . . > > > > LONG_LONG > > If gr>9, go to OTHER. Otherwise, . . . > > > > OTHER: > > Arguments not otherwise handled above are > > passed in the parameter words of the > > caller???s stack frame. . . . Set starg to > > starg+size, then go to SCAN. > > Note that gr is not incremented by LONG_LONG or by the later OTHER usage when gr>9. (That would be my example's 8 byte integer that is later followed by a 4 byte one.) > > That OTHER's "go to SCAN" would then lead to the following 4 byte integer in my example to be put in r10 and gr then being set to 11 instead of it being stored in a parameter word on the stack. > > The nasty thing about this for va_list/va_arg use is that the stored information does not indicate which was before vs. after in the argument order: the 4 byte r10 content or the 8 byte "OTHER" content: the two orders produce identical results. > > This can not be correct. > > The Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf is more modern and explicitly deals with VR and other modern things. (Its terminology matching LONG_LONG above is DUAL_GP.) But for what I'm dealing with here it has the following extra wording at the very end of its OTHER section: > > > If gr>9 and the type is DUAL_GP ,or . . ., or . . ., then set gr = 11 (to prevent subsequent SINGLE_GPs from being placed in registers after DUAL_GP, QUAD_GP, or EIGHT_GP arguments that would no longer fit in the registers). > > > > I've left the prior information below for reference. > > === > Mark Millard > markmi at dsl-only.net > > > > On 2016-Feb-14, at 2:34 PM, Mark Millard wrote: > > > > On 2016-Feb-14, at 11:29 AM, Roman Divacky wrote: > >> > >> Fwiw, the code to handle the vaarg is in > >> tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg() > >> > >> You can take a look to see whats wrong. > >> > >> On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote: > >>> I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that shows up for using clang 3.8.0 to buildworld/installworld for powerpc. > >>> > >>>> ls -l -n / > >>> > >>> gets a SEGV. As listed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175 ( and https://llvm.org/bugs/show_bug.cgi?id=26605 ) the following simplified program also gets the SEGV on powerpc: > >>> > >>>> #include // for va_list, va_start, va_arg, va_end > >>>> #include // for intmax_t > >>>> > >>>> intmax_t > >>>> va_test (char *s, ...) > >>>> { > >>>> va_list vap; > >>>> > >>>> va_start(vap, s); > >>>> > >>>> char* t0 = va_arg(vap, char*); > >>>> unsigned int o0 = va_arg(vap, unsigned int); > >>>> int c0 = va_arg(vap, int); > >>>> unsigned int u0 = va_arg(vap, unsigned int); > >>>> int c1 = va_arg(vap, int); > >>>> char * t1 = va_arg(vap, char*); > >>>> > >>>> intmax_t j0 = va_arg(vap, intmax_t); // This spans into overflow_arg_area. > >>>> > >>>> int c2 = va_arg(vap, int); // A copy was put in the > >>>> // overflow_arg_area because of the > >>>> // above. > >>>> // But this tries to extract from the > >>>> // last 4 bytes of the reg_save_area. > >>>> // It does not increment the > >>>> // overflow_arg_area position pointer > >>>> // past the copy that is there. > >>>> > >>>> char * t2 = va_arg(vap, char*); // The lack of increment before makes > >>>> // this extraction off by 4 bytes. > >>>> > >>>> char t2fc = *t2; // <<< This gets SEGV. t2 actually got what should be > >>>> // the c2 value. > >>>> > >>>> intmax_t j1 = va_arg(vap, intmax_t); > >>>> > >>>> va_end(vap); > >>>> > >>>> return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); > >>>> // Avoid any optimize-away for lack of use. > >>>> } > >>>> > >>>> int main(void) > >>>> { > >>>> char s[1025] = "test string for this"; > >>>> > >>>> char* t0 = s + 5; > >>>> unsigned int o0 = 3; > >>>> int c0 = 1; > >>>> unsigned int u0 = 1; > >>>> int c1 = 3; > >>>> char * t1 = s + 12; > >>>> intmax_t j0 = 314159265358979323; > >>>> int c2 = 4; > >>>> char * t2 = s + 16; > >>>> intmax_t j1 = ~314159265358979323; > >>>> > >>>> intmax_t result = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); > >>>> > >>>> return (int) (result - (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); > >>>> // Avoid any optimize-away for lack of use. > >>>> } > >>> > >>> > >>> > >>> === > >>> Mark Millard > >>> markmi at dsl-only.net > >>> > >>> _______________________________________________ > >>> freebsd-toolchain@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > >>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" > > > > clang's code base is not familiar material for me nor do I have solid reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so the below has my guess work involved. > > > > The following code appears to have hard wired a global, unvarying constant (8) into the test for picking UsingRegs vs. UsingOverflow. > > > > > >> llvm::Value *NumRegs = Builder.CreateLoad(NumRegsAddr, "numUsedRegs"); > > . . . > >> llvm::Value *CC = > >> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); > >> > >> llvm::BasicBlock *UsingRegs = CGF.createBasicBlock("using_regs"); > >> llvm::BasicBlock *UsingOverflow = CGF.createBasicBlock("using_overflow"); > >> llvm::BasicBlock *Cont = CGF.createBasicBlock("cont"); > >> > >> Builder.CreateCondBr(CC, UsingRegs, UsingOverflow); > > . . . > >> // Case 1: consume registers. > >> Address RegAddr = Address::invalid(); > >> { > > . . . > >> // Increase the used-register count. > >> NumRegs = > >> Builder.CreateAdd(NumRegs, > >> Builder.getInt8((isI64 || (isF64 && IsSoftFloatABI)) ? 2 : 1)); > >> Builder.CreateStore(NumRegs, NumRegsAddr);. . . > > . . . > >> } > >> > >> // Case 2: consume space in the overflow area. > >> Address MemAddr = Address::invalid(); > >> { > > . . . (no adjustments to NumRegs) . . . > > > > If so the means of counting NumRegs (a.k.a. gpr) then needs to take into account an allocated but unused last UsingRegs "slot" sometimes. Imagine. . . > > > > r3, r4, r5, r6, r7, r8, r9 in use already so r10 is the last possible "UsingRegs" context. > > (0 1 2 3 4 5 6, leaving r10 as position 7, the last < 8 value) > > > > Then the next two arguments are a 8 byte integer then a a 4 byte integer (in that order). That results in what should be: > > > > r10 "UsingRegs" slot reserved and un-accessed > > In other words: counted as allocated so that the rest goes in in the overflow area > > (so no position 7 usage) > > > > then > > > > overflow with the 8 byte integer then the 4 byte integer. > > > > > > And, in fact, the memory content reflects this in the overflow area. > > > > > > But the va_arg access code does not count r10's slot as allocated in "Using Regs" after the 8 byte integer. So later it tries to use r10's slot for the 4 byte integer that is actually in the UsingOverflow area. > > > > One fix of sorts is to have "Case 2: consume space in the overflow area." set NumRegs (a.k.a. gpr) to the bound from the Builder.CreateICmpULT (8 in this context). Then the first (or any/every) use of the UsingOverflow area forces no more use of the UsingRegs area (for the involved va_list). > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Mon Feb 15 20:17:59 2016 Return-Path: Delivered-To: freebsd-toolchain@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 043DAAAACBA for ; Mon, 15 Feb 2016 20:17:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD377F55 for ; Mon, 15 Feb 2016 20:17:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31897 invoked from network); 15 Feb 2016 20:17:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 20:17:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 15 Feb 2016 15:18:01 -0500 (EST) Received: (qmail 9845 invoked from network); 15 Feb 2016 20:18:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 20:18:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7C4371C43B3; Mon, 15 Feb 2016 12:17:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <20160215191100.GA17387@vlakno.cz> Date: Mon, 15 Feb 2016 12:17:50 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:17:59 -0000 On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >=20 > Mark, I believe you're right. What do you think about this patch? >=20 > Index: tools/clang/lib/CodeGen/TargetInfo.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) > +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) > @@ -3599,6 +3599,8 @@ > { > CGF.EmitBlock(UsingOverflow); >=20 > + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); > + > // Everything in the overflow area is rounded up to a size of at = least 4. > CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >=20 >=20 > Can you test it? It may be later today before I can start the the test process. While your change is not wrong as presented, it does seem to be based on = the ABI document's numbering with the range 3 <=3D gr <12, where 3 <=3D = gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack area use. = (gr being the ABI documents name.) The clang code generation that I saw while analyzing the problem and the = clang source that you had me look at did not use that numbering. Instead = it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 cover = r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being what = gdb showed me as I remember.) In other words: clang counts the number of = "parameter registers" already in use as it goes along instead of = tracking register numbers that have been used. So assigning any value that appears to be positive and >=3D 8 should = work, such as: Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); A cross check on this is the clang source code below: > llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); > . . . > llvm::Value *CC =3D > Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >=20 > llvm::BasicBlock *UsingRegs =3D CGF.createBasicBlock("using_regs"); > llvm::BasicBlock *UsingOverflow =3D = CGF.createBasicBlock("using_overflow"); > llvm::BasicBlock *Cont =3D CGF.createBasicBlock("cont"); >=20 > Builder.CreateCondBr(CC, UsingRegs, UsingOverflow); I'd guess that the Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), = "cond") for using in Builder.CreateCondBr is a test for < 8 (unsigned = test?) picking UsingRegs and >=3D8 picking UsingOverflow. 11>=3D8 so 11 = would work. But the clang folks might prefer that the same figure be used in both = places, possibly with the source code naming the value once and using = the name in both places, not that the figure is likely to change in this = already PowerPC specific code. In analyzing the powerpc code absent knowledge of clang's code = generation source code I would likely have been confused by seeing such = differing numbers in the generated code if I'd run into such. That is = another reason to use the same figure in both places. I continue to provide some history below for reference. =3D=3D=3D Mark Millard markmi at dsl-only.net On Mon, Feb 15, 2016 at 12:52:15AM -0800, Mark Millard wrote: >=20 > I'm top posting as the following can stand on its own fairly well. >=20 > On Sun Feb 14 23:46:14 UTC 2016 Nathan Whitehorn wrote: >=20 >> On 02/14/16 14:34, Mark Millard wrote: >>> clang's code base is not familiar material for me nor do I have = solid=20 >>> reference material for the FreeBSD TARGET_ARCH=3Dpowerpc ABI rules = so=20 >>> the below has my guess work involved. The following code appears to=20= >>> have hard wired a global, unvarying constant (8) into the test for=20= >>> picking UsingRegs vs. UsingOverflow. >>=20 >> For reference, we use the standard ELF ABI=20 >> (https://uclibc.org/docs/psABI-ppc.pdf). >> -Nathan >=20 > Reviewing the Parameter Passing material in that document shows that = the problem is in the original specification. >=20 > And there is a more modern specification that has a fix in its = wording. (Which shows that I'm not likely to be wrong.) I'll reference = and quote it later. >=20 > First I'll explain the problem that is in psABI-ppc.pdf (the old = SunSoft 1995 document). >=20 > First a numbering point: psABI-ppc.pdf uses "gr" matching the numeral = in r3, r4, . . . , r10, starting at r3 (i.e, 3). And gr indicates the = next register to be used, not the last one already used. >=20 > The document splits the algorithm for placement of parameters into 3 = stages with the following structure, intended as they have it in the = document but various less interesting details for my "8byte then 4byte" = example omitted: >=20 >> INITIALIZING: >> Set fr=3D1, gr=3D3, and starg to the address of >> parameter word 1. >> SCAN: >> If there are no more arguments, terminate. >> Otherwise, select one of the following >> depending on the type of the next argument: >>=20 >> DOUBLE_OR_FLOAT >> If fr>8 ( . . .), go to OTHER. Otherwise, >> . . . >>=20 >> SIMPLE_ARG >> If gr>10, go to OTHER. Otherwise, load the >> argument value into general register gr, >> set gr to gr+1, can goto SCAN. . . . >>=20 >> LONG_LONG >> If gr>9, go to OTHER. Otherwise, . . . >>=20 >> OTHER: >> Arguments not otherwise handled above are >> passed in the parameter words of the >> caller???s stack frame. . . . Set starg to >> starg+size, then go to SCAN. >=20 > Note that gr is not incremented by LONG_LONG or by the later OTHER = usage when gr>9. (That would be my example's 8 byte integer that is = later followed by a 4 byte one.) >=20 > That OTHER's "go to SCAN" would then lead to the following 4 byte = integer in my example to be put in r10 and gr then being set to 11 = instead of it being stored in a parameter word on the stack. >=20 > The nasty thing about this for va_list/va_arg use is that the stored = information does not indicate which was before vs. after in the argument = order: the 4 byte r10 content or the 8 byte "OTHER" content: the two = orders produce identical results. >=20 > This can not be correct. >=20 > The Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf is more modern and = explicitly deals with VR and other modern things. (Its terminology = matching LONG_LONG above is DUAL_GP.) But for what I'm dealing with here = it has the following extra wording at the very end of its OTHER section: >=20 >> If gr>9 and the type is DUAL_GP ,or . . ., or . . ., then set gr =3D = 11 (to prevent subsequent SINGLE_GPs from being placed in registers = after DUAL_GP, QUAD_GP, or EIGHT_GP arguments that would no longer fit = in the registers). >=20 >=20 >=20 > I've left the prior information below for reference. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 > On 2016-Feb-14, at 2:34 PM, Mark Millard wrote: >>=20 >> . . . >> clang's code base is not familiar material for me nor do I have solid = reference material for the FreeBSD TARGET_ARCH=3Dpowerpc ABI rules so = the below has my guess work involved. >>=20 >> The following code appears to have hard wired a global, unvarying = constant (8) into the test for picking UsingRegs vs. UsingOverflow. >>=20 >>=20 >>> llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); >> . . . >>> llvm::Value *CC =3D >>> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >>>=20 >>> llvm::BasicBlock *UsingRegs =3D CGF.createBasicBlock("using_regs"); >>> llvm::BasicBlock *UsingOverflow =3D = CGF.createBasicBlock("using_overflow"); >>> llvm::BasicBlock *Cont =3D CGF.createBasicBlock("cont"); >>>=20 >>> Builder.CreateCondBr(CC, UsingRegs, UsingOverflow); >> . . . >>> // Case 1: consume registers. >>> Address RegAddr =3D Address::invalid(); >>> { >> . . . >>> // Increase the used-register count. >>> NumRegs =3D >>> Builder.CreateAdd(NumRegs, >>> Builder.getInt8((isI64 || (isF64 && = IsSoftFloatABI)) ? 2 : 1)); >>> Builder.CreateStore(NumRegs, NumRegsAddr);. . . >> . . . >>> } >>>=20 >>> // Case 2: consume space in the overflow area. >>> Address MemAddr =3D Address::invalid(); >>> { >> . . . (no adjustments to NumRegs) . . . >>=20 >> If so the means of counting NumRegs (a.k.a. gpr) then needs to take = into account an allocated but unused last UsingRegs "slot" sometimes. = Imagine. . . >>=20 >> r3, r4, r5, r6, r7, r8, r9 in use already so r10 is the last possible = "UsingRegs" context. >> (0 1 2 3 4 5 6, leaving r10 as position 7, the last < 8 = value) >>=20 >> Then the next two arguments are a 8 byte integer then a a 4 byte = integer (in that order). That results in what should be: >>=20 >> r10 "UsingRegs" slot reserved and un-accessed >> In other words: counted as allocated so that the rest goes in in the = overflow area >> (so no position 7 usage) >>=20 >> then >>=20 >> overflow with the 8 byte integer then the 4 byte integer. >>=20 >>=20 >> And, in fact, the memory content reflects this in the overflow area. >>=20 >>=20 >> But the va_arg access code does not count r10's slot as allocated in = "Using Regs" after the 8 byte integer. So later it tries to use r10's = slot for the 4 byte integer that is actually in the UsingOverflow area. >>=20 >> One fix of sorts is to have "Case 2: consume space in the overflow = area." set NumRegs (a.k.a. gpr) to the bound from the = Builder.CreateICmpULT (8 in this context). Then the first (or any/every) = use of the UsingOverflow area forces no more use of the UsingRegs area = (for the involved va_list). >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Mon Feb 15 20:20:24 2016 Return-Path: Delivered-To: freebsd-toolchain@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 216B5AAAD9D; Mon, 15 Feb 2016 20:20:24 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id DD95D101F; Mon, 15 Feb 2016 20:20:23 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id E45BD1E22EB6; Mon, 15 Feb 2016 21:18:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1455567480; bh=rapkILx3f5M4TmZ0s1vKsEqiopfGhNnZCBTHv/VIU+Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ByqJ/JcWoIRDCN2Rrft9gMprKYKaUjAkFpJbhF7P2bOT93b4+mGibd3+7tlt7k41g 6NV8Tm2TjNX6jjMXIsAlo+DJOYbB3KeH9Ans81vAkm6/1uriGgUzZTtedETHjhZLWl FJqe79MMITVYltGMTDE9moatc1YLTt8WWwhNJO58= Date: Mon, 15 Feb 2016 21:18:00 +0100 From: Roman Divacky To: Mark Millard Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc Message-ID: <20160215201800.GA20796@vlakno.cz> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:20:24 -0000 On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: > On 2016-Feb-15, at 11:11 AM, Roman Divacky wrote: > > > > Mark, I believe you're right. What do you think about this patch? > > > > Index: tools/clang/lib/CodeGen/TargetInfo.cpp > > =================================================================== > > --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) > > +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) > > @@ -3599,6 +3599,8 @@ > > { > > CGF.EmitBlock(UsingOverflow); > > > > + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); > > + > > // Everything in the overflow area is rounded up to a size of at least 4. > > CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4); > > > > > > Can you test it? > > It may be later today before I can start the the test process. > > While your change is not wrong as presented, it does seem to be based on the ABI document's numbering with the range 3 <= gr <12, where 3 <= gr < 11 cover r3-r10 use and gr=11 implies overflow stack area use. (gr being the ABI documents name.) > > The clang code generation that I saw while analyzing the problem and the clang source that you had me look at did not use that numbering. Instead it seems to be based on 0 <= gpr < 9, where 0 <= gpr < 8 cover r3-r10 use and gpr=8 implies overflow stack area use. (gpr being what gdb showed me as I remember.) In other words: clang counts the number of "parameter registers" already in use as it goes along instead of tracking register numbers that have been used. > > So assigning any value that appears to be positive and >= 8 should work, such as: > > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); Can you check what number gcc uses? We want to be interoperable with gcc. Anyway, thanks for testing! Roman From owner-freebsd-toolchain@freebsd.org Mon Feb 15 21:20:07 2016 Return-Path: Delivered-To: freebsd-toolchain@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 1E421AA9CDB for ; Mon, 15 Feb 2016 21:20:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C48A119DF for ; Mon, 15 Feb 2016 21:20:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24410 invoked from network); 15 Feb 2016 21:20:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 21:20:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 15 Feb 2016 16:20:14 -0500 (EST) Received: (qmail 3732 invoked from network); 15 Feb 2016 21:20:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 21:20:14 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AC8FB1C43A8; Mon, 15 Feb 2016 13:20:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <20160215201800.GA20796@vlakno.cz> Date: Mon, 15 Feb 2016 13:20:04 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:20:07 -0000 On 2016-Feb-15, at 12:18 PM, Roman Divacky wrote: >=20 > On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>=20 >>> Mark, I believe you're right. What do you think about this patch? >>>=20 >>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>> @@ -3599,6 +3599,8 @@ >>> { >>> CGF.EmitBlock(UsingOverflow); >>>=20 >>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>> + >>> // Everything in the overflow area is rounded up to a size of at = least 4. >>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>=20 >>>=20 >>> Can you test it? >>=20 >> It may be later today before I can start the the test process. >>=20 >> While your change is not wrong as presented, it does seem to be based = on the ABI document's numbering with the range 3 <=3D gr <12, where 3 <=3D= gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack area use. = (gr being the ABI documents name.) >>=20 >> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>=20 >> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>=20 >> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >=20 > Can you check what number gcc uses? We want to be interoperable with = gcc. >=20 > Anyway, thanks for testing! >=20 > Roman I'll do that check of gcc 4.2.1 code generation before starting the test = later today. But if the clang numbering is different in gcc 4.2.1 then far more than = just adding a > Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) for some "?" would need to be involved in the changes in order to reach = compatibility. I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form > cmplwi r?,7 for some r?, such as r5 or r4, and the conditional branch generated is a = bgt instruction. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Feb 16 00:28:02 2016 Return-Path: Delivered-To: freebsd-toolchain@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 8784EAA8396 for ; Tue, 16 Feb 2016 00:28:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C21D1E03 for ; Tue, 16 Feb 2016 00:28:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26240 invoked from network); 16 Feb 2016 00:28:01 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 00:28:01 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 15 Feb 2016 19:28:03 -0500 (EST) Received: (qmail 395 invoked from network); 16 Feb 2016 00:28:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 00:28:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D4F451C42A7; Mon, 15 Feb 2016 16:27:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: Date: Mon, 15 Feb 2016 16:27:58 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:28:02 -0000 On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>=20 >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>=20 >>>> Mark, I believe you're right. What do you think about this patch? >>>>=20 >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>> @@ -3599,6 +3599,8 @@ >>>> { >>>> CGF.EmitBlock(UsingOverflow); >>>>=20 >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>> + >>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>=20 >>>>=20 >>>> Can you test it? >>>=20 >>> It may be later today before I can start the the test process. >>>=20 >>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>=20 >>> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>=20 >>> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>>=20 >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> Can you check what number gcc uses? We want to be interoperable with = gcc. >>=20 >> Anyway, thanks for testing! >>=20 >> Roman >=20 > I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >=20 > But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >=20 >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >=20 >=20 > for some "?" would need to be involved in the changes in order to = reach compatibility. >=20 >=20 > I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >=20 >> cmplwi r?,7 >=20 >=20 > for some r?, such as r5 or r4, and the conditional branch generated is = a bgt instruction. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net gcc 4.2.1 generates comparison instructions for va_arg of the form: cmplwi cr7,r0,8 and the conditional branch generated is a "bge cr7, . . ." instruction. So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. Other aspects of the code generation distinctions would take me time to = analyze. It will be a while before I will be looking at other points. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Feb 16 10:45:35 2016 Return-Path: Delivered-To: freebsd-toolchain@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 1B177AA93EA for ; Tue, 16 Feb 2016 10:45:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2FD31271 for ; Tue, 16 Feb 2016 10:45:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31892 invoked from network); 16 Feb 2016 10:45:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 10:45:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 16 Feb 2016 05:45:36 -0500 (EST) Received: (qmail 12467 invoked from network); 16 Feb 2016 10:45:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 10:45:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A12DD1C43D2; Tue, 16 Feb 2016 02:45:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: Date: Tue, 16 Feb 2016 02:45:31 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:45:35 -0000 I used: > Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (revision 295601) > +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (working copy) > @@ -3569,6 +3569,8 @@ > { > CGF.EmitBlock(UsingOverflow); > =20 > + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > + > // Everything in the overflow area is rounded up to a size of at = least 4. > CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); as my test change. (Get evidence of operation before potential cleanup = of the duplicated 8's.) After a full buildworld/installworld based on the updated compiler. . . My simple example of the problem no longer fails. "ls -l -n /" now works. "svnlite update -r295601 /usr/src" now works. So whatever you want to do for the details of any submitted code, the = basics of the change do avoid the SEGVs and allow these programs to = work. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>=20 >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>=20 >>>> Mark, I believe you're right. What do you think about this patch? >>>>=20 >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>> @@ -3599,6 +3599,8 @@ >>>> { >>>> CGF.EmitBlock(UsingOverflow); >>>>=20 >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>> + >>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>=20 >>>>=20 >>>> Can you test it? >>>=20 >>> It may be later today before I can start the the test process. >>>=20 >>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>=20 >>> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>=20 >>> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>>=20 >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> Can you check what number gcc uses? We want to be interoperable with = gcc. >>=20 >> Anyway, thanks for testing! >>=20 >> Roman >=20 > I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >=20 > But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >=20 >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >=20 >=20 > for some "?" would need to be involved in the changes in order to = reach compatibility. >=20 >=20 > I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >=20 >> cmplwi r?,7 >=20 >=20 > for some r?, such as r5 or r4, and the conditional branch generated is = a bgt instruction. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net gcc 4.2.1 generates comparison instructions for va_arg of the form: cmplwi cr7,r0,8 and the conditional branch generated is a "bge cr7, . . ." instruction. So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. Other aspects of the code generation distinctions would take me time to = analyze. It will be a while before I will be looking at other points. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Feb 16 13:51:54 2016 Return-Path: Delivered-To: freebsd-toolchain@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 740AAAAA632 for ; Tue, 16 Feb 2016 13:51:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 363AF15A9 for ; Tue, 16 Feb 2016 13:51:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1842 invoked from network); 16 Feb 2016 13:52:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 13:52:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 16 Feb 2016 08:52:02 -0500 (EST) Received: (qmail 26053 invoked from network); 16 Feb 2016 13:52:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 16 Feb 2016 13:52:02 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 04D3E1C43C4; Tue, 16 Feb 2016 05:51:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> Date: Tue, 16 Feb 2016 05:51:51 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 13:51:54 -0000 By the way: Nothing tested or seen so far checks DOUBLE_OR_FLOAT = handling. That involves fr (fpr in va_list in clang terms) instead of gr/gpr. = fr/fpr has its own independent count and bound for using floating point = registers vs. using the overflow area. There is also condition register = bit 6 that indicates if floating point is involved overall or not. Ultimately which of gpr vs. fpr and which bound (if the numbers are = distinct in value) depends on the type specified in va_arg = (SIMPLE_ARG/LONG_LONG vs. DOUBLE_OR_FLOAT status). This may mean that the fix is an improvement for some types of usage but = not a complete update: It is wrong for DOUBLE_OR_FLOAT instances of = var_arg as stands. fpr would need to be involved instead. For world I = expect it is fairly generally an improvement. Also if the condition register indicates floating point is involved = overall then there is likely management/handling of floating point state = (for context switching management). (If it indicates no floating point = involvement then there might be optimizations possible.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-16, at 2:45 AM, Mark Millard wrote: I used: > Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (revision 295601) > +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (working copy) > @@ -3569,6 +3569,8 @@ > { > CGF.EmitBlock(UsingOverflow); >=20 > + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > + > // Everything in the overflow area is rounded up to a size of at = least 4. > CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); as my test change. (Get evidence of operation before potential cleanup = of the duplicated 8's.) After a full buildworld/installworld based on the updated compiler. . . My simple example of the problem no longer fails. "ls -l -n /" now works. "svnlite update -r295601 /usr/src" now works. So whatever you want to do for the details of any submitted code, the = basics of the change do avoid the SEGVs and allow these programs to = work. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>=20 >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>=20 >>>> Mark, I believe you're right. What do you think about this patch? >>>>=20 >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>> @@ -3599,6 +3599,8 @@ >>>> { >>>> CGF.EmitBlock(UsingOverflow); >>>>=20 >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>> + >>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>=20 >>>>=20 >>>> Can you test it? >>>=20 >>> It may be later today before I can start the the test process. >>>=20 >>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>=20 >>> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>=20 >>> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>>=20 >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> Can you check what number gcc uses? We want to be interoperable with = gcc. >>=20 >> Anyway, thanks for testing! >>=20 >> Roman >=20 > I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >=20 > But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >=20 >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >=20 >=20 > for some "?" would need to be involved in the changes in order to = reach compatibility. >=20 >=20 > I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >=20 >> cmplwi r?,7 >=20 >=20 > for some r?, such as r5 or r4, and the conditional branch generated is = a bgt instruction. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net gcc 4.2.1 generates comparison instructions for va_arg of the form: cmplwi cr7,r0,8 and the conditional branch generated is a "bge cr7, . . ." instruction. So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. Other aspects of the code generation distinctions would take me time to = analyze. It will be a while before I will be looking at other points. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Feb 18 05:23:51 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C79F3AAB2A6 for ; Thu, 18 Feb 2016 05:23:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 868DD1FC6 for ; Thu, 18 Feb 2016 05:23:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20848 invoked from network); 18 Feb 2016 05:23:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 18 Feb 2016 05:23:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Thu, 18 Feb 2016 00:23:47 -0500 (EST) Received: (qmail 21744 invoked from network); 18 Feb 2016 05:23:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 18 Feb 2016 05:23:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7A05A1C43A8; Wed, 17 Feb 2016 21:23:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> Date: Wed, 17 Feb 2016 21:23:43 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 05:23:52 -0000 My fpr related notes/worries about the fix were wrong. I finally got some time to look at this again and I see that I somehow = missed the following code when I looked before: // The calling convention either uses 1-2 GPRs or 1 FPR. Address NumRegsAddr =3D Address::invalid(); if (isInt || IsSoftFloatABI) { NumRegsAddr =3D Builder.CreateStructGEP(VAList, 0, = CharUnits::Zero(), "gpr"); } else { NumRegsAddr =3D Builder.CreateStructGEP(VAList, 1, CharUnits::One(), = "fpr"); } So the Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); in Case 2 is tracking gpr vs. fpr usage contexts as it should. Also: llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); =20 // "Align" the register count when TY is i64. if (isI64 || (isF64 && IsSoftFloatABI)) { NumRegs =3D Builder.CreateAdd(NumRegs, Builder.getInt8(1)); NumRegs =3D Builder.CreateAnd(NumRegs, Builder.getInt8((uint8_t) = ~1U)); } =20 llvm::Value *CC =3D Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); is using the same bounds check figure (8) for gpr and fpr. Apparently that common bound is one reason that the clang numbering is = not the same as the ABI document's numbering: clang's numbering allows = using the same figure for both contexts. (Given the prior alignment for = isI64 (or isF64 with IsSoftFloatABI).) Sorry for the prior noise about fpr. It is still true that DOUBLE_OR_FLOAT is untested so far. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-16, at 5:51 AM, Mark Millard wrote: By the way: Nothing tested or seen so far checks DOUBLE_OR_FLOAT = handling. That involves fr (fpr in va_list in clang terms) instead of gr/gpr. = fr/fpr has its own independent count and bound for using floating point = registers vs. using the overflow area. There is also condition register = bit 6 that indicates if floating point is involved overall or not. Ultimately which of gpr vs. fpr and which bound (if the numbers are = distinct in value) depends on the type specified in va_arg = (SIMPLE_ARG/LONG_LONG vs. DOUBLE_OR_FLOAT status). This may mean that the fix is an improvement for some types of usage but = not a complete update: It is wrong for DOUBLE_OR_FLOAT instances of = var_arg as stands. fpr would need to be involved instead. For world I = expect it is fairly generally an improvement. Also if the condition register indicates floating point is involved = overall then there is likely management/handling of floating point state = (for context switching management). (If it indicates no floating point = involvement then there might be optimizations possible.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-16, at 2:45 AM, Mark Millard wrote: I used: > Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (revision 295601) > +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (working copy) > @@ -3569,6 +3569,8 @@ > { > CGF.EmitBlock(UsingOverflow); >=20 > + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > + > // Everything in the overflow area is rounded up to a size of at = least 4. > CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); as my test change. (Get evidence of operation before potential cleanup = of the duplicated 8's.) After a full buildworld/installworld based on the updated compiler. . . My simple example of the problem no longer fails. "ls -l -n /" now works. "svnlite update -r295601 /usr/src" now works. So whatever you want to do for the details of any submitted code, the = basics of the change do avoid the SEGVs and allow these programs to = work. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>=20 >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>=20 >>>> Mark, I believe you're right. What do you think about this patch? >>>>=20 >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>> @@ -3599,6 +3599,8 @@ >>>> { >>>> CGF.EmitBlock(UsingOverflow); >>>>=20 >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>> + >>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>=20 >>>>=20 >>>> Can you test it? >>>=20 >>> It may be later today before I can start the the test process. >>>=20 >>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>=20 >>> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>=20 >>> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>>=20 >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> Can you check what number gcc uses? We want to be interoperable with = gcc. >>=20 >> Anyway, thanks for testing! >>=20 >> Roman >=20 > I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >=20 > But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >=20 >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >=20 >=20 > for some "?" would need to be involved in the changes in order to = reach compatibility. >=20 >=20 > I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >=20 >> cmplwi r?,7 >=20 >=20 > for some r?, such as r5 or r4, and the conditional branch generated is = a bgt instruction. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net gcc 4.2.1 generates comparison instructions for va_arg of the form: cmplwi cr7,r0,8 and the conditional branch generated is a "bge cr7, . . ." instruction. So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. Other aspects of the code generation distinctions would take me time to = analyze. It will be a while before I will be looking at other points. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Feb 18 22:29:38 2016 Return-Path: Delivered-To: freebsd-toolchain@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 343E4AADD91 for ; Thu, 18 Feb 2016 22:29:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAE4CA76 for ; Thu, 18 Feb 2016 22:29:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5885 invoked from network); 18 Feb 2016 22:29:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Feb 2016 22:29:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Thu, 18 Feb 2016 17:29:25 -0500 (EST) Received: (qmail 7085 invoked from network); 18 Feb 2016 22:29:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 18 Feb 2016 22:29:24 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 34AF6B1E002; Thu, 18 Feb 2016 14:29:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] From: Mark Millard In-Reply-To: <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> Date: Thu, 18 Feb 2016 14:29:29 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 22:29:38 -0000 On 2016-Feb-17, at 9:23 PM, Mark Millard wrote: >=20 > My fpr related notes/worries about the fix were wrong. >=20 > I finally got some time to look at this again and I see that I somehow = missed the following code when I looked before: >=20 > // The calling convention either uses 1-2 GPRs or 1 FPR. > Address NumRegsAddr =3D Address::invalid(); > if (isInt || IsSoftFloatABI) { > NumRegsAddr =3D Builder.CreateStructGEP(VAList, 0, = CharUnits::Zero(), "gpr"); > } else { > NumRegsAddr =3D Builder.CreateStructGEP(VAList, 1, = CharUnits::One(), "fpr"); > } >=20 > So the >=20 > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >=20 > in Case 2 is tracking gpr vs. fpr usage contexts as it should. Also: >=20 > llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); >=20 > // "Align" the register count when TY is i64. > if (isI64 || (isF64 && IsSoftFloatABI)) { > NumRegs =3D Builder.CreateAdd(NumRegs, Builder.getInt8(1)); > NumRegs =3D Builder.CreateAnd(NumRegs, Builder.getInt8((uint8_t) = ~1U)); > } >=20 > llvm::Value *CC =3D > Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >=20 > is using the same bounds check figure (8) for gpr and fpr. >=20 > Apparently that common bound is one reason that the clang numbering is = not the same as the ABI document's numbering: clang's numbering allows = using the same figure for both contexts. (Given the prior alignment for = isI64 (or isF64 with IsSoftFloatABI).) >=20 > Sorry for the prior noise about fpr. >=20 > It is still true that DOUBLE_OR_FLOAT is untested so far. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I finally got some time to apply to some basic testing involving double = as well (for involving fpr use). . . No problems with exceptions. Looking at the memory contents at various = stages in gdb looks good. va_list's gpr, fpr, overflow_arg_area changes = as its va_args use progresses look good. Values extracted by va_args use = looks good. Both default and -O2. The added > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); passes my checks. I've not observed any problems from buildworld = materials, unlike when that line is missing. [Note: I run with the signal delivery modified to have a "red zone" to = deal with other aspects of clang 3.8.0 code generation that are not ABI = compliant for when the stack pointer is moved. Having a "red zone" is = still operationally correct for an ABI compliant code generation, it = just temporarily wastes more bytes. Also: the kernel was built with gcc = 4.2.1 but world was built with clang 3.8.0.] =3D=3D=3D Mark Millard markmi at dsl-only.net . . . [bad fpr related material omitted] . . . On 2016-Feb-16, at 2:45 AM, Mark Millard wrote: I used: > Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (revision 295601) > +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (working copy) > @@ -3569,6 +3569,8 @@ > { > CGF.EmitBlock(UsingOverflow); >=20 > + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > + > // Everything in the overflow area is rounded up to a size of at = least 4. > CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); as my test change. (Get evidence of operation before potential cleanup = of the duplicated 8's.) After a full buildworld/installworld based on the updated compiler. . . My simple example of the problem no longer fails. "ls -l -n /" now works. "svnlite update -r295601 /usr/src" now works. So whatever you want to do for the details of any submitted code, the = basics of the change do avoid the SEGVs and allow these programs to = work. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>=20 >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>=20 >>>> Mark, I believe you're right. What do you think about this patch? >>>>=20 >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>> @@ -3599,6 +3599,8 @@ >>>> { >>>> CGF.EmitBlock(UsingOverflow); >>>>=20 >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>> + >>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>=20 >>>>=20 >>>> Can you test it? >>>=20 >>> It may be later today before I can start the the test process. >>>=20 >>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>=20 >>> The clang code generation that I saw while analyzing the problem and = the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>=20 >>> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>>=20 >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> Can you check what number gcc uses? We want to be interoperable with = gcc. >>=20 >> Anyway, thanks for testing! >>=20 >> Roman >=20 > I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >=20 > But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >=20 >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >=20 >=20 > for some "?" would need to be involved in the changes in order to = reach compatibility. >=20 >=20 > I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >=20 >> cmplwi r?,7 >=20 >=20 > for some r?, such as r5 or r4, and the conditional branch generated is = a bgt instruction. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net gcc 4.2.1 generates comparison instructions for va_arg of the form: cmplwi cr7,r0,8 and the conditional branch generated is a "bge cr7, . . ." instruction. So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. Other aspects of the code generation distinctions would take me time to = analyze. It will be a while before I will be looking at other points. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Feb 19 19:37:10 2016 Return-Path: Delivered-To: freebsd-toolchain@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 6B769AAEC7B for ; Fri, 19 Feb 2016 19:37:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21D0D160C for ; Fri, 19 Feb 2016 19:37:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4284 invoked from network); 19 Feb 2016 19:37:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Feb 2016 19:37:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 19 Feb 2016 14:36:56 -0500 (EST) Received: (qmail 10175 invoked from network); 19 Feb 2016 19:36:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 19 Feb 2016 19:36:56 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 827AFB1E001; Fri, 19 Feb 2016 11:36:58 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I've' submitted 207325 and 207359 for powerpc/powrpc64 c++ exception problems for projects/clang380-import -r295601 (9 line program) Message-Id: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> Date: Fri, 19 Feb 2016 11:37:01 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 19:37:10 -0000 The following program does not work for my example TARGET_ARCH=3Dpowerpc = and TARGET_ARCH=3Dpowerpc64 environments for buildworld based on = projects/clang380-import -r205601: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} // same result without & return 0; } The details vary for what happens and what compiler is in use. TARGET_ARCH=3Dpowerpc with clang 3.8.0: SEGV TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-gcc: unbouded loop in = _Unwind_RaiseException For the powerpc64 context: g++49 can be used to show the problem as = well: Using g++49's a.out gets the same unbounded loop result for: # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp = =20 But the a.out works fine for a normal g++49 header/library usage: # g++49 -g -Wall -pedantic exception_test.cpp # ./a.out #=20 (These were noticed by trying to build and use kyua to run the = /usr/tests material in tehse enviroments.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Feb 20 01:15:40 2016 Return-Path: Delivered-To: freebsd-toolchain@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 627D9AAD89A for ; Sat, 20 Feb 2016 01:15:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 493FF88E for ; Sat, 20 Feb 2016 01:15:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u1K0voU7084424 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Feb 2016 16:57:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u1K0voKN084423 for freebsd-toolchain@freebsd.org; Fri, 19 Feb 2016 16:57:50 -0800 (PST) (envelope-from sgk) Date: Fri, 19 Feb 2016 16:57:50 -0800 From: Steve Kargl To: freebsd-toolchain@freebsd.org Subject: confusing messages from clang Message-ID: <20160220005749.GA84382@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 01:15:40 -0000 If anyone is interesting fixing FreeBSD's C compiler, it would be appreciated. % cat foo.c #include #include void foo(int i) { if (i < 0) goto whoops; if (i == 0) printf("foo\n"); if (i > 0) goto corrupt; return; whoops: printf("whoops\n"); return corrupt: printf("corrupt\n"); } % cc -c foo.c foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you mean 'crypt'? corrupt: ^~~~~~~ crypt /usr/include/unistd.h:450:7: note: 'crypt' declared here char *crypt(const char *, const char *); ^ foo.c:21:8: error: expected ';' after return statement corrupt: ^ ; foo.c:14:12: error: use of undeclared label 'corrupt' goto corrupt; ^ 3 errors generated. No, I did not mean crypt. 'corrupt' is a defined label. The missing semicolon occurs in line 19, but the line is not properly identified in error output. -- Steve From owner-freebsd-toolchain@freebsd.org Sat Feb 20 07:33:21 2016 Return-Path: Delivered-To: freebsd-toolchain@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 4EE61AAE228 for ; Sat, 20 Feb 2016 07:33:21 +0000 (UTC) (envelope-from 1101.debian@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8FE815EA for ; Sat, 20 Feb 2016 07:33:20 +0000 (UTC) (envelope-from 1101.debian@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id c200so105047911wme.0 for ; Fri, 19 Feb 2016 23:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=QikA6YAvpc7aZhLLXTlaqb8aUWOKYnzlIFQBqeoJGII=; b=nqZ+Q0h6jLtimx8sMhs1Qh4yZNzGKuI50dC2bbrsXk39NZ2fPk1VJ97eTjK0+/pnVv URlBfo53plZuQqHrYgzYfQZT44wYviKQ8WsRn8zBu6DYM2uBXdQe2mmgAySigMDUfXJ1 qCBQO/+Wv42GYjpTmwypAg+6ygpuVIA8GhKeVmtelgXhHleDTIHwEiBmrXZJPuMYoag1 Dl8vZ/AQktS3M2Z5/im/it+nnWkRE1BrUruP9KiZh5NbctwN9UY/oI1tqpHAsXtgYGbO 5ZmwAKfjPIumrnTGaibPf8hgwOfBQ7nlBh0npiYDeN5XH7GO2GE3xiatyMaRQqzw2qPp VM5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=QikA6YAvpc7aZhLLXTlaqb8aUWOKYnzlIFQBqeoJGII=; b=nHoXeYGb9/tXwgCiEvip3QuGqUarZ7yI5Ry27B3t41Jr0bnvMy6Ri85FEYyoeDVm3R KtTZcnZ2PiqlZrX8eZeSVyx3R6LhmtDRL7Df4Z5/kR31O473IbpxNcp6g3x68pWIiS4i jTvN/jhtQ4+ydWbVYV/msMCu2MxA9s25O46Sbx1746OfoHz9PrdDQdf/hSWFnvZ2RoMs GHfb3ly5FEl4MK4zyj6UaTS6vNJtoeh+ku7yCajbei6durflza94b2LJSEw7s7jS4xQq DK39VpBSlFFR+yiEQ1QhvHQrFaOh5OeZKoLfSXhyNRKWEXvWgmqFFCuY44SgqKFmjCzg dujA== X-Gm-Message-State: AG10YOQab+sSR2LGnFqiBBLAAXohdBUZaytpLjQqSf/UzcomWbK6e/cCMM1o5I0HX1InNQ== X-Received: by 10.28.211.130 with SMTP id k124mr1304310wmg.7.1455953599412; Fri, 19 Feb 2016 23:33:19 -0800 (PST) Received: from ?IPv6:2a02:8109:8380:1dc4:5566:2066:87c0:d3ba? ([2a02:8109:8380:1dc4:5566:2066:87c0:d3ba]) by smtp.gmail.com with ESMTPSA id p125sm10888704wmd.16.2016.02.19.23.33.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Feb 2016 23:33:18 -0800 (PST) Subject: Re: confusing messages from clang Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A0F02BAB-2151-4DAD-8F6E-9CAD82040A7C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Alex Denisov <1101.debian@gmail.com> In-Reply-To: <20160220005749.GA84382@troutmask.apl.washington.edu> Date: Sat, 20 Feb 2016 08:33:16 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: References: <20160220005749.GA84382@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 07:33:21 -0000 --Apple-Mail=_A0F02BAB-2151-4DAD-8F6E-9CAD82040A7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Steve, I=E2=80=99ve submitted the bug to LLVM=E2=80=99s bugzilla: = https://llvm.org/bugs/show_bug.cgi?id=3D26678 Also, it looks like OS agnostic. At least I see the same behaviour on = OSX as well. -- AlexDenisov Software Engineer, http://lowlevelbits.org > On 20 Feb 2016, at 01:57, Steve Kargl = wrote: >=20 > If anyone is interesting fixing FreeBSD's C compiler, it > would be appreciated. >=20 > % cat foo.c > #include > #include >=20 > void > foo(int i) > { > if (i < 0) > goto whoops; >=20 > if (i =3D=3D 0) > printf("foo\n"); >=20 > if (i > 0) > goto corrupt; > return; >=20 > whoops: > printf("whoops\n"); > return >=20 > corrupt: > printf("corrupt\n"); > } >=20 > % cc -c foo.c > foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you = mean 'crypt'? > corrupt: > ^~~~~~~ > crypt > /usr/include/unistd.h:450:7: note: 'crypt' declared here > char *crypt(const char *, const char *); > ^ > foo.c:21:8: error: expected ';' after return statement > corrupt: > ^ > ; > foo.c:14:12: error: use of undeclared label 'corrupt' > goto corrupt; > ^ > 3 errors generated. >=20 >=20 > No, I did not mean crypt. 'corrupt' is a defined label. > The missing semicolon occurs in line 19, but the line is > not properly identified in error output. >=20 > -- > Steve > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" --Apple-Mail=_A0F02BAB-2151-4DAD-8F6E-9CAD82040A7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWyBa9AAoJEKnZX2FYSnX6yTUIALuJHlpIRBn5vIAnP4dWI0Nz UqrMDW5n9ahmC6NGtyI6398B4T/xmHjiU6IZnVLixHn9OT5VKgp4uM0SmOYyzV8X ay0Ohh1+53IvBJQ7jQowxHvXvyNH8UVtITObIRu2fi2FwjpzlpSFE/DGuTMmq5yO TE+VQd/BPyOtPw85jq4ydx2lzkH8frw4yg0Egta7hZ9SbfHcGY4VgliI2Q8c2jfI nj77DyOqZymF3w9Wzdz/VCVLPgB1qj8cqgxQSZxwO1n7ajx0tVeZ7J+jzGqEwwOU cs1wr4f4rquBnvO7yMASfRhaER45QByYHhfyiCd6jvtYRriNeK2B+e+tIUODE0c= =voh+ -----END PGP SIGNATURE----- --Apple-Mail=_A0F02BAB-2151-4DAD-8F6E-9CAD82040A7C-- From owner-freebsd-toolchain@freebsd.org Sat Feb 20 08:37:15 2016 Return-Path: Delivered-To: freebsd-toolchain@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 2791FAAFA0C; Sat, 20 Feb 2016 08:37:15 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id C8C501239; Sat, 20 Feb 2016 08:37:14 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 7F43D1E22A88; Sat, 20 Feb 2016 09:34:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1455957290; bh=QeAgPO+laCwfHsBItkk1oUsDqVnOsBvhqYSTSemvQIs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=AsopzhD23XVbeR2mzblbmOQzpUBzJoALjl4OlQfsV7mab5hJCmlno/HfgZQiSXB6W HQSWHzmcstggIDpn2ypLo5EB0adDX/kikO00SkE+y0uXSWyTESERukVNMS+rWUVje8 mbw9kK+vM3WV/cIBhG1BUg15e1N798C2nZNqI3tQ= Date: Sat, 20 Feb 2016 09:34:50 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] Message-ID: <20160220083450.GA55777@vlakno.cz> References: <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 08:37:15 -0000 Fwiw, I've just committed the patch to clang in r261422. You might want to keep using a local modification or ask dim@ to import that patch to our copy of 3.8. Thanks for your diagnosis and testing! Roman On Thu, Feb 18, 2016 at 02:29:29PM -0800, Mark Millard wrote: > On 2016-Feb-17, at 9:23 PM, Mark Millard wrote: > > > > My fpr related notes/worries about the fix were wrong. > > > > I finally got some time to look at this again and I see that I somehow missed the following code when I looked before: > > > > // The calling convention either uses 1-2 GPRs or 1 FPR. > > Address NumRegsAddr = Address::invalid(); > > if (isInt || IsSoftFloatABI) { > > NumRegsAddr = Builder.CreateStructGEP(VAList, 0, CharUnits::Zero(), "gpr"); > > } else { > > NumRegsAddr = Builder.CreateStructGEP(VAList, 1, CharUnits::One(), "fpr"); > > } > > > > So the > > > > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > > > > in Case 2 is tracking gpr vs. fpr usage contexts as it should. Also: > > > > llvm::Value *NumRegs = Builder.CreateLoad(NumRegsAddr, "numUsedRegs"); > > > > // "Align" the register count when TY is i64. > > if (isI64 || (isF64 && IsSoftFloatABI)) { > > NumRegs = Builder.CreateAdd(NumRegs, Builder.getInt8(1)); > > NumRegs = Builder.CreateAnd(NumRegs, Builder.getInt8((uint8_t) ~1U)); > > } > > > > llvm::Value *CC = > > Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); > > > > is using the same bounds check figure (8) for gpr and fpr. > > > > Apparently that common bound is one reason that the clang numbering is not the same as the ABI document's numbering: clang's numbering allows using the same figure for both contexts. (Given the prior alignment for isI64 (or isF64 with IsSoftFloatABI).) > > > > Sorry for the prior noise about fpr. > > > > It is still true that DOUBLE_OR_FLOAT is untested so far. > > > > === > > Mark Millard > > markmi at dsl-only.net > > I finally got some time to apply to some basic testing involving double as well (for involving fpr use). . . > > No problems with exceptions. Looking at the memory contents at various stages in gdb looks good. va_list's gpr, fpr, overflow_arg_area changes as its va_args use progresses look good. Values extracted by va_args use looks good. Both default and -O2. > > The added > > > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > > > passes my checks. I've not observed any problems from buildworld materials, unlike when that line is missing. > > [Note: I run with the signal delivery modified to have a "red zone" to deal with other aspects of clang 3.8.0 code generation that are not ABI compliant for when the stack pointer is moved. Having a "red zone" is still operationally correct for an ABI compliant code generation, it just temporarily wastes more bytes. Also: the kernel was built with gcc 4.2.1 but world was built with clang 3.8.0.] > > > === > Mark Millard > markmi at dsl-only.net > > . . . [bad fpr related material omitted] . . . > > On 2016-Feb-16, at 2:45 AM, Mark Millard wrote: > > I used: > > > Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp > > =================================================================== > > --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp (revision 295601) > > +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) > > @@ -3569,6 +3569,8 @@ > > { > > CGF.EmitBlock(UsingOverflow); > > > > + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > > + > > // Everything in the overflow area is rounded up to a size of at least 4. > > CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4); > > as my test change. (Get evidence of operation before potential cleanup of the duplicated 8's.) > > After a full buildworld/installworld based on the updated compiler. . . > > My simple example of the problem no longer fails. > > "ls -l -n /" now works. > > "svnlite update -r295601 /usr/src" now works. > > So whatever you want to do for the details of any submitted code, the basics of the change do avoid the SEGVs and allow these programs to work. > > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: > > On 2016-Feb-15, at 1:20 PM, Mark Millard wrote: > > > > On 2016-Feb-15, at 12:18 PM, Roman Divacky wrote: > >> > >> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: > >>> On 2016-Feb-15, at 11:11 AM, Roman Divacky wrote: > >>>> > >>>> Mark, I believe you're right. What do you think about this patch? > >>>> > >>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp > >>>> =================================================================== > >>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) > >>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) > >>>> @@ -3599,6 +3599,8 @@ > >>>> { > >>>> CGF.EmitBlock(UsingOverflow); > >>>> > >>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); > >>>> + > >>>> // Everything in the overflow area is rounded up to a size of at least 4. > >>>> CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4); > >>>> > >>>> > >>>> Can you test it? > >>> > >>> It may be later today before I can start the the test process. > >>> > >>> While your change is not wrong as presented, it does seem to be based on the ABI document's numbering with the range 3 <= gr <12, where 3 <= gr < 11 cover r3-r10 use and gr=11 implies overflow stack area use. (gr being the ABI documents name.) > >>> > >>> The clang code generation that I saw while analyzing the problem and the clang source that you had me look at did not use that numbering. Instead it seems to be based on 0 <= gpr < 9, where 0 <= gpr < 8 cover r3-r10 use and gpr=8 implies overflow stack area use. (gpr being what gdb showed me as I remember.) In other words: clang counts the number of "parameter registers" already in use as it goes along instead of tracking register numbers that have been used. > >>> > >>> So assigning any value that appears to be positive and >= 8 should work, such as: > >>> > >>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); > >> > >> Can you check what number gcc uses? We want to be interoperable with gcc. > >> > >> Anyway, thanks for testing! > >> > >> Roman > > > > I'll do that check of gcc 4.2.1 code generation before starting the test later today. > > > > But if the clang numbering is different in gcc 4.2.1 then far more than just adding a > > > >> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) > > > > > > for some "?" would need to be involved in the changes in order to reach compatibility. > > > > > > I'll note that for clang 3.8.0 the actual comparison instruction generated is of the form > > > >> cmplwi r?,7 > > > > > > for some r?, such as r5 or r4, and the conditional branch generated is a bgt instruction. > > > > === > > Mark Millard > > markmi at dsl-only.net > > gcc 4.2.1 generates comparison instructions for va_arg of the form: > > cmplwi cr7,r0,8 > > and the conditional branch generated is a "bge cr7, . . ." instruction. > > So the same number range is in use by both compilers: They are compatible for the bounds checks for reg vs. overflow for how they count, equality inclusion/exclusion matching up with the specific number (8 vs. 7) used to make things the same overall. > > Other aspects of the code generation distinctions would take me time to analyze. It will be a while before I will be looking at other points. > > > === > Mark Millard > markmi at dsl-only.net > > > > > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Feb 20 09:03:00 2016 Return-Path: Delivered-To: freebsd-toolchain@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 2CBC5AAE4A5 for ; Sat, 20 Feb 2016 09:03:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E439F1BBD for ; Sat, 20 Feb 2016 09:02:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28353 invoked from network); 20 Feb 2016 09:03:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Feb 2016 09:03:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 20 Feb 2016 04:03:01 -0500 (EST) Received: (qmail 27690 invoked from network); 20 Feb 2016 09:03:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 20 Feb 2016 09:03:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E153E1C405F; Sat, 20 Feb 2016 01:02:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] From: Mark Millard In-Reply-To: <20160220083450.GA55777@vlakno.cz> Date: Sat, 20 Feb 2016 01:02:56 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <601B33C1-D258-4F23-9814-1B4291C57A5F@dsl-only.net> References: <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> <20160220083450.GA55777@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 09:03:00 -0000 Thanks! llvm bugzilla's 26605 did not having anything yet for this so I've = copied over your note. But I've left the status alone. The next thing that I ran into looks nastier: c++'s exception handling = is broken. #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} // same result without & return 0; } does not work on powerpc (SEGV) or powerpc64 (unbounded loop, never = returning from _Unwind_RaiseException). (The powerpc64 context is using = devel/powerpc64-gcc or g++49 as the compiler with the system's headers = and libraries. powerpc64-gcc was used for buildworld/buildkernel as well = for this context.) [g++49 using its own headers and libraries works fine for the above = program.] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-20, at 12:34 AM, Roman Divacky wrote: Fwiw, I've just committed the patch to clang in r261422. You might want to keep using a local modification or ask dim@ to import that patch to our copy of 3.8. Thanks for your diagnosis and testing! Roman On Thu, Feb 18, 2016 at 02:29:29PM -0800, Mark Millard wrote: > On 2016-Feb-17, at 9:23 PM, Mark Millard wrote: >>=20 >> My fpr related notes/worries about the fix were wrong. >>=20 >> I finally got some time to look at this again and I see that I = somehow missed the following code when I looked before: >>=20 >> // The calling convention either uses 1-2 GPRs or 1 FPR. >> Address NumRegsAddr =3D Address::invalid(); >> if (isInt || IsSoftFloatABI) { >> NumRegsAddr =3D Builder.CreateStructGEP(VAList, 0, = CharUnits::Zero(), "gpr"); >> } else { >> NumRegsAddr =3D Builder.CreateStructGEP(VAList, 1, = CharUnits::One(), "fpr"); >> } >>=20 >> So the >>=20 >> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>=20 >> in Case 2 is tracking gpr vs. fpr usage contexts as it should. Also: >>=20 >> llvm::Value *NumRegs =3D Builder.CreateLoad(NumRegsAddr, = "numUsedRegs"); >>=20 >> // "Align" the register count when TY is i64. >> if (isI64 || (isF64 && IsSoftFloatABI)) { >> NumRegs =3D Builder.CreateAdd(NumRegs, Builder.getInt8(1)); >> NumRegs =3D Builder.CreateAnd(NumRegs, Builder.getInt8((uint8_t) = ~1U)); >> } >>=20 >> llvm::Value *CC =3D >> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond"); >>=20 >> is using the same bounds check figure (8) for gpr and fpr. >>=20 >> Apparently that common bound is one reason that the clang numbering = is not the same as the ABI document's numbering: clang's numbering = allows using the same figure for both contexts. (Given the prior = alignment for isI64 (or isF64 with IsSoftFloatABI).) >>=20 >> Sorry for the prior noise about fpr. >>=20 >> It is still true that DOUBLE_OR_FLOAT is untested so far. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I finally got some time to apply to some basic testing involving = double as well (for involving fpr use). . . >=20 > No problems with exceptions. Looking at the memory contents at various = stages in gdb looks good. va_list's gpr, fpr, overflow_arg_area changes = as its va_args use progresses look good. Values extracted by va_args use = looks good. Both default and -O2. >=20 > The added >=20 >> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >=20 >=20 > passes my checks. I've not observed any problems from buildworld = materials, unlike when that line is missing. >=20 > [Note: I run with the signal delivery modified to have a "red zone" to = deal with other aspects of clang 3.8.0 code generation that are not ABI = compliant for when the stack pointer is moved. Having a "red zone" is = still operationally correct for an ABI compliant code generation, it = just temporarily wastes more bytes. Also: the kernel was built with gcc = 4.2.1 but world was built with clang 3.8.0.] >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > . . . [bad fpr related material omitted] . . . >=20 > On 2016-Feb-16, at 2:45 AM, Mark Millard wrote: >=20 > I used: >=20 >> Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (revision 295601) >> +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp = (working copy) >> @@ -3569,6 +3569,8 @@ >> { >> CGF.EmitBlock(UsingOverflow); >>=20 >> + Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >> + >> // Everything in the overflow area is rounded up to a size of at = least 4. >> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >=20 > as my test change. (Get evidence of operation before potential cleanup = of the duplicated 8's.) >=20 > After a full buildworld/installworld based on the updated compiler. . = . >=20 > My simple example of the problem no longer fails. >=20 > "ls -l -n /" now works. >=20 > "svnlite update -r295601 /usr/src" now works. >=20 > So whatever you want to do for the details of any submitted code, the = basics of the change do avoid the SEGVs and allow these programs to = work. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Feb-15, at 4:27 PM, Mark Millard wrote: >=20 > On 2016-Feb-15, at 1:20 PM, Mark Millard = wrote: >>=20 >> On 2016-Feb-15, at 12:18 PM, Roman Divacky = wrote: >>>=20 >>> On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >>>> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>>>=20 >>>>> Mark, I believe you're right. What do you think about this patch? >>>>>=20 >>>>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision = 260852) >>>>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>>>> @@ -3599,6 +3599,8 @@ >>>>> { >>>>> CGF.EmitBlock(UsingOverflow); >>>>>=20 >>>>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>>>> + >>>>> // Everything in the overflow area is rounded up to a size of at = least 4. >>>>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>>>=20 >>>>>=20 >>>>> Can you test it? >>>>=20 >>>> It may be later today before I can start the the test process. >>>>=20 >>>> While your change is not wrong as presented, it does seem to be = based on the ABI document's numbering with the range 3 <=3D gr <12, = where 3 <=3D gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack = area use. (gr being the ABI documents name.) >>>>=20 >>>> The clang code generation that I saw while analyzing the problem = and the clang source that you had me look at did not use that numbering. = Instead it seems to be based on 0 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 implies overflow stack area use. (gpr being = what gdb showed me as I remember.) In other words: clang counts the = number of "parameter registers" already in use as it goes along instead = of tracking register numbers that have been used. >>>>=20 >>>> So assigning any value that appears to be positive and >=3D 8 = should work, such as: >>>>=20 >>>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >>>=20 >>> Can you check what number gcc uses? We want to be interoperable with = gcc. >>>=20 >>> Anyway, thanks for testing! >>>=20 >>> Roman >>=20 >> I'll do that check of gcc 4.2.1 code generation before starting the = test later today. >>=20 >> But if the clang numbering is different in gcc 4.2.1 then far more = than just adding a >>=20 >>> Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) >>=20 >>=20 >> for some "?" would need to be involved in the changes in order to = reach compatibility. >>=20 >>=20 >> I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form >>=20 >>> cmplwi r?,7 >>=20 >>=20 >> for some r?, such as r5 or r4, and the conditional branch generated = is a bgt instruction. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > gcc 4.2.1 generates comparison instructions for va_arg of the form: >=20 > cmplwi cr7,r0,8 >=20 > and the conditional branch generated is a "bge cr7, . . ." = instruction. >=20 > So the same number range is in use by both compilers: They are = compatible for the bounds checks for reg vs. overflow for how they = count, equality inclusion/exclusion matching up with the specific number = (8 vs. 7) used to make things the same overall. >=20 > Other aspects of the code generation distinctions would take me time = to analyze. It will be a while before I will be looking at other points. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Sat Feb 20 12:51:21 2016 Return-Path: Delivered-To: freebsd-toolchain@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 BA472AAE4D3 for ; Sat, 20 Feb 2016 12:51:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 77F5CE8F for ; Sat, 20 Feb 2016 12:51:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u1KCp8H3082712 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Feb 2016 12:51:13 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: confusing messages from clang From: David Chisnall In-Reply-To: <20160220005749.GA84382@troutmask.apl.washington.edu> Date: Sat, 20 Feb 2016 12:51:03 +0000 Cc: freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160220005749.GA84382@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 12:51:21 -0000 C compilers are always doing best effort attempts to report when you = feed them code that is not valid C. For example, in this case: On 20 Feb 2016, at 00:57, Steve Kargl = wrote: > if (i > 0) > goto corrupt; This is valid, as long as you have a label called corrupt to look for. = You do not, however, because: > return; >=20 > whoops: > printf("whoops\n"); > return >=20 > corrupt: > printf("corrupt\n=E2=80=9D); The statement: > return corrupt: printf("corrupt\n"); is just confusing. It appears to be trying to return the value in = corrupt (which is not an identifier that corresponds to any valid = variable) and then has some trailing characters after the end of the = statement. Fortunately, the compiler tells you exactly what is wrong: First it says: > foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you = mean 'crypt'? > corrupt: > ^~~~~~~ Here, it is telling you that the value passed to your return statement = is an undeclared identifier. Then it tells you that you have more = tokens after the end of your return statement: > foo.c:21:8: error: expected ';' after return statement > corrupt: > ^ > ; I am slightly surprised that there=E2=80=99s no warning that a return = statement with a value is invalid in a function that returns void, but = perhaps that=E2=80=99s because after finding two things wrong with one = statement it gives up. The correct fix, of course, is to insert the missing semicolon after the = return at the end of line 19. If you had tried compiling the same thing = with gcc 5, then you would have noticed that you get very similar error = messages (though gcc doesn=E2=80=99t attempt to provide a fixit hint and = does warn that you have a return statement returning a value from a = function that returns void). David From owner-freebsd-toolchain@freebsd.org Sat Feb 20 14:27:01 2016 Return-Path: Delivered-To: freebsd-toolchain@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 76AE3AAEB43; Sat, 20 Feb 2016 14:27:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 306541BAF; Sat, 20 Feb 2016 14:27:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::18c3:362f:6e6e:ec33] (unknown [IPv6:2001:7b8:3a7:0:18c3:362f:6e6e:ec33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1DA88203F6; Sat, 20 Feb 2016 15:26:59 +0100 (CET) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5DA5F582-065E-46E8-83AF-BAAAF307D47F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160220083450.GA55777@vlakno.cz> Date: Sat, 20 Feb 2016 15:26:58 +0100 Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: <68D66F67-EC4D-4CF2-A249-C7F0C4D4747D@FreeBSD.org> References: <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> <20160220083450.GA55777@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 14:27:01 -0000 --Apple-Mail=_5DA5F582-065E-46E8-83AF-BAAAF307D47F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 20 Feb 2016, at 09:34, Roman Divacky wrote: > Fwiw, I've just committed the patch to clang in r261422. You might want > to keep using a local modification or ask dim@ to import that patch > to our copy of 3.8. I've asked the LLVM release manager to consider merging this into the 3.8 branch. The fix looks trivial enough. :) -Dimitry --Apple-Mail=_5DA5F582-065E-46E8-83AF-BAAAF307D47F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbId7IACgkQsF6jCi4glqN1uQCbBiWkEoIRhsQvUq1tAZQl04+N ppMAoLIjMK+iAPOdBzQi3b+7siKZ6Zcx =RUdp -----END PGP SIGNATURE----- --Apple-Mail=_5DA5F582-065E-46E8-83AF-BAAAF307D47F-- From owner-freebsd-toolchain@freebsd.org Sat Feb 20 14:32:43 2016 Return-Path: Delivered-To: freebsd-toolchain@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 01A9DAAEE2B for ; Sat, 20 Feb 2016 14:32:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0AB41F1C for ; Sat, 20 Feb 2016 14:32:42 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 95D8815340A for ; Sat, 20 Feb 2016 15:32:27 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jygVVYLoZbkQ; Sat, 20 Feb 2016 15:31:58 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 63864153401 for ; Sat, 20 Feb 2016 15:31:58 +0100 (CET) To: FreeBSD Toolchain From: Willem Jan Withagen Subject: Questions about problems/errors with the include files Message-ID: <56C878DD.2070203@digiware.nl> Date: Sat, 20 Feb 2016 15:31:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 14:32:43 -0000 Hi, Before I actually dump the problem here. Would this be the place to ask about include files that give errors for code compiling under GCC but not under Clang 3.7?? gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 Target: x86_64-unknown-freebsd11.0 Thread model: posix --WjW From owner-freebsd-toolchain@freebsd.org Sat Feb 20 14:37:25 2016 Return-Path: Delivered-To: freebsd-toolchain@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 7524DAAEF8A for ; Sat, 20 Feb 2016 14:37:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E3FF1F8A for ; Sat, 20 Feb 2016 14:37:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D3A6520418; Sat, 20 Feb 2016 15:37:21 +0100 (CET) Subject: Re: Questions about problems/errors with the include files Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E70D6046-7BE4-4852-8948-121F668969C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56C878DD.2070203@digiware.nl> Date: Sat, 20 Feb 2016 15:37:15 +0100 Cc: FreeBSD Toolchain Message-Id: References: <56C878DD.2070203@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 14:37:25 -0000 --Apple-Mail=_E70D6046-7BE4-4852-8948-121F668969C9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 20 Feb 2016, at 15:31, Willem Jan Withagen wrote: > > Before I actually dump the problem here. > Would this be the place to ask about include files that give errors for > code compiling under GCC but not under Clang 3.7?? > > gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) > > FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 > Target: x86_64-unknown-freebsd11.0 > Thread model: posix Well, posting the actual error message(s) would help. :-) -Dimitry --Apple-Mail=_E70D6046-7BE4-4852-8948-121F668969C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbIeiEACgkQsF6jCi4glqNkHwCggKLjjn1EAtMRUI6OU4ZTuXvm njoAoJeV7TyOezsT0Gdy21X28dm34xBu =fywi -----END PGP SIGNATURE----- --Apple-Mail=_E70D6046-7BE4-4852-8948-121F668969C9-- From owner-freebsd-toolchain@freebsd.org Sat Feb 20 14:54:07 2016 Return-Path: Delivered-To: freebsd-toolchain@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 70A96AAF54E for ; Sat, 20 Feb 2016 14:54:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3927EB19 for ; Sat, 20 Feb 2016 14:54:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5ACB42044F; Sat, 20 Feb 2016 15:54:05 +0100 (CET) Subject: Re: confusing messages from clang Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F9809CE0-4FDE-456C-B1D7-E33BEB87B999"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: Date: Sat, 20 Feb 2016 15:53:57 +0100 Cc: Steve Kargl , freebsd-toolchain@freebsd.org Message-Id: <8468C8EA-A503-40FD-8379-2A957CE47C77@FreeBSD.org> References: <20160220005749.GA84382@troutmask.apl.washington.edu> To: Alex Denisov <1101.debian@gmail.com> X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 14:54:07 -0000 --Apple-Mail=_F9809CE0-4FDE-456C-B1D7-E33BEB87B999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 20 Feb 2016, at 08:33, Alex Denisov <1101.debian@gmail.com> wrote: >> On 20 Feb 2016, at 01:57, Steve Kargl = wrote: >>=20 >> If anyone is interesting fixing FreeBSD's C compiler, it >> would be appreciated. ... >> foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you = mean 'crypt'? >> corrupt: >> ^~~~~~~ >> crypt >> /usr/include/unistd.h:450:7: note: 'crypt' declared here >> char *crypt(const char *, const char *); >> ^ >> foo.c:21:8: error: expected ';' after return statement >> corrupt: >> ^ >> ; >> foo.c:14:12: error: use of undeclared label 'corrupt' >> goto corrupt; >> ^ ... > I=E2=80=99ve submitted the bug to LLVM=E2=80=99s bugzilla: = https://llvm.org/bugs/show_bug.cgi?id=3D26678 >=20 > Also, it looks like OS agnostic. At least I see the same behaviour on = OSX as well. Yes, the messages could definitely be improved. But for a compiler, it is sometimes hard to guess the 'intent' of the code, though. :) Note that gcc (I used 6.0 from ports) gives similarly confused messages: foo.c: In function 'foo': foo.c:21:1: error: 'corrupt' undeclared (first use in this function) corrupt: ^~~~~~~ foo.c:21:1: note: each undeclared identifier is reported only once for = each function it appears in foo.c:21:1: warning: 'return' with a value, in function returning void foo.c:5:1: note: declared here foo(int i) ^~~ foo.c:21:8: error: expected ';' before ':' token corrupt: ^ foo.c:14:6: error: label 'corrupt' used but not defined goto corrupt; ^~~~ In gcc's case, it appears to read the statement as "return corrupt:", causing it to first complain about the undeclared identifier, and then about a missing semicolon. Later, the label is of course still not defined, so it complains again. -Dimitry --Apple-Mail=_F9809CE0-4FDE-456C-B1D7-E33BEB87B999 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbIfgwACgkQsF6jCi4glqMLPQCfQZGgjWHQuxPLD1WFpHaUpkwd NSkAnA9f/zlG5JkB2LNrppcipKNnuTBg =0J1D -----END PGP SIGNATURE----- --Apple-Mail=_F9809CE0-4FDE-456C-B1D7-E33BEB87B999-- From owner-freebsd-toolchain@freebsd.org Sat Feb 20 15:00:51 2016 Return-Path: Delivered-To: freebsd-toolchain@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 70BA5AAF84E for ; Sat, 20 Feb 2016 15:00:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D029C3D; Sat, 20 Feb 2016 15:00:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 18F1E1534E5; Sat, 20 Feb 2016 16:00:49 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMINlr02T1QB; Sat, 20 Feb 2016 16:00:20 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 5FE6D1534E3; Sat, 20 Feb 2016 16:00:20 +0100 (CET) Subject: Re: Questions about problems/errors with the include files To: Dimitry Andric References: <56C878DD.2070203@digiware.nl> Cc: FreeBSD Toolchain From: Willem Jan Withagen Message-ID: <56C87F83.8020901@digiware.nl> Date: Sat, 20 Feb 2016 16:00:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 15:00:51 -0000 On 20-2-2016 15:37, Dimitry Andric wrote: > On 20 Feb 2016, at 15:31, Willem Jan Withagen wrote: >> >> Before I actually dump the problem here. >> Would this be the place to ask about include files that give errors for >> code compiling under GCC but not under Clang 3.7?? >> >> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) >> >> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 >> Target: x86_64-unknown-freebsd11.0 >> Thread model: posix > > Well, posting the actual error message(s) would help. :-) I know, but Don't want the burden the list with a lot of cr.p if it is not appriciated.... Will send a next post. --WjW From owner-freebsd-toolchain@freebsd.org Sat Feb 20 15:09:21 2016 Return-Path: Delivered-To: freebsd-toolchain@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 75204AAFABF for ; Sat, 20 Feb 2016 15:09:21 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0805DF15 for ; Sat, 20 Feb 2016 15:09:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id A6FF815340A for ; Sat, 20 Feb 2016 16:09:17 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAWUm5MkXkL6; Sat, 20 Feb 2016 16:09:06 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 6DF9E153413 for ; Sat, 20 Feb 2016 16:09:06 +0100 (CET) To: FreeBSD Toolchain From: Willem Jan Withagen Subject: Ceph compilation on inclusion of /usr/include/c++/v1/deque X-Enigmail-Draft-Status: N1110 Message-ID: <56C88191.7030801@digiware.nl> Date: Sat, 20 Feb 2016 16:09:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 15:09:21 -0000 I'm trying to build a port of Ceph for FreeBSD, which is sort of trying to shoot at a tank with a watergun.... :) There are 2 things to porting burdens: Linux <> FreeBSD GCC <> Clang So I'm not sure whether to error below is due a GCC-ism that is not suppoted by the 3.7.1 Clang we are running on CURRENT. I you want to reproduce it is rather labourious, but not all that complex: git clone https://github.com/wjwithagen/ceph.git cd ceph git checkout wip-wjw-freebsd-tests ./do_freebsd.sh And wait for the error to appear. --WjW libtool: compile: clang++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_GNU_SOURCE -DCEPH_LIBDIR=\"/usr/local/lib\" -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\" -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT -Woverloaded-virtual -fPIC -I./xxHash -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -g -DGTEST_USE_OWN_TR1_TUPLE=1 -I/usr/local/include -Wno-unused-local-typedef -Wno-mismatched-tags -Wno-macro-redefined -Wno-unused-function -Wno-unused-label -Wno-undefined-bool-conversion -Wno-unused-private-field -Wno-unused-local-typedef -Wno-uninitialized -Wno-gnu-designator -Wno-inconsistent-missing-override -Wno-deprecated-declarations -std=gnu++11 -MT rgw/librgw_la-rgw_basic_types.lo -MD -MP -MF rgw/.deps/librgw_la-rgw_basic_types.Tpo -c rgw/rgw_basic_types.cc -o rgw/librgw_la-rgw_basic_types.o >/dev/null 2>&1 In file included from rgw/rgw_client_io.cc:8: In file included from rgw/rgw_client_io.h:13: In file included from rgw/rgw_common.h:37: In file included from rgw/rgw_website.h:18: rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] while (o = iter.get_next()) { ~~^~~~~~~~~~~~~~~~~ rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to silence this warning while (o = iter.get_next()) { ^ ( ) rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an equality comparison while (o = iter.get_next()) { ^ == In file included from rgw/rgw_cache.cc:4: In file included from rgw/rgw_cache.h:7: In file included from rgw/rgw_rados.h:11: In file included from rgw/rgw_common.h:37: In file included from rgw/rgw_website.h:18: rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] while (o = iter.get_next()) { ~~^~~~~~~~~~~~~~~~~ rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to silence this warning while (o = iter.get_next()) { ^ ( ) rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an equality comparison while (o = iter.get_next()) { ^ == In file included from rgw/rgw_cr_rados.cc:1: In file included from rgw/rgw_rados.h:11: In file included from rgw/rgw_common.h:37: In file included from rgw/rgw_website.h:18: rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] while (o = iter.get_next()) { ~~^~~~~~~~~~~~~~~~~ rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to silence this warning while (o = iter.get_next()) { ^ ( ) rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an equality comparison while (o = iter.get_next()) { ^ == In file included from rgw/rgw_tools.cc:11: In file included from rgw/rgw_common.h:37: In file included from rgw/rgw_website.h:18: rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] while (o = iter.get_next()) { ~~^~~~~~~~~~~~~~~~~ rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to silence this warning while (o = iter.get_next()) { ^ ( ) rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an equality comparison while (o = iter.get_next()) { ^ == In file included from rgw/rgw_bucket.cc:11: In file included from rgw/rgw_rados.h:11: In file included from rgw/rgw_common.h:37: In file included from rgw/rgw_website.h:18: rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a condition without parentheses [-Wparentheses] while (o = iter.get_next()) { ~~^~~~~~~~~~~~~~~~~ rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to silence this warning while (o = iter.get_next()) { ^ ( ) rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an equality comparison while (o = iter.get_next()) { ^ == In file included from rgw/rgw_cache.cc:4: In file included from rgw/rgw_cache.h:7: In file included from rgw/rgw_rados.h:8: In file included from ./include/Context.h:19: In file included from ./common/dout.h:19: In file included from ./global/global_context.h:18: In file included from ./common/ceph_context.h:26: In file included from ./common/cmdparse.h:12: In file included from ./common/Formatter.h:8: /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'RGWPeriod') static const difference_type __block_size = sizeof(value_type) < 256 ? 4096 / sizeof(value_type) : 16; ^~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/deque:1159:15: note: in instantiation of template class 'std::__1::__deque_base >' requested here : private __deque_base<_Tp, _Allocator> ^ rgw/rgw_period_history.h:26:27: note: in instantiation of template class 'std::__1::deque >' requested here std::deque periods; ^ rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod' class RGWPeriod; ^ From owner-freebsd-toolchain@freebsd.org Sat Feb 20 15:13:39 2016 Return-Path: Delivered-To: freebsd-toolchain@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 4BDB8AAFCB3 for ; Sat, 20 Feb 2016 15:13:39 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1682A1156 for ; Sat, 20 Feb 2016 15:13:39 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 015F6153416 for ; Sat, 20 Feb 2016 16:13:37 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ggAVSwbIkV2; Sat, 20 Feb 2016 16:13:08 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id DB16815340A for ; Sat, 20 Feb 2016 16:13:08 +0100 (CET) Subject: Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque To: FreeBSD Toolchain References: <56C88191.7030801@digiware.nl> From: Willem Jan Withagen Message-ID: <56C88284.2020006@digiware.nl> Date: Sat, 20 Feb 2016 16:13:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C88191.7030801@digiware.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 15:13:39 -0000 On 20-2-2016 16:09, Willem Jan Withagen wrote: > I'm trying to build a port of Ceph for FreeBSD, which is sort of trying > to shoot at a tank with a watergun.... :) > > There are 2 things to porting burdens: > Linux <> FreeBSD > GCC <> Clang > > So I'm not sure whether to error below is due a GCC-ism that is not > suppoted by the 3.7.1 Clang we are running on CURRENT. > > I you want to reproduce it is rather labourious, but not all that complex: > git clone https://github.com/wjwithagen/ceph.git > cd ceph > git checkout wip-wjw-freebsd-tests Forgot to mention to install the dependancies: sudo ./install_deps.sh --WjW From owner-freebsd-toolchain@freebsd.org Sat Feb 20 15:50:47 2016 Return-Path: Delivered-To: freebsd-toolchain@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 52120AAEC61 for ; Sat, 20 Feb 2016 15:50:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19AE91F71 for ; Sat, 20 Feb 2016 15:50:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 34C0E20505; Sat, 20 Feb 2016 16:50:44 +0100 (CET) Subject: Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A00D131F-74B9-4436-8A20-62AA7152D61F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56C88191.7030801@digiware.nl> Date: Sat, 20 Feb 2016 16:50:33 +0100 Cc: FreeBSD Toolchain Message-Id: References: <56C88191.7030801@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 15:50:47 -0000 --Apple-Mail=_A00D131F-74B9-4436-8A20-62AA7152D61F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Feb 2016, at 16:09, Willem Jan Withagen wrote: >=20 > I'm trying to build a port of Ceph for FreeBSD, which is sort of = trying > to shoot at a tank with a watergun.... :) This is very nice, it would be good to have Ceph on FreeBSD. Note that if you have problems with porting, usually the freebsd-ports mailing list is a better audience. > I you want to reproduce it is rather labourious, but not all that = complex: > git clone https://github.com/wjwithagen/ceph.git > cd ceph > git checkout wip-wjw-freebsd-tests > ./do_freebsd.sh >=20 > And wait for the error to appear. ... > /usr/include/c++/v1/deque:912:49: error: invalid application of = 'sizeof' > to an incomplete type 'value_type' (aka 'RGWPeriod') > static const difference_type __block_size =3D sizeof(value_type) < = 256 > ? 4096 / sizeof(value_type) : 16; > ^~~~~~~~~~~~~~~~~~ > /usr/include/c++/v1/deque:1159:15: note: in instantiation of template > class 'std::__1::__deque_base std::__1::allocator >' requested here > : private __deque_base<_Tp, _Allocator> > ^ > rgw/rgw_period_history.h:26:27: note: in instantiation of template = class > 'std::__1::deque >> ' requested here > std::deque periods; > ^ > rgw/rgw_period_history.h:16:7: note: forward declaration of = 'RGWPeriod' > class RGWPeriod; > ^ Without having to build anything, I see the problem already. :) The error message is unfortunately rather confusing, but the gist of it is that the implementation of std::deque<> requires a complete type. Which means that you cannot do this: #include class foo; std::deque bar; Compiling this example with clang and libc++ will result in (not all errors shown, no need to): In file included from deque-test.cpp:1: /usr/include/c++/v1/deque:912:49: error: invalid application of = 'sizeof' to an incomplete type 'value_type' (aka 'foo') static const difference_type __block_size =3D sizeof(value_type) = < 256 ? 4096 / sizeof(value_type) : 16; ^~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/deque:1159:15: note: in instantiation of = template class 'std::__1::__deque_base >' = requested here : private __deque_base<_Tp, _Allocator> ^ deque-test.cpp:3:17: note: in instantiation of template class = 'std::__1::deque >' requested here std::deque bar; ^ deque-test.cpp:2:7: note: forward declaration of 'foo' class foo; ^ Similarly, compiling the example with g++ and libstdc++ (6.0.0 from ports) results in: In file included from /usr/local/lib/gcc6/include/c++/deque:64:0, from deque-test.cpp:1: /usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation = of 'void std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) = [with _Tp =3D foo; _Alloc =3D std::allocator; std::size_t =3D = unsigned int]': /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26: required = from 'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp =3D foo; = _Alloc =3D std::allocator]' /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23: required = from 'std::deque<_Tp, _Alloc>::deque() [with _Tp =3D foo; _Alloc =3D = std::allocator]' deque-test.cpp:3:17: required from here /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: = invalid application of 'sizeof' to incomplete type 'foo' const size_t __num_nodes =3D (__num_elements/ = __deque_buf_size(sizeof(_Tp)) = ^ /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: = invalid application of 'sizeof' to incomplete type 'foo' % __deque_buf_size(sizeof(_Tp))); ^ Looking at rgw_period_history.h, it is indeed using an incomplete type: #include #include #include #include #include "include/assert.h" #include "include/types.h" namespace bi =3D boost::intrusive; class RGWPeriod; /** * RGWPeriodHistory tracks the relative history of all inserted = periods, * coordinates the pulling of missing intermediate periods, and = provides a * Cursor object for traversing through the connected history. */ class RGWPeriodHistory final { /// an ordered history of consecutive periods struct History : public bi::avl_set_base_hook<> { std::deque periods; E.g at this point, all the compiler has is a forward declaration of RGWPeriod. If this even compiles on Linux, I am unsure how it manages to do so. :-) Maybe the Linux build pulls in some other header first, getting the full definition of RGWPeriod somehow? In any case, the easiest fix is probably to switch around the inclusions of the headers in rgw_period_history.cc, e.g. changing: #include "rgw_period_history.h" #include "rgw_rados.h" to: #include "rgw_rados.h" #include "rgw_period_history.h" Since rgw_rados.h contains the full definition of RGWPeriod, the forward declaration on line 16 of rgw_period_history.h can then be deleted. Alternatively, include rgw_rados.h directly in rgw_period_history.h, which is what I would do. I am unsure how Ceph upstream thinks about that, though. Maybe you can check with them? -Dimitry --Apple-Mail=_A00D131F-74B9-4436-8A20-62AA7152D61F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbIi1MACgkQsF6jCi4glqO2MQCeKem6LeqXxcXeI87HovaOD56p +M0An2Va/AzGJ1XYKMpmb6bhdks5/55X =srsF -----END PGP SIGNATURE----- --Apple-Mail=_A00D131F-74B9-4436-8A20-62AA7152D61F-- From owner-freebsd-toolchain@freebsd.org Sat Feb 20 20:00:20 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C3F15AAEF47 for ; Sat, 20 Feb 2016 20:00:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59EB018AD; Sat, 20 Feb 2016 20:00:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B7E4815340A; Sat, 20 Feb 2016 21:00:16 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dg6BRSVyAnt; Sat, 20 Feb 2016 21:00:03 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id EE2CA153416; Sat, 20 Feb 2016 20:47:30 +0100 (CET) Subject: Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque To: Dimitry Andric References: <56C88191.7030801@digiware.nl> Cc: FreeBSD Toolchain From: Willem Jan Withagen X-Enigmail-Draft-Status: N1110 Message-ID: <56C8C2D1.9070603@digiware.nl> Date: Sat, 20 Feb 2016 20:47:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 20:00:21 -0000 On 20-2-2016 16:50, Dimitry Andric wrote: > On 20 Feb 2016, at 16:09, Willem Jan Withagen wrote: >> >> I'm trying to build a port of Ceph for FreeBSD, which is sort of trying >> to shoot at a tank with a watergun.... :) > > This is very nice, it would be good to have Ceph on FreeBSD. Note that > if you have problems with porting, usually the freebsd-ports mailing > list is a better audience. > > >> I you want to reproduce it is rather labourious, but not all that complex: >> git clone https://github.com/wjwithagen/ceph.git >> cd ceph >> git checkout wip-wjw-freebsd-tests >> ./do_freebsd.sh >> >> And wait for the error to appear. > ... >> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' >> to an incomplete type 'value_type' (aka 'RGWPeriod') >> static const difference_type __block_size = sizeof(value_type) < 256 >> ? 4096 / sizeof(value_type) : 16; >> ^~~~~~~~~~~~~~~~~~ >> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template >> class 'std::__1::__deque_base> std::__1::allocator >' requested here >> : private __deque_base<_Tp, _Allocator> >> ^ >> rgw/rgw_period_history.h:26:27: note: in instantiation of template class >> 'std::__1::deque >>> ' requested here >> std::deque periods; >> ^ >> rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod' >> class RGWPeriod; >> ^ > > Without having to build anything, I see the problem already. :) The > error message is unfortunately rather confusing, but the gist of it is > that the implementation of std::deque<> requires a complete type. > > Which means that you cannot do this: > > #include > class foo; > std::deque bar; > > Compiling this example with clang and libc++ will result in (not all > errors shown, no need to): > > In file included from deque-test.cpp:1: > /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'foo') > static const difference_type __block_size = sizeof(value_type) < 256 ? 4096 / sizeof(value_type) : 16; > ^~~~~~~~~~~~~~~~~~ > /usr/include/c++/v1/deque:1159:15: note: in instantiation of template class 'std::__1::__deque_base >' requested here > : private __deque_base<_Tp, _Allocator> > ^ > deque-test.cpp:3:17: note: in instantiation of template class 'std::__1::deque >' requested here > std::deque bar; > ^ > deque-test.cpp:2:7: note: forward declaration of 'foo' > class foo; > ^ > > Similarly, compiling the example with g++ and libstdc++ (6.0.0 from > ports) results in: > > In file included from /usr/local/lib/gcc6/include/c++/deque:64:0, > from deque-test.cpp:1: > /usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation of 'void std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) [with _Tp = foo; _Alloc = std::allocator; std::size_t = unsigned int]': > /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26: required from 'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp = foo; _Alloc = std::allocator]' > /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23: required from 'std::deque<_Tp, _Alloc>::deque() [with _Tp = foo; _Alloc = std::allocator]' > deque-test.cpp:3:17: required from here > /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: invalid application of 'sizeof' to incomplete type 'foo' > const size_t __num_nodes = (__num_elements/ __deque_buf_size(sizeof(_Tp)) > ^ > /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: invalid application of 'sizeof' to incomplete type 'foo' > % __deque_buf_size(sizeof(_Tp))); > ^ > > Looking at rgw_period_history.h, it is indeed using an incomplete type: > > #include > #include > #include > #include > #include "include/assert.h" > #include "include/types.h" > > namespace bi = boost::intrusive; > > class RGWPeriod; > > /** > * RGWPeriodHistory tracks the relative history of all inserted periods, > * coordinates the pulling of missing intermediate periods, and provides a > * Cursor object for traversing through the connected history. > */ > class RGWPeriodHistory final { > /// an ordered history of consecutive periods > struct History : public bi::avl_set_base_hook<> { > std::deque periods; > > E.g at this point, all the compiler has is a forward declaration of > RGWPeriod. If this even compiles on Linux, I am unsure how it manages > to do so. :-) Maybe the Linux build pulls in some other header first, > getting the full definition of RGWPeriod somehow? > > In any case, the easiest fix is probably to switch around the inclusions > of the headers in rgw_period_history.cc, e.g. changing: > > #include "rgw_period_history.h" > #include "rgw_rados.h" > > to: > > #include "rgw_rados.h" > #include "rgw_period_history.h" > > Since rgw_rados.h contains the full definition of RGWPeriod, the forward > declaration on line 16 of rgw_period_history.h can then be deleted. > > Alternatively, include rgw_rados.h directly in rgw_period_history.h, > which is what I would do. I am unsure how Ceph upstream thinks about > that, though. Maybe you can check with them? Hi Dimitry, Thanx for all the advise. It is going to take some time to absorbe all. :) I've got a FreeBSD pull running, and on and off I'm commented by other committers as to how or why... You've given enough text to actually put in the commit message. And we'll find out how they feel about it. As to running this by the ports list, I have not really seen any this type of problem passing by there. Next to that I expected it more to be GCC <> Clang because every commit is run through Jenkins compilation and testing, and it would be noticed there. Thanx for the help, --WjW