[Bug fortran/43310] New: -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[Bug fortran/43310] New: -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[giese025 at umn dot edu]

Easier to explain with a trivial piece of code...
PROGRAM BAR
  LOGICAL :: foo
  INTEGER,PARAMETER :: a = HUGE(1)
  INTEGER :: b
  b = HUGE(1)
  foo = NOT(a) >= 0  ! FAILS WITH -pedantic
  foo = NOT(b) >= 0  ! OK WITH -pedantic
END PROGRAM BAR

If -pedantic is used, then PARAMETERs appear to be handled differently
then if -pedantic is not used.
Moreover, this only seems to be an issue if the parameter is set to the result
of some other function, e.g., huge. 
Additionally, the program compiles as expected if the same code is used but
making the variable NOT a parameter.

This code snippet hasn't been a problem with intel nor nag compilers.
Nor is it a problem with gfortran if -pedantic is not used.

I would expect this to not be a problem with gfortran when -pedantic is used.

The error messege that I receive is

[name@host dir]$ gfortran -c -pedantic bar.f90
bar.f90:6.12:

  foo = NOT(a) >= 0  ! FAILS* WITH -pedantic
            1
Error: Result of NOT gives range error for its kind at (1)


My version

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)


-- 
           Summary: -pedantic errors on valid code involving PARAMETERs
                    initialized to intrinsic function result
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: giese025 at umn dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2010-03-09 19:40 -------
Don't use -pedantic.  It forces a symmetric range on
the integer type, [-huge():huge].  This can be checked
during constant folding, and NOT(A) is detected as an
error.  gfortran does not instrument the runtime code
for NOT(B), so it cannot detect that you are violating
the range of the pedantic integer type.  The GCC middle
end and back end do not enforce the symmetry of the range.

There was a long, long, long debate about this years ago
in the fortran@gcc.gnu.org mailing list.  See the archives
for details.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2010-03-09 20:45 -------
> Don't use -pedantic.  It forces a symmetric range on
> the integer type, [-huge():huge].

This should probably be documented. Probably after

Valid Fortran 95 programs should compile properly with or without this option.
However, without this option, certain GNU extensions and traditional Fortran
features are supported as well. With this option, many of them are rejected.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2010-03-09 21:06 -------
If one is trying to adhere to a Standard then use -std=.
-pedantic simply should not be used with gfortran.

As for documenting this, see arith.c, the PR's listed
there and the mailing list.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[giese025 at umn dot edu]

------- Comment #4 from giese025 at umn dot edu  2010-03-10 01:17 -------
(In reply to comment #3)
> If one is trying to adhere to a Standard then use -std=.
> -pedantic simply should not be used with gfortran.
> 
> As for documenting this, see arith.c, the PR's listed
> there and the mailing list.
> 

I think Dominique was referring to the documentation for the "regular people",
i.e., Sec. (4.3) from the gfortran manual, which is where his quote comes from,
and which was the quote that initially caused me to include -pedantic as one of
the flags that I (now previously) used when compiling with gfortran.

Sec. (4.3) should be changed so that

"Valid FORTRAN 95 programs should compile properly with or without this option.
However, without this option, certain GNU extensions and traditional Fortran
features are supported as well. With this option, many of them are rejected."

instead reads

"Not all valid FORTRAN 95 programs will compile properly when using this
option.  If you want to ensure compliance with one of the FORTRAN standards,
please see the -std= option."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2010-03-10 03:15 -------
(In reply to comment #4)

> 
> "Not all valid FORTRAN 95 programs will compile properly when using this
> option.  If you want to ensure compliance with one of the FORTRAN standards,
> please see the -std= option."
> 

The problem is that your program does not conform to
the Fortran 95 standard.  A program(mer) is forbidden
to call an intrinsic procedure if it returns a result
that is outside the representable range of the return 
trye.  When you specified -pedantic, you declared that
the representable range is [-huge():huge()], which is 
a strict interpretation of the model number representation
of an integer.  NOT(1) is invalid with -pedantic.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[giese025 at umn dot edu]

------- Comment #6 from giese025 at umn dot edu  2010-03-10 16:07 -------
(In reply to comment #5)
> (In reply to comment #4)
> 
> > 
> > "Not all valid FORTRAN 95 programs will compile properly when using this
> > option.  If you want to ensure compliance with one of the FORTRAN standards,
> > please see the -std= option."
> > 
> 
> The problem is that your program does not conform to
> the Fortran 95 standard.
> 

It compiles without error nor warning with
gfortran -std=f95 -Wall bar.f90

I'm not trying to sound argumentative here but you can't have it both ways...
so are you saying that this is really a problem with -std, as opposed to
-pedantic?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2010-03-10 17:17 -------
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > 
> > > 
> > > "Not all valid FORTRAN 95 programs will compile properly when using this
> > > option.  If you want to ensure compliance with one of the FORTRAN standards,
> > > please see the -std= option."
> > > 
> > 
> > The problem is that your program does not conform to
> > the Fortran 95 standard.
> > 
> 
> It compiles without error nor warning with
> gfortran -std=f95 -Wall bar.f90
> 
> I'm not trying to sound argumentative here but you can't have it both ways...
> so are you saying that this is really a problem with -std, as opposed to
> -pedantic?

The issue is with -pedantic.  It doesn't do what one may think
it does.  When one uses -pedantic, it will strictly enforce a
range of [-huge():huge()] on integer types.  Without -pedantic,
the range is [-huge()-1:huge()].  There are issues with either
choice of range.  You found one with NOT(1).  Another issue is
with IABS() and the most negative integer value.

If you're trying to enforce standard conformance use -std=f95.
-pedantic has too much baggage from times before gfortran was
in the tree. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2010-03-13 01:18 -------
Maybe we just need to document that -pedantic changes the range of integers to
be what the Fortran standard requires (a symmetric range).

> Not all valid FORTRAN 95 programs will compile properly when using this
> option. 

Except it is not a valid Fortran 95 program as the standard requires the ranges
to be symmetric.  (note to be picky only the F is uppercase for Fortran 95; the
last one which was all upper case was 77).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2010-03-13 03:52 -------
(In reply to comment #8)
> Maybe we just need to document that -pedantic changes the range of integers to
> be what the Fortran standard requires (a symmetric range).

The Fortran Standard requires neither a symmetric nor asymmetric
range.  It simply requires that a program(mer) cannot invoke an
intrinsic procedure that will return an out-of-range value.

program one
  integer i
  i = not(1)
end program one

is a valid Fortran 95 program if INTEGER has the range [-huge()-1:huge()]
(assuming a twos complement system). If the range is, however,
[-huge():huge()], then it is an invalid program.  Guess what happen
when the stupid option -pedantic is used?  It changes the range, and this
behavior is completely conforming.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-03-17 20:16 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Maybe we just need to document that -pedantic changes the range of integers to
> > be what the Fortran standard requires (a symmetric range).
> 
> The Fortran Standard requires neither a symmetric nor asymmetric
> range.

Well, the number model is symmetric. See Fortran 2003
(http://www.j3-fortran.org/doc/year/04/04-007.pdf):

"13.4 Numeric models" [...]
"The model set for integer i is defined by

  i = s * sum_{k=0}^{q-1} w_k * r^k

where r is an integer exceeding one, q is a positive integer, each wk is a
nonnegative integer less than r, and s is +1 or −1."

> It simply requires that a program(mer) cannot invoke an
> intrinsic procedure that will return an out-of-range value.

That can be found in "13.7 Specifications of the standard intrinsic
procedures":

"A program is prohibited from invoking an intrinsic procedure under cir10
cumstances where a value to be returned in a subroutine argument or function
result is outside the range of values representable by objects of the specified
type and type parameters, unless the intrinsic module IEEE ARITHMETIC (section
14) is accessible and there is support for an infinite or a NaN result, as
appropriate."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2010-03-17 21:31 -------
> Well, the number model is symmetric. See Fortran 2003 ...

I agree, but it is a very pedantic view that should at least be mentioned in
the manual. 
Now I think the implementation is not consistent:

[macbook] f90/bug% cat > ishft_1.f90
print *, ishft(1,31)
end
[macbook] f90/bug% gfc -Wall -pedantic ishft_1.f90
[macbook] f90/bug% a.out
 -2147483648


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2010-03-17 22:20 -------
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Maybe we just need to document that -pedantic changes the range of integers to
> > > be what the Fortran standard requires (a symmetric range).
> > 
> > The Fortran Standard requires neither a symmetric nor asymmetric
> > range.
> 
> Well, the number model is symmetric. 

You're preaching to the choir. ;)

Yes, the model number representation of integer is symmetric.
However, the representable range on integer does not have to
correspond to the model numbers.

function myabs(i)
  myabs = iabs(i)
end function myabs

function mynot(i)
  mynot = not(i)
end function mynot

Do these functions conform to the standard for all poosible
values of i? Careful with your answer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu dot org]

------- Comment #13 from kargl at gcc dot gnu dot org  2010-03-17 22:26 -------
(In reply to comment #11)
> > Well, the number model is symmetric. See Fortran 2003 ...
> 
> I agree, but it is a very pedantic view that should at least be mentioned in
> the manual.

You forgot to attach your patch.

> Now I think the implementation is not consistent:
> 
> [macbook] f90/bug% cat > ishft_1.f90
> print *, ishft(1,31)
> end
> [macbook] f90/bug% gfc -Wall -pedantic ishft_1.f90
> [macbook] f90/bug% a.out
>  -2147483648

gfc_simplify_ishft doesn't range check its result.
Patch welcomed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> What should be done with this two and a half year old PR?
> Apply the patch in comment #14 or closing it as INVALID or WONTFIX?

After more than two years without feedback closing as WONTFIX.

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-07-01

--- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
What should be done with this two and a half year old PR?
Apply the patch in comment #14 or closing it as INVALID or WONTFIX?

[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #14 from kargl at gcc dot gnu.org 2010-11-03 17:33:59 UTC ---
(In reply to comment #13)
> (In reply to comment #11)
> > > Well, the number model is symmetric. See Fortran 2003 ...
> > 
> > I agree, but it is a very pedantic view that should at least be mentioned in
> > the manual.
> 
> You forgot to attach your patch.
> 
> > Now I think the implementation is not consistent:
> > 
> > [macbook] f90/bug% cat > ishft_1.f90
> > print *, ishft(1,31)
> > end
> > [macbook] f90/bug% gfc -Wall -pedantic ishft_1.f90
> > [macbook] f90/bug% a.out
> >  -2147483648
> 
> gfc_simplify_ishft doesn't range check its result.
> Patch welcomed.

laptop:kargl[210] gfc4x -o z t.f90
laptop:kargl[211] ./z
 -2147483648
laptop:kargl[212] gfc4x -o z -pedantic t.f90
t.f90:1.14:

print*, ishft(1,31)
              1
Error: Result of ISHFT gives range error for its kind at (1)

Index: simplify.c
===================================================================
--- simplify.c  (revision 166091)
+++ simplify.c  (working copy)
@@ -3002,7 +3002,7 @@ simplify_shift (gfc_expr *e, gfc_expr *s
   convert_mpz_to_signed (result->value.integer, bitsize);
   gfc_free (bits);

-  return result;
+  return  range_check (result, name);
 }