Patchwork Using -ffunction-sections and -p

login
register
mail settings
Submitter Sriraman Tallam
Date Nov. 5, 2012, 4:04 a.m.
Message ID <CAAs8HmxNf-V7AuTRPKtK7du73hKQ--0=9fW4tVk3LoLFioE4pg@mail.gmail.com>
Download mbox | patch
Permalink /patch/197134/
State New
Headers show

Comments

Sriraman Tallam - Nov. 5, 2012, 4:04 a.m.
Hi,

   Currently, using -ffunction-sections and -p together results in a
warning. I ran into this problem when compiling the kernel. This is
discussed in this thread:

http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html

Ian's reply suggests this warning is no longer necessary and can be
removed. Is this patch alright to commit with all tests passing:

        * toplev.c (process_options): Do not warn when -ffunction-sections
          and -fprofile are used together.

     {



Thanks,
-Sri.
Ian Taylor - Nov. 5, 2012, 5:03 a.m.
On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>
>    Currently, using -ffunction-sections and -p together results in a
> warning. I ran into this problem when compiling the kernel. This is
> discussed in this thread:
>
> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
>
> Ian's reply suggests this warning is no longer necessary and can be
> removed. Is this patch alright to commit with all tests passing:
>
>         * toplev.c (process_options): Do not warn when -ffunction-sections
>           and -fprofile are used together.

In that thread Jeff suggested that this be tested on Solaris and PA.
I don't know how to test on PA, but could somebody test the patch on
Solaris?

Ian
Sriraman Tallam - Nov. 14, 2012, 6:58 p.m.
On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>>
>>    Currently, using -ffunction-sections and -p together results in a
>> warning. I ran into this problem when compiling the kernel. This is
>> discussed in this thread:
>>
>> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
>>
>> Ian's reply suggests this warning is no longer necessary and can be
>> removed. Is this patch alright to commit with all tests passing:
>>
>>         * toplev.c (process_options): Do not warn when -ffunction-sections
>>           and -fprofile are used together.
>
> In that thread Jeff suggested that this be tested on Solaris and PA.
> I don't know how to test on PA, but could somebody test the patch on
> Solaris?

Is it reasonable to gate this using a target hook and start allowing
this on selected targets? For instance, i386 does not seem to have a
problem with this.

Thanks,
-Sri.

>
> Ian
Ian Taylor - Nov. 14, 2012, 8 p.m.
On Wed, Nov 14, 2012 at 10:58 AM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor <iant@google.com> wrote:
>> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>>>
>>>    Currently, using -ffunction-sections and -p together results in a
>>> warning. I ran into this problem when compiling the kernel. This is
>>> discussed in this thread:
>>>
>>> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
>>>
>>> Ian's reply suggests this warning is no longer necessary and can be
>>> removed. Is this patch alright to commit with all tests passing:
>>>
>>>         * toplev.c (process_options): Do not warn when -ffunction-sections
>>>           and -fprofile are used together.
>>
>> In that thread Jeff suggested that this be tested on Solaris and PA.
>> I don't know how to test on PA, but could somebody test the patch on
>> Solaris?
>
> Is it reasonable to gate this using a target hook and start allowing
> this on selected targets? For instance, i386 does not seem to have a
> problem with this.

At this point I don't know that any target at all has a problem with this.

Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains.  I'll approve the patch unless
somebody objects in the next 24 hours.

Ian
Jeff Law - Nov. 14, 2012, 8:04 p.m.
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
> Given that nobody has stepped forward to test it, let's just remove
> the code and see if anybody complains.  I'll approve the patch unless
> somebody objects in the next 24 hours.
I think the target to check would be 32 bit HPUX.

-ffunction-sections was largely driven by issues we wanted to resolve on 
the PA.

jeff
Ian Taylor - Nov. 14, 2012, 8:32 p.m.
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law <law@redhat.com> wrote:
> On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
>>
>> Given that nobody has stepped forward to test it, let's just remove
>> the code and see if anybody complains.  I'll approve the patch unless
>> somebody objects in the next 24 hours.
>
> I think the target to check would be 32 bit HPUX.
>
> -ffunction-sections was largely driven by issues we wanted to resolve on the
> PA.

Does anybody still have access to a 32-bit HPUX machine?

Ian
Jeff Law - Nov. 14, 2012, 10:40 p.m.
On 11/14/2012 01:32 PM, Ian Lance Taylor wrote:
> On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law <law@redhat.com> wrote:
>> On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
>>>
>>> Given that nobody has stepped forward to test it, let's just remove
>>> the code and see if anybody complains.  I'll approve the patch unless
>>> somebody objects in the next 24 hours.
>>
>> I think the target to check would be 32 bit HPUX.
>>
>> -ffunction-sections was largely driven by issues we wanted to resolve on the
>> PA.
>
> Does anybody still have access to a 32-bit HPUX machine?
:-)  I've got one gathering dust downstairs...  If David doesn't have 
one anymore, I'll fire up mine up and see what I can find...

jeff
Sriraman Tallam - Dec. 4, 2012, 9:43 p.m.
On Tue, Dec 4, 2012 at 1:31 PM, Jeff Law <law@redhat.com> wrote:
> On 12/03/2012 01:08 PM, Sriraman Tallam wrote:
>>
>> Hi Jeff,
>>
>>     Wondering if you got a chance to do this?
>
> Hmm, thinking more about this, it couldn't have been a 32 bit HPUX issue.
> First that port claims to not support -ffunction-sections -- which is true,
> we can't make arbitrarily named sections, though each function is placed
> into its own $CODE$ section/subspace.
>
> Second, even with each function in its own $CODE$ subspace, profiling works.
>
> So it couldn't have been 32 bit HPUX.
>
> I think Ian's plan of going forward and see if anyone complains is
> reasonable.  Regardless, we're talking about OSs that are > 10 years old,.
> the odds of folks building modern versions of GCC is pretty slim.  The odds
> they're building modern versions of GCC and care about both
> function-sections and profiling is probably approaching zero.
>
> Jeff
>

Patch

--- toplev.c (revision 193117)
+++ toplev.c (working copy)
@@ -1467,12 +1467,6 @@  process_options (void)
  }
     }

-  if (flag_function_sections && profile_flag)
-    {
-      warning (0, "-ffunction-sections disabled; it makes profiling
impossible");
-      flag_function_sections = 0;
-    }
-
 #ifndef HAVE_prefetch
   if (flag_prefetch_loop_arrays > 0)