gfortran 8.1 fails to compile

[stgeke]

Compilation fails as we are passing arguments containing too few elements for a dummy argument. Here is an example:

subroutine foo(a,b)
real a(1)
call foo2(a)
return
end

subroutine fo2(c)
real c(lx1*ly1*lz1)
...
return
end

We do this quite frequently in the code.

To fix this we have two options:

• change to assumed size array e.g. real a(*)
• compile with -std=legacy

[pschlatt1]

I would prefer assumed size arrays. We have seen a similar issue for the Cray compiler which produced wrong results when full optimisation was on. using assume size arrays fixed it, if I recall well.

[stgeke]

Agreed but it may take a while to do this (a lot of code needs to be changed). In the meantime I'll add the compilation flag. Is the Cray compiler issue #430 fixed?

[fischer1]

I would propose that we put in the desired value, e.g.,

  subroutine foo(a,b,n)
  real a(n), b(n)

  do i=1,n
       a(i) = func of b(i)
   enddo
   return
   end

If there are routines where this is not clear, then we can use a(*)

Note that there are some openacc() instances where it does not like passing
a scalar into such a routine (i.e., n=1 case). For example,

   s=glsum(s,1)

seems to cause some difficulties. In this case, the issue is: where does the
input "s" reside?? Host? Or device?

It is a perfectly valid and correct use of glsum. We could, however, develop
a scalar ("host-oriented") implementation, of the form:

   s=glsum_host(s)

or
s=glsum_sc(s)

...

[misunmin]

Yes that would be my preference too while openacc requires the length.

…

________________________________ From: fischer1 <notifications@github.com> Sent: Sunday, May 27, 2018 12:57:21 PM To: Nek5000/Nek5000 Cc: Subscribed Subject: Re: [Nek5000/Nek5000] gfortran 8.1 fails to compile (#497) I would propose that we put in the desired value, e.g., subroutine foo(a,b,n) real a(n), b(n) do i=1,n a(i) = func of b(i) enddo return end If there are routines where this is not clear, then we can use a(*) Note that there are some openacc() instances where it does not like passing a scalar into such a routine (i.e., n=1 case). For example, s=glsum(s,1) seems to cause some difficulties. In this case, the issue is: where does the input "s" reside?? Host? Or device? It is a perfectly valid and correct use of glsum. We could, however, develop a scalar ("host-oriented") implementation, of the form: s=glsum_host(s) or s=glsum_sc(s) ... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#497 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMZ6O1Dgp4Ag3i7n4ge4bR96TPECEVcYks5t2ukBgaJpZM4UPQ8g>.

[fischer1]

Incidentally,

In your foo example, there is nothing really wrong (of course)---and it seems to me
that the hard-coded parameter-based array declaration must be ok---it should perform
fast because the compiler is being told how big the array is.

The rest is merely a pointer to memory...

So, what I'm saying is that I wouldn't want to do is to replace "real a(lx1ly1lz1)" with "real a(*)"

I cannot see how the latter could be more informative to the compiler.

[stgeke]

Fixed in b635b29