[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 23 Jul 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
> 
> --- Comment #29 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #28)
> 
> > -fdump-tree-all-uid without the space 
> 
> OK, so this works.
> 
> What we have in the *.004t.original dump is
> 
>     fs ();
>     {
>       struct __class_f_S_p rhs.2D.3928;
> 
>       rhs.2D.3928 = c_ ();
>       resD.3913._vptrD.3910 = rhs.2D.3928._vptrD.3910;
>       resD.3913._dataD.3909 = rhs.2D.3928._dataD.3909;
>     }
> 
> which looks, good and in *.005t.gimple
> 
>         fs ();
>         {
>           struct __class_f_S_p rhs.2D.3928;
> 
>           try
>             {
>               c_.5_10 = c_D.3927;
>               rhs.2D.3928 = c_.5_10 ();
>               _11 = rhs.2D.3928._vptrD.3910;
>               resD.3913._vptrD.3910 = _11;
>               _12 = rhs.2D.3928._dataD.3909;
>               resD.3913._dataD.3909 = _12;
>             }
>           finally
>             {
>               rhs.2D.3928 = {CLOBBER};
>             }
>         }
> 
> From the naming convention, the variable c_D.3927 looks like something
> generated by the front end, but it's not there in the *.original dump:
> 
> $ grep 3927 proc_ptr_51.f90.00*
> proc_ptr_51.f90.005t.gimple:              c_.5_10 = c_D.3927;
> proc_ptr_51.f90.007t.omplower:              c_.5_10 = c_D.3927;
> proc_ptr_51.f90.008t.lower:          c_.5_10 = c_D.3927;
> 
> So, there might possibly be something wrong about
> 
>       rhs.2D.3928 = c_ ();
> 
> but what?

  c_D.3918 = cD.3925;
  c_.5_12 = c_D.3933;
  rhs.2D.4008 = c_.5_12 ();

which is what I showed.  So the initialization of 'c_' happens
to the variable with UID 3918 while the read from 'c_' happens
through the variable with UID 3933.  Looking at the fortran
source I assume 'c_' is a global variable so we should only
have one, correct?

I can see in .original (x86_64 btw!)

fs ()
{
  c_D.3918 = cD.3925;
  return;
}

MAIN__ ()
{
  extern struct __class_f_S_p (*<T5da>) (void) c_D.3951;
(!)
...
      rhs.2D.3934 = c_ ();

(unfortunately we don't dump the UID here, but it's 3933).

this is gimplified to

              c_.5_10 = c_D.3933;
              rhs.2D.3934 = c_.5_10 ();

so this is yet another variable!?  (again extern declared)

So something is odd with how the frontend handles 'c_'.

The symbol table has two:

__f_MOD_c_/2 (c_) @0x7f763892d300
  Type: variable definition analyzed
  Visibility: public
  References:
  Referring: __f_MOD_fs/6 (write)
  Availability: not-ready
  Varpool flags:

__f_MOD_c_/15 (c_) @0x7f763892df80
  Type: variable
  Visibility: external public
  previous sharing asm name: 2
  References:
  Referring: MAIN__/8 (read)
  Availability: not-ready
  Varpool flags:

In principle this might work out but it seems that on powerpc
one gets a section anchor while the other not and we end up
disambiguating based on that.

So I'd say frontends are not expected to do this.  For example
the C fronted for a similar

void f(){}

void (*g)();
void bar()
{
  g = f;
}

int main()
{
  extern void (*g)();
  bar();
  g();
}

produces

bar ()
{
  gD.1909 = fD.1907;
}

main ()
{
  intD.6 D.1917;

  {
    extern voidD.51 (*<T1f4>) () gD.1915;
^^ for debug info only

    bar ();
    g.0_1 = gD.1909; // g, merged with the earlier definition
    g.0_1 ();
  }
  D.1917 = 0;
  return D.1917;
}

since the variables are not recorded as aliases but only
share the assembler name nothing in symtab_node::equal_address_to
fires.  On x86 you are lucky enough that load and store are not
re-ordered (even with -fschedule-insns).