PR96325 should be high priority

PR96325 should be high priority

[Steve Kargl]

This bug

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

should be a high priority for anyone trying to improve
gfortran.  Not only does gfortran accept an invalid 
Fortran program, the wrong code is simply bad.

Simplified testcase:

program bar 
   implicit none

   type t2
      integer r1
   end type

   type(t2) :: t
   integer :: a
   
   a = t%r1%foo(1)   ! There is no foo component/TBP.
   if (a == 42) stop
end

-fdump-tree-original gives

MAIN__ ()
{
  integer(kind=4) a;
  struct t2 t;

  a = 1;
  if (a == 42)
    {
      _gfortran_stop_string (0B, 0, 0);
    }
  L.1:;
}

and -fdump-parse-tree shows

Namespace: A-Z: (UNKNOWN 0)
procedure name = bar
  symtree: 'T2'          || symbol: 't2'           
    type spec : (UNKNOWN 0)
    attributes: (DERIVED )
    components: 
    (r1 (INTEGER 4) ())
    hash: 48537418
    Procedure bindings:
    Operator bindings:
  symtree: 'a'           || symbol: 'a'            
    type spec : (INTEGER 4)
    attributes: (VARIABLE )
  symtree: 'bar'         || symbol: 'bar'          
    type spec : (UNKNOWN 0)
    attributes: (PROGRAM PUBLIC  SUBROUTINE)
  symtree: 't'           || symbol: 't'            
    type spec : (DERIVED t2)
    attributes: (VARIABLE )
  symtree: 't2'          || symbol: 't2'           
    type spec : (UNKNOWN 0)
    attributes: (PROCEDURE  FUNCTION)
    Generic interfaces: t2

  code:
  ASSIGN bar:a 1
  IF (= bar:a 42)
    STOP -1
  ENDIF

I've run out of ideas on how to track this done.
Something in gfc_match_rvalue() goes sideways.

-- 
Steve

Re: PR96325 should be high priority

[Jerry DeLisle]

Regression testing your patch and will commit if it test OK with a testcase.

Jerry
On 7/28/20 8:58 AM, Steve Kargl via Fortran wrote:
> This bug
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>
> should be a high priority for anyone trying to improve
> gfortran.  Not only does gfortran accept an invalid
> Fortran program, the wrong code is simply bad.
>
> Simplified testcase:
>
> program bar
>     implicit none
>
>     type t2
>        integer r1
>     end type
>
>     type(t2) :: t
>     integer :: a
>     
>     a = t%r1%foo(1)   ! There is no foo component/TBP.
>     if (a == 42) stop
> end
>
> -fdump-tree-original gives
>
> MAIN__ ()
> {
>    integer(kind=4) a;
>    struct t2 t;
>
>    a = 1;
>    if (a == 42)
>      {
>        _gfortran_stop_string (0B, 0, 0);
>      }
>    L.1:;
> }
>
> and -fdump-parse-tree shows
>
> Namespace: A-Z: (UNKNOWN 0)
> procedure name = bar
>    symtree: 'T2'          || symbol: 't2'
>      type spec : (UNKNOWN 0)
>      attributes: (DERIVED )
>      components:
>      (r1 (INTEGER 4) ())
>      hash: 48537418
>      Procedure bindings:
>      Operator bindings:
>    symtree: 'a'           || symbol: 'a'
>      type spec : (INTEGER 4)
>      attributes: (VARIABLE )
>    symtree: 'bar'         || symbol: 'bar'
>      type spec : (UNKNOWN 0)
>      attributes: (PROGRAM PUBLIC  SUBROUTINE)
>    symtree: 't'           || symbol: 't'
>      type spec : (DERIVED t2)
>      attributes: (VARIABLE )
>    symtree: 't2'          || symbol: 't2'
>      type spec : (UNKNOWN 0)
>      attributes: (PROCEDURE  FUNCTION)
>      Generic interfaces: t2
>
>    code:
>    ASSIGN bar:a 1
>    IF (= bar:a 42)
>      STOP -1
>    ENDIF
>
> I've run out of ideas on how to track this done.
> Something in gfc_match_rvalue() goes sideways.
>

Re: PR96325 should be high priority

[Steve Kargl]

On Tue, Jul 28, 2020 at 06:42:54PM -0700, Jerry DeLisle wrote:
> Regression testing your patch and will commit if it test OK with a testcase.
> 

Saw your regression testing results in bugzilla.  gfortran
treats components and type bound procedures along different
paths through the compiler.  I've attached a new patch, which
includes a test for a TBP.

-- 
Steve

Re: PR96325 should be high priority

[Jerry DeLisle]

I would have Steve's fix committed but I muffed the git commit log 
format and it won't take.  I see the examples and the rules, etc. and no go.

My latest looks like this:

Total 6 (delta 5), reused 0 (delta 0), pack-reused 0
remote: *** ChangeLog format failed:
remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should 
be done separately from normal commits
remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/master
To git+ssh://gcc.gnu.org/git/gcc.git
  ! [remote rejected]         master -> master (hook declined)
error: failed to push some refs to 
'git+ssh://jvdelisle@gcc.gnu.org/git/gcc.git

... and locally here

$ git log

commit f16ea43e7838097fda1077f3690a6a70c4985f54 (HEAD -> master)
Author: Jerry DeLisle <jvdelisle@charter.net>
Date:   Tue Jul 28 20:12:40 2020 -0700

     Add a check for component or type bound procedure.

     2020-07-28  Steven G. Kargl  <kargl@gcc.gnu.org>

     gcc/fortran/ChangeLog:

             PR fortran/96325
             * primary.c (gfc_match_varspec): Check for either a
             component or a type bound procedure of the derived type.

     Co-Authored-By:  Jerry DeLisle  <jvdelisle@gcc.gnu.org>


Is it the date entry off, since I started last night on this?

On 7/28/20 6:42 PM, Jerry DeLisle via Fortran wrote:
> Regression testing your patch and will commit if it test OK with a 
> testcase.
>
> Jerry
> On 7/28/20 8:58 AM, Steve Kargl via Fortran wrote:
>> This bug
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>>
>> should be a high priority for anyone trying to improve
>> gfortran.  Not only does gfortran accept an invalid
>> Fortran program, the wrong code is simply bad.
>>
>> Simplified testcase:
>>
>> program bar
>>     implicit none
>>
>>     type t2
>>        integer r1
>>     end type
>>
>>     type(t2) :: t
>>     integer :: a
>>         a = t%r1%foo(1)   ! There is no foo component/TBP.
>>     if (a == 42) stop
>> end
>>
>> -fdump-tree-original gives
>>
>> MAIN__ ()
>> {
>>    integer(kind=4) a;
>>    struct t2 t;
>>
>>    a = 1;
>>    if (a == 42)
>>      {
>>        _gfortran_stop_string (0B, 0, 0);
>>      }
>>    L.1:;
>> }
>>
>> and -fdump-parse-tree shows
>>
>> Namespace: A-Z: (UNKNOWN 0)
>> procedure name = bar
>>    symtree: 'T2'          || symbol: 't2'
>>      type spec : (UNKNOWN 0)
>>      attributes: (DERIVED )
>>      components:
>>      (r1 (INTEGER 4) ())
>>      hash: 48537418
>>      Procedure bindings:
>>      Operator bindings:
>>    symtree: 'a'           || symbol: 'a'
>>      type spec : (INTEGER 4)
>>      attributes: (VARIABLE )
>>    symtree: 'bar'         || symbol: 'bar'
>>      type spec : (UNKNOWN 0)
>>      attributes: (PROGRAM PUBLIC  SUBROUTINE)
>>    symtree: 't'           || symbol: 't'
>>      type spec : (DERIVED t2)
>>      attributes: (VARIABLE )
>>    symtree: 't2'          || symbol: 't2'
>>      type spec : (UNKNOWN 0)
>>      attributes: (PROCEDURE  FUNCTION)
>>      Generic interfaces: t2
>>
>>    code:
>>    ASSIGN bar:a 1
>>    IF (= bar:a 42)
>>      STOP -1
>>    ENDIF
>>
>> I've run out of ideas on how to track this done.
>> Something in gfc_match_rvalue() goes sideways.
>>
>

Re: PR96325 should be high priority

[Richard Biener]

On Wed, Jul 29, 2020 at 3:48 PM Jerry DeLisle via Fortran
<fortran@gcc.gnu.org> wrote:
>
> I would have Steve's fix committed but I muffed the git commit log
> format and it won't take.  I see the examples and the rules, etc. and no go.
>
> My latest looks like this:
>
> Total 6 (delta 5), reused 0 (delta 0), pack-reused 0
> remote: *** ChangeLog format failed:
> remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should
> be done separately from normal commits
> remote:
> remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
> remote:
> remote: error: hook declined to update refs/heads/master
> To git+ssh://gcc.gnu.org/git/gcc.git
>   ! [remote rejected]         master -> master (hook declined)
> error: failed to push some refs to
> 'git+ssh://jvdelisle@gcc.gnu.org/git/gcc.git
>
> ... and locally here
>
> $ git log
>
> commit f16ea43e7838097fda1077f3690a6a70c4985f54 (HEAD -> master)
> Author: Jerry DeLisle <jvdelisle@charter.net>
> Date:   Tue Jul 28 20:12:40 2020 -0700
>
>      Add a check for component or type bound procedure.
>
>      2020-07-28  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>      gcc/fortran/ChangeLog:
>
>              PR fortran/96325
>              * primary.c (gfc_match_varspec): Check for either a
>              component or a type bound procedure of the derived type.
>
>      Co-Authored-By:  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
>
>
> Is it the date entry off, since I started last night on this?

You seem to be pushing the wrong thing, not only the above commit.
Try with git push -n -v which should show you what it tries to push
and where.

Richard.

> On 7/28/20 6:42 PM, Jerry DeLisle via Fortran wrote:
> > Regression testing your patch and will commit if it test OK with a
> > testcase.
> >
> > Jerry
> > On 7/28/20 8:58 AM, Steve Kargl via Fortran wrote:
> >> This bug
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
> >>
> >> should be a high priority for anyone trying to improve
> >> gfortran.  Not only does gfortran accept an invalid
> >> Fortran program, the wrong code is simply bad.
> >>
> >> Simplified testcase:
> >>
> >> program bar
> >>     implicit none
> >>
> >>     type t2
> >>        integer r1
> >>     end type
> >>
> >>     type(t2) :: t
> >>     integer :: a
> >>         a = t%r1%foo(1)   ! There is no foo component/TBP.
> >>     if (a == 42) stop
> >> end
> >>
> >> -fdump-tree-original gives
> >>
> >> MAIN__ ()
> >> {
> >>    integer(kind=4) a;
> >>    struct t2 t;
> >>
> >>    a = 1;
> >>    if (a == 42)
> >>      {
> >>        _gfortran_stop_string (0B, 0, 0);
> >>      }
> >>    L.1:;
> >> }
> >>
> >> and -fdump-parse-tree shows
> >>
> >> Namespace: A-Z: (UNKNOWN 0)
> >> procedure name = bar
> >>    symtree: 'T2'          || symbol: 't2'
> >>      type spec : (UNKNOWN 0)
> >>      attributes: (DERIVED )
> >>      components:
> >>      (r1 (INTEGER 4) ())
> >>      hash: 48537418
> >>      Procedure bindings:
> >>      Operator bindings:
> >>    symtree: 'a'           || symbol: 'a'
> >>      type spec : (INTEGER 4)
> >>      attributes: (VARIABLE )
> >>    symtree: 'bar'         || symbol: 'bar'
> >>      type spec : (UNKNOWN 0)
> >>      attributes: (PROGRAM PUBLIC  SUBROUTINE)
> >>    symtree: 't'           || symbol: 't'
> >>      type spec : (DERIVED t2)
> >>      attributes: (VARIABLE )
> >>    symtree: 't2'          || symbol: 't2'
> >>      type spec : (UNKNOWN 0)
> >>      attributes: (PROCEDURE  FUNCTION)
> >>      Generic interfaces: t2
> >>
> >>    code:
> >>    ASSIGN bar:a 1
> >>    IF (= bar:a 42)
> >>      STOP -1
> >>    ENDIF
> >>
> >> I've run out of ideas on how to track this done.
> >> Something in gfc_match_rvalue() goes sideways.
> >>
> >
>