[Bug fortran/94289] New: Assumed-rank array bounds resuscitate on the second call

[Bug fortran/94289] New: Assumed-rank array bounds resuscitate on the second call

[jrfsousa at gmail dot com]

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

            Bug ID: 94289
           Summary: Assumed-rank array bounds resuscitate on the second
                    call
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 48096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48096&action=edit
Code demonstrating problems.

Hi all!

Assumed-rank array bounds of the type ubound:lbound are correctly set to
1:extent on the first call but they raise again in the second call.

both on:

GNU Fortran (GCC) 9.3.1 20200322

and

GNU Fortran (GCC) 10.0.1 20200316 (experimental)

Thank you very much.

Best regards,
José Rui

P.S.- Sorry for the bad puns... :-)

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[jrfsousa at gmail dot com]

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

--- Comment #1 from José Rui Faustino de Sousa <jrfsousa at gmail dot com> ---
Hi all!

My first comment is not very clear so to elaborate a bit.

For assumed-rank arrays no temporary array descriptor with the correct bounds
is created like it is for assumed-shape arrays.

So although the array bounds are correctly reported by the lbound, ubound and
shape intrinsics the underlying array descriptor is still the original one.

And since it is the original array descriptor, not a temporary with correct
array bounds, that is passed down the call chain subsequent procedures will get
a descriptor with the wrong bounds.

This will probably imply adding assumed-rank arrays to the deferred
initialization list, which is already done (I guess accidentally) for bind(c)
procedures.

I guess by removing the condition on the first if clause in
gfc_build_dummy_array_decl and, hopefully, then in the "type_of_array" switch
in gfc_trans_deferred_vars. This will imply also solving PR93957.

Best regards,
José Rui

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-07-08

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed from at least GG7.

Note that I didn't check the validity of the expectations.

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I find the testcase confusing – but I think it works now correctly on mainline
(GCC 11), thanks to the fix for PR99043 (committed to both GCC 11 and GCC 10)
and possibly some other prior fixes.

Namely:
- if the dummy argument is a pointer/allocatable, it has the same bounds as the
dummy argument
- if is is nonallocatable nonpointer, the lower bounds are [1, 1, 1].


Can you check? (GCC 10 or GCC 11)
Can you also check whether your PR95196 is fixed with mainline (GCC 11)?

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

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

--- Comment #4 from sandra at gcc dot gnu.org ---
I'm still seeing failures on mainline head, specifically these 3 groups:

 Testing pointer array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

 Testing allocatable array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

 Testing explicit array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

I'm also confused about the validity of the expectations.  :-S

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Sandra Loosemore <sandra@gcc.gnu.org>:

https://gcc.gnu.org/g:c31d2d14f798dc7ca9cc078200d37113749ec3bd

commit r12-4629-gc31d2d14f798dc7ca9cc078200d37113749ec3bd
Author: Sandra Loosemore <sandra@codesourcery.com>
Date:   Fri Oct 22 11:08:19 2021 -0700

    Add testcase for PR fortran/94289

    2021-10-22  José Rui Faustino de Sousa  <jrfsousa@gmail.com>
                Sandra Loosemore  <sandra@codesourcery.com>

            gcc/testsuite/

            PR fortran/94289
            * gfortran.dg/PR94289.f90: New.

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #6 from sandra at gcc dot gnu.org ---
This is working now.  I've committed a slightly cleaned-up version of the
testcase (basically just exchanging the print "FAIL!"s with STOPs).  I also
convinced myself that the testcase is correct.  ;-)