Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor III
9 Views

array definition: warning desired

Jump to solution

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

Accepted Solutions
Highlighted
Black Belt
9 Views

Yes, it's a compiler bug.  In

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos
15 Replies
Highlighted
Black Belt
9 Views

The standard allows this

Jump to solution

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

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
9 Views

>>The standard allows this

Jump to solution

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

0 Kudos
Highlighted
Black Belt
9 Views

Yup.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor III
9 Views

Thanks Steve and Jim,

Jump to solution

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

0 Kudos
Highlighted
Black Belt
10 Views

Yes, it's a compiler bug.  In

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos
Highlighted
New Contributor III
9 Views

Hi Steve, dear all,

Jump to solution

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

 

0 Kudos
Highlighted
Employee
9 Views

I will submit defect reports

Jump to solution

I will submit defect reports shortly for the issues discussed.

(Internal tracking id: TBD)

0 Kudos
Highlighted
Black Belt
9 Views

It's an interesting idea to

Jump to solution

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!

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor III
9 Views

It's getting even more weird

Jump to solution

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.

0 Kudos
Highlighted
Black Belt
9 Views

It is allowed, though I might

Jump to solution

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

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Black Belt
9 Views

`character :: x` is a synonym

Jump to solution

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


 

0 Kudos
Highlighted
New Contributor III
9 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.

0 Kudos
Highlighted
Black Belt
9 Views

I ran this by the committee

Jump to solution

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 (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Black Belt
9 Views

I wrote a comprehensive test

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor III
9 Views

Ah, sorry for causing

Jump to solution

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!

0 Kudos