Andrea (Drea) Tamar Pinski

@malwareminigun@infosec.exchange

"Everyone has a different opinion " Again see the eposide of Silicon Valley.

Anyways there is an option for GCC to change the tab stop. But most don't know about it. -ftabstop=.

@malwareminigun@infosec.exchange @chandlerc@hachyderm.io See the eposide of Silicon Valley. It was a mistake that this fight even happens. Anyways tabs with spaces rules the world. A tab is always every 8th column; nothing else makes sense. And windows and modern editors are broken.

@notbobbytables@infosec.exchange glibc side of things is discussed here: https://inbox.sourceware.org/libc-alpha/PAWPR08MB8982DA2C405BDC8CE4DC66AE83F42@PAWPR08MB8982.eurprd08.prod.outlook.com/T/ gdb side of things is discussed here: https://inbox.sourceware.org/gdb-patches/20260629153203.10142-1-muhammad.kamran@arm.com/

@notbobbytables@infosec.exchange So what happens is gdb breaks. Because it overloads malloc. It is a bug in gdb and a newer gdb will not be released for a while. So it was decided to revert the glibc patch for now. And wait till the next release cycle for the glibc patch. The gdb fix went in as it does not break anything else too. I would provide a link but sourceware.org is under a huge ddos attack due to Ai bots.

@brouhaha@mastodon.social @revk@toot.me.uk >I am slightly curious as to whether the GCC implementation uses a display vector, or a static link in the stack frame. It is a stack chain but it is "unnested" so the stack chain is really just a struct these days. For pre-GCC 4.0, it was a full stack link that was passed to the functions. The "unnesting" is done in tree-nested.cc. For nested function which are called indirectly information is below: For some ABIs (e.g. powerpc64 ABIv1 [maybe ABIv2 too]), since there is already a fat pointer for function pointers (with an context pointer), it will use that. For others, it uses the stack and for others still it will use statically allocated function pointers (aarch64 darwin) [this is swappable to compile time even].

@JamesWidman@mastodon.social The weird thing i saw about p4 is the developers were like we like our bison/flex parser/lexer. As someone wrote their parser and lexer for p4 I was super confused why they like it. The lexing nor the parsing part was the big issue with p4 but rather the semantics were not always fully defined. Especially their type matching for function calls. They left it up for implemented defined there. Especially with generics being included. It was fun to implement and get similar semantics and even prove the semantics and implementations dont line up.

@JamesWidman@mastodon.social Oh p4 is another language which does not take into account non ascii identifiers into account. It was never even brought up as a problem. The main reason why many of these languages do that is because they depend on flex rather than hand written lexers.

@JamesWidman@mastodon.social Japanese code is written with huge amount of Japanese comments. All of the cell specifications were translated into Japanese for both Sony and Toshiba even if the original was written in English. Chinese code is all native in Chinese. I had to wait for someone to translate comments for me while I was trying to help aliaba improve their code. Including their open source code. The English omly crowd is hugely Americans and British folks who are have not learned any other language or hate on non native speakers. Even the push for llms for translations to English is another English only thing. Using a human translator is good, learning English is neutral. But pushing llms for translation is just bad.

So this VRP regression is one of these; this is odd and you keep on thinking why is this code causing issues later on.
And then you remember there is a cache in place. And then you think can reset the cache after this code is done; not exactly so things get complex.
Basically time to hand this over to the person who designed this whole thing; maybe they can think of a decent way of fixing this.

Look prototyping something should be fun and rewarding. Having a computer do it for you is boring and not rewarding.
Yes experience can make the prototyping faster but that is just like doing an outline of a book or an outline for drawing. Both are types of prototyping. You lay down the infrastructure of a drawing or book first via these outlines.

You could claim that your english instructions to the computer is an outline (yes it is but for a different reason than you think). And that the computer takes that outline and makes something. But it didn't make anything but rather it just took the words/tokens and did a search of previous work and put that all together. It created a derivative work of many things all mashed together. It didn't create anything new. Unlike when you create something .

Debugging a vrp miss optimization regression.

Lucky it is just a regression in gcc 16.
And only shows up in a small cases that I highly doubt it will affect real code.

Today reminds me that I am not a super human and that I have only so much time in the day.
I try to have a good balance between cleanups and improvements for gcc.
In fact most of my cleanups are directly related to the improvements I am doing

Finally understood how to implement this piece of code and the old code too.

Plus it should give an infrastructure to implement another piece of code. That a coworker was implementing.

@SRAZKVT@tech.lgbt yes oop vistor pattern. What I find in the code that does those kind of is missing part of the point of oop. Most of the time the vistor code should belong with the class itself rather than having a seperate vistor class. A big example of over use of the oop vistor code is the p4c compiler. When I wrote my own P4 front-end. I used oop/classes but things like cloning and "generics" replacement and folding was handled by each AST itself rather than a vistor class for each of those things.

I find the code that uses visit style programming bad.
Sorry LLVM; I think it is badly written code and is a bad style of code in general.

Yes some folks are adding that style to GCC for the rust front-end.

But I think there are better ways of writing the code. Especially when there are things like statements that would share the same code.

Yes I would say C++ code popularized it and I think it is poorly thought out code.

Sent out an RFC for GCC to turn off `-ftrapping-math` by default for C and C++.
This will make GCC inline for clang/LLVM.
A few years ago I would have recommened doing the opposite that is an RFC for Clang to change its default but looking into GCC more; GCC really does not implement -ftrapping-math correctly and seemly never has.

@SRAZKVT@tech.lgbt did swift use it? I have not looked into their generics yet. I know rust does. I have not looked into zig either.

@mirabilos@toot.mirbsd.org @joe@f.duriansoftware.com https://developer.arm.com/documentation/109697/2025_12/Feature-descriptions/The-Armv8-8-architecture-extension "FEAT_MOPS, Standardization of memory operations"

@joe@f.duriansoftware.com @mirabilos@toot.mirbsd.org I assume for aarch64 with the mops instruction it always inlines memset anyways so what does it matter there :). /me goes off and hides since he only cares about targets with MOPs now.

@mirabilos@toot.mirbsd.org @joe@f.duriansoftware.com

https://github.com/llvm/llvm-project/blob/8ebd85716101c392fca08fa6483628831d6e2865/llvm/lib/Target/AArch64/GISel/AArch64GlobalISelUtils.cpp#L77

The important check is:

Libcalls.getLibcallImpl(RTLIB::BZERO) == RTLIB::Unsupported

@glyph@mastodon.social It has to do with his blog entry on Bambu Lab. I suspect.

@fay59@tech.lgbt

So I use both GUI editors and vi. For quick and simple (and most of the time small) stuff, it is faster to use vi (for me).

For an example most of my GCC testcases are almost all written via vi. Creating a new file is easier using vi rather than a GUI; especially copying the file into the correct location afterwards and having to edit it after testing it (make check-gcc RUNTESTFLAGS=...).

Larger changes and changes which I have to think about I use an editor with a GUI (notepad++).

I also use vi to read code in many cases more than a GUI editor but that is because edit vs command view is more natural for that. But that is also if I was searching for something quickly. Rather than something which I need to keep in view for a lot longer and then I use notepad++.

For me I use both for different purposes and for different lengths. I won't leave open a vi session for hours on end while I will leave open a few notepad++ sessions for days on end. (yes I use screen too).

@giflian@techhub.social long covid?

[RFC PATCH 0/3] wasm: New backend (for GCC)
https://inbox.sourceware.org/gcc-patches/20260505223045.347444-2-feedabl3@gmail.com/

Canonical ceo Mark is huge tech bro who peaked on high school as obvious by his questions about experience during high school.
So his company choosing a half finished utils is just peak white cis male who peaked in high school.

@thephd@pony.social @CursedSilicon@social.restless.systems As I mentioned anyone can sign up and get an account. We are trying to encourage folks to use it especially if they rather use it than emailing patches. We have a more open policy giving access to folks have their own repo hosted here than on the main repo. The only thing we dont want is private repositories and code that is not related to projects hosted on sourceware (there might be exceptions but those are handled on case by case). But we want folks to have their own branches and such. And not worry about the "qualify for an account" idea either.

@CursedSilicon@social.restless.systems @thephd@pony.social No but we (the GCC project) are testing a Forgejo based forge which can be accessed at: https://forge.sourceware.org/gcc/gcc-TEST Anyone can sign up for an account and then get access to have patches reviewed that way (patches are still sent to the email list though). See https://gcc.gnu.org/wiki/UsingForge for more information.

@ireneista@adhd.irenes.space @lcamtuf@infosec.exchange "Netscape went bankrupt trying to re-write their software from scratch" It is also why Microsoft Edge went from something written from scratch to be a fork of chromium. The story is the same and even more it is about the similar product. Plus it is a recent example of the whole starting from scratch issues.

"Woman are supposed to submissive."

That is the thinking of why tech bros call their chatbot by women pronouns.

Plain and simple.
It is the same reason why ships and cars are woman names too.

Nothing new here.

It is also why transwomen are not women to them because transwomen correct men.

It is always me I am the top of the food chain be submissive to me.
The whole chucked, calling men girls, etc. Happens too.

It is all interconnected.

@thesamesam https://sourceware.org/pipermail/binutils/2015-February/087626.html So it was closer to 10 years rather than 15. So gcc 6 or 7.

@thesamesam gcc internals uses slim rather than thin https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html I also cant remember when gcc switched from full lto to WHOPR by default but it was about the same time hjl linux binutils went away. And the bfd linker got plug-in support. That was so long ago too; maybe 15 years ago. The original whorp mode was gold only as plug-in support was gold only.

@thesamesam @mgorny

Backporting just via git cherry-pick is very very bad.

Even yesterday in GCC there needed a fixup for backport (it applied cleanly via git cherry-pick too but produced wrong code) just on newly branched GCC 16. https://gcc.gnu.org/pipermail/gcc-patches/2026-May/715488.html :).

@mgorny On a slightly related subject I think many free/open source projects do have a LTS issue. Even gcc which only does 1 major release a year. Gcc has a support cycle of 4 years. Is that long enough or does it really need to be longer. Some folks complain gcc does not release often enough. While others complain gcc should support much older releases. There are some bugs which are hard (not impossible) to fix in older releases of the cycle due to code infrastructure changes. I can provide a few examples which I fixed in the last year, backporting the fix would be hard. But I can also say those cases didnt show up in a bug report by an user but rather myself looking for a specific case at the time (not even found by a fuzzier). The others were due to a fuzzier (with some options which most folks dont use or some odd code which is possible in real code but I would doubt show up). To do the backports would require to spend a few days to do them and if it was an obvious issue from code in the wild, I would spend that time. Now if you look at llvm, there is what a few minor releases after the major one and then off to the major one.

@mgorny I think the failure here goes to show that kernel LTS is not really a LTS at all. I have to wonder why this was not all stop event for the folks employed by the Linux foundation. I can understand say gcc where there are no maintainers employed by a foundation but linux foundation exists and employees some of the Linux maintainers. Greg is one such example of that.

@slava@mathstodon.xyz @andnull@social.nouveau.community No i get it right. Be was not using gcc until post 1997/98.

@slava@mathstodon.xyz @andnull@social.nouveau.community Well metrowerks might had been acquired by apple rather than Freescale. Or did I get the time lines wrong.

Do you want some toast?
How about an English muffin?

@zyx @jorge

The default for x86 is pc via config.sub: # We use pc' rather than unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users.

If architecture of a building an art then is so architecture of a program an art.

User-interface is art as is the design of a building is art.

Internals of say how floors are put together and pipes are also considered art. So code is art too.

@bshn@hachyderm.io Gcc compile is not bad if you just compile gcc and not the target libraries and not do a bootstrap. Maybe 5-10 minutes. Incremental builds are really fast; I do them all the time. Just dont touch a shared header otherwise everything gets rebuilt.

Where gcc build gets slow is more about the target libraries and multilib (which you can disable) and the bootstrap. Doing the bootstrap is you build most of the code 3 times including the runtime libraries.

${src}/configure --disable-bootstrap --enable-languages=c++ is the fastest.

When doing gcc development I mainly take a previous built objdir and the update the sources and just rebuild cc1/cc1plus and run a small subset of the testsuite. When I am happy with the patch i run the a full bootstrap/test cycle (takes 2-3 hours now). Testsuite takes a long time these days. Most folks wont run the testsuite so ....

Over the years I just assigned myself bug reports. And then never get around to fixing them. This year I have done the opposite and started to unassign myself and for some of them I also decided to put them in the easy to fix list and even put them in the newsletter.
Guess what the bugs I had assigned to myself are now being fixed.

The summary here is dont be greedy and instead spread the work around. And getting in new folks might be easier than we had thought. Provide them with guidance of what can be done and folks will come and fix it.
The other thing I learned now is that unless there are provided steps on getting partial transitions finished nobody is going to fix them. So it is better to write them up for new comers to work on than just say it is partial transitioned.

When I first started this newsletter I did it as I wanted to know what went in the last week but I now have turned it into gaining new contributors and hopefully folks will stay around. I am also learning so much about how to attract new people. And even learning about gcc missopportunities for the last 20 years here. And hope folks see this work and see that it is working and start doing similar stuff.

On reviewing side of getting more reviewers, similar things need to happen. Provide an opportunity for someone nervous about reviewing to come in and review a patch. Even if it is a private review to a mentor.
I suspect there are folks out there that want to review a patch or two but dont know how to start or even how to select a patch to review.

Even though we old timers learned the hard way to review, it does not mean new folks have that same experience.

Let's talk about "Predictable calling conventions" for a second. It is a good thing to have a stable one. And well documented one. Without this performance analysis is hard to do.

Also let's talk about portability, and why it is a good thing. Depending on one implemention of the language makes your code not portable at all. In fact it does the opposite. You now depend on one source base which might be go away.

You think bash and gnu sed, gnu awk got where it was not for portability you missing the point. Likewise of gcc.
The extensions of gcc, gnu sed, gnu awk and bash was only a boost to its usage in the last 20 years once it was obvious unix war was over.
Posix was the end of the war. Oh posix was done to compete with windows. Companies like sun hated one of the two groups that formed the open group but in the end they knew it was needed to beat the monopoly of Microsoft.
History is repeating itself with one language.

One thing I noticed is that sometimes LLVM does not handle non-constant form of some cases. In this case, you just need to know if the always variable was positive (or zero).
For GCC the question is easy answered by tree_expr_nonnegative_p for both non-constant and the constant case. So it is just easier to handle the non-constant case than even trying to just handle the constant case.

This was about https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110262 .

@lcamtuf@infosec.exchange
While C/C++ does not support that directly @compiler_explorer@hachyderm.io does.

So recently I have been thinking about conversion projects that are partly completed in gcc. Most of them are at a state where folks who are new to the project could come in and help finish them up. Many of these projects have been at this state for over 10 years too.
It is if everyone accepted the idea they are partly completed.
And now with the live of llms some folks want to use them to finish it. I already proved that is not needed for some, new folks are willing to do the small changes to learn gcc and make it better.

https://gcc.gnu.org/pipermail/gcc-patches/2026-April/714691.html is an example of a totally new person helping with this.

So far with my weekly newsletter and the weekly easy issue to solve; i have gotten 2 new folks who now have at least a patch each pushed into the repo. Would they have done gcc development without this, I dont know. But what I can say is getting a patch in within a week of posting is new.

RE: @alexa_pavlova@mastodon.social

The bug was not really a bug. It was a loophole that Apple didn't realize until it was too late.
Also it was a logic issue. Rust would NOT fix that issue.
Folks like I quoted here is exactly why I mention rust is a cult.
Also Apple is moving towards safety C++ and C faster than most other company because they control programming langauge inputs. Unlike most other places like Linux (open source). It is both a blessing and a problem.

@penguin42@mastodon.org.uk @regehr@mastodon.social Well IBM had most of their compiler engineers working on XLC (toby) at the hight in Toronto. Most of the GCC developers at IBM at the same time were mostly in Australia at the oz linux lab (which is now closed down). Nvidia engineers are also spread across many different cities too. So if it is mean same place as being same company then things are different. Even Qualcomm has at least 4 sites for their compiler engineers . I don't know how many are in the GPU side of things either.

Look a 30 year having sex with a 16 year is just creepy. No matter how famous that 30 year old.
No matter how legal it is. It is creepy and definitely was not consensual. There is a power dynamics that causes it not to be.

@navi Adding shell arrays makes shell more useful and needing to use awk less :).

@whynothugo Co-Authored-By: GNU ed 1.22