Re: Dimension attribute based on host-associated variable - bug in Intel Fortran

Arjen Markus wrote:
Rich Townsend schreef:

Hi all --

A question about what appears to be a bug in the Intel compiler: in a module
subroutine, I have declarations of the form

real, dimension(2*COUNT(spheres%inter)) :: lambda
real, dimension(COUNT(spheres%inter)) :: rho
integer, dimension(2*COUNT(spheres%inter)) :: indices
logical, dimension(COUNT(spheres%inter)) :: active_mask

The array spheres is accessed via host association, and is declared thusly:

type sphere_t
real, dimension(3) :: r = 0. ! Position vector
real :: l = 0. ! Radius
real :: rho = 0. ! Density
real :: lambda_in = 0. ! Ray entrance coordinate
real :: lambda_ex = 0. ! Ray exit coordinate
logical :: inter = .FALSE. ! Ray intersection flag
end type sphere_t

...

type(sphere_t), dimension(:), allocatable :: spheres

When I try to compile the code using Intel Fortran for Linux (9.1.40), I get the
following error messages:

fortcom: Error: sphimp_dda.f90, line 544: An array-valued argument is required
in this context. [COUNT]
real, dimension(2*COUNT(spheres%inter)) :: lambda
----------------------------^
fortcom: Error: sphimp_dda.f90, line 545: An array-valued argument is required
in this context. [COUNT]
real, dimension(COUNT(spheres%inter)) :: rho
--------------------------^
fortcom: Error: sphimp_dda.f90, line 546: An array-valued argument is required
in this context. [COUNT]
integer, dimension(2*COUNT(spheres%inter)) :: indices
-------------------------------^
fortcom: Error: sphimp_dda.f90, line 547: An array-valued argument is required
in this context. [COUNT]
logical, dimension(COUNT(spheres%inter)) :: active_mask

Now, as I understand it, there is nothing wrong with my code; spheres%inter is
an array-valued argument. Can I confirm that this is a bug in the Intel compiler?

I tried the following program with Intel Fortran 8.1 on Linux:

program sphereprogram
type sphere
logical :: has
end type sphere

type(sphere), dimension(3) :: spheres

spheres(1)%has = .false.
spheres(2)%has = .true.
spheres(3)%has = .false.
write(*,*) count(spheres%has)
end program

It seems perfectly happy, so I do think your version 9.1.40 is
misinterpreting
the code.

Regards,

Arjen


Hmmm, I can compile this program too, without problem. It seems that the error
message is triggered by the use of COUNT() in an automatic array declaration, as
David Frank has already surmised. I've tried my original code on Lahey lf95, and
it compiles without problem.

cheers,

RIch
.

Relevant Pages

  • Re: More on as-fast-as-C benchmarks
    ... On using Common Lisp for Scientific Computing ... foreign language interface to SBCL. ... After that, the compiler ... I believe that SMCL team could do something about declarations without ...
    (comp.lang.lisp)
  • Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and OpenVMS
    ... > running Linux and using an Intel compiler, the other running HP-UX, ... was more like 30% ahead of the Intel compiler back around the McKinley ... factor for EV7 over the same range, but I specifically referred to scaling ... configuration) SPECfp_rate score is only 8.78x that of the single-processor ...
    (comp.os.vms)
  • Re: Ommiting void
    ... easily avoid the issue by always declarating "int main". ... I do, however, also drop K&R style declarations, along with implicit ... If you don't want to support them in your compiler, that's fine, ... actually, in my case I seem not to mix well with moderators, as moderators necessarily reject my posts, and English teachers necessarily give me very low grades, even when my grammar and spelling is correct. ...
    (comp.std.c)
  • Re: Prototype or not prototype?
    ... in PDP-11 environments as well as Standard C environments, ... The code used a lot of function pointers and enum parameters ... K&R-style declarations or the C compiler had been able to root them out, ...
    (comp.std.c)
  • Re: POLL: about arguments of invariable type to methods
    ... I think the compiler can take advantage of it. ... declarations can be safely ignored by a Common Lisp implementation. ... #<Function FOO 4060010A2C> ... either type decls or specializers when you compile with different ...
    (comp.lang.lisp)