public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Manuel Rigger" <manuel.rigger@jku.at>
To: <gcc@gcc.gnu.org>
Cc: <s.marr@kent.ac.uk>,<bram.adams@polymtl.ca>
Subject: Unused GCC builtins
Date: Mon, 22 Jan 2018 15:47:00 -0000	[thread overview]
Message-ID: <5A66076F0200008100014BC3@s05gw02.im.jku.at> (raw)

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


             reply	other threads:[~2018-01-22 15:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 15:47 Manuel Rigger [this message]
2018-01-22 15:55 ` David Brown
2018-01-22 16:02   ` Joel Sherrill
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=5A66076F0200008100014BC3@s05gw02.im.jku.at \
    --to=manuel.rigger@jku.at \
    --cc=bram.adams@polymtl.ca \
    --cc=gcc@gcc.gnu.org \
    --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).