public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: Andre Vehreschild <vehre@gmx.de>,
	GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: Re: [Fortran, Patch, PR 96992] Fix Class arrays of different ranks are rejected as storage association argument
Date: Sun, 16 Jun 2024 23:27:46 +0200	[thread overview]
Message-ID: <2b124dcc-d96a-4f6b-a3a9-d730ffec29f9@gmx.de> (raw)
Message-ID: <20240616212746.YuUBTILG_01i-k917xZ0gvpBo9_pZA6Lzd0G0wZsvRI@z> (raw)
In-Reply-To: <20240614170546.4180607f@vepi2>

Hi Andre,

Am 14.06.24 um 17:05 schrieb Andre Vehreschild:
> Hi all,
>
> I somehow got assigned to this PR so I fixed it. GFortran was ICEing because of
> the ASSUME_RANK in a derived to class conversion. After fixing this, storage
> association was producing segfaults. The "shape conversion" of the class array
> as dummy argument was not initializing the dim 0 stride and with that grabbing
> into the memory somewhere. This is now fixed and
>
> regtests fine on x86_64 Fedora 39. Ok for mainline?

the patch fixes the testcase in your submission, but not the following
slight variation of the main program:

module foo_mod
   implicit none
   type foo
      integer :: i
   end type foo
contains
   subroutine d1(x,n)
     integer, intent(in) :: n
     integer :: i
     class (foo), intent(out) :: x(n)
     select type(x)
     class is(foo)
        x(:)%i = (/ (42 + i, i = 1, n ) /)
     class default
        stop 1
     end select
   end subroutine d1
   subroutine d2(x,n)
     integer, intent(in) :: n
     integer :: i
     class (foo), intent(in) :: x(n,n,n)
     select type (x)
     class is (foo)
        print *,x%i
        if ( any( x%i /= reshape((/ (42 + i, i = 1, n ** 3 ) /), [n, n,
n] ))) stop 2
     class default
        stop 3
     end select
   end subroutine d2
end module foo_mod
program main
   use foo_mod
   implicit none
   type (foo), dimension(:), allocatable :: f
   integer :: n
   n = 2
   allocate (f(n*n*n))
   ! Original testcase:
   call d1(f,n*n*n)
   call d2(f,n)                  ! OK
   call d1(f(1:n*n*n),n*n*n)
   print *, "After call d1(f(1:n*n*n:1),n*n*n):"
   print *, f%i
   call d2(f(1:n*n*n),n)         ! OK
   ! Using stride -1:
   call d1(f(n*n*n:1:-1),n*n*n)
   print *, "After call d1(f(n*n*n:1:-1),n*n*n):"
   print *, f%i
   call d2(f(n*n*n:1:-1),n)      ! not OK
   deallocate (f)
end program main

While this runs fine with the latest Intel compiler, gfortran including
your patch prints:

           43          44          45          46          47
48          49          50
  After call d1(f(1:n*n*n:1),n*n*n):
           43          44          45          46          47
48          49          50
           43          44          45          46          47
48          49          50
  After call d1(f(n*n*n:1:-1),n*n*n):
           50          49          48          47          46
45          44          43
           43           0           0          49           0
34244976           0    34238480
STOP 2

So while the negative stride (-1) in the call to d1 appears to
work as it should, it does not work properly for the call to d2.
The first array element is fine in d2, but anything else isn't.

Do you see what goes wrong here?

(This may be a more general, pre-existing issue in a different place.)

Thanks,
Harald

P.S.: regarding your commit message, I think the reference to the pr
in brackets should be moved to the end of the summary line, i.e. for

Fortran: [PR96992] Fix rejecting class arrays of different ranks as
storage association argument.

the "[PR96992" should be moved.  Makes it also easier to read.

> I assume this patch could be fixing some other PRs with class array's parameter
> passing, too. If that sounds familiar, feel free to point me to them.
>
> Regards,
> 	Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de


  reply	other threads:[~2024-06-16 21:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 15:05 Andre Vehreschild
2024-06-16 21:27 ` Harald Anlauf [this message]
2024-06-16 21:27   ` Harald Anlauf
2024-06-19  7:07   ` Andre Vehreschild
2024-06-19 19:17     ` Harald Anlauf
2024-06-19 19:17       ` Harald Anlauf
2024-07-03 10:58       ` [Fortran, Patch, PR 96992, V3] " Andre Vehreschild

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b124dcc-d96a-4f6b-a3a9-d730ffec29f9@gmx.de \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=vehre@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).