[Bug fortran/92639] Error: Integer too big for its kind at (1)

2023-03-01 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639

--- Comment #4 from Steve Kargl  ---
On Wed, Mar 01, 2023 at 05:51:29PM +, cessenat at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
> 
> --- Comment #2 from Olivier Cessenat  ---
> integer(kind=4) valid range is -2147483648_4 to +2147483647_4.
> So I consider this is a gfortran bug.
> 
> Moreover, if -2147483648_4 is considered out of range, why
> -2147483647_4 - 1_4 is not ? Constant elimination makes it evaluated to 
> -2147483648_4.
> 
> I disagree with the term "there are no negative integers"
> [-2147483648_4 is equal to +2147483648_4]
   
  exceeds huge(1)
% cat a.f90
print *, huge(1)
end
% gfortran -o z a.f90 && ./z
  2147483647


I've already explained the issue.  But, I'll go over it
one more time.  -2147483648_4 is parsed as unary minus
operator and an operand of 2147483648_4.  2147483648_4
exceeds huge(1).  Fortunately, gfortran can save you,
and the error message even tells you.

1 | i = -2147483648_4
  | 1
Error: Integer too big for its kind at (1). This check can be
   disabled with the option '-fno-range-check'


So, let me amend the quote above "there are no negative
integer-literal constants."

[Bug fortran/92639] Error: Integer too big for its kind at (1)

2023-03-01 Thread jvdelisle at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
Please observe:

program demonstrate
  integer :: i
  i = huge(i)
  print *, i

  i= -huge(i)
  print *, i
end program

$ gfc demonstrate.f90 
$ ./a.out 
  2147483647
 -2147483647

This is by the fortran standard definition for a 32 bit integer.  You cannot
represent 2147483648 in 32 bits because you need bit 32 to represent the sign
of the value. How other compilers are storing the sign I can not speak to.

[Bug fortran/92639] Error: Integer too big for its kind at (1)

2023-03-01 Thread cessenat at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639

--- Comment #2 from Olivier Cessenat  ---
integer(kind=4) valid range is -2147483648_4 to +2147483647_4.
So I consider this is a gfortran bug.

Moreover, if -2147483648_4 is considered out of range, why
-2147483647_4 - 1_4 is not ? Constant elimination makes it evaluated to 
-2147483648_4.

I disagree with the term "there are no negative integers"
[-2147483648_4 is equal to +2147483648_4]

Other compilers, such as aocc, nvfortran, ifort, oneapi are OK with that

Thanks

[Bug fortran/92639] Error: Integer too big for its kind at (1)

2019-11-23 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Shubham Narlawar from comment #0)
> For below testcase, I ran on godbolt.org GFORTRAN trunk. Here are some
> observations - 
> 
> gfortran throws an error for BGE intrinsic when the value of one of
> parameter is -2147483648 which should not be according to permissible range
> of BGE, the maximum range for default kind is (-2147483648, 2147483647)
> 
> derived as -2^31 to 2^31 - 1
> 
> whereas x86-64 ifort 19.0.0 (Intel's fortran compiler) gives output without
> error.
> 
> 
> TESTCASE---
> 
> subroutine print_pass_fail(expected, actual)
> implicit none
>   logical :: actual, expected
>if ( actual .eqv. expected )then
> print *, "PASS"
>else
> print *, "FAIL"
> end if
> end subroutine print_pass_fail
> program bge_test_base
>   implicit none
>   logical :: index
>   index = BGE(127, -2147483648);
>   !print *, index
>   call print_pass_fail (.true.,index)
> end program

There are no negative integers.  There are integers and unary minus operator. 
This means that "-2147483648" is parse as "unary minus 2147483648".  2147483648
is too big for its kind.