On Fri, Feb 27, 2015 at 3:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably
On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably help reviewers if you pointed to actual path
submission [1], which
On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote:
On 02/05/2015 11:01 AM, H.J. Lu wrote:
Can you elaborate why it depends on COPY relocation? There
is no COPY relocation on x86-64.
Ho hum, we
On Thu, Feb 5, 2015 at 10:54 AM, Richard Henderson r...@redhat.com wrote:
On 02/04/2015 03:29 PM, H.J. Lu wrote:
+++ b/gcc/varasm.c
@@ -6826,11 +6826,17 @@ default_binds_local_p_1 (const_tree exp, int shlib)
(TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
{
varpool_node
On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote:
On 02/05/2015 11:01 AM, H.J. Lu wrote:
Can you elaborate why it depends on COPY relocation? There
is no COPY relocation on x86-64.
Ho hum, we appear to have switched topics mid-thread.
I agree that we cannot override
On Thu, Feb 5, 2015 at 2:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote:
On 02/05/2015 11:01 AM, H.J. Lu wrote:
Can you elaborate why it depends on
On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote:
On 02/05/2015 11:01 AM, H.J. Lu wrote:
Can you elaborate why it depends on COPY relocation? There
is no COPY relocation on x86-64.
Ho hum, we
On February 5, 2015 12:29:40 AM GMT+01:00, H.J. Lu hjl.to...@gmail.com
wrote:
On Wed, Feb 4, 2015 at 3:10 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 2:47 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On February 4, 2015 11:37:01 PM GMT+01:00, H.J. Lu
On 02/04/2015 03:29 PM, H.J. Lu wrote:
+++ b/gcc/varasm.c
@@ -6826,11 +6826,17 @@ default_binds_local_p_1 (const_tree exp, int shlib)
(TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
{
varpool_node *vnode = varpool_node::get (exp);
- if (vnode (resolution_local_p
On 02/05/2015 11:01 AM, H.J. Lu wrote:
Can you elaborate why it depends on COPY relocation? There
is no COPY relocation on x86-64.
Ho hum, we appear to have switched topics mid-thread.
I agree that we cannot override a weak symbol in the executable with even a
non-weak symbol in a shared
On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
So we aren't SYMBOL_REF_EXTERNAL_P nor
SYMBOL_REF_LOCAL_P. What do we reference?
That is
On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
Common symbol should be resolved locally for PIE.
binds_local_p yes, binds_to_current_def_p no.
Jakub
On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
Common symbol should be resolved locally for PIE.
binds_local_p yes, binds_to_current_def_p no.
Is SYMBOL_REF_LOCAL_P set to binds_local_p or
On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
Common symbol should be resolved locally for PIE.
binds_local_p yes, binds_to_current_def_p no.
On Wed, Feb 04, 2015 at 10:27:34AM -0800, Sriraman Tallam wrote:
On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
So we aren't
On Wed, Feb 4, 2015 at 10:31 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 04, 2015 at 10:27:34AM -0800, Sriraman Tallam wrote:
On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03,
On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
Common symbol should
On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb
On Wed, Feb 4, 2015 at 3:10 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 2:47 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On February 4, 2015 11:37:01 PM GMT+01:00, H.J. Lu hjl.to...@gmail.com
wrote:
On Wed, Feb 4, 2015 at 1:53 PM, Sriraman Tallam
On Wed, Feb 4, 2015 at 1:53 PM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed,
On February 4, 2015 11:37:01 PM GMT+01:00, H.J. Lu hjl.to...@gmail.com
wrote:
On Wed, Feb 4, 2015 at 1:53 PM, Sriraman Tallam tmsri...@google.com
wrote:
On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam
tmsri...@google.com
On Wed, Feb 4, 2015 at 2:47 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On February 4, 2015 11:37:01 PM GMT+01:00, H.J. Lu hjl.to...@gmail.com
wrote:
On Wed, Feb 4, 2015 at 1:53 PM, Sriraman Tallam tmsri...@google.com
wrote:
On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu
On Tue, Feb 3, 2015 at 1:35 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Feb 3, 2015 at 1:29 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On
On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
So we aren't SYMBOL_REF_EXTERNAL_P nor
SYMBOL_REF_LOCAL_P. What do we reference?
That is reasonable. There is no guarantee the extern weak symbol is local,
it could very well be non-local. All that you know about the symbols is
that
+davidxl +ccoutant
On Tue, Feb 3, 2015 at 11:25 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com
On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably help reviewers if you pointed to actual path
submission [1], which
On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
This was the original patch to i386.c to let global accesses take
advantage of copy relocations and avoid the GOT.
@@ -13113,7 +13113,11 @@ legitimate_pic_address_disp_p (rtx disp)
return true;
}
else if
On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
This was the original patch to i386.c to let global accesses take
advantage of copy relocations and avoid the GOT.
@@ -13113,7 +13113,11 @@
On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
This was the original patch to i386.c to let global accesses take
advantage of copy
On Tue, Feb 3, 2015 at 1:29 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
This was the
On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
So we aren't SYMBOL_REF_EXTERNAL_P nor
SYMBOL_REF_LOCAL_P. What do we reference?
That is reasonable. There is no guarantee the extern weak symbol is local,
it
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which further explains that this functionality is
currently only supported
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which
On Thu, Dec 4, 2014 at 5:46 PM, H.J. Lu hjl.to...@gmail.com wrote:
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which further explains that this functionality is
currently only supported
Normally, with -fPIE/-fpie, GCC accesses globals that are extern to the
module using the GOT. This is two instructions, one to get the address
of the global from the GOT and the other to get the value. If it turns
out that the global gets defined in the executable at link-time, it still
On Thu, Dec 4, 2014 at 2:19 PM, Dominique Dhumieres domi...@lps.ens.fr wrote:
Normally, with -fPIE/-fpie, GCC accesses globals that are extern to the
module using the GOT. This is two instructions, one to get the address
of the global from the GOT and the other to get the value. If it turns
On Tue, Dec 2, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to
On Wed, Dec 3, 2014 at 5:47 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
On Wed, Dec 3, 2014 at 7:01 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Dec 3, 2014 at 5:47 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at
Ping.
On Mon, Nov 10, 2014 at 3:22 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com
wrote:
Ping.
On Fri, Sep 19, 2014 at 2:11 PM,
On Mon, Sep 8, 2014 at 3:19 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson r...@redhat.com wrote:
On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
Index: config/i386/i386.c
===
---
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which further explains that this functionality is
currently only supported with gold, patched with [3].
[1]
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which further explains that this
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation in the
patch itself [2], which further explains that this
On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the
On Tue, Dec 02, 2014 at 12:16:09PM -0800, H.J. Lu wrote:
IMO, nobody will use this highly special x86_64-only option. It would
be best for gnu-ld to reach feature parity with gold as far as this
functionality is concerned. In this case, the optimization would be
auto-configured, and would
On Tue, Dec 2, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Ping.
Ping.
Ping.
Ping.
It would probably help reviewers if you pointed to
On Tue, Dec 2, 2014 at 12:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Dec 02, 2014 at 12:16:09PM -0800, H.J. Lu wrote:
IMO, nobody will use this highly special x86_64-only option. It would
be best for gnu-ld to reach feature parity with gold as far as this
functionality is
On Tue, Dec 2, 2014 at 2:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Dec 2, 2014 at 12:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Dec 02, 2014 at 12:16:09PM -0800, H.J. Lu wrote:
IMO, nobody will use this highly special x86_64-only option. It would
be best for gnu-ld to reach
Ping.
On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi Richard,
I also ran the gcc testsuite
Ping.
On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi Richard,
I also ran the gcc testsuite with
RUNTESTFLAGS=--tool_opts=-mcopyrelocs to check for issues. The only
test that
Ping.
On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi Richard,
I also ran the gcc testsuite with
RUNTESTFLAGS=--tool_opts=-mcopyrelocs to check for issues. The only
test that failed was g++.dg/tsan/default_options.C. It uses -fpie
-pie and BFD ld to link.
Hi Richard,
I also ran the gcc testsuite with
RUNTESTFLAGS=--tool_opts=-mcopyrelocs to check for issues. The only
test that failed was g++.dg/tsan/default_options.C. It uses -fpie
-pie and BFD ld to link. Since BFD ld does not support copy
relocations with -pie, it does not link. I linked with
On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson r...@redhat.com wrote:
On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
Index: config/i386/i386.c
===
--- config/i386/i386.c(revision 211826)
+++ config/i386/i386.c
On 2 September 2014 22:40:50 CEST, Richard Henderson r...@redhat.com wrote:
On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 211826)
+++ config/i386/i386.c
Ping.
On Fri, Jul 11, 2014 at 10:42 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam tmsri...@google.com wrote:
Hi Uros,
Could you please review this patch?
Thanks
Sri
On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam
On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
Index: config/i386/i386.c
===
--- config/i386/i386.c(revision 211826)
+++ config/i386/i386.c(working copy)
@@ -12691,7 +12691,9 @@ legitimate_pic_address_disp_p (rtx
Ping.
On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam tmsri...@google.com wrote:
Hi Uros,
Could you please review this patch?
Thanks
Sri
On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam tmsri...@google.com wrote:
Patch Updated.
Sri
On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam
Hi Uros,
Could you please review this patch?
Thanks
Sri
On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam tmsri...@google.com wrote:
Patch Updated.
Sri
On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam
Patch Updated.
Sri
On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com
wrote:
Optimize access to globals
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote:
Optimize access to globals with -fpie, x86_64 only:
Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote:
Optimize access to globals with -fpie, x86_64 only:
Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
module
using the GOT. This is two instructions, one to get the address of the
Optimize access to globals with -fpie, x86_64 only:
Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module
using the GOT. This is two instructions, one to get the address of the global
from the GOT and the other to get the value. If it turns out that the global
gets
63 matches
Mail list logo