From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 17:46:57 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16F6106564A; Sun, 6 Nov 2011 17:46:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id 905E98FC08; Sun, 6 Nov 2011 17:46:57 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id CD4502A28CC5; Sun, 6 Nov 2011 18:28:35 +0100 (CET) Date: Sun, 6 Nov 2011 18:28:35 +0100 From: Ed Schouten To: Alexander Best Message-ID: <20111106172835.GO2258@hoeg.nl> References: <20111105102102.GA54596@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3dbUQUznexwzCA76" Content-Disposition: inline In-Reply-To: <20111105102102.GA54596@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 17:46:57 -0000 --3dbUQUznexwzCA76 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Alexander! Even though that I agree that Clang is sometimes a bit picky, we'd better spend the time fixing the actual bugs in the code. I am more than willing to commit patches that fix actual warnings/errors in code. --=20 Ed Schouten WWW: http://80386.nl/ --3dbUQUznexwzCA76 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOtsPDAAoJEG5e2P40kaK7/d4P/A2jdcmEpokfomjqkl7e2r1K p1jiwIR1eey6pshys8G27CWlGqoTuiIL/qxrgIrUogfQuWogEHzfdvHUcYlT8ZC/ q0YLRxbiTonFdmDdhrYlKNhSp9nLR7k2TcqL/7ZjgZ7XW8ufeKdP7ZJJlNqcKMJr O0XCOK/RHEBiDivoOAZR+G/Ont1c9S6tC/QueMfGGeF7zgT5/NM7x07SQ0zV3oy3 LQ++7llMRWUXN+9H6uXwU4as+d3151ZOIej64XfZoyiBnmH/obRFBrUk2ombmdFO GotESnpbEKaW44tA8C46S5f1pWnvXAV9ysb6FYqR+tmwoNNNSrUtQ3iS3C2yUKDb Ny4Il6HwZsBE0i28G3J+iFuDrP+LU+q9Fje7whIhjKZNADKePcEVj1jcU6JHnPQR T7JSDJu7JEFbCd37hcZt7GjgqDcUP08uAB0/yIaJB8+ONAPyjfFctpPad09gr+2L BnpaZfk+GAS8F7JJ3ma5+PVdmDoy5qnYEY+LIULZv+AypXy50RBlfc3T3uZIyEKN fPrlXOc82xlGTY642p1NkKsTFzFUabXXRYbznLSIkSPorf2ZkyX8jBTcSIp4bfYr V5oj1+za6nFKIPUuj5HUzvg8LDt2wlkoHntyz+ZehePmweD9roCQBYdG4m0Rg67Y L1A/aXe+7n2SrL3gD+vA =YBSN -----END PGP SIGNATURE----- --3dbUQUznexwzCA76-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 20:33:16 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A18FF1065702; Sun, 6 Nov 2011 20:33:16 +0000 (UTC) Date: Sun, 6 Nov 2011 20:33:16 +0000 From: Alexander Best To: Ed Schouten Message-ID: <20111106203316.GA73216@freebsd.org> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111106172835.GO2258@hoeg.nl> Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 20:33:16 -0000 On Sun Nov 6 11, Ed Schouten wrote: > Hello Alexander! > > Even though that I agree that Clang is sometimes a bit picky, we'd > better spend the time fixing the actual bugs in the code. I am more than > willing to commit patches that fix actual warnings/errors in code. the problem is, something like uint x; if (x < 0) ... clang will warn about this, yet it is 100% valid code so my vote would be to make such an error into a warning. the same with int x; x = x; i believe in both cases clang is too picky. cheers. alex > > -- > Ed Schouten > WWW: http://80386.nl/ From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 20:38:38 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DD53D1065678; Sun, 6 Nov 2011 20:38:38 +0000 (UTC) Date: Sun, 6 Nov 2011 20:38:38 +0000 From: Alexander Best To: Ed Schouten Message-ID: <20111106203838.GA74911@freebsd.org> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111106203316.GA73216@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 20:38:38 -0000 On Sun Nov 6 11, Alexander Best wrote: > On Sun Nov 6 11, Ed Schouten wrote: > > Hello Alexander! > > > > Even though that I agree that Clang is sometimes a bit picky, we'd > > better spend the time fixing the actual bugs in the code. I am more than > > willing to commit patches that fix actual warnings/errors in code. however it would be nice, if you could take a look at PR 162321. cheers. alex > > the problem is, something like > > uint x; > > if (x < 0) ... > > clang will warn about this, yet it is 100% valid code so my vote would be to > make such an error into a warning. > > the same with > > int x; > > x = x; > > i believe in both cases clang is too picky. > > cheers. > alex > > > > > -- > > Ed Schouten > > WWW: http://80386.nl/ > > From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 20:52:33 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3CBA106564A; Sun, 6 Nov 2011 20:52:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A67D28FC0C; Sun, 6 Nov 2011 20:52:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a81b:6656:1bbc:a3f7] (unknown [IPv6:2001:7b8:3a7:0:a81b:6656:1bbc:a3f7]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D9BB45C59; Sun, 6 Nov 2011 21:52:32 +0100 (CET) Message-ID: <4EB6F38E.2080006@FreeBSD.org> Date: Sun, 06 Nov 2011 21:52:30 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> In-Reply-To: <20111106203316.GA73216@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 20:52:34 -0000 On 2011-11-06 21:33, Alexander Best wrote: ... > the problem is, something like > > uint x; > > if (x < 0) ... > > clang will warn about this, yet it is 100% valid code so my vote would be to > make such an error into a warning. Sorry, but checking something unsigned to be smaller than zero is bogus, or at the least superfluous, and it's perfectly sane to warn about this, especially since the compiler is not going to emit code for it at all. The only time when this sort of check could be relevant, is when you are using a typedef'd type, and you have no way to be sure if the type is signed or unsigned. But then you will be in for trouble anyway... ... > the same with > > int x; > > x = x; > > i believe in both cases clang is too picky. This is a often-used idiom for attempting to 'shut up' a compiler when it (quite legitimately) complains about unused variables or arguments. However, a better idiom is: (void) x; but even this can lead some compilers or analysis tools to complain about "statements that don't do anything". A better way is to provide UNUSED_VARIABLE and UNUSED_ARGUMENT macros, and handle shutting up the compiler in its specific way there. Of course, the best solution is to just eliminate the unused variables or arguments. If that is not possible, for example due to a function signature that cannot be changed because of API considerations, you can always use __unused attributes. From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 20:58:05 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9524C1065673; Sun, 6 Nov 2011 20:58:05 +0000 (UTC) Date: Sun, 6 Nov 2011 20:58:05 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111106205805.GA78142@freebsd.org> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB6F38E.2080006@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 20:58:05 -0000 On Sun Nov 6 11, Dimitry Andric wrote: > On 2011-11-06 21:33, Alexander Best wrote: > ... > > the problem is, something like > > > > uint x; > > > > if (x < 0) ... > > > > clang will warn about this, yet it is 100% valid code so my vote would be to > > make such an error into a warning. > > Sorry, but checking something unsigned to be smaller than zero is bogus, > or at the least superfluous, and it's perfectly sane to warn about this, > especially since the compiler is not going to emit code for it at all. there was a discussion with the topic "disable -Wtautological-compare for clang" on freebsd-toolchain@ and most of the devs considered this code *not* to be bogus. ;) > > The only time when this sort of check could be relevant, is when you are > using a typedef'd type, and you have no way to be sure if the type is > signed or unsigned. But then you will be in for trouble anyway... > > > ... > > the same with > > > > int x; > > > > x = x; > > > > i believe in both cases clang is too picky. > > This is a often-used idiom for attempting to 'shut up' a compiler when > it (quite legitimately) complains about unused variables or arguments. > > However, a better idiom is: > > (void) x; > > but even this can lead some compilers or analysis tools to complain > about "statements that don't do anything". A better way is to provide > UNUSED_VARIABLE and UNUSED_ARGUMENT macros, and handle shutting up the > compiler in its specific way there. > > Of course, the best solution is to just eliminate the unused variables > or arguments. If that is not possible, for example due to a function > signature that cannot be changed because of API considerations, you can > always use __unused attributes. i see. does PR #162321 fall into this category, or can the assignment be removed? cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Sun Nov 6 21:13:00 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85107106566B; Sun, 6 Nov 2011 21:13:00 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from stark.strangled.net (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 6BAA68FC18; Sun, 6 Nov 2011 21:13:00 +0000 (UTC) Received: from [10.0.10.6] (c-71-204-150-235.hsd1.ca.comcast.net [71.204.150.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by stark.strangled.net (Postfix) with ESMTPSA id 1B4253981E; Sun, 6 Nov 2011 13:13:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20111106205805.GA78142@freebsd.org> Date: Sun, 6 Nov 2011 13:13:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Nov 2011 21:13:00 -0000 On Nov 6, 2011, at 12:58 PM, Alexander Best wrote: > On Sun Nov 6 11, Dimitry Andric wrote: >> On 2011-11-06 21:33, Alexander Best wrote: >> ...=20 >>> the problem is, something like >>>=20 >>> uint x; >>>=20 >>> if (x < 0) ... >>>=20 >>> clang will warn about this, yet it is 100% valid code so my vote = would be to >>> make such an error into a warning. >>=20 >> Sorry, but checking something unsigned to be smaller than zero is = bogus, >> or at the least superfluous, and it's perfectly sane to warn about = this, >> especially since the compiler is not going to emit code for it at = all. >=20 > there was a discussion with the topic > "disable -Wtautological-compare for clang" on freebsd-toolchain@ and = most of > the devs considered this code *not* to be bogus. ;) Tautologic checks are good because they may find problems you never = thought about. The examples pointed out are quite simple and are missing = the point. You have to thinking about crazy macros. The only argument against this tautological check that I agree with is = when the code is explicitly trying to be safe. If the developer checks = for "i < 0" when indexing an array he/she is trying to guard against = possible pitfalls in the future when someone suddenly decides to change = the variable type to become signed. One possible security vulnerability = was avoided because that developer checked for negative values. I'm against turning this off by default, but it should not cause an = error. Regards, -- Rui Paulo From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 00:39:53 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71419106566B; Mon, 7 Nov 2011 00:39:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 295E48FC0C; Mon, 7 Nov 2011 00:39:49 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA70YiN2062233 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Nov 2011 17:34:44 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111106205805.GA78142@freebsd.org> Date: Sun, 6 Nov 2011 17:34:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 06 Nov 2011 17:34:44 -0700 (MST) Cc: freebsd-toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2011 00:39:53 -0000 On Nov 6, 2011, at 1:58 PM, Alexander Best wrote: > On Sun Nov 6 11, Dimitry Andric wrote: >> On 2011-11-06 21:33, Alexander Best wrote: >> ...=20 >>> the problem is, something like >>>=20 >>> uint x; >>>=20 >>> if (x < 0) ... >>>=20 >>> clang will warn about this, yet it is 100% valid code so my vote = would be to >>> make such an error into a warning. >>=20 >> Sorry, but checking something unsigned to be smaller than zero is = bogus, >> or at the least superfluous, and it's perfectly sane to warn about = this, >> especially since the compiler is not going to emit code for it at = all. >=20 > there was a discussion with the topic > "disable -Wtautological-compare for clang" on freebsd-toolchain@ and = most of > the devs considered this code *not* to be bogus. ;) The code actually is bogus. It may be masking a real problem, because = often times it is a "sanity check" to make sure that you aren't doing = something naughty, like passing -1 for the length. However, if you then = pass the unsigned through a signed value, it suddenly becomes negative, = and you have a hard to spot bug. IIR the the tread, there weren't too = many people offering an opinion... Warner= From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 00:39:54 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023911065673; Mon, 7 Nov 2011 00:39:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AF8588FC12; Mon, 7 Nov 2011 00:39:53 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA70ajma062240 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Nov 2011 17:36:45 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 6 Nov 2011 17:36:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> To: Rui Paulo X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 06 Nov 2011 17:36:45 -0700 (MST) Cc: Alexander Best , freebsd-toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2011 00:39:54 -0000 On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: > The only argument against this tautological check that I agree with is = when the code is explicitly trying to be safe. If the developer checks = for "i < 0" when indexing an array he/she is trying to guard against = possible pitfalls in the future when someone suddenly decides to change = the variable type to become signed. One possible security vulnerability = was avoided because that developer checked for negative values. > I'm against turning this off by default, but it should not cause an = error. Except when you pass args back and forth between signed and unsigned and = back again. If you check < 0 in the middle, that's one more security = bug you thought you had fixed, but really you've done nothing with. Warner From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 00:47:38 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12ACE1065672; Mon, 7 Nov 2011 00:47:38 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from stark.strangled.net (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id EB7FD8FC28; Mon, 7 Nov 2011 00:47:37 +0000 (UTC) Received: from [10.0.10.6] (c-71-204-150-235.hsd1.ca.comcast.net [71.204.150.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by stark.strangled.net (Postfix) with ESMTPSA id 9FBCE3981E; Sun, 6 Nov 2011 16:47:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> Date: Sun, 6 Nov 2011 16:47:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: Alexander Best , freebsd-toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2011 00:47:38 -0000 On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: > On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: >> The only argument against this tautological check that I agree with = is when the code is explicitly trying to be safe. If the developer = checks for "i < 0" when indexing an array he/she is trying to guard = against possible pitfalls in the future when someone suddenly decides to = change the variable type to become signed. One possible security = vulnerability was avoided because that developer checked for negative = values. >> I'm against turning this off by default, but it should not cause an = error. >=20 > Except when you pass args back and forth between signed and unsigned = and back again. If you check < 0 in the middle, that's one more = security bug you thought you had fixed, but really you've done nothing = with. Of course, but in the context of the compiler checks this argument = doesn't apply. Regards, -- Rui Paulo From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 01:20:51 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB2F9106566B; Mon, 7 Nov 2011 01:20:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7F63A8FC08; Mon, 7 Nov 2011 01:20:51 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA71Kmhn062380 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Nov 2011 18:20:49 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 6 Nov 2011 18:20:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3AE02E7D-A4BD-492D-97E4-9BA7538ECE89@bsdimp.com> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> To: Rui Paulo X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 06 Nov 2011 18:20:49 -0700 (MST) Cc: Alexander Best , freebsd-toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2011 01:20:51 -0000 On Nov 6, 2011, at 5:47 PM, Rui Paulo wrote: > On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: >=20 >> On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: >>> The only argument against this tautological check that I agree with = is when the code is explicitly trying to be safe. If the developer = checks for "i < 0" when indexing an array he/she is trying to guard = against possible pitfalls in the future when someone suddenly decides to = change the variable type to become signed. One possible security = vulnerability was avoided because that developer checked for negative = values. >>> I'm against turning this off by default, but it should not cause an = error. >>=20 >> Except when you pass args back and forth between signed and unsigned = and back again. If you check < 0 in the middle, that's one more = security bug you thought you had fixed, but really you've done nothing = with. >=20 >=20 > Of course, but in the context of the compiler checks this argument = doesn't apply. It is also useful for code where the default differs from system to = system. For example, char are signed on some architectures, and = unsigned on others. This warning would expose cases where the < 0 check = was done for safety from those where it was done in error. Warner= From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 00:12:47 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9DD421065689; Tue, 8 Nov 2011 00:12:47 +0000 (UTC) Date: Tue, 8 Nov 2011 00:12:47 +0000 From: Alexander Best To: Adrian Chadd Message-ID: <20111108001247.GA88837@freebsd.org> References: <20111103104523.GA30132@freebsd.org> <4EB2AF08.9010806@FreeBSD.org> <20111103190312.GA6709@freebsd.org> <4EB2F4CE.8050806@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 00:12:47 -0000 On Thu Nov 3 11, Adrian Chadd wrote: > Hi, > > Please submit a PR and I'll fix the AR5210 code. I'll have to find an > AR5210 though to test it against though... filed under kern/162366 and assigned to you. ;) cheers. alex > > > Adrian > > On 3 November 2011 13:08, Dimitry Andric wrote: > > On 2011-11-03 20:03, Alexander Best wrote: > >> On Thu Nov  3 11, Dimitry Andric wrote: > >>> On 2011-11-03 11:45, Alexander Best wrote: > >>> ... > >>>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: warning: signed shift result (0x200000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] > >>>>                 OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW); > >>>>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note: expanded from macro 'OS_REG_RMW_FIELD' > >>>>                 (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f))) > >>>>                                                        ^ > >>>> /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from macro 'OS_REG_WRITE' > >>>>             (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val)) > > ... > >>> Those warnings are bogus, and due to this bug: > > > > Actually, I was too quick with this one, since it isn't bogus.  The > > macro invocation: > > > >  OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW); > > > > ultimately expands to: > > > >  bus_space_write_4((bus_space_tag_t)(ah)->ah_st, (bus_space_handle_t)(ah)->ah_sh, (0x4004), ((bus_space_read_4((bus_space_tag_t)(ah)->ah_st, (bus_space_handle_t)(ah)->ah_sh, (0x4004)) &~ (0x00030000)) | (((0x00020000) << 16) & (0x00030000)))); > > > > The problem part is ((0x00020000) << 16), which is an overflow.  I'm not > > sure how clang concludes that the result (0x200000000) needs 35 bits to > > represent, as it seems to use 34 bits to me.  But that it doesn't fit > > into a signed integer is crystal-clear. > > > > E.g. this is a real bug!  Probably something in the macro needs to > > explicitly cast to 64 integers, or another workaround must be found. > > > > The other warning: > > > >> In file included from /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99: > >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15: warning: shift count is negative [-Wshift-count-negative] > >>          .chan11a               = BM4(F1_4950_4980, > >>                                   ^~~~~~~~~~~~~~~~~ > >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4: note: expanded from macro 'BM4' > >>           W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) } > >>           ^ > >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45: note: expanded from macro 'W1' > >>         (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) : (uint64_t) 0)) > >>                                                    ^ ~~~~~~~~~ > > > > is indeed bogus, since the macro makes sure the shift count never > > becomes negative.  (N.B.: This only happens for global initializations, > > *not* if you would use the same macro in a function.) > > > > > >>>   http://llvm.org/bugs/show_bug.cgi?id=10030 > >>> > >>> Unfortunately, it is still not fixed for the 3.0 release branch, and I > >>> don't expect it will be fixed for the actual release. > >> > >> thanks for the info. so how about something like > >> > >> diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk > >> index a0a595f..3cb13de 100644 > >> --- a/sys/conf/kern.mk > >> +++ b/sys/conf/kern.mk > >> @@ -1,12 +1,28 @@ > >>  # $FreeBSD$ > >> > >>  # > >> -# Warning flags for compiling the kernel and components of the kernel: > >> +# XXX Disable bogus llvm warnings, complaining about perfectly valid shifts. > >> +# See http://llvm.org/bugs/show_bug.cgi?id=10030 for more details. > >> +# > >> +.if ${CC:T:Mclang} == "clang" > >> +NOSHIFTWARNS=  -Wno-shift-count-negative -Wno-shift-count-overflow \ > >> +               -Wno-shift-overflow > >> +.endif > >> + > >> > >> ...and then add ${NOSHIFTWARNS} to the end of CWARNFLAGS? > > > > No, this is a way too big hammer, because it eliminates the useful > > warnings together with the false positives. > > > > It would be better to only apply this band-aid for the specific source > > files that need it, and even then, I would rather wait for the proper > > fix from upstream. > > From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 00:25:56 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AE8AA106566B; Tue, 8 Nov 2011 00:25:56 +0000 (UTC) Date: Tue, 8 Nov 2011 00:25:56 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20111108002556.GA91218@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 00:25:56 -0000 hi there, i've seen dozens of issues, where people set CPUTYPE=native. although this works in a lot of cases, it doesn't in others. why don't we simply add something like . if ${CPUTYPE} == "native" . error "bla" . endif in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is known to cause problems. cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 07:55:39 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F257D106566B; Tue, 8 Nov 2011 07:55:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id B6E0E8FC14; Tue, 8 Nov 2011 07:55:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb] (unknown [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0530D5C59; Tue, 8 Nov 2011 08:55:37 +0100 (CET) Message-ID: <4EB8E07B.5070908@FreeBSD.org> Date: Tue, 08 Nov 2011 08:55:39 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111108002556.GA91218@freebsd.org> In-Reply-To: <20111108002556.GA91218@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 07:55:40 -0000 On 2011-11-08 01:25, Alexander Best wrote: > i've seen dozens of issues, where people set CPUTYPE=native. although this > works in a lot of cases, it doesn't in others. why don't we simply add > something like > > . if ${CPUTYPE} == "native" > . error "bla" > . endif > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > known to cause problems. What does this solve? Don't you think it is better to try to fix the actual problems? Some people like being able to optimize for their specific CPU, however much you can shoot yourself in the foot with it. I haven't seen any consistent bug reports yet, just a lot of complaints that indicate a rather high probability of PEBKAC. And just to counter the nay-saying, I compiled a number of boxes with clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen any problems at all. From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 15:39:02 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5280106567D for ; Tue, 8 Nov 2011 15:39:02 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFFC8FC08 for ; Tue, 8 Nov 2011 15:39:02 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 13C397F383F; Tue, 8 Nov 2011 16:38:56 +0100 (CET) Date: Tue, 8 Nov 2011 16:38:56 +0100 From: Roman Divacky To: Dimitry Andric Message-ID: <20111108153856.GA90966@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB8E07B.5070908@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Alexander Best , freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 15:39:03 -0000 On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote: > On 2011-11-08 01:25, Alexander Best wrote: > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > works in a lot of cases, it doesn't in others. why don't we simply add > > something like > > > > . if ${CPUTYPE} == "native" > > . error "bla" > > . endif > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > known to cause problems. > > What does this solve? Don't you think it is better to try to fix the > actual problems? Some people like being able to optimize for their Yes, we definitely should aim for fixing the problems instead of working around them. This way both clang and freebsd benefits. roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 20:49:12 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A4680106567C; Tue, 8 Nov 2011 20:49:12 +0000 (UTC) Date: Tue, 8 Nov 2011 20:49:12 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20111108204912.GA34155@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 20:49:12 -0000 hi there, any reason 'make cleanworld' does otaku% make cleanworld rm -rf /usr/obj/usr/git-freebsd-head/* chflags -R 0 /usr/obj/usr/git-freebsd-head rm -rf /usr/obj/usr/git-freebsd-head/* where otaku% make cleanworld chflags -R 0 /usr/obj/usr/git-freebsd-head rm -rf /usr/obj/usr/git-freebsd-head/* should be sufficient? cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:04:20 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EB71D1065674; Tue, 8 Nov 2011 21:04:20 +0000 (UTC) Date: Tue, 8 Nov 2011 21:04:20 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20111108210420.GA37161@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108153856.GA90966@freebsd.org> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:04:21 -0000 On Tue Nov 8 11, Roman Divacky wrote: > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote: > > On 2011-11-08 01:25, Alexander Best wrote: > > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > > works in a lot of cases, it doesn't in others. why don't we simply add > > > something like > > > > > > . if ${CPUTYPE} == "native" > > > . error "bla" > > > . endif > > > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > > known to cause problems. > > > > What does this solve? Don't you think it is better to try to fix the > > actual problems? Some people like being able to optimize for their > > Yes, we definitely should aim for fixing the problems instead of working > around them. > > This way both clang and freebsd benefits. for me -march=native reports: otaku% gcc -march=native -E -v - search starts here: /usr/include/gcc/4.2 /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "" where instead of nocona, core2 would have been the better choice: [1.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 [1.000000] Features=0xbfebfbff [1.000000] Features2=0xe39d [1.000000] AMD Features=0x20100800 [1.000000] AMD Features2=0x1 [1.000000] TSC: P-state invariant, performance statistics cheers. alex > > roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:09:11 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6CA106564A; Tue, 8 Nov 2011 21:09:11 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id B01108FC18; Tue, 8 Nov 2011 21:09:11 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 340F97F383D; Tue, 8 Nov 2011 22:09:05 +0100 (CET) Date: Tue, 8 Nov 2011 22:09:05 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20111108210905.GA28416@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108210420.GA37161@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:09:12 -0000 clang will use "core2" for family=6 and model=15 check llvm/lib/Support/Host.cpp what is the problem? The fact that our gcc from the middle-ages does not recognize that? On Tue, Nov 08, 2011 at 09:04:20PM +0000, Alexander Best wrote: > On Tue Nov 8 11, Roman Divacky wrote: > > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote: > > > On 2011-11-08 01:25, Alexander Best wrote: > > > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > > > works in a lot of cases, it doesn't in others. why don't we simply add > > > > something like > > > > > > > > . if ${CPUTYPE} == "native" > > > > . error "bla" > > > > . endif > > > > > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > > > known to cause problems. > > > > > > What does this solve? Don't you think it is better to try to fix the > > > actual problems? Some people like being able to optimize for their > > > > Yes, we definitely should aim for fixing the problems instead of working > > around them. > > > > This way both clang and freebsd benefits. > > for me -march=native reports: > > otaku% gcc -march=native -E -v - Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic > #include "..." search starts here: > #include <...> search starts here: > /usr/include/gcc/4.2 > /usr/include > End of search list. > # 1 "" > # 1 "" > # 1 "" > # 1 "" > > where instead of nocona, core2 would have been the better choice: > > [1.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) > [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > [1.000000] Features=0xbfebfbff > [1.000000] Features2=0xe39d > [1.000000] AMD Features=0x20100800 > [1.000000] AMD Features2=0x1 > [1.000000] TSC: P-state invariant, performance statistics > > cheers. > alex > > > > > roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:23:52 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 93F9D106566B; Tue, 8 Nov 2011 21:23:52 +0000 (UTC) Date: Tue, 8 Nov 2011 21:23:52 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20111108212352.GA39160@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> <20111108210905.GA28416@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108210905.GA28416@freebsd.org> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:23:52 -0000 On Tue Nov 8 11, Roman Divacky wrote: > clang will use "core2" for family=6 and model=15 > > check llvm/lib/Support/Host.cpp > > what is the problem? The fact that our gcc from the middle-ages > does not recognize that? actually a few months ago quite a lot of gcc commits happend to add newer optimisations (such as core2) to gcc and some commits aimed at modifying gcc, so it would make the best -march=native choice there is. what's the clang command (similar to gcc -march=native -E -v - > On Tue, Nov 08, 2011 at 09:04:20PM +0000, Alexander Best wrote: > > On Tue Nov 8 11, Roman Divacky wrote: > > > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote: > > > > On 2011-11-08 01:25, Alexander Best wrote: > > > > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > > > > works in a lot of cases, it doesn't in others. why don't we simply add > > > > > something like > > > > > > > > > > . if ${CPUTYPE} == "native" > > > > > . error "bla" > > > > > . endif > > > > > > > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > > > > known to cause problems. > > > > > > > > What does this solve? Don't you think it is better to try to fix the > > > > actual problems? Some people like being able to optimize for their > > > > > > Yes, we definitely should aim for fixing the problems instead of working > > > around them. > > > > > > This way both clang and freebsd benefits. > > > > for me -march=native reports: > > > > otaku% gcc -march=native -E -v - > Using built-in specs. > > Target: amd64-undermydesk-freebsd > > Configured with: FreeBSD/amd64 system compiler > > Thread model: posix > > gcc version 4.2.2 20070831 prerelease [FreeBSD] > > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic > > #include "..." search starts here: > > #include <...> search starts here: > > /usr/include/gcc/4.2 > > /usr/include > > End of search list. > > # 1 "" > > # 1 "" > > # 1 "" > > # 1 "" > > > > where instead of nocona, core2 would have been the better choice: > > > > [1.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) > > [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > [1.000000] Features=0xbfebfbff > > [1.000000] Features2=0xe39d > > [1.000000] AMD Features=0x20100800 > > [1.000000] AMD Features2=0x1 > > [1.000000] TSC: P-state invariant, performance statistics > > > > cheers. > > alex > > > > > > > > roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:32:59 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6241065675; Tue, 8 Nov 2011 21:32:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5DEF58FC08; Tue, 8 Nov 2011 21:32:59 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 6E8317F383F; Tue, 8 Nov 2011 22:32:53 +0100 (CET) Date: Tue, 8 Nov 2011 22:32:53 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20111108213253.GA31062@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> <20111108210905.GA28416@freebsd.org> <20111108212352.GA39160@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108212352.GA39160@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:32:59 -0000 On Tue, Nov 08, 2011 at 09:23:52PM +0000, Alexander Best wrote: > On Tue Nov 8 11, Roman Divacky wrote: > > clang will use "core2" for family=6 and model=15 > > > > check llvm/lib/Support/Host.cpp > > > > what is the problem? The fact that our gcc from the middle-ages > > does not recognize that? > > actually a few months ago quite a lot of gcc commits happend to add newer > optimisations (such as core2) to gcc and some commits aimed at modifying gcc, > so it would make the best -march=native choice there is. > > what's the clang command (similar to gcc -march=native -E -v - one can use to check what actual optimisation clang turns "native" into? clang -### -march=native will show something like "-target-cpu" "k8-sse3" > also there seem to be cross-compilation issues. when people are running i386 > and want to cross-compile for amd64 and put CPUTYPE=core2 (or any other amd64 > cpu) into their make.conf, this gets downgraded by bsd.cpu.mk to prescott. > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800 > and > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html If gcc supports nocona now, the conf/84800 patch is ok. The same goes with downgrading core2 -> prescott. I have no idea what gcc supports these days. I think we should just skip the downgrading completely for clang as it either supports everything or can be made easily to support what it doesnt. roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:34:02 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92FE106564A; Tue, 8 Nov 2011 21:34:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A83C48FC19; Tue, 8 Nov 2011 21:34:02 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA8LTth5094520 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 14:29:56 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111108204912.GA34155@freebsd.org> Date: Tue, 8 Nov 2011 14:29:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07EC4416-D366-4CD9-8655-CB89935B0354@bsdimp.com> References: <20111108204912.GA34155@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 08 Nov 2011 14:29:56 -0700 (MST) Cc: freebsd-toolchain@freebsd.org Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:34:03 -0000 On Nov 8, 2011, at 1:49 PM, Alexander Best wrote: > hi there, >=20 > any reason 'make cleanworld' does >=20 > otaku% make cleanworld > rm -rf /usr/obj/usr/git-freebsd-head/* > chflags -R 0 /usr/obj/usr/git-freebsd-head > rm -rf /usr/obj/usr/git-freebsd-head/* >=20 > where >=20 > otaku% make cleanworld > chflags -R 0 /usr/obj/usr/git-freebsd-head > rm -rf /usr/obj/usr/git-freebsd-head/* >=20 > should be sufficient? chflags is a lot slower when it has to do an entire tree, rather than = just a few files. So this winds up being faster. Or did across a wide = swath of FreeBSD version 4-7. Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:39:10 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 99E30106566B; Tue, 8 Nov 2011 21:39:10 +0000 (UTC) Date: Tue, 8 Nov 2011 21:39:10 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20111108213910.GA42560@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> <20111108210905.GA28416@freebsd.org> <20111108212352.GA39160@freebsd.org> <20111108213253.GA31062@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108213253.GA31062@freebsd.org> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:39:10 -0000 On Tue Nov 8 11, Roman Divacky wrote: > On Tue, Nov 08, 2011 at 09:23:52PM +0000, Alexander Best wrote: > > On Tue Nov 8 11, Roman Divacky wrote: > > > clang will use "core2" for family=6 and model=15 > > > > > > check llvm/lib/Support/Host.cpp > > > > > > what is the problem? The fact that our gcc from the middle-ages > > > does not recognize that? > > > > actually a few months ago quite a lot of gcc commits happend to add newer > > optimisations (such as core2) to gcc and some commits aimed at modifying gcc, > > so it would make the best -march=native choice there is. > > > > what's the clang command (similar to gcc -march=native -E -v - > one can use to check what actual optimisation clang turns "native" into? > > clang -### -march=native will show something like otaku% clang -### -march=native FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: x86_64-unknown-freebsd9.0 Thread model: posix ? > > "-target-cpu" "k8-sse3" > > > > also there seem to be cross-compilation issues. when people are running i386 > > and want to cross-compile for amd64 and put CPUTYPE=core2 (or any other amd64 > > cpu) into their make.conf, this gets downgraded by bsd.cpu.mk to prescott. > > > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800 > > and > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html > > If gcc supports nocona now, the conf/84800 patch is ok. The same goes > with downgrading core2 -> prescott. > > I have no idea what gcc supports these days. I think we should just skip > the downgrading completely for clang as it either supports everything or > can be made easily to support what it doesnt. > > roman From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:39:48 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 760F81065673; Tue, 8 Nov 2011 21:39:48 +0000 (UTC) Date: Tue, 8 Nov 2011 21:39:48 +0000 From: Alexander Best To: Warner Losh Message-ID: <20111108213948.GB42560@freebsd.org> References: <20111108204912.GA34155@freebsd.org> <07EC4416-D366-4CD9-8655-CB89935B0354@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07EC4416-D366-4CD9-8655-CB89935B0354@bsdimp.com> Cc: freebsd-toolchain@freebsd.org Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:39:48 -0000 On Tue Nov 8 11, Warner Losh wrote: > > On Nov 8, 2011, at 1:49 PM, Alexander Best wrote: > > > hi there, > > > > any reason 'make cleanworld' does > > > > otaku% make cleanworld > > rm -rf /usr/obj/usr/git-freebsd-head/* > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > where > > > > otaku% make cleanworld > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > should be sufficient? > > chflags is a lot slower when it has to do an entire tree, rather than just a few files. So this winds up being faster. Or did across a wide swath of FreeBSD version 4-7. ahh thanks. haven't thought about that. :) > > Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:43:07 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B05B106566B; Tue, 8 Nov 2011 21:43:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6F58FC0A; Tue, 8 Nov 2011 21:43:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb] (unknown [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4FD405C59; Tue, 8 Nov 2011 22:43:06 +0100 (CET) Message-ID: <4EB9A268.5020805@FreeBSD.org> Date: Tue, 08 Nov 2011 22:43:04 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111108204912.GA34155@freebsd.org> In-Reply-To: <20111108204912.GA34155@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:43:07 -0000 On 2011-11-08 21:49, Alexander Best wrote: > any reason 'make cleanworld' does > > otaku% make cleanworld > rm -rf /usr/obj/usr/git-freebsd-head/* > chflags -R 0 /usr/obj/usr/git-freebsd-head > rm -rf /usr/obj/usr/git-freebsd-head/* > > where > > otaku% make cleanworld > chflags -R 0 /usr/obj/usr/git-freebsd-head > rm -rf /usr/obj/usr/git-freebsd-head/* > > should be sufficient? The first method is more efficient, because there are usually just a few files with schg flags set on them (zero even, if you build as a regular user). Suppose you have 30,000 files in /usr/obj, of which 20 have schg flags. The first method will unlink 29,980 files, failing on 20 of them. Then it will change flags on just 20 files, and lastly unlink those 20 files. Total number of 'operations' is 30,000 + 20 + 20 = 30,040. The second method will change flags on all 30,000 files, then unlink all 30,000 files. Total number of 'operations' is now 30,000 + 30,000 = 60,000. From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:55:49 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 42EB71065673; Tue, 8 Nov 2011 21:55:49 +0000 (UTC) Date: Tue, 8 Nov 2011 21:55:49 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111108215549.GA44260@freebsd.org> References: <20111108204912.GA34155@freebsd.org> <4EB9A268.5020805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB9A268.5020805@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 21:55:49 -0000 On Tue Nov 8 11, Dimitry Andric wrote: > On 2011-11-08 21:49, Alexander Best wrote: > > any reason 'make cleanworld' does > > > > otaku% make cleanworld > > rm -rf /usr/obj/usr/git-freebsd-head/* > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > where > > > > otaku% make cleanworld > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > should be sufficient? > > The first method is more efficient, because there are usually just a few > files with schg flags set on them (zero even, if you build as a regular > user). > > Suppose you have 30,000 files in /usr/obj, of which 20 have schg flags. > > The first method will unlink 29,980 files, failing on 20 of them. Then > it will change flags on just 20 files, and lastly unlink those 20 files. > Total number of 'operations' is 30,000 + 20 + 20 = 30,040. > > The second method will change flags on all 30,000 files, then unlink all > 30,000 files. Total number of 'operations' is now 30,000 + 30,000 = > 60,000. maybe the comment in /usr/src/Makefile could be updated to mention the efficiency aspect? right now it only says: # # This 'cleanworld' target is not included in TGTS, because it is not a # recursive target. All of the work for it is done right here. It is # expected that BW_CANONICALOBJDIR == the CANONICALOBJDIR as would be # created by bsd.obj.mk, except that we don't want to .include that file # in this makefile. # # In the following, the first 'rm' in a series will usually remove all # files and directories. If it does not, then there are probably some # files with chflags set, so this unsets them and tries the 'rm' a # second time. There are situations where this target will be cleaning # some directories via more than one method, but that duplication is # needed to correctly handle all the possible situations. Also this # another tought would be to do the following: find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} + rm/obj/usr/git-freebsd-head/* that should only execute chflags(1) on those files with flags set. cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 22:06:11 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBECE106564A; Tue, 8 Nov 2011 22:06:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD6F8FC15; Tue, 8 Nov 2011 22:06:11 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb] (unknown [IPv6:2001:7b8:3a7:0:e5f2:b2e3:287d:70bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CFAFF5C59; Tue, 8 Nov 2011 23:06:10 +0100 (CET) Message-ID: <4EB9A7D1.9030800@FreeBSD.org> Date: Tue, 08 Nov 2011 23:06:09 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111031 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> In-Reply-To: <20111108210420.GA37161@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 22:06:11 -0000 On 2011-11-08 22:04, Alexander Best wrote: ... > for me -march=native reports: > > otaku% gcc -march=native -E -v - Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic > #include "..." search starts here: > #include <...> search starts here: > /usr/include/gcc/4.2 > /usr/include > End of search list. > # 1 "" > # 1 "" > # 1 "" > # 1 "" > > where instead of nocona, core2 would have been the better choice: > > [1.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) > [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > [1.000000] Features=0xbfebfbff > [1.000000] Features2=0xe39d > [1.000000] AMD Features=0x20100800 > [1.000000] AMD Features2=0x1 > [1.000000] TSC: P-state invariant, performance statistics That's weird, the logic in gcc goes: cpuid (1, eax, ebx, ecx, edx); ... has_ssse3 = !!(ecx & bit_SSSE3); ... if (arch) { if (has_ssse3) cpu = "core2"; else if (has_sse3) { if (has_longmode) cpu = "nocona"; else cpu = "prescott"; } else if (has_sse2) cpu = "pentium4"; else if (has_cmov) cpu = "pentiumpro"; else if (has_mmx) cpu = "pentium-mmx"; else if (has_cmpxchg8b) cpu = "pentium"; else cpu = "i386"; } else cpu = "generic"; goto done; E.g. it seems to conclude your cpu *doesn't* have SSSE3, but does have long mode, and thus jumps to nocona. You might be able to debug this, by putting some printfs in this function. :) From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 22:26:18 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE4891065672; Tue, 8 Nov 2011 22:26:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 785238FC16; Tue, 8 Nov 2011 22:26:18 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA8MPDJU095062 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 15:25:15 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111108215549.GA44260@freebsd.org> Date: Tue, 8 Nov 2011 15:25:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03A12F28-FC6A-479F-9F94-A12E3D7EEE1F@bsdimp.com> References: <20111108204912.GA34155@freebsd.org> <4EB9A268.5020805@FreeBSD.org> <20111108215549.GA44260@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 08 Nov 2011 15:25:15 -0700 (MST) Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 22:26:18 -0000 On Nov 8, 2011, at 2:55 PM, Alexander Best wrote: > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} + > rm/obj/usr/git-freebsd-head/* >=20 > that should only execute chflags(1) on those files with flags set. THat's only faster if the entire directory tree says in the directory = cache. It isn't so much about chflags being called N times, but having = to look at N files twice. Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 22:39:24 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 088691065670; Tue, 8 Nov 2011 22:39:24 +0000 (UTC) Date: Tue, 8 Nov 2011 22:39:24 +0000 From: Alexander Best To: Warner Losh Message-ID: <20111108223924.GA50971@freebsd.org> References: <20111108204912.GA34155@freebsd.org> <4EB9A268.5020805@FreeBSD.org> <20111108215549.GA44260@freebsd.org> <03A12F28-FC6A-479F-9F94-A12E3D7EEE1F@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03A12F28-FC6A-479F-9F94-A12E3D7EEE1F@bsdimp.com> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 22:39:24 -0000 On Tue Nov 8 11, Warner Losh wrote: > > On Nov 8, 2011, at 2:55 PM, Alexander Best wrote: > > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} + > > rm/obj/usr/git-freebsd-head/* > > > > that should only execute chflags(1) on those files with flags set. > > THat's only faster if the entire directory tree says in the directory cache. It isn't so much about chflags being called N times, but having to look at N files twice. i think i got it now. ;) sorry for beeing so slow. i'll try to come up with a patch for Makefile, which mentions this in the comment. cheers. alex > > Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 22:49:14 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A65D51065674; Tue, 8 Nov 2011 22:49:14 +0000 (UTC) Date: Tue, 8 Nov 2011 22:49:14 +0000 From: Alexander Best To: Warner Losh Message-ID: <20111108224914.GA52935@freebsd.org> References: <20111108204912.GA34155@freebsd.org> <4EB9A268.5020805@FreeBSD.org> <20111108215549.GA44260@freebsd.org> <03A12F28-FC6A-479F-9F94-A12E3D7EEE1F@bsdimp.com> <20111108223924.GA50971@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108223924.GA50971@freebsd.org> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 22:49:14 -0000 On Tue Nov 8 11, Alexander Best wrote: > On Tue Nov 8 11, Warner Losh wrote: > > > > On Nov 8, 2011, at 2:55 PM, Alexander Best wrote: > > > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} + > > > rm/obj/usr/git-freebsd-head/* > > > > > > that should only execute chflags(1) on those files with flags set. > > > > THat's only faster if the entire directory tree says in the directory cache. It isn't so much about chflags being called N times, but having to look at N files twice. > > i think i got it now. ;) sorry for beeing so slow. i'll try to come up with a > patch for Makefile, which mentions this in the comment. thoughts? diff --git a/Makefile b/Makefile index 61e678b..5d053c2 100644 --- a/Makefile +++ b/Makefile @@ -185,7 +185,10 @@ buildworld: upgrade_checks # files with chflags set, so this unsets them and tries the 'rm' a # second time. There are situations where this target will be cleaning # some directories via more than one method, but that duplication is -# needed to correctly handle all the possible situations. +# needed to correctly handle all the possible situations. Getting rid +# of all files without chflags set in the first 'rm' instance saves us +# time, because now 'chflags' only needs to take the remaining files +# (those with chflags set) into account. # BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} cleanworld: > > cheers. > alex > > > > > Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 22:50:07 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5D61065672; Tue, 8 Nov 2011 22:50:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 384248FC14; Tue, 8 Nov 2011 22:50:05 +0000 (UTC) Received: by wwp14 with SMTP id 14so1493423wwp.31 for ; Tue, 08 Nov 2011 14:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MfRahDYnGQo+CjfHdd64nJRjiXdf+iXl0FINSJR0X28=; b=dzgfr6FKHQhs6/duiTqO/YEWviGtWtrbTucEnr2ch3WrWoMyp7BKUHSuXl0N4bbAj4 ayEydfden5HzcwvCqrN2H5i3aoLTICuqWcsXzsCWBwg2vkeyu6xFMiAdJVBT57Pg/bKR okdE/0Rec8Y/7ugmAt5QpRw6Jx4Stt/aLficQ= MIME-Version: 1.0 Received: by 10.180.100.34 with SMTP id ev2mr15068188wib.41.1320790753051; Tue, 08 Nov 2011 14:19:13 -0800 (PST) Received: by 10.180.8.34 with HTTP; Tue, 8 Nov 2011 14:19:13 -0800 (PST) In-Reply-To: <20111108215549.GA44260@freebsd.org> References: <20111108204912.GA34155@freebsd.org> <4EB9A268.5020805@FreeBSD.org> <20111108215549.GA44260@freebsd.org> Date: Tue, 8 Nov 2011 17:19:13 -0500 Message-ID: From: Ryan Stone To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: make cleanworld X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Nov 2011 22:50:07 -0000 On Tue, Nov 8, 2011 at 4:55 PM, Alexander Best wrote: > another tought would be to do the following: > > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} + > rm/obj/usr/git-freebsd-head/* As far as I can tell, the expensive part is not chflags, but walking the entire directory tree. Running find will still cause us to walk it twice. From owner-freebsd-toolchain@FreeBSD.ORG Wed Nov 9 07:15:06 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2AE106564A; Wed, 9 Nov 2011 07:15:06 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2A918FC0C; Wed, 9 Nov 2011 07:15:05 +0000 (UTC) Received: by iabz21 with SMTP id z21so2168563iab.13 for ; Tue, 08 Nov 2011 23:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=8fRyUpIqXAdEYkB3HJbEQn/rDThxRFif2fg+YnOfE0g=; b=cQOtFcz3yHG92tobqRPhSz6pU+vKs2uXo6HaaAkv94S5eHAEILZ/V1Kbj4RttPt9R9 2IwdgHxd1JYyCxZCR+GxbncL4wy+/eSdGqUD3gBTuUlJ9Q2r86aEe0MasdsSKbYZo5AI zVVCsBUmxGS+etBP/3I+4B7sRebHnZTLAf6Us= Received: by 10.50.202.100 with SMTP id kh4mr1137656igc.41.1320821528637; Tue, 08 Nov 2011 22:52:08 -0800 (PST) Received: from DataIX.net (adsl-99-181-144-127.dsl.klmzmi.sbcglobal.net. [99.181.144.127]) by mx.google.com with ESMTPS id fu10sm3088564igc.6.2011.11.08.22.52.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 22:52:06 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost.DataIX.local [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pA96q4hS057661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2011 01:52:04 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pA96q36w057660; Wed, 9 Nov 2011 01:52:04 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Wed, 9 Nov 2011 01:52:03 -0500 From: Jason Hellenthal To: Alexander Best Message-ID: <20111109064719.GA39458@DataIX.net> References: <20111108002556.GA91218@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108002556.GA91218@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 07:15:06 -0000 On Tue, Nov 08, 2011 at 12:25:56AM +0000, Alexander Best wrote: > hi there, > > i've seen dozens of issues, where people set CPUTYPE=native. although this > works in a lot of cases, it doesn't in others. why don't we simply add > something like I thought it was reccomened to use 'CPUTYPE?=' syntax therefore ultimately allowing the build to omit the CPUTYPE for its own setting... since not all optimizations done for -march or -mcpu are good for the whole source tree. From owner-freebsd-toolchain@FreeBSD.ORG Wed Nov 9 13:59:16 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 000C41065672; Wed, 9 Nov 2011 13:59:15 +0000 (UTC) Date: Wed, 9 Nov 2011 13:59:15 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111109135915.GA16834@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> <4EB9A7D1.9030800@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB9A7D1.9030800@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 13:59:16 -0000 On Tue Nov 8 11, Dimitry Andric wrote: > On 2011-11-08 22:04, Alexander Best wrote: > ... > > for me -march=native reports: > > > > otaku% gcc -march=native -E -v - > Using built-in specs. > > Target: amd64-undermydesk-freebsd > > Configured with: FreeBSD/amd64 system compiler > > Thread model: posix > > gcc version 4.2.2 20070831 prerelease [FreeBSD] > > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic > > #include "..." search starts here: > > #include <...> search starts here: > > /usr/include/gcc/4.2 > > /usr/include > > End of search list. > > # 1 "" > > # 1 "" > > # 1 "" > > # 1 "" > > > > where instead of nocona, core2 would have been the better choice: > > > > [1.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) > > [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > [1.000000] Features=0xbfebfbff > > [1.000000] Features2=0xe39d > > [1.000000] AMD Features=0x20100800 > > [1.000000] AMD Features2=0x1 > > [1.000000] TSC: P-state invariant, performance statistics > > That's weird, the logic in gcc goes: > > cpuid (1, eax, ebx, ecx, edx); > ... > has_ssse3 = !!(ecx & bit_SSSE3); > ... > if (arch) > { > if (has_ssse3) > cpu = "core2"; > else if (has_sse3) > { > if (has_longmode) > cpu = "nocona"; > else > cpu = "prescott"; > } > else if (has_sse2) > cpu = "pentium4"; > else if (has_cmov) > cpu = "pentiumpro"; > else if (has_mmx) > cpu = "pentium-mmx"; > else if (has_cmpxchg8b) > cpu = "pentium"; > else > cpu = "i386"; > } > else > cpu = "generic"; > goto done; > > E.g. it seems to conclude your cpu *doesn't* have SSSE3, but does have > long mode, and thus jumps to nocona. > > You might be able to debug this, by putting some printfs in this > function. :) same on ref9-amd64.freebsd.org: ref9-amd64% clang -march=native -### blabla.c FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: x86_64-unknown-freebsd9.0 Thread model: posix "/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd9.0" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "tower.c" "-mrelocation-model" "static" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "core2" "-momit-leaf-frame-pointer" "-resource-dir" "/usr/bin/../lib/clang/3.0" "-ferror-limit" "19" "-fmessage-length" "275" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/cc-ImChyq.o" "-x" "c" "tower.c" "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-o" "tower" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/cc-ImChyq.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" BUT ref9-amd64% gcc -march=native -E -v - search starts here: /usr/include/gcc/4.2 /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "" cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Thu Nov 10 20:47:22 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C79CD106566C; Thu, 10 Nov 2011 20:47:22 +0000 (UTC) Date: Thu, 10 Nov 2011 20:47:22 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20111110204722.GA85046@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: format string is not a string literal (potentially insecure) [-Wformat-security] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2011 20:47:22 -0000 hi there, clang outputs the following warning during 'make buildkernel': clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector-all /usr/git-freebsd-head/sys/kern/kern_conf.c /usr/git-freebsd-head/sys/kern/kern_conf.c:1019:45: warning: format string is not a string literal (potentially insecure) [-Wformat-security] ret = make_dev_alias_p(flags, cdev, pdev, devfspath); ^~~~~~~~~ does this indicate a security risk, which should be fixed or rather a bugus warning? cheers. alex