[Bug fortran/14957] [gfortran] testsuite issues

["Tobias dot Schlueter at physik dot uni-muenchen dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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