(j3.2006) (SC22WG5.4906) [ukfortran] Comment on a comment on the WG5 letterballot on N1947

[Bill Long]

On 1/16/13 4:12 PM, Ian Chivers wrote:
> Integer overflow
> ================
>
> Hardware support
> ----------------
>
> Whilst the current IEEE standard doesn't say anything
> about integer arithmetic there is nothing to stop
> hardware manufacturers adding additional functionality
> to their hardware.
>

Yes, if they can justify the cost.  Some processors already include a 
"multiply-upper" integer multiply instruction that will return the upper 
64 bits of the 128-bit product (or half those sizes for 32-bit) which 
could be checked for zero in compiler-generated code as a mechanism for 
testing for overflow in multiplies.   Though it does not work for 
addition, it is at least a partial means for implementing a check.  (At 
a serious performance hit, of course.  But you would do this only for 
debugging.)

> There have also been processors that have supported
> integer overflow detection.
>

Yes, I recall the VAX had this.  Interesting, though, that the feature 
seems to have not caught on.


> possible with both of these compilers to switch
> range and sub range checking on.
>
> You could for example do something similar
> to the following
>
>    day    [1..31]
>    month  [1..12]
>    year   [1900..2000]
>
> and trap invalid days, month and year values.

This seems closer to "bounds" checking where you compare values to limit 
values, none of which involved hardware overflow.   With a derived type 
and procedures for assignment and operations, you could implement this 
sort of thing in Fortran.


> Simple Fortran example
> ----------------------
>
> The following trivial program illustrates
> integer overflow on most compilers.
>
> So Bill's claim that integer overflow
> never creates problems is not a claim
> I would agree with.
>

Well, I meant to say I had not seen it.  A sufficiently perverse 
programmer can always cause problems.

I assume this is a sample program from your "don't do this" bag for 
first-time programmers.

> program ch0504
> implicit none
> real :: Light_Minute, Distance, Elapse
> integer :: Minute, Second
> real , parameter :: Light_Year=9.46*10**12

This is a problem on a system with 32-bit integers as default.  A 
"teaching opportunity" example.  Though there is obviously a problem 
from looking at the output, it would be less obvious to the beginner 
what went wrong.

On the other hand, the example is also in conflict with another 
recommendation against mixed-type expressions.  And, once the class got 
to the "syntax for real constants" section, they would hopefully write 
the initialization as 9.46e12 and avoid the problem entirely.

Even so, it is a nice example.

>
> I worked in User Support from 1978-2001 helping debug other peoples
> programs.
> I've spent quite a lot of time chasing bugs in peoples code.
>

Basically my experience as well.

Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101