Request to improve docs: Fortran integer ranges vs. machine representation

[Elias Toivanen]

Hi,

I stumbled upon a Fortran quirk regarding the ranges for integers. The standard 
stipulates that the ranges be symmetric even though as we know two's complement 
signed integers have asymmetrical ranges, e.g. int8 kind can vary between -128 
and 127.

This is sure to cause confusion as for example the following program does not 
compile:

```
program main
  use iso_fortran_env
  implicit none
  print *, -128_int8
end program
```

GFortran 13.2.0 provides the error message

Error: Integer too big for its kind at (1). This check can be disabled with the 
option '-fno-range-check'
 
While a workaround to disable the range check is provided, the error message is 
a bit misleading. For one, the number is too small for the int8 number model. 
For the second, it is not obvious to the lay why removing the kind literal 
leads to a clean compile.

Codewise the topic has been discussed in PRs 13490 and 17912, and I think the 
current implementation is correct. What could be improved are the pages 
https://gcc.gnu.org/bugs/ and the above error message. 

I would like to propose that the error message should hint more towards the 
root cause. Something along the lines of: 'Out of range integer for its 
selected kind at (1). This check can be disabled with the option 
'-fno-range-check'.

Secondly, I think this quirk could be a good candidate to the known bugs 
section of your website.

I tried to file a bug / craft a PR but access to your repos is a bit limited at 
this point, so I decided to write this message as my 2 cents. 

Anyway, thanks for your good work! I can also volunteer to help you with this 
or some other tasks. Haven't done it before but would be interesting to try it 
out.

--
Best regards / Ystävällisesti
Elias Toivanen
elias.a.toiva...@gmail.com

Re: Request to improve docs: Fortran integer ranges vs. machine representation

[Elias Toivanen]

Guys, it's unproductive to discuss GFortran internals or the nuances of the 
standard with an end-user like me ;-)

AFAIK, the implementation is compliant and correct. My angle here was 
completely different. The question is whether this aspect of Fortran leads to 
confusion and subsequently to duplicate bug reports and other such noise, which 
is away from your precious time. If so, the way the error messages are worded 
and the way your docs are written play a crucial role in mitigating the issue.

Enabling the `-pedantic` flag in myself, in the listing (primary.cc:286 
<http://primary.cc:286/>) 

```
if (gfc_range_check (e) != ARITH_OK)
{
  gfc_error ("Integer too big for its kind at %C. This check can be "
 "disabled with the option %<-fno-range-check%>");

  gfc_free_expr (e);
  return MATCH_ERROR;
}
```

the if-block will be entered for any of the current and future error codes, 
while the error message only talks about the magnitude of the input.

If on the other hand you deem that working on this is not worth the effort, the 
issue is naturally resolved. 


--
Best regards / Ystävällisesti
Elias Toivanen
elias.a.toiva...@gmail.com


> On 27. Jan 2024, at 0.38, FX Coudert  wrote:
> 
>> Interesting example.
>> 
>> % gfcx -o z a.f90 &&  ./z
>> -128
>> % gfcx -o z -pedantic a.f90 && ./z
>> a.f90:5:20:
>> 
>>   5 |   data j /-128_int8/
>> |1
>> Error: Integer too big for its kind at (1). This check can be disabled with 
>> the option ‘-fno-range-check’
> 
> That qualifies as a compiler bug, I think. Our documentation for -pedantic 
> states: “Issue warnings for uses of extensions to Fortran.” and "Valid 
> Fortran programs should compile properly with or without this option.”
> 
> The same is true of the following, which is also valid Fortran since 95 :
> 
> use iso_fortran_env
> implicit none
> complex, parameter :: z = (-128_int8, -128_int8)
> print *, z
> end
> 
> Right now it fails to compile with -pedantic.
> 
> Or are they illegal because of how the range should be be symmetric? I can’t 
> quite find the language in the standard for that, actually. To me, they’re 
> valid signed-int-literal-constant.
> 
> FX
> 
> 
> PS: I’m going to ignore the cases of the P and DT edit descriptors, because 
> they’re not allowed to have a kind value, and therefore the corner cases 
> occur for values too big to be actually relevant to anything.