help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Make check on FreeBSD 10.x - Intel


From: nicolas cellier
Subject: Re: [Help-smalltalk] Make check on FreeBSD 10.x - Intel
Date: Thu, 21 May 2015 20:00:18 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Holger Freyther <holger <at> freyther.de> writes:

> 
> 
> > On 16 Apr 2015, at 01:14, Holger Freyther <holger <at> freyther.de> wrote:
> 
> > Our mul_with_check doesn’t properly detect the overflow on a multiplication
> > like (380536542838076625 * 576687883419648000) printNl. The result is
> > negative. I don’t have a fix yet but that is easy now. We need to review the
> > other routines with an overflow check too. We run the tests on travis-ci so
> > I wonder how intmax_t is different between  BSD and GNU.
> 
> the compiler optimizes the overflow check away. Shall we move to use a
> routine like __builtin_mul_overflow (if it is available)?
> 
> The below is taken from GNU Smalltalk to see what is happening. With clang
> from apple (Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM
3.6.0svn))
> generates different output depending on -O0 vs. -O3.
> 
> result / b == a seems to be considered always true by the compiler. I
don’t know
> the C specification but I assume that “a * b” is assumed to never overflow
so that
> the result of “a * b / b” is certainly “a”. 
> 

That's exactly it. Overflow is undefined behavior.
The C compiler has a license to ignore undefined behavior because you are
not suppose to rely on it.

See for example
http://smallissimo.blogspot.fr/2015/04/the-more-or-less-defined-behavior-we.html
where I explain a similar problem in Squeak VM.

And see a fix in
http://smallissimo.blogspot.fr/2015/04/removing-ub-in-bytecodeprimmultiply.html.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]