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

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

[Julian Waters]

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

It's alright Gabriel, pay this intellectually challenged individual no
mind. It's clear that, unlike Stefan, who at the very least knows how to
disassemble native code and understands what the instruction sequences mean
(even though the way he goes about it is flat out wrong), this retard
doesn't know how the fuck compiler code emission works in the slightest.
I'd be surprised if our friend Dave here (from "killthe.net", VERY
professional Dave!) even knows what registers or the stack are. Hell Dave,
forget about something as advanced as a compiler for native chip
architectures, do you even know the basic design principles of a fucking
Interpreter? Should be easy for a "Big Dog" like you, shouldn't it? Hell,
I'll make it easy for you, you can ignore ultra low level Interpreters like
the one within the JVM (because there is no fucking way in hell someone
like you with IQ comparable to room temperature can ever grasp how such a
complex system works), how would a basic Interpreter even function? How
does simple interpreter dispatch work, hm? How does cpython (or PyPy) or
even one as simple as the Matz Ruby Interpreter operate? Can you answer
that Dave? Or have you deluded your braindead self into thinking that
you're one of the "Big Dogs" (Your own words) and are now punching way
above your league? Are you going to answer with the "Hurr durr they work by
translating source code to machine code on the fly" that outdated and flat
out wrong as shit text in computer science textbooks say? Pffft



Sorry for my outburst, to the rest of this list. I can no longer stay
silent and watch these little shits bully people who are too kind to fire
back with the same kind of venom in their words. They may be polite enough
to refrain from doing so, Dave, but rest assured, I am far from as kind as
they are when dealing with assholes. I'm all for constructive criticism to
help improve a product as a whole, but if any of Stefan's (or god forbid,
David's) mails are "constructive", then Donald Trump is the second fucking
incarnation of Jesus Christ himself returning to earth for the second coming

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

[Paul Smith]

On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote:
> Sorry for my outburst, to the rest of this list. I can no longer stay
> silent and watch these little shits bully people who are too kind to
> fire back with the same kind of venom in their words.

Many of us have had Dave in our killfiles for a long time already.  I
recommend you (and everyone else) do the same.  You won't miss out on
any information of any use to anyone: he apparently just enjoys making
other people angry.

I'm quite serious: it's so not worth the mental energy to even read his
messages, much less to reply to him.  Arguing with "people who are
wrong on the internet" can be cathartic but this is not arguing, it's
just stabbing yourself in the eye with a pencil.  Don't play.

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

[David Brown]

On 06/06/2023 14:53, Paul Smith wrote:
> On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote:
>> Sorry for my outburst, to the rest of this list. I can no longer stay
>> silent and watch these little shits bully people who are too kind to
>> fire back with the same kind of venom in their words.
> 
> Many of us have had Dave in our killfiles for a long time already.  I
> recommend you (and everyone else) do the same.  You won't miss out on
> any information of any use to anyone: he apparently just enjoys making
> other people angry.
> 
> I'm quite serious: it's so not worth the mental energy to even read his
> messages, much less to reply to him.  Arguing with "people who are
> wrong on the internet" can be cathartic but this is not arguing, it's
> just stabbing yourself in the eye with a pencil.  Don't play.
> 

If a poster is causing enough aggravation that a large number of people 
have killfiled him, is there a process for banning him from the list? 
That is surely a better solution than having many people individually 
killfiling him?  I would assume those with the power to blacklist 
addresses from the mailing list do not do so lightly, and that there is 
a procedure for it.

David

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

[David Edelsohn]

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

On Tue, Jun 6, 2023 at 11:38 AM David Brown via Gcc <gcc@gcc.gnu.org> wrote:

> On 06/06/2023 14:53, Paul Smith wrote:
> > On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote:
> >> Sorry for my outburst, to the rest of this list. I can no longer stay
> >> silent and watch these little shits bully people who are too kind to
> >> fire back with the same kind of venom in their words.
> >
> > Many of us have had Dave in our killfiles for a long time already.  I
> > recommend you (and everyone else) do the same.  You won't miss out on
> > any information of any use to anyone: he apparently just enjoys making
> > other people angry.
> >
> > I'm quite serious: it's so not worth the mental energy to even read his
> > messages, much less to reply to him.  Arguing with "people who are
> > wrong on the internet" can be cathartic but this is not arguing, it's
> > just stabbing yourself in the eye with a pencil.  Don't play.
> >
>
> If a poster is causing enough aggravation that a large number of people
> have killfiled him, is there a process for banning him from the list?
> That is surely a better solution than having many people individually
> killfiling him?  I would assume those with the power to blacklist
> addresses from the mailing list do not do so lightly, and that there is
> a procedure for it.
>

The GNU Toolchain leadership has blacklisted people in the past, but we
have used the power sparingly.

The behavior of the individual attracts attention, albeit negative, while
not effectively accomplishing what he purports to desire.  The recommended
solution is to ignore the poster instead of trying to encourage him to
communicate more effectively.

Thanks, David

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

[Arsen Arsenović]

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


David Edelsohn <dje.gcc@gmail.com> writes:

> The GNU Toolchain leadership has blacklisted people in the past, but we
> have used the power sparingly.
>
> The behavior of the individual attracts attention, albeit negative, while
> not effectively accomplishing what he purports to desire.  The recommended
> solution is to ignore the poster instead of trying to encourage him to
> communicate more effectively.

IMO, the sparing usage of this power on what are clearly purely abusive
participants can only drive away users and contributors.  It seems
reasonable to establish a process for dealing with incidents like this
(and appeals, of course), especially given their frecency.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

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

[Mark Wielaard]

Hi Arsen,

On Tue, Jun 06, 2023 at 08:43:05PM +0200, Arsen Arsenović via Gcc wrote:
> IMO, the sparing usage of this power on what are clearly purely abusive
> participants can only drive away users and contributors.  It seems
> reasonable to establish a process for dealing with incidents like this
> (and appeals, of course), especially given their frecency.

I completely agree. Having a clear code of conduct for participants on
this list and procedures for when people don't stop harassing others
would be really welcome.

Thanks,

Mark

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

[David Brown]

On 06/06/2023 02:09, Dave Blanchard wrote:
> 
> 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?
> 

You apparently appreciate Stefan's posts, but burst a blood vessel when 
reading anyone else's.  And Stefan has shown a total disregard for what 
anyone else writes.

Rather than everyone else having to killfile the pair of you, why don't 
you do everyone a favour and have your little rants with each other 
directly, and not on this list?

If either of you are remotely interested in improving gcc's 
optimisation, there are two things you must do:

1. Stop wasting the developers' time and driving them up the wall, so 
that they have more time to work on improving the tools.

2. Make the suggestions and requests for improvements through the proper 
channels - polite, factual and detailed bug reports.

This is not rocket science - it's basic human decency, and should not be 
difficult to understand.

David

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

[Jonathan Wakely]

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

On Tue, 6 Jun 2023, 01:07 Dave Blanchard, <dave@killthe.net> wrote:

> On Tue, 6 Jun 2023 01:59:42 +0200
> Gabriel Ravier <gabravier@gmail.com> 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!
>

Why are you still here then?

Other compilers are available.

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

Great, so there's no reason for you to follow the development of current
gcc.

Toddle off somewhere else.

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

[Paul Koning]

> On Jun 5, 2023, at 8:09 PM, Dave Blanchard <dave@killthe.net> wrote:
> 
> On Tue, 6 Jun 2023 01:59:42 +0200
> Gabriel Ravier <gabravier@gmail.com> 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? 

Done.  Since you have not shown any ability to have a civilized conversation, I will now use my email filter to be spared any further exposure.

	paul

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

[Gabriel Ravier]

On 6/6/23 02:09, Dave Blanchard wrote:
> On Tue, 6 Jun 2023 01:59:42 +0200
> Gabriel Ravier <gabravier@gmail.com> 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!
Well, evidently you have a completely different understanding of what 
the "important discussion" here is. I've simply been trying to respond 
to your emails in a manner I thought appropriate: I didn't think you 
were sending mails with the expectation that it is apparently 
unacceptable for me to respond to them, especially when they contain 
multiple explicit direct questions.
>
> 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.

I did not think Poe's law would become applicable to so many discussions 
on this mailing list, but here I am... I guess that leaves me with only 
one question: are you actually serious in your claim that this "much 
older version of GCC" will produce faster code than a recent one ?

>
> 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 <gabravier@gmail.com> 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?

[Gabriel Ravier]

On 6/6/23 00:23, Dave Blanchard wrote:
> On Mon, 5 Jun 2023 13:35:22 +0200
> Gabriel Ravier via Gcc <gcc@gcc.gnu.org> 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.

Well, while I don't agree with your opinion on the reasonableness of 
that response (while I'd say it would perhaps be ever so slightly over 
the top as of right now, I don't think it'd be that unreasonable, and 
Stefan's current behavior could easily escalate to a point where one 
could very reasonably want to avoid even a smidge of indirect 
interaction with him), my point is that such a response is a plausible 
one, and given you appear to assume bad faith on the part of the GCC 
developers, I can only assume you agree with me that such a reaction is 
indeed plausible, if for a different reason.

>
>> 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?
I don't think he doesn't care about optimizers. Certainly, looking at 
his website for just a few minutes makes it clear that he very much 
cares a lot about them. But his behavior is so puzzling as to make me 
question how it's possible to argue his case so badly, as to stretch my 
capacity to apply Hanlon's razor: indeed, a technically possible, if 
hopefully wrong conjecture, would be that he does care a lot about the 
optimizer, but simply hates GCC's optimizer so badly (for failing to 
optimize his code exactly how he wants it to be) that he doesn't even 
care about improving it and just wants to shout at the developers 
endlessly over it. This *should* be obviously stupid, but his current 
behavior on this list makes this possibility practically 
indistinguishable to me from one that assumes good faith (and seemingly 
cripplingly bad communication skills) and, as a result, I need to make a 
conscious effort to assume such good faith on his part.
>
>> Someone else might  instead think you're just a troll
> Not you, of course. No sir. You're smarter than that, right?
Well, either I'm spending my time trying to get someone to stop 
completely destroying any potential for them to actually be able to 
contribute to GCC's development, or am I indeed quite the fool and 
completely wasting my time for the enjoyment of someone who doesn't care 
at all. That's all I'm trying to say, I don't think assuming good faith 
magically makes your IQ go up.
>
>> 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
>
Wow, I'm actually impressed by how inflammatory you've managed to make 
this single sentence: it feels like you've managed to bottle up the very 
essence of flaming. Anyway, see above for what I meant by "waste the 
time of people like me", if you didn't understand what I meant by that.

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 <gcc@gcc.gnu.org> 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: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Julian Waters]

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

gcc -O0 -c -mabm -mbmi retard.c -o retard.o
           ^
           |
           |
           |

int code(unsigned long long number) {
    return (int) _tzcnt_u64(number);
}

objdump --disassemble-all retard.o

0000000000000000 <code>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 83 ec 10             sub    $0x10,%rsp
   8:   48 89 4d 10             mov    %rcx,0x10(%rbp)
   c:   48 8b 45 10             mov    0x10(%rbp),%rax
  10:   48 89 45 f8             mov    %rax,-0x8(%rbp)
  14:   31 c0                   xor    %eax,%eax
  16:   f3 48 0f bc 45 f8       tzcnt  -0x8(%rbp),%rax
 <---------------------
  1c:   48 83 c4 10             add    $0x10,%rsp
  20:   5d                      pop    %rbp

Moron.

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

[Gabriel Ravier]

On 6/5/23 12:17, Stefan Kanthak wrote:
> --- failure.c ---
> int _clz(unsigned long long argument) {
>      return __builtin_clzll(argument);
> }
>
> int _ctz(unsigned long long argument) {
>      return __builtin_ctzll(argument);
> }
> --- EOF ---
>
> GCC 13.1    -m32 -mabm -mbmi -mlzcnt -O3 failure.c
>
> <https://godbolt.org/z/MMf11hKch>
> _clz(unsigned long long):
>          mov     edx, DWORD PTR [esp+8]
>          xor     ecx, ecx
>          xor     eax, eax
>          lzcnt   eax, DWORD PTR [esp+4]
>          add     eax, 32
>          lzcnt   ecx, edx
>          test    edx, edx
>          cmovne  eax, ecx
>          ret
> _ctz(unsigned long long):
>          sub     esp, 20
>          push    DWORD PTR [esp+28]
>          push    DWORD PTR [esp+28]
>          call    __ctzdi2
>          add     esp, 28
>          ret
>
> OUCH: although EXPLICITLY enabled via -mabm (for AMD processors) and -mbmi
>        (for Intel processors), GCC generates slowmotion code calling __ctzdi2()
>        instead of TZCNT instructions available since 10 (in words: TEN) years.
>
>
> GCC 13.1    -m32 -march=i386 -O3 failure.c
>
> <https://godbolt.org/z/16ezfaexb>
> _clz(unsigned long long):
>          mov     edx, DWORD PTR [esp+4]
>          mov     eax, DWORD PTR [esp+8]
>          test    eax, eax
>          je      .L2
>          bsr     eax, eax
>          xor     eax, 31
>          ret
> .L2:
>          bsr     eax, edx
>          xor     eax, 31
>          lea     eax, [eax+32]
>          ret
> _ctz(unsigned long long):
>          sub     esp, 20
>          push    DWORD PTR [esp+28]
>          push    DWORD PTR [esp+28]
>          call    __ctzdi2
>          add     esp, 28
>          ret
>
> OUCH²: the BSF/BSR instructions were introduced 38 (in words: THIRTY-EIGHT)
>         years ago with the i386 processor, but GCC fails to know/use BSF --
>         a real shame!
>
> OUCH³: an optimising compiler would of course generate "JMP __ctzdi2" instead
>         of code fiddling with the stack!
>
> Stefan Kanthak
>

Hi,

While the optimization concerns your email raises appear to be genuine 
to some degree, I must admit to being quite clueless as to why, exactly, 
after at least 2 years of intermittently sending various seemingly quite 
incensed emails to this list, you appears not to have, at any point, 
questioned whether this method of action is in any way effective.

I myself have, too, made a hobby of investigating the capabilities of 
GCC's optimizer on various pieces of code, and trying to get it 
improved, by filing various appropriately formulated bugs in GCC's 
bugzilla whenever it seemed appropriate to do so (see e.g. 
https://gcc.gnu.org/PR94795, https://gcc.gnu.org/PR98957, 
https://gcc.gnu.org/PR102224 or https://gcc.gnu.org/PR104371 for what I 
believe to be pretty good examples of how to file such a bug).

I have not spent all this time sending various inflammatory emails to 
mailing lists not made for that purpose, and I am quite puzzled by the 
fact you appear to have concluded that doing so is appropriate. Should 
the page on GCC's website about the mailing lists perhaps contain a 
mention that the main mailing list is not made for spamming complaints 
about minor bugs ? I'd have figured it'd be self-evident, but evidently 
it seems this might perhaps be necessary...

Anyway, this leaves me with two more things I'd like to ask you about:

1. Why exactly are you so mad at GCC's optimizer and constantly belittle 
its capacities ? Did a GCC developer working on the optimizer destroy 
your hometown and salt the earth or something ? I also don't get why you 
put "optimizer" between quotes like that - is this supposed to imply 
calling GCC's optimizer as such is some insult to some hypothetical 
better optimizer ? (note: I say hypothetical because I haven't seen any 
optimizer that would be so much better than GCC's as to make it seem 
insultingly bad compared to it - Clang is comparable to GCC in its 
capacities but you also appear to hate it, given what I've seen 
elsewhere, and I'd expect other compilers like ICC and MSVC to be the 
ones that would be the butt of the joke here, given how poor they are 
compared to GCC and Clang...)

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. Arguably, to not be biased against them would encourage you 
to keep sending more emails, which people do not want as of now.


PS: I hope you understand that I'm being somewhat generous when assuming 
you genuinely want to get GCC's optimizer to improve, and are simply 
failing to work effectively towards this goal. Someone else might 
instead think you're just a troll that uses this as a pretext to send 
inflammatory emails everywhere and waste the time of people like me.

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

[Jonathan Wakely]

https://gcc.gnu.org/bugs/

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

[Stefan Kanthak]

--- failure.c ---
int _clz(unsigned long long argument) {
    return __builtin_clzll(argument);
}

int _ctz(unsigned long long argument) {
    return __builtin_ctzll(argument);
}
--- EOF ---

GCC 13.1    -m32 -mabm -mbmi -mlzcnt -O3 failure.c

<https://godbolt.org/z/MMf11hKch>
_clz(unsigned long long):
        mov     edx, DWORD PTR [esp+8]
        xor     ecx, ecx
        xor     eax, eax
        lzcnt   eax, DWORD PTR [esp+4]
        add     eax, 32
        lzcnt   ecx, edx
        test    edx, edx
        cmovne  eax, ecx
        ret
_ctz(unsigned long long):
        sub     esp, 20
        push    DWORD PTR [esp+28]
        push    DWORD PTR [esp+28]
        call    __ctzdi2
        add     esp, 28
        ret

OUCH: although EXPLICITLY enabled via -mabm (for AMD processors) and -mbmi
      (for Intel processors), GCC generates slowmotion code calling __ctzdi2()
      instead of TZCNT instructions available since 10 (in words: TEN) years.


GCC 13.1    -m32 -march=i386 -O3 failure.c

<https://godbolt.org/z/16ezfaexb>
_clz(unsigned long long):
        mov     edx, DWORD PTR [esp+4]
        mov     eax, DWORD PTR [esp+8]
        test    eax, eax
        je      .L2
        bsr     eax, eax
        xor     eax, 31
        ret
.L2:
        bsr     eax, edx
        xor     eax, 31
        lea     eax, [eax+32]
        ret
_ctz(unsigned long long):
        sub     esp, 20
        push    DWORD PTR [esp+28]
        push    DWORD PTR [esp+28]
        call    __ctzdi2
        add     esp, 28
        ret

OUCH²: the BSF/BSR instructions were introduced 38 (in words: THIRTY-EIGHT)
       years ago with the i386 processor, but GCC fails to know/use BSF --
       a real shame!

OUCH³: an optimising compiler would of course generate "JMP __ctzdi2" instead
       of code fiddling with the stack!

Stefan Kanthak