Plan to Update GPC

Kevan Hashemi hashemi at
Wed Jun 3 15:03:44 CEST 2020

Dear Tom,

> At least now there is some record and maybe that will help
> the next person to work on this.

I'll add two more comments that explain why I gave up on the GNU Compiler Collection.

(7) Waldek has GPC compiling on GCC 4.3.5. As I describe in (5) and (6), I was unable to build GCC 4.3.5 on MacOS. But I do have GCC 4.9.4, installed by Home Brew. So I thought, "Surely I can just use 4.9.4, maybe a few tweaks will be required." But no, it's not just a few tweaks. Between GCC 4.3.5 and 4.9.4, the GCC people made dramatic changes to the interface between the front end and the middle end. The file varray.c is gone. The definition of the GENERIC tree structure is scattered through a bunch of new files and is incompatible with the old structures.

The GCC team claim their objective is to provide a platform upon which we can create front-ends for any and all languages we want. It's the "GNU Compiler Collection". It's a great idea. It's the idea that drew me into GPC and GCC in the first place. We can combine FORTRAN, Pascal, and C and link them into one executable. It was great.

But fundamental to any such endeavor is a firm commitment to backward compatibility. Making dramatic changes to the trees interface that break other people's front ends is absolutely contrary to the "compiler collection" philosophy. The GCC team has abandoned its mission. Maybe they have recovered their sense of direction in the past ten years, since GCC 4, heading into GCC 11, but I doubt it.

And that's when I gave up. I hate C, that's why I program in Pascal. Spending hundreds of hours programming in C to get a Pascal compiler to work was going to be painful. So I switched to FPC. And now I discover that the secondary problems with GCC (it's a pain in the neck) have been obscuring its primary problems.

(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit. Most compile-time optimisation takes place in the middle and back ends, not the front end. So, after all that fuss, and making so much work for Waldek and the rest of the GPC writers, the GCC crew still can't produce efficient code. And because GCC compiles itslef, the compiler itself is slow. Compiling my code with FPC goes twice as fast as compiling with GCC.

My conclusion is that GCC is a disorganised and ineffectual mess. The header and macro arrangement beloved of C has created a monstrous body of code that is almost impossible to compile and is being modified continuously by people who don't want to maintain the version they released six months ago, even though that version was dramatically different from the version they released a year ago. I note that MacOS abandoned GCC, switching to CLANG, and Windows does not appear to use GCC at all. Only on Linux is GCC common, but people are starting to build Linux with CLANG, so we'll see what the future holds for GCC. I'm not optimistic.

Best, Kevan

Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University

More information about the Gpc mailing list