This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Fixed family and model detection for AMD CPU's
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Pawar, Amit" <Amit dot Pawar at amd dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 5 Nov 2015 12:49:50 +0000
- Subject: RE: [PATCH] Fixed family and model detection for AMD CPU's
- Authentication-results: sourceware.org; auth=none
- References: <SN1PR12MB0733CCE45E6F9B965769E21E97290 at SN1PR12MB0733 dot namprd12 dot prod dot outlook dot com> <563B276D dot 4010403 at redhat dot com> <SN1PR12MB07330D19C8A7EE7224462F2E97290 at SN1PR12MB0733 dot namprd12 dot prod dot outlook dot com>
On Thu, 5 Nov 2015, Pawar, Amit wrote:
> Hi Florian,
>
> This is a correctness patch where family and model detection was wrong.
That doesn't answer the question. What do you mean by "wrong"? What is
the background documentation that shows that the proposed change makes the
logic correct?
A proper explanation might be along the lines of "processor X reports
values A, B, C from CPUID; the existing code follows paths P and Q that
wrongly identify it as processor Y, but, as explained in document R (URL),
CPUID values on AMD processors should be interpreted as way S, meaning
that the logic should change in way T". And with a bug filed in Bugzilla
if this was user-visible (e.g. inappropriate function implementations
being selected in glibc because of the wrong choices).
--
Joseph S. Myers
joseph@codesourcery.com