From owner-svn-src-head@freebsd.org Fri Jan 19 21:16:45 2018 Return-Path: Delivered-To: svn-src-head@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 9E720EC8E61 for ; Fri, 19 Jan 2018 21:16:45 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic316-9.consmr.mail.gq1.yahoo.com (sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.33]) (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 79CA675F58 for ; Fri, 19 Jan 2018 21:16:45 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: k5Y3hyUVM1mFfQXfZDxdtJYhXpMov7HLgqurUhJzeHtaMmPhlqK26Dh200tD.3u .Ejqdck7umSo8zasav.wvhtowen8bLs6L6fSxwwELsBa7PLWR7IH5MP8n3lttNmyp9zDk2ltPT72 QHvbvkNo4JgNgrkj57MM539eXIfLiBmQvPPTGIslZiQT79iSBe51ksDWg3PjHGfW1eUk8FFD_yTo t93jBEaipGwu0S2WJWBsUbHi_LQejIdmIy1B_TIBXDRZoA7JQs4z8xcf5eDD8pquT7HqS1HEStdF vCvYkdUmhGkPkPf3ncJaagKeI7qbZs7n_hTYrjUr0u1LFszpY0h9AzBxf.FMRp.Db5LxagjRf5ZJ t0yvfeLrBYPTIjaGHcPGjvS3ZCnEubOCtCWd_SpwIeGQDxy.HAjVCU1w5onARfsNKcxzRbtUJHN0 v9If8vkMkBi_aU0VWbGXgNLtctrew8ezj.YbW1J.TEafMNGqqZkZ6zG_KwhtZUOyowpdNYFxxeBP KswpMbQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Jan 2018 21:16:44 +0000 Received: from smtpgate104.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.215.136.172]) by smtp405.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 2f98a4c1431b1c279c08fa307227131f; Fri, 19 Jan 2018 20:46:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r328159 - head/sys/modules Message-Id: Date: Fri, 19 Jan 2018 12:46:22 -0800 To: Andriy Gapon , "Conrad E. Meyer" , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 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: Fri, 19 Jan 2018 21:16:45 -0000 Andriy Gapon avg at FreeBSD.org wrote on Fri Jan 19 18:41:07 UTC 2018 : > On 19/01/2018 20:30, Conrad Meyer wrote: > > On Fri, Jan 19, 2018 at 9:37 AM, Rodney W. Grimes > > wrote: > >> If you think in assembler it is easy to understand why this is UB, > >> most (all) architectures Right Logic or Arithmetic Shift only = accept an > >> operand that is a size that can hold log2(wordsize). > >=20 > > This is a logical right shift by a constant larger than the width of > > the left operand. As a result, it would a constant zero in any > > emitted machine code. It is a bug in the C standard and a = concession > > to naive, non-optimizing compilers that this is considered UB. > >=20 >=20 > Are you sure? > I seem to recall that the actual shift happens to be N % 32 for 32-bit = registers > (at least on some processors). >=20 > [Goes to check AMD Programmer's manual] >=20 > Ah, here you are: > The processor masks the upper three bits of the count operand, thus = restricting > the count to a number between 0 and 31. When the destination is 64 = bits wide, > the processor masks the upper two bits of the count, providing a = count in the > range of 0 to 63. It sounds to me that Conrad might want compile-time-constant shift distance cases to potentially produce different results than run-time-value cases for the same shift distance. Personally, I'm no fan of the same shift-distance value having a mix of having undefined behavior and well defined behavior based on if it is run-time vs. compile-time for when the value is known. C (and C++) made the choice to not require the run-time case to implicitly follow a more general rule (avoiding extra machine code) and then made compile-time-known cases the same. There may be other languages that require the run-time case to have whatever extra code is required despite the kinds of matching definitions that you quote. This too could keep run-time and compile-time uniform. Off the top of my head I do not remember running into a language that treated run-time and compile-time cases for the shift distance differently for the resultant, shifted value. But there may well be some. Mathematically, C and C++ are just not clean for the issue. But they would be even messier mathematically with the run-time versus compile-time distinction. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late)