[PATCH] Fix fortran/PR114024

[PATCH] Fix fortran/PR114024

[Steve Kargl]

I have attached a patch to PR114024, see

https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html

The patch contains a new testcase and passes regression
testing on x86_64-*-freebsd.  Could someone castr an eye 
over the patch and commit it?

-- 
Steve

Re: [PATCH] Fix fortran/PR114024

[Jerry D]

On 2/21/24 10:30 AM, Steve Kargl wrote:
> I have attached a patch to PR114024, see
> 
> https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
> 
> The patch contains a new testcase and passes regression
> testing on x86_64-*-freebsd.  Could someone castr an eye
> over the patch and commit it?
> 

Hi Steve,

I looked it over and looks reasonable.  I will try to apply it next few 
days and test here. If OK, I will commit.

Jerry

Re: [PATCH] Fix fortran/PR114024

[Harald Anlauf]

On 2/21/24 20:41, Jerry D wrote:
> On 2/21/24 10:30 AM, Steve Kargl wrote:
>> I have attached a patch to PR114024, see
>>
>> https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
>>
>> The patch contains a new testcase and passes regression
>> testing on x86_64-*-freebsd.  Could someone castr an eye
>> over the patch and commit it?
>>
>
> Hi Steve,
>
> I looked it over and looks reasonable.  I will try to apply it next few
> days and test here. If OK, I will commit.
>
> Jerry
>

Actually the patch has two issues:

- a minor one: a new front-end memleak which can be avoided by
   using either gfc_replace_expr (see its other uses)
   Hint: try valgrind on f951

- it still fails on the following code, because the traversal
   of the refs is incomplete / wrong:

program foo
    implicit none
    complex               :: cmp(3)
    real, pointer         :: pp(:)
    class(*), allocatable :: uu(:)
    type t
       real :: re
       real :: im
    end type t
    type u
       type(t) :: tt(3)
    end type u
    type(u) :: cc

    cmp = (3.45,6.78)
    cc% tt% re = cmp% re
    cc% tt% im = cmp% im
    allocate (pp, source = cc% tt% im)       ! ICE
    print *, pp
    allocate (uu, source = cc% tt% im)       ! ICE
end

This still crashes for me for the indicated cases.

Harald

Re: [PATCH] Fix fortran/PR114024

[Jerry D]

On 2/21/24 12:28 PM, Harald Anlauf wrote:
> On 2/21/24 20:41, Jerry D wrote:
>> On 2/21/24 10:30 AM, Steve Kargl wrote:
>>> I have attached a patch to PR114024, see
>>>
>>> https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
>>>
>>> The patch contains a new testcase and passes regression
>>> testing on x86_64-*-freebsd.  Could someone castr an eye
>>> over the patch and commit it?
>>>
>>
>> Hi Steve,
>>
>> I looked it over and looks reasonable.  I will try to apply it next few
>> days and test here. If OK, I will commit.
>>
>> Jerry
>>
> 
> Actually the patch has two issues:
> 
> - a minor one: a new front-end memleak which can be avoided by
>    using either gfc_replace_expr (see its other uses)
>    Hint: try valgrind on f951

Yes, I am learning to do that.

> 
> - it still fails on the following code, because the traversal
>    of the refs is incomplete / wrong:
> 
> program foo
>     implicit none
>     complex               :: cmp(3)
>     real, pointer         :: pp(:)
>     class(*), allocatable :: uu(:)
>     type t
>        real :: re
>        real :: im
>     end type t
>     type u
>        type(t) :: tt(3)
>     end type u
>     type(u) :: cc
> 
>     cmp = (3.45,6.78)
>     cc% tt% re = cmp% re
>     cc% tt% im = cmp% im
>     allocate (pp, source = cc% tt% im)       ! ICE
>     print *, pp
>     allocate (uu, source = cc% tt% im)       ! ICE
> end
> 
> This still crashes for me for the indicated cases.
> 
> Harald
> 

Good catch.  I will hold off until that is figured out.

Jerry

Re: [PATCH] Fix fortran/PR114024

[Steve Kargl]

On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote:
> On 2/21/24 20:41, Jerry D wrote:
> > On 2/21/24 10:30 AM, Steve Kargl wrote:
> > > I have attached a patch to PR114024, see
> > > 
> > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
> > > 
> > > The patch contains a new testcase and passes regression
> > > testing on x86_64-*-freebsd.  Could someone castr an eye
> > > over the patch and commit it?
> > > 
> > 
> > Hi Steve,
> > 
> > I looked it over and looks reasonable.  I will try to apply it next few
> > days and test here. If OK, I will commit.
> > 
> > Jerry
> > 
> 
> Actually the patch has two issues:
> 
> - a minor one: a new front-end memleak which can be avoided by
>   using either gfc_replace_expr (see its other uses)
>   Hint: try valgrind on f951

Unfortunately, valgrind does not work on AMD FX-8350 cpu.
memleak vs ICE.  I think I'll take one over the other.
Probably need to free code->expr3 before the copy.
I tried gfc_replace_expr in an earlier patch.  It did not
work. 

> - it still fails on the following code, because the traversal
>   of the refs is incomplete / wrong:
> 
> program foo
>    implicit none
>    complex               :: cmp(3)
>    real, pointer         :: pp(:)
>    class(*), allocatable :: uu(:)
>    type t
>       real :: re
>       real :: im
>    end type t
>    type u
>       type(t) :: tt(3)
>    end type u
>    type(u) :: cc
> 
>    cmp = (3.45,6.78)
>    cc% tt% re = cmp% re
>    cc% tt% im = cmp% im
>    allocate (pp, source = cc% tt% im)       ! ICE

cc%tt%im isn't a complex-part-ref, so this seems to
be a different (maybe related) issue.  Does the code
compile with 'source = (cc%tt%im)'?  If so, perhaps,
detecting a component reference and doing the simply
wrapping with parentheses can be done.

>    print *, pp
>    allocate (uu, source = cc% tt% im)       ! ICE

Ditto.  Not to mention I know nothing about the implementation
of CLASS in gfortran.

-- 
Steve

Re: [PATCH] Fix fortran/PR114024

[Harald Anlauf]

On 2/21/24 22:00, Steve Kargl wrote:
> Unfortunately, valgrind does not work on AMD FX-8350 cpu.

Do you mean valgrind does not work at all?
For gcc, you need to configure --enable-valgrind-annotations
to not get bogus warnings.

> memleak vs ICE.  I think I'll take one over the other.
> Probably need to free code->expr3 before the copy.

Yep.

> I tried gfc_replace_expr in an earlier patch.  It did not
> work.



>> - it still fails on the following code, because the traversal
>>    of the refs is incomplete / wrong:
>>
>> program foo
>>     implicit none
>>     complex               :: cmp(3)
>>     real, pointer         :: pp(:)
>>     class(*), allocatable :: uu(:)
>>     type t
>>        real :: re
>>        real :: im
>>     end type t
>>     type u
>>        type(t) :: tt(3)
>>     end type u
>>     type(u) :: cc
>>
>>     cmp = (3.45,6.78)
>>     cc% tt% re = cmp% re
>>     cc% tt% im = cmp% im
>>     allocate (pp, source = cc% tt% im)       ! ICE
>
> cc%tt%im isn't a complex-part-ref, so this seems to
> be a different (maybe related) issue.  Does the code
> compile with 'source = (cc%tt%im)'?  If so, perhaps,
> detecting a component reference and doing the simply
> wrapping with parentheses can be done.

Yes, that's why I tried to make up the above example.
I think %re and %im are not too special, they work
here pretty much like component refs elsewhere.

>
>>     print *, pp
>>     allocate (uu, source = cc% tt% im)       ! ICE
>
> Ditto.  Not to mention I know nothing about the implementation
> of CLASS in gfortran.
>

You can ignore this one for now.  It works if one places
parens around the source expr as for the other cases.

Harald

Re: [PATCH] Fix fortran/PR114024

[Steve Kargl]

On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> On 2/21/24 22:00, Steve Kargl wrote:
> > Unfortunately, valgrind does not work on AMD FX-8350 cpu.
> 
> Do you mean valgrind does not work at all?
> For gcc, you need to configure --enable-valgrind-annotations
> to not get bogus warnings.

It does not work at all unless one tracks done an obscure
patch for valgrind.  The FX-8350 has a tbm instruction.
Everything on the system would need be compiled with -mno-tbm
(or -fno-tbm).

%  valgrind ./z
...
==88861== Process terminating with default action of signal 4 (SIGILL):
 dumping core
==88861==  Illegal opcode at address 0x4D30D87
==88861==    at 0x4D30D87: ??? (in /lib/libc.so.7)
==88861==    by 0x4D213DE: ??? (in /lib/libc.so.7)
==88861==    by 0x4D2B935: ??? (in /lib/libc.so.7)
==88861==    by 0x4D2C34E: ??? (in /lib/libc.so.7)
==88861==    by 0x400AB8C: ??? (in /libexec/ld-elf.so.1)
==88861==    by 0x4009828: ??? (in /libexec/ld-elf.so.1)
==88861==    by 0x4006AE8: ??? (in /libexec/ld-elf.so.1)

 

> > memleak vs ICE.  I think I'll take one over the other.
> > Probably need to free code->expr3 before the copy.
> 
> Yep.
> 
> > I tried gfc_replace_expr in an earlier patch.  It did not
> > work.
> 
> 
> 
> > > - it still fails on the following code, because the traversal
> > >    of the refs is incomplete / wrong:
> > > 
> > > program foo
> > >     implicit none
> > >     complex               :: cmp(3)
> > >     real, pointer         :: pp(:)
> > >     class(*), allocatable :: uu(:)
> > >     type t
> > >        real :: re
> > >        real :: im
> > >     end type t
> > >     type u
> > >        type(t) :: tt(3)
> > >     end type u
> > >     type(u) :: cc
> > > 
> > >     cmp = (3.45,6.78)
> > >     cc% tt% re = cmp% re
> > >     cc% tt% im = cmp% im
> > >     allocate (pp, source = cc% tt% im)       ! ICE
> > 
> > cc%tt%im isn't a complex-part-ref, so this seems to
> > be a different (maybe related) issue.  Does the code
> > compile with 'source = (cc%tt%im)'?  If so, perhaps,
> > detecting a component reference and doing the simply
> > wrapping with parentheses can be done.
> 
> Yes, that's why I tried to make up the above example.
> I think %re and %im are not too special, they work
> here pretty much like component refs elsewhere.
> 

I see.  The %re and %im complex-part-ref correspond to 
ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
A part-ref for a user-defined type doesn't have an
INQUIRY_xxx, so we'll need to see if there is a way to
easily identify, e.g., cc%tt%re from your testcase.  

-- 
Steve

Re: [PATCH] Fix fortran/PR114024

[Steve Kargl]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > On 2/21/24 22:00, Steve Kargl wrote:
> > > memleak vs ICE.  I think I'll take one over the other.
> > > Probably need to free code->expr3 before the copy.
> > 
> > Yep.
> > 
> > > I tried gfc_replace_expr in an earlier patch.  It did not
> > > work.


I tried freeing code->expr3 before assigning the new expression.
That leads to

% gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90 
pid 69473 comm f951 has trashed its stack, killing
gfortran: internal compiler error: Illegal instruction signal terminated program f951

If I don't free code->expr3 but simply assign the new
expression from gfc_get_parentheses(), your example
now compiles are executes are expected.  It now
allocate_with_source_28.f90.  Caveat:  I don't know
how to test the CLASS uu.

> > > > - it still fails on the following code, because the traversal
> > > >    of the refs is incomplete / wrong:
> > > > 
> > > > program foo
> > > >     implicit none
> > > >     complex               :: cmp(3)
> > > >     real, pointer         :: pp(:)
> > > >     class(*), allocatable :: uu(:)
> > > >     type t
> > > >        real :: re
> > > >        real :: im
> > > >     end type t
> > > >     type u
> > > >        type(t) :: tt(3)
> > > >     end type u
> > > >     type(u) :: cc
> > > > 
> > > >     cmp = (3.45,6.78)
> > > >     cc% tt% re = cmp% re
> > > >     cc% tt% im = cmp% im
> > > >     allocate (pp, source = cc% tt% im)       ! ICE
> > > 
> > > cc%tt%im isn't a complex-part-ref, so this seems to
> > > be a different (maybe related) issue.  Does the code
> > > compile with 'source = (cc%tt%im)'?  If so, perhaps,
> > > detecting a component reference and doing the simply
> > > wrapping with parentheses can be done.
> > 
> > Yes, that's why I tried to make up the above example.
> > I think %re and %im are not too special, they work
> > here pretty much like component refs elsewhere.
> > 
> 
> I see.  The %re and %im complex-part-ref correspond to 
> ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
> A part-ref for a user-defined type doesn't have an
> INQUIRY_xxx, so we'll need to see if there is a way to
> easily identify, e.g., cc%tt%re from your testcase.  

The attach patch uses ref->type == REF_COMPONENT to deal 
with the above code.

-- 
Steve

[-- Attachment #2: pr114024.diff --]
[-- Type: text/x-diff, Size: 3134 bytes --]

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..414248fe2e5 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6354,9 +6354,35 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
 	   al = al->next)
 	vtab_needed = (al->expr->ts.type == BT_CLASS);
 
+      /* When expr3 is a variable, i.e., a very simple expression, then
+	 convert it once here.  */
+ 
       gfc_init_se (&se, NULL);
-      /* When expr3 is a variable, i.e., a very simple expression,
-	     then convert it once here.  */
+
+      /* If one has source = z%re or z%im with z a complex array or 
+	 source = a%b%c where a or b is an array of a derived type, then
+	 things can go sideways with the complex-part-refi or part-ref, so
+	 wrap the entity in parentheses to force evaluation of an expression.
+	 That is, the else-branch in the following if-else-stmt is entered.  */
+
+      if (code->expr3->expr_type == EXPR_VARIABLE
+	  && code->expr3->ts.type == BT_REAL
+	  && code->expr3->ref)
+	{
+	  gfc_ref *ref = code->expr3->ref;
+
+	  while (ref->next)
+	    ref = ref->next;
+
+	  if (ref->u.i == INQUIRY_IM || ref->u.i == INQUIRY_RE
+	      || ref->type == REF_COMPONENT)
+	    {
+	      gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+	      code->expr3 = gfc_copy_expr (etmp);
+	      gfc_free_expr (etmp);
+	    }
+	}
+
       if (code->expr3->expr_type == EXPR_VARIABLE
 	  || code->expr3->expr_type == EXPR_ARRAY
 	  || code->expr3->expr_type == EXPR_CONSTANT)
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
new file mode 100644
index 00000000000..d0f0f3c4a84
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
@@ -0,0 +1,20 @@
+!
+! { dg-do run }
+!
+! fortran/PR114024
+! https://github.com/fujitsu/compiler-test-suite
+! Modified from Fortran/0093/0093_0130.f90
+!
+program foo
+   implicit none
+   complex :: cmp(3)
+   real, allocatable :: xx(:), yy(:), zz(:)
+   cmp = (3., 6.78)
+   allocate(xx, source = cmp%re)          ! This caused an ICE.
+   allocate(yy, source = cmp(1:3)%re)     ! This caused an ICE.
+   allocate(zz, source = (cmp%re))
+   if (any(xx /= [3., 3., 3.])) stop 1
+   if (any(yy /= [3., 3., 3.])) stop 2
+   if (any(zz /= [3., 3., 3.])) stop 3
+end program foo
+
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
new file mode 100644
index 00000000000..5eeeeb167cd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
@@ -0,0 +1,27 @@
+!
+! { dg-do run }
+! Testcase from Harald Anlauf
+! fortran/pr114024
+!
+program foo
+
+   implicit none
+
+   complex cmp(3)
+   real, pointer :: pp(:)
+   class(*), allocatable :: uu(:)
+   type t
+      real re, im
+   end type t
+   type u
+      type(t) tt(3)
+   end type u
+   type(u) :: cc
+
+   cmp = (3.,4.)
+   cc%tt%re = cmp%re
+   cc%tt%im = cmp%im
+   allocate (pp, source = cc%tt%im)       ! ICE
+   if (any(pp /= [4., 4., 4.])) stop 1
+   allocate (uu, source = cc%tt%im)       ! ICE
+end

Re: [PATCH] Fix fortran/PR114024

[Harald Anlauf]

Hi Steve!

On 2/22/24 01:52, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
>> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
>>> On 2/21/24 22:00, Steve Kargl wrote:
>>>> memleak vs ICE.  I think I'll take one over the other.
>>>> Probably need to free code->expr3 before the copy.
>>>
>>> Yep.
>>>
>>>> I tried gfc_replace_expr in an earlier patch.  It did not
>>>> work.
>
>
> I tried freeing code->expr3 before assigning the new expression.
> That leads to
>
> % gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
> pid 69473 comm f951 has trashed its stack, killing
> gfortran: internal compiler error: Illegal instruction signal terminated program f951

Right.  I also don't see what the lifetimes of the expressions are.

But is the gfc_copy_expr really needed?  Wouldn't the following suffice?

   code->expr3 = gfc_get_parentheses (code->expr3);

> If I don't free code->expr3 but simply assign the new
> expression from gfc_get_parentheses(), your example
> now compiles are executes are expected.  It now
> allocate_with_source_28.f90.  Caveat:  I don't know
> how to test the CLASS uu.
>
>>>>> - it still fails on the following code, because the traversal
>>>>>     of the refs is incomplete / wrong:
>>>>>
>>>>> program foo
>>>>>      implicit none
>>>>>      complex               :: cmp(3)
>>>>>      real, pointer         :: pp(:)
>>>>>      class(*), allocatable :: uu(:)
>>>>>      type t
>>>>>         real :: re
>>>>>         real :: im
>>>>>      end type t
>>>>>      type u
>>>>>         type(t) :: tt(3)
>>>>>      end type u
>>>>>      type(u) :: cc
>>>>>
>>>>>      cmp = (3.45,6.78)
>>>>>      cc% tt% re = cmp% re
>>>>>      cc% tt% im = cmp% im
>>>>>      allocate (pp, source = cc% tt% im)       ! ICE
>>>>
>>>> cc%tt%im isn't a complex-part-ref, so this seems to
>>>> be a different (maybe related) issue.  Does the code
>>>> compile with 'source = (cc%tt%im)'?  If so, perhaps,
>>>> detecting a component reference and doing the simply
>>>> wrapping with parentheses can be done.
>>>
>>> Yes, that's why I tried to make up the above example.
>>> I think %re and %im are not too special, they work
>>> here pretty much like component refs elsewhere.
>>>
>>
>> I see.  The %re and %im complex-part-ref correspond to
>> ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
>> A part-ref for a user-defined type doesn't have an
>> INQUIRY_xxx, so we'll need to see if there is a way to
>> easily identify, e.g., cc%tt%re from your testcase.
>
> The attach patch uses ref->type == REF_COMPONENT to deal
> with the above code.

I actually wanted to draw your attention away from the
real/complex stuff, because that is not really the point.
When do we actually need to enforce the parentheses?

I tried the following, and it seems to work:

       if (code->expr3->expr_type == EXPR_VARIABLE
	  && is_subref_array (code->expr3))
	code->expr3 = gfc_get_parentheses (code->expr3);

(Beware: this is not regtested!)

On the positive side, it not only seems to fix the cases in question,
but also substring references etc., like the following:

program foo
   implicit none
   complex               :: cmp(3) = (3.45,6.78)
   real, pointer         :: pp(:)
   integer, allocatable  :: aa(:)
   class(*), allocatable :: uu(:), vv(:)
   type t               ! pseudo "complex" type
      real :: re
      real :: im
   end type t
   type ci              ! "complex integer" type
      integer :: re
      integer :: im
   end type ci
   type u
      type(t)  :: tt(3)
      type(ci) :: ii(3)
   end type u
   type(u) :: cc
   character(3)              :: str(3) = ["abc","def","ghi"]
   character(:), allocatable :: ac(:)

   allocate (ac, source=str(1::2)(2:3))
   print *, str(1::2)(2:3)
   call my_print (ac)
   cc% tt% re = cmp% re
   cc% tt% im = cmp% im
   cc% ii% re = nint (cmp% re)
   cc% ii% im = nint (cmp% im)
   print *, "re=", cc% tt% re
   print *, "im=", cc% tt% im
   allocate (pp, source = cc% tt% re)
   print *, pp
   allocate (uu, source = cc% tt% im)
   call my_print (uu)
   allocate (vv, source = cc% ii% im)
   call my_print (vv)
contains
   subroutine my_print (x)
     class(*), intent(in) :: x(:)
     select type (x)
     type is (real)
        print *, "'real':", x
     type is (integer)
        print *, "'integer':", x
     type is (character(*))
        print *, "'character':", x
     end select
   end subroutine my_print
end

Cheers,
Harald

Re: [PATCH] Fix fortran/PR114024

[Steve Kargl]

On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
> Hi Steve!
> 
> On 2/22/24 01:52, Steve Kargl wrote:
> > On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> > > On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > > > On 2/21/24 22:00, Steve Kargl wrote:
> > > > > memleak vs ICE.  I think I'll take one over the other.
> > > > > Probably need to free code->expr3 before the copy.
> > > > 
> > > > Yep.
> > > > 
> > > > > I tried gfc_replace_expr in an earlier patch.  It did not
> > > > > work.
> > 
> > I tried freeing code->expr3 before assigning the new expression.
> > That leads to
> > 
> > % gfcx -c ~/gcc/gccx/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
> > pid 69473 comm f951 has trashed its stack, killing
> > gfortran: internal compiler error: Illegal instruction signal terminated program f951
> 
> Right.  I also don't see what the lifetimes of the expressions are.
> 
> But is the gfc_copy_expr really needed?  Wouldn't the following suffice?
> 
>   code->expr3 = gfc_get_parentheses (code->expr3);

It's been awhile since I use gfc_copy_expr, gfc_replace_expr, etc.
I did not try the above.  If that works, then we should use that
for simplicity.

> > If I don't free code->expr3 but simply assign the new
> > expression from gfc_get_parentheses(), your example
> > now compiles are executes are expected.  It now
> > allocate_with_source_28.f90.  Caveat:  I don't know
> > how to test the CLASS uu.
> > 
> > > > > > - it still fails on the following code, because the traversal
> > > > > >     of the refs is incomplete / wrong:
> > > > > > 
> > > > > > program foo
> > > > > >      implicit none
> > > > > >      complex               :: cmp(3)
> > > > > >      real, pointer         :: pp(:)
> > > > > >      class(*), allocatable :: uu(:)
> > > > > >      type t
> > > > > >         real :: re
> > > > > >         real :: im
> > > > > >      end type t
> > > > > >      type u
> > > > > >         type(t) :: tt(3)
> > > > > >      end type u
> > > > > >      type(u) :: cc
> > > > > > 
> > > > > >      cmp = (3.45,6.78)
> > > > > >      cc% tt% re = cmp% re
> > > > > >      cc% tt% im = cmp% im
> > > > > >      allocate (pp, source = cc% tt% im)       ! ICE
> > > > > 
> > > > > cc%tt%im isn't a complex-part-ref, so this seems to
> > > > > be a different (maybe related) issue.  Does the code
> > > > > compile with 'source = (cc%tt%im)'?  If so, perhaps,
> > > > > detecting a component reference and doing the simply
> > > > > wrapping with parentheses can be done.
> > > > 
> > > > Yes, that's why I tried to make up the above example.
> > > > I think %re and %im are not too special, they work
> > > > here pretty much like component refs elsewhere.
> > > > 
> > > 
> > > I see.  The %re and %im complex-part-ref correspond to
> > > ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively.
> > > A part-ref for a user-defined type doesn't have an
> > > INQUIRY_xxx, so we'll need to see if there is a way to
> > > easily identify, e.g., cc%tt%re from your testcase.
> > 
> > The attach patch uses ref->type == REF_COMPONENT to deal
> > with the above code.
> 
> I actually wanted to draw your attention away from the
> real/complex stuff, because that is not really the point.
> When do we actually need to enforce the parentheses?

This is essentially my concern.  I was inserting parentheses
only if I determined they were needed (to avoid unnecessary
temporary variable).  The code paththat enters the else portion
of the following if-else-stmt, where a temporary is created.
That is, 

allocate(x, source=z%re) becomes allocate(x, source=(z%re))
and from code generation viewpoint this is

tmp = (z%re)
allocate(x, sourcer=tmp)
deallocate(tmp)

> I tried the following, and it seems to work:
> 
>       if (code->expr3->expr_type == EXPR_VARIABLE
> 	  && is_subref_array (code->expr3))
> 	code->expr3 = gfc_get_parentheses (code->expr3);
> 
> (Beware: this is not regtested!)
> 
> On the positive side, it not only seems to fix the cases in question,
> but also substring references etc., like the following:

If the above passes a regression test, then by all means we should
use it.  I did not consider the substring case.  Even if unneeded
parentheses are inserted, which may cause generation of a temporary
variable, I hope users are not using 'allocate(x,source=z%re)' is
some deeply nested crazy loops structure.

BTW, my patch and I suspect your improved patch also
fixes 'allocate(x,mold=z%re)'.  Consider,

   complex z(3)
   real, allocatable :: x(:)
   z = 42
   allocate(x, mold=z%re)
   print *, size(x)
   end

% gfortran13 -o z a.f90
a.f90:9:25:

    9 |    allocate(x, mold=z%re)
      |                         1
internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6070
0x247d7a679 __libc_start1
        /usr/src/lib/libc/csu/libc_start1.c:157

% gfcx -o z a.f90 && ./z
           3



-- 
Steve

Re: [PATCH] Fix fortran/PR114024

[Harald Anlauf]

On 2/22/24 22:01, Steve Kargl wrote:
> On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
>> On the positive side, it not only seems to fix the cases in question,
>> but also substring references etc., like the following:
>
> If the above passes a regression test, then by all means we should
> use it.  I did not consider the substring case.  Even if unneeded
> parentheses are inserted, which may cause generation of a temporary
> variable, I hope users are not using 'allocate(x,source=z%re)' is
> some deeply nested crazy loops structure.

First thing is code correctness.  There are cases where the
allocation shall preserve the array bounds, which is where
we must avoid the parentheses at all cost.  But these cases
should be very limited.  (There are some code comments/TODOs
regarding this and an open PR by Tobias(?)).

The cases we are currently discussing are even requiring(!)
the resetting of the lower bounds to 1, so your suggestion
to enforce parentheses does not look unreasonable.

BTW: If someone uses allocate in a tight loop, he/she deserves
to be punished anyway...

> BTW, my patch and I suspect your improved patch also
> fixes 'allocate(x,mold=z%re)'.  Consider,
>
>     complex z(3)
>     real, allocatable :: x(:)
>     z = 42ha
>     allocate(x, mold=z%re)
>     print *, size(x)
>     end
>
> % gfortran13 -o z a.f90
> a.f90:9:25:
>
>      9 |    allocate(x, mold=z%re)
>        |                         1
> internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6070
> 0x247d7a679 __libc_start1
>          /usr/src/lib/libc/csu/libc_start1.c:157
>
> % gfcx -o z a.f90 && ./z
>             3
>

Nice!  I completely forgot about MOLD...

So the only missing pieces are a really comprehensive testcase
and successful regtests...

Cheers,
Harald

[PATCH, v2] Fix fortran/PR114024

[Harald Anlauf]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Hi Steve, all,

here's an updated patch with an enhanced testcase that also
checks MOLD= besides SOURCE=.

Regtested on x86_64-pc-linux-gnu.  Is it OK for mainline?

Cheers,
Harald

On 2/22/24 22:32, Harald Anlauf wrote:
> On 2/22/24 22:01, Steve Kargl wrote:
>> BTW, my patch and I suspect your improved patch also
>> fixes 'allocate(x,mold=z%re)'.  Consider,
>>
>>     complex z(3)
>>     real, allocatable :: x(:)
>>     z = 42ha
>>     allocate(x, mold=z%re)
>>     print *, size(x)
>>     end
>>
>> % gfortran13 -o z a.f90
>> a.f90:9:25:
>>
>>      9 |    allocate(x, mold=z%re)
>>        |                         1
>> internal compiler error: in retrieve_last_ref, at
>> fortran/trans-array.cc:6070
>> 0x247d7a679 __libc_start1
>>          /usr/src/lib/libc/csu/libc_start1.c:157
>>
>> % gfcx -o z a.f90 && ./z
>>             3
>>
>
> Nice!  I completely forgot about MOLD...
>
> So the only missing pieces are a really comprehensive testcase
> and successful regtests...

[-- Attachment #2: pr114024-v2.diff --]
[-- Type: text/x-patch, Size: 5446 bytes --]

From a176c2f44f812d82aeb430fadf23ab4b6dd5bd65 Mon Sep 17 00:00:00 2001
From: Steve Kargl <kargl@gcc.gnu.org>
Date: Fri, 23 Feb 2024 22:05:04 +0100
Subject: [PATCH] Fortran: ALLOCATE statement, SOURCE/MOLD expressions with
 subrefs [PR114024]

	PR fortran/114024

gcc/fortran/ChangeLog:

	* trans-stmt.cc (gfc_trans_allocate): When a source expression has
	substring references, part-refs, or %re/%im inquiries, wrap the
	entity in parentheses to force evaluation of the expression.

gcc/testsuite/ChangeLog:

	* gfortran.dg/allocate_with_source_27.f90: New test.
	* gfortran.dg/allocate_with_source_28.f90: New test.

Co-Authored-By: Harald Anlauf <anlauf@gmx.de>
---
 gcc/fortran/trans-stmt.cc                     | 10 ++-
 .../gfortran.dg/allocate_with_source_27.f90   | 20 +++++
 .../gfortran.dg/allocate_with_source_28.f90   | 90 +++++++++++++++++++
 3 files changed, 118 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
 create mode 100644 gcc/testsuite/gfortran.dg/allocate_with_source_28.f90

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..e09828e218b 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6355,8 +6355,14 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
 	vtab_needed = (al->expr->ts.type == BT_CLASS);
 
       gfc_init_se (&se, NULL);
-      /* When expr3 is a variable, i.e., a very simple expression,
-	     then convert it once here.  */
+      /* When expr3 is a variable, i.e., a very simple expression, then
+	 convert it once here.  If one has a source expression that has
+	 substring references, part-refs, or %re/%im inquiries, wrap the
+	 entity in parentheses to force evaluation of the expression.  */
+      if (code->expr3->expr_type == EXPR_VARIABLE
+	  && is_subref_array (code->expr3))
+	code->expr3 = gfc_get_parentheses (code->expr3);
+
       if (code->expr3->expr_type == EXPR_VARIABLE
 	  || code->expr3->expr_type == EXPR_ARRAY
 	  || code->expr3->expr_type == EXPR_CONSTANT)
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
new file mode 100644
index 00000000000..d0f0f3c4a84
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_27.f90
@@ -0,0 +1,20 @@
+!
+! { dg-do run }
+!
+! fortran/PR114024
+! https://github.com/fujitsu/compiler-test-suite
+! Modified from Fortran/0093/0093_0130.f90
+!
+program foo
+   implicit none
+   complex :: cmp(3)
+   real, allocatable :: xx(:), yy(:), zz(:)
+   cmp = (3., 6.78)
+   allocate(xx, source = cmp%re)          ! This caused an ICE.
+   allocate(yy, source = cmp(1:3)%re)     ! This caused an ICE.
+   allocate(zz, source = (cmp%re))
+   if (any(xx /= [3., 3., 3.])) stop 1
+   if (any(yy /= [3., 3., 3.])) stop 2
+   if (any(zz /= [3., 3., 3.])) stop 3
+end program foo
+
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
new file mode 100644
index 00000000000..976c567cf22
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_28.f90
@@ -0,0 +1,90 @@
+! { dg-do run }
+!
+! PR fortran/114024
+
+program foo
+  implicit none
+  complex :: cmp(3) = (3.,4.)
+  type ci           ! pseudo "complex integer" type
+     integer :: re
+     integer :: im
+  end type ci
+  type cr           ! pseudo "complex" type
+     real :: re
+     real :: im
+  end type cr
+  type u
+     type(ci) :: ii(3)
+     type(cr) :: rr(3)
+  end type u
+  type(u) :: cc
+
+  cc% ii% re = nint (cmp% re)
+  cc% ii% im = nint (cmp% im)
+  cc% rr% re = cmp% re
+  cc% rr% im = cmp% im
+ 
+ call test_substring ()
+  call test_int_real ()
+  call test_poly ()
+
+contains
+
+  subroutine test_substring ()
+    character(4)              :: str(3) = ["abcd","efgh","ijkl"]
+    character(:), allocatable :: ac(:)
+    allocate (ac, source=str(1::2)(2:4))
+    if (size (ac) /= 2 .or. len (ac) /= 3) stop 11
+    if (ac(2) /= "jkl")                    stop 12
+    deallocate (ac)
+    allocate (ac, mold=str(1::2)(2:4))
+    if (size (ac) /= 2 .or. len (ac) /= 3) stop 13
+    deallocate (ac)
+  end
+
+  subroutine test_int_real ()
+    integer, allocatable  :: aa(:)
+    real, pointer         :: pp(:)
+    allocate (aa, source = cc% ii% im)
+    if (size (aa) /= 3)      stop 21
+    if (any (aa /= cmp% im)) stop 22
+    allocate (pp, source = cc% rr% re)
+    if (size (pp) /= 3)      stop 23
+    if (any (pp /= cmp% re)) stop 24
+    deallocate (aa, pp)
+  end
+
+  subroutine test_poly ()
+    class(*), allocatable :: uu(:), vv(:)
+    allocate (uu, source = cc% ii% im)
+    allocate (vv, source = cc% rr% re)
+    if (size (uu) /= 3) stop 31
+    if (size (vv) /= 3) stop 32
+    call check (uu)
+    call check (vv)
+    deallocate (uu, vv)
+    allocate (uu, mold = cc% ii% im)
+    allocate (vv, mold = cc% rr% re)
+    if (size (uu) /= 3) stop 33
+    if (size (vv) /= 3) stop 34
+    deallocate (uu, vv)
+  end
+
+  subroutine check (x)
+    class(*), intent(in) :: x(:)
+    select type (x)
+    type is (integer)
+       if (any (x /= cmp% im)) then
+          print *, "'integer':", x
+          stop 41
+       end if
+    type is (real)
+       if (any (x /= cmp% re)) then
+          print *, "'real':", x
+          stop 42
+       end if
+    type is (character(*))
+       print *, "'character':", x
+    end select
+  end
+end
-- 
2.35.3

Re: [PATCH, v2] Fix fortran/PR114024

[rep.dot.nop]

On 23 February 2024 22:15:17 CET, Harald Anlauf <anlauf@gmx.de> wrote:
>Hi Steve, all,
>
>here's an updated patch with an enhanced testcase that also
>checks MOLD= besides SOURCE=.
>
>Regtested on x86_64-pc-linux-gnu.  Is it OK for mainline?

LGTM
cheers

>
>Cheers,
>Harald

Re: [PATCH, v2] Fix fortran/PR114024

[Steve Kargl]

On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote:
> Hi Steve, all,
> 
> here's an updated patch with an enhanced testcase that also
> checks MOLD= besides SOURCE=.
> 
> Regtested on x86_64-pc-linux-gnu.  Is it OK for mainline?
> 

From my viewpoint, yes.

Thanks for finding a better solution than I had conjured.

-- 
Steve