From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jan 17 16:53:49 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id EF48F356C2F; Thu, 17 Jan 2013 16:53:48 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by www.open-std.org (Postfix) with ESMTP id ED865356932 for ; Thu, 17 Jan 2013 16:53:44 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUPgCv+LoagGtwo/I36HqKW/6m+HKz0vq@postini.com; Thu, 17 Jan 2013 05:55:14 PST Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.318.1; Thu, 17 Jan 2013 07:52:03 -0600 Message-ID: <50F80207.90904@cray.com> Date: Thu, 17 Jan 2013 07:52:07 -0600 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Chivers CC: 'sc22wg5' Subject: Re: [ukfortran] (SC22WG5.4899) (j3.2006) Comment on a comment on the WG5 letterballot on N1947 References: <20130108205438.50F4E356B56@www.open-std.org> <20130113210632.B1C67356BEA@www.open-std.org> <20130116050422.92E30356BE0@www.open-std.org> <20130116191114.A6A75356A2B@www.open-std.org> <003301cdf436$a0a80670$e1f81350$@chivers@chiversandbryan.co.uk> In-Reply-To: <003301cdf436$a0a80670$e1f81350$@chivers@chiversandbryan.co.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk 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@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