public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rong Xu <xur@google.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	Richard Henderson <rth@redhat.com>,
		Richard Biener <richard.guenther@gmail.com>,
	Xinliang David Li <davidxl@google.com>,
		Jan Hubicka <hubicka@ucw.cz>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		reply@codereview.appspotmail.com
Subject: Re: atomic update of profile counters (issue7000044)
Date: Thu, 21 Nov 2013 01:24:00 -0000	[thread overview]
Message-ID: <CAF1bQ=SXZ=QL12cmDR87b1o5r+FFjDwBDcP1vHMpYjaOrvSY7Q@mail.gmail.com> (raw)
In-Reply-To: <CA+=Sn1ndfActLz81tbPHKV3m5fF70UC6p1Lfn8wX665whCCe+Q@mail.gmail.com>

OK. Sorry for miss-reading the message.
In that case, linking in libatomic becomes a separate issue. We don't
need to touch gcc.c in this patch.

Thanks,

-Rong

On Wed, Nov 20, 2013 at 2:19 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Wed, Nov 20, 2013 at 2:07 PM, Rong Xu <xur@google.com> wrote:
>> Joseph and Andrew, thanks for the suggestion. That's really helpful.
>>
>> Here is the new patch for gcc.c.
>> Basically, it's just what you have suggested: enclosing -latomic with
>> --as-needed, and using macros.
>> For the case of no --as-needed support, I use static link. (just found
>> that some code already using this in the SPEC).
>> I'm flexible on this part -- if you think this is unnecessary, I can remove.
>
>
> I think Joseph's suggestion was also to include -latomic even when not
> generating atomic profiling due to the C11 code requiring it.
>
> Thanks,
> Andrew
>
>>
>> Thanks,
>>
>> -Rong
>>
>> Index: gcc.c
>> ===================================================================
>> --- gcc.c       (revision 205053)
>> +++ gcc.c       (working copy)
>> @@ -748,6 +748,23 @@ proper position among the other output files.  */
>>      %{fvtable-verify=preinit: -lvtv -u_vtable_map_vars_start
>> -u_vtable_map_vars_end}}"
>>  #endif
>>
>> +/* This spec is for linking in libatomic in gcov atomic counter update.
>> +   We will use the atomic functions defined in libatomic, only when the builtin
>> +   versions are not available. In the case of no LD_AS_NEEDED support, we
>> +   link libatomic statically.  */
>> +
>> +#ifndef GCOV_ATOMIC_SPEC
>> +#if USE_LD_AS_NEEDED
>> +#define GCOV_ATOMIC_SPEC "%{fprofile-generate-atomic=*:" LD_AS_NEEDED_OPTION \
>> +  " -latomic} " LD_NO_AS_NEEDED_OPTION
>> +#elif defined(HAVE_LD_STATIC_DYNAMIC)
>> +#define GCOV_ATOMIC_SPEC "%{fprofile-generate-atomic=*:" LD_STATIC_OPTION \
>> +                    " -latomic " LD_DYNAMIC_OPTION "}"
>> +#else /* !USE_LD_AS_NEEDED && !HAVE_LD_STATIC_DYNAMIC  */
>> +#define GCOV_ATOMIC_SPEC "%{fprofile-generate-atomic=*:-latomic}"
>> +#endif
>> +#endif
>> +
>>  /* -u* was put back because both BSD and SysV seem to support it.  */
>>  /* %{static:} simply prevents an error message if the target machine
>>     doesn't handle -static.  */
>> @@ -771,7 +788,8 @@ proper position among the other output files.  */
>>      %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
>>      %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
>>      %(mflib) " STACK_SPLIT_SPEC "\
>> -    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
>> +    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov\
>> +      " GCOV_ATOMIC_SPEC "} " SANITIZER_SPEC " \
>>      %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
>>      %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}}}}}"
>>
>>
>>
>> On Wed, Nov 20, 2013 at 1:04 PM, Joseph S. Myers
>> <joseph@codesourcery.com> wrote:
>>> On Wed, 20 Nov 2013, Rong Xu wrote:
>>>
>>>> I could do this in the SPEC
>>>>   -Wl,-Bstatic -latomic -Wl,-Bdynamic
>>>> which would link libatomic statically.
>>>> I works for me. But it looks a little weird in gcc driver.
>>>
>>> I think we should generally link libatomic with --as-needed by default on
>>> platforms supporting --as-needed, in line with the general principle that
>>> C code just using language not library facilities (_Atomic in this case)
>>> shouldn't need any special options to link it (libatomic is like libgcc,
>>> which is linked in automatically); the trickier question is what to do
>>> with it on any systems supporting shared libraries but not --as-needed.
>>>
>>> --
>>> Joseph S. Myers
>>> joseph@codesourcery.com

  reply	other threads:[~2013-11-20 22:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21  6:45 Rong Xu
2012-12-21  9:25 ` Jan Hubicka
2012-12-21 18:38   ` Rong Xu
2012-12-28 19:33     ` Rong Xu
2012-12-28 19:35       ` Xinliang David Li
2013-01-03  1:16         ` Rong Xu
2013-01-03  1:25           ` Andrew Pinski
2013-01-03  1:29             ` Rong Xu
2013-01-03  1:31               ` Andrew Pinski
2013-01-03  9:05             ` Richard Biener
2013-01-04  0:42               ` Rong Xu
2013-01-07 20:36                 ` Richard Henderson
2013-01-07 20:56                   ` Rong Xu
2013-11-20  7:03                     ` Rong Xu
2013-11-20  7:20                       ` Andrew Pinski
2013-11-20 19:59                         ` Rong Xu
2013-11-20 20:08                           ` Andrew Pinski
2013-11-20 20:31                             ` Andrew Pinski
2013-11-20 23:18                           ` Joseph S. Myers
2013-11-21  0:07                             ` Rong Xu
2013-11-21  0:14                               ` Andrew Pinski
2013-11-21  1:24                                 ` Rong Xu [this message]
2014-05-26  6:01                       ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF1bQ=SXZ=QL12cmDR87b1o5r+FFjDwBDcP1vHMpYjaOrvSY7Q@mail.gmail.com' \
    --to=xur@google.com \
    --cc=davidxl@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=joseph@codesourcery.com \
    --cc=pinskia@gmail.com \
    --cc=reply@codereview.appspotmail.com \
    --cc=richard.guenther@gmail.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).