https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #3) > The tree level gets this right and on x86_64 RTL expansion looks ok as well. > Can it be that PPC relies on REG_POINTER stuff and maybe the function > pointer isn't marked that way? > > That said, looks like a RTL / backend issue to me. The opd stores were removed by tree dse: --- pr64703.c.090t.phicprop1 2015-01-21 10:41:50.673199149 +0100 +++ pr64703.c.091t.dse1 2015-01-21 10:41:50.674199132 +0100 @@ -42,12 +42,9 @@ resolve_ifunc (long unsigned int value, _10 = func_9->fd_func; _11 = sym_map_4(D)->l_addr; _12 = _10 + _11; - opd.fd_func = _12; _14 = func_9->fd_toc; _15 = _11 + _14; - opd.fd_toc = _15; _17 = func_9->fd_aux; - opd.fd_aux = _17; value_19 = (long unsigned int) &opd; <bb 6>: so I don't see how this would be a RTL or backend problem. Though, of course the backend would need to somehow explain to the aliasing machinery that it has something like function descriptors and what they really mean for function calls. Unless we want to disable DSE altogether before any function calls, eek.
