Defect: co_broadcast derived type with allocatable components

[everythingfunctional]

• I am reporting a bug others will be able to reproduce and not asking a question or requesting a new feature.

System information including:

• OpenCoarrays Version: OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.9.2)
• Fortran Compiler: GNU Fortran (Homebrew GCC 10.2.0_2) 10.2.0
• C compiler used for building lib: unknown
• Installation method: homebrew
• All flags & options passed to the installer
• Output of uname -a: Darwin Brads-MBP.lan 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec 2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64
• MPI library being used: openmp ?
• Machine architecture and number of physical cores: Intel x86-64, 8 cores
• Version of CMake: N/A

To help us debug your issue please explain:

What you were trying to do (and why)

Attempting to use co_broadcast with a derived type.

What happened (include command output, screenshots, logs, etc.)

Not all components are copied correctly.

What you expected to happen

All components should be broadcast to all images.

Step-by-step reproduction instructions to reproduce the error/bug

A minimal reproducer that might serve as a regression test is below:

  implicit none

  type foo_t
    integer i
    integer, allocatable :: j
  end type

  type(foo_t) foo
  integer, parameter :: source_image = 1

  if (this_image() == source_image)  then
    foo = foo_t(2,3)
  else
    allocate(foo%j)
  end if
  call co_broadcast(foo, source_image)

  if ((foo%i /= 2) .or. (foo%j /= 3))  error stop "Test failed."
  sync all
  print *, "Test passed."

end

With 11.2.0, the above code prints, "Test failed."

[rouson]

As @everythingfunctional has pointed out offline, the issue here appears to be mixing a non-allocatable component with an allocatable component. We currently have two orthogonal tests:

1. allocatable-component co_broadcast unit test.f90, where all components are allocatable, and
2. co_broadcast_derived_type.f90, where no components are allocatable.

To expose this, we probably just need a simple test with both an allocatable component and a non-allocatable component.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[praynaud]

@rouson @everythingfunctional: It looks like this issue is not yet fixed. Are there plans to fix it in the near future?

As you know, there are possible workarounds, but it would be nice to be able to use intrinsic co_broadcast rather than create custom broadcast procedures to work around the issue.

[rouson]

@praynaud I'll reopen it and investigate how to turn off the bot that closed this issue. I'll contact you to discuss the status and plan for a fix.

[rouson]

The original reproducer is as follows:

module foo_m
    implicit none

    type :: foo_t
        integer :: i
        integer, allocatable :: j(:)
    contains
        procedure :: broadcast
    end type
contains
    subroutine broadcast(self, source_image)
        class(foo_t), intent(inout) :: self
        integer, intent(in) :: source_image

        type(foo_t) :: message
        integer :: size_j

        associate(me => this_image())
            if (me == source_image) then
                size_j = size(self%j)
            end if

            call co_broadcast(size_j, source_image)

            if (me == source_image) then
                message%i = self%i
                message%j = self%j
            else
                allocate(message%j(size_j))
            end if

            call co_broadcast(message, source_image)

            if (me /= source_image) then
                self%i = message%i
                self%j = message%j
            end if
        end associate
    end subroutine
end module

program main
    use foo_m, only: foo_t

    implicit none

    type(foo_t) :: foo

    associate(me => this_image())
        if (me == 1) then
            foo = foo_t(100, [1,2])
        end if
        call foo%broadcast(1)

        print *, "foo%i = ", foo%i, ", foo%j = ", foo%j, "on image: ", me
    end associate
end program

and the corresponding output:

[Brads-MBP:~/tmp/co_broadcast] caf co_broadcast_derived_type.f90 
[Brads-MBP:~/tmp/co_broadcast] cafrun -n 2 a.out
 foo%i =          100 , foo%j =            1           2 on image:            1
 foo%i =            0 , foo%j =            1           2 on image:            2

[vehre]

Test case at: issue-727-co-broadcast-on-mixed-derived-type

Unfortunately this is a compiler bug and can not be fixed in the library itself.

GitHub

Build software better, together

GitHub is where people build software. More than 73 million people use GitHub to discover, fork, and contribute to over 200 million projects.

[praynaud]

@rouson Is the next step then to submit a compiler bug to gfortran?

[rouson]

@praynaud done: see gfortran bug report 103970

@vehre please let us know whether you can work on the compiler fix.

[vehre]

That would allow me to submit a patch. Doing the PR and patch myself always feels Abit odd. So when you can file it, I can provide the patch.

[rouson]

@vehre see PR 103970

[vehre]

Well, the patch is nearly done. I just have to do a testcase for the fortran patch or it won't get accepted.

[vehre]

The patch is available at: https://gcc.gnu.org/pipermail/fortran/2022-January/057459.html

[rouson]

I believe this is fixed by #750 and #751.