From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-474186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10653 invoked by alias); 21 Jan 2015 09:44:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 10593 invoked by uid 48); 21 Jan 2015 09:43:53 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64703] glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile
Date: Wed, 21 Jan 2015 09:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64703-4-GQ8NHcoTP4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64703-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64703-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02180.txt.bz2

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.