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 16:39:00 -0000	[thread overview]
Message-ID: <9712302335.AA22623@kona.> (raw)
In-Reply-To: <9712302324.AA01798@vlsi1.ultra.nyu.edu>

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

 Paul> The alternatives are (a) to allow the compiler to do
 Paul> something it's not documented to do and that will cause
 Paul> subtle bugs, or (b) require the compiler to do something
 Paul> that it is documented to do, does no harm in any case, and
 Paul> avoids hairy bugs.  I think the right choice is pretty
 Paul> clear.

 Richard> First of all, there's no question that, at least in the
 Richard> short term, we have to make this change since there's code
 Richard> out there that depends on this behavior.

If I understand right, what you're saying is that the near-term change
should be to have input-only asms default to volatile.  Right?  Sounds
good.

 Richard> But the issue is what should the documented behavior *be*.
 Richard> In other words, how do we disambiguate the documentation.

Um, so are you saying then that you want the compiler to change to
match the documentation, and then later change both documentation and
compiler to behave once again the way they do in 2.7?

 Richard> There are *lots* of ways to write undefined C that can cause
 Richard> "subtle bugs" (things like "a[i++] * 2 + a[i]" are good
 Richard> examples of that).  We don't decide on the semantics of a
 Richard> language based on the fact that a programmer can use it
 Richard> improperly!

Actually, in many programming languages the likelihood of subtle bugs
IS a language design consideration.  Look at the Algol-68 report for
examples.  On the other hand, it's clear that C is an exception to
this.  But yes, if a feature has significant benefits, then the fact
that it can also create subtle bugs is usually not enough reason to
exclude it.

On the other hand, when considering a design decision where the issue
isn't forced by some standards committee, my inclination would be to
reduce the number of suble-bug-inducing features rather than
increasing it, ALL OTHER THINGS BEING EQUAL.  And no one has made an
argument so far that there is any BENEFIT to doing it the other way.
So, on one side of the balance there is a benefit (arguably small, but
a benefit nonetheless) and on the other side of the balance there is
nothing.  So the balance tips, doesn't it?

	paul

       reply	other threads:[~1997-12-30 16:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9712302324.AA01798@vlsi1.ultra.nyu.edu>
1997-12-30 16:39 ` Paul Koning [this message]
     [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] <9712302109.AA01369@vlsi1.ultra.nyu.edu>
1997-12-30 14:41 ` Paul Koning
1997-12-30 23:05   ` Richard Stallman
     [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=9712302335.AA22623@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).