[Bug fortran/105371] The result of the merge function is different when it's type of parameters is the extensions type of derived type

anlauf at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Oct 10 19:28:33 GMT 2022


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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-10
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Thing is, I have to find a compiler that gives the result the reporter
> expects.

Update: the NAG compiler 7.1 seems to be the only compiler that behaves
as expected by the user.

The somewhat modified testcase shows that not only simplification of MERGE,
but also the generated code behaves inconsistently:

program p
  implicit none
  type t
     integer :: c
  end type
  type, extends (t) :: t2
     integer :: c2
  end type
  class(t), allocatable :: x, y, r
  integer :: i = 1
  x = t2(1,-1)
  y = t2(2,-2)
  r = x
  call check_type()
  r = merge (x, x, i == 1)
  call check_type ()
  r = merge (y, y, i == 2)
  call check_type ()
  r = merge (x, y, i == 2)
  call check_type ()
contains
  subroutine check_type ()
    select type (z => r)
    type is (t)
       print *, "type is (t) :", z% c
    type is (t2)
       print *, "type is (t2):", z% c, z% c2
    end select
  end subroutine
end program p

NAG 7.1 prints:

 type is (t2): 1 -1
 type is (t2): 1 -1
 type is (t2): 2 -2
 type is (t2): 2 -2

Current gfortran:

 type is (t2):           1          -1
 type is (t) :           1
 type is (t) :           2
 type is (t2):           2          -2

As MERGE is expanded inline, I was hoping to understand what happens here,
but a first look at the dump-tree looked strange for the second and third
case.  Needs further investigation.


More information about the Gcc-bugs mailing list