[Bug fortran/14957] New: [gfortran] testsuite issues

[Bug fortran/14957] New: [gfortran] testsuite issues

[jv244 at cam dot ac dot uk]

1) noncompile : empty
2) execute

contains a few instances of incorrect or non-standard fortran (many accepted 
by ifc, but that's no reference). 

incorrect equivalence:
intrinsic_fraction_exponent.f90
intrinsic_set_exponent.f90
arguments of different kind to max:
intrinsic_minmax.f90
syntax error (subroutine missing?):
stack_varsize.f90
non-standard intrinsic (dcmplx):
cmplx.f90
incorrect length of character variables passed:
intrinisic_index.f90
intrinisic_trim.f90
f95:
st_function.f90, line 32: Subobject of constant not allowed in statement
function

several instances where e.g. an integer is passed to a subroutine expecting a 
real. In principle that is illegal (but very common, indeed).

-- 
           Summary: [gfortran] testsuite issues
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/14957] [gfortran] testsuite issues

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-14 17:40 -------
stack_varsize.f90:
   program STACK
     internal subroutine SUB1

   end
      ^
Error 74 at (20:pr14957.1.f90) : SUBROUTINE missing
     internal subroutine SUB2

   end
      ^
Error 74 at (29:pr14957.1.f90) : SUBROUTINE missing

2 Errors
compilation aborted for pr14957.1.f90 (code 1)

I think IFC is wrong here (please someone check with another fortran compiler).

intrinsic_minmax.f90:
It is complaining about "   if (max (4d0, r) .ne. 4d0) call abort" but this might have changed for 
fortran2003.

cmplx.f90:
maybe added to fortran2003 (or is it 2004).

st_function.f90:
"The statement function is obsolescent in Fortran 95"

intrinsic_index.f90:
 I get the warnings or errors with IFC.

intrinsic_trim.f90:
"
   program INTRINSIC_TRIM
  b=trim(a)
    ^
Warning 141 at (9:pr14957.6.f90) : Character string truncated to length 4 on assignment
   external function WORK
"

intrinsic_fraction_exponent.f90:
  equivalence (x, i), (y, j)
                          ^
Warning 23 at (8:pr14957.7.f90) : Equivalencing default and non-default numeric types is an extension 
to standard Fortran 95

Since I do not know fortran 77/90/95/2003 that well but remember IFC is not the compiler that all that 
ends all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-14 17:40:39
               date|                            |
   Target Milestone|---                         |tree-ssa


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

[Bug fortran/14957] [gfortran] testsuite issues

[jv244 at cam dot ac dot uk]

------- Additional Comments From jv244 at cam dot ac dot uk  2004-04-14 18:49 -------
> I think IFC is wrong here (please someone check with another fortran 
compiler).

FYI, all checked against NAG f95

> intrinsic_minmax.f90:
> It is complaining about "   if (max (4d0, r) .ne. 4d0) call abort" but this 
might have changed for 
> fortran2003.

no:
Arguments. The arguments shall all have the same type which shall be integer, 
real, or character and they shall all have the same kind type parameter. 


> cmplx.f90:
> maybe added to fortran2003 (or is it 2004).

2003 (and no). 

> st_function.f90:
> "The statement function is obsolescent in Fortran 95"
That's just a warning. The construct on line 32 is an error with NAG. But, I'm 
not an expert here.

> intrinsic_index.f90:
>  I get the warnings or errors with IFC.
> intrinsic_trim.f90:
> "
>    program INTRINSIC_TRIM
>   b=trim(a)
>     ^
> Warning 141 at (9:pr14957.6.f90) : Character string truncated to length 4 on 
assignment
>    external function WORK
> "
The real problem is
b=work(9,a) (a is of length 8, not 9). Similar in the above. "FORTRAN" is 7 
not 8 charachters.

> Since I do not know fortran 77/90/95/2003 that well but remember IFC is not 
the compiler that all that 
> ends all.

No, IFC is rather poor ;)
Thanks for your quick reply! A bug master worthy 

-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[jv244 at cam dot ac dot uk]

------- Additional Comments From jv244 at cam dot ac dot uk  2004-05-13 13:24 -------

> several instances where e.g. an integer is passed to a subroutine expecting a 
> real. In principle that is illegal (but very common, indeed).

In some cases it is also plain wrong. I would expect this tentative mini patch
to solve some testsuite failures :
RCS file:
/cvsroot/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_scale.f90,v
retrieving revision 1.2
diff -r1.2 intrinsic_scale.f90
7,8c7,8
<   call test_real4 (0, 3)
<   call test_real8 (0, 3)
---
>   call test_real4 (0., 3)
>   call test_real8 (0.0_8, 3)



-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-06-03 19:15 -------
(In reply to comment #0)
> incorrect equivalence:
> intrinsic_fraction_exponent.f90
> intrinsic_set_exponent.f90

Indeed, this could be achieved with TRANSFER instead. We don't seem to enforce
all restrictions on EQUIVALENCE, we might want to enforce them but allow a way
out via a language extension.
The problem is:
  INTEGER I
  REAL R
  EQUIVALENCE (R,I) ! not allowed, can only equivalence same basic type


> arguments of different kind to max:
> intrinsic_minmax.f90

This is a language extension. See the code in check.c:check_rest(). This
shouldn't pass with -pedantic.

> syntax error (subroutine missing?):
> stack_varsize.f90

Test passes here. Supposedly it's been fixed in the meantime.

> non-standard intrinsic (dcmplx):
> cmplx.f90

A language extension.

> incorrect length of character variables passed:
> intrinisic_index.f90
> intrinisic_trim.f90

True, this is a quality of implementation issue we should keep track of.

> f95:
> st_function.f90, line 32: Subobject of constant not allowed in statement
> function

Do you have a quote from the standard to back this? I couldn't find one.

> several instances where e.g. an integer is passed to a subroutine expecting a 
> real. In principle that is illegal (but very common, indeed).

Does it warn with -pedantic? It should.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


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

[Bug fortran/14957] [gfortran] testsuite issues

[jv244 at cam dot ac dot uk]

------- Additional Comments From jv244 at cam dot ac dot uk  2004-06-10 11:06 -------
(In reply to comment #4)
> (In reply to comment #0)

> > syntax error (subroutine missing?):
> > stack_varsize.f90
> 
> Test passes here. Supposedly it's been fixed in the meantime.

the point is actually that it shouldn't pass :-) 
both ifc and nag reject the code (line 20 should read: end subroutine sub1)

> 
> Do you have a quote from the standard to back this? I couldn't find one.
> 

No, this is an error from NAG f95. Normally a very good reference when it comes
to the standard, but I'm not sure why this wouldn't be allowed.


> > several instances where e.g. an integer is passed to a subroutine expecting a 
> > real. In principle that is illegal (but very common, indeed).
> 
> Does it warn with -pedantic? It should.

Well, the compiler can't easily check for this (e.g. subroutines in different
files) and if the data type don't have the same size it is really likely to be
an error, even if not pendantic. It is up to the programmer to get this right.
See also comment #3. I'm fairly sure such errors are the reasons for a number of
the (machine dependent) failures observed. 

-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de  2004-06-10 11:31 -------
Subject: Re:  [gfortran] testsuite issues

jv244 at cam dot ac dot uk wrote:
> ------- Additional Comments From jv244 at cam dot ac dot uk  2004-06-10 11:06 -------
> (In reply to comment #4)
> 
>>(In reply to comment #0)
> 
> 
>>>syntax error (subroutine missing?):
>>>stack_varsize.f90
>>
>>Test passes here. Supposedly it's been fixed in the meantime.
> 
> 
> the point is actually that it shouldn't pass :-) 
> both ifc and nag reject the code (line 20 should read: end subroutine sub1)
> 

Ah, ok. I checked the standard (p 208 of the draft F95 standard):
--------------
R1224 /end-subroutine-stmt/ *is* END [SUBROUTINE [/subroutine-name/ ]]

Constraint: SUBROUTINE shall be present in the /end-subroutine-stmt/ of 
an internal or module subroutine
...
--------------
the same goes for functions.


Re: "st_function.f90, line 32: Subobject of constant not allowed in 
statement function"
> 
>>Do you have a quote from the standard to back this? I couldn't find one.
>>
> No, this is an error from NAG f95. Normally a very good reference when it comes
> to the standard, but I'm not sure why this wouldn't be allowed.
> 

Can it be configured to output the relevant section of the standard? I 
looked through section 12.5.4 which defines statement functions and I 
didn't find anything which says this, but maybe I missed some subtlety.

>>>several instances where e.g. an integer is passed to a subroutine expecting a 
>>>real. In principle that is illegal (but very common, indeed).
>>
>>Does it warn with -pedantic? It should.
> 
> 
> Well, the compiler can't easily check for this (e.g. subroutines in different
> files) and if the data type don't have the same size it is really likely to be
> an error, even if not pendantic. It is up to the programmer to get this right.
> See also comment #3. I'm fairly sure such errors are the reasons for a number of
> the (machine dependent) failures observed. 

I don't think this is a problem, as we always pass C pointers to the 
referenced objects, and if these are of the same size, there shouldn't 
be problem. But nevertheless, it would be cleaner if we fixed the 
testcases. Unless those testcases were specifically meant to test the 
passing of integers in place of reals and vice versa.


-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[jv244 at cam dot ac dot uk]

------- Additional Comments From jv244 at cam dot ac dot uk  2004-06-10 11:52 -------

> Re: "st_function.f90, line 32: Subobject of constant not allowed in 
> statement function"
> > 
> >>Do you have a quote from the standard to back this? I couldn't find one.
> >>
> > No, this is an error from NAG f95. Normally a very good reference when it comes
> > to the standard, but I'm not sure why this wouldn't be allowed.
> > 
> 
> Can it be configured to output the relevant section of the standard? I 

Not as far as I know. What I get is :
Error: st_function.f90, line 32: Subobject of constant not allowed in statement
function


> I don't think this is a problem, as we always pass C pointers to the 
> referenced objects, and if these are of the same size, there shouldn't 
> be problem. 

i.e. comment #3 passing a integer*4 to a subroutine expecting a real*8 isn't Ok.



-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-06-10 12:18 -------
(In reply to comment #7)
> 
> i.e. comment #3 passing a integer*4 to a subroutine expecting a real*8 isn't Ok.
> 
> 
Sorry, I had missed that. Apparently, I didn't see that those subroutines are
external. I will commit a fix for this later today.

Thanks.

-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-06-10 12:35 -------
(In reply to comment #6)
> Ah, ok. I checked the standard (p 208 of the draft F95 standard):
> --------------
> R1224 /end-subroutine-stmt/ *is* END [SUBROUTINE [/subroutine-name/ ]]
> 
> Constraint: SUBROUTINE shall be present in the /end-subroutine-stmt/ of 
> an internal or module subroutine
> ...
> --------------
> the same goes for functions.
Patch here: http://gcc.gnu.org/ml/fortran/2004-06/msg00070.html

-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-06-10 12:41 -------
Subject: Bug 14957

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2004-06-10 12:41:33

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gfortran.fortran-torture/execute: 
	                                                intrinsic_scale.f90 

Log message:
	PR fortran/14957
	* gfortran.fortran-torture/execute/intrinsic_scale.f90: Make all
	arguments to test_* REAL and of the right size.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3837&r2=1.3838
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_scale.f90.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-06-10 12:47 -------
(In reply to comment #8)
> (In reply to comment #7)
> > 
> > i.e. comment #3 passing a integer*4 to a subroutine expecting a real*8 isn't Ok.
> > 
> > 
> Sorry, I had missed that. Apparently, I didn't see that those subroutines are
> external. I will commit a fix for this later today.

This didn't cause any failures, at least I couldn't find any on the
gcc-testresults mailing list, and it seems clear why: because the value passed
to the function is used in both calculations, so as long as the calculation
doesn't hit any denormals, overflows, etc., it should still work.

Anyway, this issue is fixed by the above commit.

-- 


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

[Bug fortran/14957] [gfortran] testsuite issues

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-06-12 15:02 -------
Subject: Bug 14957

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2004-06-12 15:02:01

Modified files:
	gcc/fortran    : ChangeLog decl.c 
	gcc/testsuite  : ChangeLog 
	gcc/testsuite/gfortran.fortran-torture/execute: 
	                                                stack_varsize.f90 

Log message:
	fortran/
	PR fortran/14957
	* decl.c (gfc_match_end): Require END {SUBROUTINE|FUNCTION} for
	contained procedure.
	
	testsuite/
	PR fortran/14957
	* gfortran.fortran-torture/execute/stack_varsize.f90: Correct
	syntax errors in end statements of contained subroutines.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.66&r2=1.67
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.8&r2=1.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3848&r2=1.3849
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/stack_varsize.f90.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


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

[Bug fortran/14957] testsuite issues

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.5.0                       |---


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

[Bug fortran/14957] testsuite issues

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-07-15 20:32 -------
I think all issues here have been resolved. Please re-open if there's something
I missed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/14957] testsuite issues

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.5.0


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