From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23983 invoked by alias); 20 Nov 2013 22:07:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23970 invoked by uid 89); 20 Nov 2013 22:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from Unknown (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 20 Nov 2013 22:07:29 +0000 Received: by mail-ob0-f174.google.com with SMTP id wn1so4639582obc.33 for ; Wed, 20 Nov 2013 14:07:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RZ6WR0U2ZCw2IGGpZEz0NuFazdvVhpEXor1lDN1mu3A=; b=VuubqHUeEqaf7BOMbpjoum38OoVBxSExpFr1iXi5NoWs6UIZGCpRkC+LTr2l3Rbb18 PeT85F02Wok4h9p9RgUCtYcXSIrWEZpcdgWnbzrrXQD5d9JBZ/FJUfaUbXkcnzhnSW3V BI3Bx0hPEtap2D3+DK09vpXn07j8mMzT734hkHSNHm9wm+rIllqSp+QzSI1mkSieOmQe QgbtCDl+eIRiVipz+17Cp7CKVxIsZlklOH6YRLqcClVcURK6VxMdxXFgHWCtDsoqqSZZ JMHkeVYjPGByCaycqxplKKZxZCtDM+5CQkZvitzO2vsWgYN3aH0pOiOdfqjSlCWUGn35 kgAA== X-Gm-Message-State: ALoCoQnTBUOksQ1gzOzumwMJCrg+bPff3uFk6oZjHRT/9vr7mndLes3O5lIU6Ba9JrkUIoURCYTF0u+NdIuda99zRp9xTohnEkCFSeeggKhm9Yurb7P9SUj+Q3xZh3faR9NOTSk7WqNeaPxdTU5nan9XwrOGhhZqfoQ/IdEWtFMhzuMnY7v0fEkkqKN0HdjLjnO4wdoxP5x9asqskq0IG/vCMM+XU183SA== MIME-Version: 1.0 X-Received: by 10.60.68.10 with SMTP id r10mr2359752oet.62.1384985241641; Wed, 20 Nov 2013 14:07:21 -0800 (PST) Received: by 10.182.32.39 with HTTP; Wed, 20 Nov 2013 14:07:21 -0800 (PST) In-Reply-To: References: <20121221064539.0E1A7100704@rong.mtv.corp.google.com> <20121221092532.GA7055@kam.mff.cuni.cz> <50EB31B7.9090307@redhat.com> Date: Thu, 21 Nov 2013 00:07:00 -0000 Message-ID: Subject: Re: atomic update of profile counters (issue7000044) From: Rong Xu To: "Joseph S. Myers" Cc: Andrew Pinski , Richard Henderson , Richard Biener , Xinliang David Li , Jan Hubicka , GCC Patches , reply@codereview.appspotmail.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg02635.txt.bz2 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. 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 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