topic I wrote a comprehensive test in Intel® Fortran Compiler

array definition: warning desired

Johannes_Rieke — Mon, 20 Feb 2017 14:52:13 GMT

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

The standard allows this

Steve_Lionel — Mon, 20 Feb 2017 15:53:48 GMT

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).

>>The standard allows this

jimdempseyatthecove — Mon, 20 Feb 2017 16:00:39 GMT

>>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

Yup.

Steve_Lionel — Mon, 20 Feb 2017 16:21:15 GMT

Yup.

Thanks Steve and Jim,

Johannes_Rieke — Mon, 20 Feb 2017 16:21:43 GMT

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

Yes, it's a compiler bug. In

Steve_Lionel — Mon, 20 Feb 2017 20:10:47 GMT

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.

Hi Steve, dear all,

Johannes_Rieke — Tue, 21 Feb 2017 08:35:20 GMT

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

I will submit defect reports

Kevin_D_Intel — Tue, 21 Feb 2017 18:26:08 GMT

I will submit defect reports shortly for the issues discussed.

(Internal tracking id: TBD)

It's an interesting idea to

Steve_Lionel — Tue, 21 Feb 2017 18:43:16 GMT

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!

It's getting even more weird

Johannes_Rieke — Wed, 22 Feb 2017 08:21:01 GMT

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.

It is allowed, though I might

Steve_Lionel — Wed, 22 Feb 2017 13:59:37 GMT

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

`character :: x` is a synonym

IanH — Thu, 23 Feb 2017 09:05:55 GMT

`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.)

Hi Ian,

Johannes_Rieke — Thu, 23 Feb 2017 09:39:38 GMT

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.

I ran this by the committee

Steve_Lionel — Thu, 23 Feb 2017 13:26:39 GMT

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.

I wrote a comprehensive test

Steve_Lionel — Thu, 23 Feb 2017 14:34:59 GMT

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.

Ah, sorry for causing

Johannes_Rieke — Thu, 23 Feb 2017 14:48:59 GMT

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!