HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gcc-mirror
gcc
C++2011–2026
gcc-mirror / gcc

gcc

Discover this repository through its Hacker News conversations.

Explore on GitHubRead Hacker News discussions
108Distinct people
122Mentions
0Explicit recommenders
11.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

The source check is incomplete. Verified examples will appear here.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year122 dated mentions

Observed mentions: 2011-12-14 05:37:23 UTC to 2026-09-27 21:56:56 UTC.

0510152011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC101
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC101
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC000
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC14113
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC817
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC808
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC918
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC615
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC1019
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC14113
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC12012
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC808
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC12111
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC12012
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

122 sources
sparkie·Sep 27, 2026
If you want to know how bad it can be, only need to take a look at GCC's implementation of `stddef.h` for `size_t` and `ptrdiff_t` etc. https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/s... There's a simpler way to define these types in newer versions of C which have `typeof`, we can take advantage of the fact that `sizeof()` always returns a `size_t`, `ptr - ptr` always returns a `ptrdiff_t`, and a literal L'c' has type `wchar_t`, etc. typedef typeof(sizeof(0)) size_t; typedef typeof(nullptr) nullptr_t; typedef typeof((void*)0-(void*)0) ptrdiff_t; typedef typeof(L'\0') wchar_t; typedef typeof(u8'\0') char8_t; typedef typeof(u'\0') char16_t; typedef typeof(U'\0') char32_t; Don't need ifdef soup to test what the sizes of things are on different architectures - we just utilize the compiler's implementa
Read the rest
tion of those types.
In C's Flexible Integer Sizes Were Not a Design Mistake
phiresky·Apr 24, 2026
I'm a bit disappointed that this only solves the "find index of file in tar" problem, but not at all the "partially read a tar.gz" file problem. So really you're still reading the whole file into memory, so why not just extract the files properly while you are doing that? Takes the same amount of time (O(n)) and less memory. The gzip-random-access problem one is a lot more difficult because the gzip has internal state. But in any case, solutions exist! Apparently the internal state is only 32kB, so if you save this at 1MB offsets, you can reduce the amount of data you need to decompress for one file access to a constant. https://github.com/mxmlnkn/ratarmount does this, apparently using https://github.com/pauldmccarthy/indexed_gzip internally. zlib even has an example of this method in its own source tree: https://github.com/gcc-mirror/gcc
Read the rest
/blob/master/zlib/examples/... All depends on the use case of course. Seems like the author here has a pretty specific one - though I still don't see what the advantage of this is vs extracting in JS and adding all files individually to memfs. "Without any copying" doesn't really make sense because the only difference is copying ONE 1MB tar blob into a Uint8Array vs 1000 1kB file blobs One very valid constraint the author makes is not being able to touch the source file. If you can do that, there's of course a thousand better solutions to all this - like using zip, which compresses each file individually and always has a central index at the end.
In Mounting tar archives as a filesystem in WebAssembly
shevy-java·Dec 31, 2025
So his view is from a programmer / developer. That's fine. I had an issue on my local computer system yesterday; manjaro would not boot with a new kernel I compiled from source. It would freeze, at the boot menu, which I never had before. Anyway. I installed linuxmint today and went on to actually compile a multitude of things from source. I finally finished compiling mesa, xorg-server, ffmpeg, mpv, gtk3 + gtk4 - and the prior dependencies (llvm etc...). So I am almost finished finally. I had to invest quite a lot of time hunting for dependencies. Most recent one was glad2 for libplacebo. Turns out "pip install glad2" suffices here. But getting that wasn't so trivial. The project project at pip website was virtually useless; respectively I installed "pip install glad" which was too old. Also took me perhaps one full minute or more to re
Read the rest
alise it. I am tapping into LFS and BLFS webpage (Linux from scratch), which helps a lot but it is not perfect. So much information is not described and people have to know what they are doing. You can say this is fair, as this is more for advanced users. Ok. The problem is ... so many things that compilers do, is not well-described; or at the least you can not easily find high quality documentation. Google search is almost virtually useless now; AI just hallucinates and flat out lies to you often. Or tells you things that are trivia and you already know it. We kind of lose quality here. It's as if everything got dumbed down. Meanwhile more and more software is required to build other software. Take mesa. Now I need not only LLVM but also the whole spirv-stack. And shaderc. And lots more. And also rust - why is rust suddenly such a huge dependency? Why is there such a proliferation of programming languages? Ok, perhaps C and C++ are no longer the best language, but WHY is the whole stack constantly expanding? We worship complexity. The compilers also become bigger and bigger. About two days ago I cloned gcc from https://github.com/gcc-mirror/gcc. The .tar.xz sits at 3.8 GB. Granted, regular tarball releases are much smaller, e. g. 15.1.0 tar.xz at 97MB (at https://ftp.gnu.org/gnu/gcc/?C=M;O=D). But still. These things become bigger and bigger. gcc-7.2.0.tar.xz from 9 years ago had a size of 59M. Almost twice the size now in less than 10 years. And that's really just like all the other software too. We ended up worshipping more and more bloat. Nobody cares about size. Now one can say "this is just static code", but this is expanded and it just keeps on getting bigger. Look at LLVM. How to compile this beast: https://www.linuxfromscratch.org/blfs/view/svn/general/llvm.... - and this will only get bigger and bigger and bigger. So, back to the "are compilers your best friend"? I am not sure. We seem to have the problem of more and more complexity getting in at the same time. And everyone seems to think this is no issue. I believe there are issues. Take slackware; basically it was a one person maintains it. This may not be the primary reason, but slackware slowed down a lot in the last some years. Perhaps maintaining all of that requires a team of people. Older engineers cared about size due to constraints. Now that the constraints are less important, bloat became the default.
In The compiler is your best friend
TuxSH·Aug 31, 2025
In particular, std::thread constructor's (the non-default one) has a workaround against LTO optimizing the pthread call away: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-... > Parallelism without pthread To get __atomic_add_dispatch to work, looks like one is expected to ensure pthread_create is referenced. One way to do it without creating a pthread or std::thread, is to do it outside LTO'd files, or like they did above. > > It is possible to create threads by using the OS syscalls bypassing completely the requirement of pthead As the other person said, it is impratical to do so, and it's easier to just reimplement gthread and pthread functions to be hooks (some toolchains do this).
In Shared_ptr: the (not always) atomic reference counted smart pointer (2019)
StillBored·Jul 8, 2025
I'm not sure I understand what your trying to say here WRT to cpu microarch optimization with multiple cpu microarches in the machine. Maybe something about SMT/hyperthreading? But that doesn't appear to be what your saying either. AKA: I'm talking about the uplift one gets from say -march=native (or your arch of choice), FDO/PGO and various other optimization choices. Ex: Instruction selection for OoO cores. The compiler can know you only have to functional units capable of some operation with coreX, and your codes critpath is bottlnecked by those operations and can adjust the instruction mix to (mis)use some other functional units in parallel. Two units doing X, and one doing Y. Or just load to use latency, or avoidance of certain sequences, etc. Those optimizations are tightly bound to a given core type. Sure modern OoO cores do a bett
Read the rest
er job of keeping units busy, but its not uncommon to be working around some core deficiency by tweaking the compiler heuristics even now. Trolling through the gcc machine definitions: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i38... So, when the CPU's are heterogeneous with differing optimization targets the code author ends up picking 'generic' optimization targets, and this decision by itself can frequently mean leaving a generation or two of performance behind vs the usual method of just building a handful of shared libraries/etc and picking one at runtime based on the cpu type. Although, sure an application author can on some platforms hook a rescheduling notification, and then run a custom thread local jump table update to reconfigure which code paths are being run, or other non-standard operation. Or for that matter just set their affinity to a matching set of cores, but none of this is a core operation in any of the normal runtime/etc environments without considerable effort on the part of the application vendor.
In Intel's Lion Cove P-Core and Gaming Workloads
shakna·Jun 8, 2025
It returns a new pointer, with the same buffer, as I said already. "There's a different length marked along with the pointer, but that's it." You need a slice, which has a different length. That is how you do it, without a new allocation. It's effectively: struct String { size_t length; char\* buffer }; struct String\* Unbounded_Slice(struct String\* original, size_t Low, size_t High) { struct String\* slice = malloc(sizeof(struct String)); // Bounds checking would go here... slice->buffer = original + Low; slice->length = High; return slice; } (The exact definition of a string is implementation-defined. But that's the concept.) Ada enforces safe ranges, which means you need to carry the length of the slice somehow. It does not use C's 0-terminated strings. So slicing does no
Read the rest
t work the same way as strtok or other self-modifying systems - the length isn't guessed, it's known. But if you change one character in the buffer of the slice, it'll be changed in the original Unbounded_String too. For trimming whitespace, you're right that Unbounded's standard Trim may reallocate. It carries multiple buffers, and when you Trim sometimes it will just hand it back, other times it'll reallocate. [0] Mostly for performance tradeoff. Keeping the original can make iteration slower, as it holds multiple buffers. So, to implement our own - with one caveat. Slice can't handle 0-length, because range safety is enforced. So in the case of a wholly whitespace string, we'll be doing a whole new allocation. -- This line is just for pasting into godbolt pragma Source_File_Name (NTrim, Body_File_Name => "example.adb"); with Ada.Strings.Unbounded; with Ada.Strings.Maps; use Ada.Strings.Unbounded; function NTrim(Source : Unbounded_String) return Unbounded_String is Len : constant Natural := Length(Source); First, Last : Natural; Whitespace : constant Ada.Strings.Maps.Character_Set := Ada.Strings.Maps.To_Set(" " & ASCII.HT & ASCII.LF & ASCII.CR); begin if Len = 0 then return Source; end if; First := 1; while First <= Len and then Ada.Strings.Maps.Is_In(Element(Source, First), Whitespace) loop First := First + 1; end loop; Last := Len; while Last >= First and then Ada.Strings.Maps.Is_In(Element(Source, Last), Whitespace) loop Last := Last - 1; end loop; if First > Last then return To_Unbounded_String(""); end if; declare Trimmed_Length : constant Natural := Last - First + 1; begin if Trimmed_Length >= 3 then return Unbounded_Slice(Source, First, First + 2); else return Unbounded_Slice(Source, First, Last); end if; end; end NTrim; The resulting compilation [1] has a few things. Our whitespace map gets allocated and deallocated most of the time. A map is harder to treat as a constant, and the compiler doesn't always optimise that nicely. Most of the code is bounds checking. No off-by-one allowed, here. Where first is greater than last, you get a new full allocation. [0] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna... [1] https://godbolt.org/z/x8Erhqn5n
In Ada and SPARK enter the automotive ISO-26262 market with Nvidia
whytevuhuni·Jun 7, 2025
I see it does what you're saying on the "else" branch, but that just returns the previous string unmodified, which makes sense. The more important one is the "if" branch though. Looking at your Godbolt example's assembly, even if I add -O3, I see it does a call to "ada__strings__unbounded__unbounded_slice", but until I know the contents of that I can't say whether the pointer it returns is derived from the same allocation as the original one, or from a new allocation that the string was copied to. You're using the Unbounded_Slice function [1], which calls To_Unbounded_String [2], which calls `new String` [3], which you mentioned in a previous comment that it will allocate, right? The kind of operation I'm looking for is something like a "Trim_Whitespace" function that re-uses the old allocation without copying all the data, even when ther
Read the rest
e is whitespace to trim. [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna... [2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna... [3] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna...
In Ada and SPARK enter the automotive ISO-26262 market with Nvidia
shakna·Jun 6, 2025
Allocating a new String, requires... "new String". You issue the "new" command, or the source does. But what Unbounded does is... "U.Reference (U.First .. U.Last)". It returns a reference. It's not duplicating, because that would defeat the point of its entire existence. Its the buffer, containing one or more string objects, and you're just slicing a reference out of it - because that's the point. If you want a String, you need to allocate one. function Slice (Source : in Unbounded_String; Low : in Positive; High : in Natural) return String; For this - there is no `out` marked. What you're grabbing is part of Unbounded, and the compiler won't let you deallocate it. Because it's owned, as a reference, to the Unbounded String. For example, here's the actual GNAT source of the function [1]: function
Read the rest
Slice (Source : Unbounded_String; Low : Positive; High : Natural) return String is begin -- Note: test of High > Length is in accordance with AI95-00128 if Low - 1 > Source.Last or else High > Source.Last then raise Index_Error; else return Source.Reference (Low .. High); end if; end Slice; A pre-existing reference is returned. There is no allocation that happens whatsoever. [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna...
In Ada and SPARK enter the automotive ISO-26262 market with Nvidia
cmovq·May 21, 2025
Interestingly, a complete implementation of strtol [1] is shorter than this wrapper. If you don't like strtol's API or error handling, just implement your own. [1]: https://github.com/gcc-mirror/gcc/blob/master/libiberty/strt... > If an overflow is detected, it calls abort() An aside, but this doesn't detect overflows on Windows due to both long and int being 32 bits (you'd want strtoll for that).
In Ratatoi is a C libary that wraps stdlib's strtol (as atoi does), but it's evil.
benesch·May 11, 2025
It’s hard to overstate the amount of service Ian provided to the Go community, and the programming community at large. In addition to gccgo, Ian wrote the gold linker, has blogged prolifically about compiler toolchains, and maintains huge swaths of the gcc codebase [0]. And probably much, much more that I’m not aware of. I’ve had the pleasure of trading emails with Ian several times over the years. He’s been a real inspiration to me. Amidst whatever his responsibilities and priorities were at Google he always found time to respond to my emails and review my patches, and always with insightful feedback. I have complicated feelings about the language that is Go, but I feel confident in saying the language will be worse off without Ian involved. The original Go team had strong Bell Labs vibes—a few folks who understood computers inside and o
Read the rest
ut who did it all: as assembler, linker, two compilers, a language spec, a documentation generator, a build system, and a vast standard library. It has blander, corporate vibes now, as the language has become increasingly important to Google, and standard practices for scaling software projects have kicked in. Such is the natural course of things, I suppose. I suspect this cultural shift is what Ian alluded to in his message, though I am curious about the specific tipping point that led to his decision to leave. Ian, I hope you take a well-deserved break, and I look forward to following whatever projects you pursue next. [0]: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS
In Leaving Google

Showing the 15 most recent of 122 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.