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 rguent...@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).