GCC front-ends [LWN.net]

GCC front-ends

Posted Jan 1, 2025 18:12 UTC (Wed) by ceplm (subscriber, #41334) [Link] (7 responses)

There is and there never was anything significantly wrong with GCC. If all these projects [1] managed to work with GCC, it means to me that there is nothing significantly wrong with. The only reason for Apple’s switch to LLVM then (I am not going into battle on merits between LLVM and GCC *now*, that’s a different story) was Steve Job being a control freak, who cannot live without having complete toolset under his control, and perhaps him taking revenge on GCC for forcing him to give up on the Objective-C front end [2].

[1] https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Sup...
[2] https://github.com/JoshCheek/clisp/blob/master/doc/Why-CL... and https://www.gnu.org/philosophy/pragmatic.html

GCC front-ends

Posted Jan 1, 2025 18:18 UTC (Wed) by ceplm (subscriber, #41334) [Link]

Better URL for the CLISP-related correspondence is https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc...

GCC front-ends

Posted Jan 1, 2025 22:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> There is and there never was anything significantly wrong with GCC.

Care to remember the state of GCC around 2005? It was a crusty C codebase that still pretended to be buildable by pre-C89 compilers.

The first clang compiler set the bar on error reporting, with colored output that pinpointed the exact position of the errors. GCC later replicated that.

GCC front-ends

Posted Jan 2, 2025 17:12 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> The only reason for Apple’s switch to LLVM then ...

https://blog.robenkleene.com/2019/04/11/2012-apples-great...

It's far beyond GCC.

GCC front-ends

Posted Jan 2, 2025 17:21 UTC (Thu) by marcH (subscriber, #57642) [Link]

The GPLv2 has a political agenda but it's still just a "pure" software licence. Legal departments are not fans but they've learned to live with it.

The GPL v3 elevated the agenda much higher and reaches beyond software itself. Legal departments generally hate it. Unlike v2, it's been pretty much banned all across Apple products, see reference above.

Whether you agree with the political agenda or not is irrelevant, I'm just sticking to facts here.

GCC front-ends

Posted Jan 3, 2025 2:24 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> Steve Job being a control freak, who cannot live without having complete toolset under his control

That was never the case and it's pretty easy to prove: to this very day every macOS device carries bash (version 3.2.57), screen (version 4.0.3) and many other tools not controlled by Apple.

It was always about GPLv3. That's why Apple never upgraded past GCC 4.2.

GCC front-ends

Posted Jan 4, 2025 20:25 UTC (Sat) by Heretic_Blacksheep (guest, #169992) [Link] (1 responses)

Doesn't prove anything.

The reason that's the case is because the BSD software MacOS/Darwin are based on never upgraded past GCC 4 because of GPL v3. That's one remove. What it does say is that because LLVM has a vastly more permissive license it's more acceptable to businesses who are in the business of selling software tool sets without giving hints away of what's in their secret sauce. It's business as usual in exploiting unpaid labor whether it's gladly or grudgingly granted without doing more than tossing the open source world a bone from time to time.

GCC front-ends

Posted Jan 4, 2025 23:26 UTC (Sat) by geofft (subscriber, #59789) [Link]

> It's business as usual in exploiting unpaid labor

I would assume that the vast majority of labor that goes into LLVM is paid, much of it by Apple.

The cause of free software is hurt by pretending that free software spontaneously comes into existence from unpaid hobbyists—it means that businesses who would pay for that labor think, it's going to happen on its own whether or not we pay for it, and if we start to pay for it we might prevent it from happening.

GCC front-ends

Posted Jan 1, 2025 18:30 UTC (Wed) by jklowden (subscriber, #107637) [Link] (4 responses)

LLVM is the target, right, the low-level virtual machine? Clang is the compiler toolkit. My experience with clang over a decade ago is why we opted for GCC over clang for COBOL. If the GCC API is criticized as hard to use, it has one singular advantage over clang: it exists.

Those years ago, I wanted to use clang to parse C++, and write the metadata to a database. I left with the sense that it might be possible, but I'd have to write the manual first.

(I still *do* want to write that tool. It would underpin a source-code navigation tool for C++, something that doesn't exist for large code bases. We have C-based tools like GNU Global and cscope, and I remember using a web-based text-search engine, but nothing that could distinguish open(2) from std::stream::open(), or report the call stack that modifies a variable.)

The GCC Internals manual runs some 800 pages. Even at that, the 10% of that document devoted to front-end development woefully inadequate; after all, the ISO COBOL specification is 1280 pages, and it describes only one language. But that document, plus a tutorial example, gave us a toehold. Within a week we had the "hello world" version of a COBOL compiler. Then it was just a quick 8 or so man-years of work.

GCC front-ends

Posted Jan 1, 2025 19:07 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

The tool you want to write sounds like it could be most easily written as a client of the clangd language server.

https://clangd.llvm.org/

GCC front-ends

Posted Jan 1, 2025 22:32 UTC (Wed) by ejr (subscriber, #51652) [Link]

Having had to port front- and back-ends from LLVM 12 to 18, I concur on the lack of an API.

Both systems have their benefits and drawbacks. Neither "wins." What we had to do would have been much more painful in GCC for various reasons. But so was the forward porting. meh. That's why we're "engineers," right?

GCC front-ends

Posted Jan 2, 2025 14:58 UTC (Thu) by iabervon (subscriber, #722) [Link]

LLVM is the cross-language backend part; clang is the C family frontend part. Unlike with GCC, the same frontend is used for C, C++, and ObjC, but I assume Algol or COBOL would be a separate frontend (like Rust, for example).

GCC front-ends

Posted Jan 4, 2025 23:31 UTC (Sat) by geofft (subscriber, #59789) [Link]

I found the LLVM tutorial excellent when I was going through it recently - I got a working AOT compiler for a tiny subset of Python going in a couple of hours.

This is the opposite of what you're looking for, to be fair; I wanted to use LLVM's compilation backend with a non-C language, and you wanted to use Clang's C parser. But there is a libclang tutorial that looks brief and readable that might be what you wanted. (Perhaps it did not exist at the time.)

GCC front-ends

Posted Jan 1, 2025 20:41 UTC (Wed) by segher (subscriber, #109337) [Link]

GCC frontends are mostly stand-alone code, creating its *own* data structures. Only when converting the data *out of* the frontend you convert it to something more generic (GENERIC and/or Gimple, usually).

GCC front-ends

Posted Jan 1, 2025 22:50 UTC (Wed) by jwakely (guest, #60262) [Link]

Jose has been a contributor to GCC, binutils etc for years.