public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: cpuid_eax damages registers (2.4.7pre7)
Date: 19 Jul 2001 11:36:49 -0700	[thread overview]
Message-ID: <9j79c1$5ap$1@cesium.transmeta.com> (raw)
In-Reply-To: <200107182204.f6IM4K001282@penguin.transmeta.com> <Pine.LNX.4.10.10107191113080.2341-100000@l>

Followup to:  <Pine.LNX.4.10.10107191113080.2341-100000@l>
By author:    Julian Anastasov <ja@ssi.bg>
In newsgroup: linux.dev.kernel
> 
> 	This patch works for me too (I checked all cpuid_XXX calls).
> After some thinking I produced another patch. The interesting part is
> that __volatile__ solves the problem. Patch appended. I see in other
> kernel files that volatile solves gcc bugs. The question is whether
> the volatile is needed only as a work-around or it is needed in this
> case particulary, i.e. where the output registers are not used and are
> optimized.
> 

It certainly shouldn't; obviously, the assembly code is clearly
declaring that it is outputting multiple things.  "volatile" on an
"asm" statement basically means "do this even if you don't need the
output values" (i.e. don't assume you're doing this just for the
computation), which is incorrect in this case (we *are* doing it just
for the output values, not for any side effects), but it is not really
surprising that it works around this bug.

The problem seems to be that gcc 2.91.66 thinks it can optimize away
half of an indivisible operation, which cannot be called anything but
a bug.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

  reply	other threads:[~2001-07-19 18:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 10:48 cpuid_eax damages registers (2.4.7pre7) Julian Anastasov
2001-07-18 15:10 ` Linus Torvalds
2001-07-18 17:08   ` Julian Anastasov
2001-07-18 17:21     ` Linus Torvalds
2001-07-18 20:43       ` Kai Germaschewski
2001-07-18 22:04       ` Linus Torvalds
2001-07-18 22:25         ` Kai Germaschewski
2001-07-19  8:23         ` Julian Anastasov
2001-07-19 18:36           ` H. Peter Anvin [this message]
2001-07-20  1:42         ` Julian Anastasov
2001-07-19 22:51           ` H. Peter Anvin
2001-07-20  2:01             ` Julian Anastasov
2001-07-19 23:02               ` H. Peter Anvin
2001-07-19 22:55           ` Linus Torvalds
2001-07-20  2:19             ` Julian Anastasov
2001-07-19 23:23               ` H. Peter Anvin
2001-07-19 23:24               ` Linus Torvalds
2001-07-22  0:00         ` Richard Henderson
2001-07-22  4:27           ` H. Peter Anvin
2001-07-21 23:45   ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
2001-07-18 20:30 Rick Hohensee
2001-07-19  5:15 ` Keith Owens

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='9j79c1$5ap$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.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