archive mirror
 help / color / mirror / Atom feed
From: Robert Love <>
Cc: David Woodhouse <>,
	Dinesh Gandhewar <>,
Subject: Re: volatile variable
Date: Mon, 11 Aug 2003 10:07:02 -0700	[thread overview]
Message-ID: <1060621622.684.84.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.53.0308110944350.17240@chaos>

On Mon, 2003-08-11 at 07:06, Richard B. Johnson wrote:

> The regparm(0) atttibute tells gcc that schedule() will get any/all
> of its parameters in registers. Since schedule() receives no parameters,
> that means that, as far as gcc is concerned, it cannot modify
> anything. That said, this may be a bug or it may have been added
> to work around some gcc bug. But, nevertheless, as the declaration
> stands, schedule() will never modify anything because somebody told
> gcc it won't.

No, regparm(0) means "zero parameters in registers", so everything is to
be found on the stack.

Also, the notion of functions as compiler barriers has nothing to do
with arguments. It has to do with global variables and pointers from

All functions are compile barriers, regardless of regparm() magic or the
number of parameters, with the exception of functions with the gcc
'pure' keyword.

Also, sleep_on() is deprecated and bad. Thanks for trolling today.

	Robert Love

  parent reply	other threads:[~2003-08-11 17:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-01 10:57 volatile variable Dinesh  Gandhewar
2003-08-01 11:38 ` Richard B. Johnson
2003-08-11 13:33   ` David Woodhouse
2003-08-11 14:06     ` Richard B. Johnson
2003-08-11 14:37       ` Jakub Jelinek
2003-08-11 14:38       ` David Woodhouse
2003-08-11 14:40       ` David Howells
2003-08-11 14:49       ` Mike Galbraith
2003-08-11 17:07       ` Robert Love [this message]
2003-08-02 14:52 Harm Verhagen

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1060621622.684.84.camel@localhost \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).