public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Koning <pkoning@xedia.com>
To: kenner@vlsi1.ultra.nyu.edu
Cc: gcc2@cygnus.com, egcs@cygnus.com
Subject: Re: New problems with gcc-2.8.0 based code - NOW FIXED!
Date: Tue, 30 Dec 1997 14:41:00 -0000	[thread overview]
Message-ID: <9712302117.AA21765@kona.> (raw)
In-Reply-To: <9712302109.AA01369@vlsi1.ultra.nyu.edu>

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 Paul> You mentioned the issue of an asm with inputs only that
 Paul> should still be treated as non-volatile.  I have a hard time
 Paul> conceiving of such a beast.  Can you show a real world
 Paul> example?

 Richard> Lighting some light. In such cases, you don't care whether
 Richard> or not it was moved around a few statements in the basic
 Richard> block.  Indeed, I'd say that *most* occurrences of asm would
 Richard> be in this category.

Hm.  I suppose that's possible, IF you're just trying to turn it on.
It doesn't work if you want it to blink, because the compiler can move
the on/off asm statement right around your blink delay unless you use
the volatile rule.

As for "most occurrences", I beg to differ.  I can't think of any
outputless asm statement I've ever written or seen anywhere that IS in
the "movable" category.  The example you gave is the first I've seen
that comes even close.

And in that example it would be perfectly harmless to use the rule as
documented (i.e., the asm is volatile).  Is there any example of an
input-only asm statement that *should not* be treated as volatile,
i.e., it actually hurts to make it non-movable automatically?  If such
a thing realistically exists it might make sense to invent a
"novolatile" keyword; without meaningful examples, the right answer is
to do what's documented.

Considering Joe Buck's analogy: would you consider it acceptable for a
compiler to permute the order of void function invocations unless
explicitly instructed not to do so?  I don't think so.  An asm
statement is also a function invocation, it just has a somewhat
different syntax.

	paul

       reply	other threads:[~1997-12-30 14:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9712302109.AA01369@vlsi1.ultra.nyu.edu>
1997-12-30 14:41 ` Paul Koning [this message]
1997-12-30 23:05   ` Richard Stallman
     [not found] <E0xnN2N-0005UN-00@paddington.london.uk.eu.org>
     [not found] ` <199801030231.DAA25241@mail.macqel.be>
1998-01-05 10:13   ` Paul Koning
     [not found] <9712302324.AA01798@vlsi1.ultra.nyu.edu>
1997-12-30 16:39 ` Paul Koning
     [not found] <9712301949.AA01218@vlsi1.ultra.nyu.edu>
1997-12-30 13:52 ` Paul Koning
1997-12-30 12:27   ` Linus Torvalds
     [not found] <199712302041.MAA25118@atrus.synopsys.com>
1997-12-30 13:45 ` Toon Moene
1997-12-10 23:09 cannot bootstrap neither gcc-2.8.0-971206 nor egcs-971207 on sparc-sun-sunos4.1.3 Manfred.Hollstein
1997-12-22 12:06 ` Jeffrey A Law
1997-12-26  8:11   ` New problems with gcc-2.8.0 based code [was: Re: cannot bootstrap neither gcc-2.8.0-971206 nor egcs-971207 on sparc-sun-sunos4.1.3 ] Manfred Hollstein
1997-12-27 12:13     ` New problems with gcc-2.8.0 based code - NOW FIXED! Manfred Hollstein
1997-12-28 23:23       ` Richard Stallman
1997-12-29  7:48         ` Jeffrey A Law
1997-12-29 11:17           ` Manfred Hollstein
1997-12-29 10:20             ` Jeffrey A Law
1997-12-30  8:57               ` Manfred Hollstein
1997-12-30  9:47                 ` Andi Kleen
1998-01-01 10:02                   ` Manfred Hollstein
1997-12-30 11:33                 ` Philip Blundell
1997-12-30 13:17                 ` Paul Koning
1997-12-29 11:08         ` Manfred Hollstein

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=9712302117.AA21765@kona. \
    --to=pkoning@xedia.com \
    --cc=egcs@cygnus.com \
    --cc=gcc2@cygnus.com \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).