Re: About gsoc

[Dave Blanchard]

On Tue, 5 Mar 2024 09:32:26 +
Jonathan Wakely  wrote:

> On Tue, 5 Mar 2024 at 09:31, Jonathan Wakely  wrote:
> >
> > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard  wrote:
> > >
> > > On Mon, 4 Mar 2024 10:06:34 +
> > > Jonathan Wakely via Gcc  wrote:
> > >
> > > > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc 
> > > >  wrote:
> > > > >
> > > > > Hello sir/mam
> > > > > I am mokshagna reddy from Mahindra university and i am currently in 
> > > > > my second year of under graduation in Btech artificial intelligence i 
> > > > > had intrest in your organization and i know programming languages 
> > > > > like c, c++,python   how can i contribute from now and can u send 
> > > > > details about the project . Thank you hope i will get reply as soon 
> > > > > as possible.
> > > >
> > > > If you want to apply for GSoC and convince people you're a suitable
> > > > candidate and would invest the necessary time and effort, maybe you
> > > > should find details of the project for yourself instead of asking
> > > > others to provide them.
> > > >
> > > > A simple web search would have found 
> > > > https://gcc.gnu.org/wiki/SummerOfCode
> > >
> > > Wow, what a fucking prick this guy is.
> > >
> > > My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
> > >
> > > Maybe he did you a favor with such a response. Why should anyone waste 
> > > their time and energy donating free work to a dumpster fire project like 
> > > GCC, when this is the thanks you get? I recommend contributing your 
> > > valuable time to LLVM/clang or some other non-GNU project instead, where 
> > > it will likely be more appreciated.
> >
> > GSoC isn't free work, it's paid. Get a clue, or go away.

Oh, I see! Since this poor young university student might expect to receive 
small payment  for his time spent in improving GCC--which is a very complex 
project that is not easily modified--therefore you're excused in treating him 
like yesterday's trash.

Makes perfect sense to you, I guess.

> 
> That's directed at Dave, in case it wasn't obvious. He contributes
> nothing here except bile.

Have you read any of your own posts? You are one of the biggest assholes I've 
encountered in the open source world, and I've met some real dicks. People like 
you have been driving newbies away from Linux/BSD for decades. You never learn.

What you call "bile" is merely me being the one guy who's willing to call you 
on your bullshit. This is hardly the first time you've shown your ass to 
someone who was trying to help the GCC project in some way. Remember Stefan 
Kanthak? Others may remember he pointed out serious problems with the GCC 
optimizer on x86-32 which you also rudely dismissed, calling him a noob, etc.

Are you an official representative of the GCC project, or just some random 
asshole who lurks here and thinks he owns the place? What do YOU actually 
contribute to this list that is so valuable it excuses your rudeness? I wonder 
if Mr. Stallman approves of you helping to drive away potential GNU 
contributors, at a time when this project needs fresh blood arguably more than 
ever. Let's find out.

Dave

Re: About gsoc

[Dave Blanchard]

On Mon, 4 Mar 2024 10:06:34 +
Jonathan Wakely via Gcc  wrote:

> On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc  
> wrote:
> >
> > Hello sir/mam
> > I am mokshagna reddy from Mahindra university and i am currently in my 
> > second year of under graduation in Btech artificial intelligence i had 
> > intrest in your organization and i know programming languages like c, 
> > c++,python   how can i contribute from now and can u send details about the 
> > project . Thank you hope i will get reply as soon as possible.
> 
> If you want to apply for GSoC and convince people you're a suitable
> candidate and would invest the necessary time and effort, maybe you
> should find details of the project for yourself instead of asking
> others to provide them.
> 
> A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Wow, what a fucking prick this guy is.

My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness. 

Maybe he did you a favor with such a response. Why should anyone waste their 
time and energy donating free work to a dumpster fire project like GCC, when 
this is the thanks you get? I recommend contributing your valuable time to 
LLVM/clang or some other non-GNU project instead, where it will likely be more 
appreciated.

Dave

Re: 'posix_spawnp' error in build

[Dave Blanchard]

On Mon, 25 Dec 2023 10:28:14 -0600
Segher Boessenkool  wrote:

> That is wrong.  Build dir as a subdir of the source dir is not
> supported.  It might work in many cases, but that does not mean it is
> okay to do.

Works perfectly fine on every version of GCC I've used, from 5 to 12, and I've 
done this countless times in various configurations. 

If there is any kind of problem here, GCC needs to fix its junk build process, 
instead of being the one package on the planet requiring some absurd 
out-of-directory build.

> I don't know if that is one of the weird problems caused by this.  Easy
> enough to find out.  First "make distclean", and then "git status".
> 
> The error message says that the newly compiled compiler driver ("xgcc",
> which will be insbtalled as just "gcc" eventually) cannot execute the
> newly compiled actual C++ compiler ("cc1plus"), not from the place it
> thinks it put it, anyway.

It's GNU software, so go figure. 

A mysterious "No such file or directory" error here can also indicate the 
binary isn't finding the libc loader for some reason, due to bad rpath or some 
such. Use 'readelf -a' to ensure the C library loader path is correct.

Dave

Re: issue: unexpected results in optimizations

[Dave Blanchard]

Hi Jingwen,

This is the same GCC which in recent versions produces something like two dozen 
extraneous, useless, no-op instructions when doing a simple 64-bit math 
operation on 32-bit systems, and does not use SSE properly either. In each 
major release these problems get worse. The code generator is clearly in a 
state of slow degradation, starting about GCC version 5 or 6--not 
coincidentally the same time when the major version numbers started 
increasingly so rapidly, although it really has been junk since the beginning.

Stefan Kanthak hammered this point home numerous times on this list, much to 
the ire of people like Jonathan Wakely who called him a noob, telling him to 
"go file a bug" in a filing cabinet in some obscure corner of a disused 
lavatory so that it can be safely ignored, and so on. 

It seems that if correct code generation and optimization is important to you 
(as it should be), GCC is NOT the compiler to be using. I'm all the time 
discovering new and crazy problems with this convoluted pile of junk. My recent 
foray into bootstrapping GNAT (ADA) has opened up yet another can of worms. 
It's broken on GCC 10, and even more broken on GCC 9, and this despite 30+ 
years of development. 

Sometimes these days I even blame GCC when it wasn't at fault after all, 
because it's making itself into more and more of a likely suspect as the years 
go by.

I haven't examined the code output of Clang to see how it compares, but it's 
worth serious investigation. 

Dave

Re: GNAT on GCC 10.x has build problems

[Dave Blanchard]

Did you know it's possible to read my post and ruminate upon its meaning 
without responding this way? I bet you didn't know that.

I'm not asking for any of your 'help', in case it wasn't obvious. I'm quite 
used to solving the GCC project's problems myself by now, since the GCC project 
seems determined not to fix its own problems, judging by the typical 
commonplace response of ingrates such as yourself. I simply asked if this 
broken piece of shit--which should have been designed correctly decades ago but 
somehow isn't--has finally been fixed, or if it continues to be a broken piece 
of shit. 

Dave

GNAT on GCC 10.x has build problems

[Dave Blanchard]

Hello all, while bootstrapping GNAT onto my cross compiled system with GCC 10.x 
I found that the make script leaves something to be desired. 

First off it doesn't add the host prefix to the cross compiler binaries; it 
calls gnatmake, gnatlink, gnatbind, gnatls, and gcc without the 
x86_64-linux-gnu- prefix, requiring an ugly hack to symlink to those tools to 
complete the build. Also at the end of the build there is an error when it 
tries to install gnatdll, which isn't built, doesn't exist, and is for Windows 
only. 

Does anyone know if these problems are fixed in later GCC versions? And do 
these people even test their obviously broken crap before releasing it on the 
world?

I also note that the AdaCore team seem to be doing everything in their power to 
railroad people into giving them money for their proprietary compiler. First 
they disabled C and C++ languages in their 2018-up Community Edition binaries, 
which makes bootstrapping a full GCC impossible with these tools. I guess that 
didn't do the trick as people just used older CE releases to bootstrap with 
instead, so they discontinued CE entirely and removed links to the CE download 
page from their site, making it hard to find unless one knows what to search 
for. 

I've also been told that there is some kind of special licensing clause for the 
GNAT project which requires all code built by their GPL compiler to be GPL3 
licensed, which is a laugh as I'm never doing that. Not sure if that's actually 
true or not. 

Anyhow, it's surprising (or should be surprising) to see such shoddy 
workmanship from an anti-freedom commercial organization joined to the hip with 
GCC.

Dave

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Dave Blanchard]

On Fri, 08 Sep 2023 02:25:38 -0300
Alexandre Oliva via Gcc  wrote:

> Attribute sym, named after symver, is the one in the latest version of
> the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> possibilities that comes to mind.  The 2020-August thread has many more.

Sounds like a useful feature. Since it specifically deals with C++ name 
mangling, how about 'demangle'?

C++ is an abomination and name mangling is a perfect example of the brain 
damage surrounding this abortion of a language, but I digress...

Re: Network Services Alert#489707

[Dave Blanchard]

On Thu, 13 Jul 2023 12:10:32 +0200
Mark Wielaard  wrote:

> Hi Dave,
> 
> On Wed, Jul 12, 2023 at 09:34:31AM -0500, Dave Blanchard wrote:
> > You know, if you useless cocksuckers [...]
> 
> Please stop using this kind of language on this list.  I know it is
> annoying if the spam filters didn't catch some obvious scam message.
> But you are not helping anybody by replying to it.  And using
> offensive language, even if you are annoyed, isn't acceptable.

Really? That's all you have to add? If my tone was so "offensive", how did YOU 
help by replying to it?

I'm pretty sure I'm much, much more than "ANNOYED" about a lot of things going 
on in this world--and you would be too, if you were any kind of man. 

Maybe if you spent less time worried about inconsequential things like people's 
"offensive" language, and more time worried about how your country (you live in 
the Western world, correct?) is circling the drain, maybe the world would not 
be such a FUCKING SHITHOLE.

I will not make any more such comments in the future to this list, so as not to 
further disturb any pearl-clutching Puritans here by using "offensive language" 
(the horror!) on the Internet.

THANKS.

Dave

Re: Network Services Alert#489707

[Dave Blanchard]

You know, if you useless cocksuckers would spend half as much energy and 
cleverness figuring out some kind of morally upright way to generate income 
instead of scamming retards on the internet, you'd be billionaires by now.

This is what "civilization" has devolved to; a world of grifters scamming other 
grifters. The only difference between this guy and the rest is that his scam is 
obvious to intelligent people; the most dangerous frauds are the most 
legitimate appearing, and are heavily promoted and legally enforced by 
"authorities." Rob a bank and you go to jail; own the bank and you can rob it 
all day long. We need to bring back the guillotine.

Dave

>On Wed, 12 Jul 2023 19:44:01 +0530
Michael Smith via Gcc  wrote:

> Dear user,  g...@gnu.org
> 
> Thank you again for subscribing to us!
> 
> [...]
>
> As you opted for auto-debit, the recurring fee will be debited again next 
> year on July 10, 2024, unless you choose to cancel the subscription or stop 
> auto-debit payments.
> 
> If you wish to opt out or drop all charges and want the full amount refunded 
> back to the original payment source, please contact us at +1 {888}-713-5735
> 
>  
> 
> Regards,,
> 
> Michael Smith
> Customer Support Dept.
> Toll-free Number: +1 {888}-713-5735
> 

Re: Expert Engagement

[Dave Blanchard]

On Mon, 3 Jul 2023 19:24:23 +
Richard Nardi via Gcc  wrote:

> 
> Hello,
> I hope you are having a wonderful day. I would like to engage your firm to 
> prepare my tax return for the current tax year. [...]

Sounds legit. I have a feeling you'll be asking me for my credit card number 
and bank account information also at some point, plus my home mailing address 
so you can send me all your documents, so would it be helpful if I went ahead 
and emailed those to you right now? 

Thanks in advance for this opportunity to help you with your financial 
troubles. Can't wait to get started!

Sincerely,
Dave
Professional Tax Preparer and All-Around Generous Guy
www.intuit.com
phone number: 1-800-4INTUIT

Re: New version of gnu assembler

[Dave Blanchard]

On Sat, 01 Jul 2023 13:33:07 +0100
Sam James via Gcc  wrote:

> If you've taken files from Binutils BFD, please make sure you preserve
> the copyright headers too.

Why? How is that important? That's all you have to say about this? 

Copyright is an abomination, and especially so the GPL; particularly the GPLv3. 
I hope he deleted the copyright notice.

OP: Good work and nice project. The GNU ecosystem is full of bloated shitware 
and cruft, and it's nice to see people working to get rid of all the junk so we 
can have software that is actually usable and maintainable.

Dave

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Dave Blanchard]

On Tue, 6 Jun 2023 01:59:42 +0200
Gabriel Ravier  wrote:

> [nothing of value]

If this guy's threads are such a terrible waste of your time, how about 
employing your email client's filters to ignore his posts (and mine too) and 
fuck off? 

Now YOU'RE wasting everyone's time, as your type is so skilled at doing, 
refocusing an important discussion to generic whining about "muh feelings", 
instead of the real issue at hand here: GCC's optimizer is TERRIBLE!

I for one appreciate this guy's posts, as this issue might have never been 
called to my attention otherwise; certainly not if this were relegated to the 
dusty corner of some bug list somewhere. I've now reverted to a much older 
version of GCC which will hopefully waste much fewer of my old computer's CPU 
cycles, while also (provably) not constantly breaking my system with all the 
added warnings and errors every release.

Dave

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Dave Blanchard]

On Mon, 5 Jun 2023 13:35:22 +0200
Gabriel Ravier via Gcc  wrote:

> [pages of bullshit deleted]
>
> 2. Are you aware that these emails are not only pretty useless, but 
> potentially actively counterproductive ? I'd personally expect GCC 
> developers, who are rightfully not particularly happy at the thought of 
> having to constantly suffer your belittling emails, to at best actively 
> ignore them - but even worse from what I presume would be your POV (that 
> of someone who wants GCC's optimizer to improve), this constant spam 
> might give rise to what would be a pretty reasonable response: to be 
> biased against any proposed improvement that comes from or derives from 
> your emails. 

Sounds like the response of an idiot, or a malignant individual who isn't 
interested in improving their junk code. A not-uncommon response in today's 
world, full of arrogant, self-righteous, brittle individuals who just can't 
stand criticism.

> PS: I hope you understand that I'm being somewhat generous when assuming 
> you genuinely want to get GCC's optimizer to improve,

What? Are you claiming he *doesn't* want to see it improved?

> Someone else might  instead think you're just a troll 

Not you, of course. No sir. You're smarter than that, right?

> that uses this as a pretext to send 
> inflammatory emails everywhere and waste the time of people like me.

I thought the entire purpose of these threads was to call attention to the fact 
that our time IS being wasted already, by the shitty GCC optimizer?

Dave

Re: Another epic optimiser failure

[Dave Blanchard]

On Sun, 28 May 2023 15:50:41 +0800
Julian Waters via Gcc  wrote:

> Man, these clang fanboys sure are getting out of hand

Strange reasoning you've used here. Is this sort of like how if I'm against 
Donald Trump, then I must be for Hillary Clinton, or vice versa?

That's called a "false dichotomy" FYI.

> I feel like all this garbage can be easily resolved by y'all showing this
> idiot

There's your first mistake. Hint: people who are able to hand deconstruct the 
output of a compiler's code generator and point out exactly how instructions 
are wasted are never correctly referred to as an "idiot", in the context of 
computer programming at least.

He's certainly got a few things wrong from time to time in his zeal, but his 
overall point seems to stand. Do you have any rebuttals of his argument to 
present yourself? Or do you prefer to just sit back and wait on "y'all" to do 
the heavy lifting?

> the exact proper options required 

You mean the ones which are unclear and uncertain, because the GCC 
documentation is inaccurate or simply lies?

> and attaching the resulting compiled assembly exactly as he wants it

And what if GCC is unable to produce anything like that, because the code 
generator is at the very least questionable, as his postings seems to prove?

> or if gcc doesn't compile the exact assembly he wants, explaining why gcc 
> chose a different
> route than the quote on quote "Perfect assembly" that he expects it to spit
> out

What version of GCC can we expect to generate efficient and correct code for 
this brand new, just-released "x86" instruction set? Maybe GCC 97 will finally 
get it right...which at the current rate of major version number increase, 
should be some time next year I guess.

Or rather more accurately, when will GCC's code generator stop regressing as it 
seemingly has done for many versions now, and finally Make Compiling Great 
Again?

> And Stefan? Ever heard of the saying that "the loudest man in the room is
> always the weakest"?

Ever heard the saying "if you can't run with the big dogs, stay under the 
porch"?

Are the GCC developers *trying* to subtly push everyone toward Clang, by slowly 
degrading GCC over time in hopes that people will eventually give up and leave 
in frustration? Serious question. 

Dave

Will GCC eventually support correct code compilation?

[Dave Blanchard]

On Fri, 26 May 2023 18:44:41 +0200
David Brown via Gcc  wrote:

> On 26/05/2023 17:49, Stefan Kanthak wrote:
> 
> > I don't like to argue with idiots: they beat me with experience!
> > 
> > Stefan
> > 
> 
> Stefan, you are clearly not happy about the /free/ compiler you are 
> using, and its /free/ documentation (which, despite its flaws, is better 
> than I have seen for most other compilers).

When the flaws continue to stack up as things get provably worse over time, at 
some point you need to stop patting yourself on the back, riding on the 
coattails of your past successes, and get to work making things right.

At the very least, GCC documentation is HORRIBLE, as this previous thread 
proves.

> Instead of filing a bug report, as you have been asked to do, or reading 
> the documentation, or thinking, or posting to an appropriate mailing 
> list, you have chosen to rant, yell, shout at and insult the very people 
> who could make the changes and improvements you want.

Actually, no, that's not what happened. He made a valid observation and got the 
run-around; the typical "just RTFM noob" treatment, despite pointing out again 
and again that the documentation LIES. 

The overall point however was successfully buried in the noise: looks like the 
code quality of GCC is shit anymore.

If you hand me a pile of shit wrapped up nicely in a plastic bag, guess what: I 
still don't want it, even if it's free. So I think this man (and the people of 
this mailing list) deserve a real explanation. Why does GCC generate such shit 
code?

> So who, exactly, do you think is acting like an idiot?  I'd say it is 
> the rude and arrogant fool that is sawing off the branch he is sitting on.

If the branch is rotten and splintered then maybe it's time to get off that 
branch and climb onto another one.

> Remember, these are people with /no/ obligation to help you. 

... and it often shows!

> Some do gcc development as voluntary contributions, others are paid to work 
> on 
> it - but they are not paid by /you/.  And none are paid to sit and 
> listen to your tantrums.

So is this proof of the technical and intellectually bankruptcy of the open 
source development model, or...?

If nobody wants to have detailed discussions about the technical workings of a 
very serious tool that millions are relying on day in and day out, what is this 
mailing list FOR, exactly?

Dave

Will GCC eventually support correct code compilation?

[Dave Blanchard]

On Fri, 26 May 2023 18:44:41 +0200
David Brown via Gcc  wrote:

> On 26/05/2023 17:49, Stefan Kanthak wrote:
> 
> > I don't like to argue with idiots: they beat me with experience!
> > 
> > Stefan
> > 
> 
> Stefan, you are clearly not happy about the /free/ compiler you are 
> using, and its /free/ documentation (which, despite its flaws, is better 
> than I have seen for most other compilers).

When the flaws continue to stack up as things get provably worse over time, at 
some point you need to stop patting yourself on the back, riding on the 
coattails of your past successes, and get to work making things right.

At the very least, GCC documentation is HORRIBLE, as this previous thread 
proves.

> Instead of filing a bug report, as you have been asked to do, or reading 
> the documentation, or thinking, or posting to an appropriate mailing 
> list, you have chosen to rant, yell, shout at and insult the very people 
> who could make the changes and improvements you want.

Actually, no, that's not what happened. He made a valid observation and got the 
run-around; the typical "just RTFM noob" treatment, despite pointing out again 
and again that the documentation LIES. 

The overall point however was successfully buried in the noise: looks like the 
code quality of GCC is shit anymore.

If you hand me a pile of shit wrapped up nicely in a plastic bag, guess what: I 
still don't want it, even if it's free. So I think this man (and the people of 
this mailing list) deserve a real explanation. Why does GCC generate such shit 
code?

> So who, exactly, do you think is acting like an idiot?  I'd say it is 
> the rude and arrogant fool that is sawing off the branch he is sitting on.

If the branch is rotten and splintered then maybe it's time to get off that 
branch and climb onto another one.

> Remember, these are people with /no/ obligation to help you. 

... and it often shows!

> Some do gcc development as voluntary contributions, others are paid to work 
> on 
> it - but they are not paid by /you/.  And none are paid to sit and 
> listen to your tantrums.

So is this proof of the technical and intellectually bankruptcy of the open 
source development model, or...?

If nobody wants to have detailed discussions about the technical workings of a 
very serious tool that millions are relying on day in and day out, what is this 
mailing list FOR, exactly?

Dave

Re: More C type errors by default for GCC 14

[Dave Blanchard]

On Tue, 09 May 2023 16:07:50 +0100
Sam James via Gcc  wrote:

> Florian did note this already - ABI. Implicit function declarations are
> pretty horrible in a number of cases:
> - they prevent fortification (_FORTIFY_SOURCE)

So what? Print a warning, for those who are writing new code or maintaining old 
code and actually care. Done.

> - they prevent time64 and LFS migrations from working correctly

So what? Print a warning, for those who are writing new code or maintaining old 
code and actually care. Done.

2038 is 15 years away. I'm trying to keep existing code working TODAY.

> - they break with different ABIs (see e.g. Apple's arm64 ABI)

I don't care about Apple or ARM64. I'm trying to keep old code working fine on 
x86.

> - they can cause runtime crashes when combined wtih bfd's default of
> not warning on underlinking

My system is perfectly stable, thanks. In fact it is much more stable and much 
snappier than the garbage released by the likes of Fedora, RedHat, etc. If 
runtime crashes and stability were a concern for those folks, they should start 
by dropping 'Linux Puttering' out of a helicopter.

> int-conversion generally indicates severe runtime problems as well. 

Not in my experience. My system works fine, despite approximately 10,000,000 
warnings spit out by GCC during the build process.

> Many of the cases I've seen on musl absolutely do not work at runtime and
> weren't caught by any other warnings (often because of padding mismatches).

Well that's the risk you take by changing the C standard library. My system 
works fine on glibc. If any given package has a problem on musl, I will take 
that on a case by case basis. Wrecking my build process by introducing 10,000 
new errors isn't part of the solution.

> That's why Fedora and Gentoo have been aggressively working on this
> before even proposing it. We are being proactive in making sure that
> common things are fixed.

Yeah, you're being proactive in ruining everything. Thanks. How's systemd and 
pulseaudio working out for you?

> I don't know if it's that aggressive to drop something which was
> removed in C99 because of how dangerous it is.

You're breaking old code unnecessarily by introducing an error, when the 
existing warning is perfectly fine.

If it was such a horrible, terrible, no-good thing that it must be removed 
immediately, then why wasn't this already changed decades ago? Hint: BECAUSE 
YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON.

> Also, keep in mind, Florian went around and asked many of the first
> group (the foundational folks) who didn't object.

No, he asked a few big shot million dollar well-funded distributions if they 
had any problems with increasing their workload and maybe hiring a few extra 
developers. Unsurprisingly that select group of insiders had no problem with 
it. Meanwhile there are thousands of other smaller users and organizations out 
there whose concerns are just as important.

> Not that this is a strong argument, and I don't like making it, but
> if Clang is doing it and GCC does too, it's not like they can reassess
> their choices anyway.

In fact that's exactly why GCC should continue just the way it is, so that 
people can have an actual alternative to the "bondage and discipline" approach, 
and continue keeping their old code working just fine when there are literally 
NO PROBLEMS with the status quo.


-- 
Dave Blanchard 

Re: More C type errors by default for GCC 14

[Dave Blanchard]

On Tue, 9 May 2023 16:14:28 +0100
Jonathan Wakely via Gcc  wrote:

> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".

And in the process, break half of my system, and make it even more of a pain in 
the ass to compile old software. With no real gain or benefit whatsoever. To 
hell with that bullshit.


> Accepting invalid code by default is a disservice to users. Those who
> need to compile invalid C code can use an extra option to allow it,
> the default should be to tell users their code is doing something bad.

The default ALREADY IS to tell users their code is doing something bad. It's 
called a "warning." Hello?


-- 
Dave Blanchard 

Re: More C type errors by default for GCC 14

[Dave Blanchard]

tion, and possibly int-conversion from warnings
> into errors for GCC 14.  This would give upstream projects roughly
> another year to make new releases with compatibility fixes that have
> been contributed so far.  I do not think waiting longer, until GCC 15,
> would make a meaningful difference because any upstream project that
> does not release within the next 12 months is not likely to release in
> the next 24 months, either.
> 
> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.
> 
> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
> 
> I have no data how big the compatibility impact of turning
> incompatible-pointer-types into errors will be.  For now, int-conversion
> has higher priority.  However, it looks like another change that could
> benefit developers (the first group).
> 
> I do not plan to work specifically on C2X compatibility fixes for now
> (to support bool-as-keyword, for example), but I could imagine a similar
> project a few years from now, fewer than 25 hopefully, that would enable
> GCC to make the switch to C2X by default.
> 
> Thanks,
> Florian
> 


-- 
Dave Blanchard 

Re: Good grief Charlie Brown

[Dave Blanchard]

On Tue, 13 Dec 2022 14:20:39 -0500
Paul Koning  wrote:

> I'm puzzled.  What is your purpose?  What result do you expect from your 
> messages?  What action would you like to see?

GCC is a "mailing list." This is a recent innovation in which people post 
comments about subjects they are interested in discussing, and others submit 
replies on response. 

My message was a reply in one of those ongoing conversations entitled "Good 
grief Charlie Brown", in which OP laments certain design decisions the GCC 
project was made.

A response was made to his post, containing a counter-argument.

My response to that response contained my own counter-counter-argument.

Understand?

> I see some vague hints that there are some issues. 

Really? So you are vaguely aware that the GNU/Glibc/GCC bootstrap process is 
insanely brittle and broken?

> If you want those to be addressed, you should report them as defects through 
> the bug tracker.  To do so, you should be specific as to what's failing so 
> others can reproduce what you did and see what goes wrong.

So what should be the title of this issue--"your software is insanely broken 
and buggy and basically needs a partial or complete redesign"? OK. When should 
I expect resolution of this issue?

> Apart from that, generic "I don't like what you guys did" is obviously just 
> going to get ignored as meaningless ravings.

And this should be considered surprising, considering GNU's long history of 
(seemingly on purpose) releasing junkware, despite user complaints?

Hell, I haven't even got started complaining about anything. Should we get into 
The Entire Linux Ecosystem, Led By GNU's recent bizarre decision to start 
incrementing major version numbers seemingly every 3 months? It's almost like 
you have forgotten every lesson you've ever learned about how to version 
software releases.

Dave

Re: Good grief Charlie Brown

[Dave Blanchard]

Since my response did not get posted (maybe one of the words wasn't allowed? or 
because I attached binaries?) here it is again:


Begin forwarded message:

Date: Tue, 13 Dec 2022 11:35:39 -0600
From: Dave Blanchard 
To: gcc@gcc.gnu.org
Cc: p...@mad-scientist.net
Subject: Re: Good grief Charlie Brown



> I guess if you were one of the "everybody" needing "everything" on
> "every" environment, instead of you needing what you need in your
> environment, you might think differently!

*angry, grumpy, pi$$ed off, GNU-hating distro maintainer enters the chat*

Yeah, and if you were one of those people who has spent the last 14 MONTHS 
banging your head on the wall trying to *properly* bootstrap gcc, and to 
*ensure* that the bootstrap is correct--while still having no clue after all 
this time if it is *really* correct now, or only *pretending* to be correct for 
a while, until the next time something screws up with the weirdest error 
messages imaginable, showing that it's not--YOU might feel differently.

Just like the other day when I thought it would be a simple matter to add 'D' 
language to my distro. I'm on GCC 9, switching the distro and build scripts 
over to GCC 12, and thought "hey, I'll take advantage of GCC 9 while it's here 
to build GDC9, then bootstrap GDC12 with it, and I'll have D also, finally! 
hooray!" Yeah, right. 

SOMETHING somewhere is wrong/misconfigured with the bootstrap I guess, because 
on the second build of GCC12 it dies with some ridiculous libatomic-related 
error message, and nobody on the mailing list has any idea what it could 
possibly be I guess, since nobody responded to my email. 

My response: just delete D from --enable-languages and forget I ever heard 
about it, because I'm definitely not spending ANOTHER year trying to figure out 
this junk.

Don't get me wrong, I'm happy to have GCC, but it is HORRIBLY DESIGNED 
SOFTWARE. As is GLIBC. Matter of fact, pretty much everything out of GNU is the 
most overcomplicated and/or painful junk imaginable. (gnulib anyone?) And don't 
tell me it has to be this way. I know that it doesn't. 

The freshly-generated manual pages for GCC 12.2 are attached to this email, for 
OP. [edit: removed. Sorry.]

Dave

Re: GDC environment variable - solved, but new problem

[Dave Blanchard]

> Re GCC 9.1, however beware of 
> "stage1 d21 fails to link with GDC 9.1".

Thanks for all who replied. Thanks especially for mentioning this problem, as 
my build did indeed fail with this error on GCC 9.3. I applied the fix and 
that's now resolved. Now I have the following problem:

gcc-12.2.0/libphobos/libdruntime/core/internal/atomic.d:771:24: error: 
undefined identifier '__atomic_fetch_add', did you mean function 
'__atomic_fetch_add_1'?

I tried to force --enable-libatomic which had no effect. --disable-libatomic 
caused a failure elsewhere. Well, I'm stumped. Any ideas? Thank you.

Dave

GDC environment variable

[Dave Blanchard]

Is there an environment variable like 'CC' or 'CXX', which specifies the name 
of the D compiler to use, which I might need to set when bootstrapping GCC? 
Thanks.

-- 
Dave Blanchard 

GNU = Junkware

[Dave Blanchard]

No, I'm not trolling, just venting here for a moment. So sick of garbage ass, 
crusty junkware that's always a battle to the death to accomplish anything.

I really understand where Liu Hao was coming from yesterday when he was in here 
raging against the AT assembler. I could sense the bitterness and disgust in 
him, the kind that can only come from a lifetime of bitter disappointment in 
the status quo. It's like he's just as sick and tired as I am of broken ass, 
buggy software.

GNU GCC/GLIBC IS THE MOST PAINFUL PIECE OF SHIT FUCKING SOFTWARE ON THE PLANET 
TO BOOTSTRAP.

Not even the flaming pile of dogshit that is PYTHON comes close to the misery 
and hell awaiting any hapless person who wants to accomplish what ought to be 
the Simple And Straightforward Fucking Task of bootstrapping a cross-compiled 
GNU gcc/glibc/binutils system.

I have been working on this project FOR AN ENTIRE YEAR and the pain just never 
seems to end. 

I've encountered every shitty, stupid, inane, puzzling, worthless, completely 
nonsensical error message that could possibly be generated by a piece of 
software, which almost NEVER leads toward figuring out exactly went wrong, but 
usually just deeper into the quagmire.

Seemingly the only way that will ever finally get this junk working is to just 
sit there randomly trying different stuff in the hope that it somehow moves one 
closer toward getting something that works right. 

/rant

-- 
Dave Blanchard 

Re: Please, really, make `-masm=intel` the default for x86

[Dave Blanchard]

On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc  wrote:
>> One annoying thing about GCC is that, for x86 if I need to write I piece of 
>> inline assembly then I
>> have to do it twice: one in AT syntax and one in Intel syntax.

> Why? A default is merely a default. I don't really see why changing
> that should help you specifically. A decision "which assembly syntax
> to use" is one that makes a project like ones you're contributing to,
> not GCC. If they decided to use AT syntax, they won't switch to
> Intel just because a compiler toolchain has changed their default.

While I sympathize with the desire to get rid of crud (and I agree that AT 
syntax is crud), as stated above it wouldn't really make a practical 
difference. For distro maintainers it would likely break some/many older 
packages which assumed the old default behavior, thus requiring a number of 
patches. Usually not a big deal in and of itself (though it can be if the build 
system for that package is particularly junky), but when you consider there are 
so many packages including GCC always deprecating and changing things, it adds 
up to a lot of work to keep up with it all.

-- 
Dave Blanchard 

Re: Mail delivery failed: returning message to sender

[Dave Blanchard]

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>  gcc@gcc.gnu.org
>(generated from g...@gnu.org)
>host gcc.gnu.org [2620:52:3:1:0:246e:9693:128c]
>SMTP error from remote mail server after end of data:
>550 5.7.1 Blocked by SpamAssassin

Naughty GCC mailing list, trying to spam itself, perhaps in an endless loop. 
Fortunately SpamAssassin stepped in to prevent this attempt at self-harm.

-- 
Dave Blanchard 

Re: FW: Redesigning the GCC website

[Dave Blanchard]

> However, the website for the GCC is... shall we say... "bad". 

No, we shall not say that. We shall in fact loudly compliment the GCC web site 
as being "very well designed", because it serves exactly the purpose it's meant 
to serve with minimal distraction, while loading quickly on my slow connection.

> It looks outdated compared to the GNU project's homepage. 

"Outdated" is a high compliment these days, when everything around us is 
turning into absolute dogshit. Modernism is a mental disease.

> Unfortunately, a few of my friends seem to think so too, and I would like to 
> lend a hand in redesigning it. 

We're just fine, thanks.

-- 
Dave Blanchard 

Re: Inquiry: Country of Origin for gfortran

[Dave Blanchard]

On Sun, 17 Jul 2022 14:18:40 EDT
Richard Kenner via Gcc  wrote:

> > Should this question be posed to the Linux distribution that NASA is using?
> 
> Yes, most likely.  But exactly how Free Software fits into the
> Buy America Act (what she's talking about) is less than clear.

If these bureaucratic parasites (but I repeat myself) don't want to use GCC, or 
Clang, then they can write their own compiler suite from scratch. Doubt that's 
going to happen, so this "investigation" is simply yet another frivilous waste 
of taxpayer dollars.

-- 
Dave Blanchard 

Re: Change in preprocessor behavior

[Dave Blanchard]

On Tue, 21 Jun 2022 09:28:00 +0200
Richard Biener  wrote:

> On Tue, Jun 21, 2022 at 2:34 AM Dave Blanchard  wrote:
> >
> > At some point between GCC 9 and GCC 12, the preprocessor started behaving 
> > differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I 
> > think) it would assume the user wanted to preprocess something and 
> > automatically launch in preprocessor mode. Now the behavior has changed and 
> > it just acts as the normal compiler. Can someone kindly point me to the 
> > patch or commit where this feature was changed, and the rationale for doing 
> > so? Thank you.
> 
> maybe you can be more specific as to how you invoke 'cpp'.  Did you
> build gcc yourself?  What
> is the 'cpp' you invoke (is it maybe a script or a symlink?)

Oops, it looks like my script had accidentally overwritten 'cpp' with a symlink 
to gcc. Fixed that and it's working now. Thanks.
 

Change in preprocessor behavior

[Dave Blanchard]

At some point between GCC 9 and GCC 12, the preprocessor started behaving 
differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I think) 
it would assume the user wanted to preprocess something and automatically 
launch in preprocessor mode. Now the behavior has changed and it just acts as 
the normal compiler. Can someone kindly point me to the patch or commit where 
this feature was changed, and the rationale for doing so? Thank you.

-- 
Dave Blanchard