Ping. Is this alright to apply now or should I wait for Stage 1?
* plugin-api.h (ld_plugin_get_wrap_symbols): New
plugin interface.
Thanks
Sri
On Thu, Feb 15, 2018 at 1:52 PM, Sriraman Tallam wrote:
> Ping, this patch was approved for binutils by Cary:
> https://sourceware.org/ml/bi
On Fri, Dec 8, 2017 at 11:02 AM, Sriraman Tallam wrote:
> Patch attached.
>
> * plugin-api.h (ld_plugin_get_wrap_symbols): New
> plugin interface.
>
> On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam wrote:
>> Hi,
>>
>>This patch was approved for binutils b
ri
>
> Thanks,
> Stephen
>
> On Mon, Dec 11, 2017 at 2:10 PM, Sriraman Tallam wrote:
>> On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote:
>>>> include/ChangeLog:
>>>> 2017-11-09 Stephen Crane
>>>>
>>>> * plugi
it's not too much trouble. I think much has changed to need a
> rebase?
Ok, let me apply your patch. I will get back if there are inconsistencies.
Thanks
Sri
>
> Thanks,
> Stephen
>
> On Mon, Dec 11, 2017 at 2:10 PM, Sriraman Tallam wrote:
>> On Thu, Nov 9, 2017
On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote:
>> include/ChangeLog:
>> 2017-11-09 Stephen Crane
>>
>> * plugin-api.h: Add new plugin hook to allow processing of input
>> files added by a plugin.
>> (ld_plugin_new_input_handler): New funcion hook type.
>> (l
Patch attached.
* plugin-api.h (ld_plugin_get_wrap_symbols): New
plugin interface.
On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam wrote:
> Hi,
>
>This patch was approved for binutils by Cary:
> https://sourceware.org/ml/binutils/2017-12/msg00023.html
>
>Is it ok to
Hi,
This patch was approved for binutils by Cary:
https://sourceware.org/ml/binutils/2017-12/msg00023.html
Is it ok to apply this to GCC include/plugin-api.h ?
Thanks
Sri
On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote:
> > include/ChangeLog:
> > 2017-11-09 Stephen Crane
> >
> > * plugin-api.h: Add new plugin hook to allow processing of input
> > files added by a plugin.
> > (ld_plugin_new_input_handler): New funcion hook type.
> >
On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote:
> > include/ChangeLog:
> > 2017-11-09 Stephen Crane
> >
> > * plugin-api.h: Add new plugin hook to allow processing of input
> > files added by a plugin.
> > (ld_plugin_new_input_handler): New funcion hook type.
> >
On Thu, Sep 21, 2017 at 5:29 PM, Cary Coutant wrote:
>> 2017-09-21 Stephen Crane
>>
>> * plugin-api.h: Add new hook to the plugin transfer vector to
>> support assigning plugin-generated sections to unique output
>> segments.
>> (ld_plugin_register_new_input): New
On Mon, Oct 5, 2015 at 2:58 PM, Sriraman Tallam wrote:
> On Wed, Sep 9, 2015 at 4:01 PM, Sriraman Tallam wrote:
>> On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam wrote:
>>>
>>> On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote:
>>> >> Thanks, wi
On Wed, Sep 9, 2015 at 4:01 PM, Sriraman Tallam wrote:
> On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam wrote:
>>
>> On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote:
>> >> Thanks, will make those changes. Do you recommend a different name
>> >> for
On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam wrote:
>
> On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote:
> >> Thanks, will make those changes. Do you recommend a different name
> >> for this flag like -fmake-comdat-functions-static?
> >
> > Well,
On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote:
>> Thanks, will make those changes. Do you recommend a different name
>> for this flag like -fmake-comdat-functions-static?
>
> Well, the C++ ABI refers to this as "vague linkage." It may be a bit
> too long or too ABI-specific, but maybe somet
On Tue, Aug 18, 2015 at 2:14 PM, Cary Coutant wrote:
> Based on Richard's suggestion, I have a patch to localize comdat
> functions which seems like a very effective solution to this problem.
> The text size increase is limited to the extra comdat copies generated
> for the special
On Wed, Aug 12, 2015 at 10:36 PM, Sriraman Tallam wrote:
> On Tue, Aug 4, 2015 at 11:43 AM, Sriraman Tallam wrote:
>> On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam wrote:
>>> On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li
>>> wrote:
>>>>>
>
On Tue, Aug 4, 2015 at 11:43 AM, Sriraman Tallam wrote:
> On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam wrote:
>> On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li
>> wrote:
>>>>
>>>> Hm. But which options are unsafe? Also wouldn't it be bet
On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam wrote:
> On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li wrote:
>>>
>>> Hm. But which options are unsafe? Also wouldn't it be better to simply
>>> _not_ have unsafe options produce comdats but always make l
On Fri, Apr 17, 2015 at 5:36 AM, H.J. Lu wrote:
> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
>> On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>>> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
>>> > creating yet another library for that.
>>> > So, IMH
On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li wrote:
>>
>> Hm. But which options are unsafe? Also wouldn't it be better to simply
>> _not_ have unsafe options produce comdats but always make local clones
>> for them (thus emit the comdat with "unsafe" flags dropped)?
>
> Always localize com
On Thu, Jun 4, 2015 at 10:05 AM, Richard Henderson wrote:
> On 06/04/2015 09:54 AM, Sriraman Tallam wrote:
>> + DECL_ATTRIBUTES (SYMBOL_REF_DECL (XEXP(fnaddr, 0)
>
> Spacing.
>
>> {
>> use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OF
> Patch attached with those changes.
Is this patch alright to commit?
* c-family/c-common.c (noplt): New attribute.
(handle_noplt_attribute): New handler.
* calls.c (prepare_call_address): Check for noplt attribute.
* config/i386/i386.c (ix86_function_ok_for_sibcall): Check
for noplt attribute.
On Wed, Jun 3, 2015 at 1:09 PM, Richard Henderson wrote:
> On 06/03/2015 11:38 AM, Sriraman Tallam wrote:
>> + { "no_plt", 0, 0, true, false, false,
>> + handle_no_plt_attribute, false },
>
> Call it noplt. We don&#x
>
> I agree now that it will be much cleaner just to punt this into the backend,
> so it may be worth noting that making this work properly for the non-PIC
> case requires quite a degree of massaging in the backends.
>
> Objections withdrawn.
Thanks!, I have attached the latest patch after making
On Tue, Jun 2, 2015 at 1:56 PM, Ramana Radhakrishnan
wrote:
> On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan
>> wrote:
>>> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote:
>>>> On
On Tue, Jun 2, 2015 at 12:32 PM, Bernhard Reutner-Fischer
wrote:
> On June 2, 2015 8:15:42 PM GMT+02:00, Sriraman Tallam
> wrote:
> []
>
>>I have now modified this patch.
>>
>>This patch does two things:
>>
>>1) Adds new generic function attribute "
On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan
wrote:
> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan
>> wrote:
>>> On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote:
>>>> On
On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan
wrote:
> On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan
>> wrote:
>>>
>>>>> Why isn't it just an indirect call in the cases that woul
On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan
wrote:
>
>>> Why isn't it just an indirect call in the cases that would require a GOT
>>> slot and a direct call otherwise ? I'm trying to work out what's so
>>> different on each target that mandates this to be in the target backend.
>>> Also i
On Fri, May 29, 2015 at 3:24 PM, Ramana Radhakrishnan
wrote:
>
>
> On Friday, 29 May 2015, Sriraman Tallam wrote:
>>
>> On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka wrote:
>> >> * config/i386/i386.c (avoid_plt_to_call): New function.
>> >>
Made one more change and New patch attached.
Thanks
Sri
On Fri, May 29, 2015 at 2:37 PM, Sriraman Tallam wrote:
> On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka wrote:
>>> * config/i386/i386.c (avoid_plt_to_call): New function.
>>> (ix86_output_call_insn): Gener
On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka wrote:
>> * config/i386/i386.c (avoid_plt_to_call): New function.
>> (ix86_output_call_insn): Generate indirect call for functions
>> marked with "noplt" attribute.
>> (attribute_spec ix86_attribute_): Define new attribute "nopl
+Uros
On Fri, May 29, 2015 at 10:25 AM, H.J. Lu wrote:
> On Fri, May 29, 2015 at 10:20 AM, Sriraman Tallam wrote:
>> Hi HJ,
>>
>> Is this ok to commit?
>>
>
> Looks good to me. But I can't approve it.
>
> --
> H.J.
Hi HJ,
Is this ok to commit?
Thanks
Sri
On Thu, May 28, 2015 at 11:03 PM, Sriraman Tallam wrote:
> On Thu, May 28, 2015 at 5:05 PM, H.J. Lu wrote:
>> On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam wrote:
>>> On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
>>>>
On Thu, May 28, 2015 at 5:05 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at 2:0
On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 2:01 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at 12:0
On Thu, May 28, 2015 at 2:01 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 12:05 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at
On Thu, May 28, 2015 at 12:05 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 11:42 AM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam
>>> wrote:
>>>> I have attached a p
On Thu, May 28, 2015 at 11:42 AM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam wrote:
>> I have attached a patch that adds the new attribute "noplt". Please review.
>>
>> * config/i386/i386.c (avoid_plt_to_call): New function.
>> (ix86
ibute "noplt".
* doc/extend.texi: Document new attribute "noplt".
* gcc.target/i386/noplt-1.c: New testcase.
* gcc.target/i386/noplt-2.c: New testcase.
Thanks
Sri
On Fri, May 22, 2015 at 2:00 AM, Pedro Alves wrote:
> On 05/21/2015 11:02 PM, Sriraman Tallam wrote:
>
On Fri, May 22, 2015 at 2:00 AM, Pedro Alves wrote:
> On 05/21/2015 11:02 PM, Sriraman Tallam wrote:
>> On Thu, May 21, 2015 at 2:51 PM, Pedro Alves wrote:
>>> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>>>>
>>>> My original proposal, for x86_64 only
On Thu, May 21, 2015 at 2:51 PM, Pedro Alves wrote:
> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>>
>> My original proposal, for x86_64 only, was to add
>> -fno-plt=. This lets the user decide for which
>> functions PLT must be avoided. Let the compiler always g
On Thu, May 21, 2015 at 2:12 PM, Sriraman Tallam wrote:
> On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>>
>> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>>
>> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>>> On Mon, May 4, 2015 at 7
On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>
> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>
> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>> On Mon, May 4, 2015 at 7:45 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 30 Apr 201
On Tue, May 19, 2015 at 10:22 AM, Yury Gribov wrote:
> On 05/19/2015 09:16 AM, Sriraman Tallam wrote:
>>
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like to hear
On Tue, May 19, 2015 at 2:39 AM, Richard Biener
wrote:
> On Tue, May 19, 2015 at 8:16 AM, Sriraman Tallam wrote:
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like t
We have the following problem with selectively compiling modules with
-m options and I have provided a solution to solve this. I would
like to hear what you think.
Multi versioning at module granularity is done by compiling a subset
of modules with advanced ISA instructions, supported on later
ge
>>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
>>>> Sriraman Tallam writes:
>>>>>
>>>>> This comes with caveats. This cannot be generally done for all
>>>>> functions marked extern as it is impossible for the compiler to say i
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
> Sriraman Tallam writes:
>>
>> This comes with caveats. This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if
>> a function is "truly extern"
On Thu, Apr 30, 2015 at 8:21 PM, Alan Modra wrote:
> On Thu, Apr 30, 2015 at 05:31:30PM -0700, Sriraman Tallam wrote:
>> This comes with caveats. This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if
>> a func
Hi,
We noticed that one of our benchmarks sped-up by ~1% when we
eliminated PLT stubs for some of the hot external library functions
like memcmp, pow. The win was from better icache and itlb
performance. The main reason was that the PLT stubs had no spatial
locality with the call-sites. I have st
On Thu, Feb 5, 2015 at 2:23 PM, H.J. Lu wrote:
> On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam wrote:
>> On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson wrote:
>>> On 02/05/2015 11:01 AM, H.J. Lu wrote:
>>>> Can you elaborate why it depends on COPY relo
On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson 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 a weak
On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu wrote:
> On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam wrote:
>> On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu wrote:
>>> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek wrote:
>>>> On Wed, Feb 04, 2015 at 10:38:48AM -080
On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu wrote:
> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek 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_
On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu wrote:
> On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek 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 guaran
On Tue, Feb 3, 2015 at 1:29 PM, H.J. Lu wrote:
> On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam wrote:
>> On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek wrote:
>>> On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
>>>> This was the original patch to
On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek 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.
>>
>&g
+davidxl +ccoutant
On Tue, Feb 3, 2015 at 11:25 AM, Sriraman Tallam wrote:
> On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu wrote:
>> On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak wrote:
>>> On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu wrote:
>>>
>>>>>>>&g
On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu wrote:
> On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak wrote:
>> On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu wrote:
>>
It would probably help reviewers if you pointed to actual path
submission [1], which unfortunately contains the explanation
Ping.
On Mon, Nov 10, 2014 at 3:22 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam
>> wrote:
>>> Ping.
>>>
>>> On Fri, S
Ping.
On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam wrote:
>>> Hi Richard,
>>>
>>> I also ra
On Tue, Nov 4, 2014 at 10:47 AM, Uros Bizjak wrote:
> On Tue, Nov 4, 2014 at 10:46 AM, Uros Bizjak wrote:
>
>>> Following patch fixes PR 63538, where the data in the large data
>>> section was accessed through 32bit address. The patch unifies places
>>> where large data sections are determined an
On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li wrote:
> On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam wrote:
>> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote:
>>> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam
>>> wrote:
>>>> On
On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote:
> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote:
>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li
>> wrote:
>>> Why removing the tree_code check?
>>
>> The actual problem happens bec
er case where the constant goes into
rodata but is not accessed via a VAR_DECL. Also note that TREE_STATIC
(decl) is true for STRING_CST.
Thanks
Sri
>
> David
>
> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote:
>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David
CODE check to do the
right thing so this seems unnecessary & buggy here.
Thanks
Sri
>
> David
>
> On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam wrote:
>> Hi,
>>
>>This patch is under review for trunk GCC :
>> https://gcc.gnu.org/ml/gcc-patches/2014-
Hi,
This patch is under review for trunk GCC :
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html.
In the mean time, is this ok for google/gcc-4_9 branch? Without
this, -mcmodel=medium is unusable if .lrodata goes beyond the 2G
boundary.
Thanks
Sri
Index: testsuite/gcc.dg/pr63538.c
Hi,
I have attached patch for bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538
Please review.
Thanks
Sri
With -mcmodel=medium, .lrodata accesses must use far address. Here
the check for TREE_CODE(decl) == VAR_DECL in function ix86_encode_section_info
is removed as this does not handl
On Thu, Oct 9, 2014 at 3:34 PM, Cary Coutant wrote:
If adding a new option, you need to document it in invoke.texi.
>>>
>>> Patch updated.
>>
>> Is this alright for google/gcc-4_9?
>
> +no-pie
> +Driver RejectNegative Negative(pie)
> +Create a position dependent executable
>
> I'd suggest add
On Mon, Oct 6, 2014 at 4:19 PM, Sriraman Tallam wrote:
> On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers
> wrote:
>> If adding a new option, you need to document it in invoke.texi.
>
> Patch updated.
Is this alright for google/gcc-4_9?
Sri
>
> Thanks
> Sri
&g
On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers wrote:
> If adding a new option, you need to document it in invoke.texi.
Patch updated.
Thanks
Sri
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Add a negative for option -pie: -no-pie builds a position dependent executable.
Note that -no-pie
Hi,
A build tool we are using adds -pie by default and I am adding
-no-pie to override this when necessary.
Is this patch alright? Would this be suitable for trunk?
Thanks
Sri
Add a negative for option -pie: -no-pie builds a position dependent executable.
Note that -no-pie also negates a pri
Ping.
On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam wrote:
> Ping.
>
> On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam wrote:
>> Hi Richard,
>>
>> I also ran the gcc testsuite with
>> RUNTESTFLAGS="--tool_opts=-mcopyrelocs" to check for issues. T
Ping.
On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam 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
. I linked with gold to make
the test pass.
Could you please take another look at this patch?
Thanks
Sri
On Mon, Sep 8, 2014 at 3:19 PM, Sriraman Tallam wrote:
> On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson wrote:
>> On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
>>&g
On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson wrote:
> On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
>> Index: config/i386/i386.c
>> ===
>> --- config/i386/i386.c(revision 211826)
>
Ping.
On Fri, Jul 11, 2014 at 10:42 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam wrote:
>> Hi Uros,
>>
>>Could you please review this patch?
>>
>> Thanks
>> Sri
>>
>> On Fri, Jun 20, 2
Ping.
On Wed, Aug 6, 2014 at 2:42 PM, Sriraman Tallam wrote:
> Hi,
>
> Just wondering if you got a chance to look at this?
>
> Sri
>
> On Tue, Jul 8, 2014 at 10:45 AM, Sriraman Tallam wrote:
>> On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
>>>
Hi,
Just wondering if you got a chance to look at this?
Sri
On Tue, Jul 8, 2014 at 10:45 AM, Sriraman Tallam wrote:
> On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
>> On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka wrote:
>>> Hello,
>>> I apologize for taki
Ping.
On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam wrote:
> Hi Uros,
>
>Could you please review this patch?
>
> Thanks
> Sri
>
> On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam wrote:
>> Patch Updated.
>>
>> Sri
>>
>> On Mon, Ju
On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
> On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka wrote:
>> Hello,
>> I apologize for taking so long to get into this patch. I ad busy time
>> (wedding
>> and teaching), should be back in regular schedule now.
names
> within one comdat groups are same, perhaps it was part of the reverted patch
> for AIX. I will try to get that one back in now.
>
> Jan
>>
>> Thanks,
>>
>> David
>>
>> On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam
>> wrote:
>
Hi,
I have attached a patch for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599. Is this alright?
Thanks
Sri
Patch to fix PR 61599:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
Function int_size_in_bytes returns -1 in as the size in cases where
the size of the type can var
Hi Uros,
Could you please review this patch?
Thanks
Sri
On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam wrote:
> Patch Updated.
>
> Sri
>
> On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, May 19, 2014 at 11:11 AM, Sri
Hi Honza,
Could you review this patch when you find time?
Thanks
Sri
On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam
>
Patch Updated.
Sri
On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam
>> wrote:
>>> Optimize access to globals
Ping.
On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam
>> wrote:
>>> Ping.
>>>
>>> On
Ping.
On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote:
>>> Hi,
>>>
>>> I would like this p
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam wrote:
>> Optimize access to globals with -fpie, x86_64 only:
>>
>> Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
On Thu, May 22, 2014 at 5:04 PM, Xinliang David Li wrote:
> Also missing documentation in invoke.texi? Other than that, ok.
I have made the changes and committed my patch.
Sri
>
> David
>
> On Thu, May 22, 2014 at 5:00 PM, Paul Pluzhnikov
> wrote:
>> On Thu, May 22, 2
This patch is pending review for trunk. Please see if this is ok to
commit to google/gcc-4_8 branch. Please see this for more details:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html
Patch attached.
Thanks
Sri
Index: config/i386/i386.c
===
Ping.
On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam wrote:
> Ping.
>
> On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> I would like this patch reviewed and considered for commit when
>> Stage 1 is active again.
>>
>> Patch
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam 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 gl
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 defi
Ping.
On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote:
> Hi,
>
> I would like this patch reviewed and considered for commit when
> Stage 1 is active again.
>
> Patch Description:
>
> A C++ thunk's section name is set to be the same as the original function&#
On Tue, Feb 11, 2014 at 4:39 PM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 4:32 PM, Sriraman Tallam wrote:
>> On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson wrote:
>>>
>>> On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote:
>>>>
>
On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson wrote:
>
> On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote:
>>
>> On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson
>> wrote:
>> > On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam
>> > wrote:
>
On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson wrote:
> On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam wrote:
>> Hi Teresa,
>>
>>I have attached a patch to recognize and reorder split functions in
>> the function reordering plugin. Please review.
>
Hi Teresa,
I have attached a patch to recognize and reorder split functions in
the function reordering plugin. Please review.
Thanks
Sri
This enhances the linker plugin to reorder functions that are split when
using -freorder-blocks-and-partition.
Index: function_reordering_plugin/callgraph.h
1 - 100 of 364 matches
Mail list logo
