mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away
Date: Wed, 29 Nov 2006 17:04:28 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKOEGKAAAC.davids@webmaster.com> (raw)
In-Reply-To: <20061128.200453.104036587.davem@davemloft.net>


Ask yourself this question: Can an assignment to a non-volatile variable be
optimized out? Then ask yourself this question: Does casting away volatile
make it not volatile any more?

> The volatile'ness does not simply disappear the moment you
> assign the result to some local variable which is not volatile.

Yes, it does. That's what a cast does, it tells the compiler to, in all
respects, pretend that a variable is of a different type than it 'actually
is', such that it actually isn't anymore.

> Half of our drivers would break if this were true.

On the contrary, they'd break if it was true. If casting away volatile
didn't make it go away, then casting in volatile wouldn't have to make it
appear. A cast causes the compiler to act as if a variable really was the
type you cast it to. If you cast volatile away, that has the reverse of the
same affect casting to volatile has.

The 'readl' function should actually assign the value to a volatile
variable. Assignments to volatiles cannot be cast away, but casts can and
assignments to non-volatile variables can be optimized out.

DS



  parent reply	other threads:[~2006-11-30  1:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29  2:22 Keith Owens
2006-11-29  3:08 ` Nicholas Miell
2006-11-29  3:56   ` Keith Owens
2006-11-29  4:04     ` David Miller
2006-11-29  4:30       ` Keith Owens
2006-11-29  4:57         ` Nicholas Miell
2006-11-30  1:04       ` David Schwartz [this message]
2006-12-01  5:50         ` Kyle Moffett
2006-12-01 11:24           ` David Schwartz
2006-12-01 12:08             ` Kyle Moffett
2006-12-01 13:52               ` David Schwartz
2006-12-02  9:02                 ` Jan Engelhardt
2006-12-01 12:31             ` Andreas Schwab
2006-12-01 14:03               ` David Schwartz
2006-12-02 10:39                 ` Kyle Moffett
2006-12-03  4:29                   ` David Schwartz
2006-12-07 14:02                     ` Kyle Moffett
2006-12-08  4:22                       ` David Schwartz
2006-11-29  9:08     ` Jakub Jelinek
2006-11-29 20:14       ` Willy Tarreau
2006-12-01  5:05         ` Andrew Morton
2006-12-01  5:14           ` Keith Owens
2006-12-01  5:26             ` Willy Tarreau
2006-12-01  6:32               ` Keith Owens
2006-12-01  7:28                 ` Willy Tarreau
2006-12-01  7:57                   ` Jakub Jelinek

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=MDEHLPKNGKAHNMBLJOLKOEGKAAAC.davids@webmaster.com \
    --to=davids@webmaster.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

all inboxes | Powered by JetHome®