Single File GCC

https://people.csail.mit.edu/smcc/projects/single-file-programs/

Most frequent identifiers:
10080 = static
10280 = x1
10350 = it
11068 = that
11099 = tree
11898 = x2
12039 = t
12594 = this
13272 = void
13350 = operands
13520 = and
15022 = we
15561 = goto
15719 = i
16125 = in
16314 = xexp
16897 = int
17138 = x
20050 = for
20788 = else
22959 = of
23499 = is
23643 = rtx
24553 = to
25456 = insn
25936 = a
28287 = case
32008 = return
61014 = the
74058 = if

1283 = continue
1432 = license
1766 = gnu


So for every loop continue statement there is a GPL license text :D

Total words: 2218042
Unique words: 57067

I wonder how much faster they compile compared to the original spam of .h and .c files.

>>5
Disk access will be much faster, because continuous file. Preprocessor and parser should also run much faster, since all that header crap now processed only once. But optimization algorithms will be much slower since they have so much more stuff to deal with on the global scale. The resulting code should be a bit faster though. Edited on 08/10/2020 23:04.

>>5
Disk access will be much faster, because continuous file. Predecessor and parser should also run much faster, since all that header crap now processed only once. But optimization algorithms will be much slower since they have so much more stuff to deal with on the global scale. The resulting code should be a bit faster though.
Disk access will be much faster, because continuous file. Preprocessor and parser should also run much faster, since all that header crap now processed only once. But optimization algorithms will be much slower since they have so much more stuff to deal with on the global scale. The resulting code should be a bit faster though.

>>6
`Much faster' and `a bit faster' mean fuckall bud. Is that twice as fast? 100x faster? 1%?
I was wondering about actual numbers not your handwaving bullshit.

>>7
Try testing it.

But I'm dead sure, if you're not compiling with optimizations, most of the time is taken by make, which runs bash, and which in turn invokes GCC for each single file. That is why Common Lisp SBCL compiles at such lightning speed, even despite Lisp being two times slower than C. So it makes sense to integrate the make-system into the compiler, while at the same time packing the static parts of the build tree inside a zip archive. LZ can be unpacked faster than read from disk, and C/C++ files compress really well, especially with pre-trained dictionary packer.

C build system is a mess.

C is a mess, in general. If we weren't stuck with so much legacy C-based code I'd say it should be left on a mainframe in the 70s where it belongs.