public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters  is the extensions type of derived type
@ 2022-04-25  0:56 xudong.luo@compiler-dev.com
  2022-04-25  7:03 ` [Bug fortran/105371] " schwab@linux-m68k.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: xudong.luo@compiler-dev.com @ 2022-04-25  0:56 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 105371
           Summary: The result of the merge function is different when
                    it's type of parameters  is the extensions type of
                    derived type
           Product: gcc
           Version: 11.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xudong.luo@compiler-dev.com
  Target Milestone: ---

Created attachment 52862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52862&action=edit
output

Whether the mask is a constant or a variable causes inconsistent results of the
merge function when it's type of parameters  is the extensions type of derived
type.
1.The mask is constant
Program test00
  Type t
    Integer :: c
  End Type
  Type,Extends(t) :: t2
    Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,.true.)
  Select Type (z=>r)
  Type Is (t)
    print *,z%c
  Type Is (t2)
    print *,z%c,z%c2
  End Select
End Program
2. The mask is variable
Program test01
  Type t
    Integer :: c
  End Type
  Type,Extends(t) :: t2
    Integer :: c2
  End Type
  Class(t),Allocatable :: x,y,r
  logical :: ok = .true.
  integer :: i = 1
  x = t2(1,-1)
  y = t2(2,-2)
  r = merge (x,y,i == 1)
  Select Type (z=>r)
  Type Is (t)
    print *,z%c
  Type Is (t2)
    print *,z%c,z%c2
  End Select
End Program

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
@ 2022-04-25  7:03 ` schwab@linux-m68k.org
  2022-04-26 18:12 ` kargl at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: schwab@linux-m68k.org @ 2022-04-25  7:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 105372 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
  2022-04-25  7:03 ` [Bug fortran/105371] " schwab@linux-m68k.org
@ 2022-04-26 18:12 ` kargl at gcc dot gnu.org
  2022-04-27  9:28 ` xudong.luo@compiler-dev.com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: kargl at gcc dot gnu.org @ 2022-04-26 18:12 UTC (permalink / raw)
  To: gcc-bugs

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
So, what do you believe the correct output should be?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
  2022-04-25  7:03 ` [Bug fortran/105371] " schwab@linux-m68k.org
  2022-04-26 18:12 ` kargl at gcc dot gnu.org
@ 2022-04-27  9:28 ` xudong.luo@compiler-dev.com
  2022-04-27 19:51 ` anlauf at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: xudong.luo@compiler-dev.com @ 2022-04-27  9:28 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from luoxudong <xudong.luo@compiler-dev.com> ---
(In reply to kargl from comment #2)
> So, what do you believe the correct output should be?

 I think the output when the mask is constant should be consistent with the
result when the mask is variable.
1.The output when the mask is constant : 1
2.The output when the mask is constant : 1  -1
the correct output should be : 1 -1

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
                   ` (2 preceding siblings ...)
  2022-04-27  9:28 ` xudong.luo@compiler-dev.com
@ 2022-04-27 19:51 ` anlauf at gcc dot gnu.org
  2022-04-27 22:14 ` sgk at troutmask dot apl.washington.edu
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-04-27 19:51 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following untested hackish patch leads to the same answer for both cases:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 233cc42137f..abd93956217 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource,
gfc_expr *mask)
     {
       result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
       /* Parenthesis is needed to get lower bounds of 1.  */
-      result = gfc_get_parentheses (result);
+      if (result->rank)
+       result = gfc_get_parentheses (result);
       gfc_simplify_expr (result, 1);
       return result;
     }

Thing is, I have to find a compiler that gives the result the reporter expects.
E.g. Intel 2021.5 prints

           1

for both cases.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
                   ` (3 preceding siblings ...)
  2022-04-27 19:51 ` anlauf at gcc dot gnu.org
@ 2022-04-27 22:14 ` sgk at troutmask dot apl.washington.edu
  2022-04-28  0:10 ` xudong.luo@compiler-dev.com
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2022-04-27 22:14 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Apr 27, 2022 at 07:51:10PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> The following untested hackish patch leads to the same answer for both cases:
> 
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index 233cc42137f..abd93956217 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource,
> gfc_expr *mask)
>      {
>        result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
>        /* Parenthesis is needed to get lower bounds of 1.  */
> -      result = gfc_get_parentheses (result);
> +      if (result->rank)
> +       result = gfc_get_parentheses (result);
>        gfc_simplify_expr (result, 1);
>        return result;
>      }
> 
> Thing is, I have to find a compiler that gives the result the reporter expects.
> E.g. Intel 2021.5 prints
> 
>            1
> 
> for both cases.
> 

Harald,  thanks for looking at this!

I don't use polymorphism in my codes.

The "class(t) :: x, y, r" declaration clearly gives x, y, r the
type type(t).  I assume that the assignments "x = t2(1,-1)" and
"y = t2(2,-2)" now change the dynamic type of x and y to type(t2).
When "r = merge(x,y,...)" is evaluated and assigned the dynamic
type of r becomes type(t2).  So, the output should be

1 -1

But, again, I'm not polymorphic.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
                   ` (4 preceding siblings ...)
  2022-04-27 22:14 ` sgk at troutmask dot apl.washington.edu
@ 2022-04-28  0:10 ` xudong.luo@compiler-dev.com
  2022-04-28  7:00 ` xudong.luo@compiler-dev.com
  2022-10-10 19:28 ` anlauf at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: xudong.luo@compiler-dev.com @ 2022-04-28  0:10 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from luoxudong <xudong.luo@compiler-dev.com> ---
(In reply to Steve Kargl from comment #5)
> On Wed, Apr 27, 2022 at 07:51:10PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
> > 
> > --- Comment #4 from anlauf at gcc dot gnu.org ---
> > The following untested hackish patch leads to the same answer for both cases:
> > 
> > diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> > index 233cc42137f..abd93956217 100644
> > --- a/gcc/fortran/simplify.cc
> > +++ b/gcc/fortran/simplify.cc
> > @@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource,
> > gfc_expr *mask)
> >      {
> >        result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
> >        /* Parenthesis is needed to get lower bounds of 1.  */
> > -      result = gfc_get_parentheses (result);
> > +      if (result->rank)
> > +       result = gfc_get_parentheses (result);
> >        gfc_simplify_expr (result, 1);
> >        return result;
> >      }
> > 
> > Thing is, I have to find a compiler that gives the result the reporter expects.
> > E.g. Intel 2021.5 prints
> > 
> >            1
> > 
> > for both cases.
> > 
> 
> Harald,  thanks for looking at this!
> 
> I don't use polymorphism in my codes.
> 
> The "class(t) :: x, y, r" declaration clearly gives x, y, r the
> type type(t).  I assume that the assignments "x = t2(1,-1)" and
> "y = t2(2,-2)" now change the dynamic type of x and y to type(t2).
> When "r = merge(x,y,...)" is evaluated and assigned the dynamic
> type of r becomes type(t2).  So, the output should be
> 
> 1 -1
> 
> But, again, I'm not polymorphic.
(In reply to Steve Kargl from comment #5)
> On Wed, Apr 27, 2022 at 07:51:10PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
> > 
> > --- Comment #4 from anlauf at gcc dot gnu.org ---
> > The following untested hackish patch leads to the same answer for both cases:
> > 
> > diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> > index 233cc42137f..abd93956217 100644
> > --- a/gcc/fortran/simplify.cc
> > +++ b/gcc/fortran/simplify.cc
> > @@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource,
> > gfc_expr *mask)
> >      {
> >        result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
> >        /* Parenthesis is needed to get lower bounds of 1.  */
> > -      result = gfc_get_parentheses (result);
> > +      if (result->rank)
> > +       result = gfc_get_parentheses (result);
> >        gfc_simplify_expr (result, 1);
> >        return result;
> >      }
> > 
> > Thing is, I have to find a compiler that gives the result the reporter expects.
> > E.g. Intel 2021.5 prints
> > 
> >            1
> > 
> > for both cases.
> > 
> 
> Harald,  thanks for looking at this!
> 
> I don't use polymorphism in my codes.
> 
> The "class(t) :: x, y, r" declaration clearly gives x, y, r the
> type type(t).  I assume that the assignments "x = t2(1,-1)" and
> "y = t2(2,-2)" now change the dynamic type of x and y to type(t2).
> When "r = merge(x,y,...)" is evaluated and assigned the dynamic
> type of r becomes type(t2).  So, the output should be
> 
> 1 -1
> 
> But, again, I'm not polymorphic.

I think so,thanks a lot.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
                   ` (5 preceding siblings ...)
  2022-04-28  0:10 ` xudong.luo@compiler-dev.com
@ 2022-04-28  7:00 ` xudong.luo@compiler-dev.com
  2022-10-10 19:28 ` anlauf at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: xudong.luo@compiler-dev.com @ 2022-04-28  7:00 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from luoxudong <xudong.luo@compiler-dev.com> ---
(In reply to Steve Kargl from comment #5)
> On Wed, Apr 27, 2022 at 07:51:10PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
> > 
> > --- Comment #4 from anlauf at gcc dot gnu.org ---
> > The following untested hackish patch leads to the same answer for both cases:
> > 
> > diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> > index 233cc42137f..abd93956217 100644
> > --- a/gcc/fortran/simplify.cc
> > +++ b/gcc/fortran/simplify.cc
> > @@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource,
> > gfc_expr *mask)
> >      {
> >        result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
> >        /* Parenthesis is needed to get lower bounds of 1.  */
> > -      result = gfc_get_parentheses (result);
> > +      if (result->rank)
> > +       result = gfc_get_parentheses (result);
> >        gfc_simplify_expr (result, 1);
> >        return result;
> >      }
> > 
> > Thing is, I have to find a compiler that gives the result the reporter expects.
> > E.g. Intel 2021.5 prints
> > 
> >            1
> > 
> > for both cases.
> > 
> 
> Harald,  thanks for looking at this!
> 
> I don't use polymorphism in my codes.
> 
> The "class(t) :: x, y, r" declaration clearly gives x, y, r the
> type type(t).  I assume that the assignments "x = t2(1,-1)" and
> "y = t2(2,-2)" now change the dynamic type of x and y to type(t2).
> When "r = merge(x,y,...)" is evaluated and assigned the dynamic
> type of r becomes type(t2).  So, the output should be
> 
> 1 -1
> 
> But, again, I'm not polymorphic.

But I still have a question, why does gfortran's code support polymorphic merge
when the mask is a logical variable? What is this code? I hope you can answer
it. Thank you very much

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug fortran/105371] The result of the merge function is different when it's type of parameters  is the extensions type of derived type
  2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
                   ` (6 preceding siblings ...)
  2022-04-28  7:00 ` xudong.luo@compiler-dev.com
@ 2022-10-10 19:28 ` anlauf at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-10-10 19:28 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-10-10 19:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-25  0:56 [Bug fortran/105371] New: The result of the merge function is different when it's type of parameters is the extensions type of derived type xudong.luo@compiler-dev.com
2022-04-25  7:03 ` [Bug fortran/105371] " schwab@linux-m68k.org
2022-04-26 18:12 ` kargl at gcc dot gnu.org
2022-04-27  9:28 ` xudong.luo@compiler-dev.com
2022-04-27 19:51 ` anlauf at gcc dot gnu.org
2022-04-27 22:14 ` sgk at troutmask dot apl.washington.edu
2022-04-28  0:10 ` xudong.luo@compiler-dev.com
2022-04-28  7:00 ` xudong.luo@compiler-dev.com
2022-10-10 19:28 ` anlauf at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).