From owner-svn-src-head@FreeBSD.ORG Mon Jan 23 12:31:38 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8389E106564A; Mon, 23 Jan 2012 12:31:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 670578FC0C; Mon, 23 Jan 2012 12:31:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0NCVWWF079526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 14:31:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0NCVWVr085655; Mon, 23 Jan 2012 14:31:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0NCVWsl085654; Mon, 23 Jan 2012 14:31:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jan 2012 14:31:32 +0200 From: Kostik Belousov To: Dimitry Andric Message-ID: <20120123123132.GM31224@deviant.kiev.zoral.com.ua> References: <201201200138.q0K1cSou016739@svn.freebsd.org> <20120120.123256.1432718473132856309.hrs@allbsd.org> <20120123.132840.618925004528110765.hrs@allbsd.org> <4F1D51A0.6040405@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wFtFFPDCaES44eZG" Content-Disposition: inline In-Reply-To: <4F1D51A0.6040405@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Hiroki Sato , eadler@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r230354 - head/usr.sbin/makefs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 12:31:38 -0000 --wFtFFPDCaES44eZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2012 at 01:25:04PM +0100, Dimitry Andric wrote: > On 2012-01-23 05:28, Hiroki Sato wrote: > ... > > I don't think it is needed. The makefs utility is a special case > > because it will probably diverge from the upstream to support > > FreeBSD-specific feature in the future (this is one of the reasons > > why it is not in contrib/). It didn't happen so far, however. > > > > By the way, does gcc46 no longer allow unused code? Generally > > speaking, I think it is enough to clean up unused code only when we > > actually change the code. >=20 > The warnings are not about unused code, but about variables which are > assigned, but then never referenced anymore. Sometimes this is just a > cosmetic issue, and the compiler will hopefully optimize out the > unreferenced variable(s). In other situations there are real bugs. >=20 > In any case, gcc 4.5 and 4.6 just enable more warnings by default, and > when using -Wall; in particular the "variable set but not used" one. >=20 > This warning should really be suppressed when WARNS is set to a low > level, such as with makefs (it has WARNS?=3D2). >=20 > Attached diff makes it so, for gcc45 and gcc46. It uses the same > approach as I added earlier for clang. It can also be easily extended > to other warnings. There is a typo in the second or condition, should it be gcc46 both times ? Anyway, the reason to answer this message is two ask the for seemingly unreasonable approach of matching compiler type/version based on the driver name. This completely precludes anybody from using gcc installed not from the ports tree. Could the tests performed based on the driver version information instead of name ? --wFtFFPDCaES44eZG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8dUyMACgkQC3+MBN1Mb4iKqgCg8glXah5zu8+ZhSHWgj+FHMyG 6SwAnid/dyzGYZysvACwEKGVQ8D5x3hU =LDJn -----END PGP SIGNATURE----- --wFtFFPDCaES44eZG--