public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: David Brown <david@westcontrol.com>
Cc: Manuel Rigger <manuel.rigger@jku.at>,
	gcc@gcc.gnu.org, s.marr@kent.ac.uk,        bram.adams@polymtl.ca
Subject: Re: Unused GCC builtins
Date: Mon, 22 Jan 2018 16:07:00 -0000	[thread overview]
Message-ID: <20180122160659.GJ2063@tucnak> (raw)
In-Reply-To: <5A66097E.7010005@westcontrol.com>

On Mon, Jan 22, 2018 at 04:55:42PM +0100, David Brown wrote:
> Many of these are going to be used automatically by the compiler.  You
> write "strdup" in your code, and the compiler treats it as
> "__builtin_strdup".  I don't know that such functions need to be
> documented as extensions, but they are certainly in use.
> 
> You will also find that a large number of the builtins are for specific
> target processors, and projects using them are not going to turn up on
> GitHub.  They will be used in embedded software that is not open source.

Not just that.  If the statistics e.g. ignored GCC headers, then obviously
it will miss most of the target builtins, because the normal and only
supported way for the target builtins is to use them through the intrinsic
inline functions or macros provided by those headers.
So, take those out (usually a vendor ABI is something that says what
intrinsics are provided, so even if you made statistics on what intrinsic is
used in the 5000 most popular projects, we still couldn't remove them) and
taking out the above category, where the builtins are just an alternative
for a standard function and depending on prototype and chosen standard some
functions are treated like builtins, pretty much nothing remains in your
survey.

	Jakub

  parent reply	other threads:[~2018-01-22 16:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 15:47 Manuel Rigger
2018-01-22 15:55 ` David Brown
2018-01-22 16:02   ` Joel Sherrill
2018-01-22 16:07   ` Jakub Jelinek [this message]
2018-01-22 16:10   ` Andrew Pinski
2018-01-22 18:30 ` Florian Weimer
2018-01-24 14:05   ` Manuel Rigger
2018-01-24 14:10     ` Jakub Jelinek
2018-01-24 18:15       ` Florian Weimer
2018-01-27 19:11       ` Martin Sebor

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=20180122160659.GJ2063@tucnak \
    --to=jakub@redhat.com \
    --cc=bram.adams@polymtl.ca \
    --cc=david@westcontrol.com \
    --cc=gcc@gcc.gnu.org \
    --cc=manuel.rigger@jku.at \
    --cc=s.marr@kent.ac.uk \
    /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).