linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Dinesh Gandhewar <dinesh_gandhewar@rediffmail.com>,
	mlist-linux-kernel@nntp-server.caltech.edu
Subject: Re: volatile variable
Date: Mon, 11 Aug 2003 10:37:01 -0400	[thread overview]
Message-ID: <20030811103701.M23055@devserv.devel.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0308110944350.17240@chaos>; from root@chaos.analogic.com on Mon, Aug 11, 2003 at 10:06:36AM -0400

On Mon, Aug 11, 2003 at 10:06:36AM -0400, Richard B. Johnson wrote:
> > If 'a' is a local variable that's true. If 'a' is a global as the
> > original poster explicitly declared, then the compiler must assume that
> > function calls (such as the one to schedule()) may modify it, and hence
> > may not optimise away the second and subsequent reads. Therefore, the
> > 'volatile' is not required.
> >
> 
> Again, this is incorrect. If you look at the declaration of schedule(),
> you will note "asmlinkage void schedule(void);". Now look up
> "asmlinkage"
> #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
> 
> 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.

You're wrong.  regparm(0) attribute tells GCC to pass all arguments
on the stack.  Also function argument passing (the only thing this
attribute controls) is completely orthogonal to whether a function may
modify global variables or not.
__attribute__((const)) functions are not allowed to write nor read
global memory, __attribute__((pure)) functions are not allowed to
write global memory and all other functions are allowed to both
read and write global memory.
As schedule is neither const nor pure, the compiler must assume
a global variable can be changed by schedule().

	Jakub

  reply	other threads:[~2003-08-11 14:37 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 [this message]
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
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:
  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=20030811103701.M23055@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=dinesh_gandhewar@rediffmail.com \
    --cc=dwmw2@infradead.org \
    --cc=mlist-linux-kernel@nntp-server.caltech.edu \
    --cc=root@chaos.analogic.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 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).