@miodvallat
To this day, I still have this board, and occasionally run it for a test drive.
Old hardware is so much more robust!
Do you have problems with the capacitors on your machine park? An SS20 has blown one, but my SS5 is still running…
<deraadt> demand that they not be worse
Yeah, like that’ll go so well… (having had to fix the same for former coworkers with… insufficient svn and/or git skills, I know) but good it got resolved well in the end.
You’ve switched {even,odd}64 there, in the “oh no!” section.
the best debugging tools of the trade
😹
True, until you hit the situation where adding it either mixes up the registers sufficiently to hide the bug or hides the miscompilation gcc bug. But, mostly yes.
I could not figure out how to make gcc 2.95 handle this shared area the way gcc 2.8 did, and actually, there were probably very good reasons to change this behaviour. To remain on the safe side, I opted to stop defining STACK_PARMS_IN_REG_PARM_AREA.
Sounds like an ABI break though? I wonder why GCC does that saving/restoring…
The next one was the libc fix.
That link 404s.
Engrish commit messages are normal for us Europeans ;_)
-Wpedantic-latin: an erratum, a processor erratum, multiple errata.
And, it’s good you write about compiler bugs. I just read gccint(GNU) and it turns out that PCC struct return (as opposed to register struct return) sometimes involves caller-provided stack space and sometimes “static storage”, which is indeed global. I’ll have to have a look at mine… Merci!