我正在研究由多个模块组成并使用OOP功能的大型Fortran代码。使用gfortran版本7至9编译此代码时,我遇到错误。

  • 我在下面提供了一个最小的工作示例来重现该错误。可以将其另存为test.f95并使用gfortran -fcheck=all -c test.f95进行编译。
  • -fcheck=all传递给编译器时会触发该错误。
  • 该错误出现在gfortran 7、8和9中,但没有出现在早期版本中(已通过gfortran 5和6测试)。请参见下面的编译器输出。
  • 我正在使用Ubuntu 18.04.3 LTS,4.15.0-65通用x86_64

  • 有人可以尝试重现并确认此错误吗?我看过不同的错误跟踪系统,但找不到类似的东西。我尚未报告它,因此想确保在报告之前值得报告。

    另外,有没有一种方法可以解决此编译器错误?

    最小工作示例:
    module buggy
      implicit none
    
      type :: par
      contains
        procedure, public :: fun => fun_par
      end type par
    
      type comp
        class(par), allocatable :: p
      end type comp
    
      type foo
        type(comp), allocatable :: m(:)
      contains
        procedure, public :: init   => init_foo
        procedure, public :: update => update_foo
      end type foo
    
    contains
    
      function fun_par(this, x) result(y)
        implicit none
        class(par)          :: this
        integer, intent(in) :: x(:)
        integer             :: y(size(x))
      end function fun_par
    
      subroutine init_foo(this, n)
        implicit none
        class(foo)          :: this
        integer, intent(in) :: n
        integer             :: k
        allocate(this%m(n))
        do k = 1, n
          allocate(par :: this%m(k)%p)
        end do
      end subroutine init_foo
    
      subroutine update_foo(this, x)
        implicit none
        class(foo)       :: this
        integer, intent(in) :: x(:)
        integer             :: k
        do k = 1, size(this%m)
          write(*,*) this%m(k)%p%fun(x)
        end do
      end subroutine update_foo
    
    end module buggy
    

    从反复试验中得出几点意见:
  • foo的定义中,如果将m指定为固定长度的 vector (例如type(comp) :: m(10)),则会触发相同的错误。 allocatable似乎不是这里的罪魁祸首。
  • 使用p而不是comptype(par)中定义class(par)不会触发该错误。但是我需要p在我的代码中是多态的。
  • p被指定为指针而不是可分配 vector 时,存在相同的错误。
  • y中结果fun_par()的维度似乎有问题:例如,当它是一个标量(用y代替y(size(x)))时,不会触发该错误。


  • 编译器错误消息

    使用gfortran 9.2.1:
    $ /usr/bin/gfortran-9 -fcheck=all -c test.f95
    test.f95:50:0:
    
       50 |       write(*,*) this%m(k)%p%fun(x)
          |
    internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:6785
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-9/README.Bugs> for instructions.
    

    使用gfortran 8.3.0:
    $ /usr/bin/gfortran-8 -fcheck=all -c test.f95
    test.f95:50:0:
    
           write(*,*) this%m(k)%p%fun(x)
    
    internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:6410
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-8/README.Bugs> for instructions.
    

    使用gfortran 7.4.0:
    $ /usr/bin/gfortran-7 -fcheck=all -c test.f95
    test.f95:50:0:
    
           write(*,*) this%m(k)%p%fun(x)
    
    internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:6290
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
    

    使用gfortran 6.5.0和gfortran 5.5.0:没有错误。

    最佳答案

    未知的内部编译器错误始终值得报告。在这种情况下,我也找不到报告,但是更熟悉gcc历史的人也许可以找到报告。

    要变通解决此编译器错误,似乎您可以直接引用函数fun_par而不是组件fun的绑定(bind)p:

    write(*,*) fun_par(this%m(1)%p, x)
    

    最后,我们可以使示例稍微更小一些:
    module buggy
      implicit none
    
      type :: par
      contains
        procedure, public :: fun => fun_par
      end type par
    
      type comp
        class(par), allocatable :: p
      end type comp
    
      type foo
        type(comp), allocatable :: m(:)
      end type foo
    
    contains
    
      function fun_par(this)
        class(par)          :: this
        integer             :: fun_par(1)
        fun_par=0
      end function fun_par
    
      subroutine update_foo(this)
        class(foo)       :: this
        write(*,*) this%m(1)%p%fun()
      end subroutine update_foo
    
    end module buggy
    

    关于compiler-errors - 动态(可分配)向量的gfortran编译器错误,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/58311522/

    10-11 22:14
    查看更多