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. _______________________________________________ help-smalltalk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
