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
next parent 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).