Home > Archive > Fortran > January 2006 > Disable Type Checking
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Disable Type Checking
|
|
|
| Hi All,
I'm not very familiar with fortran, but I need to compile
a fortran library to be used in for another program. I'm
getting the following error that halts the compilation of
the library:
---------------------------------------------------------
CALL DMUMPS_185( id )
^
cf90-1108 f90fe64: ERROR DMUMPS_142, File = dmumps_part5.F,
Line = 3604, Column = 26 The type of the actual argument,
"type(DMUMPS_STRUC)", does not match "type(DMUMPS_STRUC)",
the type of the dummy argument."
----------------------------------------------------------
What I'm guessing is that the code is legacy that is not
type-checked, while mpif90 is trying to perform strong
type-checking. Is there a way to disable type-checking
on mpif90 to see if that will resolve the issue? I'm using
Absoft mpif90.
Thanks.
| |
| Michael Metcalf 2006-01-13, 7:01 pm |
|
"A. A." <dont@spam.com> wrote in message news:opWxf.446$sq.333@trnddc01...
>
> What I'm guessing is that the code is legacy that is not
> type-checked, while mpif90 is trying to perform strong
> type-checking. Is there a way to disable type-checking
> on mpif90 to see if that will resolve the issue? I'm using
> Absoft mpif90.
>
This looks less like legacy code than recent code where a derived data type
is defined in two places, thereby creating, inadvertently, two identical but
incompatible types.
Hope that helps,
Mike Metcalf
| |
|
| Michael Metcalf wrote:
> This looks less like legacy code than recent code where a derived data type
> is defined in two places, thereby creating, inadvertently, two identical but
> incompatible types.
Thank you for your insight, Mike. The strange thing that the
code compiles on one intel ifort compiler, but not on Absoft
mpif90 compiler! The ifort compiler is not compatible with
our cluster, though, so I cannot use it. If a data type is
defined twice, shouldn't the two compilers complain about it?
I did a grep for "TYPE DMUMPS_STRUC" in the whole source
package, but only found one definition of TYPE DMUMPS_STRUC.
Where could be the other source of TYPE DMUMPS_STRUC exist
if only one definition can be found in the package?
The package is MUMPS (http://graal.ens-lyon.fr/MUMPS). I
emailed the developers about this compilation error, but
haven't heard back yet. I think they use intel compiler,
which doesn't cause this error.
Thanks.
| |
| Ken Plotkin 2006-01-13, 9:57 pm |
| On Sat, 14 Jan 2006 00:18:35 GMT, "A. A." <dont@spam.com> wrote:
[snip]
>I did a grep for "TYPE DMUMPS_STRUC" in the whole source
>package, but only found one definition of TYPE DMUMPS_STRUC.
>Where could be the other source of TYPE DMUMPS_STRUC exist
>if only one definition can be found in the package?
[snip]
Make sure that the type definition is known to all program uints that
use it (usually by being defined in a module used by all) and that
there is a type statement for the variables that are supposed to be
that type.
Grep TYPE and separately grep DMUMPS_STRUCT (wouldn't hurt to do grep
-i) and see what turns up.
Ken Plotkin
| |
| Bil Kleb 2006-01-14, 7:57 am |
| A. A. wrote:
> Michael Metcalf wrote:
>
>
> Thank you for your insight, Mike. The strange thing that the
> code compiles on one intel ifort compiler, but not on Absoft
> mpif90 compiler! The ifort compiler is not compatible with
> our cluster, though, so I cannot use it.
I found almost the exact problem just yesterday: I accidentally
introduced duplicate type definitions, and Lahey-Fujitsu 6.2
complained while Intel 9.0 did not.
> If a data type is
> defined twice, shouldn't the two compilers complain about it?
I think so.
But, to try to make up for the fact that they do not, we
regularly compile our code on nearly every Fortran compiler
made. As a consequence, we've managed to find at least one
bug in every compiler, save Lahey-Fujitsu.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
| |
|
| Ken Plotkin wrote:
> On Sat, 14 Jan 2006 00:18:35 GMT, "A. A." <dont@spam.com> wrote:
>
> Make sure that the type definition is known to all program uints that
> use it (usually by being defined in a module used by all) and that
> there is a type statement for the variables that are supposed to be
> that type.
I did something that allowed the file to compile, but not sure if
it's the right thing to do. The subroutine named DMUPS_185 called
from another subroutine named DMUPS_142. The line where DMUPS_185
is called in DMUPS_142 is where the error occurs. DMUPS_185 is
defined in a module named DMUMPS_LOAD. So there is a "USE DMUMPS_LOAD"
statement in DMUPS_142. I removed that statement and the file
compiled! This doesn't make sense to me. How does DMUPS_142 know
about DMUPS_185 and compiles successfully if I removed the
"USE DMUMPS_LOAD" statement where DMUPS_185 is defined?
I didn't link all the files to build the library yet. Trying to
resolve other issues. But do you think that the library will not
link because I removed that statement?
Thanks.
| |
|
| Bil Kleb wrote:
> I found almost the exact problem just yesterday: I accidentally
> introduced duplicate type definitions, and Lahey-Fujitsu 6.2
> complained while Intel 9.0 did not.
I come from the c/c++ world. When a type is defined twice,
the compiler tells you where it was defined first. I spent
a couple of days now to figure out where the mipf90 compiler
thinks the first definition of MUMPS_STRUC is, without any
luck! I can only find one definition of it by inspection.
Is there a more standard procedure through the compiler or
debugger or otherwise to find where a type is first define
in a Fortran program?
Thanks.
| |
| Michael Metcalf 2006-01-14, 6:58 pm |
|
"A. A." <dont@spam.com> wrote in message news:fn9yf.6513$Di.2175@trnddc06...
> Ken Plotkin wrote:
>
> I did something that allowed the file to compile, but not sure if
> it's the right thing to do. The subroutine named DMUPS_185 called
> from another subroutine named DMUPS_142. The line where DMUPS_185
> is called in DMUPS_142 is where the error occurs. DMUPS_185 is
> defined in a module named DMUMPS_LOAD. So there is a "USE DMUMPS_LOAD"
> statement in DMUPS_142. I removed that statement and the file
> compiled! This doesn't make sense to me. How does DMUPS_142 know
> about DMUPS_185 and compiles successfully if I removed the
> "USE DMUMPS_LOAD" statement where DMUPS_185 is defined?
>
This really does look like a compiler bug. When you remove the USE, you
would apperar to make an explicit interface into an implicit one. Then there
is no error checking (but probably an error!). The compiler is perhaps
 somehow with the type definition mechanism in this case. You could
try to put the type definition into a module all by itself, and use that
module in DMUMPS_LOAD and wherever else necessary.
Hope that helps,
Mike Metcalf
| |
|
| Michael Metcalf wrote:
> This really does look like a compiler bug. When you remove the USE, you
> would apperar to make an explicit interface into an implicit one. Then there
> is no error checking (but probably an error!). The compiler is perhaps
> somehow with the type definition mechanism in this case. You could
> try to put the type definition into a module all by itself, and use that
> module in DMUMPS_LOAD and wherever else necessary.
I think I found what the problem is this time, but don't know how
to resolve it. Bascially, the mpif90 compiler seems not to like
derived types to be passed in subroutine calls. When I changed
the subroutine parameter from derived type DMUMPS_STRUC to INTEGER,
the file compiled witout any errors. The problem, though, is that
I need to pass the derived type, not the simple intrinsic integer
type. Is there a way to cast DMUMPS_STRUC to some sort of intrinsic
typein the caller subroutine, pass it, then cast it back to
DMUMPS_STRUC in the callee subroutine?
Thanks.
| |
| Michael Metcalf 2006-01-14, 6:58 pm |
|
"A. A." <dont@spam.com> wrote in message news:WRcyf.1259$he.194@trnddc03...
> Michael Metcalf wrote:
> type. Is there a way to cast DMUMPS_STRUC to some sort of intrinsic
> typein the caller subroutine, pass it, then cast it back to
> DMUMPS_STRUC in the callee subroutine?
>
Yes. Given
module m
type t
integer :: i
real :: r
end type t
end module m
use m
type(t) thing
call s(thing)
:
subroutine s(x)
use m
type(t) x
you can replace the last few lines with
call s(thing%i, thing%r))
:
subroutine s(xi, xr)
integer :: xi
all untested.
Hope that helps,
Mike Metcalf
real :: xi
| |
|
| "A. A." <dont@spam.com> wrote in message news:opWxf.446$sq.333@trnddc01...
>
> I'm not very familiar with fortran, but I need to compile
> a fortran library to be used in for another program. I'm
> getting the following error that halts the compilation of
> the library:
>
> ---------------------------------------------------------
> CALL DMUMPS_185( id )
> ^
> cf90-1108 f90fe64: ERROR DMUMPS_142, File = dmumps_part5.F,
> Line = 3604, Column = 26 The type of the actual argument,
> "type(DMUMPS_STRUC)", does not match "type(DMUMPS_STRUC)",
> the type of the dummy argument."
> ----------------------------------------------------------
You will beed to look at DMUMPS_185 source to see what the
structure of the dummy argument is. There is no point in passing
something that doesn't match the dummy argument.
> What I'm guessing is that the code is legacy that is not
> type-checked, while mpif90 is trying to perform strong
> type-checking. Is there a way to disable type-checking
> on mpif90 to see if that will resolve the issue? I'm using
> Absoft mpif90.
| |
|
| Mike,
Thank you very much for taking the time to write this code.
While digging into Absoft compiler documentation, I found
a comment about using user-defined types within modules in
addition to using the SEQUENCE modifier. So, I copied the
code in all the header files with the derived type definition
into a loadable module file then loaded that module instead
of including the header file. This seems to have resolved
the issue for now as all files are compiling without an error.
Not sure if that's considered to be a bug, or a strict
implementation of the standards. But obviously, other compilers
only requires either the use of MODULE or SEQUENCE to work, but
not both as is the case with Absoft Fortran.
Just thought to mention this out in case other people come
across the same problem.
Thanks once again for your insight and assistance!
-ammar
Michael Metcalf wrote:
> "A. A." <dont@spam.com> wrote in message news:WRcyf.1259$he.194@trnddc03...
> Yes. Given
>
> module m
> type t
> integer :: i
> real :: r
> end type t
> end module m
>
> use m
> type(t) thing
> call s(thing)
> subroutine s(x)
> use m
> type(t) x
>
> you can replace the last few lines with
>
> call s(thing%i, thing%r))
> subroutine s(xi, xr)
> integer :: xi
>
> all untested.
>
> Hope that helps,
> Mike Metcalf
> real :: xi
| |
| Michael Metcalf 2006-01-15, 7:12 pm |
|
"A. A." <dont@spam.com> wrote in message
news:pwfyf.12239$sq.9250@trnddc01...
> Mike,
>
> Thank you very much for taking the time to write this code.
>
> While digging into Absoft compiler documentation, I found
> a comment about using user-defined types within modules in
> addition to using the SEQUENCE modifier. So, I copied the
> code in all the header files with the derived type definition
> into a loadable module file then loaded that module instead
> of including the header file. This seems to have resolved
> the issue for now as all files are compiling without an error.
>
> Not sure if that's considered to be a bug, or a strict
> implementation of the standards. But obviously, other compilers
> only requires either the use of MODULE or SEQUENCE to work, but
> not both as is the case with Absoft Fortran.
>
Ah, ha! That is indeed the problem. The type has to be defined in a module
that is used where appropriate. If the type definition is in an INCLUDE
file, that is merely a text substitution and each include generates an
identical but different type! Lesson: avoid include wherever possible.
Regards,
Mike Metcalf
|
|
|
|
|