Date: Fri, 19 Jan 2018 12:46:22 -0800 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Andriy Gapon <avg@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r328159 - head/sys/modules Message-ID: <D22B97EE-A3A7-491E-BBDC-09DD938C1058@yahoo.com>
next in thread | raw e-mail | index | archive | help
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 > > <freebsd at pdx.rh.cn85.dnsmgr.net> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D22B97EE-A3A7-491E-BBDC-09DD938C1058>