Re: [Tinycc-devel] Broken commit e460f7dbb216

[Vincent Lefevre]

On 2022-08-01 14:13:09 +0200, grischka wrote:
> On 30.07.2022 20:13, Vincent Lefevre wrote:
> > On 2022-07-30 19:48:29 +0200, grischka wrote:
> > > Sorry, what?  Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0)
> > > and with n == 0 -> (0 & -1) does not evaluate to 0 in both cases always
> > > necessarily, in C?
> > 
> > Yes, if the 0 happens to be a negative 0, 1 & 0 will give 1
> > in ones' complement, and 0 & -1 will also give non-zero in
> > both ones' complement and "sign and magnitude".
> 
> Okay, I was not thinking about that.  Still, nothing just "happens".
> 
> For example, 0 cannot "happen" to be a negative 0.  A negative 0
> needs to be generated, for example using the complement operator ~0.

Indeed, so that's not possible with n == 1, because 1 - 1 necessarily
generates a normal zero.

> We need to be precise.  When we are considering two cases, 1 and 0
> this clearly does not include a third case ~0.
> 
> What you maybe are trying to say is that we do not know whether
>     n = expr_const();
> could maybe return a negative zero on an imaginary platform.

Yes, but not an imaginary platform (this is in the standard because
such platforms existed). Rather an obsolete platform. According to
Wikipedia: "Many early computers, including the UNIVAC 1101, CDC 160,
CDC 6600, the LINC, the PDP-1, and the UNIVAC 1107, used ones'
complement arithmetic. Successors of the CDC 6600 continued to use
ones' complement arithmetic until the late 1980s, and the descendants
of the UNIVAC 1107 (the UNIVAC 1100/2200 series) still do, but the
majority of modern computers use two's complement." Concerning the
UNIVAC 2200 series, Wikipedia mentions "UNISYS ClearPath Dorado 8300
introduced in 2015". If it still uses ones' complement (at least for
compatibility), this is not that old. However, this probably doesn't
concern tcc (unless someone tries to port tcc on these systems). And
about sign-magnitude, there was IBM 7090 according to Wikipedia.

> However this is not about tcc, it is about our knowledge about tcc
> pr the platform.   If we were interested we could update our knowledge
> and then we would make sure that unexpected negative zeros can never
> happen.
> 
> In conclusion I think we did prove that in both the existing as well
> as the imaginary tcc, the additional "(n > 1 &&" clause is and will
> remain redundant and unnecessary.

While I agree that unnecessary conditions should be avoided, this
case is particular, because the values n = 0 and 1 are particular
cases when one seeks to check that the code is correct (well, for
n = 1, it depends, but n = 0 is really a particular case). So the
"n > 1" condition could help to understand the code without having
to look at the various cases more closely.

Note that there are common advises that add unnecessary code, such as

  if (i != 0)

instead of

  if (i)

when i is an integer. And

  if (a = b)

is strongly discouraged ("gcc -Wall" gives a warning).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)