public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Waters <tanksherman27@gmail.com>
To: Dave Blanchard <dave@killthe.net>, gcc@gcc.gnu.org
Subject: Re: Another epic optimiser failure
Date: Tue, 30 May 2023 12:04:10 +0800	[thread overview]
Message-ID: <CAP2b4GNy_ZpA-XGFZXEngVa=UpMu=dVekYBeiKiKLn=8U8haww@mail.gmail.com> (raw)
In-Reply-To: <20230529140119.91d6f657a19b31f68d80467d@killthe.net>

[-- Attachment #1: Type: text/plain, Size: 5497 bytes --]

"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."

gdb -batch -ex 'set disassembly-flavor intel' -ex 'file /bin/ls' -ex
'disassemble method'


Being able to run a disassembler does not make you intelligent or hot shit ;)

"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."


Literally a few sentences later:


"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."


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


I will concede that gcc's documentation is pretty horrible, but that's
the exact reason I asked the gcc developers

and maintainers to list the options out here instead. Maybe you need
to brush up on your comprehension skills?

"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?"

I would, if he hadn't already been absolutely schooled in more recent
replies pointing out why gcc produces certain code sequences.

At least he had the maturity to apologize and make his leave once he
found out he had made several mistakes, unlike

a certain someone I'm speaking to right now. And the few corner cases
he mentions that are valid he didn't even bother

filing a bug report, but instead resorted to endlessly screaming on a
mailing list without letting anyone talk to

him properly.


"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?"

Again, you may want to look at the more recent code snippets posted
after the main argument got sidetracked, I don't

even have to do anything, hilariously enough.


It's also amazing how you managed to overpoliticize the rest of your
post after using that criticism against me

initially, how ironic.


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

You think you're one of the big dogs? Pffft, that's cute.


I have no interest in getting into a compiler pissing match past this
point, so be on your way. Go annoy other people instead with

your garbage.


On Tue, May 30, 2023 at 2:59 AM Dave Blanchard <dave@killthe.net> wrote:

> On Sun, 28 May 2023 15:50:41 +0800
> Julian Waters via Gcc <gcc@gcc.gnu.org> 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
>
>

  parent reply	other threads:[~2023-05-30  4:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28  7:50 Julian Waters
2023-05-29 19:01 ` Dave Blanchard
2023-05-29 23:44   ` Nicholas Vinson
2023-05-30  4:04   ` Julian Waters [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-05-27 21:04 Stefan Kanthak
2023-05-27 21:20 ` Jakub Jelinek
2023-05-27 21:28   ` Stefan Kanthak
2023-05-27 21:42     ` Andrew Pinski
2023-05-27 22:00       ` Stefan Kanthak
2023-05-27 22:46         ` Jonathan Wakely
2023-05-28  6:28 ` Nicholas Vinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP2b4GNy_ZpA-XGFZXEngVa=UpMu=dVekYBeiKiKLn=8U8haww@mail.gmail.com' \
    --to=tanksherman27@gmail.com \
    --cc=dave@killthe.net \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).