Bug 13490 - Compiler rejects valid constant -2147483648 for 32-bit int
Summary: Compiler rejects valid constant -2147483648 for 32-bit int
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: tree-ssa
: P2 enhancement
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: patch, rejects-valid
: 16512 (view as bug list)
Depends on:
Blocks: 17912
  Show dependency treegraph
 
Reported: 2003-12-25 17:50 UTC by Scott Robert Ladd
Modified: 2004-10-28 21:48 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux
Target: i686-pc-linux
Build: i686-pc-linux
Known to work:
Known to fail:
Last reconfirmed: 2004-04-26 04:05:34


Attachments
An example the gfortran can't compile (133 bytes, text/plain)
2003-12-25 17:52 UTC, Scott Robert Ladd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Robert Ladd 2003-12-25 17:50:48 UTC
The attached program compiles and runs correctly with Intel Fortran 95 8.0 and
Lahey Fortran 95 6.1, but generates an error with gfortran. The error is:

In file parambug.f90:5
 
    integer(MY_KIND), parameter :: X = -2147483648
                                             1
Error: Arithmetic overflow at (1)
Comment 1 Scott Robert Ladd 2003-12-25 17:52:05 UTC
Created attachment 5370 [details]
An example the gfortran can't compile
Comment 2 Andrew Pinski 2003-12-25 17:54:26 UTC
Most likely what is happening is also happens in C that 2147483648 has to defined as an unsigned 
and then the negative is applied causing this error.
Comment 3 Scott Robert Ladd 2003-12-25 19:13:37 UTC
Fortran 95 uses GMP internally, while (as far as I know), the C compiler does
not. The following is a message I posted to the GNU Fortran 95 mailing list a
few minutes ago:

I reported the following as a bug, but after reading the gfortran source
code, I'm not entirely certain of my diagnosis.

This program compiles and exceutes with Lahey and Intel compilers, but
*not* with gfortran:

    program parambug
    implicit none

    integer, parameter :: MY_KIND  = SELECTED_INT_KIND(10)
    integer(MY_KIND), parameter :: X = -2147483648

    write (*,*) X

    end program parambug

The result of compiling with gfortran is:

     In file parambug.f90:5

    integer(MY_KIND), parameter :: X = -2147483648
                                             1
    Error: Arithmetic overflow at (1)

Looking at arith.c, I find this comment:

      mpz_init (int_info->min_int);
      mpz_neg (int_info->min_int, int_info->huge);
      /* No -1 here, because the representation is symmetric.  */


Yet I can't find anything in the Fortran 95 standard that supports the
contention that potitive and negative values are symmetric (as suggested
by the comment.

So is this a bug or not? It certainly is different from other Fortran 95
compilers... 
Comment 4 Paul Brook 2003-12-26 15:25:51 UTC
See 
http://gcc.gnu.org/ml/fortran/2003-12/msg00082.html 
Relevant section of (draft) F95 standard is 13.7.1 
Comment 5 Scott Robert Ladd 2003-12-26 19:01:27 UTC
gfortran is behaving correctly according to the Standard.

In reflection of interoperability needs, I've posted a patch to pcc-patches that
implements a new flag, -fasymmetrical-integers. This flag tells gfortran to
accept integers in the range [-n-1,n], whereas the standard requires the range
[-n,n].
Comment 6 Andrew Pinski 2004-07-13 16:23:41 UTC
*** Bug 16512 has been marked as a duplicate of this bug. ***
Comment 7 Scott Robert Ladd 2004-10-19 18:49:24 UTC
Posted a slightly revised patch, ten months after the first.
Comment 8 Andrew Pinski 2004-10-19 19:15:32 UTC
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01613.html>.
Comment 9 Scott Robert Ladd 2004-10-22 00:05:35 UTC
When this topic came up last year, I was in favor of gfortran working like other
Fortran 95 compilers, which accept minimum integer values of -(2**(n-1)).
Several Fortran language lawyers insisted that the default behavior should be to
reject such values, as they are not symmetrical across ABS() (a requirement
implied by the Standard.)

My previous patches for this problem have catered to the language lawyers by
adding a switch to enable "asymmetric" integers. I never liked doing it that way.

After a discussion with Tobias Schlüter, I've decided to present the following
patch, which causes gfortran to behave exactly like other Fortran 95 compilers.
For a -pedantic compile, gfortran will now display a warning about a potential
Standard violation.

This patch gives me warm fuzzies. The gods only know what the language lawyers
will think... :)

Bootstrapped and tested on i686-pc-linux and x86_64-pc-linux.

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01876.html
Comment 10 Scott Robert Ladd 2004-10-28 21:45:50 UTC
Patch committed after approval
Comment 11 GCC Commits 2004-10-28 22:25:22 UTC
Subject: Bug 13490

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	srladd@gcc.gnu.org	2004-10-28 22:25:18

Modified files:
	gcc/fortran    : ChangeLog 

Log message:
	Fix for PR fortran/13490, PR fortran/17912

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.239&r2=1.240

Comment 12 GCC Commits 2004-10-29 04:41:53 UTC
Subject: Bug 13490

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	billingd@gcc.gnu.org	2004-10-29 04:41:49

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gfortran.dg/g77: 20030326-1.f README 

Log message:
	2004-10-29  David Billinghurst <David.Billinghurst@riotinto.com>
	
	PR fortran/13490
	* gfortran.dg/g77/20030326-1.f: Change xfail on error to warning.
	* gfortran.dg/g77/README: Update.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4516&r2=1.4517
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/20030326-1.f.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/README.diff?cvsroot=gcc&r1=1.6&r2=1.7