From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758802AbcEFUH7 (ORCPT ); Fri, 6 May 2016 16:07:59 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:24207 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758265AbcEFUH5 (ORCPT ); Fri, 6 May 2016 16:07:57 -0400 Subject: Re: linux/bitops.h To: "H. Peter Anvin" , John Denker , tytso@mit.edu, noloader@gmail.com, linux-kernel@vger.kernel.org, Stephan Mueller , Herbert Xu , andi@firstfloor.org, Sandy Harris , cryptography@lakedaemon.net, linux-crypto@vger.kernel.org References: <1462170413-7164-1-git-send-email-tytso@mit.edu> <1462170413-7164-2-git-send-email-tytso@mit.edu> <20160504174901.GC3901@thunk.org> <20160504190723.GD3901@thunk.org> <572A6CDD.10503@av8n.com> <572A724C.6010704@av8n.com> <572A9437.4020208@zytor.com> Cc: Linus Torvalds From: Sasha Levin Message-ID: <572CF971.9060100@oracle.com> Date: Fri, 6 May 2016 16:07:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <572A9437.4020208@zytor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2016 08:30 PM, H. Peter Anvin wrote: > On 05/04/16 15:06, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>> Beware that shifting by an amount >= the number of bits in the >>>> word remains Undefined Behavior. >> >>> This construct has been supported as a rotate since at least gcc2. >> >> How then should we understand the story told in commit d7e35dfa? >> Is the story wrong? >> >> At the very least, something inconsistent is going on. There >> are 8 functions. Why did d7e35dfa change one of them but >> not the other 7? > > Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the description even says so. No, the description says that it produces worse code for *really really* ancient GCC versions. > As I said, gcc has treated the former code as idiomatic since gcc 2, so that support is beyond ancient. Because something works in a specific way on one compiler isn't a reason to ignore this noncompliance with the standard. Thanks, Sasha