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.

Reply via email to