[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] ZeroDivide bug in float printing
From: |
Holger Freyther |
Subject: |
Re: [Help-smalltalk] ZeroDivide bug in float printing |
Date: |
Fri, 29 Mar 2019 09:07:48 +0000 |
> On 29. Mar 2019, at 00:07, Derek Zhou <address@hidden> wrote:
>
> list,
>
thanks for looking into it!
> There were discussion on this list about this bug in the debian package:
Are you aware of:
http://git.savannah.gnu.org/cgit/smalltalk.git/commit/libgst/interp.inl?id=72ada189aba0283c551ead16635c1983968080b8
> Last night I tracked it down. It only happens with:
>
> * 64 bit arch
> * gcc 4.9.x
Why is this version of GCC used? What prevents the usage of GCC8? Can the
above be backported to the debian package? And let's get a new release out
of the door (maybe skip VisualGST...)
> The reason is smalltalk has to detect integer multiplication overflow
> reliably; and there were 3 ways in the code:
>
> 1. use __builtin_mul_overflow
> 2, see if the result is too big or too small
> 3, basically a * b / b == a ? OK : OVERFLOW
>
> gcc 5+ and clang use 1. 32 bit arch use 2. they all works. However, on
> gcc 4.9 and 64 bit it has to fall back to 3 which does not work. The
> reason is gcc is being overly smart and optimize it away. gcc does
> provide a switch "-fwrapv" to disable this optimization, but I am not
> sure what other thing it may cause and we dont want to get caught in the
> compiler shenanigan again in other compilers or other platform.
>
> I propose to change 3 into a more conservative and slower test
> such as:
>
> (MAX_ST_INT / abs(b)) < abs(a) ? OVERFLOW : OK
Overflow checking requires lots of thinking. E.g. have you considered
where abs(a) < 0? I would prefer if we can exclusively use the compiler
primitive.