From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Sandipan Das'" <sandipan@linux.vnet.ibm.com>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"paulus@samba.org" <paulus@samba.org>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"anton@samba.org" <anton@samba.org>
Subject: Re: [PATCH] powerpc/lib/sstep: Fix count leading zeros instructions
Date: Mon, 9 Oct 2017 09:20:53 -0500 [thread overview]
Message-ID: <20171009142053.GA4406@gate.crashing.org> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD008D92D@AcuExch.aculab.com>
On Mon, Oct 09, 2017 at 01:49:26PM +0000, David Laight wrote:
> From: Sandipan Das
> > Sent: 09 October 2017 12:07
> > According to the GCC documentation, the behaviour of __builtin_clz()
> > and __builtin_clzl() is undefined if the value of the input argument
> > is zero. Without handling this special case, these builtins have been
> > used for emulating the following instructions:
> > * Count Leading Zeros Word (cntlzw[.])
> > * Count Leading Zeros Doubleword (cntlzd[.])
> >
> > This fixes the emulated behaviour of these instructions by adding an
> > additional check for this special case.
>
> Presumably the result is undefined because the underlying cpu
> instruction is used - and it's return value is implementation defined.
It is undefined because the result is undefined, and the compiler
optimises based on that. The return value of the builtin is undefined,
not implementation defined.
The patch is correct.
Segher
next prev parent reply other threads:[~2017-10-09 15:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 11:07 [PATCH] powerpc/lib/sstep: Fix count leading zeros instructions Sandipan Das
2017-10-09 13:49 ` David Laight
2017-10-09 14:20 ` Segher Boessenkool [this message]
2017-10-09 14:43 ` David Laight
2017-10-09 14:47 ` naveen.n.rao
2017-10-09 15:24 ` David Laight
2017-10-09 14:47 ` Segher Boessenkool
2017-10-09 14:45 ` Naveen N. Rao
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=20171009142053.GA4406@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=David.Laight@ACULAB.COM \
--cc=anton@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=sandipan@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.