octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #54572] int64 does not saturate correctly in n


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54572] int64 does not saturate correctly in negative direction
Date: Tue, 28 Aug 2018 15:09:53 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Follow-up Comment #12, bug #54572 (project octave):

Producing a short stand-alone C program might be difficult, at least for me
since I don't know very well how the math operators are constructed.

FWIW, I'm attaching a sample program that goes down the path of attempting to
uncover a problem and/or testing how robust the GNU library routines for
hardware-overflow-check are to this issue.  It doesn't uncover anything
really, and it may not be a surprise since the routines could be something
much different from typically compiler behavior.  The program output here is:


@linux ~/octave/bug/54572 $ gcc -O2 -std=c++11 overflow_check.cc -lstdc++
@linux ~/octave/bug/54572 $ ./a.out32-bit decrement: -2147483648 ->
2147483647
64-bit decrement: -9223372036854775808 -> 9223372036854775807
32-bit subtract: -2147483648 - 1 = 2147483647 (overflow)
32-bit subtract: -2147483647 - 1 = -2147483648 (no overflow)
64-bit subtract: -9223372036854775808 - 1 = 9223372036854775807 (overflow)
64-bit subtract: -9223372036854775807 - 1 = -9223372036854775808 (no
overflow)
@linux ~/octave/bug/54572 $ gcc --versiongcc (Ubuntu 5.4.0-6ubuntu1~16.04.10)
5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


The problem from the standpoint of my comprehension is that integer arithmetic
typically wraps and I don't know how that is being addressed in the software. 
One method is to check before-hand if the operation will saturate by making
sure the difference between the saturation limit and first operand is greater
than the second operand (or something like that).  Another way might be some
type of C signal that catches overflows--if that is what is being used, I
could certainly imagine a C++ optimizing compiler bug that is failing to throw
that signal.

(file #44889)
    _______________________________________________________

Additional Item Attachment:

File name: overflow_check.cc              Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54572>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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