https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644

--- Comment #1 from Matt Thompson <matthew.thompson at nasa dot gov> ---
Further update from a colleague:

Some observations:

* The function result having the name 'parameters' has no effect. It's from
this line "parameters = get()".

* The 'public :: get' must be present in the module otherwise it compiles

* Appending letters to the word 'parameters', for example 'parametersabc' still
causes a crash

* Prepending letters to the word 'parameters' does not crash

* The 'private' clause at the top is not necessary

Here's a more stripped down reproducer:

module test
  public :: get !this line is necessary for the crash

contains

  subroutine init()
    integer :: parameters
     parameters = get()
  end subroutine init

  function get() result(p)
     integer :: p
     p = 1
  end function get

end module test

The bug seems to have been introduced in gfortran 7. I tried GCC 8.2, 8.1, 7.3,
7.2 and 7.1 and the bug is present in all of them. However, it is not present
in GCC 6.3 and previous versions.

Another interesting thing I noticed is that if you just have a variable named
'parameters' and assign it a value you get this warning:

module test

contains

  subroutine init()
    integer :: parameters
     parameters = 1
  end subroutine init

end module test

gfortran_reproducer.F90:8:14:

      parameters = 1
              1
Warning: Legacy Extension: PARAMETER without '()' at (1)

This legacy extension seems like it's the culprit, and this patch

 https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00206.html

describes the error we found and roughly coincides with GCC 7 when the bug
appeared, but it says it should only apply to fixed-form code.

> However, note that this would change by default the compiler's
> interpretation of fixed-form variables starting with the string
> "parameter", if any such cases existed in real code. IMO fixed form
> code is isomorphic to legacy code, so I imagine most users writing
> fixed-form/legacy code would intend for a legacy PARAMETER statement,
> rather than assignment to variable PARAMETERPI, when writing such a
> statement.

But our code is obviously not fixed-format and that doesn't explain why "public
:: get" should have any effect.

Reply via email to