public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: David Brown <david@westcontrol.com>,
	Manuel Rigger <manuel.rigger@jku.at>,
	gcc@gcc.gnu.org
Cc: s.marr@kent.ac.uk, bram.adams@polymtl.ca
Subject: Re: Unused GCC builtins
Date: Mon, 22 Jan 2018 16:02:00 -0000	[thread overview]
Message-ID: <1710b594-8989-6ed6-8457-0b7a03b087c2@oarcorp.com> (raw)
In-Reply-To: <5A66097E.7010005@westcontrol.com>



On 1/22/2018 9:55 AM, David Brown wrote:
> On 22/01/18 16:46, Manuel Rigger wrote:
>> Hi everyone,
>>
>> As part of my research, we have been analyzing the usage of GCC builtins
>> in 5,000 C GitHub projects. One of our findings is that many of these
>> builtins are unused, even though they are described in the documentation
>> (see https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions)
>> and obviously took time to develop and maintain. I’ve uploaded a CSV
>> file with the unused builtins to
>> http://ssw.jku.at/General/Staff/ManuelRigger/unused-builtins.csv.
>>
>> Details: We downloaded all C projects from GitHub that had more than 80
>> GitHub stars, which yielded almost 5,000 projects with a total of more
>> than one billion lines of C code. We filtered GCC, forks of GCC, and
>> other compilers as we did not want to incorporate internal usages of GCC
>> builtins or test cases. We extracted all builtin names from the GCC
>> docs, and also tried to find such names in the source code, which we
>> considered as builtin usages. We excluded subdirectories with GCC or
>> Clang, and removed other false positives. In total, we found 320k
>> builtin usages in these projects, and 3030 unused builtins out of a
>> total of 6039 builtins.
>>
>> What is your take on this? Do you believe that some of these unused
>> builtins could be removed from the GCC docs or deprecated? Or are they
>> used in special "niche" domains that we did not consider? If yes, do you
>> think it is worth to maintain them? Are some of them only used in C++
>> projects? Might it be possible to remove their implementations (which
>> has already happened for the Cilk Plus builtins)?
>>
>> We would be glad for any feedback.
>>
>> - Manuel
>>
> 
> 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.
> 
> I am sure there are builtins that are rarely or never used - but I doubt
> if it is anything like as many as you have identified from this survey.
> 

My first thought was that there is a lot of free and open source 
software that is not hosted at github. Larger projects are often 
self-hosted. Does this list cover all GNU, Savannah, sourceware.org, 
Apache, KDE, *BSD, Mozilla, etc projects?

You might get lucky and some like RTEMS and FreeBSD (I think) have
a github mirror. But github is not the entire universe of free and
open source software.

--joel sherrill
RTEMS

  reply	other threads:[~2018-01-22 16:02 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 [this message]
2018-01-22 16:07   ` Jakub Jelinek
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=1710b594-8989-6ed6-8457-0b7a03b087c2@oarcorp.com \
    --to=joel.sherrill@oarcorp.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).