Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

array definition: warning desired

Johannes_Rieke
New Contributor III
354 Views

Hi,

the following code is accepted by ifort 17.0.1. A warning or error for line 6 would be perfect. The contradictory double definition in line 9 is checked and an error is given, but line 6 is accepted.

program array_definition
  use ISO_FORTRAN_ENV, only : rk => real64
  implicit none
  
  ! Variables
  real(rk), dimension(10) :: foo(10)  ! this shouldn't work, should it? --> no error or warning is given
  
  
  !real(rk), dimension(10) :: foo(20)  ! this shouldn't work also! And it works not...
  !  1>------ Build started: Project: array_definition, Configuration: Debug Win32 ------
  !  1>Compiling with Intel(R) Visual Fortran Compiler 17.0.1.143 [IA-32]...
  !  1>array_definition.f90
  !  1>D:\02_Fortran\99_test\array_definition\array_definition.f90(7): error #6417: The dimensions of this array have been defined more than once.   [FOO]
  !  1>D:\02_Fortran\99_test\array_definition\array_definition.f90(6): remark #7712: This variable has not been used.   [FOO]
  !  1>compilation aborted for D:\02_Fortran\99_test\array_definition\array_definition.f90 (code 1)
  
end program array_definition

Maybe it is easy to implement?

Kind regards, Johannes

0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
354 Views

Yes, it's a compiler bug.  In both cases the array specification attached to the variable overrides the DIMENSION. Confusing for the reader, to be sure.

The same principle applies to character lengths. For example:

character(10) :: foo*20

The (10) is overridden by the *20.

Intel Fortran gets this one right.

View solution in original post

15 Replies
Steve_Lionel
Black Belt Retired Employee
354 Views

The standard allows this explicitly:

The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, except that the DIMENSION attribute may be specified or overridden for an entity by the appearance of array-spec in its entity-decl, and the CODIMENSION attribute may be specified or overridden for an entity by the appearance of coarray-spec in its entity-decl.

This is the sort of thing I have advocated putting under a "usage warnings" option - usage that is legal but is questionable or prone to issues (such as mixed-mode arithmetic).

jimdempseyatthecove
Black Belt
354 Views

>>The standard allows this explicitly

Then the error message when the dimension did not match is wrong. When

real(rk), dimension(10) :: foo(20)

used.

Jim Dempsey

Steve_Lionel
Black Belt Retired Employee
354 Views

Yup.

Johannes_Rieke
New Contributor III
354 Views

Thanks Steve and Jim,

I agree Jim. This works without warning:

  real(rk), dimension(20) :: foo(10)  ! this shouldn't work, should it? --> a warning is given
  write(*,*) size(foo)                ! -> 10
  !  1>------ Build started: Project: array_definition, Configuration: Debug Win32 ------
  !  1>Compiling with Intel(R) Visual Fortran Compiler 17.0.1.143 [IA-32]...
  !  1>array_definition.f90

But the other way round an error is thrown:

real(rk), dimension(10) :: foo(20)  ! this shouldn't work also! And it works not...
  !write(*,*) size(foo)                ! -> should be 20
  !  1>------ Build started: Project: array_definition, Configuration: Debug Win32 ------
  !  1>Compiling with Intel(R) Visual Fortran Compiler 17.0.1.143 [IA-32]...
  !  1>array_definition.f90
  !  1>   \array_definition.f90(7): error #6417: The dimensions of this array have been defined more than once.   [FOO]
  !  1>   \array_definition.f90(6): remark #7712: This variable has not been used.   [FOO]
  !  1>compilation aborted for    \array_definition\array_definition.f90 (code 1)

Is this an compiler issue?

Best regards, Johannes

Steve_Lionel
Black Belt Retired Employee
355 Views

Yes, it's a compiler bug.  In both cases the array specification attached to the variable overrides the DIMENSION. Confusing for the reader, to be sure.

The same principle applies to character lengths. For example:

character(10) :: foo*20

The (10) is overridden by the *20.

Intel Fortran gets this one right.

View solution in original post

Johannes_Rieke
New Contributor III
354 Views

Hi Steve, dear all,

that's good to know. Hopefully this misleading functionality will be erased from the standard in future. Can anyone imagine what this is good for? Especially in case of the character length definition it seems to me extremely strange. I thought

character(len=10) :: foo

is the 'newer' one than

character :: foo*10

I would have suggested that the 'newer' format overrides the older one... Nevertheless, if array-spec overrides dimension, it's logical that this is also valid for characters, isn't it.

@Intel team: can you open a defect record for the compiler error seen in opener (line 9), please. An optional "usage warning", as Steve suggested, would be fine, too. In most cases, I think, it's not the intent of the coders to have this double definition. If the warning shows in addition the actual size/length accepted would also be fine.

Best regards, Johannes

 

Kevin_D_Intel
Employee
354 Views

I will submit defect reports shortly for the issues discussed.

(Internal tracking id: TBD)

Steve_Lionel
Black Belt Retired Employee
354 Views

It's an interesting idea to deprecate having both specifications - I don't recall it ever coming up before while I've been on the committee. Note that in the character case F77 allowed you to say:

character*10 foo*20

In fact I recall fixing a bug in VAX Fortran that rejected that. The "character*10" form is deprecated, but still standard.

I can't think of another place in the standard that allows duplicated specifications, especially those that conflict!

Johannes_Rieke
New Contributor III
354 Views

It's getting even more weird to me. This one also compiles without error or warning following the override logic:

character(len=10), dimension(30)            :: foo2*50(20)
! or 
character*10     , dimension(30)            :: foo3*50(20)

I don't think that this makes sense to be allowed by the Fortran standard.

Steve_Lionel
Black Belt Retired Employee
354 Views

It is allowed, though I might agree that it shouldn't be.

IanH
Black Belt
354 Views

`character :: x` is a synonym for `character(LEN=1) :: x`, hence any specification of character length in an entity-decl is effectively an override.  It doesn't concern me particularly due to my personal coding style, but I suspect that deleting specification of character length in an entity-decl would result in wide-spread civil insurrection. 

(If there's even a hint of deleting specification of an array's dimension stuff in an entity-decl, then I'll be out on the streets creating mayhem and havoc too.)


 

Johannes_Rieke
New Contributor III
354 Views

Hi Ian,

OK, that sounds complicated. My idea was just to find a way to avoid the ugly constructs above, e.g.

character(len=10), dimension(30) :: foo2*50(20)

If it can't be done without destroying compatibility, a warning would be fine. Anyone who wants can configure this warning so that it is treated as an error.

Steve_Lionel
Black Belt Retired Employee
354 Views

I ran this by the committee members and got general agreement that having two specifications for length, bounds or cobounds should be deprecated in the next (post-2015) standard. This would enable compilers to give standards warnings for this usage. It's not clear to me that I can make a formal proposal yet, as the gates haven't been opened for that yet.

Steve_Lionel
Black Belt Retired Employee
354 Views

I wrote a comprehensive test for this issue, and it all worked correctly. ifort doesn't complain about a repeated length or dimension or codimension. What happened in post 1 was that both declarations of foo were uncommented, and the compiler correctly complained about a duplicate declaration.

Johannes_Rieke
New Contributor III
354 Views

Ah, sorry for causing confusion about that error message. I misunderstood that one. That's clear a double definition of foo in post 1. The error text might be a little misleading. Anyway, good to know that ifort is compliant to the standard and that's not a bug. Nevertheless the topic was very interesting.

Big thanks to you, Steve!

Reply