[Bug fortran/98022] New: ICE in gfc_assign_data_value, at fortran/data.c:468

[Bug fortran/98022] New: ICE in gfc_assign_data_value, at fortran/data.c:468

[asolokha at gmx dot com]

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

            Bug ID: 98022
           Summary: ICE in gfc_assign_data_value, at fortran/data.c:468
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-11.0.0-alpha20201122 snapshot
(g:e23f47ec4065e9eec53c4ad9db91bc36a4f90793) ICEs when compiling the following
testcase reduced from test/Semantics/data05.f90 from the flang 11.0.0 test
suite:

module ur
contains
  subroutine kn
    complex :: hm(1:1)
    data (hm(1)%re, md=1,1)/1,1/
  end subroutine kn
end module ur

% powerpc-e300c3-linux-gnu-gfortran-11.0.0 -c bq8izije.f90
f951: internal compiler error: in gfc_assign_data_value, at fortran/data.c:468
0x5acbfc gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/data.c:468
0x87f4a4 check_data_variable
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:16271
0x87f97c traverse_data_var
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:16401
0x87f97c traverse_data_list
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:16357
0x8863b6 traverse_data_var
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:16399
0x8863b6 resolve_data
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:16456
0x8863b6 resolve_types
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:17283
0x8862ab resolve_types
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:17269
0x876aee gfc_resolve(gfc_namespace*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:17373
0x876aee gfc_resolve(gfc_namespace*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/resolve.c:17354
0x868141 gfc_parse_file()
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/parse.c:6488
0x8bddbe gfc_be_parse_file
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/fortran/f95-lang.c:212

(While my target here is powerpc, the ICE is not target-dependent.)

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
   Last reconfirmed|                            |2020-11-27
             Status|UNCONFIRMED                 |NEW
            Summary|ICE in                      |[9/10/11 Regression] ICE in
                   |gfc_assign_data_value, at   |gfc_assign_data_value, at
                   |fortran/data.c:468          |fortran/data.c:468 since
                   |                            |r9-3803-ga5fbc2f36a291cbe
   Target Milestone|---                         |9.4

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r9-3803-ga5fbc2f36a291cbe.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
This is not a regression IMHO since the inquiry reference feature (ie. ...%re)
was introduced by the commit reference in comment 1.

That said, it does remove the syntax error for the non-existent feature with an
ICE.

Paul

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 49722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49722&action=edit
Tentative patch for the PR

The attached regtests OK and the following runs correctly:
module ur
contains
  function kn1() result(hm2)
    complex :: hm(1:2), hm2(1:2)
    data (hm(md)%re, md=1,2)/1.0, 2.0/
    hm2 = hm
  end function kn1

  function kn2() result(hm2)
    complex :: hm(1:2), hm2(1:2)
    data (hm(md)%im, md=1,2)/1.0, 2.0/
    hm2 = hm
  end function kn2
end module ur

  use ur
  if (any (kn1() .ne. [(1.0,0.0),(2.0,0.0)])) stop 1
  if (any (kn2() .ne. [(0.0,1.0),(0.0,2.0)])) stop 2
end

I have yet to test inquiry references of derived type components. I suspect
that a bit more work is needed.

Watch this space

Paul

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)

>   function kn1() result(hm2)
>     complex :: hm(1:2), hm2(1:2)
>     data (hm(md)%re, md=1,2)/1.0, 2.0/
>     hm2 = hm
>   end function kn1

Are you sure that this is valid Fortran?  I cannot
find anything in the Fortran standard that says hm%im
is defined.  Thus, 'hm2=hm' is referencing a variable
that is no completely defined.


19.6.1 Definition of objects and subobjects

2 Arrays, including sections, and variables of derived, character,
  or complex type are objects that consist of zero or more subobjects.
  Associations may be established between variables and subobjects and
  between subobjects of different variables. These subobjects may become
  defined or undefined.

5 A complex or character scalar object is defined if and only if all
  of its subobjects are defined.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-5959-gff2dfdef2f2e01c579dd280daa1d81fbeb4d7ac5
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 12 14:01:08 2020 +0000

    Fortran: Enable inquiry references in data statements [PR98022].

    2020-12-12  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Handle inquiry references in
            the data statement object list.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: New test.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to kargl from comment #4)
> (In reply to Paul Thomas from comment #3)
> 
> >   function kn1() result(hm2)
> >     complex :: hm(1:2), hm2(1:2)
> >     data (hm(md)%re, md=1,2)/1.0, 2.0/
> >     hm2 = hm
> >   end function kn1
> 
> Are you sure that this is valid Fortran?  I cannot
> find anything in the Fortran standard that says hm%im
> is defined.  Thus, 'hm2=hm' is referencing a variable
> that is no completely defined.
> 
> 
> 19.6.1 Definition of objects and subobjects
> 
> 2 Arrays, including sections, and variables of derived, character,
>   or complex type are objects that consist of zero or more subobjects.
>   Associations may be established between variables and subobjects and
>   between subobjects of different variables. These subobjects may become
>   defined or undefined.
> 
> 5 A complex or character scalar object is defined if and only if all
>   of its subobjects are defined.

Hi Steve,

I saw your comment a bit too late. I think that you are correct. I guess that,
at very least, I should not zero out the undefined part of the complex object?
That way it would be equivalent to using assignment to achieve the same thing
or to partially define a derived type.

I'll post on clf.

Cheers

Paul

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Dec 12, 2020 at 04:02:54PM +0000, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
> 
> --- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
> (In reply to kargl from comment #4)
> > (In reply to Paul Thomas from comment #3)
> > 
> > >   function kn1() result(hm2)
> > >     complex :: hm(1:2), hm2(1:2)
> > >     data (hm(md)%re, md=1,2)/1.0, 2.0/
> > >     hm2 = hm
> > >   end function kn1
> > 
> > Are you sure that this is valid Fortran?  I cannot
> > find anything in the Fortran standard that says hm%im
> > is defined.  Thus, 'hm2=hm' is referencing a variable
> > that is no completely defined.
> > 
> > 
> > 19.6.1 Definition of objects and subobjects
> > 
> > 2 Arrays, including sections, and variables of derived, character,
> >   or complex type are objects that consist of zero or more subobjects.
> >   Associations may be established between variables and subobjects and
> >   between subobjects of different variables. These subobjects may become
> >   defined or undefined.
> > 
> > 5 A complex or character scalar object is defined if and only if all
> >   of its subobjects are defined.
> 
> Hi Steve,
> 
> I saw your comment a bit too late. I think that you are correct. I guess that,
> at very least, I should not zero out the undefined part of the complex object?
> That way it would be equivalent to using assignment to achieve the same thing
> or to partially define a derived type.
> 
> I'll post on clf.
> 

I recall looking at this PR a long time ago, but came up empty
with ideas on how to fix it.  You've some made some progress.

It gets messy (at least to me) to determine if it is valid,
and comes from reading 8.6.7 "Data statement", carefully.
One gets to 

   A data-stmt-constant other than boz-literal-constant, null-init,
   or initial-data-target shall be compatible with its corresponding
   variable according to the rules of intrinsic assignment (10.2.1.2).
   The variable is initially defined with the value specified by the
   data-stmt-constant; if necessary, the value is converted according
   to the rules of intrinsic assignment (10.2.1.3) to a value that
   agrees in type, type parameters, and shape with the variable.

Now, we go to "what is a variable?"

   R902 variable  is designator

   R901 designator  is ...
                    or complex-part-designator
                    ...

   R915 complex-part-designator  is designator % RE
                                 or designator % IM


In your example, hm%re is real, so the rules for intrinsic
assignment to a real applies.

Of course, I could be wrong.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
The example that you give shows that setting the undefined part to zero
certainly is not correct. I updated my tree for the commit and am only just now
rebuilding. It'll be tomorrow before I put this right.

I guess that this is in the category of invalid but not forbidden. It's in the
same category as:
  complex :: a, b
  a%im = 1.0
  b = a
  print *, a, b
end

Thanks

Paul

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Dec 12, 2020 at 05:54:43PM +0000, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
> 
> --- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
> The example that you give shows that setting the undefined part to zero
> certainly is not correct. I updated my tree for the commit and am only just now
> rebuilding. It'll be tomorrow before I put this right.
> 
> I guess that this is in the category of invalid but not forbidden. It's in the
> same category as:
>   complex :: a, b
>   a%im = 1.0
>   b = a
>   print *, a, b
> end
> 

Yes, it's invalid under the same portion of section 19 I quoted earlier.
'a' is undefined because 'a%re' is undefined.  I cannot find anything
in the Standard that requires an error or a warning message.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

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

commit r11-6342-gc7256c8260afa313e019fd531574ad33ec49b9f6
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 26 16:44:24 2020 +0000

    Fortran: Correction to recent patch in light of comments [PR98022].

    2020-12-26  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Throw an error for inquiry
            references. Follow with corrected code that would provide the
            expected result and provides clean error recovery.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: Change to dg-compile and
            add errors for inquiry references.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:259c63ce6d73f05bec3f84f36305ee71e435b62e

commit r10-9290-g259c63ce6d73f05bec3f84f36305ee71e435b62e
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 12 14:01:08 2020 +0000

    Fortran: Enable inquiry references in data statements [PR98022].

    2020-12-12  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Handle inquiry references in
            the data statement object list.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: New test.

    (cherry picked from commit ff2dfdef2f2e01c579dd280daa1d81fbeb4d7ac5)

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:0184527ae9f81ef3865703b43212963b95ae174d

commit r10-9291-g0184527ae9f81ef3865703b43212963b95ae174d
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 26 16:44:24 2020 +0000

    Fortran: Correction to recent patch in light of comments [PR98022].

    2020-12-26  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Throw an error for inquiry
            references. Follow with corrected code that would provide the
            expected result and provides clean error recovery.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: Change to dg-compile and
            add errors for inquiry references.

    (cherry picked from commit c7256c8260afa313e019fd531574ad33ec49b9f6)

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:87472f174299fba9b17fdbcc016818587919bd12

commit r9-9196-g87472f174299fba9b17fdbcc016818587919bd12
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 12 14:01:08 2020 +0000

    Fortran: Enable inquiry references in data statements [PR98022].

    2020-12-12  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Handle inquiry references in
            the data statement object list.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: New test.

    (cherry picked from commit ff2dfdef2f2e01c579dd280daa1d81fbeb4d7ac5)

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:5c84d9e37d6a647bc2bbc83ac28250a4902a86ea

commit r9-9197-g5c84d9e37d6a647bc2bbc83ac28250a4902a86ea
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Dec 26 16:44:24 2020 +0000

    Fortran: Correction to recent patch in light of comments [PR98022].

    2020-12-26  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98022
            * data.c (gfc_assign_data_value): Throw an error for inquiry
            references. Follow with corrected code that would provide the
            expected result and provides clean error recovery.

    gcc/testsuite/
            PR fortran/98022
            * gfortran.dg/data_inquiry_ref.f90: Change to dg-compile and
            add errors for inquiry references.

    (cherry picked from commit c7256c8260afa313e019fd531574ad33ec49b9f6)

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

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

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on all three branches.

Thanks for the report.

Paul