[RFA] PR 81552 -finit-integer=n is restricted to 32-bit INTEGER

[Dominique d'Humières]

Hi Janne,

Thanks for the answer.

> Le 11 févr. 2019 à 11:59, Janne Blomqvist <blomqvist.janne@gmail.com> a écrit :
> 
> On Mon, Feb 11, 2019 at 12:41 PM Dominique d'Humières <dominiq@lps.ens.fr> wrote:
> I see two possibilities:
> 
> (1) Document the restriction by replacing
> 
> … by the -finit-integer=n,…
> 
> with something such as
> 
> … by the -finit-integer=n (if the value of n is outside the range of INTEGER, it is wrapped around,
> for KIND=8 and above, the wrapping is done for INTEGER(4)), …
> 
> and close the PR as WONTFIX.
> 
> (2) Extend -finit-integer to INTEGER(8) using the analysis in the PR with the following patch
> 
> …

> (3) Extend -finit-integer to INTEGER(16) if available.
> 
> (4) Always clip the value to -HUGE(1_k)-1 or HUGE(1_k) for INTERGER(k) (IMO it is probably the behavior expected by users).
> 
> While I can handle alone (1) or (2), Il’d need help for (3) or (4).
> 
> Any opinion, comment?
> 
> I agree that ideally we should do (4), but I'm sceptical whether the use of it is worth the effort. I'd go for (2), with a couple caveats:
> 
> a) On win64, long is a 32-bit type, so this won't help there. There is atoll (long long), except it's not present in win64. I'd just say, eh, if somebody is interested in improving win64 support and has access to that target, they are free to contribute.

For 9.1, I’ll commit (1) leaving the PR opened until the end of the year. At that time, if the PR is stil unassigned, I’ll close it as WONTFIX.

Dominique

> b) Might be better to use strtol() instead of atol(), and check for errors. So one could catch things like '-finit-integer=1abc234'.
> 
> -- 
> Janne Blomqvist