Bug 98445 - Bogus error: derived type used as an actual argument
Summary: Bogus error: derived type used as an actual argument
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 10.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-25 21:24 UTC by Rich Townsend
Modified: 2020-12-27 21:56 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-12-26 00:00:00

Attachments
Minimal working example (195 bytes, text/plain)
2020-12-25 21:24 UTC, Rich Townsend 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2020-12-25 21:24:38 UTC 
Created attachment 49844 [details]
Minimal working example

I'm running into what I believe to be a bogus error, when passing a function that (via interface overloading) has the same name as a derived type.

Attached is a MWE. When compiled, I get the error

passed_procedure_bug.f90:30:11:

   30 |     call s(t)
      |           1
Error: Derived type 't' is used as an actual argument at (1)

cheers,

Rich
Comment 1 anlauf 2020-12-26 11:01:00 UTC 
Can you explain when did this become valid?  And which compiler accepts this?

Intel v21 also rejects it with a similar error:

pr98445.f90(31): error #6478: A type-name must not be used as a variable.   [T]
    call s(t)
-----------^

plus some more.
Comment 2 Rich Townsend 2020-12-26 20:13:31 UTC 
I know it's acceptable to overload a type name with one or more functions -- from 12.4.3.4.1 of the F2008 standard,

"A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions."

In reading the rules for actual and dummy arguments (12.5.2), I don't see anything prohibiting a function-overloaded type name being passed in. However, I'm going to hit up comp.lang.fortran to see if I can get advice from one of the Fortran congnescenti.
Comment 3 Rich Townsend 2020-12-27 19:56:00 UTC 
OK, my code isn't valid -- it's not permitted to pass a generic procedure name as an actual argument. As such, gfortran is correct in its behavior.

Happy for this one to be closed -- sorry for the false alarm!
Comment 4 anlauf 2020-12-27 21:56:26 UTC 
OK, closing as invalid as suggested by the original submitter.