Re: two complaints by Intel Fortran
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Thu, 6 Sep 2007 09:07:07 -0700
highegg <highegg@xxxxxxxxx> wrote:
when porting a gfortran-developed program to Intel today, I stumbled....
across two issues:
1. Intel (9.1.040 for AMD/Linux) consider two interfaces incompatible
if one has an overriden lower bound for array.
g95, gfortran and pathscale accept it. I suppose Intel is wrong,
according to 12.2.1.1 of F2003. Or was this different in F95?
Sounds like a compiler bug to me. The shape is a characteristic; the
bounds aren't. No change in this area since f90 that I can think of.
2. this happened when compiling an automatically generated source.
Intel (as well as g95, gfortran and pathscale) accepts an empty
generic interface, but unlike
the others it refuses to swallow a PUBLIC spec for it. Source:
module testm
implicit none
interface empty
! nothing here
end interface
public empty ! ERROR
end module
is rejected by Intel. I admit this _really_ is a corner case. I can't
figure this out from the standard.
The code looks fine to me. Another compiler bug. There are some syntax
forms that the standard doesn't allow to be empty. Mostly such
restrictions are pointless and prohibit perfectly sensible and useful
code. A few such restrictions have been removed in later versions of the
standard.
For example, there still seems to be a restriction against having a
CONTAINS with nothing after it; don't ask me why. (I though that one
went away with f2003, but it looks to still be there). That can be
useful for simplifying automatic code generation (or comparable rote
things done by hand).
Another example is a derived type with no components. That turns out to
be quite useful, common even, for inheritance, so I'm sure that one got
fixed in f2003. I'm not even going to go check - it better be fixed.
There were cases in f90/f95 where empty derived types could be useful,
but they were at least rare. With inheritance, they aren't rare.
Anyway, an empty interface block is fine in f95. See the bnf for
interface-block (R1201 in f95). See 1.6.2(3) for explanation of the bnf
form used. The explanation says that it may occur zero or more times.
There is certainly no justification at all for rejecting the public
statement. You won't find it in the standard because it isn't there.
I might add that I don't consider this to be that much of a corner case.
I can see uses for it, much like an empty extensible derived type. In
fact, I'd say the situations were similar. This allows you to define a
generic that has no specifics as yet, but will presumably be extended in
other scopes that USE this module.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.
- References:
- two complaints by Intel Fortran
- From: highegg
- two complaints by Intel Fortran
- Prev by Date: Re: read or write "how to convert integer to string?"
- Next by Date: Re: two complaints by Intel Fortran
- Previous by thread: two complaints by Intel Fortran
- Next by thread: Re: two complaints by Intel Fortran
- Index(es):
Relevant Pages
|
