[HN Gopher] Usability Improvements in GCC 15
___________________________________________________________________
Usability Improvements in GCC 15
Author : dmalcolm
Score : 236 points
Date : 2025-04-10 14:03 UTC (1 days ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| Night_Thastus wrote:
| I'm all up for better error messaging. :)
|
| Can't use Clang where I'm at, but I _do_ get to use fairly
| cutting-edge GCC, at least for Windows development. So I may get
| to see these improvements once they drop into MSYS.
| meisel wrote:
| The template error messages look great. I wonder if it's worth
| writing a translator from clang/gcc messages to these ones, for
| users of clang and older gcc (to pipe one's error messages to)
| charcircuit wrote:
| I mean why not show a proper image instead of doing fancier
| ASCII art. Or skip it entirely and have an LLM describe the
| issues and fix it for you.
| jmclnx wrote:
| I hope gcc remains the default in Linux due to the GPL. But I
| expect someday clang will become the default.
|
| Plus I heard COBOL was merged in with the compiler collection,
| nice!
| mort96 wrote:
| GCC can honestly only blame itself for its inevitable
| increasing obsolescence. LLVM only has the attention it has
| because it can be used as a building block in other compilers.
| GCC could've made a tool and library which accepts IR, performs
| optimizations and emits machine code, but the project avoided
| that for ideological reasons, and as a result created a void in
| the ecosystem for a project like LLVM.
| Tpt wrote:
| There is now libgccjit that aims at allowing to embed gcc
| https://gcc.gnu.org/onlinedocs/jit/
|
| There is an alternative backend to rustc that relies on it.
| aengelke wrote:
| libgccjit is, despite its name, just another front-end for
| GIMPLE. The JIT-part is realized through compiling the
| object file to a shared library and using dlopen on this.
|
| One big problem with libgccjit, despite its fairly bad
| compile-time performance, is that it's GPL-licensed and
| thereby makes the entire application GPL, which makes it
| impossible to use not just in proprietary use-cases but
| also in cases where incompatible licenses are involved.
| pjmlp wrote:
| The embedded compiler vendors, UNIX and consoles are quite
| happy with it.
|
| How much do you think they contribute back upstream regarding
| ISO compliance outside LLVM backend for their hardware and
| OS?
| mort96 wrote:
| Embedded compiler vendors and UNIXes want a possibly
| slightly patched C or C++ compiler, maybe with an extra
| back-end bolted on. I'm talking about use-cases like Rust
| and Zig and Swift, projects which want a solid optimizing
| back-end but their own front-end and tooling.
| pjmlp wrote:
| And FOSS folks most likely would like to enjoy those
| patches as well on their installations.
| umanwizard wrote:
| And they do! You _can_ choose not to contribute your
| changes back to permissively-licensed software, but in
| actual practice most people do contribute them. It 's not
| like the Rust compiler is proprietary software with their
| own closed-source fork of LLVM...
| trelane wrote:
| > You can choose not to contribute your changes back to
| permissively-licensed software, but in actual practice
| most people do contribute them.
|
| They contribute _some_ things, sure. But the also _don
| 't_ contribute some things. It is hard to know how much
| because it's kept secret from all of us, even their own
| customers.
|
| > "It's not like the Rust compiler is proprietary
| software with their own closed-source fork of LLVM..."
|
| Rust no, hut there are a _lot_ of proprietary, semi-
| incompatible proprietary forks out there.
| mort96 wrote:
| I haven't advocated for re-licensing GCC to be
| permissively licensed. And patching GCC is necessarily
| going to be much easier for vendors than to build a new C
| front-end which generates GCC IR. So I'm not sure what
| difference you think what I'm proposing would make with
| regard to your concerns.
| vbezhenar wrote:
| gccrs is a rust implementation for gcc. Just because Rust
| developers don't want their users to be fully free
| doesn't mean there are any problems with gcc. And clang
| is developed by Apple which is a huge warning sign by
| itself.
| bigstrat2003 wrote:
| Rust developers don't "not want their users to be fully
| free", they disagree with you on which license is best.
| Don't deliberately phrase people's motivations in an
| uncharitable way, it's obnoxious as hell.
| mort96 wrote:
| And gccrs is not really very widely used and is not the
| "official" Rust compiler. The Rust project chose to base
| their compiler on LLVM, for good technical reasons.
| That's bad news for the GCC project.
| tmiku wrote:
| I thought that most FOSS projects took multiple compiler
| implementations as a sign of a healthy language
| environment, without much prestige associated with being
| the "premier" compiler and instead having more of an it-
| takes-a-village attitude. Granted, I'm mostly
| extrapolating from Go and Python here - is it a sharper
| divide in the Rust community?
| mort96 wrote:
| No, and I think the gccrs project is great and a sign
| that the language is maturing. I'm just saying that LLVM
| was chosen instead of GCC to build the official Rust
| compiler for very good technical reasons, and that ought
| to worry GCC.
| viraptor wrote:
| It's an early implementation of a part of rust. It's not
| even close to being able to use as the daily compiler.
| LeFantome wrote:
| LLVM/Clang is evolving more quickly than and is a much
| richer base for innovation than GCC is. LLVM spawned
| Rust, Swift, and Zig. The most recent GCC languages are
| Spark and COBOL.
|
| One of the reasons that LLVM has been able to evolve so
| quickly is because of all the corporate contribution it
| gets.
|
| GCC users want Clang/LLVM users to know how dumb they are
| for taking advantage of all the voluntary corporate
| investment in Clang/LLVM because, if you just used GCC
| instead, corporate contributions would be involuntary.
|
| The GPL teaches us that we are not really free unless we
| have taken choice away from the developers and
| contributors who provide the code we use. This is the
| "fifth freedom".
|
| The "four freedoms" that the Free Software Foundation
| talks about are all provided by MIT and BSD. Those only
| represent "partial freedom".
|
| Only the GPL makes you "fully free" by providing the
| "fifth freedom"---freedom to claim ownership over code
| other people will write in the future.
|
| Sure, the "other people" are less free. But that is the
| price that needs to be paid for our freedom. Proper
| freedom ("full freedom") is always rooted in the
| subjugation of others.
| pjmlp wrote:
| Amazon and the like appreciate indeed their freedom not
| to contribute back, while pumping the cash register.
| wolvesechoes wrote:
| Some slaves were treated well, fed nicely and overall had
| rather good life. Yet, they remained slaves, so master
| could take all of that from them at any moment.
|
| But hey, if you try hard to be nice to your master and do
| not demand anything, for sure they will always treat you
| well!
| vbezhenar wrote:
| GPL gives more freedom to software users. BSD gives more
| freedom to software developers.
|
| I think that's the core difference.
| duped wrote:
| It's not like GCC or the embedded toolchains are a shining
| beacon of ISO compliance... and if you mean video game
| consoles, are any of them using GCC today? Sony and
| Nintendo are both LLVM and Microsoft is Microsoft
| pjmlp wrote:
| The difference being that vendors forks not compliant
| with GPL can be legally asked for the changes they
| haven't sent upstream.
| bluGill wrote:
| Venders who use llvm quickly discover the cost of
| mainaining their own fork is too high and end up
| contributing back.
| pjmlp wrote:
| The point was the whole clang package, and no they don't,
| plenty of examples.
| LeFantome wrote:
| Except they do, plenty of examples (many already
| provided)
| pjmlp wrote:
| Examples yes, I provided the examples of everyone taking
| advantage while not contributing.
|
| I am still waiting for the counter examples regarding
| clang contributions.
| bluGill wrote:
| Clang is in git with good tracking of who each
| contributor is - there are more than 4000.
| duped wrote:
| With LLVM they don't need to fork it in the first place.
| But still, it doesn't matter because ISO compliance is a
| frontend problem.
|
| The one vendor who forks LLVM and doesn't contribute
| their biggest patches back is Apple, and if you want
| bleeding edge or compliance you're not using Apple Clang
| at all.
|
| If you say "isn't it great vendor toolchains have to
| contribute back to upstream?" I'm going to say "no, it
| sucks that vendor toolchains have to exist"
| mort96 wrote:
| Forcing vendors to contribute back upstream is an attempt
| at making vendor toolchains not exist.
|
| If a company makes a new MCU with some exciting new
| instruction set, they need to make a compiler available
| which supports that instruction set and make that
| compiler available to their customers.
|
| With LLVM as the base, the vendor could make their
| toolchain proprietary, making it _impossible_ to
| integrate it back into LLVM, which means the vendor
| toolchain will exist until the ISA gets wide-spread
| enough for volunteers to invest the time required to make
| a separate production-quality LLVM back-end from scratch.
|
| With GCC as the base, the vendor must at least make their
| GCC fork available to their customers under the GPL.
| This, in theory, allows the GCC community to "just"
| integrate the back-end developed by the vendor into GCC
| rather than starting from scratch.
|
| Now I don't know how effective this is, or how much it
| happens in practice that the GCC project integrates back-
| ends from vendor toolchains. But in principle, it's great
| that vendors have to make their toolchains FOSS _because_
| it reduces the need for vendor toolchains.
| dzaima wrote:
| gcc requires that contributors assign copyright to FSF
| (or at least "certify the Developer Certificate of
| Origin")[0], so a fork isn't gonna get upstreamed without
| the approval of the fork's authors. So that limits the
| benefit from gcc-forks to individuals keeping the fork
| alive.
|
| [0]: https://gcc.gnu.org/contribute.html#legal
| charcircuit wrote:
| >making it impossible to integrate it back into LLVM
|
| Code getting open source is not impossible. Companies do
| it all of the time because it's expensive to rebase.
| mort96 wrote:
| Dude you can't just quote a fraction of a sentence and
| then argue against that fragment. Read the whole
| sentence. The part about how "the vendor could make their
| toolchain proprietary" is kinda important.
| charcircuit wrote:
| My comment was about proprietary software being open
| sourced.
| mort96 wrote:
| My comment was about forcing companies to not make
| proprietary software.
| LeFantome wrote:
| Myth: GPL means more companies contribute to GCC
|
| Previous reality: companies write fully proprietary code
| to avoid GCC
|
| Current reality: companies choose Clang over GCC because
| of the license and then contribute many of their changes
| back.
| pjmlp wrote:
| So are you aware how many contributions have actually
| been upstream by Sony, Nintendo, IBM, ARM, Green Hills,
| Codegear, TI, Microchip, Codeplay, NVidia, AMD, Intel,
| HP,.... ?
|
| Because Apple certainly isn't alone.
| trelane wrote:
| The question is less what's upstream than what's _not._
| pjmlp wrote:
| The question is who is leeching clang while pumping the
| cash register.
| uecker wrote:
| GCC has very good ISO compliance and ISO C23 is better
| supported than in Clang (which I expect to catch up soon
| though)
| throwaway2037 wrote:
| Knowing the history of GCC (more focused on C) and Clang
| (more focused on C++), it makes sense to me that GCC has
| better ISO _C_ compliance.
|
| Clang has a very nice specific page for ISO C version
| compliance: https://clang.llvm.org/c_status.html#c2x
|
| I could not find the same for GCC, but I found an old one
| for C99: https://gcc.gnu.org/c99status.html
|
| CppRef has a joint page, but honestly, I am more likely
| to believe a page directly owned/controlled/authored by
| the project itself:
| https://en.cppreference.com/w/c/compiler_support/23
|
| Finally, is there a specific feature of C23 that you need
| that Clang does not support?
| bobmcnamara wrote:
| Apple, Arm, OpenBSD, FreeBSD have all switched to Clang.
| pjmlp wrote:
| Swichting wasn't the point.
| johnisgood wrote:
| Why did OpenBSD switch to clang? Licensing issues?
| umanwizard wrote:
| What exactly do you mean by "UNIX"? Commercial UNIX vendors
| other than Apple have basically a rounding error from 0% of
| market share.
| anthk wrote:
| Are you from 2001? Sorry, but Apple at servers' market
| it's non-existent. RH and Canonical make tons of money
| thanks to being THE platform of the ubiquituous internet.
| Support is not free.
| mort96 wrote:
| Are you calling Linux a UNIX? I mean GNU/Linux is
| certainly a UNIX-like system, but aren't "UNIXes"
| typically used to refer to operating systems which stem
| from AT&T's UNIX, such as the BSDs and Solaris and HP-UX
| and the like? GNU's Not UNIX after all
| johnisgood wrote:
| I have fond memories associated with OpenSolaris. Oracle
| ruined it.
|
| I have not tried OpenIndiana, however.
| anthk wrote:
| GNU isn't Unix as NT isn't Win32.
|
| Gnu promotes Unix, but also promotes Emacs on top. NT can
| run Win32 on top of it, but there's far more than Win32
| with NT systems. Just get ReactOS and open the NT object
| explorer under explorer.exe.
|
| Far more advanced than Windows 95/98.
| mort96 wrote:
| Win32 is an API, while UNIX, NT and GNU are all operating
| systems made by AT&T, Microsoft and the GNU Project
| respectively. I agree that the GNU operating system isn't
| the UNIX operating system, and I agree that the NT
| operating system isn't the Win32 API, but I have no idea
| what comparison you're trying to draw.
|
| It almost sounds like you think UNIX is an API like
| Win32, and that GNU is an operating system which
| "implements UNIX" like NT is an operating system which
| "implements Win32"? Are you confusing UNIX with POSIX?
|
| GNU was made to replace UNIX, not to promote it.
| anthk wrote:
| No, I'm not confusing Unix with POSIX, but POSIX today
| superseded old Unix. What I mean both NT and GNU enhanced
| and modernized their own subsystems.
|
| Even OpenBSD is not as 'pure Unix' as Unix V7.
| umanwizard wrote:
| Gnu/Linux and UNIX are not the same thing. Yes I
| understand that RHEL and Ubuntu are popular.
| pjmlp wrote:
| Yet IBM, Oracle, HP and POSIX RTOS vendors keep enough
| customers happy with that rouding error.
| encom wrote:
| Apple is not a UNIX vendor. They checked off enough of a
| compliance list to pass in the legal and marketing sense,
| but in any real practical sense it's not usable as a UNIX
| system. It's not designed to serve anything. Most of it
| is locked down and proprietary. No headless operation, no
| native package manager, root is neutered... and so on.
| It's not UNIX.
| dralley wrote:
| Yet another reason why I'm not a fan of Richard Stallman.
|
| Most of the decisions he made over the past 25 years have
| been self-defeating and led directly to the decline of the
| influence of his own movement. It's not that "the GCC
| project" avoided that for ideological reason, Stallman was
| personally a veto on that issue for years, and his personal
| objection led to several people quitting the project for
| LLVM, with a couple saying as much directly to him.
|
| https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html
|
| https://lists.gnu.org/archive/html/emacs-
| devel/2015-01/msg00...
|
| (both threads are interesting reading in their entirety, not
| just those specific emails)
| knowknow wrote:
| Kind like how GPL 3 makes it infeasible for most companies
| to use/support free software. At least Stallman gets to
| feel morally superior though
| dralley wrote:
| And Free Software does not benefit from a morass of
| mutually-incompatible copyleft licenses that may as well
| have been proprietary since you can't use them together.
|
| None of the permissive licenses have this problem.
| gkbrk wrote:
| Which open-source licenses can't be used together?
| dralley wrote:
| GPLv2 and GPLv3, for one example... It's sad when two
| licenses from the same organization are incompatible.
|
| GPLv2 and Apache.
| teddyh wrote:
| The number of significant software projects which are
| licensed as GPLv2- _only_ , and which are therefore
| incompatible with GPLv3, can probably be counted on one
| hand. _Normal_ GPLv2 projects are licensed - as
| instructed by the text in the license itself - as "GPLv2
| _or later_ ". Which means that any normal GPLv2-licensed
| software can be relicensed to GPLv3, and can therefore be
| combined with any other GPLv3-licensed program without
| any issue whatsoever.
| gus_massa wrote:
| For GPL v2 only, let's start the list with Linux and
| Git...
|
| The "or later" has been used in creative ways, like
| relicencing all the Wikipedia content, or the Affero to
| AGPL transition. Nothing shady, but unexpected.
|
| Do you trust RMS to avoid doing shady things in the later
| GPL licence? I do, but he is not longer in the FSF.
|
| Do you trust the current members of the FSF to avoid
| doing shady things in the later GPL licence? I don't know
| them.
|
| Do you trust the future members of the FSF to avoid doing
| shady things in the later GPL licence???
| CorrectHorseBat wrote:
| >Do you trust RMS to avoid doing shady things in the
| later GPL licence? I do, but he is not longer in the FSF.
|
| Yes he is: https://www.fsf.org/about/staff-and-board
| ndiddy wrote:
| Section 14 of the GPL says "The Free Software Foundation
| may publish revised and/or new versions of the GNU
| General Public License from time to time. Such new
| versions will be similar in spirit to the present
| version, but may differ in detail to address new problems
| or concerns." Given that the preamble to the GPL
| explicitly says "the GNU General Public License is
| intended to guarantee your freedom to share and change
| all versions of a program--to make sure it remains free
| software for all its users", I don't think that a judge
| would find that a hypothetical GPLv4 that was basically
| MIT or something is "similar in spirit" to the present
| version.
|
| If you're worried about the other direction (i.e. a
| hypothetical GPLv4 that had some bizarre restriction like
| "all users must donate to the FSF"), the "or any later
| version" means that as long as you don't decide to update
| the license you use yourself, people can continue to use
| it under the GPLv2 or v3 indefinitely.
| raverbashing wrote:
| Honestly at least Linus has his head in the right place
| kstrauser wrote:
| I think that's an unreasonable lens for viewing his work.
| _Of course_ he values purity over practicality. _That 's
| his entire platform._ His decision making process always
| prioritizes supporting Free Software over proprietary
| efforts, pragmatism be damned.
|
| Expecting Stallman to make life easier for commercial
| vendors is like expecting PETA to recommend a good foie
| gras farm. That's not what they do.
| dralley wrote:
| >Expecting Stallman to make life easier for commercial
| vendors is like expecting PETA to recommend a good foie
| gras farm. That's not what they do.
|
| He threw open-source developers under the bus in the
| process. As a result approximately nobody writes GCC
| plugins, open source or otherwise.
| kstrauser wrote:
| Alternatively, if you join a Stallman-led Free Software
| project and hope he'll accept your ideas for making life
| easier for proprietary vendors, you're gonna have a bad
| time. I mean, the GNU Emacs FAQ for MS Windows (https://w
| ww.gnu.org/software/emacs/manual/html_mono/efaq-w32...)
| says:
|
| > It is not our goal to "help Windows users" by making
| text editing on Windows more convenient. We aim to
| replace proprietary software, not to enhance it. So why
| support GNU Emacs on Windows?
|
| > We hope that the experience of using GNU Emacs on
| Windows will give programmers a taste of freedom, and
| that this will later inspire them to move to a free
| operating system such as GNU/Linux. That is the main
| valid reason to support free applications on nonfree
| operating systems.
|
| RMS has been exceedingly clear about his views for
| decades. At this point it's hard to be surprised that
| he'll make a pro-Free Software decision every time,
| without fail. That doesn't mean you have to agree with
| his decisions, of course! But to be shocked or
| disappointed by them is a sign of not understanding his
| platform.
| umanwizard wrote:
| But the person you're responding to never said he was
| shocked or disappointed by the views; he just said the
| views are bad/counterproductive.
| kstrauser wrote:
| But they're only bad/counterproductive when assessed
| against their own goals. They're a lot more reasonable if
| you assess them against Stallman's, where you could say
| "yeah, these actions kept GCC from becoming a handy tool
| for proprietary interests who don't want to share their
| work back with us".
| Keyframe wrote:
| I found out the older I get the more sense rms makes.
| kstrauser wrote:
| On the subject of software freedom, I hate how accurately
| prophetic he is.
|
| RMS: Here's how they'll get ya!
|
| Me: Nice, but that'd never happen.
|
| Vendor: Here's how we got ya!
|
| Me: Dammit.
|
| Seriously, he must have a working crystal ball.
|
| Now, my agreement with him starts and ends on that
| subject. He says plenty of other things I wholly disagree
| with. But his warnings about proprietary software lock-
| in? Every. Single. Time.
| johnisgood wrote:
| I mean, I think he is right. If everyone stopped
| supporting Windows, it would have long died out in favor
| of easy-to-install Linux distributions... probably.
| codedokode wrote:
| In reality though Microsoft just added a WSL; not bad:
| Linux code can run on Windows now.
|
| Also, if you want Windows to die you need to work with
| OEMs: I assume that most users simply use whatever OS is
| pre-installed.
| johnisgood wrote:
| I agree.
| Analemma_ wrote:
| > His decision making process always prioritizes
| supporting Free Software over proprietary efforts,
| pragmatism be damned.
|
| No, this is giving him too much credit. His stance on gcc
| wasn't just purity over pragmatism, it was antithetical
| to Free Software. The entire point of Free Software is to
| let users modify the software to make it more useful to
| them, there is _no point_ to Free Software if that
| freedom doesn 't exist - I might as well use proprietary
| software then, it makes no difference.
|
| Stallman fought tooth and nail to make gcc harder for the
| end user to modify, he directly opposed letting users
| make their tools better for them. He claims it was for
| the greater good, but in practice he was undermining the
| whole reason for free software to exit. And for what? It
| was all for nothing anyway, proprietary software hasn't
| relied on the compiler as the lynchpin of its strategy
| for decades.
| cherryteastain wrote:
| Without GNU, GPL and Richard Stallman, FOSS would not exist
| in the first place. The GPL forced companies to make FOSS a
| thing, whether they liked it or not.
| azinman2 wrote:
| And then the world started moving on, with other licenses
| that gave even more freedom and flexibility.
|
| It was a great start, but you need to adapt or you
| perish.
| anthk wrote:
| When VSCode et all beging shipping DRM and who knows what
| in their extensions, then we'll se what with happens with
| these half-shareware semilibre projects.
|
| Specially when propietary dependencies kill thousands of
| projects at once.
| spookie wrote:
| Well, you are already unable to get most of the
| functionality out of vscode without Microsoft's extension
| store.
|
| I, for one, am happy that there are still a couple of
| people here and there that you can really trust on this
| stuff.
| trelane wrote:
| > other licenses that gave even more freedom and
| flexibility
|
| That gave _vendors_ more freedom and flexibility (to lock
| their software away from their customers.)
|
| As usual, customers got _less_ freedom and flexibility.
| azinman2 wrote:
| I disagree. They got software that's open under a
| different license that otherwise would have just been
| purely proprietary, or not created at all (due to the
| compounding effects of open source)
| trelane wrote:
| We are currently talking about GCC, where they _would_
| have gotten the source prior to LLVM.
|
| > They got software that's open under a different license
| that otherwise would have just been purely proprietary
|
| This is not a given, even outside of compilers. It's a
| heck of a cope there.
| azinman2 wrote:
| > Without GNU, GPL and Richard Stallman, FOSS would not
| exist in the first place. The GPL forced companies to
| make FOSS a thing, whether they liked it or not.
|
| I was responding to this, which is more widespread than
| GCC (although it was one of the first wins of the GNU).
|
| There were various companies who wanted to add on
| backends and other bits to GCC, but wouldn't due to the
| license. That's one of the reasons LLVM is so popular.
| wolvesechoes wrote:
| As with any other achievement of civilization, younger
| generations will at some point find why previous ones
| fought for something and how it sucks to loose it.
|
| But when this realization comes, it will be too late.
| bluGill wrote:
| Bsd was long a thing proving you wrong. Yes gpl got more
| press but the other options existed for long.
| IshKebab wrote:
| I doubt that. People often say "without <person that
| started thing> we wouldn't have <thing>!" but it's
| nonsense. Someone else would have done it just slightly
| later.
| azinman2 wrote:
| The question is if that person would have dedicated their
| life in the same way.
| JoshTriplett wrote:
| Don't forget that the LLVM folks actually _went to GNU_ and
| offered it to them, and they _failed to pay attention and
| respond_. (It 's not even that they responded negatively;
| they just dropped it on the floor completely.) There's an
| alternate history where LLVM was a GNU project.
|
| With the benefit of hindsight, I'm glad that that didn't
| happen, even though I have mixed feelings about LLVM being
| permissively licensed.
| alienthrowaway wrote:
| Gcc is _the_ flagship of the GNU Project - allowing an
| endrun of the the spirit of the GPL in gcc was _never_
| going to happen. The project paid more attention than you
| give them credit for because allowing closed source
| plugins and improvements that use gcc as a frontend is
| anathema to Free software.
|
| There's an impedance mismatch between people who think
| gcc should have maximized user utility vs. the actual GNU
| philosophy. The actions of the gcc project make a lot of
| sense if you consider the FSF/GNU are monomaniacal about
| maximizing users _freedoms,_ and not popularity, momentum
| or other ego-stroking metric.
| JoshTriplett wrote:
| Whether you care about _number of users_ or not, there 's
| value in considering whether what you're doing is
| actually advancing the cause of Free Software or not.
|
| GCC today has a very interesting license term, the GCC
| Runtime Library Exception, that makes the use of runtime
| libraries like libgcc free if-and-only-if you use an
| entirely Free Software toolchain to compile your code
| with; otherwise, you're subject to the terms of the GPL
| on libgcc and similar. _That_ is a sensible pragmatic
| term, and if they 'd come up with that term many years
| ago, they could have shipped libgccjit and other ways to
| plug into GCC years ago, and the programming language
| renaissance that arose due to LLVM might have been built
| atop GCC instead.
|
| _That_ would have been a net win for user freedoms.
| Instead, because they were so afraid of someone using an
| intermediate representation to work around GCC 's
| license, and didn't do anything to _solve_ that problem,
| LLVM is now the primary infrastructure people build new
| languages around, and GCC lost a huge amount of its
| relevance, and people now have less software freedom as a
| result.
| steveklabnik wrote:
| > allowing an endrun of the the spirit of the GPL in gcc
| was never going to happen.
|
| You're right:
|
| https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
|
| > If people are seriously in favor of LLVM being a long-
| term part of GCC, I personally believe that the LLVM
| community would agree to assign the copyright of LLVM
| itself to the FSF and we can work through these details.
| codeshaunted wrote:
| Is it still the case that the Linux kernel cannot be compiled
| using clang, or can you do that now?
| bombcar wrote:
| I believe clang has worked for years now.
| codeshaunted wrote:
| Why would anyone bother with GCC then? :P
| bombcar wrote:
| I believe GCC still wins _by far_ on support for weird
| CPUs and embedded systems.
| codeshaunted wrote:
| With LLVM I doubt this will remain true. LLVM makes
| custom code generation far too easy for GCC to remain
| viable imo.
| jcranmer wrote:
| I don't have much experience with writing a custom gcc
| backend, but my experience with LLVM is that its model
| ends up being a somewhat poor fit for smaller or weirder
| architectures. For example, LLVM has this annoying
| tendency to really aggressively promote the size of
| everything--if you have a 32-bit core with 64-bit memory
| indexing, LLVM tends to make anything that eventually
| becomes a memory index a 64-bit computation, even if it
| would be more efficient to keep everything as 32-bit.
| mort96 wrote:
| Hm, is it so much easier to write an LLVM back-end than a
| GCC back-end? I haven't looked into GCC's code gen
| infrastructure that much, but I looked into making a new
| back-end to LLVM some time ago and it seemed extremely
| complex and entirely undocumented. All guidance I found
| on it basically amounted to, "copy an existing back-end
| and bang it against a rock until you've made it generate
| the machine code you need". And it certainly wasn't a
| case of having clean and simple enough code to make
| documentation unnecessary. It would honestly surprise me
| if GCC is more difficult to add a back-end to.
| SubjectToChange wrote:
| The problem is that "weird CPUs and embedded systems" are
| not mainstream platforms, nor do they have a lot of money
| behind them (particularly for open source development).
| Hence, there is little motivation and/or resources for
| anyone to develop a new backend for LLVM when a mature
| GCC backend already exists. Moreover, the LLVM developers
| are weary to accept new backends for niche platforms when
| there is no guarantee that they will be maintained in the
| future.
| bombcar wrote:
| Exactly - often the GCC branch is barely maintained by
| whoever is selling the CPU/chip, and it is patches
| against a specific version that you must use, or it goes
| haywire.
|
| At least with GCC they can sometimes merge the patches.
| SubjectToChange wrote:
| GCC still for Linux distributions using glibc or any
| other library with many "GCCisms". Also, I'm not sure
| whether or not Clang is ABI compatible _enough_ for
| enterprise customers with some rather extreme backwards
| compatibility requirements. Still, I can imagine a future
| where glibc can be built with Clang, possibly even one
| where llvm-libc is "good enough" for many users.
| IshKebab wrote:
| Mainly because it was the default for so long, and Clang
| isn't _so_ much better that distros really need to
| switch.
| jart wrote:
| GCC is still marginally superior at both code size and
| performance in my experience.
|
| The main thing I like about clang is it compiles
| byzantine c++ code much faster.
|
| Some projects like llama.cpp it's like eating nails if
| you're not using clang.
|
| So with projects like llamafile I usually end up using
| both compilers.
|
| That's why my cosmocc toolchain comes with -mgcc and
| -mclang.
| homebrewer wrote:
| https://static.lwn.net/kerneldoc/kbuild/llvm.html
|
| I do remember reading about LTO not working properly,
| you're either unable to link the kernel with LTO, or get a
| buggy binary which crashes at runtime. Doesn't look like
| much effort has been put into solving it, maybe it's just
| too large a task.
| LeFantome wrote:
| There are a few distros that use Clang as the system
| compiler (SerpentOS and Chimera Linux for two).
| aengelke wrote:
| I'd add code quality as a reason. I find it much easier to
| understand and modify code in LLVM compared to GCC. Both have
| a fairly steep learning curve and not too much documentation,
| but often I (personally) find LLVM's architecture to be more
| thought out and easier to understand. GCC's age shows in the
| code base and it feels like many concepts and optimizations
| are just bolted on without "required" architectural changes
| for a proper integration.
| pxc wrote:
| > I expect someday clang will become the default [compiler for
| the Linux kernel].
|
| Why? I don't personally use GCC except to compile other
| people's projects in a way that's mostly invisible to me, but
| it seems like it's still widely used and constantly improving,
| thanks in part to competition with LLVM/Clang. Is the situation
| really so dire?
| wahern wrote:
| > Is the situation really so dire?
|
| I for one don't think so. From my perspective, there's at
| least as much momentum in GCC as clang/LLVM, especially on
| the static analysis and diagnostics front over the past 5 or
| so years. That was originally one of the selling points for
| clang, and GCC really took it to heart. It's been 10 years
| since GCC adopted ASAN, and after playing catchup GCC never
| stopped upping their game.
|
| Perhaps the image problem is that LLVM seems to be preferred
| more often for interesting research projects, drawing more
| eyeballs. But by and large these are ephemeral; the activity
| is somewhat illusory, at least when comparing the liveliness
| of the LLVM and GCC communities.
|
| For example, both clang/LLVM and GCC have seen significant
| work on addressing array semantics in the language, as part
| of the effort to address buffer overflows and improve static
| analysis. But GCC is arguably farther along in terms of
| comprehensive integration, with a clearer path forward,
| including for ISO standardization.
|
| More importantly, the "competition" between GCC and
| clang/LLVM is mutually beneficial. GCC losing prominence
| would not be good for LLVM long-term, just as GCC arguably
| languished in the period after the egcs merger.
| pxc wrote:
| > More importantly, the "competition" between GCC and
| clang/LLVM is mutually beneficial. GCC losing prominence
| would not be good for LLVM long-term, just as GCC arguably
| languished in the period after the egcs merger.
|
| You're right to note that "competition" here is more like
| inspiration than a deathmatch. But I vaguely remember two
| things that seem similar to motivation via competitive
| pressure to me: (1) when GCC 5 came out, it had way nicer
| error messages, and I immediately thought "Oh, they wanted
| to make GCC nice like Clang" and (2) IIRC the availability
| of a more modular compiler stack like LLVM/Clang
| essentially neutralized Stallman's old strategic argument
| against more a more pluggable design, right?
| enasterosophes wrote:
| Unless you're talking about a compiler built into the kernel, I
| don't see that anyone is in a position to dictate to each
| distro what compilers they package.
| ahartmetz wrote:
| Clang:
|
| - has about the same quality of error messages as GCC now
|
| - is now almost exactly as slow (/fast) as GCC at compiling now
|
| - sometimes produces faster code than Clang, sometimes slower,
| about the same overall
|
| I see no reason why the default would change.
| almostgotcaught wrote:
| well for one clang uses way less memory (RAM). also ld.lld is
| wayyyyyyyy faster than ld (and also uses way less memory).
| ahartmetz wrote:
| ld.lld works with any compiler, and anyway, mold is even
| faster and also works with any compiler.
| mwkaufma wrote:
| Usability improvement request for this article: don't hijack the
| browser back button :P
| llm_nerd wrote:
| It's already egregious when a site adds history pushState
| entries for just clicking through a gallery or something, but
| wow adding them just for scrolling down on a page is simply
| bizarre, especially on a page about usability.
| nottorp wrote:
| It's in the spirit of adding emojis to compiler output...
| ender341341 wrote:
| I actually quite like the emojis they put in the output, it
| helps alleviate the balance of providing enough context
| while also giving a clear visual indicator for the actual
| error message.
|
| They aren't going overboard on it, they just put a warning
| emoji in front of the error message.
| nottorp wrote:
| How do you grep for it without taking your hands off the
| keyboard?
| perching_aix wrote:
| Windows key + dot, then type in warning / if it was among
| the last ones you used, use the arrow keys, and hit Enter
| to insert it.
|
| If you use whatever OS other than Windows, I'm sure there
| are similar flows available if you search for it. And
| since it's just Unicode, I'm sure there are numpad based
| keybinds available too.
| nottorp wrote:
| why shouldn't i just type grep warning instead of
| bringing up some GUI that possibly takes forever to
| initialize?
|
| how does it work over ssh? :)
| johnisgood wrote:
| It makes too much sense.
| alisonatwork wrote:
| Emoji selector is fast and works perfectly fine over SSH,
| it's no different to any other input method that needs to
| use characters beyond 7-bit ASCII.
|
| grep is a bit more iffy. UNIX command line tools seem to
| be a bit of a crapshoot in how or if they support
| Unicode, especially if you switch between different
| systems like Linux, BSD, Cygwin etc. You might need a bit
| of experimenting with the LANG variable to get it work
| (e.g. Git Bash on Windows needs LANG=C.UTF16 to match an
| emoji). I've also had cases where grep or sed works, but
| awk doesn't, or vice versa. On the whole it works a lot
| better nowadays than it used to, though, and that's a win
| for non-English users of the command line as well as
| emoji fans.
| nottorp wrote:
| > that's a win for non-English users of the command line
|
| I am non english. I use aaist. When writing a text
| document for humans.
|
| I also use :) but not .
|
| I'm still of the opinion that anything not 7-bit ascii
| doesn't belong in something that may be machine
| processed. Which includes compiler output.
|
| Edit: hey, HN erased my emoji. The dot was supposed to be
| the :) emoji style.
| alisonatwork wrote:
| Didn't you ever grep a text document written in a
| language other than English? No processing of CSV files
| in different charsets? Not even encountered a file with a
| non-English character in the name? Not to mention the
| folks who deliberately set LANG so that their compiler
| and everything else will give them localized error
| messages. This stuff was all much worse 25 years ago,
| even 15 years ago. Like them or not, I do think emojis
| have helped drive forward much better Unicode handling
| across the whole stack, including the command line.
| nottorp wrote:
| > Didn't you ever grep a text document written in a
| language other than English?
|
| Yes but it was for humans originally? Not for machine
| processing.
|
| > Not to mention the folks who deliberately set LANG so
| that their compiler and everything else will give them
| localized error messages.
|
| The horror! Who even works on translations for compiler
| error messages ?!? It makes absolutely no sense!
|
| Next they'll want to localize programming language
| keywords. I wonder how well that will work at this
| current project of mine that has people native to 3
| countries, none english speaking ...
| perching_aix wrote:
| It's not a next, but more a previously :) Localized
| development tooling is an old timer thing.
| nottorp wrote:
| How old? I'm old enough that my first Linux experience
| included a stack of floppy disks and recompiling a 0.9x
| kernel in late high school, and my first c++ program was
| done with Borland C++ 3.1. It never occured to me to look
| for a localized UI for either of them.
|
| Older than that?
| perching_aix wrote:
| I don't know, you wanted to grep for the emoji.
| nottorp wrote:
| That's what you think?
|
| I wanted something I could grep for easily. Which doesn't
| seem to be the emoji, since it needs extra software to
| get on the grep command line...
| perching_aix wrote:
| It's not a "what I think" thing, these were your literal
| words:
|
| > How do you grep for it
|
| And then how badly or well this works will depend on your
| build of grep and your environment variables, as the
| other user noted. I did not consider this, because I'd
| expect grep to just work with Unicode symbols like this
| when my stdin is set to UTF-8, which I'd further expect
| to always being the case in 2025, but it appears that's
| not an expectation one can reasonably have in the *nix
| world.
|
| It was and continues to be unclear to me why you'd want
| to grep for the warning emoji though, since according to
| the article these are inserted somewhere deep in the
| console-visual explanations. They do not replace the slug
| denoting the compiler message type at the start of these,
| which as you said, can (still) be found by just grepping
| for "warning".
| nottorp wrote:
| > xpect to always being the case in 2025
|
| Oh but in the real world you vpn into a server that
| privately tailscales to some boxes that are hard to reach
| inside a factory and no one has physically touched them
| since 2018 at best ...
|
| What's this 2025 you speak of? Not in production.
| perching_aix wrote:
| Don't remind me lol, even worse when it's a fresh VM but
| the software is still ancient.
| yazantapuz wrote:
| TIL that winkey+dot in kde launchs the emoji selector ...
| but it is copied into the clipboard, so more keystrokes
| nottorp wrote:
| At least i didn't get a link to an youtube tutorial as an
| answer :)
| optionalsquid wrote:
| In Firefox, you can prevent this by setting
| `browser.navigation.requireUserInteraction` via about:config.
| I've been told that it breaks some stuff, but to date I haven't
| noticed any downsides
| teddyh wrote:
| > _you can prevent this by setting
| `browser.navigation.requireUserInteraction`_
|
| Setting it to what?
| optionalsquid wrote:
| true
| budmichstelk wrote:
| Doesn't answer your question, but in Tor Browser it would
| decrease your anonymity set.
| DyslexicAtheist wrote:
| Usability improvement request for this site: don't promote a
| comment that isn't related to the content to the top :P
| perching_aix wrote:
| Not an issue with JS disabled ;)
| bigstrat2003 wrote:
| Browser makers should straight up remove the JS API for
| interacting with history. There are legitimate uses for it, but
| the malicious actors far outweigh the good ones at this point.
| Just remove it.
| Dracophoenix wrote:
| Ditto for unprompted redirects.
| bonzini wrote:
| Redirects are used for stuff like POST->GET or
| canonicalizing URLs (adding slashes on directories), would
| you get rid of that too?
| Calavar wrote:
| That's done with HTTP headers though, right? Not
| JavaScript.
| bonzini wrote:
| Ah, I see what you mean. The canonicalization is, whereas
| redirects after processing forms could be done in
| JavaScript from and on click or on submit handler.
| spookie wrote:
| same for clipboard events.
| panzi wrote:
| I mean, without `history.pushState()` and `window.onpopstate`
| things wouldn't be as nice. Ok, I guess one could do about
| everything with `location.hash = ...` and
| `window.onhashchange`, like in the before times. But the
| server will not get the hash part of the URL so a link to
| such an page can't be server side rendered and has to fetch
| the actual page content in JavaScript, evaluating the hash.
| When I browse things like image search it is really handy
| that you can use the browsers back button to close an opened
| image without loosing any dynamic state of the page and that
| the x button on the page will close the image and remove the
| history entry just the same way, so a later back won't re-
| open that image.
|
| For me the back button wasn't hijacked.
|
| But I am for disallowing the use of `history.go()` or any
| kind of navigation inside of `onpopstate`, `onhashchange`,
| `onbeforeunload` or similar or from a timer started from one
| of those.
| mort96 wrote:
| How about we just navigate to new pages by .. navigating to
| new pages? Browsers have perfectly functional history
| without javascript shenanigans
| bigstrat2003 wrote:
| Like I said: I recognize there are legitimate uses. But
| unfortunately, they are majorly outnumbered by people doing
| things like overwriting my history so that when I hit
| "back", it stays on the site instead of going back to my
| search engine. I would love to live in the world where
| malicious dark patterns didn't exist, and we could have
| nice things. But we don't, and so I would rather not have
| the functionality at all.
| nightfly wrote:
| This type of thinking is what doomed uBlock Origin. I
| strongly disagree.
| jenadine wrote:
| The difference is that uBlock Origin is an extension you
| intentionally trust and install, while the JS API we talk
| about are something any websites (untrusted) can use.
| PaulDavisThe1st wrote:
| How is uBlock Origin "doomed" ?
| nightfly wrote:
| https://ublockorigin.com/#:~:text=Understanding%20Manifes
| t%2...
| PaulDavisThe1st wrote:
| So UBO isn't doomed, just UBO on Chrome. While that's
| significant given Chrome's market share, I and everyone
| else on the planet have the option to use something else,
| and will continue to do so.
| encom wrote:
| An advertising company controls the user agent everyone
| uses to access the internet, and wants to shove more ads
| into your eyeballs. uBlock exists as long as they allow
| it. Anyone who disagrees with this, works for them or own
| shares in the company.
| goku12 wrote:
| Perhaps the users should be given an option to opt out
| (enabled by default) for such APIs on a per-site basis.
| That way, users can intervene when they're abused, while
| their fair use will remain transparent.
| nightfly wrote:
| This seems like a good compromise. Similar to requesting
| location information, and/or denying popups after a few
| have been spawned
| nullc wrote:
| Ditto for rewriting anchor destinations onclick, allowing
| sites to show one destination for hover but send you
| somewhere else.
| jart wrote:
| That's a biased thing to say, since you're never going to
| notice the times when the history api is being used
| appropriately. Just as often I find myself raging when a
| webpage _doesn 't_ rewrite history at times when it should.
| Good taste is hard to come by.
| TZubiri wrote:
| But wouldn't you be able to replicate the same issue by using
| a redirect?
| TZubiri wrote:
| works fine for me (MS Edge)
| codeshaunted wrote:
| Big fan of all of this except for the emojis in my console
| guenthert wrote:
| I actually appreciate a #\WARNING_SIGN, but then, why is there
| no #\STOP_SIGN ?
| staplung wrote:
| On the one hand I feel like the #WARNING_SIGN is a welcome
| addition. On the other, I'm sensitive to the idea that it will
| be totally obnoxious if you need to grep/search for it in
| whatever tool you're using.
|
| Was a little surprised to learn that the warning sign is
| generally considered an Emoji; I guess I don't think of it that
| way. Was even more surprised to learn that there is no great
| definition for what constitutes an Emoji. The term doesn't seem
| to have much meaning in Unicode. The warning sign - U+26A0 -
| goes all the way back to Unicode version 4.0 and is in the BMP,
| whereas most Emoji are in the SMP.
| codeshaunted wrote:
| How will it output on my VT100 serial terminal? :P
|
| Somewhat related fun fact, anyone can submit an emoji to the
| Unicode Consortium annually, submissions are actually open
| right now: https://unicode.org/emoji/proposals.html.
| Someone wrote:
| > Was even more surprised to learn that there is no great
| definition for what constitutes an Emoji. The term doesn't
| seem to have much meaning in Unicode
|
| The definition is messy, but the list of Unicode emojis is
| defined. Starting points:
| https://www.unicode.org/reports/tr51/,
| https://unicode.org/emoji/charts/full-emoji-list.html
| bonzini wrote:
| It's only an emoji if followed by the "emoji presentation
| selector" U+FE0F. Without it, it has no colors (but
| hackernews doesn't allow including it).
| high_na_euv wrote:
| Why?
| umanwizard wrote:
| Well, other than the fact that it's hard to search for,
| things should be kept as simple as possible to improve
| reliability/interoperability. Are you confident that multi-
| column-wide non-ASCII characters work reliably without
| causing rendering issues on every possible combination of
| terminal/shell/OS, including over SSH? I'm certainly not.
| gpderetta wrote:
| You can already put multi-column-wide non-ASCII characters
| in your source code, so the horse has left the barn
| already.
| umanwizard wrote:
| Of course you _can_. I 'd argue you shouldn't, but that's
| beside the point. There is clearly a difference between
| people being able to do something, and the compiler
| forcing it on them.
| IshKebab wrote:
| But the compiler isn't forcing it on anyone?
| dzaima wrote:
| If anything, an emoji is easier to search for, as less
| things would be using it than a general "warning" (or
| whatever would make sense, as the emoji'd thing isn't the
| warning itself). Do have to get a copy from somewhere to
| search for though. It's also much easier to "visually"
| search for it.
|
| At least in the blog there are a two spaces after the emoji
| so it can freely draw past its boundaries rightwards
| without colliding with anything for a good bit; and nothing
| to its right is used assuming monospace alignment. So at
| worst you just get a half-emoji.
| aseipp wrote:
| They are quite easy to search for actually, because they
| are sparse and you tend to not get so many spurious results
| due hitting things that contain your query as a substring.
| Even then, the glyphs appear inline in the warning message,
| they are not the anchor, you could still just search for
| "warning:" like you or your editor have been doing for
| years. Every operating system comes with an emoji picker,
| it takes like 2 seconds to use. I'm not sympathetic, tbqh.
| codeshaunted wrote:
| Makes me feel like I'm writing JavaScript, if that makes any
| sense. Also I hate fun.
| javier_e06 wrote:
| I started putting emoji's in my bash scripts.
|
| gitk broke! Can't parse emojis
|
| I want emojis in my code. They are a superior form of
| communication (non-linear)
| nomel wrote:
| > I want emojis in my code.
|
| Then you will enjoy swift [1]!
|
| [1] Emoji driven development:
| https://www.swiftbysundell.com/special/emoji-driven-
| developm...
| dlachausse wrote:
| It should be easy to patch out or possibly add a command line
| switch to disable it if desired.
| cassepipe wrote:
| Already exists : -fdiagnostics-text-art-
| charset=[none|ascii|unicode|emoji]
| Karliss wrote:
| Few versions ago GCC added `-fdiagnostics-text-art-
| charset=[none|ascii|unicode|emoji]` so feel free to disable
| them.
|
| https://godbolt.org/z/bYc7EqYWE
| pxc wrote:
| If you're using an OS that honors your font choices (i.e., not
| macOS), you can use a font like Symbola to provide emoji so
| that they're stylized, monochrome, and vectorized, rather than
| incongruous color bitmap images. That helps them play nice with
| terminal colorschemes and things like that.
|
| I'm not aware of any emoji fonts like Symbola which provide a
| monospace typeface, though. That would be a great option.
| wiseowise wrote:
| Already looking forward to `grep`ing warning emojis in output.
| What's next? Poop emoji for errors?
| johnisgood wrote:
| I do not want any emojis from my compiler's output, heck, in my
| terminal in general. Please, do not make it the default
| behavior.
|
| (BTW my terminal does not even support emojis.)
| aseipp wrote:
| Why wouldn't you just keep search for the "warning:" or
| "error:" anchor, like people (and editors) have been doing
| forever? Even if that wasn't true it's not like searching for
| emojis is hard anyway. If it takes longer than 2 seconds for
| you to open a picker then you should ask for a refund for your
| computer.
| db48x wrote:
| Why would you grep for the emoji? The actual pattern you want
| to match is the standard format of the error message that
| proceeds it, which hasn't changed in eons: my
| $line = "infinite-loop-linked-list.c:30:10: warning: infinite
| loop [CWE-835] [-Wanalyzer-infinite-loop]"; grammar gcc
| { token filename { <-[:]>+ }; token
| linenumber { \d+ }; token colnumber { \d+ };
| token severity { info|warning|error }; token
| message { .* $$ }; regex diagnostic {
| <filename> [\:] <linenumber>
| [\:] <colnumber> [\:]\s
| <severity> [\:]\s <message>
| }; token TOP { <diagnostic> }; }
| say gcc.parse($line);
|
| which when run produces the obvious output:
| [infinite-loop-linked-list.c:30:10: warning: infinite loop
| [CWE-835] [-Wanalyzer-infinite-loop]] diagnostic =>
| [infinite-loop-linked-list.c:30:10: warning: infinite loop
| [CWE-835] [-Wanalyzer-infinite-loop]] filename =>
| [infinite-loop-linked-list.c] linenumber => [30]
| colnumber => [10] severity => [warning]
| message => [infinite loop [CWE-835] [-Wanalyzer-infinite-loop]]
|
| I'll leave handling filenames containing colons as an exercise
| for the reader.
|
| The emoji just focus the reader's eye on the most critical line
| of the explanation.
| munificent wrote:
| Using a hierarchy to show template errors is brilliant and I'm
| sort of surprised compilers haven't always done that.
|
| I was investigating C++-style templates for a hobby language of
| mine and SFINAE is an important property to make them work in
| realistic codebases, but leads to exactly this problem. When a
| compile error occurs, there isn't a single cause, or even a
| linear chain of causes, but an potentially arbitrarily large
| _tree_ of them.
|
| For example, it sees a call to foo() and there is a template
| foo(). It tries to instantiate that but the body of foo() calls
| bar(). It tries to resolve that and finds a template bar() which
| it tries to instantiate, and so on.
|
| The compiler is basically searching the entire tree of possible
| instantiations/overloads and backtracking when it hits dead ends.
|
| Showing that tree _as a tree_ makes a lot of sense.
| eddd-ddde wrote:
| I really wish templates didn't work on a dumb "replace at call
| site until something compiles" manner.
|
| All template requirements should be verified at the function
| definition, not at every call site.
|
| There is concepts. But they are so unwieldy.
| munificent wrote:
| It's honestly a seriously hard problem.
|
| Yes, it's definitely nice to be able to typecheck generic
| code before instantiation. But supporting that ends up adding
| a _lot_ of complexity to the typesystem.
|
| C++-style templates are sort of like "compile-time dynamic
| types" where the type system is much simpler because you can
| just write templates that _try_ to do stuff and if the
| instantiation works, it works.
|
| C++ templates are more powerful than generics in most other
| languages, while not having to deal with
| covariance/contravariance, bounded quantification, F-bounded
| quantification, traits, and all sorts of other complex
| machinery that Java, C#, etc. have.
|
| I still generally prefer languages that do the type-checking
| before instantiation, but I think C++ picks a really
| interesting point in the design space.
| jenadine wrote:
| C++0x concepts tried to achieve that but that didn't work.
|
| (But Rust traits works like that)
| pjmlp wrote:
| There were lots of politics evolved, moreso than technical
| issues.
|
| While not perfect concepts lite, alongside compile time
| evaluation do the job.
| trashburger wrote:
| Please no. Templates being lazy is so much better than Rust's
| eager trait evaluation, the latter causing incredible amounts
| of pain beyond a certain complexity threshold.
| eddd-ddde wrote:
| How so? I'd really like to see an example. If you can't
| explain what requirements your function has before calling
| it then how do you know it even does what you expect?
| pjmlp wrote:
| Only if stuck in C++17 and earlier.
|
| Past that point SFINAE should be left for existing code, while
| new code should make use of concepts and compile time
| execution.
| budmichstelk wrote:
| I like a these modernization efforts in GCC, a lot of old niggles
| are gone now, and they've made a lot of new improvements I didn't
| think were possible/easy!
| brcmthrowaway wrote:
| What is the status of GCC plugins?
| o11c wrote:
| Is there any reason to ask this? GCC plugins have been good
| since 4.8. 4.5 lacked some essential features; 4.6 would be
| fine if not for the annoyance of trying to support a plugin
| that works across the C++ transition. Of course, you can just
| use the Python plugin to save yourself a lot of sanity ...
| aseipp wrote:
| They work. You can use them? They haven't gone anywhere and the
| Linux kernel relies on them extensively, among other things.
| porphyra wrote:
| With GCC error messages usually the only part I wanna see is
| "required from here" and yet it spams zillions of "note: ...".
| With the nesting enabled, it's way easier to read --- just look
| at the top indentation level. Hooray!!!
| taschenorakel wrote:
| Why all this waste in Unicode art that nobody will ever see and
| that confuses your IDE.
|
| Why not spend time on helping IDEs to understand error messages?
| That would be billion times more useful.
| levodelellis wrote:
| Please gcc, let me have a `~/.config/gcc` config file or an ENV
| variable so I can ask for single lined error messages.
|
| I literally do not need ascii art to point to my error, just tell
| me line:col and a unique looking error message so I can spend no
| more than 1 second understanding what went wrong
|
| Also allow me to extend requires with my own error messages. I
| know it'll be non standard but it would be very nice tyvm
| kazinator wrote:
| I can't imagine a piece of software easier to use than gcc 3.4.6,
| sorry.
|
| We are now entering a Rococo period of unnecessarily ornate
| compiler diagnostics.
|
| Getting these elaborate things to work is a nice puzzle, like
| Leetcode or Advent of Code --- but does it have to be merged?
| jart wrote:
| Here's the pending GCC 15 release notes:
| https://gcc.gnu.org/gcc-15/changes.html (since the link in the
| article points to GCC 14)
|
| - I'd love to see godbolt examples of the sort of optimizations
| [[unsequenced]] and [[reproducible]] can do.
|
| - GCC has always been in my experience smart enough to know how
| to optimize normal C code into ROL and ROR instructions. I've
| never had any issues with it. So what's the point of
| __builtin_stdc_rotate_left()? Why create a builtin when it is not
| needed? What I wish GCC and Clang would do instead, is formally
| document the magic ANSI C89 incantations that trigger the
| optimization, e.g. `#define ROL(x, n) (((x) << (n)) | ((x) >> (64
| - (n))))`. That way we can have clean portable code with less
| #ifdef hell along with assurances it'll go fast when -O is
| passed.
|
| - What is "Abs Without Undefined Behavior (addition of builtins
| for use in future C library <stdlib.h> headers)."?
|
| - What is "Allow zero length operations on null pointers"?
|
| - Re: "Introduce complex literals." How about some __int128
| literals?
|
| - "The "redzone" clobber is now allowed in inline assembler
| statements" wooo I've wanted something like this for a while.
|
| Great work from the greatest compiler team!
| fuhsnn wrote:
| > How about some __int128 literals
|
| There are _BitInt literals (wb and uwb), look adequate
| https://godbolt.org/z/xjEEM5Pa4 despite clang's "is a C23
| extension" noise.
| jart wrote:
| Wait I missed that. They finally implemented _BitInt? YESSS
| bmn__ wrote:
| The writer David Malcolm tells a story in his article about
| compiling C17 code and pretending it's C23. Duh, no wonder it
| breaks!
|
| You C standard authors have it bass-ackwards. The version of the
| code must accompany the code, not the compiler invocation.
___________________________________________________________________
(page generated 2025-04-11 23:02 UTC)