Re: type based aliasing again

Re: type based aliasing again

[Phil Edwards]

> If we use the term "illegal" to describe user code, it carries the
> implication that the users who wrote it are evildoers and ought to be
> punished.

I think we're treating this too seriously for our own good.

> That's why there is a GNU convention of describing code which
> doesn't follow the language rules as "invalid", not "illegal".

So it's not evil (illegal), it's just handicapped or elderly (invalid)?

Why not just follow the example of at least one ISO language standard and
call it "non-conforming"?  Since we're all supposed to be nonconformist
GNU rebels anyhow, this will be even less harsh/judgemental on the user,
and could even be construed as positive.  :-)


-- 
philip.edwards@{sn.wpafb,afrl}.af.mil
Targeting & Attack Radar                                  UFOs are real.
Air Force Research Labs                                   The Air Force
Senior Systems Administrator                              doesn't exist.

Re: type based aliasing again

[Phil Edwards]

> If we use the term "illegal" to describe user code, it carries the
> implication that the users who wrote it are evildoers and ought to be
> punished.

I think we're treating this too seriously for our own good.

> That's why there is a GNU convention of describing code which
> doesn't follow the language rules as "invalid", not "illegal".

So it's not evil (illegal), it's just handicapped or elderly (invalid)?

Why not just follow the example of at least one ISO language standard and
call it "non-conforming"?  Since we're all supposed to be nonconformist
GNU rebels anyhow, this will be even less harsh/judgemental on the user,
and could even be construed as positive.  :-)


-- 
philip.edwards@{sn.wpafb,afrl}.af.mil
Targeting & Attack Radar                                  UFOs are real.
Air Force Research Labs                                   The Air Force
Senior Systems Administrator                              doesn't exist.

Re: type based aliasing again

[John W. Stevens]

[Snippage abounds, mostly personal attacks, bald assertions and
 repetitions, but some other things may have been inadvertently
 snipped.]

> >> >I believe this is a false premise.  Standards change.
> >> 
> >> Not in this respect, apparently.
> >
> >As I understand it, we are talking about a change that moves a construct
> >from "undefined" to "incorrect".
> 
> No, read the standard, then come back and tell us what the difference
               ^^^^^^^^
This is, indeed, the point I am trying to make: there exists a body
of code that was written before what-ever-version-of the standard
you are refering to by the use of the word: standard.

> is between "undefined" and "incorrect" in the standard.

According to the second version of "The C Programming Language" (which
was based on the Draft ANSI C standard) casting pointers from one
type to another is neither incorrect, nor undefined, it was
"implementation dependent", with the warnings being related to
alignment problems.

> If the standard does not define the behavior of a construct, then
> the construct *is* undefined.

In the first version of "The C Programming Language", this appears
to be undefined.

> My impression is that's what
> was the case with K&R C.

That is my impression as well, though of course, this is difficult
to pinpoint precisely, due to the fact that the language of the first
version of this book was not written as a language standard.

> I assume that for the purposes of this
> discussion; else -traditional should imply -fno-alias-analysis.

I am not familiar with any of the discussion re: -traditional.  If
-traditional means: "K&R C", then perhaps this switch should imply
the use of -fno-alias-analysis, under the assumption that the
code being compiled under this flag probably will contain
undefined or implementation dependent code.

> Right, in the sense that you could not be sent to prison simply because
> your code performed that construct.  Samed for division by zero,
> square root of a negative number, dereferencing a NULL pointer, etc.

Excuse, but the two classes are not analogous.  Division by zero (etc.)
is a *mathematically* undefined operation, and on some processors
such an action constitutes a reason for raising a run time
exception.

The act of doing:

{
	auto	sockaddr		sockStructure;
	auto	sockaddr_in		*inetSockStructurePointer;

	/*	Get pointer to internet socket structure.	*/
	inetSockStructurePointer = (struct sockaddr_in *) &sockStructure;
}

is not the same class of "undefined" (it is not a mathematically
undefined operation).  It is, in short, a very common operation.

One that now seems to be inadvisable, at best.

> I don't recall K&R I ever using language like "defined as illegal",
> but, for all intents and purposes, that is *exactly* the same
> as "undefined", within the context of a manual describing a language
> like C.

I disagree with this statement.  And, in fact, both K and R wrote
code that violated the new standard.  There is a fair body of
work written by K&R still floating around out there, some of
which was released into the public domain, that will demonstrate this.

> >Excuse, but the point I'm making is: there isn't necesarily a bug
> >in *either* of them.  It doesn't have to be a yes/no, black/white,
> >binary kind of thing.
> 
> But, in this case, it is *exactly* that.  The user code is undefined
> according to ISO C.  Period.

"Undefined".  Thank you.  That was my point: it isn't a bug, it is
undefined.

The whole discussion really lies in just this: it is an inflamatory
term that assigns blame.  It's use, especially in a public forum
or in an exchange with the user community, is detrimental to both
your stated aims, and the good of the project (the GNU project)
as a whole.

> How many times must I, and others, say that before you'll a) believe
> us or b) read the ISO C standard for yourself?

I've read it.  I've reread the relevant portions.  Your interpretation
disagrees with mine.  This is not an issue of belief, it is an issue of
interpretation.

Incidentally, nobody but you has told me that this code constitutes
a "bug", and in fact, I've received some private email indicating
that some people agree with me: IOW, that this is not a bug in the users
program, or in GCC, it is a *mismatch* between tool and input.

IOW, when you write implementation dependent code, you are creating
a relationship between code and tool.  This relationship must be
taken into account if you choose to change the tools you use.

> >And where we differ is in your use of the term: "bug".  I wouldn't consider
> >either GCC, or your program, to be buggy.  The act of mixing
> >incompatible pieces is probably a mistake, though.
> 
> Though I've already corrected you several times,

Excuse, but you have yet to correct me.  In fact, above, you admit above
that this is not a bug, it is simply either undefined, or implementation
dependent.

> I'll also point
> out that when a mistake is the act of mixing Y and Z, and Z is a
> specification-conforming off-the-shelf part

Which GCC is not.

> while Y is fully under the
> control of the person doing the mixing (i.e. user code), then the
> mistake is on the part of the person who mixed the two, if not
> the person who created Y.

While your explanation breaks down on point one, I agree that the
mistake lies in the persons actions, not Y or Z.  But then again,
I've already said this multiple times.  I'm happy to see that
you finally understand this, and agree with me. ;->

> It is never on the part of those who created Z.

I never (*NEVER*, *NEVER*) said that it was.

*NEVER*.

You will not find one shred, segement or phrase that I wrote that
assigns blame to GCC for this.

What you will find is generalized support for what has been done,
except that I whole heartedly agree with the suggestion that warning
code be added, where reasonable and feasible, to let the user know
what GCC is thinking.

> >And I don't believe that anybody is actually advocating this.
> 
> Actually, yes, that's what has been advocated, repeatedly, by at
> least two or three people -- that the responsibility for making
> buggy code work is on GCC's shoulders in this case.

Again, that word . . . I have seen some mail that suggests
that backwards compatibility should be a high priority.  I've
never seen *any* mail that suggests that GCC should be responsible
for making buggy code work.

When I do:

	auto	char	*tp;
	auto	char	bf[32];

	strcpy(bf, tp);

I don't expect GCC to make this buggy code work.  I *appreciate* the
warnings I *can* get re: uninitialized variables.  But that is not
the same as saying you *SHOULD* give me such warnings.

I will go on record, though, as saying just that: if possible, feasible
and reasonable, such warnings should be given.

> Then don't throw them in -- teach them.

Well, yes, that is what I was advocating.  Was I being unclear?

> GCC is not a teaching compiler.

I disagree.  I don't think such strong classifications are
reasonable.  In fact, I know many situations where GCC is,
indeed, used in a teaching environment.

> >People that *have* to have this environment to learn should not,
> >at the very least, be allowed to play with anything that might
> >injure or kill others (learning not to point a loaded gun at
> >somebody should not be something you learn by trial and error).
> 
> GCC is not a loaded gun,

I did not say it was.  GCC is a compiler suite.  I was drawing an analogy.

Allow me to point out that mission critical software failures
can indeed cost lives.  I can, if you need me to, point you to
one of the more famous cases of a software bug killing people. . .

And C is definitely a language that allows, indeed, encourages people
to do things "outside the box".

> That should not be the responsibility of GCC,

I'm not saying that it should be the *responsibility* of GCC, I'm
saying that backwards compatibility, even if only for a limited period
of time, is a "good thing".

> But, we're now told, it *is* to be thought of as the responsibility
> of GCC.  And I'm told not to object to that anymore.

Actually, you were *requested*, quite politely, not to exagerate
so much.

You seem unable to view the situation in any thing other than
black-or-white, my-way-or-yours, right-or-wrong.

There is a compromise position that is superior to either extreme,
and it seems that RMS has hit on that compromise (or, at least,
come darn close to it).  No surprise there, as he has been doing
this a very long time.

Perhaps when you get some time, gain some distance, get some
perspective, you will see this.

Maybe not.

> Which is exactly what GCC provided in 2.95, but that's not good
> enough, apparently.

It is for me.  I don't let my code fall into an "unmaintained state".

I will still modify/fix/change the very first free software package
I ever released, though I freely admit that due to email address
changes and time, it is highly unlikely that some of my original
users can in fact get a hold of me . . . :-(

> Exactly.  And GCC will continue to be plagued by arguments over
> that line, which is fuzzy at best, and will be disagreed about among
> the hundreds of programmers discussing the issue at any one time.

Which is why RMS was seeking a compromise, not laying out a
dictate.

> There *is* a bright line available: ISO C, for example.  Too bad GCC
> chooses to ignore that,

This is an exageration.  GCC already is relatively ISO C compliant,
it does not ignore the standard.  Please try not to use such
absolute terms . . . especially since in doing so, you actually
damage your own cause.  If someone new to GCC were to read this,
they may well conclude that there is no benefit to writing ISO C
compliant code when their intention is to feed that code to GCC . . .
which as you can see, will cause further problems of the type
you seem to be trying to avoid.

> >Agreed.  But GCC extensions do not make the GCC transparent.  They
> >simply add interface.
> 
> If that's the case, they can be done without adding extensions -- just
> by adding interfaces, since the ISO C language has the concept of
> procedure (function) interfaces.

Excuse, but the extensions add capabilities not supported by the
C language.

The intention in using the terminology above was to indicate by a kind
of short hand that the implementation details of something like:

__builtin_apply

Are best kept secret by adding this capability, along with its
associated interface, to the language and compiler.

This allows for a clean separation between the responsibilities
of the compiler (which are to translate high level language
constructs into the relevant assembly language) and the
responsibilities of the program designer.

The addition of "asm" support to the compiler is a much bigger
"transparency issue" than the addition of extensions.

Machine dependencies can and should be hidden by the high
level language design.

> The number counts too.

The effect of number is very small (not zero, but very small).

The following bit of code doesn't suffer from the same degradation
curve as you expect in the "physical world":

#define	NUMBER_OF_ARRAY_ELEMENTS	100

{
	auto	int			i;
	auto	DemoStruct	*array[NUMBER_OF_ARRAY_ELEMENTS];

	for (i = 0; i < NUMBER_OF_ARRAY_ELEMENTS; i++)
		array[i] = calloc(1, sizeof( DemoStruct ));
}

This code doesn't become noticeably more
complex if you change the definition of NUMBER_OF_ARRAY_ELEMENTS to 1000.

Obviously, it becomes more complex when you add error handling and
an error handling control flow path . . . but that is, as I am sure
you will agree, independent of the number of objects, yes?
		
> If you depend on 2 billion transistors working
> correctly instead of 2 million, your risk of failure goes up on
> that basis alone.

Your analogy . . . isn't.  You're comparing hardware
manafacturing to software manafacturing.  The two are not so
totally separate that there is no relationship, but the instantiation
of two million instances of the same class does not increase the
complexity of a program in the same ratio as the manafacture
of circuit that uses two million transistors does.

In hardware manafacture, a piece of dirt could damage one of your
two million transistors, but in software design, this danger is much
reduced and is, in general, considered to be quite low (if not
negligible).

If it does become a problem, then you have a *HARDWARE* problem,
not a software problem (IOW, replace your damaged memory,
adjust your processor clock speed, put better fans in the
box, replace your hard drive, what have you).

> It doesn't matter if all of them are exactly the
> same, when assessing that particular dimension.

The problem with attempting to apply an understanding of physical
engineering to software engineering is that you may fail to question
some of your assumptions.

And while I am not saying you have a degree in engineering, it does
appear to be the case that you have failed to question some of your
assumptions.

> But, yes, generally, the more *distinct* components, the more of a
> problem you have as well, because understanding how they interact,
> or might interact, gets harder.  (Especially if some are out of
> spec, e.g. buggy C code.)

The more distinct components, the more code.  More code (as a
general rule) more complexity.

> >Agreed.  But GCC extensions are, indeed, published black-box behavioral
> >descriptions.
> 
> Not by my standards they aren't

They extensions are documented.  That documentation is freely available.
That documentation comes with every copy of GCC. The ISO C standard
does *NOT* come with every copy of GCC.

In some respects, the GCC extensions are more public, and better
"published" than the ISO C standard is, from the standpoint of
a GCC user. :-)

> >Disagree.  Instantiation with parameters does not increase the
> >transparency of the instantiated object.
> 
> You're ignoring the effect of such instantiation on the maintenance
                                                          ^^^^^^^^^^^
> requirements of the *code* that requires those parameters, and the
> ease with which bugs in that code can be assessed.

The discussion was re: transparency.  Not complexity.  And I do
not ignore it.  It is true that, by reducing functionality,
that you *can* reduce complexity.

And I am not ignoring maintenance costs.  Obviously, one way 
to reduce maintenance costs is to reduce functionality (thereby
reducing the amount of code, thereby reducing complexity).

The question then becomes one of "necesity" (or, if you prefer,
"design" or "responsibility"), not one of transparency or complexity.

If an interface-and-implementation is definable as "unnecesary"
you'd have a clear win by eliminating it.  But that definition
is not solely an engineering decision.

Which takes us out of the realm of pure engineering, and back to
the (superset) realm of group dynamics *plus*.  Which, incidentally,
seems to be the real failure here: you seem to view this decision
as one that should be made purely and solely from an engineering
standpoint, when in reality, this decision must be made
with in the context of a wider and much larger system.

> Witness this whole thread, which has been repeated several times in
> the past.  *All* because of bugs in user code.

I disagree.  The thread has been repeated several times due to a
failure in communications.  Some of the GCC maintainers have
been talking/thinking solely in an "engineering" mode, when in
reality, this kind of decision transcends mere engineering.

> *All* of which could
> have been avoided had the clarity of responsibility been understood
> by all parties in the first place.  The result would be that,
> *today*, there'd be *no* code widely deployed with this bug, because
> we'd have collectively devoted our resources to *finding* and *fixing*
> it, rather than *arguing* about just how we should *accommodate* it.

Your statement is in error.  In point of fact, what would have happened
is that an indeterminate set of users would have written GCC off as
a "bad show", and gone elsewhere.

While this prospect may not bother you, I submit to you that it should.

The words "feasible, reasonable and practical" are indeed fuzzy, but this
is an advantage, not a disadvantage, as it makes the system as a whole
more dynamic, more adaptive.

> Viewing the accommodating of a bug as equivalent to passing the number of
> lines for `tail' to display strikes me as rather unwise.

Probably because that is not what I was talking about.

> It's certainly
> not a view a true engineer would take of an entire system.

Please try to avoid jumping topics.  The topic was re: complexity
control, not "accomodating bugs".

As for "the view a true engineer would take", I submit to you that
this is a statment of belief: in short, this is not a statement
that a true engineer would make.

;-> ;-> ;-> ;-> 

An engineer stands at the juntion where math, science, politics, economics
and group dynamics collide.  Decisions must be made within the context
of the system as a whole, and not solely within the context of single,
small, sub system.

> That's a stunning statement, since it implies that even when the
> switch no longer has the effect necessary for the *system* to
> work, the component being given the switch cannot reject it so
> as to warn the designer, or the other component, that something
> is no longer working.

Yes.  Indeed.  You are aware that this is already common practice
in GNU systems, are you not?

I can within 30 seconds draw up documentation on three different
GNU programs that describe a switch as being "accepted for
compatibility reasons", but that is documented as doing nothing,
or as being unnecesary.

> It may be reasonable.  It *is* unnecessary, by definition: nobody
> *needs* GCC to compile code with this bug,

You are incorrect.  Consider the economic impact of being required
to change a body of code that is more than 1 million lines . . .

Then mulitply that by the total number of such bodies of code.

> since, as long as GCC
> compiles ISO-C-conforming code correctly (which *is* presumed to
> be necessary), any code believed to contain this bug can be
> fixed,

Have you ever managed a project?  Believe it or not, it is sometimes
cheaper to spend 10 million dollars over six years, than to get
exactly the same thing for three million dollars all at once.

   [ Accounting isn't black magic, it just some times looks like it! ]

> That's *exactly* what some people have suggested.

Again, I have not seen any mail on the list that I would interpret
in this fashion.

> Look, it *should* be this simple:

Another statement of belief?  I thought you were the proponent of
pure engineering thought?

> What *has* been happening is the maintainer tracks down the bug,
> sees it's the result of undefined behavior, but reports it as
> a bug to the GCC lists anyway, because "that's not the way GCC
> worked last week".

And this is a valid action on the part of the user.

It is equally valid for the GCC maintainers to take into account
all of the relevant factors, then make a decision as to what
response (ranging from: "you gotta fix your code", to "oops, sorry,
we'll fix GCC so it doesn't do that") they will give.

But the response given must arise from the philosophical basis
for the project: IOW, the GNU project has a philosophical basis
that should guide the decision making process.

Which was, in short, what RMS was doing.

> In other words, the whole discussion is about making GCC's internal
> processing more "open", on the assumption it already *is* "open".

I don't equate the above to making GCC "open".  In fact, changing
implementation dependent results from one version of the compile
to another does more to makes GCC more transparent than that of
a user requesting that the change *not* be made.

> Please go back and read the entire thread, as well as the ISO C
> standard from front to back, before responding to this email with
> further arguments against these basic points.

You would be well advised to go back and read more than just the current
version of the ISO C standard.  Start with K&R's original book, then 
read the various "draft" versions of the standard, then check the date
on which the "finished" version of the standard was released and
estimate in your head just how much code was written before the
"finished" version was released.

It may be worth the effort if you also attempt to estimate the *cost*
of changing that much code.

> >This is your opinion.  You are free to state it.  The GCC user (as by
> >now is abundantly clear) does not share your opinion on what "matters".
> 
> Of course not.

:-(

> To those GCC users, what matters is a free ride --

Again, an unfair characterization.

> >A compromise is in order.  A good engineer cares about what his
> >customers/users care about.
> 
> False.

I would be shocked by this, but at this point, I am simply
saddened by this response, not shocked.

> A good engineer cares about the correct results being obtained.

"Correct" . . . is a slippery term.  In some respects, that
is a characterization that could be applied to the user: he
just cares about getting correct results, and the new version
of GCC didn't give him correct results, so he is pissed off.

> Now, if you want to know who *does* care about what his customers/users
> care about -- that's called a "marketing person", or a "product manager".

If your engineers do not care about the customer, then your engineers
are a waste of money.  The only reason for having engineers, is
to meet the needs of the customer.

In short: a software craftsperson is analogous to a counter-person
working at MacDonalds . . . you are only useful so long as you
service your customer.

> Ask the engineers who worked on those dams in China.  What their
> customers/users -- the government -- cared about was saving money,
> etc.  The result?  The largest technological disaster, in terms of
> lives lost, in this century.

Again, physical engineering is not equivalent to software engineering.

Again, decisions must take into account all factors.  That includes,
but is *NOT* limited to, "engineering correctness".

Limiting a decision to "economic correctness" is just as counter-productive
as limiting a decision to "engineering correctness".  Both factors 
(and more!) must be taken into account, and given weight.

> Now, had they cared first and foremost about doing the *right* thing,

The "right thing" takes into account such factors as money.  It does
not depend solely on money, but it must take that into account.

> But if you look at every technological disaster this century, pretty
> much in every instance you can find a marketing type working in an
> engineering role, i.e. doing just what *you* say they should be doing --
> accounting first for what someone "wants", rather than what the
> realities of engineering *require*.

And there are many examples of failed companies due to the fact that
they had engineers in the marketing department who cared not a whit
about the customer.

Or, who worse yet, treated the marketing department as the enemy, instead
of as a partner, a valued and respected part of the organization.

And, again, *want* and *require* must be judged within the larger context.

There are *wants* that outway petty engineering "requirements", because
in the context of the larger picture, that *want* is a requirement,
while that "engineering requirement" is simply a difficulty that
can be worked around.

> That "one" therefore is incapable of distinguishing between the risks
> we all take by living and the specific risks introduced by tolerating
> incompetent design strategies.

Consider the fact that no system can be proven "correct".  Consider,
also, that most systems are built from compromises.   Consider the
effect that these compromises have on the system.

> Therefore, that "one" should be disallowed from working on *any* system
> of any import in our society.

That "one" pretty much describes the vast majority of the people who
control systems design and implementation.

Like it or not, compromises are a fact of life.  These compromises
may reduce the *engineering* correctness of a system, but they do
not invalidate that system.  They do, in general, make most systems
more failure prone than they (theoretically) need to be, but as that
theoretical basis is "unreal", it is not a valid point to argue from.

> >This assumption makes GCC a smaller, less complex component . . . at
> >the cost of making the *whole* system *MUCH* more complex.
> 
> False.

No, it's true.

This is so true, that it has become a working principle for engineers:
reusable design patterns.  The GCC extensions arise out of repeatedly
solving the same types of problems.  Eventually, this fact is recognized,
an analysis is done, and a generically applicable solution is constructed
and installed.

This reduces complexity enourmously.  Think: library (generic
implmentations of reusable design patterns).

__builin_apply is an extension that greatly reduces the complexity
of the system as a whole.

> In fact, the code GCC compiled would get *easier* to maintain
> because it'd conform *better* to the *one* widely known standard
> for the C language: ISO C.

You contradict yourself.  ;->

First you complain that nobody
reads or understands the ISO C standard, then you claim that it
is widely known.

> >This statement seems to be based on the false premise that adding
> >interface, makes an object more transparent (it does not).
> 
> Your statement *is* based on the false premise that adding
> an interface to cause one component to be more complicated just
> to accommodate another component being out of spec is in no
> way different than adding an interface for other, legitimate reasons.

Nope.  I recognize the difference, though I disagree with your
use of the phrase "legitimate".  Adding interface to *an* object
to accomodate a *set* of out-of-spec components is both legitimate,
and indeed, it reduces the complexity of the system as a whole.

Changing 200 lines in GCC to avoid changing 2 million lines of
application/OS source code may indeed constitute a legitimate change.

> If you can't distinguish between those cases, you'll *never* be
> able to prevent all sorts of new interfaces being added to
> component A to accommodate bugs in component B.

It can be prevented in exactly the way it has always been
prevented: through the group dynamic.  If a small number of people
want an accomodation, it will probably not occur.  If a large number
of people want an accomodation, it probably will (and should) occur.

> *That's* the whole
> point of my objection -- while, in any one instance, it might
> indeed seem "helpful" to do that, there's unlikely to be the
> backbone necessary to prevent that one instance from turning into
> a flood.

Your fears are ungrounded.  The group dynamic will (and HAS!)  prevent
this from occurring.

> (Go back and read the archives, especially Linus Torvald's posts of months
> ago, where he basically says, as he has said so often, "why not
> accommodate *my* needs, when you've accommodated X, Y, and Z?".

Excuse, but your paraphrase is not entirely accurate.  Linus argued
that the needs of Linux are symptomatic of a much larger body of code.

And yes, I've been following this list for quite some time.  I do
not need to go back to the archives: I was there, and read it as it
came in.

> You would, if you paid attention,
> quickly learn the lesson: never accommodate anyone's "needs", just
> write to the pertinent standards/specifications...or get into
> marketing.)

I pay attention.  And I do accomodate needs.  And I am not
a marketeer.

> Well, it could be said we already *had* the dialog vis-a-vis
> this construct: user says "I want to program in C"; GCC says
> "I compile ISO C to run pretty fast"; users says "great, I'll
> use it".

The only problem is: that is a mis-statement, as "C" is a moving
target.

The problem (as is almost always the case) is one of miscommunication:
and in most cases, the user isn't saying "I want to program in
pure, latest-available-ISO-C-standard-C", they are saying: I want
a compiler that generates correct code from my source, which turns
out to be "defacto standard C".

If it makes it any clearer, think of C, like every other language,
as a result of group consensus.  A standards document may say one
thing, but the group may say something else.  Which is why RMS
believes in paying attention to the standard, but not in being
slavishly bound to it.

> >The success of the GUI simply proves what has been known for a
> >very long time: dialog is better than monologue, and monologue
> >is better than no communications what-so-ever.
> 
> Tell that to blind users.  And I don't mean that to be flippant:
> having studied GUIs vs. CLIs, and the issues arising therefrom,
> I cannot possibly agree with your flat-out statement as used
> in this context.

The GUI is an *instance* of a user interface design pattern
based on the concept of dialog.  It isn't the *GRAPHICAL* part
of GUI that makes GUI's preferable for most people to CLI's, it
is the *STATIC* *DIALOG* part that is important.

Dialog based UI's do not need to be graphical (dialog does not
mean: GUI dialog box, it refers to a langauge based information
exchange). And in fact, my statement stands as correct: dialog
is always better than monologue, monologue is always better than
no communications what so ever.

A blind person may require that the dialog be audio, instead of
written, but the design pattern is still correct.

I've written handicapped accessible UI systems.  The dialog
UI design pattern is so basic, it can be found in nearly every
successful software system.

> The future will prove me right in
> this case as well: the warning will be assailed by many as inadequate,
> incorrect, etc.

Darn near every warning, error or notice has been assailed at one
time or another.

This does not mean that we should not have warnings, errors or
notices.  If a large body of users *DOES* complain, though, that
*DOES* indicate we need to fix/modify what they are complaining
about.

> Somewhere, somehow, responsibility for these bugs has to *stop*.
> The buck must stop somewhere.  In this case, since the bug is
> in user code, it does *not* stop with GCC.

Ok, I cannot resist doing what you do to me, so right back at ya:

<mirror>
I've corrected you multiple times.  When will you read the langauge
definitions and understand this?

It isn't a bug if it was 1) undefined or 2) implementation dependant.

It is a tool vs. input *MISMATCH* (re: philiphs head screw and
flat blade screw driver).
</mirror>

The responsiblity lies with the person mis-using a tool.  Surely
you've read those warnings about "this product not intended to be inhaled",
or some such?

Accomodating the knowledgeable user who is, unfortunately, caught
in the situation of being forced to use the new tool with old code
(because, after all, the GCC maintainers do not maintain old versions
of the compiler), is not only reasonable, it is a requirement.

> The job of a compiler is not to communicate: it is to *compile*.

The *PRIMARY* job of the compiler is to translate what the
user says, into something the machine can understand.  As with 
any translation from one language to another, the mapping isn't
one to one.  Misunderstandings can and will occur, therefore
the compiler *MUST* communicate what it is thinking to the user
so that the user can catch and fix these misunderstandings.

> But when you say the most *important* facet is to talk, you support
> those who choose to have their software talk, even when the result
> is the wrong thing (files lost, lives lost, whatever).

No, I don't support that.  The two do not have to be related.

In short, *BAD* use of dialog does not constitute a valid reason
for not using dialog.

It merely indicates that you should fix your program: its buggy! ;->

> >Warnings should be issued *even* *if* adding them increases internal
> >complexity of the object.
> 
> No.

Yes.  Increasing the complexity of a single object in order to
reduce the complexity of the entire system is good engineering
practice.

> I wasn't talking about an object with no interface.  I was talking
> about one that does what it is supposed to do, and no more.

Yes.  And part of what "it is supposed to do" is communicate with
the user.

> crash?

Certainly that would be a warning to the developer. . . but a very
poor communication technique, unless the crash (core dump, anyone?)
comes with information specifiying *WHY* the crash occurred.

> Print a message to stderr?

This may indeed be a valid response for certain kinds of programs.

What, you don't like logging?  You never use Unix, or you do, but
you never read the log files to check for intrusion *WARNINGS*
from your system? ;->

How do you keep your systems secure, then?

> Which one of these
> warnings the *caller* that it might not mean what it says?

But, in response, consider what you wrote: how can a module warn
that it's warnings may not valid?  How about this: "This input
may be invalid" . . . catch the word, "may" there.

To the user, this should imply that the compiler sees the construct
in question as ambiguous.

> False on all points.

Since it is this object, (the compiler) that defines the translation,
it is the compilers responsibility to communicate this information,
when appropriate, back to the user.

> It is *not* the responsibility of the *compiler*
> to define proper-and-appropriate.

"Implementation defined".

> To the extent the *product* of
> which it is a part does that, the knowledge can be communicated
> via documentation;

Making the system much, much more complex as putting this information
solely in the documentation, while the *enforcement* responsiblity
lies with the compiler, creates a huge and vastly complex relationship
between two objects.

You talk about complexity, then turn around and want to vastly
increase it.

Surely in your experience you've come across documentation that
disagrees with the actual code?

> via a tool that analyses code and spots problems
> (issuing warnings); or similar.

Which, again, vastly increases complexity.

You are talking about implementing two objects that have overlapping
responsibilities.

> What I'm actually suggesting is that cc1 should not produce diagnostics,
> that a separately maintained program should.

It's been tried.  It was abandoned as a bad design.

John S.

Re: type based aliasing again

[craig]

>[Snippage abounds, mostly personal attacks, bald assertions and
> repetitions, but some other things may have been inadvertently
> snipped.]

Unfortunately, this individual chose to post quotes from my *private*
email to him on this list, despite my *explicit* explanation, at
the top, that I was taking this off-list.

I'll no longer respond to, or otherwise deal, with this individual.

        tq vm, (burley)

Re: type based aliasing again

[David Edelsohn]

	I, for one, am glad that someone took the time to respond to your
fallacious reasoning.  You state a lot of things as fact which really are
your own opinion and interpretation.  I appreciate John's thoughtful
response. 

	I believe that GCC maintenance requires decisions to be made based
on more principles than technical standards alone.

David

Re: type based aliasing again

[David Edelsohn]

	I, for one, am glad that someone took the time to respond to your
fallacious reasoning.  You state a lot of things as fact which really are
your own opinion and interpretation.  I appreciate John's thoughtful
response. 

	I believe that GCC maintenance requires decisions to be made based
on more principles than technical standards alone.

David

Re: type based aliasing again

[John W. Stevens]

> >[Snippage abounds, mostly personal attacks, bald assertions and
> > repetitions, but some other things may have been inadvertently
> > snipped.]
> 
> Unfortunately, this individual chose to post quotes from my *private*
> email to him on this list, despite my *explicit* explanation, at
> the top, that I was taking this off-list.

I was the first to send private email.  You responded by posting
quotes from that email back to this list, with the statement:

"back to the list, where this belongs"

If my action pisses you off, perhaps you should not have done the
same to me, first.  After all, it gave me the impression that this
was not only Ok with you, but preferable.

John S.

Re: type based aliasing again

[craig]

This is in regarding to jsteven, who wrote:
>> >[Snippage abounds, mostly personal attacks, bald assertions and
>> > repetitions, but some other things may have been inadvertently
>> > snipped.]
>> 
>> Unfortunately, this individual chose to post quotes from my *private*
>> email to him on this list, despite my *explicit* explanation, at
>> the top, that I was taking this off-list.
>
>I was the first to send private email.  You responded by posting
>quotes from that email back to this list, with the statement:
>
>"back to the list, where this belongs"
>
>If my action pisses you off, perhaps you should not have done the
>same to me, first.  After all, it gave me the impression that this
>was not only Ok with you, but preferable.

I'm very sorry to still be posting to this list at this time, but
felt it appropriate to provide the rest of the snippets I'd edited
from the "private" email he sent to me earlier, to ensure that my
response didn't accidentally constitute taking him out of context,
edit away important qualifiers to set up strawmen, and so on.

Yes, I had forgotten he'd emailed me "in private" earlier in this
thread, but I'll note several things about that:

  1.  He didn't say anything at the top of the email indicating he
      *wanted* it kept private.  As a long-time GCC/g77 maintainer, I
      *often* get private emails that were clearly intended for some
      list.  Though one or two others here have resorted to indicating
      they'd forward such emails to pertinent lists in their .sigs,
      I hadn't yet decided to start doing that.  I don't recall ever
      being taken to task for forwarding private emails, or my
      responses quoting them, to the suitable list of which I was
      generally recognized as a contributing member (else I wouldn't
      have gotten that email from that person in the first place).

  2.  I don't believe I ridiculed any "views" of his constructed (in
      my email in response to his private email) by eliminating important
      text in that email.  If anyone disagrees, they are welcome to
      send me private email pointing out where and how I did that, at
      which point I'll look into it and decide whether to issue a
      specific apology.  (Make it public email to this list if you're
      convinced I did it intentionally and thus are uninterested in
      any response I might give explaining myself.)

  3.  When I posted that material back to the list, RMS hadn't yet
      written this to me (or, I hadn't seen it):

>Those thoughts are yours, not mine.  I am just asking you and others
>to stop arguing for a policy of harshness toward the user--to stop
>arguing against the very idea of trying to accommodate old undefined
>code.

      Among other things, this *later* convinced me to take further
      discussions -- especially over my earlier, long email to
      jstevens, which got into a lot of extra-GCC issues -- off-list.

      And there is evidence in jstevens' own email that he, too, had
      seen and been aware of this, where he apparently responded to
      my reference to RMS' statement(s):

>> But, we're now told, it *is* to be thought of as the responsibility
>> of GCC.  And I'm told not to object to that anymore.
>
>Actually, you were *requested*, quite politely, not to exagerate
>so much.

  4.  In the private email I *did* send to jstevens, I *explicitly*
      specified the following in the very first line:

>[I'm no longer discussing this on the list.]

      I don't see why that's so hard to understand.  A simple request
      for permission would have sufficed.

      Further, I don't understand how he could have been *sincere*
      in his desire to be helpful (in the sense GCC maintainers, like
      myself, are when we take private emails *to* the list) by not
      even commenting on, or *quoting*, that statement!  (I.e. that's
      the first time anyone *here* has seen that line.)

  5.  jstevens is not a maintainer of GCC (not listed in MAINTAINERS,
      for example).  Email going from a maintainer to a non-maintainer
      is not nearly as fairly interpreted as being "appropriate for
      the list" as email going in the other direction, as happened when
      jstevens sent his email to me.  After all, I couldn't have been
      reasonably interpreted to have been trying to change the direction
      of GCC by sending jstevens email, since he is *not* a maintainer --
      even aside from the fact that I'd explicitly said I wanted the
      email to not go back to the list!

      In short, I don't see why it was unfair for me to interpret his
      email to me as advocacy to me *as a GCC maintainer*.  If I'd
      kept my response private, we could have argued for awhile perhaps,
      but that would have denied others an opportunity to correct *me*,
      something quite likely given that I've definitely been in the
      minority in terms of my views (just as I was back in December
      vis-a-vis the 80-bit-spills issue -- so it's not a new role for me).

      But I also don't see why it was fair for him to assume any email
      I sent to him *explaining my views* as a GCC maintainer should
      automatically be assumed to be publicizable.

      That jstevens sees the two as equivalent, even if he was entirely
      ignorant of my longstanding role as one of GCC's maintainers, I
      find implausible, given the evidence in the emails itself, and his
      own culpability in editing them where he had opportunity to do so.

  6.  When I read jstevens' *public* response, I skimmed it, and quickly
      noticed that not only did he override my *explicit* decision to
      take this off-list, he'd apparently intentionally omitted some
      material I'd written that would have otherwise rendered his attacks
      on my so-called "views" (few of which, based on his rendering of
      them, I actually hold) unsupportable -- one in particular I can
      identify, along with another one so he could act as if another issue
      had never occurred to me.

      IMO, when someone takes a private discussion into public, he has
      a duty to fairly represent the private discussion, even if he
      disagrees with it.  As I said in point 2 above, I believe I made
      a sincere attempt to do so when I quoted his private email in
      my response to the list.

      I don't consider jsteven's corresponding effort to have been
      successful, and, given other aspects of this situation, question
      its sincerity, especially since his public email began with:

>[Snippage abounds, mostly personal attacks, bald assertions and
> repetitions, but some other things may have been inadvertently
> snipped.]

      In other words, he chose to *publish* my so-called "personal attacks,
      bald assertions and repetitions", despite my explicit statement
      that I was taking this discussion off-list.  If he had been so
      concerned about "personal attacks" of mine, why did he refer to
      them without *posting* them, except possibly to just trash my
      *public* reputation?

Finally, that a GCC Steering Committee member publically referred
to my email -- which he had *not* seen, nor has since asked to see --
as containing "fallacious reasoning" in his *thanking* of jstevens
for the behavior (which I describe above) strikes me as indicating
a terminal state of disrespect -- quite literally the last, though
huge, straw -- among some members of that Committee towards people who
have done their best (even when, in my case, it just wasn't good
enough) to make GCC (e.g. g77) a good product.  Given my other
commitments, that state of affairs strongly suggests to me that
this should be the *very* last post I make to this list.

Below are the snippets I've found that I removed from jsteven's
private email, to provide some additional context to my earlier
posting of a public response to his email sent in private.  Note
that any mistakes in this effort are mine, since I used Emacs
compare-windows to produce this and skip over my own commentary,
which is not an error-free approach.  I welcome anyone with the patience
and concern over my behavior to carefully examine my response to his
email and look for instances where my response (which I do not include
here, for brevity, and since it's in the archives) suggested I'd
intentionally removed his material just to make a point at his expense.

Also, if jstevens wishes to do the same with my earlier private email
(i.e. send the results of a similar effort to this list and welcome
comments), I hereby give him permission to do so.  If he doesn't do so
soon, I reserve my right to keep my own email to him private until such
time as I choose to make it public or share it with other individuals.

(Note: I'm still not discussing the original issues on this list anymore.
This email only serves to set the email-related record straight, not to
dredge up what has been deemed -- effectively by RMS, and then explicitly
by myself when it comes to my own opinions -- an off-topic discussion.)


Referring to jstevens' email <199909161750.LAA12073@basho.fc.hp.com>,
sent to me alone, which I only partially quoted in my public follow-up:

After:
>if you are unwilling to set the proper switch".

Came:
>IMO, that is a valid and reasonable response.  And I am an avid
>GNU/Linux fan, by the way.

After:
>gentle reminder of "traditional GCC mailing list" nomenclature.

Came:
>> >If we can warn the user by writing a reasonable amount of code then
>> >it seems to be the "nice" thing to do. Even if we can't catch all
>> >occurances (as is mentioned earlier in this thread), the ones we can catch
>> >may be quite a help to the user. 
>> 
>> I agree with that.
>
>Sounds good to me, too.  "Reasonable" being a decision left up to the
>GCC maintainers, of course.
>
>> If you, as a programmer, wish the behavior of your *program* to not
>> change, you can, as I said, simply designate a *particular* compiler
>> and version combination to use (for a particular platform, say).
>
>Right.  Kind of what I said: the users code is not incorrect, the
>action of mixing old code with a new compiler, however, may very
>well be incorrect.
>
>[ Neither the Philips head screw driver, nor the flat head screw
>  are incorrect.  It's the idiot who picked up *that* screw
>  driver to use on *that* screw that needs lessons.
>]

After:
>conforms to, right?

Came:
><IMHO>

After:
>conformance, first, of course.

Came:
></IMHO>

After:
>the compiler . . . ?

Came:
>> That's the problem with this whole notion that it is up to GCC to serve
>> as a sort of free-software installation tool.  It is the *programmer*,
>> not the installer, that needs to see the warnings.
>
>Right.  From this, I'm guessing that earlier you did mean that the user
>is not the user of the compiler, but instead the user of the program
>compiled by the compiler.
>
>If so, then I agree.  The programmer should take reasonable steps
>to generate warnings and errors (turn on warning switches, etc.),
>and then actually read 'em and do something about them.
>
>> Still, since C is not exactly a well-designed language, it is not
>> easy to write static-code-checkers (a la the lint-like facility of
>> GCC) to find all the problems typically committed by programmers.

After:
>C requires a huge amount of discipline to use correctly, and well.

Came:
>> >  It is unfortuante that it is immpossile to spew a warning on every
>> >instance of the alias problem, but I think it is necessary to provide a
>> >warning when we can do so with a minimum of effort.
>> 
>> I think everyone agrees to that.

After:
>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

Came:
>therefore, code that now breaks, was correct within the context of
>prior standards and practices, so therefore, GCC should warn
>the programmer that his once-correct code is invalid when compiled
>with this particular compiler.
>
>If the programmer chooses to ignore such warnings. . . well, tough!
>
>> What is not widely appreciated or understood is that this warning
>> *probably* will, itself, "change" across versions/releases of GCC,
>> and that programmers and users will be as upset about those changes
>> in *this* case as in the case of alias analysis becoming the default.

After:
>possible to warn me about it.

Came:
>> Am I wrong?
>
>I agree with you, with the one caveat re: "broken/buggy/incorrect"
>versus "incorrect to compile with this compiler when using default
>settings".
>
>> Well, after *tons* of exactly correct pointing out of
>> the issues, correcting *many* people on this list, as done by people
>> such as myself and Mark Mitchell, can anyone point to a *single*
>> example of anyone admitting they had been wrong and now understood
>> that they should not expect a compiler to never change the behavior
>> of their program, especially if it invokes undefined behavior according
>> to the pertinent language standard?
>
>The mental mistake here is: "the pertinent language standard".  There
>have been many "standards" (some defacto, some formal).
>
>WHICH STANDARD?

After:
>*that* code with *this* compiler, you'd be able to resolve this.

Came:
>The remaining complaints would be from people who believe that
>standards should never change.  Those people should be ignored.
>
>In response to your question, however: No, my mind hasn't changed,
>but that is because, in general, I agreed with you in the first
>place: New compilers that conform to new standards will require
>source code changes, if that source code was written to a different
>standard.

After:
>a "minefield"?

Came:
>> But anyone who thinks GCC developers can avoid this whole problem
>> (of huge amounts of argument about how GCC is "breaking programs")
>> by making it warn about this construct is, frankly, deluding themselves.
>
>The new GCC is, in fact, breaking programs when applied to programs
>that are written to a different standard than the one the new GCC
>conforms too.
>
>The fault, however, lies with the programmer who feeds that code
>to this GCC, not in GCC, or in the source code.
>
>Fair enough?

After:
>such errors and issuing warnings is not feasible).

Came:
>> Some people think GCC is a hand-holding catch-all for installing
>> free software from source, regardless of the correctness of that
>> source code (as long as it might have seemed to work on some
>> old version of some C compiler somewhere), or some approximation
>> thereof.
>
>I agree, this is a mis-conception.
>
>But I do believe in errors, warnings, etc.
>
>> That's why they think that GCC is now breaking programs by
>> defaulting to employing its alias analysis.
>
>As above, GCC is not to blame, unless GCC issues no warnings
>when it would be feasible and possible to issue such warnings.
>
>If it isn't feasible/possible, then: to bad (the standard probably
>should be modified, though).  In that case, however, a large, well
>written body of documentation should be produced and then distributed
>with the compiler that describes the situtation.
>
>You say: "I don't read the docs!"?
>
>To bad for you, then.
>
>John S.
>
>[ "I don't believe any of my wants or desires are unreasonable!"
>
>  "A true sign of a distrubed mind, that."
>
>  Overheard at the bar, at a Java conference.
>]

        tq vm, (burley)

Re: type based aliasing again

[craig]

This is in regarding to jsteven, who wrote:
>> >[Snippage abounds, mostly personal attacks, bald assertions and
>> > repetitions, but some other things may have been inadvertently
>> > snipped.]
>> 
>> Unfortunately, this individual chose to post quotes from my *private*
>> email to him on this list, despite my *explicit* explanation, at
>> the top, that I was taking this off-list.
>
>I was the first to send private email.  You responded by posting
>quotes from that email back to this list, with the statement:
>
>"back to the list, where this belongs"
>
>If my action pisses you off, perhaps you should not have done the
>same to me, first.  After all, it gave me the impression that this
>was not only Ok with you, but preferable.

I'm very sorry to still be posting to this list at this time, but
felt it appropriate to provide the rest of the snippets I'd edited
from the "private" email he sent to me earlier, to ensure that my
response didn't accidentally constitute taking him out of context,
edit away important qualifiers to set up strawmen, and so on.

Yes, I had forgotten he'd emailed me "in private" earlier in this
thread, but I'll note several things about that:

  1.  He didn't say anything at the top of the email indicating he
      *wanted* it kept private.  As a long-time GCC/g77 maintainer, I
      *often* get private emails that were clearly intended for some
      list.  Though one or two others here have resorted to indicating
      they'd forward such emails to pertinent lists in their .sigs,
      I hadn't yet decided to start doing that.  I don't recall ever
      being taken to task for forwarding private emails, or my
      responses quoting them, to the suitable list of which I was
      generally recognized as a contributing member (else I wouldn't
      have gotten that email from that person in the first place).

  2.  I don't believe I ridiculed any "views" of his constructed (in
      my email in response to his private email) by eliminating important
      text in that email.  If anyone disagrees, they are welcome to
      send me private email pointing out where and how I did that, at
      which point I'll look into it and decide whether to issue a
      specific apology.  (Make it public email to this list if you're
      convinced I did it intentionally and thus are uninterested in
      any response I might give explaining myself.)

  3.  When I posted that material back to the list, RMS hadn't yet
      written this to me (or, I hadn't seen it):

>Those thoughts are yours, not mine.  I am just asking you and others
>to stop arguing for a policy of harshness toward the user--to stop
>arguing against the very idea of trying to accommodate old undefined
>code.

      Among other things, this *later* convinced me to take further
      discussions -- especially over my earlier, long email to
      jstevens, which got into a lot of extra-GCC issues -- off-list.

      And there is evidence in jstevens' own email that he, too, had
      seen and been aware of this, where he apparently responded to
      my reference to RMS' statement(s):

>> But, we're now told, it *is* to be thought of as the responsibility
>> of GCC.  And I'm told not to object to that anymore.
>
>Actually, you were *requested*, quite politely, not to exagerate
>so much.

  4.  In the private email I *did* send to jstevens, I *explicitly*
      specified the following in the very first line:

>[I'm no longer discussing this on the list.]

      I don't see why that's so hard to understand.  A simple request
      for permission would have sufficed.

      Further, I don't understand how he could have been *sincere*
      in his desire to be helpful (in the sense GCC maintainers, like
      myself, are when we take private emails *to* the list) by not
      even commenting on, or *quoting*, that statement!  (I.e. that's
      the first time anyone *here* has seen that line.)

  5.  jstevens is not a maintainer of GCC (not listed in MAINTAINERS,
      for example).  Email going from a maintainer to a non-maintainer
      is not nearly as fairly interpreted as being "appropriate for
      the list" as email going in the other direction, as happened when
      jstevens sent his email to me.  After all, I couldn't have been
      reasonably interpreted to have been trying to change the direction
      of GCC by sending jstevens email, since he is *not* a maintainer --
      even aside from the fact that I'd explicitly said I wanted the
      email to not go back to the list!

      In short, I don't see why it was unfair for me to interpret his
      email to me as advocacy to me *as a GCC maintainer*.  If I'd
      kept my response private, we could have argued for awhile perhaps,
      but that would have denied others an opportunity to correct *me*,
      something quite likely given that I've definitely been in the
      minority in terms of my views (just as I was back in December
      vis-a-vis the 80-bit-spills issue -- so it's not a new role for me).

      But I also don't see why it was fair for him to assume any email
      I sent to him *explaining my views* as a GCC maintainer should
      automatically be assumed to be publicizable.

      That jstevens sees the two as equivalent, even if he was entirely
      ignorant of my longstanding role as one of GCC's maintainers, I
      find implausible, given the evidence in the emails itself, and his
      own culpability in editing them where he had opportunity to do so.

  6.  When I read jstevens' *public* response, I skimmed it, and quickly
      noticed that not only did he override my *explicit* decision to
      take this off-list, he'd apparently intentionally omitted some
      material I'd written that would have otherwise rendered his attacks
      on my so-called "views" (few of which, based on his rendering of
      them, I actually hold) unsupportable -- one in particular I can
      identify, along with another one so he could act as if another issue
      had never occurred to me.

      IMO, when someone takes a private discussion into public, he has
      a duty to fairly represent the private discussion, even if he
      disagrees with it.  As I said in point 2 above, I believe I made
      a sincere attempt to do so when I quoted his private email in
      my response to the list.

      I don't consider jsteven's corresponding effort to have been
      successful, and, given other aspects of this situation, question
      its sincerity, especially since his public email began with:

>[Snippage abounds, mostly personal attacks, bald assertions and
> repetitions, but some other things may have been inadvertently
> snipped.]

      In other words, he chose to *publish* my so-called "personal attacks,
      bald assertions and repetitions", despite my explicit statement
      that I was taking this discussion off-list.  If he had been so
      concerned about "personal attacks" of mine, why did he refer to
      them without *posting* them, except possibly to just trash my
      *public* reputation?

Finally, that a GCC Steering Committee member publically referred
to my email -- which he had *not* seen, nor has since asked to see --
as containing "fallacious reasoning" in his *thanking* of jstevens
for the behavior (which I describe above) strikes me as indicating
a terminal state of disrespect -- quite literally the last, though
huge, straw -- among some members of that Committee towards people who
have done their best (even when, in my case, it just wasn't good
enough) to make GCC (e.g. g77) a good product.  Given my other
commitments, that state of affairs strongly suggests to me that
this should be the *very* last post I make to this list.

Below are the snippets I've found that I removed from jsteven's
private email, to provide some additional context to my earlier
posting of a public response to his email sent in private.  Note
that any mistakes in this effort are mine, since I used Emacs
compare-windows to produce this and skip over my own commentary,
which is not an error-free approach.  I welcome anyone with the patience
and concern over my behavior to carefully examine my response to his
email and look for instances where my response (which I do not include
here, for brevity, and since it's in the archives) suggested I'd
intentionally removed his material just to make a point at his expense.

Also, if jstevens wishes to do the same with my earlier private email
(i.e. send the results of a similar effort to this list and welcome
comments), I hereby give him permission to do so.  If he doesn't do so
soon, I reserve my right to keep my own email to him private until such
time as I choose to make it public or share it with other individuals.

(Note: I'm still not discussing the original issues on this list anymore.
This email only serves to set the email-related record straight, not to
dredge up what has been deemed -- effectively by RMS, and then explicitly
by myself when it comes to my own opinions -- an off-topic discussion.)


Referring to jstevens' email <199909161750.LAA12073@basho.fc.hp.com>,
sent to me alone, which I only partially quoted in my public follow-up:

After:
>if you are unwilling to set the proper switch".

Came:
>IMO, that is a valid and reasonable response.  And I am an avid
>GNU/Linux fan, by the way.

After:
>gentle reminder of "traditional GCC mailing list" nomenclature.

Came:
>> >If we can warn the user by writing a reasonable amount of code then
>> >it seems to be the "nice" thing to do. Even if we can't catch all
>> >occurances (as is mentioned earlier in this thread), the ones we can catch
>> >may be quite a help to the user. 
>> 
>> I agree with that.
>
>Sounds good to me, too.  "Reasonable" being a decision left up to the
>GCC maintainers, of course.
>
>> If you, as a programmer, wish the behavior of your *program* to not
>> change, you can, as I said, simply designate a *particular* compiler
>> and version combination to use (for a particular platform, say).
>
>Right.  Kind of what I said: the users code is not incorrect, the
>action of mixing old code with a new compiler, however, may very
>well be incorrect.
>
>[ Neither the Philips head screw driver, nor the flat head screw
>  are incorrect.  It's the idiot who picked up *that* screw
>  driver to use on *that* screw that needs lessons.
>]

After:
>conforms to, right?

Came:
><IMHO>

After:
>conformance, first, of course.

Came:
></IMHO>

After:
>the compiler . . . ?

Came:
>> That's the problem with this whole notion that it is up to GCC to serve
>> as a sort of free-software installation tool.  It is the *programmer*,
>> not the installer, that needs to see the warnings.
>
>Right.  From this, I'm guessing that earlier you did mean that the user
>is not the user of the compiler, but instead the user of the program
>compiled by the compiler.
>
>If so, then I agree.  The programmer should take reasonable steps
>to generate warnings and errors (turn on warning switches, etc.),
>and then actually read 'em and do something about them.
>
>> Still, since C is not exactly a well-designed language, it is not
>> easy to write static-code-checkers (a la the lint-like facility of
>> GCC) to find all the problems typically committed by programmers.

After:
>C requires a huge amount of discipline to use correctly, and well.

Came:
>> >  It is unfortuante that it is immpossile to spew a warning on every
>> >instance of the alias problem, but I think it is necessary to provide a
>> >warning when we can do so with a minimum of effort.
>> 
>> I think everyone agrees to that.

After:
>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

Came:
>therefore, code that now breaks, was correct within the context of
>prior standards and practices, so therefore, GCC should warn
>the programmer that his once-correct code is invalid when compiled
>with this particular compiler.
>
>If the programmer chooses to ignore such warnings. . . well, tough!
>
>> What is not widely appreciated or understood is that this warning
>> *probably* will, itself, "change" across versions/releases of GCC,
>> and that programmers and users will be as upset about those changes
>> in *this* case as in the case of alias analysis becoming the default.

After:
>possible to warn me about it.

Came:
>> Am I wrong?
>
>I agree with you, with the one caveat re: "broken/buggy/incorrect"
>versus "incorrect to compile with this compiler when using default
>settings".
>
>> Well, after *tons* of exactly correct pointing out of
>> the issues, correcting *many* people on this list, as done by people
>> such as myself and Mark Mitchell, can anyone point to a *single*
>> example of anyone admitting they had been wrong and now understood
>> that they should not expect a compiler to never change the behavior
>> of their program, especially if it invokes undefined behavior according
>> to the pertinent language standard?
>
>The mental mistake here is: "the pertinent language standard".  There
>have been many "standards" (some defacto, some formal).
>
>WHICH STANDARD?

After:
>*that* code with *this* compiler, you'd be able to resolve this.

Came:
>The remaining complaints would be from people who believe that
>standards should never change.  Those people should be ignored.
>
>In response to your question, however: No, my mind hasn't changed,
>but that is because, in general, I agreed with you in the first
>place: New compilers that conform to new standards will require
>source code changes, if that source code was written to a different
>standard.

After:
>a "minefield"?

Came:
>> But anyone who thinks GCC developers can avoid this whole problem
>> (of huge amounts of argument about how GCC is "breaking programs")
>> by making it warn about this construct is, frankly, deluding themselves.
>
>The new GCC is, in fact, breaking programs when applied to programs
>that are written to a different standard than the one the new GCC
>conforms too.
>
>The fault, however, lies with the programmer who feeds that code
>to this GCC, not in GCC, or in the source code.
>
>Fair enough?

After:
>such errors and issuing warnings is not feasible).

Came:
>> Some people think GCC is a hand-holding catch-all for installing
>> free software from source, regardless of the correctness of that
>> source code (as long as it might have seemed to work on some
>> old version of some C compiler somewhere), or some approximation
>> thereof.
>
>I agree, this is a mis-conception.
>
>But I do believe in errors, warnings, etc.
>
>> That's why they think that GCC is now breaking programs by
>> defaulting to employing its alias analysis.
>
>As above, GCC is not to blame, unless GCC issues no warnings
>when it would be feasible and possible to issue such warnings.
>
>If it isn't feasible/possible, then: to bad (the standard probably
>should be modified, though).  In that case, however, a large, well
>written body of documentation should be produced and then distributed
>with the compiler that describes the situtation.
>
>You say: "I don't read the docs!"?
>
>To bad for you, then.
>
>John S.
>
>[ "I don't believe any of my wants or desires are unreasonable!"
>
>  "A true sign of a distrubed mind, that."
>
>  Overheard at the bar, at a Java conference.
>]

        tq vm, (burley)

Re: type based aliasing again

[John W. Stevens]

> >[Snippage abounds, mostly personal attacks, bald assertions and
> > repetitions, but some other things may have been inadvertently
> > snipped.]
> 
> Unfortunately, this individual chose to post quotes from my *private*
> email to him on this list, despite my *explicit* explanation, at
> the top, that I was taking this off-list.

I was the first to send private email.  You responded by posting
quotes from that email back to this list, with the statement:

"back to the list, where this belongs"

If my action pisses you off, perhaps you should not have done the
same to me, first.  After all, it gave me the impression that this
was not only Ok with you, but preferable.

John S.

Re: type based aliasing again

[craig]

>[Snippage abounds, mostly personal attacks, bald assertions and
> repetitions, but some other things may have been inadvertently
> snipped.]

Unfortunately, this individual chose to post quotes from my *private*
email to him on this list, despite my *explicit* explanation, at
the top, that I was taking this off-list.

I'll no longer respond to, or otherwise deal, with this individual.

        tq vm, (burley)

Re: type based aliasing again

[Rask Ingemann Lambertsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

(I'm on the list, please don't send me extra copies. Thanks.)

Den 21-Sep-99 23:46:15 skrev John W. Stevens følgende om "Re: type based aliasing again":

> They extensions are documented.  That documentation is freely available.
> That documentation comes with every copy of GCC. The ISO C standard
> does *NOT* come with every copy of GCC.

> In some respects, the GCC extensions are more public, and better
> "published" than the ISO C standard is, from the standpoint of
> a GCC user. :-)

   Is it unreasonable to expect the user to know ISO C? If not, perhaps we
could help the user get some information. There's a good chance that a
visit to the local library will dig up books on the subject. Would it be a
good idea for the GCC documentation to include a list of such books?

> You are incorrect.  Consider the economic impact of being required
> to change a body of code that is more than 1 million lines . . .

> Then mulitply that by the total number of such bodies of code.

   It has been mentioned countless times already: If you are unwilling or
unable to fix your code, or for some other reason will not be fixing your
code, then use -fno-strict-aliasing (or an older version of GCC).

   What IMHO is interesting is how to help those programmers who know or
think they have written code with aliasing problems and would like to find
and fix those pieces of code.

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen       | E-mail: mailto:rask@kampsax.k-net.dk  |
| Registered Phase5 developer    | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 866 kkeys/s (RC5-64)    | "ThrustMe" on XPilot, ARCnet and IRC  |
|      Machine-independent:  Does not run on any existing machine.       |

Re: type based aliasing again

[Joe Buck]

>    What IMHO is interesting is how to help those programmers who know or
> think they have written code with aliasing problems and would like to find
> and fix those pieces of code.

This is what the developers are attempting to do (come up with ways of
warning about code with aliasing problems).

Re: type based aliasing again

[Joe Buck]

>    What IMHO is interesting is how to help those programmers who know or
> think they have written code with aliasing problems and would like to find
> and fix those pieces of code.

This is what the developers are attempting to do (come up with ways of
warning about code with aliasing problems).

Re: type based aliasing again

[Rask Ingemann Lambertsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

(I'm on the list, please don't send me extra copies. Thanks.)

Den 21-Sep-99 23:46:15 skrev John W. Stevens følgende om "Re: type based aliasing again":

> They extensions are documented.  That documentation is freely available.
> That documentation comes with every copy of GCC. The ISO C standard
> does *NOT* come with every copy of GCC.

> In some respects, the GCC extensions are more public, and better
> "published" than the ISO C standard is, from the standpoint of
> a GCC user. :-)

   Is it unreasonable to expect the user to know ISO C? If not, perhaps we
could help the user get some information. There's a good chance that a
visit to the local library will dig up books on the subject. Would it be a
good idea for the GCC documentation to include a list of such books?

> You are incorrect.  Consider the economic impact of being required
> to change a body of code that is more than 1 million lines . . .

> Then mulitply that by the total number of such bodies of code.

   It has been mentioned countless times already: If you are unwilling or
unable to fix your code, or for some other reason will not be fixing your
code, then use -fno-strict-aliasing (or an older version of GCC).

   What IMHO is interesting is how to help those programmers who know or
think they have written code with aliasing problems and would like to find
and fix those pieces of code.

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen       | E-mail: mailto:rask@kampsax.k-net.dk  |
| Registered Phase5 developer    | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 866 kkeys/s (RC5-64)    | "ThrustMe" on XPilot, ARCnet and IRC  |
|      Machine-independent:  Does not run on any existing machine.       |

Re: type based aliasing again

[John W. Stevens]

[Snippage abounds, mostly personal attacks, bald assertions and
 repetitions, but some other things may have been inadvertently
 snipped.]

> >> >I believe this is a false premise.  Standards change.
> >> 
> >> Not in this respect, apparently.
> >
> >As I understand it, we are talking about a change that moves a construct
> >from "undefined" to "incorrect".
> 
> No, read the standard, then come back and tell us what the difference
               ^^^^^^^^
This is, indeed, the point I am trying to make: there exists a body
of code that was written before what-ever-version-of the standard
you are refering to by the use of the word: standard.

> is between "undefined" and "incorrect" in the standard.

According to the second version of "The C Programming Language" (which
was based on the Draft ANSI C standard) casting pointers from one
type to another is neither incorrect, nor undefined, it was
"implementation dependent", with the warnings being related to
alignment problems.

> If the standard does not define the behavior of a construct, then
> the construct *is* undefined.

In the first version of "The C Programming Language", this appears
to be undefined.

> My impression is that's what
> was the case with K&R C.

That is my impression as well, though of course, this is difficult
to pinpoint precisely, due to the fact that the language of the first
version of this book was not written as a language standard.

> I assume that for the purposes of this
> discussion; else -traditional should imply -fno-alias-analysis.

I am not familiar with any of the discussion re: -traditional.  If
-traditional means: "K&R C", then perhaps this switch should imply
the use of -fno-alias-analysis, under the assumption that the
code being compiled under this flag probably will contain
undefined or implementation dependent code.

> Right, in the sense that you could not be sent to prison simply because
> your code performed that construct.  Samed for division by zero,
> square root of a negative number, dereferencing a NULL pointer, etc.

Excuse, but the two classes are not analogous.  Division by zero (etc.)
is a *mathematically* undefined operation, and on some processors
such an action constitutes a reason for raising a run time
exception.

The act of doing:

{
	auto	sockaddr		sockStructure;
	auto	sockaddr_in		*inetSockStructurePointer;

	/*	Get pointer to internet socket structure.	*/
	inetSockStructurePointer = (struct sockaddr_in *) &sockStructure;
}

is not the same class of "undefined" (it is not a mathematically
undefined operation).  It is, in short, a very common operation.

One that now seems to be inadvisable, at best.

> I don't recall K&R I ever using language like "defined as illegal",
> but, for all intents and purposes, that is *exactly* the same
> as "undefined", within the context of a manual describing a language
> like C.

I disagree with this statement.  And, in fact, both K and R wrote
code that violated the new standard.  There is a fair body of
work written by K&R still floating around out there, some of
which was released into the public domain, that will demonstrate this.

> >Excuse, but the point I'm making is: there isn't necesarily a bug
> >in *either* of them.  It doesn't have to be a yes/no, black/white,
> >binary kind of thing.
> 
> But, in this case, it is *exactly* that.  The user code is undefined
> according to ISO C.  Period.

"Undefined".  Thank you.  That was my point: it isn't a bug, it is
undefined.

The whole discussion really lies in just this: it is an inflamatory
term that assigns blame.  It's use, especially in a public forum
or in an exchange with the user community, is detrimental to both
your stated aims, and the good of the project (the GNU project)
as a whole.

> How many times must I, and others, say that before you'll a) believe
> us or b) read the ISO C standard for yourself?

I've read it.  I've reread the relevant portions.  Your interpretation
disagrees with mine.  This is not an issue of belief, it is an issue of
interpretation.

Incidentally, nobody but you has told me that this code constitutes
a "bug", and in fact, I've received some private email indicating
that some people agree with me: IOW, that this is not a bug in the users
program, or in GCC, it is a *mismatch* between tool and input.

IOW, when you write implementation dependent code, you are creating
a relationship between code and tool.  This relationship must be
taken into account if you choose to change the tools you use.

> >And where we differ is in your use of the term: "bug".  I wouldn't consider
> >either GCC, or your program, to be buggy.  The act of mixing
> >incompatible pieces is probably a mistake, though.
> 
> Though I've already corrected you several times,

Excuse, but you have yet to correct me.  In fact, above, you admit above
that this is not a bug, it is simply either undefined, or implementation
dependent.

> I'll also point
> out that when a mistake is the act of mixing Y and Z, and Z is a
> specification-conforming off-the-shelf part

Which GCC is not.

> while Y is fully under the
> control of the person doing the mixing (i.e. user code), then the
> mistake is on the part of the person who mixed the two, if not
> the person who created Y.

While your explanation breaks down on point one, I agree that the
mistake lies in the persons actions, not Y or Z.  But then again,
I've already said this multiple times.  I'm happy to see that
you finally understand this, and agree with me. ;->

> It is never on the part of those who created Z.

I never (*NEVER*, *NEVER*) said that it was.

*NEVER*.

You will not find one shred, segement or phrase that I wrote that
assigns blame to GCC for this.

What you will find is generalized support for what has been done,
except that I whole heartedly agree with the suggestion that warning
code be added, where reasonable and feasible, to let the user know
what GCC is thinking.

> >And I don't believe that anybody is actually advocating this.
> 
> Actually, yes, that's what has been advocated, repeatedly, by at
> least two or three people -- that the responsibility for making
> buggy code work is on GCC's shoulders in this case.

Again, that word . . . I have seen some mail that suggests
that backwards compatibility should be a high priority.  I've
never seen *any* mail that suggests that GCC should be responsible
for making buggy code work.

When I do:

	auto	char	*tp;
	auto	char	bf[32];

	strcpy(bf, tp);

I don't expect GCC to make this buggy code work.  I *appreciate* the
warnings I *can* get re: uninitialized variables.  But that is not
the same as saying you *SHOULD* give me such warnings.

I will go on record, though, as saying just that: if possible, feasible
and reasonable, such warnings should be given.

> Then don't throw them in -- teach them.

Well, yes, that is what I was advocating.  Was I being unclear?

> GCC is not a teaching compiler.

I disagree.  I don't think such strong classifications are
reasonable.  In fact, I know many situations where GCC is,
indeed, used in a teaching environment.

> >People that *have* to have this environment to learn should not,
> >at the very least, be allowed to play with anything that might
> >injure or kill others (learning not to point a loaded gun at
> >somebody should not be something you learn by trial and error).
> 
> GCC is not a loaded gun,

I did not say it was.  GCC is a compiler suite.  I was drawing an analogy.

Allow me to point out that mission critical software failures
can indeed cost lives.  I can, if you need me to, point you to
one of the more famous cases of a software bug killing people. . .

And C is definitely a language that allows, indeed, encourages people
to do things "outside the box".

> That should not be the responsibility of GCC,

I'm not saying that it should be the *responsibility* of GCC, I'm
saying that backwards compatibility, even if only for a limited period
of time, is a "good thing".

> But, we're now told, it *is* to be thought of as the responsibility
> of GCC.  And I'm told not to object to that anymore.

Actually, you were *requested*, quite politely, not to exagerate
so much.

You seem unable to view the situation in any thing other than
black-or-white, my-way-or-yours, right-or-wrong.

There is a compromise position that is superior to either extreme,
and it seems that RMS has hit on that compromise (or, at least,
come darn close to it).  No surprise there, as he has been doing
this a very long time.

Perhaps when you get some time, gain some distance, get some
perspective, you will see this.

Maybe not.

> Which is exactly what GCC provided in 2.95, but that's not good
> enough, apparently.

It is for me.  I don't let my code fall into an "unmaintained state".

I will still modify/fix/change the very first free software package
I ever released, though I freely admit that due to email address
changes and time, it is highly unlikely that some of my original
users can in fact get a hold of me . . . :-(

> Exactly.  And GCC will continue to be plagued by arguments over
> that line, which is fuzzy at best, and will be disagreed about among
> the hundreds of programmers discussing the issue at any one time.

Which is why RMS was seeking a compromise, not laying out a
dictate.

> There *is* a bright line available: ISO C, for example.  Too bad GCC
> chooses to ignore that,

This is an exageration.  GCC already is relatively ISO C compliant,
it does not ignore the standard.  Please try not to use such
absolute terms . . . especially since in doing so, you actually
damage your own cause.  If someone new to GCC were to read this,
they may well conclude that there is no benefit to writing ISO C
compliant code when their intention is to feed that code to GCC . . .
which as you can see, will cause further problems of the type
you seem to be trying to avoid.

> >Agreed.  But GCC extensions do not make the GCC transparent.  They
> >simply add interface.
> 
> If that's the case, they can be done without adding extensions -- just
> by adding interfaces, since the ISO C language has the concept of
> procedure (function) interfaces.

Excuse, but the extensions add capabilities not supported by the
C language.

The intention in using the terminology above was to indicate by a kind
of short hand that the implementation details of something like:

__builtin_apply

Are best kept secret by adding this capability, along with its
associated interface, to the language and compiler.

This allows for a clean separation between the responsibilities
of the compiler (which are to translate high level language
constructs into the relevant assembly language) and the
responsibilities of the program designer.

The addition of "asm" support to the compiler is a much bigger
"transparency issue" than the addition of extensions.

Machine dependencies can and should be hidden by the high
level language design.

> The number counts too.

The effect of number is very small (not zero, but very small).

The following bit of code doesn't suffer from the same degradation
curve as you expect in the "physical world":

#define	NUMBER_OF_ARRAY_ELEMENTS	100

{
	auto	int			i;
	auto	DemoStruct	*array[NUMBER_OF_ARRAY_ELEMENTS];

	for (i = 0; i < NUMBER_OF_ARRAY_ELEMENTS; i++)
		array[i] = calloc(1, sizeof( DemoStruct ));
}

This code doesn't become noticeably more
complex if you change the definition of NUMBER_OF_ARRAY_ELEMENTS to 1000.

Obviously, it becomes more complex when you add error handling and
an error handling control flow path . . . but that is, as I am sure
you will agree, independent of the number of objects, yes?
		
> If you depend on 2 billion transistors working
> correctly instead of 2 million, your risk of failure goes up on
> that basis alone.

Your analogy . . . isn't.  You're comparing hardware
manafacturing to software manafacturing.  The two are not so
totally separate that there is no relationship, but the instantiation
of two million instances of the same class does not increase the
complexity of a program in the same ratio as the manafacture
of circuit that uses two million transistors does.

In hardware manafacture, a piece of dirt could damage one of your
two million transistors, but in software design, this danger is much
reduced and is, in general, considered to be quite low (if not
negligible).

If it does become a problem, then you have a *HARDWARE* problem,
not a software problem (IOW, replace your damaged memory,
adjust your processor clock speed, put better fans in the
box, replace your hard drive, what have you).

> It doesn't matter if all of them are exactly the
> same, when assessing that particular dimension.

The problem with attempting to apply an understanding of physical
engineering to software engineering is that you may fail to question
some of your assumptions.

And while I am not saying you have a degree in engineering, it does
appear to be the case that you have failed to question some of your
assumptions.

> But, yes, generally, the more *distinct* components, the more of a
> problem you have as well, because understanding how they interact,
> or might interact, gets harder.  (Especially if some are out of
> spec, e.g. buggy C code.)

The more distinct components, the more code.  More code (as a
general rule) more complexity.

> >Agreed.  But GCC extensions are, indeed, published black-box behavioral
> >descriptions.
> 
> Not by my standards they aren't

They extensions are documented.  That documentation is freely available.
That documentation comes with every copy of GCC. The ISO C standard
does *NOT* come with every copy of GCC.

In some respects, the GCC extensions are more public, and better
"published" than the ISO C standard is, from the standpoint of
a GCC user. :-)

> >Disagree.  Instantiation with parameters does not increase the
> >transparency of the instantiated object.
> 
> You're ignoring the effect of such instantiation on the maintenance
                                                          ^^^^^^^^^^^
> requirements of the *code* that requires those parameters, and the
> ease with which bugs in that code can be assessed.

The discussion was re: transparency.  Not complexity.  And I do
not ignore it.  It is true that, by reducing functionality,
that you *can* reduce complexity.

And I am not ignoring maintenance costs.  Obviously, one way 
to reduce maintenance costs is to reduce functionality (thereby
reducing the amount of code, thereby reducing complexity).

The question then becomes one of "necesity" (or, if you prefer,
"design" or "responsibility"), not one of transparency or complexity.

If an interface-and-implementation is definable as "unnecesary"
you'd have a clear win by eliminating it.  But that definition
is not solely an engineering decision.

Which takes us out of the realm of pure engineering, and back to
the (superset) realm of group dynamics *plus*.  Which, incidentally,
seems to be the real failure here: you seem to view this decision
as one that should be made purely and solely from an engineering
standpoint, when in reality, this decision must be made
with in the context of a wider and much larger system.

> Witness this whole thread, which has been repeated several times in
> the past.  *All* because of bugs in user code.

I disagree.  The thread has been repeated several times due to a
failure in communications.  Some of the GCC maintainers have
been talking/thinking solely in an "engineering" mode, when in
reality, this kind of decision transcends mere engineering.

> *All* of which could
> have been avoided had the clarity of responsibility been understood
> by all parties in the first place.  The result would be that,
> *today*, there'd be *no* code widely deployed with this bug, because
> we'd have collectively devoted our resources to *finding* and *fixing*
> it, rather than *arguing* about just how we should *accommodate* it.

Your statement is in error.  In point of fact, what would have happened
is that an indeterminate set of users would have written GCC off as
a "bad show", and gone elsewhere.

While this prospect may not bother you, I submit to you that it should.

The words "feasible, reasonable and practical" are indeed fuzzy, but this
is an advantage, not a disadvantage, as it makes the system as a whole
more dynamic, more adaptive.

> Viewing the accommodating of a bug as equivalent to passing the number of
> lines for `tail' to display strikes me as rather unwise.

Probably because that is not what I was talking about.

> It's certainly
> not a view a true engineer would take of an entire system.

Please try to avoid jumping topics.  The topic was re: complexity
control, not "accomodating bugs".

As for "the view a true engineer would take", I submit to you that
this is a statment of belief: in short, this is not a statement
that a true engineer would make.

;-> ;-> ;-> ;-> 

An engineer stands at the juntion where math, science, politics, economics
and group dynamics collide.  Decisions must be made within the context
of the system as a whole, and not solely within the context of single,
small, sub system.

> That's a stunning statement, since it implies that even when the
> switch no longer has the effect necessary for the *system* to
> work, the component being given the switch cannot reject it so
> as to warn the designer, or the other component, that something
> is no longer working.

Yes.  Indeed.  You are aware that this is already common practice
in GNU systems, are you not?

I can within 30 seconds draw up documentation on three different
GNU programs that describe a switch as being "accepted for
compatibility reasons", but that is documented as doing nothing,
or as being unnecesary.

> It may be reasonable.  It *is* unnecessary, by definition: nobody
> *needs* GCC to compile code with this bug,

You are incorrect.  Consider the economic impact of being required
to change a body of code that is more than 1 million lines . . .

Then mulitply that by the total number of such bodies of code.

> since, as long as GCC
> compiles ISO-C-conforming code correctly (which *is* presumed to
> be necessary), any code believed to contain this bug can be
> fixed,

Have you ever managed a project?  Believe it or not, it is sometimes
cheaper to spend 10 million dollars over six years, than to get
exactly the same thing for three million dollars all at once.

   [ Accounting isn't black magic, it just some times looks like it! ]

> That's *exactly* what some people have suggested.

Again, I have not seen any mail on the list that I would interpret
in this fashion.

> Look, it *should* be this simple:

Another statement of belief?  I thought you were the proponent of
pure engineering thought?

> What *has* been happening is the maintainer tracks down the bug,
> sees it's the result of undefined behavior, but reports it as
> a bug to the GCC lists anyway, because "that's not the way GCC
> worked last week".

And this is a valid action on the part of the user.

It is equally valid for the GCC maintainers to take into account
all of the relevant factors, then make a decision as to what
response (ranging from: "you gotta fix your code", to "oops, sorry,
we'll fix GCC so it doesn't do that") they will give.

But the response given must arise from the philosophical basis
for the project: IOW, the GNU project has a philosophical basis
that should guide the decision making process.

Which was, in short, what RMS was doing.

> In other words, the whole discussion is about making GCC's internal
> processing more "open", on the assumption it already *is* "open".

I don't equate the above to making GCC "open".  In fact, changing
implementation dependent results from one version of the compile
to another does more to makes GCC more transparent than that of
a user requesting that the change *not* be made.

> Please go back and read the entire thread, as well as the ISO C
> standard from front to back, before responding to this email with
> further arguments against these basic points.

You would be well advised to go back and read more than just the current
version of the ISO C standard.  Start with K&R's original book, then 
read the various "draft" versions of the standard, then check the date
on which the "finished" version of the standard was released and
estimate in your head just how much code was written before the
"finished" version was released.

It may be worth the effort if you also attempt to estimate the *cost*
of changing that much code.

> >This is your opinion.  You are free to state it.  The GCC user (as by
> >now is abundantly clear) does not share your opinion on what "matters".
> 
> Of course not.

:-(

> To those GCC users, what matters is a free ride --

Again, an unfair characterization.

> >A compromise is in order.  A good engineer cares about what his
> >customers/users care about.
> 
> False.

I would be shocked by this, but at this point, I am simply
saddened by this response, not shocked.

> A good engineer cares about the correct results being obtained.

"Correct" . . . is a slippery term.  In some respects, that
is a characterization that could be applied to the user: he
just cares about getting correct results, and the new version
of GCC didn't give him correct results, so he is pissed off.

> Now, if you want to know who *does* care about what his customers/users
> care about -- that's called a "marketing person", or a "product manager".

If your engineers do not care about the customer, then your engineers
are a waste of money.  The only reason for having engineers, is
to meet the needs of the customer.

In short: a software craftsperson is analogous to a counter-person
working at MacDonalds . . . you are only useful so long as you
service your customer.

> Ask the engineers who worked on those dams in China.  What their
> customers/users -- the government -- cared about was saving money,
> etc.  The result?  The largest technological disaster, in terms of
> lives lost, in this century.

Again, physical engineering is not equivalent to software engineering.

Again, decisions must take into account all factors.  That includes,
but is *NOT* limited to, "engineering correctness".

Limiting a decision to "economic correctness" is just as counter-productive
as limiting a decision to "engineering correctness".  Both factors 
(and more!) must be taken into account, and given weight.

> Now, had they cared first and foremost about doing the *right* thing,

The "right thing" takes into account such factors as money.  It does
not depend solely on money, but it must take that into account.

> But if you look at every technological disaster this century, pretty
> much in every instance you can find a marketing type working in an
> engineering role, i.e. doing just what *you* say they should be doing --
> accounting first for what someone "wants", rather than what the
> realities of engineering *require*.

And there are many examples of failed companies due to the fact that
they had engineers in the marketing department who cared not a whit
about the customer.

Or, who worse yet, treated the marketing department as the enemy, instead
of as a partner, a valued and respected part of the organization.

And, again, *want* and *require* must be judged within the larger context.

There are *wants* that outway petty engineering "requirements", because
in the context of the larger picture, that *want* is a requirement,
while that "engineering requirement" is simply a difficulty that
can be worked around.

> That "one" therefore is incapable of distinguishing between the risks
> we all take by living and the specific risks introduced by tolerating
> incompetent design strategies.

Consider the fact that no system can be proven "correct".  Consider,
also, that most systems are built from compromises.   Consider the
effect that these compromises have on the system.

> Therefore, that "one" should be disallowed from working on *any* system
> of any import in our society.

That "one" pretty much describes the vast majority of the people who
control systems design and implementation.

Like it or not, compromises are a fact of life.  These compromises
may reduce the *engineering* correctness of a system, but they do
not invalidate that system.  They do, in general, make most systems
more failure prone than they (theoretically) need to be, but as that
theoretical basis is "unreal", it is not a valid point to argue from.

> >This assumption makes GCC a smaller, less complex component . . . at
> >the cost of making the *whole* system *MUCH* more complex.
> 
> False.

No, it's true.

This is so true, that it has become a working principle for engineers:
reusable design patterns.  The GCC extensions arise out of repeatedly
solving the same types of problems.  Eventually, this fact is recognized,
an analysis is done, and a generically applicable solution is constructed
and installed.

This reduces complexity enourmously.  Think: library (generic
implmentations of reusable design patterns).

__builin_apply is an extension that greatly reduces the complexity
of the system as a whole.

> In fact, the code GCC compiled would get *easier* to maintain
> because it'd conform *better* to the *one* widely known standard
> for the C language: ISO C.

You contradict yourself.  ;->

First you complain that nobody
reads or understands the ISO C standard, then you claim that it
is widely known.

> >This statement seems to be based on the false premise that adding
> >interface, makes an object more transparent (it does not).
> 
> Your statement *is* based on the false premise that adding
> an interface to cause one component to be more complicated just
> to accommodate another component being out of spec is in no
> way different than adding an interface for other, legitimate reasons.

Nope.  I recognize the difference, though I disagree with your
use of the phrase "legitimate".  Adding interface to *an* object
to accomodate a *set* of out-of-spec components is both legitimate,
and indeed, it reduces the complexity of the system as a whole.

Changing 200 lines in GCC to avoid changing 2 million lines of
application/OS source code may indeed constitute a legitimate change.

> If you can't distinguish between those cases, you'll *never* be
> able to prevent all sorts of new interfaces being added to
> component A to accommodate bugs in component B.

It can be prevented in exactly the way it has always been
prevented: through the group dynamic.  If a small number of people
want an accomodation, it will probably not occur.  If a large number
of people want an accomodation, it probably will (and should) occur.

> *That's* the whole
> point of my objection -- while, in any one instance, it might
> indeed seem "helpful" to do that, there's unlikely to be the
> backbone necessary to prevent that one instance from turning into
> a flood.

Your fears are ungrounded.  The group dynamic will (and HAS!)  prevent
this from occurring.

> (Go back and read the archives, especially Linus Torvald's posts of months
> ago, where he basically says, as he has said so often, "why not
> accommodate *my* needs, when you've accommodated X, Y, and Z?".

Excuse, but your paraphrase is not entirely accurate.  Linus argued
that the needs of Linux are symptomatic of a much larger body of code.

And yes, I've been following this list for quite some time.  I do
not need to go back to the archives: I was there, and read it as it
came in.

> You would, if you paid attention,
> quickly learn the lesson: never accommodate anyone's "needs", just
> write to the pertinent standards/specifications...or get into
> marketing.)

I pay attention.  And I do accomodate needs.  And I am not
a marketeer.

> Well, it could be said we already *had* the dialog vis-a-vis
> this construct: user says "I want to program in C"; GCC says
> "I compile ISO C to run pretty fast"; users says "great, I'll
> use it".

The only problem is: that is a mis-statement, as "C" is a moving
target.

The problem (as is almost always the case) is one of miscommunication:
and in most cases, the user isn't saying "I want to program in
pure, latest-available-ISO-C-standard-C", they are saying: I want
a compiler that generates correct code from my source, which turns
out to be "defacto standard C".

If it makes it any clearer, think of C, like every other language,
as a result of group consensus.  A standards document may say one
thing, but the group may say something else.  Which is why RMS
believes in paying attention to the standard, but not in being
slavishly bound to it.

> >The success of the GUI simply proves what has been known for a
> >very long time: dialog is better than monologue, and monologue
> >is better than no communications what-so-ever.
> 
> Tell that to blind users.  And I don't mean that to be flippant:
> having studied GUIs vs. CLIs, and the issues arising therefrom,
> I cannot possibly agree with your flat-out statement as used
> in this context.

The GUI is an *instance* of a user interface design pattern
based on the concept of dialog.  It isn't the *GRAPHICAL* part
of GUI that makes GUI's preferable for most people to CLI's, it
is the *STATIC* *DIALOG* part that is important.

Dialog based UI's do not need to be graphical (dialog does not
mean: GUI dialog box, it refers to a langauge based information
exchange). And in fact, my statement stands as correct: dialog
is always better than monologue, monologue is always better than
no communications what so ever.

A blind person may require that the dialog be audio, instead of
written, but the design pattern is still correct.

I've written handicapped accessible UI systems.  The dialog
UI design pattern is so basic, it can be found in nearly every
successful software system.

> The future will prove me right in
> this case as well: the warning will be assailed by many as inadequate,
> incorrect, etc.

Darn near every warning, error or notice has been assailed at one
time or another.

This does not mean that we should not have warnings, errors or
notices.  If a large body of users *DOES* complain, though, that
*DOES* indicate we need to fix/modify what they are complaining
about.

> Somewhere, somehow, responsibility for these bugs has to *stop*.
> The buck must stop somewhere.  In this case, since the bug is
> in user code, it does *not* stop with GCC.

Ok, I cannot resist doing what you do to me, so right back at ya:

<mirror>
I've corrected you multiple times.  When will you read the langauge
definitions and understand this?

It isn't a bug if it was 1) undefined or 2) implementation dependant.

It is a tool vs. input *MISMATCH* (re: philiphs head screw and
flat blade screw driver).
</mirror>

The responsiblity lies with the person mis-using a tool.  Surely
you've read those warnings about "this product not intended to be inhaled",
or some such?

Accomodating the knowledgeable user who is, unfortunately, caught
in the situation of being forced to use the new tool with old code
(because, after all, the GCC maintainers do not maintain old versions
of the compiler), is not only reasonable, it is a requirement.

> The job of a compiler is not to communicate: it is to *compile*.

The *PRIMARY* job of the compiler is to translate what the
user says, into something the machine can understand.  As with 
any translation from one language to another, the mapping isn't
one to one.  Misunderstandings can and will occur, therefore
the compiler *MUST* communicate what it is thinking to the user
so that the user can catch and fix these misunderstandings.

> But when you say the most *important* facet is to talk, you support
> those who choose to have their software talk, even when the result
> is the wrong thing (files lost, lives lost, whatever).

No, I don't support that.  The two do not have to be related.

In short, *BAD* use of dialog does not constitute a valid reason
for not using dialog.

It merely indicates that you should fix your program: its buggy! ;->

> >Warnings should be issued *even* *if* adding them increases internal
> >complexity of the object.
> 
> No.

Yes.  Increasing the complexity of a single object in order to
reduce the complexity of the entire system is good engineering
practice.

> I wasn't talking about an object with no interface.  I was talking
> about one that does what it is supposed to do, and no more.

Yes.  And part of what "it is supposed to do" is communicate with
the user.

> crash?

Certainly that would be a warning to the developer. . . but a very
poor communication technique, unless the crash (core dump, anyone?)
comes with information specifiying *WHY* the crash occurred.

> Print a message to stderr?

This may indeed be a valid response for certain kinds of programs.

What, you don't like logging?  You never use Unix, or you do, but
you never read the log files to check for intrusion *WARNINGS*
from your system? ;->

How do you keep your systems secure, then?

> Which one of these
> warnings the *caller* that it might not mean what it says?

But, in response, consider what you wrote: how can a module warn
that it's warnings may not valid?  How about this: "This input
may be invalid" . . . catch the word, "may" there.

To the user, this should imply that the compiler sees the construct
in question as ambiguous.

> False on all points.

Since it is this object, (the compiler) that defines the translation,
it is the compilers responsibility to communicate this information,
when appropriate, back to the user.

> It is *not* the responsibility of the *compiler*
> to define proper-and-appropriate.

"Implementation defined".

> To the extent the *product* of
> which it is a part does that, the knowledge can be communicated
> via documentation;

Making the system much, much more complex as putting this information
solely in the documentation, while the *enforcement* responsiblity
lies with the compiler, creates a huge and vastly complex relationship
between two objects.

You talk about complexity, then turn around and want to vastly
increase it.

Surely in your experience you've come across documentation that
disagrees with the actual code?

> via a tool that analyses code and spots problems
> (issuing warnings); or similar.

Which, again, vastly increases complexity.

You are talking about implementing two objects that have overlapping
responsibilities.

> What I'm actually suggesting is that cc1 should not produce diagnostics,
> that a separately maintained program should.

It's been tried.  It was abandoned as a bad design.

John S.

Re: type based aliasing again

[Harvey J. Stein]

Here's another example of code which breaks without
-fno-strict-aliasing.  And again, it took a substantial amount of
"this doesn't work for me", vs "it's fine for me" on the mailing list
before someone came up the answer.

------- Start of forwarded message -------
Date: Sat, 18 Sep 1999 21:04:33 -0700 (PDT)
From: "William A. Barath" <wi534@victoria.tc.ca>
To: xmame@locutus.csres.utexas.edu
Subject: Re: Blockout?!
Message-ID: <Pine.GSO.3.95.iB1.0.990918210209.21502B-100000@vtn1>
Reply-To: xmame@locutus.csres.utexas.edu

On Sat, 18 Sep 1999, Alexander Oelzant wrote:

|OPTFLAGS    = -O6 -mk6 -mcpu=k6 -march=k6 -Wall -Wno-unused -funroll-loops
|\
|   -fstrength-reduce -fomit-frame-pointer -ffast-math -malign-functions=4 \
|   -malign-jumps=4 -malign-loops=4 -malign-double \
|   -mwide-multiply -fforce-mem -fforce-addr -funroll-loops \
|   -fcse-follow-jumps -fcse-skip-blocks \
|   -frerun-cse-after-loop -frerun-loop-opt -fschedule-insns2 \
|   -fgcse -fmove-all-movables -freduce-all-givs -fstrict-aliasing

you must change that last item to -fno-strict-aliasing otherwise gcc will
break the z80 core, which will make a lot of games unplayable.

  -Wil

 William Barath, AKA WseM  http://www.victoria.tc.ca/~wi534

TP7 Programmers: Check out my FREE preemptive Threads Unit!
DJGPP Programmers: Check out my FREE realtime Fractal Zoomer!
Emulation Coderz: Check out my LAME-O Apple ][+ Emulator!  ;)

---------------------------------------------------------------------------
Send administrative requests to xmame-request@acm.csres.utexas.edu

------- End of forwarded message -------

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Richard Stallman]

Could you show us the actual function?  CPP output would be clearest.

Re: type based aliasing again

[Harvey J. Stein]

Richard Stallman <rms@gnu.org> writes:

 > Could you show us the actual function?  CPP output would be
 > clearest.

I assume you're refering to the problem forwarded with xmame?  I don't
have the latest xmame or the latest gcc installed and there's also now
some argument on the list as to whether or not this is really the
problem.  I'll ask the person who claimed there was a problem to do
this.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Richard Stallman]

     > Could you show us the actual function?  CPP output would be
     > clearest.

    I assume you're refering to the problem forwarded with xmame?

Yes.  It is hard to draw conclusions from a problem
without seeing the actual code for which it occurred.

Re: type based aliasing again

[Richard Stallman]

     > Could you show us the actual function?  CPP output would be
     > clearest.

    I assume you're refering to the problem forwarded with xmame?

Yes.  It is hard to draw conclusions from a problem
without seeing the actual code for which it occurred.

Re: type based aliasing again

[Harvey J. Stein]

Richard Stallman <rms@gnu.org> writes:

 > Could you show us the actual function?  CPP output would be
 > clearest.

I assume you're refering to the problem forwarded with xmame?  I don't
have the latest xmame or the latest gcc installed and there's also now
some argument on the list as to whether or not this is really the
problem.  I'll ask the person who claimed there was a problem to do
this.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Richard Stallman]

Could you show us the actual function?  CPP output would be clearest.

Re: type based aliasing again

[Harvey J. Stein]

Here's another example of code which breaks without
-fno-strict-aliasing.  And again, it took a substantial amount of
"this doesn't work for me", vs "it's fine for me" on the mailing list
before someone came up the answer.

------- Start of forwarded message -------
Date: Sat, 18 Sep 1999 21:04:33 -0700 (PDT)
From: "William A. Barath" <wi534@victoria.tc.ca>
To: xmame@locutus.csres.utexas.edu
Subject: Re: Blockout?!
Message-ID: <Pine.GSO.3.95.iB1.0.990918210209.21502B-100000@vtn1>
Reply-To: xmame@locutus.csres.utexas.edu

On Sat, 18 Sep 1999, Alexander Oelzant wrote:

|OPTFLAGS    = -O6 -mk6 -mcpu=k6 -march=k6 -Wall -Wno-unused -funroll-loops
|\
|   -fstrength-reduce -fomit-frame-pointer -ffast-math -malign-functions=4 \
|   -malign-jumps=4 -malign-loops=4 -malign-double \
|   -mwide-multiply -fforce-mem -fforce-addr -funroll-loops \
|   -fcse-follow-jumps -fcse-skip-blocks \
|   -frerun-cse-after-loop -frerun-loop-opt -fschedule-insns2 \
|   -fgcse -fmove-all-movables -freduce-all-givs -fstrict-aliasing

you must change that last item to -fno-strict-aliasing otherwise gcc will
break the z80 core, which will make a lot of games unplayable.

  -Wil

 William Barath, AKA WseM  http://www.victoria.tc.ca/~wi534

TP7 Programmers: Check out my FREE preemptive Threads Unit!
DJGPP Programmers: Check out my FREE realtime Fractal Zoomer!
Emulation Coderz: Check out my LAME-O Apple ][+ Emulator!  ;)

---------------------------------------------------------------------------
Send administrative requests to xmame-request@acm.csres.utexas.edu

------- End of forwarded message -------

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[N8TM]

In a message dated 9/18/99 9:30:18 AM EST, moshier@mediaone.net writes:

> Surely glibc should not give different math.h answers depending on
>  compiler optimization!  
They try to deal with this by making the library versions of math functions 
the same as the in-lined ones, except possibly for limiting cases.  For 
example, the paranoia test for the accuracy of pow(x,y) where x is near 1. 
and y is large shows exactly the same problems either way.  Not that it's 
clearly beneficial for pow() to in-line.

Tim

Re: type based aliasing again

[N8TM]

In a message dated 9/18/99 9:30:18 AM EST, moshier@mediaone.net writes:

> Surely glibc should not give different math.h answers depending on
>  compiler optimization!  
They try to deal with this by making the library versions of math functions 
the same as the in-lined ones, except possibly for limiting cases.  For 
example, the paranoia test for the accuracy of pow(x,y) where x is near 1. 
and y is large shows exactly the same problems either way.  Not that it's 
clearly beneficial for pow() to in-line.

Tim

Re: type based aliasing again

[Stephen L Moshier]

>   I suppose we have no say on the 
> peculiar in-lining scheme with glibc; apparently on at -O and -O2,
> unless specifically turned off; always off at -Os even when it
> would save space.

This sounds like glibc is violating the rule that optimization is
not supposed to change the value of expressions.  Why do we even
permit glibc to know what -O switch was used?

Surely glibc should not give different math.h answers depending on
compiler optimization!  That kind of behavior should be under the
user's control.  It has long been customary to offer several different
math libraries designed for various different purposes.  Maybe glibc
should follow that custom.

Re: type based aliasing again

[Stephen L Moshier]

>   I suppose we have no say on the 
> peculiar in-lining scheme with glibc; apparently on at -O and -O2,
> unless specifically turned off; always off at -Os even when it
> would save space.

This sounds like glibc is violating the rule that optimization is
not supposed to change the value of expressions.  Why do we even
permit glibc to know what -O switch was used?

Surely glibc should not give different math.h answers depending on
compiler optimization!  That kind of behavior should be under the
user's control.  It has long been customary to offer several different
math libraries designed for various different purposes.  Maybe glibc
should follow that custom.

Re: type based aliasing again

[Artem Hodyush]

Richard Stallman wrote: 

>The only thing that is hard is when people argue, as you are doing,
>against the very idea of accommodation. So please don't do that.

There may be different degrees of accomodation. Issuing useful warning is 
one thing, altering the behavior of compiler when it sees suspicious code 
is another. 

The very idea that compiler should make an educated guess and decide 
which options to apply to my code gives me shudder. The software should 
do what I say, no more and no less. We have seen many attempts by 
various vendors to make their software 'smart', in the sense that it should 
do things that it supposes user wants it to do, without asking, because 
vendors believe that it will help them sell software to computer-impaired people. 
In my experience, the smarter software is, the closer it is to becoming unusable. 
I guess that people are worried because they see you proposing that gcc 
will also go that way. 

>Be that as it may, that question is a side issue. You are talking
>about programmers running GCC on code that they are developing. Those
>are just some of the users of GCC. Only some of the people running
>GCC are running it on code they understand, or could attempt to debug.
>
>We must not make GCC decisions with only those people in mind.

Speaking about side issues.

If people running gcc don't bother to read release notes for the version 
of gcc they run, and don't know how to put a gcc option into the 
makefile, I'd say that they are not qualified to do their job. 
You can't be kind to everyone. Is it harsh not to allow people 
to drive a car, if they can't pass driver test? Yes I'm exaggerating, 
but I'm extremely frustrated by the poor quality of software that floods 
the market. 

And if you see gcc as install tool, I think that it's not possible to 
have both an install tool and a compiler in one bottle, er, package. 

> But, I believe the analysis for GCC *itself* is *much* simpler:
> conform to the pertinent ANSI/ISO standards, etc.
>
>GCC does conform to these standards, when used with the proper set of
>options. 

GCC does not yet conform neither to ANSI C 9X, nor to the ANSI C++ 98. 

> However, technical standards are not a moral authority. The
>GNU Project policy is that we pay close attention to official
>standards, but we don't slavishly obey them.

I guess this is not the case with C and C++ standards, if you want 
serious developers to continue to use gcc.

Re: type based aliasing again

[Russ Allbery]

I probably shouldn't be sticking my nose into the middle of this
conversation, as I'm not actively involved in gcc development and am just
a user of the compiler, but I've been following this whole discussion and
it seems to me that people are arguing about something slightly different
than what's being proposed.

Artem Hodyush <artem@duma.gov.ru> writes:

> There may be different degrees of accomodation. Issuing useful warning
> is one thing, altering the behavior of compiler when it sees suspicious
> code is another.

The proposal, as I understand it, is for the compiler to do its normal
alias analysis and if it detects that two variables alias even when
they're not supposed to do so according to their types, to remember that
fact and treat them like they alias.  To detect that two variables alias
and then go on and treat them like they don't alias because they're not
supposed to would seem to me to stand a high chance of knowingly
generating bad code, and feels to me like a lack of resiliancy in the face
of errors.  So the proposal sounds very reasonable to me.

The primary objection appears to be that detection of this particular
error will be spotty and inconsistent at best, and that detecting it
sometimes and not detecting it other times will be confusing for users who
will not know whether or not their code needs fixing.  I'm confused by
this objection, though, because isn't this already the case?  It seems to
me that one of the characteristics of miscompilation caused by violation
of the aliasing rules will be that it will be spotty and inconsistent,
vary at different optimization levels, and may be avoided entirely due to
hard to understand internal compiler reasons in some circumstances and not
in others.  This seems inevitable since it's an optimization, and whether
or not a complex optimization will be applied in any particular case tends
to be rather hard to determine.

So it seems to me, if I'm accurately following the implications of all
this, that either way GCC goes the users will get spotty and inconsistent
behavior if they aren't following the aliasing rules.  Under RMS's
proposal, however, there's at least a chance that rather than incorrect
code they'll get a warning and correct code, which as a user of the
compiler I would certainly consider to be an improvement.

I think it's a very good idea for the compiler, if given -ansi, to simply
assume the standard aliasing rules and make no attempts to correct for
violations of the rules.  That's certainly what I'd expect when using
-ansi; -ansi is a promise to the compiler that the code is, modulo bugs,
going to fully comply with the ANSI standard.  But when not using -ansi, I
think the principles of resiliancy in the face of invalid input call for
the compiler to do its reasonable best to produce valid code if it can
detect the aliasing in the normal course of its analysis.

> The very idea that compiler should make an educated guess and decide
> which options to apply to my code gives me shudder.

I don't really understand this reaction; it seems to imply to me that you
wouldn't care for *any* optimizing compiler, since that sounds like the
whole point of the optimizer.

> The software should do what I say, no more and no less.

Even when given invalid input?  I spend quite a bit of time running GCC on
clearly invalid code.  I use GCC to catch syntax errors in code, I use it
with a bunch of warning flags as a partial substitute for lint, and it
helps out a great deal by being intelligent enough to figure out when
something isn't valid C.  If it encounters invalid input, I certainly
would like for it to complain, but I also expect it to attempt to continue
on anyway unless the input is horribly invalid.  To me, that's reasonably
standard behavior for a compiler.

I know one of the problems here is that GCC can't always tell that
something is unambiguously invalid.  I think in those cases where it can't
tell, it's quite reasonable to assume ANSI aliasing rules and proceed on
that basis.  It's only on the cases where GCC can be 99% certain that the
input is invalid that I'd like to see a warning and as much of an attempt
as is easily possible at getting the code right anyway.

Please don't consider object code generation to be the only purpose of a
compiler.  It is the primary purpose, but compiler diagnostics are also a
purpose and use of a compiler, and this is even backed up by the ANSI C
requirement of diagnostics for particular invalid constructs.  Warning
about invalid code is part of the basic function of a compiler.

> Yes I'm exaggerating, but I'm extremely frustrated by the poor quality
> of software that floods the market.

I think we all are, but making it less likely that GCC will successfully
compile invalid code will not make the invalid code go away.  It may
reduce it slightly, but at the cost of driving at least some people away
from GCC to compilers that will accept the invalid code.  And then those
people will proceed to write more invalid code since their compiler won't
complain about it.

Complaining *and* attempting to compensate is, in my opinion, the closest
one can get to the best of both worlds.

-- 
Russ Allbery (rra@stanford.edu)         <URL: http://www.eyrie.org/~eagle/ >

Re: type based aliasing again

[Joern Rennecke]

> -ansi; -ansi is a promise to the compiler that the code is, modulo bugs,
> going to fully comply with the ANSI standard.

No, it's the other way round.  -ansi requests that the compiler fully adheres
to the standard.
-pedantic makes it warn about detected standad violations in the source code,
and -pedantic-errors makes it reject them.

Re: type based aliasing again

[Joern Rennecke]

> -ansi; -ansi is a promise to the compiler that the code is, modulo bugs,
> going to fully comply with the ANSI standard.

No, it's the other way round.  -ansi requests that the compiler fully adheres
to the standard.
-pedantic makes it warn about detected standad violations in the source code,
and -pedantic-errors makes it reject them.

Re: type based aliasing again

[Russ Allbery]

I probably shouldn't be sticking my nose into the middle of this
conversation, as I'm not actively involved in gcc development and am just
a user of the compiler, but I've been following this whole discussion and
it seems to me that people are arguing about something slightly different
than what's being proposed.

Artem Hodyush <artem@duma.gov.ru> writes:

> There may be different degrees of accomodation. Issuing useful warning
> is one thing, altering the behavior of compiler when it sees suspicious
> code is another.

The proposal, as I understand it, is for the compiler to do its normal
alias analysis and if it detects that two variables alias even when
they're not supposed to do so according to their types, to remember that
fact and treat them like they alias.  To detect that two variables alias
and then go on and treat them like they don't alias because they're not
supposed to would seem to me to stand a high chance of knowingly
generating bad code, and feels to me like a lack of resiliancy in the face
of errors.  So the proposal sounds very reasonable to me.

The primary objection appears to be that detection of this particular
error will be spotty and inconsistent at best, and that detecting it
sometimes and not detecting it other times will be confusing for users who
will not know whether or not their code needs fixing.  I'm confused by
this objection, though, because isn't this already the case?  It seems to
me that one of the characteristics of miscompilation caused by violation
of the aliasing rules will be that it will be spotty and inconsistent,
vary at different optimization levels, and may be avoided entirely due to
hard to understand internal compiler reasons in some circumstances and not
in others.  This seems inevitable since it's an optimization, and whether
or not a complex optimization will be applied in any particular case tends
to be rather hard to determine.

So it seems to me, if I'm accurately following the implications of all
this, that either way GCC goes the users will get spotty and inconsistent
behavior if they aren't following the aliasing rules.  Under RMS's
proposal, however, there's at least a chance that rather than incorrect
code they'll get a warning and correct code, which as a user of the
compiler I would certainly consider to be an improvement.

I think it's a very good idea for the compiler, if given -ansi, to simply
assume the standard aliasing rules and make no attempts to correct for
violations of the rules.  That's certainly what I'd expect when using
-ansi; -ansi is a promise to the compiler that the code is, modulo bugs,
going to fully comply with the ANSI standard.  But when not using -ansi, I
think the principles of resiliancy in the face of invalid input call for
the compiler to do its reasonable best to produce valid code if it can
detect the aliasing in the normal course of its analysis.

> The very idea that compiler should make an educated guess and decide
> which options to apply to my code gives me shudder.

I don't really understand this reaction; it seems to imply to me that you
wouldn't care for *any* optimizing compiler, since that sounds like the
whole point of the optimizer.

> The software should do what I say, no more and no less.

Even when given invalid input?  I spend quite a bit of time running GCC on
clearly invalid code.  I use GCC to catch syntax errors in code, I use it
with a bunch of warning flags as a partial substitute for lint, and it
helps out a great deal by being intelligent enough to figure out when
something isn't valid C.  If it encounters invalid input, I certainly
would like for it to complain, but I also expect it to attempt to continue
on anyway unless the input is horribly invalid.  To me, that's reasonably
standard behavior for a compiler.

I know one of the problems here is that GCC can't always tell that
something is unambiguously invalid.  I think in those cases where it can't
tell, it's quite reasonable to assume ANSI aliasing rules and proceed on
that basis.  It's only on the cases where GCC can be 99% certain that the
input is invalid that I'd like to see a warning and as much of an attempt
as is easily possible at getting the code right anyway.

Please don't consider object code generation to be the only purpose of a
compiler.  It is the primary purpose, but compiler diagnostics are also a
purpose and use of a compiler, and this is even backed up by the ANSI C
requirement of diagnostics for particular invalid constructs.  Warning
about invalid code is part of the basic function of a compiler.

> Yes I'm exaggerating, but I'm extremely frustrated by the poor quality
> of software that floods the market.

I think we all are, but making it less likely that GCC will successfully
compile invalid code will not make the invalid code go away.  It may
reduce it slightly, but at the cost of driving at least some people away
from GCC to compilers that will accept the invalid code.  And then those
people will proceed to write more invalid code since their compiler won't
complain about it.

Complaining *and* attempting to compensate is, in my opinion, the closest
one can get to the best of both worlds.

-- 
Russ Allbery (rra@stanford.edu)         <URL: http://www.eyrie.org/~eagle/ >

Re: type based aliasing again

[Richard Stallman]

    The very idea that compiler should make an educated guess and decide 
    which options to apply to my code gives me shudder. 

No one has proposed this.

    The software should 
    do what I say, no more and no less.

The issue here is with cases where it takes some interpretation to
decide what the code "says".  There is more than one legitimate
interpretation, and the question is, should we make a certain effort
to choose the one that the code's author probably had in mind.

    In my experience, the smarter software is, the closer it is to
    becoming unusable.

I agree with you, for some questions--I think it is bad for software to
be written based on the assumption that it is smarter than the user
who is operating it, or to disbelieve that the user means what he says.
When the input has a clear meaning, software should obey it.

But the C language is such that not every program has a clearly
defined meaning.  Using a little intelligence to figure out what
the code probably meant is not disobedience, it is a more careful
kind of obedience.

Re: type based aliasing again

[Richard Stallman]

    The very idea that compiler should make an educated guess and decide 
    which options to apply to my code gives me shudder. 

No one has proposed this.

    The software should 
    do what I say, no more and no less.

The issue here is with cases where it takes some interpretation to
decide what the code "says".  There is more than one legitimate
interpretation, and the question is, should we make a certain effort
to choose the one that the code's author probably had in mind.

    In my experience, the smarter software is, the closer it is to
    becoming unusable.

I agree with you, for some questions--I think it is bad for software to
be written based on the assumption that it is smarter than the user
who is operating it, or to disbelieve that the user means what he says.
When the input has a clear meaning, software should obey it.

But the C language is such that not every program has a clearly
defined meaning.  Using a little intelligence to figure out what
the code probably meant is not disobedience, it is a more careful
kind of obedience.

Re: type based aliasing again

[Harvey J. Stein]

"Artem Hodyush" <artem@duma.gov.ru> writes:

 > The very idea that compiler should make an educated guess and decide 
 > which options to apply to my code gives me shudder. The software should 
 > do what I say, no more and no less.

Then type based aliasing should make you shudder too, since it's very
much the situation of the compiler *not* doing what you say, but doing
substantially more work to figure out a faster way to have the same
effect.  For that matter, any optimization at all should make you
shudder.

It's really a matter of degree.  In this case there seems to be a
substantial amount of code that breaks when the compiler trys to do
sophisticated analysis on variable usage to determine what can be
stored where.  This analysis is allowable by the ANSI standard, but it
seems that most people haven't written their code in a manner that's
portable wrt this analysis.  So, the question becomes, "To what extent
can the compiler help people who aren't writing code conforming to
this particular aspect of the ANSI standard?"

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Harvey J. Stein]

"Artem Hodyush" <artem@duma.gov.ru> writes:

 > The very idea that compiler should make an educated guess and decide 
 > which options to apply to my code gives me shudder. The software should 
 > do what I say, no more and no less.

Then type based aliasing should make you shudder too, since it's very
much the situation of the compiler *not* doing what you say, but doing
substantially more work to figure out a faster way to have the same
effect.  For that matter, any optimization at all should make you
shudder.

It's really a matter of degree.  In this case there seems to be a
substantial amount of code that breaks when the compiler trys to do
sophisticated analysis on variable usage to determine what can be
stored where.  This analysis is allowable by the ANSI standard, but it
seems that most people haven't written their code in a manner that's
portable wrt this analysis.  So, the question becomes, "To what extent
can the compiler help people who aren't writing code conforming to
this particular aspect of the ANSI standard?"

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Artem Hodyush]

Richard Stallman wrote: 

>The only thing that is hard is when people argue, as you are doing,
>against the very idea of accommodation. So please don't do that.

There may be different degrees of accomodation. Issuing useful warning is 
one thing, altering the behavior of compiler when it sees suspicious code 
is another. 

The very idea that compiler should make an educated guess and decide 
which options to apply to my code gives me shudder. The software should 
do what I say, no more and no less. We have seen many attempts by 
various vendors to make their software 'smart', in the sense that it should 
do things that it supposes user wants it to do, without asking, because 
vendors believe that it will help them sell software to computer-impaired people. 
In my experience, the smarter software is, the closer it is to becoming unusable. 
I guess that people are worried because they see you proposing that gcc 
will also go that way. 

>Be that as it may, that question is a side issue. You are talking
>about programmers running GCC on code that they are developing. Those
>are just some of the users of GCC. Only some of the people running
>GCC are running it on code they understand, or could attempt to debug.
>
>We must not make GCC decisions with only those people in mind.

Speaking about side issues.

If people running gcc don't bother to read release notes for the version 
of gcc they run, and don't know how to put a gcc option into the 
makefile, I'd say that they are not qualified to do their job. 
You can't be kind to everyone. Is it harsh not to allow people 
to drive a car, if they can't pass driver test? Yes I'm exaggerating, 
but I'm extremely frustrated by the poor quality of software that floods 
the market. 

And if you see gcc as install tool, I think that it's not possible to 
have both an install tool and a compiler in one bottle, er, package. 

> But, I believe the analysis for GCC *itself* is *much* simpler:
> conform to the pertinent ANSI/ISO standards, etc.
>
>GCC does conform to these standards, when used with the proper set of
>options. 

GCC does not yet conform neither to ANSI C 9X, nor to the ANSI C++ 98. 

> However, technical standards are not a moral authority. The
>GNU Project policy is that we pay close attention to official
>standards, but we don't slavishly obey them.

I guess this is not the case with C and C++ standards, if you want 
serious developers to continue to use gcc.

Re: type based aliasing again

[Ross Morgan-Linial]

> Not in this respect, apparently.  Nobody has, to my knowledge,
> proposed that -traditional imply -fno-alias-analysis, which suggests
> K&R I indeed, as has been reported, left this behavior undefined.

Well, a quick flip through my copy reveals what look to me like 
contradictory statements. In chapter 5 (pointers and arrays) it says

    You should also note the implication of the declaration that a 
    pointer is constrained to point to a particular type of object.

Now, that appears to say that playing games with pointers is right 
out. However, in appendix A (C reference manual), section 14.4, it 
says

    A pointer to one type may be converted to a pointer to another 
    type. The resulting pointer may cause addressing exceptions upon 
    use if the subject pointer does not refer to an object suitably 
    aligned in storage. It is guaranteed that a pointer to an object 
    of a given size may be converted to a pointer to an object of a 
    smaller size and back again without change.

    For example, a storage-allocation routine might accept a size (in 
    bytes) of an object to allocate, and return a char pointer; it 
    might by used in this way.

        extern char *alloc();
        double *dp;
        dp = (double *) alloc(sizeof(double));
        *dp = 22.0 / 7.0;

    alloc must ensure (in a machine-dependent way) that its return 
    value is suitable for conversion to a pointer to double; then the 
    _use_ of the function is portable.

That seems to imply that it's okay to use a pointer pointing to an 
object of different type as long as it's suitably aligned. Of course, 
I'm hardly an expert on K&R C.

Re: type based aliasing again

[Ross Morgan-Linial]

Date sent:      	Sat, 18 Sep 1999 15:19:05 +0200
From:           	Marc Lehmann <pcg@opengroup.org>
To:             	rmorgan@jetcity.com
Subject:        	Re: type based aliasing again

> On Sat, Sep 18, 1999 at 02:49:47AM -0700, Ross Morgan-Linial <rmorgan@jetcity.com> wrote:
> >     alloc must ensure (in a machine-dependent way) that its return 
> >     value is suitable for conversion to a pointer to double; then the 
> >     _use_ of the function is portable.
> > 
> > That seems to imply that it's okay to use a pointer pointing to an 
> > object of different type as long as it's suitably aligned. Of course, 
> > I'm hardly an expert on K&R C.
> 
> Use yes (copy, cast), but not dereference. This only means you can
> (temporarily) cast a pointer into some other datatype (as supported by the
> language, e.g. a long), and after casting back you can dereference it. You
> can not, however, use the long (or a pointer to a different type) and
> dereference a different type using it.

Actually, the sentence I thought implied it was this one:

    The resulting pointer may cause addressing exceptions upon use if 
    the subject pointer does not refer to an object suitably aligned 
    in storage.

I don't see why the part about alignment would be there if _any_ use 
of a pointer to data of the wrong type was bad. Sorry I wasn't clear.

Another argument for guessing K&R allowed access though arbitary 
pointers is that there is no exception for char *, so if it wasn't 
allowed memcpy-type functions would be impossible.

However, I just noticed that appendix A, section 16 seems to 
disallow, or at least discourage, this (and also provides a good 
short name for using a mistyped pointer):

    Some difficulties arise only when dubious coding practices are 
    used. It is exceedingly unwise to write programs that depend on 
    any of these properties.
    ...
    Fields are assigned to words and characters to integers right-to-
    left on the PDP-11 and left-to-right on other machines. These 
    differences are invisible to isolated programs which do not 
    indulge in type punning (for example, by converting an int 
    pointer to a char pointer and inspecting the pointed-to storage), 
    but must be accounted for when conforming to extrnally-imposed 
    storage layouts.

Re: type based aliasing again

[Ross Morgan-Linial]

Date sent:      	Sat, 18 Sep 1999 15:19:05 +0200
From:           	Marc Lehmann <pcg@opengroup.org>
To:             	rmorgan@jetcity.com
Subject:        	Re: type based aliasing again

> On Sat, Sep 18, 1999 at 02:49:47AM -0700, Ross Morgan-Linial <rmorgan@jetcity.com> wrote:
> >     alloc must ensure (in a machine-dependent way) that its return 
> >     value is suitable for conversion to a pointer to double; then the 
> >     _use_ of the function is portable.
> > 
> > That seems to imply that it's okay to use a pointer pointing to an 
> > object of different type as long as it's suitably aligned. Of course, 
> > I'm hardly an expert on K&R C.
> 
> Use yes (copy, cast), but not dereference. This only means you can
> (temporarily) cast a pointer into some other datatype (as supported by the
> language, e.g. a long), and after casting back you can dereference it. You
> can not, however, use the long (or a pointer to a different type) and
> dereference a different type using it.

Actually, the sentence I thought implied it was this one:

    The resulting pointer may cause addressing exceptions upon use if 
    the subject pointer does not refer to an object suitably aligned 
    in storage.

I don't see why the part about alignment would be there if _any_ use 
of a pointer to data of the wrong type was bad. Sorry I wasn't clear.

Another argument for guessing K&R allowed access though arbitary 
pointers is that there is no exception for char *, so if it wasn't 
allowed memcpy-type functions would be impossible.

However, I just noticed that appendix A, section 16 seems to 
disallow, or at least discourage, this (and also provides a good 
short name for using a mistyped pointer):

    Some difficulties arise only when dubious coding practices are 
    used. It is exceedingly unwise to write programs that depend on 
    any of these properties.
    ...
    Fields are assigned to words and characters to integers right-to-
    left on the PDP-11 and left-to-right on other machines. These 
    differences are invisible to isolated programs which do not 
    indulge in type punning (for example, by converting an int 
    pointer to a char pointer and inspecting the pointed-to storage), 
    but must be accounted for when conforming to extrnally-imposed 
    storage layouts.

Re: type based aliasing again

[Ross Morgan-Linial]

> Not in this respect, apparently.  Nobody has, to my knowledge,
> proposed that -traditional imply -fno-alias-analysis, which suggests
> K&R I indeed, as has been reported, left this behavior undefined.

Well, a quick flip through my copy reveals what look to me like 
contradictory statements. In chapter 5 (pointers and arrays) it says

    You should also note the implication of the declaration that a 
    pointer is constrained to point to a particular type of object.

Now, that appears to say that playing games with pointers is right 
out. However, in appendix A (C reference manual), section 14.4, it 
says

    A pointer to one type may be converted to a pointer to another 
    type. The resulting pointer may cause addressing exceptions upon 
    use if the subject pointer does not refer to an object suitably 
    aligned in storage. It is guaranteed that a pointer to an object 
    of a given size may be converted to a pointer to an object of a 
    smaller size and back again without change.

    For example, a storage-allocation routine might accept a size (in 
    bytes) of an object to allocate, and return a char pointer; it 
    might by used in this way.

        extern char *alloc();
        double *dp;
        dp = (double *) alloc(sizeof(double));
        *dp = 22.0 / 7.0;

    alloc must ensure (in a machine-dependent way) that its return 
    value is suitable for conversion to a pointer to double; then the 
    _use_ of the function is portable.

That seems to imply that it's okay to use a pointer pointing to an 
object of different type as long as it's suitably aligned. Of course, 
I'm hardly an expert on K&R C.

Re: type based aliasing again

[Harvey J. Stein]

I'd like to chip in my 2 cents on this thread by stating my support
for Richard Stallman's proposal wrt gcc's alias analysis &
optimization.

There's a lot of legacy code & even more code written by users not
intimately versed in the latest ANSI standards and its ramifications.
Not to mention the massive amount of third party code that needs to be
compiled & supported by people.  Forcibly breaking it with the next
gcc release will render gcc unusable for many people.  I've seen
recent versions of gcc break code we have here that we can't fix
directly for a number of reasons.  One example is code generated by
p2c where the pascal is still actively mantained, and no one has both
the
time and knowledge here to modify p2c to generate code which conforms
to strict ANSI semantics.

gcc has never intentially miscompiled code because it's not portable.
It's also never forced people to write portable code.  In fact, there
are plenty of enhancements that GCC supports which don't conform to
any standards.  It seems byzantine to break code not conforming to one
particular paragraph of the ANSI standard while allowing all sorts of
other deviations from the standard.  Especially when this is done
solely for the purpose of better optimization.  Even more so when it
need not be done.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[Harvey J. Stein]

I'd like to chip in my 2 cents on this thread by stating my support
for Richard Stallman's proposal wrt gcc's alias analysis &
optimization.

There's a lot of legacy code & even more code written by users not
intimately versed in the latest ANSI standards and its ramifications.
Not to mention the massive amount of third party code that needs to be
compiled & supported by people.  Forcibly breaking it with the next
gcc release will render gcc unusable for many people.  I've seen
recent versions of gcc break code we have here that we can't fix
directly for a number of reasons.  One example is code generated by
p2c where the pascal is still actively mantained, and no one has both
the
time and knowledge here to modify p2c to generate code which conforms
to strict ANSI semantics.

gcc has never intentially miscompiled code because it's not portable.
It's also never forced people to write portable code.  In fact, there
are plenty of enhancements that GCC supports which don't conform to
any standards.  It seems byzantine to break code not conforming to one
particular paragraph of the ANSI standard while allowing all sorts of
other deviations from the standard.  Especially when this is done
solely for the purpose of better optimization.  Even more so when it
need not be done.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il

Re: type based aliasing again

[craig]

[back to gcc list, where it belongs, not in private email]

>> >  However, this change is one that can affect the correctness of the users
>> > code.
>> 
>> No.  It is correct to say "this change is one that can expose the
>> incorrectness of the user's code".
>
>This statement implies that the code, as written, has *always*
>been incorrect.

Exactly.

>I believe this is a false premise.  Standards change.

Not in this respect, apparently.  Nobody has, to my knowledge, proposed
that -traditional imply -fno-alias-analysis, which suggests K&R I
indeed, as has been reported, left this behavior undefined.

>As such, it
>would probably be valid to say, "using this compiler on that code
>is incorrect", but to say that the code is, itself, incorrect is
>as improper as saying, "The GCC 2.95.1 C compiler does not compile my
>K&R C program correctly, therefore, GCC C is incorrect".

No, not in this case.  Not even if the behavior was implementation-
defined, and GCC changed its definition (and, of course, documented
the change).

>And, in fact, that appears to be the response given to the Linux
>kernel developers: "Continue to use GCC 2.7.2 if you are not
>willing to change your code to conform to the new standard, and
>if you are unwilling to set the proper switch".

I doubt you have quoted any email from a GCC developer *precisely*,
particularly in regard to the word "new" in "new standard".

Remove "new", and the statement seems pretty correct (perhaps also
change "switch" to "switches").

The resulting statement is not equivalent to the other quote
you made up.

>It might make for less heat and flame if everybody in this discussion
>simply acknowledged that neither the source, nor the compiler is to
>blame: both the compiler and the source code are correct, it is simply
>the action of mixing incompatible pieces that is inadvisable.

Again, not correct in this case....

>Which, I believe, is what RMS was trying to suggest earlier in his
>gentle reminder of "traditional GCC mailing list" nomenclature.

No, he wasn't.  The only suggestions on the table involve issuing
warnings when code can easily be determined to *appear* to have this
bug, and making -fno-alias-analysis (which works *around* the bug)
the default for some, or perhaps all, optimization levels.

(Well, there are *my* suggestions, which were rather unique.)

But the bug is in the user code being compiled, not in GCC.  Period.
There's *no* credible disagreement on that.

>> The *developer* of the *code* already got fair warning, or else is a
>> dunce who shouldn't be allowed anywhere near a computer, especially
>> not as a programmer.  Only people who understand, or at least accept,
>> the fact that re-compiling their code can legitimately change the apparent
>> behavior of their code should be allowed to represent themselves
>> as programmers in languages requiring compilation (or even interpretation).
>
>With the caveat (of course) that behaviour should not change so long
>as the code conforms to the standard that the compiler purportedly
>conforms to, right?

Incorrect.  See "implementation-defined".  When you change implementations,
which can include switching to a new version, you can change behaviors.

If you want your code to behave the same way no matter when or how
you compile it, see Java.  And even that won't completely fit
that description, IMUO.  (`U' == `Uninformed', regarding Java
specifically.  Of course, I believe I'm plenty informed about
the relevant issues, such that the issues of how Java itself
attempts to meet the "write once, run many" promise, as interpreted
by some programmers anyway, are irrelevant to my analysis.  It's
about as likely as a perpetual-motion machine -- does a physicist
really need to see the details of such a machine to make a good
guess as to the veracity of the claim?)

>As far as I can tell, GCC 2.95.1 has enough other bugs, bugs where it
>does *not* correctly compile, that I consider this discussion somewhat
>a waste of time . . .

Hallelujah.  I think maybe you're the only other person to say that
besides me.  I've been saying it for months now.  (I have this vague
recollection of having had this point echoed by maybe one other person
as well, but am not sure.)

>The simple rule is:
>
>Don't use GCC C 2.95.1 on code that does not conform to the
>C standard that GCC C 2.95.1 follows (+ GCC extensions
>of course).  Unless you bring that code into
>conformance, first, of course.

Right.  That's what the docs for GCC already say, or at least
should say, or at least imply, especially vis-a-vis warnings
about using -fno-alias-analysis.

>'Course, documentation clarifying the changes is necesary, from
>release to release.  But that documentation, if correct and complete,
>plus warnings where and if appropriate, should be considered sufficient.

Yup.

>> Now, what *users* expect is a whole 'nother can of worms.  If users
>> need fair warning that a program might not work because they use a
>> different compiler on it, then that warning must come from the
>> developers of that *program*, not the compiler.
>
>I tend to disagree, here.  When the standard changes, the reasonable
>response is to provide errors or warnings when code (that was correct
>for the previous versions of the standard) is encountered in a compiler
>that conforms to a new standard.  Break that code, bend it, what
>ever, so long as some kind of warning or error is issued.
>
>Unless by "user" you mean somebody other than the person who uses
>the compiler . . . ?

"Use" is overloaded to the point of ambiguity here.

Simple example: I write program jcb-sing, distribute it in source form
as C source jcb-sing.c and Makefile.  The latter causes "gcc -O2 jcb-sing.c"
to be invoked by default.

Now, as the *programmer*, it is *my* responsibility to get the C code
and the Makefile right.

But, what some people have been saying here is that GCC must conform
to the expectations of *users*, by which they mean that any random
person who downloads my package and types "make" is a *user* of GCC
who has no expertise or other ability to know that jcb-sing.c actually
is buggy and thus requires -fno-alias-analysis to be specified to
compile to working form.

That's simply wrong.  It is still *my* responsibility to fix jcb-sing.c
*as well as* Makefile to do the right thing, vis-a-vis new versions
of GCC that might be installed.

Now, if I decide I'll support only GCC 2.7.2 or 2.8.1, fine, then
I can document that, or try "gcc -V 2.8.1 -O2 jcb-sing.c" in the
Makefile (not that I am really suggesting that), or whatever.

But it's *my* responsibility as a vendor of a free-software tool
to make it work for any conforming C compiler support GNU CC extensions
that compiles my code without error.  The aliasing bugs in the code
are *my* bugs, not examples of GCC compiling it erroneously.

It is not in any way the responsibility of the GCC development team
to make sure I don't have to actively maintain *my* software just
so users will magically get the right overall behavior.  Achieving
that is, frankly, a pipe dream, and every engineer worth his salt
understands why: because, without agreed-upon specifications as to
how components will behave and what their tolerances will be,
there's no way to engineer large, complicated systems made out of
components built by different people at different times and continually
enhanced and fixed *without* encountering such problems.

(Even *with* agreed-upon specifications, it's incredibly hard.)

And, in case anyone was wondering: `biff', that program that tells
you when you've got mail, *vastly* exceeds the threshold set by
my use of the phrase "large, complicated" by the engineering standards
with which I'm passingly familiar.  I.e. I'm not just talking
about million-line applications -- pretty much any piece of software
used on a network-connected computer today meets that definition.

>Right.  Agreed.  Totally.  If a programmer believes that "Patterns"
>or "Methodologies" or "Software Engineering Principles" are
>"silver bullets" (or some other disparaging term that implies
>such things are ivory tower abstractions that "have no place
>in the real world") they should not be using the C language.
>
>Heck, they shouldn't be allowed anywhere near powered machinery
>of any sort what so ever.

One could at least argue they shouldn't be programming (for others
anyway) at all, but I used to say stuff like that, and, looking back,
I realize that...well, come to think of it, I shouldn't have been
programming for other people at all!  But how else to learn?  ;-)

>C requires a huge amount of discipline to use correctly, and well.

Perhaps.  Anyone who agrees with that should pause and consider
this: C++ is to C what the space shuttle is to a paper airplane.
(Okay, I'm exaggerating...a *bit*.  ;-)

>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

No, they just weren't so widely exploited by compilers.

>I can live with warnings changing.  I find it irritating to have
>to deal with silent change or breakage when it would have been
>possible to warn me about it.

I think everyone agrees with that.

>I believe that if you clarified the discussion by indicating that
>you acknowledge that the compiler user's code is *correct*, but
>pointed out that it is not correct and valid behaviour to compile
>*that* code with *this* compiler, you'd be able to resolve this.

No, I was specifying something decidedly, if only "just barely",
different: that a programmer maintaining code with this alias
bug is *the* one responsible for either *fixing* the code, *or*
taking responsibility for specifying exactly what compiler(s)
users should use that he believes do *not* happen to expose the
bugs in his code.

E.g. Linux developers have told users to use 2.7.2 or whatever
to compile Linux because of known bugs in *their code*, on the
theory (which I assume has yet to be unproved) that 2.7.2 doesn't
happen to expose those bugs.  But they've been told there is
*potential* for those bugs to be exposed, just latently (i.e. the
bad code could be running in those Linux kernels today, but just has
never been triggered, or happens to produce correct results anyway).

(I don't know offhand, and so don't want to discuss, whether these
were bugs that were easy to avoid by reading the docs, 'cause I
think they weren't...though I think they were easy to avoid by writing
to the ISO C, or an earlier, standard, i.e. I think the bug had
to do with relying on *very*-GCC-specific extensions.)

>Short and Sweet: "Evolve, or get rm'ed!" :-)

I've been thinking today about how this is really a black-box vs.
white-box problem, in the context of the larger issue of engineering.

When building a system out of components, treating each component
as a black box is a simplifying assumption.  I.e. taking each
component on its own *published* terms, and not relying on observed
or internal behavior, actually makes the job of putting together
the whole system *easier*, because the specification for the *published*
behavior of a black box is almost *always* simpler than that for
the behavior of that same box treated as a white box.  (In this
case, the complexity of GCC far exceeds that of ISO C itself,
from the point of view of a programmer writing ISO C code.  So
as soon as that programmer strays outside ISO C into GCC-specific
behavior, the complexity of the task he's undertaking goes *way*
up, even if he sees a modest reduction in the complexity of the
*code* he writes.)

Another way to simplify, or reduce the risks of failure, is to
minimize the combination of the number of components and their
complexity vis-a-vis the system.  (That last phrase means, essentially,
if you depend on only a few published aspects of a black box,
then the fact that it's incredibly complicated internally doesn't
add to the complexity of *your* effort nearly as much as if you use
a component only half as *internally* complex, but use it as a *white*
box, since, in the latter case, you are exposing all that complexity
to your entire project.)

So, the things a good engineer would do when designing, say,
my jcb-sing program include (in *roughly* descending order of
importance, but definitely not completely partitioned that way):

  -  Minimize the number of components.

  -  Rely as much as possible on only the published, black-box behavior
     of components.

  -  Choose components with the simplest *needed* severable behaviors.
     (E.g. since GCC's __asm__ facility is severable from its other
     C constructs, programmers who avoid it need not take it into
     account vis-a-vis this particular item...but see the next!)

  -  Choose components with the simplest *white-box* (internal)
     behaviors.

To the extent this is well-done, the project can tolerate replacement
and upgrade of components, as well as debugging of problems, since
there's more of an opportunity to find a smoking gun in terms of
which component (or connecting tissue, itself a component) is failing.

Going back to my jcb-sing example, among the components I include in
it, or rely upon when using it, are:

  -  A GNU C compiler

  -  A chunk of C code

  -  The ISO C standard

  -  A Makefile

  -  A `make' program

  -  Some shell scripts within the Makefile

  -  A shell

  -  An operating system

  -  Documentation

You get the idea, lots of stuff.

If I allow bugs in my code on the grounds that I can make GCC "cope"
using an option, then I increase the "whiteness", or translucency,
of the GNU C compiler component.  Right there, that increases complexity.
So, replacing GCC with a much earlier, or much later, version
can break things, if that version doesn't support that option.

But, moreso, leaving my code in a buggy state increases *its*
complexity as well, since that code is not ISO C, which means
anyone working on it besides me (in the sense that I, too,
am a "component" of the system and thus might be replaced or
upgraded ;-) has *more* complexity to deal with, because just
knowing ISO C, an off-the-shelf component, is not enough to
understand the code.

If it's important for me to freeze the behavior of my code, I can
ship it as assembler instead of C, which makes some for some
simplification at the expense of some component replacement (OS,
architecture, etc.), or in addition to C, which increases
complexity due to providing two versions and whatever logic
is used to select between them.

Or, I could write my code in Perl, or UNIX `sh', and avoid all
sorts of C-related problems.  That simplifies in some way,
but can add complexity in others (e.g. interpreted languages
rarely have as good static analyzers available for them as
compiled languages -- witness how many more "obvious" typos and
thinkos are found CVS'ed into GCC's configury -- shell-script/Makefile
combinations -- compared to its C code, taking into account
the relative sizes).  In particular, using `sh' might make
it *harder* for me to spot a problem that'll show up only
on some *other* system's `sh', whereas GCC actually can help
find such problems before they happen (e.g. uninitialized-variable
detection has this effect).

Now, if that explains my overall thinking clearly enough, perhaps
you can see why I positively *discourage*, and don't mind GCC
*itself* discouraging, programmers viewing GCC as a white box
rather than a black box.

Yes, the advantages of always having source can be leveraged
such that *every* component we used can be treated in white-box
fashion when we put components together into larger ones.

But, the lessons of engineering include, to me, that even when
one *can* treat components as white boxes, one should *not* do
so, if one wishes to engineer a solid overall product.

(Of course, for unit and system testing, it is entirely reasonable
to strategize and prepare tests based on white-box analyses of
the components.  This is something the proprietary software
industry can *never* offer its users, of course, who can legally
go no farther than gray-box testing, where they *guess* at how
the proprietary components are probably implemented, and try
to break it at the guessed-at seams.  Of course, gray-box testing
is a good idea for free software as well.)

So, when I hear people say "GCC should default to -fno-alias-analysis",
I *basically* hear them as if they're complaining about code that
either isn't important enough to have been engineered in the first
place, or isn't actively maintained but is still actively used *and*
recompiled, despite awareness that it is no longer maintained.  (Even
a user just using a downloaded source package has a responsibility to
check back at the FTP site on occasion for upgrades/fixes/etc.  Again,
if that user doesn't do that, he's not on the engineering level, so
we shouldn't worry much about how to make his hacker life comfy at
the expense of meeting the needs for engineers to have a simpler GCC.)

In both cases, I tend to think "why should we increase GCC's complexity
to address cases that either don't matter or are time-bombs waiting
to explode anyway?"

Yes, I can see *some* rays of light shining through those dark views of
the request for features, but that *is* the fundamental template
through which I now, as a more experienced software developer,
view these requests.  (I.e. there are some cases I can imagine
where accommodating these sorts of requests make sense.  As the
sole developer of g77, it was easy for me to make those decisions;
it's obviously vastly harder here in GCC-land, so it's not unreasonable
to declare that these issues will no longer be discussed, and that
GCC is no longer to be assumed a warning generator, since that'd
be a simplifying assumption consistent with the core engineering
function of GCC.)

Because remember: when you ask for a black-box product to adopt
behaviors that are white-box-like (which includes many compiler
warnings, especially these), you ask for an *increase* in the
complexity visible to end users, who *will* see those behaviors
as if they were black-box-like, and in the *internal* complexity
as well.

The increase in complexity users perceive as black-box like
can contribute to unnecessary increases in the complexity
of their projects, since one of the component's apparent
black-box behavior has now gotten more complex.

Even if you ignore that increase, the increase in internal,
white-box complexity works against *everyone* who uses that
component (GCC, in this case) in their project, *regardless*
of whether they can or will make use of that new behavior.
(That's the fourth item in my list of things to minimize,
above.)

That's why, given all the heat and light over this issue,
I'm not convinced that even the proposed *warning* is a good
idea -- because the added complexity in GCC causes *everybody*
who uses GCC to suffer an automatic increase in the risks
of success of *their* project, because it increases the likelihood
of GCC failing them as a component.

(As I said earlier, an example of a mitigating factor here is
the capture of more code that many users test against GCC using
its default options, e.g. because they gain confidence that
warning-free code isn't hitting this "awful new GCC behavior",
even if it is, or because they applaud our adding the warning
by fixing their broken code.  That extra testing can contribute
to reducing the bugginess of GCC.  It's even possible it'll
contribute to an effort, in fixing bugs the extra testing finds,
to *simplify* GCC in a way that it otherwise wouldn't have been.
Note how *unlikely* each of these positives is likely to be,
compared to the previous...but they *are* possible, and not
to be totally dismissed.)

Now, to people who say "forget all the engineering BS, I just
want to get real work done", I say, fine, you don't want to
do engineering?  Then be happy with the fact that some version
of GCC happened to compile your code so it worked at a given
moment.

And when it stops working, you, as someone who doesn't care
about engineering, can only say "oh well", and either fix it,
or just put up with it, or hire somebody who'll fix it.

The central hypocrisy of much of this thread (*not* jstevens here,
I must stress!) is that some people want to insist that GCC behave
*as if* it is perfectly engineered -- works the same way all
the time in any project in which its used, despite being upgraded,
enhanced, and fixed -- but *refuse* to acknowledge, or recognize,
the responsibility *we*, as GCC *developers*, have to exercise
some engineering methodologies to make GCC actually *work*.

In short: if you care about engineering, you don't mindlessly complain
about GCC not issuing warnings (though you might complain on other,
more legitimate, grounds, related to engineering), you might not
even complain if GCC didn't *have* a -fno-alias-analysis option,
but you *certainly* don't complain that it defaults to -falias-analysis.
(Not as a *user* of GCC, that is; GCC *developers* have their
own agendas, of course, as it is their job to set the parameters
of the box they're building.  So David Edelsohn saying "let's change
the default" is okay in lots of ways that Linus Torvalds saying it
is not.  The latter is merely a request, which can be legitimately
hand-waved aside as not pertaining sufficiently to the core mission of GCC
to even discuss, users not having the *responsibility* to set the
parameters of the GCC "box".  The former could reflect an opinion
that, in this case, increasing the complexity of the GCC box could,
in the long run, lead to more testing.  That's why developers should
*listen* to users, but not always *accommodate* them, if they
intend to build something that works.)

If you *don't* care about engineering, then you have no business
complaining that GCC should accommodate broken code either, since
that code is either *hacked* (and thus will always need fixing as
components change around it) or *engineered* (in which case it *must*
be fixed).

(If there's a category of programming other than "hacking" or "engineering",
other than the obvious one -- "incompetent" -- I'm sorry to not
be able to think of it right now and factor that into those opinions.)

>> So I can see why a few people might think even a warning is likely
>> to constitute just another new minefield for GCC developers to
>> have to march through in another year or two.
>
>That one I don't get.  How can a warning of incorrect code become
>a "minefield"?

When people treat GCC not issuing the exact same warnings given
the exact same code from one version to next as yet another case
of GCC "breaking" their code -- since it'll require them to
go "fix" their code, or turn off the warning, just like the
current situation does.

Simply put: give 'em an inch, and they'll take a mile.  (As the
*current* discussion already proves, I think, vis-a-vis earlier
discussions over the years.)

So we someday change how alias analysis works, turning on more
optimizations.  Let's say that has two effects: some previously
legit warnings stop being issued, and some previously unwarned-about
constructs start being "miscompiled" -- i.e. exposed as the bugs
they always have been -- due to adding new optimizations that
the bulk of users require as *default* (for -O1) to get any
decent performance on some popular new machine (which could even
be a Pentium IV, in theory anyway).

Does anyone really think users *then* will accept the resulting
lack of warnings about bugs in their code any more than they'll
accept the present situation?

Yet that scenario is not only likely, it's two inches short a mile
into inevitable, especially the latter part of it.  (The former
would happen if we re-designed the compiler in certain areas, I
assume, which we might not do in the process of adding the new
optimization.)

If we don't want to impose that kind of minefield on the GCC developers
of tomorrow, the quickest, and perhaps kindest, way to do that is to
let the horse die by the side of the road -- by not providing any
option at this time.

(Maybe *the* kindest is to shoot the horse -- i.e. remove any and
all support for -fno-alias-analysis in GCC 3, 2.96, or even 2.95.2.
Take the screaming for a few months, after which people who don't
simply crawl away recover from the shock of having to fix their
code and simply do it...learning the hard way to *never* write
code like that again.)

>As for avoiding the issue by adding warnings: I agree.  You will not
>avoid this issue by adding warnings.  But you can, I trust, see
>how the warnings are necesary?

No, warnings are never necessary for a compiler to emit, unless
that is required by the pertinent standards and specifications.

GCC emitting warnings is a quality-of-implementation issue, and
thus should *only* be done when the advantages of issuing the
warnings *greatly* overwhelms the disadvantages of added complexity
to GCC to support the warnings.

>I may inherit a body of code that I do not *know* is
>non-conformant . . . I would appreciate it if the compiler, when run
>on that code, informed me that the code was non-conformant.  That way,
>I could either: 1) Not use that compiler.  2) Actually read the docs :-),
>find the necesary switches, and set them.  3) Modify the code to be
>conformant.

The throw-everything-into-a-single-program mentality led to Emacs
and GCC, as well as most Microsoft products.  I used to support
it as well, but am thoroughly disenchanted with it at this point
(though I have *plenty* of understanding as to why it was a
better approach back in the '70s and '80s than it is today, so
please don't think I'm saying Emacs and GCC were necessarily bad
designs as products...as I type this in using Emacs.)

I.e. what you, as a programmer, should be using to find bugs
in your code are programs that have the *sole* purposes of
finding static, and dynamic, bugs, respectively.

The task of compiling a program (or, say, a version of it "decorated"
with code that finds dynamic bugs) into a high-performance
representation should be done by another, separate, program,
with, itself, *no* responsibility whatsoever to diagnose
bugs in the code being compiled.

Among other things, it should be obvious that the factors
influencing the evolution of each of these separated programs are
vastly different, with pretty much the sole exception of
the language in which the user's pogram is written.  That
imples differing release schedules, different maintenance
teams, even different languages appropriate to the implementation.
All of which would benefit end users (e.g. we would already
have released this new alias warning as a new version of the
static diagnostic program *months* ago, if not earlier).

Think about it this way: if we removed every diagnostic capability
of GCC to completely separate programs, one that did static
analysis and one that added dynamic-analysis code (in the same
language) for compilation by GCC, then GCC itself would probably
be *significantly* simpler, or at least somewhat simpler.

The result?  *Products* which *use* GCC to compile code would
become simpler and thus more reliable.  (Yes, they'd use those
other tools as well, but in different timeframes, so to speak;
the user installing jcb-sing, for example, would see an instance
of the project that includes only reliance on GCC, not on
those analysis tools.  At that level, the simplicity of GCC
would lead to a more robust product.  And discussions like this
would *naturally* be resolved *much* more quickly into where to
assign responsibilities for the various issues.)

I.e. GCC would become a smaller, much blacker, box.  (Perhaps having
no command-line options like -O and such whatever.)  Two or more
other small, black boxes would appear, one using static analysis
to detect problems, another decorating the code to use dynamic
analysis (i.e. a filter to be inserted prior to running GCC itself).

Each being simpler and more-well-defined in purpose and interface,
the task of maintaining, releasing, even documenting the lot would
be somewhat reduced, and using each component in isolation, which
we often do during development at a conceptual level (e.g. "compiling"
when we know we just want warnings/errors; or shipping a script
that compiles code, when we know we *don't* want those being
dealt with, at least not at that particular step), would reduce
the complexity of a *huge* number of free-software projects.

I don't happen to think this particular division of labor is
the *ideal* one -- I have a much-finer-grained system in mind,
actually, because I see other pressing needs to address.  So it's
just an example of what can be accomplished...

...by thinking out from inside the box.  ;-)

Also, there are political downsides to a finer-grained architecture,
as long-time followers of the GCC lists might recall: RTL supported
as an input language for a "separate" back end comes to mind as
a political issue, highlighting some such downsides.

>If GCC simply and silently generates invalid code, that is
>unacceptable (unless the compiler writers can show that detecting
>such errors and issuing warnings is not feasible).

Right.  Ensuring GCC is very unlikely to do that is *supposed* to
be Priority 1 of all of us working on it.  This alias-warning
issue is, comparatively, way down the list.

[...not really written to me per se, but:...]
>You say: "I don't read the docs!"?
>
>To bad for you, then.

Well, strictly speaking, I, too, am bad about reading docs.  I simply
tend to learn faster when first looking at sample code.  E.g. I
put up my own web page by "borrowing" egcs.cygnus.com's .html files --
well, their formatting, but I used the content to learn some things.
Only after I had a working familiarity with HTML did I finally
buy a couple of books, read one of them cover to cover, etc.

And I hardly ever bother reading books on computer architectures
or assembly code anymore, because I can learn it just by reading
the output of GCC on the machine.

But I try to *never* hold anyone else responsible for mistakes
I make by failing to read the documentation.  Especially since I'm
such a supporter of *anyone* who attempts to write documentation,
I want *them* to feel *wanted*!

(Still, I'm fond of failsafe procedures that cause systems
to not enter modes requiring documented expertise to use safely
as soon as they can detect their operation by someone who
has not read the documentation.  GCC doesn't need that for
end users; install scripts intended for use by end users,
and which invoke GCC, probably do, but that's not a GCC problem.)

        tq vm, (burley)

Re: type based aliasing again

[John W. Stevens]

> >This statement implies that the code, as written, has *always*
> >been incorrect.
> 
> Exactly.
> 
> >I believe this is a false premise.  Standards change.
> 
> Not in this respect, apparently.

As I understand it, we are talking about a change that moves a construct
from "undefined" to "incorrect".

IOW, before this kind of optimization was attempted, such code may
not have been legal, but it wasn't illegal, either. . . it was
undefined, right?

If you are saying that such code has always been *defined* as
illegal, then I guess I am really confused . . . as I started
programming back when C was what K&R said it was, and I don't
remember this as being defined as illegal back then.

> Nobody has, to my knowledge, proposed
> that -traditional imply -fno-alias-analysis, which suggests K&R I
> indeed, as has been reported, left this behavior undefined.

Perhaps nobody has proposed that explicitly, and perhaps that is
because people want a compromise: *intelligent* alias analysis
that allows for old code to continue to work, but in some cases,
the optimization can and will occur.

Or, maybe not.

Maybe it's just me! ;->

> The resulting statement is not equivalent to the other quote
> you made up.

I am not making up quotes.  I never claimed to be quoting, I was
paraphrasing.

> But the bug is in the user code being compiled, not in GCC.  Period.
> There's *no* credible disagreement on that.

Excuse, but the point I'm making is: there isn't necesarily a bug
in *either* of them.  It doesn't have to be a yes/no, black/white,
binary kind of thing.

It isn't a mistake to use philips head screws.  It isn't a mistake to
buy a flat head screw driver.  It *is* a mistake to use a flat head
screw driver on a philips head screw.

Of course, I may be misunderstanding the issue, here, as well.

> >With the caveat (of course) that behaviour should not change so long
> >as the code conforms to the standard that the compiler purportedly
> >conforms to, right?
> 
> Incorrect.  See "implementation-defined".  When you change implementations,
> which can include switching to a new version, you can change behaviors.

And, I think, that is where this discussion starts to unravel.  The
weight various groups give to avoiding such changes varies from zero
to very large.

My impression is that your "avoiding implementation dependent change"
priority is near zero, and that in general, you are arguing for this
to be the default GCC philosophy.

Correct me (as I'm sure you will) if my understanding is in error. :-)

> But it's *my* responsibility as a vendor of a free-software tool
> to make it work for any conforming C compiler support GNU CC extensions
> that compiles my code without error.  The aliasing bugs in the code
> are *my* bugs, not examples of GCC compiling it erroneously.

And where we differ is in your use of the term: "bug".  I wouldn't consider
either GCC, or your program, to be buggy.  The act of mixing
incompatible pieces is probably a mistake, though.

> It is not in any way the responsibility of the GCC development team
> to make sure I don't have to actively maintain *my* software just
> so users will magically get the right overall behavior.

And I don't believe that anybody is actually advocating this.

I do see people saying that, in effect, that some kind of compromise
is the best solution when *all* factors are considered.

> >Heck, they shouldn't be allowed anywhere near powered machinery
> >of any sort what so ever.
> 
> One could at least argue they shouldn't be programming (for others
> anyway) at all, but I used to say stuff like that, and, looking back,
> I realize that...well, come to think of it, I shouldn't have been
> programming for other people at all!  But how else to learn?  ;-)

Personally, I don't believe in the "throw them in, let them sink or
swim" approach to learning.

People that *have* to have this environment to learn should not,
at the very least, be allowed to play with anything that might
injure or kill others (learning not to point a loaded gun at
somebody should not be something you learn by trial and error).

> >C requires a huge amount of discipline to use correctly, and well.
> 
> Perhaps.  Anyone who agrees with that should pause and consider
> this: C++ is to C what the space shuttle is to a paper airplane.
> (Okay, I'm exaggerating...a *bit*.  ;-)

Well . . . my personal opinion re: C++ falls into the category:
inflamatory language, which is something I urge you to avoid.

> >Ditto.  As far as I can remember, the aliasing rules are *NEW*, so
> 
> No, they just weren't so widely exploited by compilers.

Which begs the question: did K&R define this behavior as
"buggy"/illegal?  I don't remember ever seeing this as being
defined, explicitly, as illegal.

If so, then you are correct.  If not, I must politely differ with
you.

And yes, there are still very large bodies of code that are,
in general, K&R C and no "higher".

> No, I was specifying something decidedly, if only "just barely",
> different: that a programmer maintaining code with this alias
> bug is *the* one responsible for either *fixing* the code,

I don't disagree that the programmer who is maintaining the code
is responsible, I am simply saying that in some cases, there may
not *be* anybody currently maintaining that code.

IMO, documentation that says, "use this switch", and some reasonable
attempt on the part of the GCC maintainers to make sure that when
that switch (plus whatever other switches are required) is used,
that the compiler generates code that is as close as possible to
that generated by earlier versions, is sufficient.

I am aware of the difficulty involved.  What isn't clear, is just
where to draw the line.

> *or*
> taking responsibility for specifying exactly what compiler(s)
> users should use that he believes do *not* happen to expose the
> bugs in his code.

And here we get back to this concept of: "bug".  Digging out my old
K&R book, and taking a long look, I don't see anything that would
indicate that this kind of code is, in fact, a *BUG*.  Dangerous,
undefined, etc.  But not a bug.

So a good faith effort to conform to earlier definitions of what
the "C" language was, and what a particular construct should do
should not be labeled a "bug", just because the language definition
has changed.

> (I don't know offhand, and so don't want to discuss, whether these
> were bugs that were easy to avoid by reading the docs, 'cause I
> think they weren't...though I think they were easy to avoid by writing
> to the ISO C, or an earlier, standard, i.e. I think the bug had
> to do with relying on *very*-GCC-specific extensions.)

The bugs (as is almost always the case), fell into all four
categories:

1) GCC bugs.
2) Linux source code bugs.
3) Miscommunication bugs.
4) Interface change bugs.

> I've been thinking today about how this is really a black-box vs.
> white-box problem, in the context of the larger issue of engineering.

[Some stuff re: complexity deleted.  Please refer to the original email
 for details.]

> (In this
> case, the complexity of GCC far exceeds that of ISO C itself,
> from the point of view of a programmer writing ISO C code.  So
> as soon as that programmer strays outside ISO C into GCC-specific
> behavior, the complexity of the task he's undertaking goes *way*
> up, even if he sees a modest reduction in the complexity of the
> *code* he writes.)

Not necesarily.  Consider the task of writing an OS kernel that is
supposed to be portable across multiple architechtures.

Adding a few extensions to GCC actually makes the system *less*
complex, because it localizes and minimizes the changes necesary.

In short, the responsibility is semi-atomic, and a good design would
assign this responsibility to GCC.

> [Snippage re: opaque vs. transparent objects.]

Agreed.  But GCC extensions do not make the GCC transparent.  They
simply add interface.

>   -  Minimize the number of components.

Disagree.  It isn't number that counts, it's number of *different*
*types* (classes) of components that count, in combination with
a number of other factors, including object transparency, use
or lack thereof of polymorphism, number of interconnections
(appropriate use of such design patterns as Facade, for example).

And more.

>   -  Rely as much as possible on only the published, black-box behavior
>      of components.

Agreed.  But GCC extensions are, indeed, published black-box behavioral
descriptions.

> To the extent this is well-done, the project can tolerate replacement
> and upgrade of components, as well as debugging of problems, since
> there's more of an opportunity to find a smoking gun in terms of
> which component (or connecting tissue, itself a component) is failing.

This is the basic, underlying assumption in object oriented maintenance.

> If I allow bugs in my code on the grounds that I can make GCC "cope"
> using an option, then I increase the "whiteness", or translucency,
> of the GNU C compiler component.

Disagree.  Instantiation with parameters does not increase the
transparency of the instantiated object.

It does increase the complexity of the interface somewhat, but this
can be controlled by making absolutely sure of your design . . .
IOW, instantiation parameters should be restricted to control
parameters only (IOW, "configuration").

> Right there, that increases complexity.
> So, replacing GCC with a much earlier, or much later, version
> can break things, if that version doesn't support that option.

This breakage should be one way.  Once introduced, a switch
should not be removed.  It may end up doing nothing much later
on (and indeed, there are already examples of this in other
GNU programs/projects/tools/systems).  But a switch (a
"control" parameter) should never be removed.

> But, moreso, leaving my code in a buggy state increases *its*
> complexity as well, since that code is not ISO C, which means
> anyone working on it besides me (in the sense that I, too,
> am a "component" of the system and thus might be replaced or
> upgraded ;-) has *more* complexity to deal with, because just
> knowing ISO C, an off-the-shelf component, is not enough to
> understand the code.

Correct.  This is an inescapable result of growth . . . as things
grow, they grow more complex.

Arguing against adding *unnecesary* complexity is entirely reasonable
and correct.  The question at hand is: is the addition of the
complexity currently under discussion worth it (eg, reasonable)?

> Now, if that explains my overall thinking clearly enough, perhaps
> you can see why I positively *discourage*, and don't mind GCC
> *itself* discouraging, programmers viewing GCC as a white box
> rather than a black box.

And so far, nothing I've seen in this discussion actually
translates into making GCC a white-box object.

Add interface, yes.  But nobody has suggested that you: "open up the
workings of GCC and make it part of the program being compiled".

> So, when I hear people say "GCC should default to -fno-alias-analysis",
> I *basically* hear them as if they're complaining about code that
> either isn't important enough to have been engineered in the first
> place,

This is an unfair and inaccurate characterization.

> In both cases, I tend to think "why should we increase GCC's complexity
> to address cases that either don't matter

This is your opinion.  You are free to state it.  The GCC user (as by
now is abundantly clear) does not share your opinion on what "matters".

A compromise is in order.  A good engineer cares about what his
customers/users care about.

> or are time-bombs waiting
> to explode anyway?"

One could characterize any-and-every software system in existence as
a "time-bomb waiting to explode".

I don't necesarily see that as being productive, though.

> it's obviously vastly harder here in GCC-land, so it's not unreasonable
> to declare that these issues will no longer be discussed, and that
> GCC is no longer to be assumed a warning generator, since that'd
> be a simplifying assumption consistent with the core engineering
> function of GCC.)

This assumption makes GCC a smaller, less complex component . . . at
the cost of making the *whole* system *MUCH* more complex.

Trading a small complexity reduction in one component of a system
for a *large* increase in the complexity of the system as a whole
is not a good engineering decision.

> Because remember: when you ask for a black-box product to adopt
> behaviors that are white-box-like

This statement seems to be based on the false premise that adding
interface, makes an object more transparent (it does not).

> (which includes many compiler
> warnings, especially these),

Compiler warnings are interface (think: return codes if that makes
it any easier).  They may add to the complexity of
the object (the object in question being the GNU C compiler)
but they do not make the object transparent.

> you ask for an *increase* in the
> complexity visible to end users,

No.  I ask for a *decrease* in ambiguity, and an *increase* in the
specificity and the total amount of "dialog".

The success of the GUI simply proves what has been known for a
very long time: dialog is better than monologue, and monologue
is better than no communications what-so-ever.

> Now, to people who say "forget all the engineering BS, I just
> want to get real work done", I say, fine, you don't want to
> do engineering?  Then be happy with the fact that some version
> of GCC happened to compile your code so it worked at a given
> moment.

That last is a basic truth . . . because no matter how hard you
try, no compiler will ever be 100% ISO C compliant except by 
the most improbable and unlikely intervention of pure luck.

> The central hypocrisy of much of this thread (*not* jstevens here,
> I must stress!) is that some people want to insist that GCC behave
> *as if* it is perfectly engineered -- works the same way all
> the time in any project in which its used, despite being upgraded,
> enhanced, and fixed -- but *refuse* to acknowledge, or recognize,
> the responsibility *we*, as GCC *developers*, have to exercise
> some engineering methodologies to make GCC actually *work*.

Obviously GCC must change.  And these changes should, when consistent
with the goals of the GNU project, be compliant with existing standards.

Just as obviously, some changes will break old code.  Perfect backwards
compatibility is impossible when change is also occurring.

The issue at hand isn't black and white, though.  The issue is: how
to reduce the total complexity of the system.  And this system is
more than just GCC.

It is (the following list is no where near complete): GCC, GCC users,
GCC maintainers, the body of existing code out there that might/must
be compiled with GCC.

As time goes by, and the very oldest code slowly "fades away", some
of the old support structures can be removed.

> In short: if you care about engineering, you don't mindlessly complain
> about GCC not issuing warnings

And, as stated above, I disagree with your assessment re: warnings
and complexity.

If, to understand a warning, you have to "pop the hood" and dig into
GCC source code, then I would agree with you.  But a simple warning,
issued by the compiler in situations that indicate a program may
possibly be non-conformant, actually *decreases* the complexity of
the system as a whole.

The above statement is dependent on where you draw the boundaries of
"the system", of course.

> If you *don't* care about engineering, then you have no business
> complaining that GCC should accommodate broken code either, since
> that code is either *hacked* (and thus will always need fixing as
> components change around it) or *engineered* (in which case it *must*
> be fixed).

And here in lies the very core of this disagreement: you seem to miss
other, valid interpretations, such as:

The code *WAS* engineered, but either the language definition, or
the compiler, changed *AND* it is far to expensive to change all of the
code to match the new definition or compiler at this time, *BUT*
the new compiler *MUST* be used.

Obviously, some of the people who are complaining,
could simply continue to use the old compiler . . . and probably
should.

Others should simply set the proper switches.

And yet others should do as you recommend: change their code.

> When people treat GCC not issuing the exact same warnings given
> the exact same code from one version to next as yet another case
> of GCC "breaking" their code

This, I would agree, is unreasonable, and fits within the range
of "implementation defined behaviors" that a user must expect to
change . . . with the caveat that there should be a good reason
for the change, and that reason should be communicated to the user.

> Simply put: give 'em an inch, and they'll take a mile.

A trifle hostile, that.  And not generally applicable, either.

Bringing us back to: inflamatory language. ;->

> Does anyone really think users *then* will accept the resulting
> lack of warnings about bugs in their code any more than they'll
> accept the present situation?

Probably not.  And rightfully so, especially if no warning of
any kind was given about this change.  Unavoidable change is
unavoidable change.  But not taking *any* care re: avoiding
unnecesary-and-avoidable-interface-changes is *VERY* poor
engineering.

> (Maybe *the* kindest is to shoot the horse -- i.e. remove any and
> all support for -fno-alias-analysis in GCC 3, 2.96, or even 2.95.2.

Which begs the question: just how interested are the GCC maintainers
in whether or not they have any users?  In how satisfied their users
are in the product?  In how the product is viewed by potential users?

> >As for avoiding the issue by adding warnings: I agree.  You will not
> >avoid this issue by adding warnings.  But you can, I trust, see
> >how the warnings are necesary?
> 
> No, warnings are never necessary for a compiler to emit,

Wrong.  Warnings are absolutely required under the principle of
"communicate".

The most basic, most important facet of human factors engineering
is: talk to the user.  The second is: avoid surprise.

This (talk!) is in fact the root of the success of the GUI: the GUI
is a system that implements a (mostly) static dialog . . .
which is immensely better than no communication at all, when
dealing with human beings.

> GCC emitting warnings is a quality-of-implementation issue,

No, it's a human factors issue (which may be included under
quality-of-implementation [QOI], depending on how you define QOI).

> and
> thus should *only* be done when the advantages of issuing the
> warnings *greatly* overwhelms the disadvantages of added complexity
> to GCC to support the warnings.

Warnings should be issued *even* *if* adding them increases internal
complexity of the object.

The least complex object is that which has no interface at all, but
that object is hardly useful, now is it?

> The throw-everything-into-a-single-program mentality

Warnings do not fall into that category.  Warnings are analogous
to return codes from functions that do input parameter checking.

> I.e. what you, as a programmer, should be using to find bugs
> in your code are programs that have the *sole* purposes of
> finding static, and dynamic, bugs, respectively.

Wrong.  Since it is the responsibility of the compiler to define
proper-and-appropriate (since the standard allows for: implementation
defined, as well as undefined), therefore it is the responsibility
of that object (the compiler), to communicate this knowledge to
the user.

Now, the current "compiler" is already an aggregate, and if you
are suggesting that different objects have different responsibilities,
and therefore are responsible for generating different classes of
warnings, then I suspect everybody would agree with you.

If you are suggesting that GCC should not produce diagnostics
at all, I suspect that very few people would agree with you.

The reasonable course lies somewhere in the middle.

John S.

Re: type based aliasing again

[John W. Stevens]

> >This statement implies that the code, as written, has *always*
> >been incorrect.
> 
> Exactly.
> 
> >I believe this is a false premise.  Standards change.
> 
> Not in this respect, apparently.

As I understand it, we are talking about a change that moves a construct
from "undefined" to "incorrect".

IOW, before this kind of optimization was attempted, such code may
not have been legal, but it wasn't illegal, either. . . it was
undefined, right?

If you are saying that such code has always been *defined* as
illegal, then I guess I am really confused . . . as I started
programming back when C was what K&R said it was, and I don't
remember this as being defined as illegal back then.

> Nobody has, to my knowledge, proposed
> that -traditional imply -fno-alias-analysis, which suggests K&R I
> indeed, as has been reported, left this behavior undefined.

Perhaps nobody has proposed that explicitly, and perhaps that is
because people want a compromise: *intelligent* alias analysis
that allows for old code to continue to work, but in some cases,
the optimization can and will occur.

Or, maybe not.

Maybe it's just me! ;->

> The resulting statement is not equivalent to the other quote
> you made up.

I am not making up quotes.  I never claimed to be quoting, I was
paraphrasing.

> But the bug is in the user code being compiled, not in GCC.  Period.
> There's *no* credible disagreement on that.

Excuse, but the point I'm making is: there isn't necesarily a bug
in *either* of them.  It doesn't have to be a yes/no, black/white,
binary kind of thing.

It isn't a mistake to use philips head screws.  It isn't a mistake to
buy a flat head screw driver.  It *is* a mistake to use a flat head
screw driver on a philips head screw.

Of course, I may be misunderstanding the issue, here, as well.

> >With the caveat (of course) that behaviour should not change so long
> >as the code conforms to the standard that the compiler purportedly
> >conforms to, right?
> 
> Incorrect.  See "implementation-defined".  When you change implementations,
> which can include switching to a new version, you can change behaviors.

And, I think, that is where this discussion starts to unravel.  The
weight various groups give to avoiding such changes varies from zero
to very large.

My impression is that your "avoiding implementation dependent change"
priority is near zero, and that in general, you are arguing for this
to be the default GCC philosophy.

Correct me (as I'm sure you will) if my understanding is in error. :-)

> But it's *my* responsibility as a vendor of a free-software tool
> to make it work for any conforming C compiler support GNU CC extensions
> that compiles my code without error.  The aliasing bugs in the code
> are *my* bugs, not examples of GCC compiling it erroneously.

And where we differ is in your use of the term: "bug".  I wouldn't consider
either GCC, or your program, to be buggy.  The act of mixing
incompatible pieces is probably a mistake, though.

> It is not in any way the responsibility of the GCC development team
> to make sure I don't have to actively maintain *my* software just
> so users will magically get the right overall behavior.

And I don't believe that anybody is actually advocating this.

I do see people saying that, in effect, that some kind of compromise
is the best solution when *all* factors are considered.

> >Heck, they shouldn't be allowed anywhere near powered machinery
> >of any sort what so ever.
> 
> One could at least argue they shouldn't be programming (for others
> anyway) at all, but I used to say stuff like that, and, looking back,
> I realize that...well, come to think of it, I shouldn't have been
> programming for other people at all!  But how else to learn?  ;-)

Personally, I don't believe in the "throw them in, let them sink or
swim" approach to learning.

People that *have* to have this environment to learn should not,
at the very least, be allowed to play with anything that might
injure or kill others (learning not to point a loaded gun at
somebody should not be something you learn by trial and error).

> >C requires a huge amount of discipline to use correctly, and well.
> 
> Perhaps.  Anyone who agrees with that should pause and consider
> this: C++ is to C what the space shuttle is to a paper airplane.
> (Okay, I'm exaggerating...a *bit*.  ;-)

Well . . . my personal opinion re: C++ falls into the category:
inflamatory language, which is something I urge you to avoid.

> >Ditto.  As far as I can remember, the aliasing rules are *NEW*, so
> 
> No, they just weren't so widely exploited by compilers.

Which begs the question: did K&R define this behavior as
"buggy"/illegal?  I don't remember ever seeing this as being
defined, explicitly, as illegal.

If so, then you are correct.  If not, I must politely differ with
you.

And yes, there are still very large bodies of code that are,
in general, K&R C and no "higher".

> No, I was specifying something decidedly, if only "just barely",
> different: that a programmer maintaining code with this alias
> bug is *the* one responsible for either *fixing* the code,

I don't disagree that the programmer who is maintaining the code
is responsible, I am simply saying that in some cases, there may
not *be* anybody currently maintaining that code.

IMO, documentation that says, "use this switch", and some reasonable
attempt on the part of the GCC maintainers to make sure that when
that switch (plus whatever other switches are required) is used,
that the compiler generates code that is as close as possible to
that generated by earlier versions, is sufficient.

I am aware of the difficulty involved.  What isn't clear, is just
where to draw the line.

> *or*
> taking responsibility for specifying exactly what compiler(s)
> users should use that he believes do *not* happen to expose the
> bugs in his code.

And here we get back to this concept of: "bug".  Digging out my old
K&R book, and taking a long look, I don't see anything that would
indicate that this kind of code is, in fact, a *BUG*.  Dangerous,
undefined, etc.  But not a bug.

So a good faith effort to conform to earlier definitions of what
the "C" language was, and what a particular construct should do
should not be labeled a "bug", just because the language definition
has changed.

> (I don't know offhand, and so don't want to discuss, whether these
> were bugs that were easy to avoid by reading the docs, 'cause I
> think they weren't...though I think they were easy to avoid by writing
> to the ISO C, or an earlier, standard, i.e. I think the bug had
> to do with relying on *very*-GCC-specific extensions.)

The bugs (as is almost always the case), fell into all four
categories:

1) GCC bugs.
2) Linux source code bugs.
3) Miscommunication bugs.
4) Interface change bugs.

> I've been thinking today about how this is really a black-box vs.
> white-box problem, in the context of the larger issue of engineering.

[Some stuff re: complexity deleted.  Please refer to the original email
 for details.]

> (In this
> case, the complexity of GCC far exceeds that of ISO C itself,
> from the point of view of a programmer writing ISO C code.  So
> as soon as that programmer strays outside ISO C into GCC-specific
> behavior, the complexity of the task he's undertaking goes *way*
> up, even if he sees a modest reduction in the complexity of the
> *code* he writes.)

Not necesarily.  Consider the task of writing an OS kernel that is
supposed to be portable across multiple architechtures.

Adding a few extensions to GCC actually makes the system *less*
complex, because it localizes and minimizes the changes necesary.

In short, the responsibility is semi-atomic, and a good design would
assign this responsibility to GCC.

> [Snippage re: opaque vs. transparent objects.]

Agreed.  But GCC extensions do not make the GCC transparent.  They
simply add interface.

>   -  Minimize the number of components.

Disagree.  It isn't number that counts, it's number of *different*
*types* (classes) of components that count, in combination with
a number of other factors, including object transparency, use
or lack thereof of polymorphism, number of interconnections
(appropriate use of such design patterns as Facade, for example).

And more.

>   -  Rely as much as possible on only the published, black-box behavior
>      of components.

Agreed.  But GCC extensions are, indeed, published black-box behavioral
descriptions.

> To the extent this is well-done, the project can tolerate replacement
> and upgrade of components, as well as debugging of problems, since
> there's more of an opportunity to find a smoking gun in terms of
> which component (or connecting tissue, itself a component) is failing.

This is the basic, underlying assumption in object oriented maintenance.

> If I allow bugs in my code on the grounds that I can make GCC "cope"
> using an option, then I increase the "whiteness", or translucency,
> of the GNU C compiler component.

Disagree.  Instantiation with parameters does not increase the
transparency of the instantiated object.

It does increase the complexity of the interface somewhat, but this
can be controlled by making absolutely sure of your design . . .
IOW, instantiation parameters should be restricted to control
parameters only (IOW, "configuration").

> Right there, that increases complexity.
> So, replacing GCC with a much earlier, or much later, version
> can break things, if that version doesn't support that option.

This breakage should be one way.  Once introduced, a switch
should not be removed.  It may end up doing nothing much later
on (and indeed, there are already examples of this in other
GNU programs/projects/tools/systems).  But a switch (a
"control" parameter) should never be removed.

> But, moreso, leaving my code in a buggy state increases *its*
> complexity as well, since that code is not ISO C, which means
> anyone working on it besides me (in the sense that I, too,
> am a "component" of the system and thus might be replaced or
> upgraded ;-) has *more* complexity to deal with, because just
> knowing ISO C, an off-the-shelf component, is not enough to
> understand the code.

Correct.  This is an inescapable result of growth . . . as things
grow, they grow more complex.

Arguing against adding *unnecesary* complexity is entirely reasonable
and correct.  The question at hand is: is the addition of the
complexity currently under discussion worth it (eg, reasonable)?

> Now, if that explains my overall thinking clearly enough, perhaps
> you can see why I positively *discourage*, and don't mind GCC
> *itself* discouraging, programmers viewing GCC as a white box
> rather than a black box.

And so far, nothing I've seen in this discussion actually
translates into making GCC a white-box object.

Add interface, yes.  But nobody has suggested that you: "open up the
workings of GCC and make it part of the program being compiled".

> So, when I hear people say "GCC should default to -fno-alias-analysis",
> I *basically* hear them as if they're complaining about code that
> either isn't important enough to have been engineered in the first
> place,

This is an unfair and inaccurate characterization.

> In both cases, I tend to think "why should we increase GCC's complexity
> to address cases that either don't matter

This is your opinion.  You are free to state it.  The GCC user (as by
now is abundantly clear) does not share your opinion on what "matters".

A compromise is in order.  A good engineer cares about what his
customers/users care about.

> or are time-bombs waiting
> to explode anyway?"

One could characterize any-and-every software system in existence as
a "time-bomb waiting to explode".

I don't necesarily see that as being productive, though.

> it's obviously vastly harder here in GCC-land, so it's not unreasonable
> to declare that these issues will no longer be discussed, and that
> GCC is no longer to be assumed a warning generator, since that'd
> be a simplifying assumption consistent with the core engineering
> function of GCC.)

This assumption makes GCC a smaller, less complex component . . . at
the cost of making the *whole* system *MUCH* more complex.

Trading a small complexity reduction in one component of a system
for a *large* increase in the complexity of the system as a whole
is not a good engineering decision.

> Because remember: when you ask for a black-box product to adopt
> behaviors that are white-box-like

This statement seems to be based on the false premise that adding
interface, makes an object more transparent (it does not).

> (which includes many compiler
> warnings, especially these),

Compiler warnings are interface (think: return codes if that makes
it any easier).  They may add to the complexity of
the object (the object in question being the GNU C compiler)
but they do not make the object transparent.

> you ask for an *increase* in the
> complexity visible to end users,

No.  I ask for a *decrease* in ambiguity, and an *increase* in the
specificity and the total amount of "dialog".

The success of the GUI simply proves what has been known for a
very long time: dialog is better than monologue, and monologue
is better than no communications what-so-ever.

> Now, to people who say "forget all the engineering BS, I just
> want to get real work done", I say, fine, you don't want to
> do engineering?  Then be happy with the fact that some version
> of GCC happened to compile your code so it worked at a given
> moment.

That last is a basic truth . . . because no matter how hard you
try, no compiler will ever be 100% ISO C compliant except by 
the most improbable and unlikely intervention of pure luck.

> The central hypocrisy of much of this thread (*not* jstevens here,
> I must stress!) is that some people want to insist that GCC behave
> *as if* it is perfectly engineered -- works the same way all
> the time in any project in which its used, despite being upgraded,
> enhanced, and fixed -- but *refuse* to acknowledge, or recognize,
> the responsibility *we*, as GCC *developers*, have to exercise
> some engineering methodologies to make GCC actually *work*.

Obviously GCC must change.  And these changes should, when consistent
with the goals of the GNU project, be compliant with existing standards.

Just as obviously, some changes will break old code.  Perfect backwards
compatibility is impossible when change is also occurring.

The issue at hand isn't black and white, though.  The issue is: how
to reduce the total complexity of the system.  And this system is
more than just GCC.

It is (the following list is no where near complete): GCC, GCC users,
GCC maintainers, the body of existing code out there that might/must
be compiled with GCC.

As time goes by, and the very oldest code slowly "fades away", some
of the old support structures can be removed.

> In short: if you care about engineering, you don't mindlessly complain
> about GCC not issuing warnings

And, as stated above, I disagree with your assessment re: warnings
and complexity.

If, to understand a warning, you have to "pop the hood" and dig into
GCC source code, then I would agree with you.  But a simple warning,
issued by the compiler in situations that indicate a program may
possibly be non-conformant, actually *decreases* the complexity of
the system as a whole.

The above statement is dependent on where you draw the boundaries of
"the system", of course.

> If you *don't* care about engineering, then you have no business
> complaining that GCC should accommodate broken code either, since
> that code is either *hacked* (and thus will always need fixing as
> components change around it) or *engineered* (in which case it *must*
> be fixed).

And here in lies the very core of this disagreement: you seem to miss
other, valid interpretations, such as:

The code *WAS* engineered, but either the language definition, or
the compiler, changed *AND* it is far to expensive to change all of the
code to match the new definition or compiler at this time, *BUT*
the new compiler *MUST* be used.

Obviously, some of the people who are complaining,
could simply continue to use the old compiler . . . and probably
should.

Others should simply set the proper switches.

And yet others should do as you recommend: change their code.

> When people treat GCC not issuing the exact same warnings given
> the exact same code from one version to next as yet another case
> of GCC "breaking" their code

This, I would agree, is unreasonable, and fits within the range
of "implementation defined behaviors" that a user must expect to
change . . . with the caveat that there should be a good reason
for the change, and that reason should be communicated to the user.

> Simply put: give 'em an inch, and they'll take a mile.

A trifle hostile, that.  And not generally applicable, either.

Bringing us back to: inflamatory language. ;->

> Does anyone really think users *then* will accept the resulting
> lack of warnings about bugs in their code any more than they'll
> accept the present situation?

Probably not.  And rightfully so, especially if no warning of
any kind was given about this change.  Unavoidable change is
unavoidable change.  But not taking *any* care re: avoiding
unnecesary-and-avoidable-interface-changes is *VERY* poor
engineering.

> (Maybe *the* kindest is to shoot the horse -- i.e. remove any and
> all support for -fno-alias-analysis in GCC 3, 2.96, or even 2.95.2.

Which begs the question: just how interested are the GCC maintainers
in whether or not they have any users?  In how satisfied their users
are in the product?  In how the product is viewed by potential users?

> >As for avoiding the issue by adding warnings: I agree.  You will not
> >avoid this issue by adding warnings.  But you can, I trust, see
> >how the warnings are necesary?
> 
> No, warnings are never necessary for a compiler to emit,

Wrong.  Warnings are absolutely required under the principle of
"communicate".

The most basic, most important facet of human factors engineering
is: talk to the user.  The second is: avoid surprise.

This (talk!) is in fact the root of the success of the GUI: the GUI
is a system that implements a (mostly) static dialog . . .
which is immensely better than no communication at all, when
dealing with human beings.

> GCC emitting warnings is a quality-of-implementation issue,

No, it's a human factors issue (which may be included under
quality-of-implementation [QOI], depending on how you define QOI).

> and
> thus should *only* be done when the advantages of issuing the
> warnings *greatly* overwhelms the disadvantages of added complexity
> to GCC to support the warnings.

Warnings should be issued *even* *if* adding them increases internal
complexity of the object.

The least complex object is that which has no interface at all, but
that object is hardly useful, now is it?

> The throw-everything-into-a-single-program mentality

Warnings do not fall into that category.  Warnings are analogous
to return codes from functions that do input parameter checking.

> I.e. what you, as a programmer, should be using to find bugs
> in your code are programs that have the *sole* purposes of
> finding static, and dynamic, bugs, respectively.

Wrong.  Since it is the responsibility of the compiler to define
proper-and-appropriate (since the standard allows for: implementation
defined, as well as undefined), therefore it is the responsibility
of that object (the compiler), to communicate this knowledge to
the user.

Now, the current "compiler" is already an aggregate, and if you
are suggesting that different objects have different responsibilities,
and therefore are responsible for generating different classes of
warnings, then I suspect everybody would agree with you.

If you are suggesting that GCC should not produce diagnostics
at all, I suspect that very few people would agree with you.

The reasonable course lies somewhere in the middle.

John S.

Re: type based aliasing again

[craig]

[back to gcc list, where it belongs, not in private email]

>> >  However, this change is one that can affect the correctness of the users
>> > code.
>> 
>> No.  It is correct to say "this change is one that can expose the
>> incorrectness of the user's code".
>
>This statement implies that the code, as written, has *always*
>been incorrect.

Exactly.

>I believe this is a false premise.  Standards change.

Not in this respect, apparently.  Nobody has, to my knowledge, proposed
that -traditional imply -fno-alias-analysis, which suggests K&R I
indeed, as has been reported, left this behavior undefined.

>As such, it
>would probably be valid to say, "using this compiler on that code
>is incorrect", but to say that the code is, itself, incorrect is
>as improper as saying, "The GCC 2.95.1 C compiler does not compile my
>K&R C program correctly, therefore, GCC C is incorrect".

No, not in this case.  Not even if the behavior was implementation-
defined, and GCC changed its definition (and, of course, documented
the change).

>And, in fact, that appears to be the response given to the Linux
>kernel developers: "Continue to use GCC 2.7.2 if you are not
>willing to change your code to conform to the new standard, and
>if you are unwilling to set the proper switch".

I doubt you have quoted any email from a GCC developer *precisely*,
particularly in regard to the word "new" in "new standard".

Remove "new", and the statement seems pretty correct (perhaps also
change "switch" to "switches").

The resulting statement is not equivalent to the other quote
you made up.

>It might make for less heat and flame if everybody in this discussion
>simply acknowledged that neither the source, nor the compiler is to
>blame: both the compiler and the source code are correct, it is simply
>the action of mixing incompatible pieces that is inadvisable.

Again, not correct in this case....

>Which, I believe, is what RMS was trying to suggest earlier in his
>gentle reminder of "traditional GCC mailing list" nomenclature.

No, he wasn't.  The only suggestions on the table involve issuing
warnings when code can easily be determined to *appear* to have this
bug, and making -fno-alias-analysis (which works *around* the bug)
the default for some, or perhaps all, optimization levels.

(Well, there are *my* suggestions, which were rather unique.)

But the bug is in the user code being compiled, not in GCC.  Period.
There's *no* credible disagreement on that.

>> The *developer* of the *code* already got fair warning, or else is a
>> dunce who shouldn't be allowed anywhere near a computer, especially
>> not as a programmer.  Only people who understand, or at least accept,
>> the fact that re-compiling their code can legitimately change the apparent
>> behavior of their code should be allowed to represent themselves
>> as programmers in languages requiring compilation (or even interpretation).
>
>With the caveat (of course) that behaviour should not change so long
>as the code conforms to the standard that the compiler purportedly
>conforms to, right?

Incorrect.  See "implementation-defined".  When you change implementations,
which can include switching to a new version, you can change behaviors.

If you want your code to behave the same way no matter when or how
you compile it, see Java.  And even that won't completely fit
that description, IMUO.  (`U' == `Uninformed', regarding Java
specifically.  Of course, I believe I'm plenty informed about
the relevant issues, such that the issues of how Java itself
attempts to meet the "write once, run many" promise, as interpreted
by some programmers anyway, are irrelevant to my analysis.  It's
about as likely as a perpetual-motion machine -- does a physicist
really need to see the details of such a machine to make a good
guess as to the veracity of the claim?)

>As far as I can tell, GCC 2.95.1 has enough other bugs, bugs where it
>does *not* correctly compile, that I consider this discussion somewhat
>a waste of time . . .

Hallelujah.  I think maybe you're the only other person to say that
besides me.  I've been saying it for months now.  (I have this vague
recollection of having had this point echoed by maybe one other person
as well, but am not sure.)

>The simple rule is:
>
>Don't use GCC C 2.95.1 on code that does not conform to the
>C standard that GCC C 2.95.1 follows (+ GCC extensions
>of course).  Unless you bring that code into
>conformance, first, of course.

Right.  That's what the docs for GCC already say, or at least
should say, or at least imply, especially vis-a-vis warnings
about using -fno-alias-analysis.

>'Course, documentation clarifying the changes is necesary, from
>release to release.  But that documentation, if correct and complete,
>plus warnings where and if appropriate, should be considered sufficient.

Yup.

>> Now, what *users* expect is a whole 'nother can of worms.  If users
>> need fair warning that a program might not work because they use a
>> different compiler on it, then that warning must come from the
>> developers of that *program*, not the compiler.
>
>I tend to disagree, here.  When the standard changes, the reasonable
>response is to provide errors or warnings when code (that was correct
>for the previous versions of the standard) is encountered in a compiler
>that conforms to a new standard.  Break that code, bend it, what
>ever, so long as some kind of warning or error is issued.
>
>Unless by "user" you mean somebody other than the person who uses
>the compiler . . . ?

"Use" is overloaded to the point of ambiguity here.

Simple example: I write program jcb-sing, distribute it in source form
as C source jcb-sing.c and Makefile.  The latter causes "gcc -O2 jcb-sing.c"
to be invoked by default.

Now, as the *programmer*, it is *my* responsibility to get the C code
and the Makefile right.

But, what some people have been saying here is that GCC must conform
to the expectations of *users*, by which they mean that any random
person who downloads my package and types "make" is a *user* of GCC
who has no expertise or other ability to know that jcb-sing.c actually
is buggy and thus requires -fno-alias-analysis to be specified to
compile to working form.

That's simply wrong.  It is still *my* responsibility to fix jcb-sing.c
*as well as* Makefile to do the right thing, vis-a-vis new versions
of GCC that might be installed.

Now, if I decide I'll support only GCC 2.7.2 or 2.8.1, fine, then
I can document that, or try "gcc -V 2.8.1 -O2 jcb-sing.c" in the
Makefile (not that I am really suggesting that), or whatever.

But it's *my* responsibility as a vendor of a free-software tool
to make it work for any conforming C compiler support GNU CC extensions
that compiles my code without error.  The aliasing bugs in the code
are *my* bugs, not examples of GCC compiling it erroneously.

It is not in any way the responsibility of the GCC development team
to make sure I don't have to actively maintain *my* software just
so users will magically get the right overall behavior.  Achieving
that is, frankly, a pipe dream, and every engineer worth his salt
understands why: because, without agreed-upon specifications as to
how components will behave and what their tolerances will be,
there's no way to engineer large, complicated systems made out of
components built by different people at different times and continually
enhanced and fixed *without* encountering such problems.

(Even *with* agreed-upon specifications, it's incredibly hard.)

And, in case anyone was wondering: `biff', that program that tells
you when you've got mail, *vastly* exceeds the threshold set by
my use of the phrase "large, complicated" by the engineering standards
with which I'm passingly familiar.  I.e. I'm not just talking
about million-line applications -- pretty much any piece of software
used on a network-connected computer today meets that definition.

>Right.  Agreed.  Totally.  If a programmer believes that "Patterns"
>or "Methodologies" or "Software Engineering Principles" are
>"silver bullets" (or some other disparaging term that implies
>such things are ivory tower abstractions that "have no place
>in the real world") they should not be using the C language.
>
>Heck, they shouldn't be allowed anywhere near powered machinery
>of any sort what so ever.

One could at least argue they shouldn't be programming (for others
anyway) at all, but I used to say stuff like that, and, looking back,
I realize that...well, come to think of it, I shouldn't have been
programming for other people at all!  But how else to learn?  ;-)

>C requires a huge amount of discipline to use correctly, and well.

Perhaps.  Anyone who agrees with that should pause and consider
this: C++ is to C what the space shuttle is to a paper airplane.
(Okay, I'm exaggerating...a *bit*.  ;-)

>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

No, they just weren't so widely exploited by compilers.

>I can live with warnings changing.  I find it irritating to have
>to deal with silent change or breakage when it would have been
>possible to warn me about it.

I think everyone agrees with that.

>I believe that if you clarified the discussion by indicating that
>you acknowledge that the compiler user's code is *correct*, but
>pointed out that it is not correct and valid behaviour to compile
>*that* code with *this* compiler, you'd be able to resolve this.

No, I was specifying something decidedly, if only "just barely",
different: that a programmer maintaining code with this alias
bug is *the* one responsible for either *fixing* the code, *or*
taking responsibility for specifying exactly what compiler(s)
users should use that he believes do *not* happen to expose the
bugs in his code.

E.g. Linux developers have told users to use 2.7.2 or whatever
to compile Linux because of known bugs in *their code*, on the
theory (which I assume has yet to be unproved) that 2.7.2 doesn't
happen to expose those bugs.  But they've been told there is
*potential* for those bugs to be exposed, just latently (i.e. the
bad code could be running in those Linux kernels today, but just has
never been triggered, or happens to produce correct results anyway).

(I don't know offhand, and so don't want to discuss, whether these
were bugs that were easy to avoid by reading the docs, 'cause I
think they weren't...though I think they were easy to avoid by writing
to the ISO C, or an earlier, standard, i.e. I think the bug had
to do with relying on *very*-GCC-specific extensions.)

>Short and Sweet: "Evolve, or get rm'ed!" :-)

I've been thinking today about how this is really a black-box vs.
white-box problem, in the context of the larger issue of engineering.

When building a system out of components, treating each component
as a black box is a simplifying assumption.  I.e. taking each
component on its own *published* terms, and not relying on observed
or internal behavior, actually makes the job of putting together
the whole system *easier*, because the specification for the *published*
behavior of a black box is almost *always* simpler than that for
the behavior of that same box treated as a white box.  (In this
case, the complexity of GCC far exceeds that of ISO C itself,
from the point of view of a programmer writing ISO C code.  So
as soon as that programmer strays outside ISO C into GCC-specific
behavior, the complexity of the task he's undertaking goes *way*
up, even if he sees a modest reduction in the complexity of the
*code* he writes.)

Another way to simplify, or reduce the risks of failure, is to
minimize the combination of the number of components and their
complexity vis-a-vis the system.  (That last phrase means, essentially,
if you depend on only a few published aspects of a black box,
then the fact that it's incredibly complicated internally doesn't
add to the complexity of *your* effort nearly as much as if you use
a component only half as *internally* complex, but use it as a *white*
box, since, in the latter case, you are exposing all that complexity
to your entire project.)

So, the things a good engineer would do when designing, say,
my jcb-sing program include (in *roughly* descending order of
importance, but definitely not completely partitioned that way):

  -  Minimize the number of components.

  -  Rely as much as possible on only the published, black-box behavior
     of components.

  -  Choose components with the simplest *needed* severable behaviors.
     (E.g. since GCC's __asm__ facility is severable from its other
     C constructs, programmers who avoid it need not take it into
     account vis-a-vis this particular item...but see the next!)

  -  Choose components with the simplest *white-box* (internal)
     behaviors.

To the extent this is well-done, the project can tolerate replacement
and upgrade of components, as well as debugging of problems, since
there's more of an opportunity to find a smoking gun in terms of
which component (or connecting tissue, itself a component) is failing.

Going back to my jcb-sing example, among the components I include in
it, or rely upon when using it, are:

  -  A GNU C compiler

  -  A chunk of C code

  -  The ISO C standard

  -  A Makefile

  -  A `make' program

  -  Some shell scripts within the Makefile

  -  A shell

  -  An operating system

  -  Documentation

You get the idea, lots of stuff.

If I allow bugs in my code on the grounds that I can make GCC "cope"
using an option, then I increase the "whiteness", or translucency,
of the GNU C compiler component.  Right there, that increases complexity.
So, replacing GCC with a much earlier, or much later, version
can break things, if that version doesn't support that option.

But, moreso, leaving my code in a buggy state increases *its*
complexity as well, since that code is not ISO C, which means
anyone working on it besides me (in the sense that I, too,
am a "component" of the system and thus might be replaced or
upgraded ;-) has *more* complexity to deal with, because just
knowing ISO C, an off-the-shelf component, is not enough to
understand the code.

If it's important for me to freeze the behavior of my code, I can
ship it as assembler instead of C, which makes some for some
simplification at the expense of some component replacement (OS,
architecture, etc.), or in addition to C, which increases
complexity due to providing two versions and whatever logic
is used to select between them.

Or, I could write my code in Perl, or UNIX `sh', and avoid all
sorts of C-related problems.  That simplifies in some way,
but can add complexity in others (e.g. interpreted languages
rarely have as good static analyzers available for them as
compiled languages -- witness how many more "obvious" typos and
thinkos are found CVS'ed into GCC's configury -- shell-script/Makefile
combinations -- compared to its C code, taking into account
the relative sizes).  In particular, using `sh' might make
it *harder* for me to spot a problem that'll show up only
on some *other* system's `sh', whereas GCC actually can help
find such problems before they happen (e.g. uninitialized-variable
detection has this effect).

Now, if that explains my overall thinking clearly enough, perhaps
you can see why I positively *discourage*, and don't mind GCC
*itself* discouraging, programmers viewing GCC as a white box
rather than a black box.

Yes, the advantages of always having source can be leveraged
such that *every* component we used can be treated in white-box
fashion when we put components together into larger ones.

But, the lessons of engineering include, to me, that even when
one *can* treat components as white boxes, one should *not* do
so, if one wishes to engineer a solid overall product.

(Of course, for unit and system testing, it is entirely reasonable
to strategize and prepare tests based on white-box analyses of
the components.  This is something the proprietary software
industry can *never* offer its users, of course, who can legally
go no farther than gray-box testing, where they *guess* at how
the proprietary components are probably implemented, and try
to break it at the guessed-at seams.  Of course, gray-box testing
is a good idea for free software as well.)

So, when I hear people say "GCC should default to -fno-alias-analysis",
I *basically* hear them as if they're complaining about code that
either isn't important enough to have been engineered in the first
place, or isn't actively maintained but is still actively used *and*
recompiled, despite awareness that it is no longer maintained.  (Even
a user just using a downloaded source package has a responsibility to
check back at the FTP site on occasion for upgrades/fixes/etc.  Again,
if that user doesn't do that, he's not on the engineering level, so
we shouldn't worry much about how to make his hacker life comfy at
the expense of meeting the needs for engineers to have a simpler GCC.)

In both cases, I tend to think "why should we increase GCC's complexity
to address cases that either don't matter or are time-bombs waiting
to explode anyway?"

Yes, I can see *some* rays of light shining through those dark views of
the request for features, but that *is* the fundamental template
through which I now, as a more experienced software developer,
view these requests.  (I.e. there are some cases I can imagine
where accommodating these sorts of requests make sense.  As the
sole developer of g77, it was easy for me to make those decisions;
it's obviously vastly harder here in GCC-land, so it's not unreasonable
to declare that these issues will no longer be discussed, and that
GCC is no longer to be assumed a warning generator, since that'd
be a simplifying assumption consistent with the core engineering
function of GCC.)

Because remember: when you ask for a black-box product to adopt
behaviors that are white-box-like (which includes many compiler
warnings, especially these), you ask for an *increase* in the
complexity visible to end users, who *will* see those behaviors
as if they were black-box-like, and in the *internal* complexity
as well.

The increase in complexity users perceive as black-box like
can contribute to unnecessary increases in the complexity
of their projects, since one of the component's apparent
black-box behavior has now gotten more complex.

Even if you ignore that increase, the increase in internal,
white-box complexity works against *everyone* who uses that
component (GCC, in this case) in their project, *regardless*
of whether they can or will make use of that new behavior.
(That's the fourth item in my list of things to minimize,
above.)

That's why, given all the heat and light over this issue,
I'm not convinced that even the proposed *warning* is a good
idea -- because the added complexity in GCC causes *everybody*
who uses GCC to suffer an automatic increase in the risks
of success of *their* project, because it increases the likelihood
of GCC failing them as a component.

(As I said earlier, an example of a mitigating factor here is
the capture of more code that many users test against GCC using
its default options, e.g. because they gain confidence that
warning-free code isn't hitting this "awful new GCC behavior",
even if it is, or because they applaud our adding the warning
by fixing their broken code.  That extra testing can contribute
to reducing the bugginess of GCC.  It's even possible it'll
contribute to an effort, in fixing bugs the extra testing finds,
to *simplify* GCC in a way that it otherwise wouldn't have been.
Note how *unlikely* each of these positives is likely to be,
compared to the previous...but they *are* possible, and not
to be totally dismissed.)

Now, to people who say "forget all the engineering BS, I just
want to get real work done", I say, fine, you don't want to
do engineering?  Then be happy with the fact that some version
of GCC happened to compile your code so it worked at a given
moment.

And when it stops working, you, as someone who doesn't care
about engineering, can only say "oh well", and either fix it,
or just put up with it, or hire somebody who'll fix it.

The central hypocrisy of much of this thread (*not* jstevens here,
I must stress!) is that some people want to insist that GCC behave
*as if* it is perfectly engineered -- works the same way all
the time in any project in which its used, despite being upgraded,
enhanced, and fixed -- but *refuse* to acknowledge, or recognize,
the responsibility *we*, as GCC *developers*, have to exercise
some engineering methodologies to make GCC actually *work*.

In short: if you care about engineering, you don't mindlessly complain
about GCC not issuing warnings (though you might complain on other,
more legitimate, grounds, related to engineering), you might not
even complain if GCC didn't *have* a -fno-alias-analysis option,
but you *certainly* don't complain that it defaults to -falias-analysis.
(Not as a *user* of GCC, that is; GCC *developers* have their
own agendas, of course, as it is their job to set the parameters
of the box they're building.  So David Edelsohn saying "let's change
the default" is okay in lots of ways that Linus Torvalds saying it
is not.  The latter is merely a request, which can be legitimately
hand-waved aside as not pertaining sufficiently to the core mission of GCC
to even discuss, users not having the *responsibility* to set the
parameters of the GCC "box".  The former could reflect an opinion
that, in this case, increasing the complexity of the GCC box could,
in the long run, lead to more testing.  That's why developers should
*listen* to users, but not always *accommodate* them, if they
intend to build something that works.)

If you *don't* care about engineering, then you have no business
complaining that GCC should accommodate broken code either, since
that code is either *hacked* (and thus will always need fixing as
components change around it) or *engineered* (in which case it *must*
be fixed).

(If there's a category of programming other than "hacking" or "engineering",
other than the obvious one -- "incompetent" -- I'm sorry to not
be able to think of it right now and factor that into those opinions.)

>> So I can see why a few people might think even a warning is likely
>> to constitute just another new minefield for GCC developers to
>> have to march through in another year or two.
>
>That one I don't get.  How can a warning of incorrect code become
>a "minefield"?

When people treat GCC not issuing the exact same warnings given
the exact same code from one version to next as yet another case
of GCC "breaking" their code -- since it'll require them to
go "fix" their code, or turn off the warning, just like the
current situation does.

Simply put: give 'em an inch, and they'll take a mile.  (As the
*current* discussion already proves, I think, vis-a-vis earlier
discussions over the years.)

So we someday change how alias analysis works, turning on more
optimizations.  Let's say that has two effects: some previously
legit warnings stop being issued, and some previously unwarned-about
constructs start being "miscompiled" -- i.e. exposed as the bugs
they always have been -- due to adding new optimizations that
the bulk of users require as *default* (for -O1) to get any
decent performance on some popular new machine (which could even
be a Pentium IV, in theory anyway).

Does anyone really think users *then* will accept the resulting
lack of warnings about bugs in their code any more than they'll
accept the present situation?

Yet that scenario is not only likely, it's two inches short a mile
into inevitable, especially the latter part of it.  (The former
would happen if we re-designed the compiler in certain areas, I
assume, which we might not do in the process of adding the new
optimization.)

If we don't want to impose that kind of minefield on the GCC developers
of tomorrow, the quickest, and perhaps kindest, way to do that is to
let the horse die by the side of the road -- by not providing any
option at this time.

(Maybe *the* kindest is to shoot the horse -- i.e. remove any and
all support for -fno-alias-analysis in GCC 3, 2.96, or even 2.95.2.
Take the screaming for a few months, after which people who don't
simply crawl away recover from the shock of having to fix their
code and simply do it...learning the hard way to *never* write
code like that again.)

>As for avoiding the issue by adding warnings: I agree.  You will not
>avoid this issue by adding warnings.  But you can, I trust, see
>how the warnings are necesary?

No, warnings are never necessary for a compiler to emit, unless
that is required by the pertinent standards and specifications.

GCC emitting warnings is a quality-of-implementation issue, and
thus should *only* be done when the advantages of issuing the
warnings *greatly* overwhelms the disadvantages of added complexity
to GCC to support the warnings.

>I may inherit a body of code that I do not *know* is
>non-conformant . . . I would appreciate it if the compiler, when run
>on that code, informed me that the code was non-conformant.  That way,
>I could either: 1) Not use that compiler.  2) Actually read the docs :-),
>find the necesary switches, and set them.  3) Modify the code to be
>conformant.

The throw-everything-into-a-single-program mentality led to Emacs
and GCC, as well as most Microsoft products.  I used to support
it as well, but am thoroughly disenchanted with it at this point
(though I have *plenty* of understanding as to why it was a
better approach back in the '70s and '80s than it is today, so
please don't think I'm saying Emacs and GCC were necessarily bad
designs as products...as I type this in using Emacs.)

I.e. what you, as a programmer, should be using to find bugs
in your code are programs that have the *sole* purposes of
finding static, and dynamic, bugs, respectively.

The task of compiling a program (or, say, a version of it "decorated"
with code that finds dynamic bugs) into a high-performance
representation should be done by another, separate, program,
with, itself, *no* responsibility whatsoever to diagnose
bugs in the code being compiled.

Among other things, it should be obvious that the factors
influencing the evolution of each of these separated programs are
vastly different, with pretty much the sole exception of
the language in which the user's pogram is written.  That
imples differing release schedules, different maintenance
teams, even different languages appropriate to the implementation.
All of which would benefit end users (e.g. we would already
have released this new alias warning as a new version of the
static diagnostic program *months* ago, if not earlier).

Think about it this way: if we removed every diagnostic capability
of GCC to completely separate programs, one that did static
analysis and one that added dynamic-analysis code (in the same
language) for compilation by GCC, then GCC itself would probably
be *significantly* simpler, or at least somewhat simpler.

The result?  *Products* which *use* GCC to compile code would
become simpler and thus more reliable.  (Yes, they'd use those
other tools as well, but in different timeframes, so to speak;
the user installing jcb-sing, for example, would see an instance
of the project that includes only reliance on GCC, not on
those analysis tools.  At that level, the simplicity of GCC
would lead to a more robust product.  And discussions like this
would *naturally* be resolved *much* more quickly into where to
assign responsibilities for the various issues.)

I.e. GCC would become a smaller, much blacker, box.  (Perhaps having
no command-line options like -O and such whatever.)  Two or more
other small, black boxes would appear, one using static analysis
to detect problems, another decorating the code to use dynamic
analysis (i.e. a filter to be inserted prior to running GCC itself).

Each being simpler and more-well-defined in purpose and interface,
the task of maintaining, releasing, even documenting the lot would
be somewhat reduced, and using each component in isolation, which
we often do during development at a conceptual level (e.g. "compiling"
when we know we just want warnings/errors; or shipping a script
that compiles code, when we know we *don't* want those being
dealt with, at least not at that particular step), would reduce
the complexity of a *huge* number of free-software projects.

I don't happen to think this particular division of labor is
the *ideal* one -- I have a much-finer-grained system in mind,
actually, because I see other pressing needs to address.  So it's
just an example of what can be accomplished...

...by thinking out from inside the box.  ;-)

Also, there are political downsides to a finer-grained architecture,
as long-time followers of the GCC lists might recall: RTL supported
as an input language for a "separate" back end comes to mind as
a political issue, highlighting some such downsides.

>If GCC simply and silently generates invalid code, that is
>unacceptable (unless the compiler writers can show that detecting
>such errors and issuing warnings is not feasible).

Right.  Ensuring GCC is very unlikely to do that is *supposed* to
be Priority 1 of all of us working on it.  This alias-warning
issue is, comparatively, way down the list.

[...not really written to me per se, but:...]
>You say: "I don't read the docs!"?
>
>To bad for you, then.

Well, strictly speaking, I, too, am bad about reading docs.  I simply
tend to learn faster when first looking at sample code.  E.g. I
put up my own web page by "borrowing" egcs.cygnus.com's .html files --
well, their formatting, but I used the content to learn some things.
Only after I had a working familiarity with HTML did I finally
buy a couple of books, read one of them cover to cover, etc.

And I hardly ever bother reading books on computer architectures
or assembly code anymore, because I can learn it just by reading
the output of GCC on the machine.

But I try to *never* hold anyone else responsible for mistakes
I make by failing to read the documentation.  Especially since I'm
such a supporter of *anyone* who attempts to write documentation,
I want *them* to feel *wanted*!

(Still, I'm fond of failsafe procedures that cause systems
to not enter modes requiring documented expertise to use safely
as soon as they can detect their operation by someone who
has not read the documentation.  GCC doesn't need that for
end users; install scripts intended for use by end users,
and which invoke GCC, probably do, but that's not a GCC problem.)

        tq vm, (burley)

Re: type based aliasing again

[Artem Hodyush]

 Richard Stallman <rms@gnu.org> wrote:

>>    Like it or not, people will come to depend on this feature, 
>
>My proposal is not a feature.  When you call it a "feature", you're
>not considering the proposal I made.
>
>The argument about "people depending on this" is flawed
>in the idea that such dependency would be due to my proposal.
>It has already happened, and it is still happening.
>
>People already depend on the invalid code we are talking about.  It
>exists in various programs today.


Sorry but I couldn't refrain from joining the discussion.

You are substituting arguments here. People already depend on 
their invalid code being correctly compiled by gcc 2.7.2. Gcc 2.95 
breaks the code, there is nothing to depend on. With your proposal, 
people will come to depend on future versions of gcc fixing their code. 
(and this will encourage them to write invalid code again and again). 

>People may also be writing more such code even today.  With GCC 2.95,
>such code will always work as expected if -O0 is used, and that may
>even be true if -O1 is used.
>
>In GCC 2.95, when -fstrict-aliasing is used, some of these cases work
>as expected, and some will not.  With my proposal, that would still be
>the overall situation.  The only difference would be that a larger
>fraction of them would work as expected.


As was already mentioned here, with slight changes in gcc internals, 
invalid code will break, sooner or later, but inevitably. And all effort 
spent to implement your proposal will be in vain.

>This difference would reduce the pain caused today, but as regards the
>potential problems you are worried about, it would not change things
>much.


This is like amputating dog's tail piece by piece, because it's too painful
to chop it off at once.


As someone have said on this list, there is about four people on earth who
know gcc internals well enough. And I, as gcc user, would prefer this people 
to spend their time fixing bugs in gcc rather than invalid user code.

Re: type based aliasing again

[Richard Stallman]

    As was already mentioned here, with slight changes in gcc internals, 
    invalid code will break, sooner or later, but inevitably. And all effort 
    spent to implement your proposal will be in vain.

"Invalid code will break" could mean either "some invalid code will
break from time to time", or "all invalid code will certainly break".
The former is true, but the latter is not.

With my proposal, some of these invalid cases may break in the future.
But chances are most of them never will break.  That is one advantage.

And the ones that do break, will most likely break a year or several
in the future instead of now.  That delay will give more time for
today's current versions of various packages to be replaced with
corrected code.  (The warning would encourage people to make new
versions which don't have these constructs in them.)

Thus, even if a given case does someday break, the resulting user
unhappiness will be less with my proposal.  That is a second
advantage.

Re: type based aliasing again

[Gabriel Dos_Reis]

Richard Stallman <rms@gnu.org> writes:

[...]

| And the ones that do break, will most likely break a year or several
| in the future instead of now.  That delay will give more time for
| today's current versions of various packages to be replaced with
| corrected code.  (The warning would encourage people to make new
| versions which don't have these constructs in them.)

And when those invalid programs will break, we'll find the same
persons arguing that GCC used to support those porgrams and should
continue to do the right thing it used to.  
Had we an opportunity to break invalid programs now, we should do so for
the GCC users and GCC maintainers common interest.

-- Gaby

Re: type based aliasing again

[Richard Stallman]

    And when those invalid programs will break, 

Not when--if.  It is possible for some of these programs
to break again, but we can confidently expect that most of them
will not break again.

This is an example of the sort of exaggeration that I have encountered
over and over again in arguments for harshness.  It is not a good
thing for GCC maintenance decisions to be based on exaggerations like
this.

						we'll find the same
    persons arguing that GCC used to support those porgrams and should
    continue to do the right thing it used to.  

Most of these cases will never again break, but some may.  If and when
that happens, we could well find SOME of the same people complaining
who complained about the same case before.

However, if the case that fails is in an April 1999 version of a
program, and if the December 1999 version has different code because a
warning advised the programmer to fix it, and if the case actually
breaks in 2001, then the programmer will not complain.  And most of
the users who compile that package will use a more recent version, so
they will not complain either.

Thus, we will get only a fraction of the number of complaints we
will get now.


Would people please stop making arguments which exaggerate to
the worst case?

Re: type based aliasing again

[Richard Stallman]

    And when those invalid programs will break, 

Not when--if.  It is possible for some of these programs
to break again, but we can confidently expect that most of them
will not break again.

This is an example of the sort of exaggeration that I have encountered
over and over again in arguments for harshness.  It is not a good
thing for GCC maintenance decisions to be based on exaggerations like
this.

						we'll find the same
    persons arguing that GCC used to support those porgrams and should
    continue to do the right thing it used to.  

Most of these cases will never again break, but some may.  If and when
that happens, we could well find SOME of the same people complaining
who complained about the same case before.

However, if the case that fails is in an April 1999 version of a
program, and if the December 1999 version has different code because a
warning advised the programmer to fix it, and if the case actually
breaks in 2001, then the programmer will not complain.  And most of
the users who compile that package will use a more recent version, so
they will not complain either.

Thus, we will get only a fraction of the number of complaints we
will get now.


Would people please stop making arguments which exaggerate to
the worst case?

Re: type based aliasing again

[Gabriel Dos_Reis]

Richard Stallman <rms@gnu.org> writes:

[...]

| And the ones that do break, will most likely break a year or several
| in the future instead of now.  That delay will give more time for
| today's current versions of various packages to be replaced with
| corrected code.  (The warning would encourage people to make new
| versions which don't have these constructs in them.)

And when those invalid programs will break, we'll find the same
persons arguing that GCC used to support those porgrams and should
continue to do the right thing it used to.  
Had we an opportunity to break invalid programs now, we should do so for
the GCC users and GCC maintainers common interest.

-- Gaby

Re: type based aliasing again

[Richard Stallman]

    As was already mentioned here, with slight changes in gcc internals, 
    invalid code will break, sooner or later, but inevitably. And all effort 
    spent to implement your proposal will be in vain.

"Invalid code will break" could mean either "some invalid code will
break from time to time", or "all invalid code will certainly break".
The former is true, but the latter is not.

With my proposal, some of these invalid cases may break in the future.
But chances are most of them never will break.  That is one advantage.

And the ones that do break, will most likely break a year or several
in the future instead of now.  That delay will give more time for
today's current versions of various packages to be replaced with
corrected code.  (The warning would encourage people to make new
versions which don't have these constructs in them.)

Thus, even if a given case does someday break, the resulting user
unhappiness will be less with my proposal.  That is a second
advantage.

Re: type based aliasing again

[Artem Hodyush]

 Richard Stallman <rms@gnu.org> wrote:

>>    Like it or not, people will come to depend on this feature, 
>
>My proposal is not a feature.  When you call it a "feature", you're
>not considering the proposal I made.
>
>The argument about "people depending on this" is flawed
>in the idea that such dependency would be due to my proposal.
>It has already happened, and it is still happening.
>
>People already depend on the invalid code we are talking about.  It
>exists in various programs today.


Sorry but I couldn't refrain from joining the discussion.

You are substituting arguments here. People already depend on 
their invalid code being correctly compiled by gcc 2.7.2. Gcc 2.95 
breaks the code, there is nothing to depend on. With your proposal, 
people will come to depend on future versions of gcc fixing their code. 
(and this will encourage them to write invalid code again and again). 

>People may also be writing more such code even today.  With GCC 2.95,
>such code will always work as expected if -O0 is used, and that may
>even be true if -O1 is used.
>
>In GCC 2.95, when -fstrict-aliasing is used, some of these cases work
>as expected, and some will not.  With my proposal, that would still be
>the overall situation.  The only difference would be that a larger
>fraction of them would work as expected.


As was already mentioned here, with slight changes in gcc internals, 
invalid code will break, sooner or later, but inevitably. And all effort 
spent to implement your proposal will be in vain.

>This difference would reduce the pain caused today, but as regards the
>potential problems you are worried about, it would not change things
>much.


This is like amputating dog's tail piece by piece, because it's too painful
to chop it off at once.


As someone have said on this list, there is about four people on earth who
know gcc internals well enough. And I, as gcc user, would prefer this people 
to spend their time fixing bugs in gcc rather than invalid user code.

Re: type based aliasing again

[craig]

>> If it's not a feature, then backwards compatibility is not an issue.
>
>  I believe the above sentence is untrue. The behaviour of the compiler
>has changed, reguardless of any lables we might throw on the situation.

I already addressed that: the behavior of the compiler *always* changes
upon installing a new release, else there's no point in installing,
or even creating, it.  (Not quite 100% true, but let's say 99.9% of the
time, that's all true.)

If you don't want the behavior of your program changing due to a change
in the compiler and/or version used to build it, then it is up to you,
the author of that program, to specify exactly which compiler/version
is to be used.

>  However, this change is one that can affect the correctness of the users
>code.

No.  It is correct to say "this change is one that can expose the
incorrectness of the user's code".

And that can be said of almost *any* change made to the code-generation
facility of a compiler.

>If we can warn the user by writing a reasonable amount of code then
>it seems to be the "nice" thing to do. Even if we can't catch all
>occurances (as is mentioned earlier in this thread), the ones we can catch
>may be quite a help to the user. 

I agree with that.

>  The assembly thing (which I don't 100% understand - I have no need to
>use it so I don't completely know the issue) is a good example, I think.

It's simple.  When you do "gcc foo.c", you get an a.out executable,
but that process, behind your back so to speak, generates, among
other things, an assembly (.s) file containing the low-level machine
codes the compiler picked to implement the code in foo.c as
mnemonic instructions.

Those instructions represent the closest thing the software industry
has to a widely understood "fix" of how the code in foo.c is actually
implemented by the compiler, e.g. given "i = j++ + k++;", whether
j or k gets incremented first.

If you, as a programmer, wish the behavior of your *program* to not
change, you can, as I said, simply designate a *particular* compiler
and version combination to use (for a particular platform, say).

And if you don't want to require people to have that particular
combination on their machines to build your program, but want
them to have the source code at some level, then provide them
the assembly (.s) file along with your source code, and instruct
the user (via Makefile, perhaps) to "compile" (really, assemble)
*that* instead of the .c.

>The behavior of the compiler was deliberatly changed. I don't care about
>what the documentation said, or who was broken before, or any of that. The
>fact is that code that used to work began (as I understand it) to fail
>silently. This is bad, even if it IS in an FAQ somewhere. Now a warning
>has been added. So the change, which is a positive one, gets to stay, but
>the user gets fair warning from the compiler.

The *developer* of the *code* already got fair warning, or else is a
dunce who shouldn't be allowed anywhere near a computer, especially
not as a programmer.  Only people who understand, or at least accept,
the fact that re-compiling their code can legitimately change the apparent
behavior of their code should be allowed to represent themselves
as programmers in languages requiring compilation (or even interpretation).

Otherwise they should restrict themselves to programming in assembly
language.  And to a very simple machine model at that.  I suggest
the PDP-8.  If they can't fit their programs into 32K 12-bit words
in PDP-8 assembly code, they aren't real programmers anyway.

Now, what *users* expect is a whole 'nother can of worms.  If users
need fair warning that a program might not work because they use a
different compiler on it, then that warning must come from the
developers of that *program*, not the compiler.

>  Now imagine that this export thing, instead of spewing an error,
>silently went on to miscompile the code.

Well-designed languages are that way to the extent that they make
it easy for compilers and interpreters that implement them reject,
or at least warn about, erroneous constructs that programmers might easily
enter, and that means those rejections and warnings are seen by
the *programmers*, not the *users* of the program.

That's the problem with this whole notion that it is up to GCC to serve
as a sort of free-software installation tool.  It is the *programmer*,
not the installer, that needs to see the warnings.  GCC can't do that
as a free-software installation tool.  It can do that, in some cases,
when properly used as a *compiler*.

Still, since C is not exactly a well-designed language, it is not
easy to write static-code-checkers (a la the lint-like facility of
GCC) to find all the problems typically committed by programmers.

>  It is unfortuante that it is immpossile to spew a warning on every
>instance of the alias problem, but I think it is necessary to provide a
>warning when we can do so with a minimum of effort.

I think everyone agrees to that.

What is not widely appreciated or understood is that this warning
*probably* will, itself, "change" across versions/releases of GCC,
and that programmers and users will be as upset about those changes
in *this* case as in the case of alias analysis becoming the default.

Am I wrong?  Well, after *tons* of exactly correct pointing out of
the issues, correcting *many* people on this list, as done by people
such as myself and Mark Mitchell, can anyone point to a *single*
example of anyone admitting they had been wrong and now understood
that they should not expect a compiler to never change the behavior
of their program, especially if it invokes undefined behavior according
to the pertinent language standard?

So I can see why a few people might think even a warning is likely
to constitute just another new minefield for GCC developers to
have to march through in another year or two.

That's why I strongly resist a warning implemented by having to
change code-generation strategies.  If the new strategy is preferable
absent any difference in warnings, fine; then, presumably, the
new warning *can* be easily added and maintained.

But anyone who thinks GCC developers can avoid this whole problem
(of huge amounts of argument about how GCC is "breaking programs")
by making it warn about this construct is, frankly, deluding themselves.

>> And there is no current silent corruption that is default in GCC
>> as pertains this thread.  If you believe that, you were misinformed,
>> and should abstain from repeating this misinformation in any other
>> forum in the future.
>
>   ? Please explain? I thought the whole point of this thread is the
>effect that alias analysis has had on Linux, god knows what else, etc. I
>though the effect was "incorrect" code (code that does not run as
>intended) generated by gcc since it assumed that ANSI rules were being
>followed by the source. Maybe silent corruption was a bad choice of words,
>and "incorrect" code (including the quotes) is a better one.

See above.

>> The whole problem here is simply one of miseducation, or ignorance,
>> on the part of people who think they know what GCC is.  We need not
>> change one line of code to fix *that* problem, and if we don't
>> fix that problem, rewriting GCC from scratch will not fix it either.
>> Certainly changing a few lines will have no worthwhile overall effect.
>> 
>
>  Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler
>maintain by the GCC team, which is an absolutly essentail part of the free
>software movement. I'm not sure what this has to do with the discussion at
>hand.

Some people think GCC is a hand-holding catch-all for installing
free software from source, regardless of the correctness of that
source code (as long as it might have seemed to work on some
old version of some C compiler somewhere), or some approximation
thereof.

That's why they think that GCC is now breaking programs by
defaulting to employing its alias analysis.

People who don't clearly understand the proper roles of various
computer programs, programmers, and end users will *never* be
able to produce well-engineered products.

        tq vm, (burley)

Re: type based aliasing again

[craig]

>> If it's not a feature, then backwards compatibility is not an issue.
>
>  I believe the above sentence is untrue. The behaviour of the compiler
>has changed, reguardless of any lables we might throw on the situation.

I already addressed that: the behavior of the compiler *always* changes
upon installing a new release, else there's no point in installing,
or even creating, it.  (Not quite 100% true, but let's say 99.9% of the
time, that's all true.)

If you don't want the behavior of your program changing due to a change
in the compiler and/or version used to build it, then it is up to you,
the author of that program, to specify exactly which compiler/version
is to be used.

>  However, this change is one that can affect the correctness of the users
>code.

No.  It is correct to say "this change is one that can expose the
incorrectness of the user's code".

And that can be said of almost *any* change made to the code-generation
facility of a compiler.

>If we can warn the user by writing a reasonable amount of code then
>it seems to be the "nice" thing to do. Even if we can't catch all
>occurances (as is mentioned earlier in this thread), the ones we can catch
>may be quite a help to the user. 

I agree with that.

>  The assembly thing (which I don't 100% understand - I have no need to
>use it so I don't completely know the issue) is a good example, I think.

It's simple.  When you do "gcc foo.c", you get an a.out executable,
but that process, behind your back so to speak, generates, among
other things, an assembly (.s) file containing the low-level machine
codes the compiler picked to implement the code in foo.c as
mnemonic instructions.

Those instructions represent the closest thing the software industry
has to a widely understood "fix" of how the code in foo.c is actually
implemented by the compiler, e.g. given "i = j++ + k++;", whether
j or k gets incremented first.

If you, as a programmer, wish the behavior of your *program* to not
change, you can, as I said, simply designate a *particular* compiler
and version combination to use (for a particular platform, say).

And if you don't want to require people to have that particular
combination on their machines to build your program, but want
them to have the source code at some level, then provide them
the assembly (.s) file along with your source code, and instruct
the user (via Makefile, perhaps) to "compile" (really, assemble)
*that* instead of the .c.

>The behavior of the compiler was deliberatly changed. I don't care about
>what the documentation said, or who was broken before, or any of that. The
>fact is that code that used to work began (as I understand it) to fail
>silently. This is bad, even if it IS in an FAQ somewhere. Now a warning
>has been added. So the change, which is a positive one, gets to stay, but
>the user gets fair warning from the compiler.

The *developer* of the *code* already got fair warning, or else is a
dunce who shouldn't be allowed anywhere near a computer, especially
not as a programmer.  Only people who understand, or at least accept,
the fact that re-compiling their code can legitimately change the apparent
behavior of their code should be allowed to represent themselves
as programmers in languages requiring compilation (or even interpretation).

Otherwise they should restrict themselves to programming in assembly
language.  And to a very simple machine model at that.  I suggest
the PDP-8.  If they can't fit their programs into 32K 12-bit words
in PDP-8 assembly code, they aren't real programmers anyway.

Now, what *users* expect is a whole 'nother can of worms.  If users
need fair warning that a program might not work because they use a
different compiler on it, then that warning must come from the
developers of that *program*, not the compiler.

>  Now imagine that this export thing, instead of spewing an error,
>silently went on to miscompile the code.

Well-designed languages are that way to the extent that they make
it easy for compilers and interpreters that implement them reject,
or at least warn about, erroneous constructs that programmers might easily
enter, and that means those rejections and warnings are seen by
the *programmers*, not the *users* of the program.

That's the problem with this whole notion that it is up to GCC to serve
as a sort of free-software installation tool.  It is the *programmer*,
not the installer, that needs to see the warnings.  GCC can't do that
as a free-software installation tool.  It can do that, in some cases,
when properly used as a *compiler*.

Still, since C is not exactly a well-designed language, it is not
easy to write static-code-checkers (a la the lint-like facility of
GCC) to find all the problems typically committed by programmers.

>  It is unfortuante that it is immpossile to spew a warning on every
>instance of the alias problem, but I think it is necessary to provide a
>warning when we can do so with a minimum of effort.

I think everyone agrees to that.

What is not widely appreciated or understood is that this warning
*probably* will, itself, "change" across versions/releases of GCC,
and that programmers and users will be as upset about those changes
in *this* case as in the case of alias analysis becoming the default.

Am I wrong?  Well, after *tons* of exactly correct pointing out of
the issues, correcting *many* people on this list, as done by people
such as myself and Mark Mitchell, can anyone point to a *single*
example of anyone admitting they had been wrong and now understood
that they should not expect a compiler to never change the behavior
of their program, especially if it invokes undefined behavior according
to the pertinent language standard?

So I can see why a few people might think even a warning is likely
to constitute just another new minefield for GCC developers to
have to march through in another year or two.

That's why I strongly resist a warning implemented by having to
change code-generation strategies.  If the new strategy is preferable
absent any difference in warnings, fine; then, presumably, the
new warning *can* be easily added and maintained.

But anyone who thinks GCC developers can avoid this whole problem
(of huge amounts of argument about how GCC is "breaking programs")
by making it warn about this construct is, frankly, deluding themselves.

>> And there is no current silent corruption that is default in GCC
>> as pertains this thread.  If you believe that, you were misinformed,
>> and should abstain from repeating this misinformation in any other
>> forum in the future.
>
>   ? Please explain? I thought the whole point of this thread is the
>effect that alias analysis has had on Linux, god knows what else, etc. I
>though the effect was "incorrect" code (code that does not run as
>intended) generated by gcc since it assumed that ANSI rules were being
>followed by the source. Maybe silent corruption was a bad choice of words,
>and "incorrect" code (including the quotes) is a better one.

See above.

>> The whole problem here is simply one of miseducation, or ignorance,
>> on the part of people who think they know what GCC is.  We need not
>> change one line of code to fix *that* problem, and if we don't
>> fix that problem, rewriting GCC from scratch will not fix it either.
>> Certainly changing a few lines will have no worthwhile overall effect.
>> 
>
>  Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler
>maintain by the GCC team, which is an absolutly essentail part of the free
>software movement. I'm not sure what this has to do with the discussion at
>hand.

Some people think GCC is a hand-holding catch-all for installing
free software from source, regardless of the correctness of that
source code (as long as it might have seemed to work on some
old version of some C compiler somewhere), or some approximation
thereof.

That's why they think that GCC is now breaking programs by
defaulting to employing its alias analysis.

People who don't clearly understand the proper roles of various
computer programs, programmers, and end users will *never* be
able to produce well-engineered products.

        tq vm, (burley)

Re: type based aliasing again

[Florin Mateoc]

Allow me to share my unsolicited 2 cents with you:

THE CLIENT IS ALWAYS RIGHT.

I know that there are good programmers that don't live
by this principle (the software is their baby and they
know best what's good for it), but if you make the
effort to listen and accommodate EVERY (distinct)
complaint or request you end up writing better
software. It is called feedback (different from the
"low-level" (or insider) one that you can get from
your peers) and, besides education, it is the single
most important outside help you can get to improve
your work.
Now it may be that the client doesn't know exactly how
to tell you WHAT she wants, maybe she tries to tell
you HOW to do it instead, or she doesn't know how to
say it politely, but this doesn't change the fact that
you are receiving valuable feedback and you should use
it.

"I find *extremely* disturbing, sufficient (especially
in conjunction with the *huge* waste of time this
discussion has been to date, and will continue to be,
in various forms, until the end of time)" that the gcc
maintainers - as compiler writers - and not the
compiler users, know best how their compiler should
behave externally. This sounds to me like Sun's
position with Java: they designed it, they know best
how it should be used. Well, if they don't happen to
take the right decisions most of the time, less and
less people will follow. I, for one, have stopped
using it, after initially thinking that it looked
promising. I am trying to use the computer as a tool
to solve real problems, not to engage in rituals
observing holy standards (or procedures, or
methodologies, or patterns, or other software
engineering silver bullets).
As for the long-term perspective, "in the long run we
are all dead"

Best regards,

Florin

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: type based aliasing again

[craig]

>Allow me to share my unsolicited 2 cents with you:
>
>THE CLIENT IS ALWAYS RIGHT.

No, and if you believe that, and conduct your software consultancy
that way, you could easily land yourself in prison, or at least
find yourself liable for several million dollars in damages.  (Hope
you have liability insurance.)

>I know that there are good programmers that don't live
>by this principle (the software is their baby and they
>know best what's good for it), but if you make the
>effort to listen and accommodate EVERY (distinct)
>complaint or request you end up writing better
>software.

Here's a clue: there are six billion people on this planet.  GCC's
"clients", to use your terminology, include every one of them.

If you're saying we should listen *and accommodate* every complaint
or request from *any* of those people, based solely on the fact
that they're a "client", you are delusional.

But prove me wrong.  Take the GCC sources, start your own project,
and take your own advice.  Show us how it makes a better compiler.

(BTW, I agree with the "listen" part of your advice.  But I'd
put "critically" in front of it.)

>Now it may be that the client doesn't know exactly how
>to tell you WHAT she wants, maybe she tries to tell
>you HOW to do it instead, or she doesn't know how to
>say it politely, but this doesn't change the fact that
>you are receiving valuable feedback and you should use
>it.

We have, and we are.

>"I find *extremely* disturbing, sufficient (especially
>in conjunction with the *huge* waste of time this
>discussion has been to date, and will continue to be,
>in various forms, until the end of time)" that the gcc
>maintainers - as compiler writers - and not the
>compiler users, know best how their compiler should
>behave externally.

Then you will continue to be disturbed, since we have proof
positive that at least *some* "compiler users" have not
bothered to even read the C language standard, which *is*
an important component in determining how their compiler
should behave externally.

And if you find it disturbing that compiler developers should
be the most informed about what the pertinent standards and
specifications say about how their product works, then you
really are delusional.

Personally, I'd rather the people who know the most about
aircraft design be the *designers* of the things, not the
passengers, or the flight attendants.

With software, it does sometimes *seem* that we accept software
written by people who know less than the average user of that
software how it should work.

GCC is not, or certainly *should* not be, an example of that!

(If I were you, I'd retract a number of the statements you have
made to this list.  Any potential employer who understands
software development will, upon seeing them, avoid hiring you,
or using your software, like the plague.)

Now, end users certainly tend to have the best idea of what
*their* requirements are.

But *their* requirements are a different beast than the
requirements of how a compiler like GCC should behave.

It is up to end users to reasonably assess how a compiler -- any
compiler -- fits into their plans to meet their requirements.

If they can read the C standard and show that a C compiler does
not meet it, *then* they can claim they know more about how
that compiler should behave than the developers.  If the developers
do not listen, the end users should pick another compiler.

>This sounds to me like Sun's
>position with Java: they designed it, they know best
>how it should be used.

I don't believe Sun has ever said that, by the way.

However, what they likely *have* said is "we designed the language Java,
and we know best how the language should be evolved".  That's possible,
though it has little to do with GCC, since we're not solely responsible
for designing or evolving the ISO C language.

And certainly vendors of Java interpreters and compilers *should*
be the ones most informed about what the Java language specifications
say about how they should work externally.

>Well, if they don't happen to
>take the right decisions most of the time, less and
>less people will follow. I, for one, have stopped
>using it, after initially thinking that it looked
>promising. I am trying to use the computer as a tool
>to solve real problems, not to engage in rituals
>observing holy standards (or procedures, or
>methodologies, or patterns, or other software
>engineering silver bullets).

Then ignore the holy standards, and accept whatever the compiler
does for/to you.  Or write your own compiler.  Or use a compiler
developed by people who promised to listen to *and accommodate*
every single request from every user, or potential user, during
its entire history.

Good luck.

Or you could recognize standards and procedures and methodologies
and patterns and software engineering silver bullets as *tools*
for *you* to use to solve those real problems *better*.  The fact
that you're even subscribed to a compiler mailing list shows
that you depend far more on all those things than you are, probably,
even remotely aware of.

(And to think I used to, so long ago, hear wise old engineers give
me the same advice that I now give, and that I, too, was not exactly
a convinced listener.  Difference was, I was open-minded enough to
*consider* what they said and evaluate it.  Clearly they were right
then; just as I am right now.)

        tq vm, (burley)

Re: type based aliasing again

[craig]

>Allow me to share my unsolicited 2 cents with you:
>
>THE CLIENT IS ALWAYS RIGHT.

No, and if you believe that, and conduct your software consultancy
that way, you could easily land yourself in prison, or at least
find yourself liable for several million dollars in damages.  (Hope
you have liability insurance.)

>I know that there are good programmers that don't live
>by this principle (the software is their baby and they
>know best what's good for it), but if you make the
>effort to listen and accommodate EVERY (distinct)
>complaint or request you end up writing better
>software.

Here's a clue: there are six billion people on this planet.  GCC's
"clients", to use your terminology, include every one of them.

If you're saying we should listen *and accommodate* every complaint
or request from *any* of those people, based solely on the fact
that they're a "client", you are delusional.

But prove me wrong.  Take the GCC sources, start your own project,
and take your own advice.  Show us how it makes a better compiler.

(BTW, I agree with the "listen" part of your advice.  But I'd
put "critically" in front of it.)

>Now it may be that the client doesn't know exactly how
>to tell you WHAT she wants, maybe she tries to tell
>you HOW to do it instead, or she doesn't know how to
>say it politely, but this doesn't change the fact that
>you are receiving valuable feedback and you should use
>it.

We have, and we are.

>"I find *extremely* disturbing, sufficient (especially
>in conjunction with the *huge* waste of time this
>discussion has been to date, and will continue to be,
>in various forms, until the end of time)" that the gcc
>maintainers - as compiler writers - and not the
>compiler users, know best how their compiler should
>behave externally.

Then you will continue to be disturbed, since we have proof
positive that at least *some* "compiler users" have not
bothered to even read the C language standard, which *is*
an important component in determining how their compiler
should behave externally.

And if you find it disturbing that compiler developers should
be the most informed about what the pertinent standards and
specifications say about how their product works, then you
really are delusional.

Personally, I'd rather the people who know the most about
aircraft design be the *designers* of the things, not the
passengers, or the flight attendants.

With software, it does sometimes *seem* that we accept software
written by people who know less than the average user of that
software how it should work.

GCC is not, or certainly *should* not be, an example of that!

(If I were you, I'd retract a number of the statements you have
made to this list.  Any potential employer who understands
software development will, upon seeing them, avoid hiring you,
or using your software, like the plague.)

Now, end users certainly tend to have the best idea of what
*their* requirements are.

But *their* requirements are a different beast than the
requirements of how a compiler like GCC should behave.

It is up to end users to reasonably assess how a compiler -- any
compiler -- fits into their plans to meet their requirements.

If they can read the C standard and show that a C compiler does
not meet it, *then* they can claim they know more about how
that compiler should behave than the developers.  If the developers
do not listen, the end users should pick another compiler.

>This sounds to me like Sun's
>position with Java: they designed it, they know best
>how it should be used.

I don't believe Sun has ever said that, by the way.

However, what they likely *have* said is "we designed the language Java,
and we know best how the language should be evolved".  That's possible,
though it has little to do with GCC, since we're not solely responsible
for designing or evolving the ISO C language.

And certainly vendors of Java interpreters and compilers *should*
be the ones most informed about what the Java language specifications
say about how they should work externally.

>Well, if they don't happen to
>take the right decisions most of the time, less and
>less people will follow. I, for one, have stopped
>using it, after initially thinking that it looked
>promising. I am trying to use the computer as a tool
>to solve real problems, not to engage in rituals
>observing holy standards (or procedures, or
>methodologies, or patterns, or other software
>engineering silver bullets).

Then ignore the holy standards, and accept whatever the compiler
does for/to you.  Or write your own compiler.  Or use a compiler
developed by people who promised to listen to *and accommodate*
every single request from every user, or potential user, during
its entire history.

Good luck.

Or you could recognize standards and procedures and methodologies
and patterns and software engineering silver bullets as *tools*
for *you* to use to solve those real problems *better*.  The fact
that you're even subscribed to a compiler mailing list shows
that you depend far more on all those things than you are, probably,
even remotely aware of.

(And to think I used to, so long ago, hear wise old engineers give
me the same advice that I now give, and that I, too, was not exactly
a convinced listener.  Difference was, I was open-minded enough to
*consider* what they said and evaluate it.  Clearly they were right
then; just as I am right now.)

        tq vm, (burley)

Re: type based aliasing again

[Florin Mateoc]

Allow me to share my unsolicited 2 cents with you:

THE CLIENT IS ALWAYS RIGHT.

I know that there are good programmers that don't live
by this principle (the software is their baby and they
know best what's good for it), but if you make the
effort to listen and accommodate EVERY (distinct)
complaint or request you end up writing better
software. It is called feedback (different from the
"low-level" (or insider) one that you can get from
your peers) and, besides education, it is the single
most important outside help you can get to improve
your work.
Now it may be that the client doesn't know exactly how
to tell you WHAT she wants, maybe she tries to tell
you HOW to do it instead, or she doesn't know how to
say it politely, but this doesn't change the fact that
you are receiving valuable feedback and you should use
it.

"I find *extremely* disturbing, sufficient (especially
in conjunction with the *huge* waste of time this
discussion has been to date, and will continue to be,
in various forms, until the end of time)" that the gcc
maintainers - as compiler writers - and not the
compiler users, know best how their compiler should
behave externally. This sounds to me like Sun's
position with Java: they designed it, they know best
how it should be used. Well, if they don't happen to
take the right decisions most of the time, less and
less people will follow. I, for one, have stopped
using it, after initially thinking that it looked
promising. I am trying to use the computer as a tool
to solve real problems, not to engage in rituals
observing holy standards (or procedures, or
methodologies, or patterns, or other software
engineering silver bullets).
As for the long-term perspective, "in the long run we
are all dead"

Best regards,

Florin

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

re: type based aliasing again

[Michael J. Bedy]

*delurk*

  I am a grad student in computer science, who is doing thesis work in the
area of compilers. My main association with gcc (thus far), is however as
a user.

  I have been reading the archives of gcc (and egcs before that) for
probably over a year, and have seen this issue come up many times. As a
user, who also knows a bit about how this whole mess works (not in gcc
specifically, but in compilers in general), I would like to interject my
opinion.

  If it is feasable in gcc to implement warning that the code is invalid
according to ISO rules, and that at some point in the future the ability
of gcc to correctly compile it WILL go away, then I think this is the
correct path. Then the users really can't say that they wern't warned. It
also gives them time to fix the code. If they choose not to fix it, even
given the warnings, then it is indeed "their problem" when it no longer
becomes feasable to support this waring.

  I often find myself at odds with RMS, but in this I think he is right:
We need to be more concerned with what the users needs, especially as far
as something as crucial as gcc.

  One of the great advantages of the Open Source, or Free Software
(whichever you prefer) development model is the greatly reduced lack of
influence the pointy haired boss has on the project. Like anything else,
there is at least a bad side to this; comercial pressures to provide
backward compatability are not there. Unfortunatly, it seems that one of
the worst traits of the community is a rather cavilier attitude towards
backward compatability. 

  While I think the gcc community does a much better job then most at
preserving this backwards compatability, this particular issue seems to be
a hot spot for some reason. I can completely understand the feeling that
the users should just "fix their damn code," but it is not always feasable
to do so immediatly. 

  In addition, if I hadn't been reading this list for so long, I wouldn't
even know about this issue. Perhaps everybody working on gcc is to close
to the problem and doesn't realize that people outside the project don't
know/don't care about this, they just want their code to work. By issueing
a warning whenever possible, the user get real, immediate information that
something is wrong with his/her code.

  In short, and in general, I think it is good policy to, if possible,
include a warning whenever the behaviour of the compiler changes. I think
the worst solution possible is the current silent corruption that is
currently default in gcc.

  To conclude: I want to make sure I thank everybody on the gcc team for
their effort. As a compiler guy myself, I know how much work supporting a
compiler is. This message is not a flame, just an honest opinion from a
(fairly) long time user.

  Include my address in the cc: if you respond plese

   Thanks,
      - Mike
 
(p.s., sorry about the spelling....)

Re: type based aliasing again

[craig]

>Unfortunatly, it seems that one of
>the worst traits of the community is a rather cavilier attitude towards
>backward compatability. 

I agree wholeheartedly with that statement, taken out of context,
and believe I've raised it earlier in this thread (though perhaps in
private emails -- I've lost track).

My opinion is that the free-software community spends too little time
making sure its software is *engineered* correctly so true backwards
compatibility actually works.  I gather problems upgrading libc on
Linux are examples, as well as Linux-related problems between
versions of gcc.  There are no excuses for the problems I've heard
about, other than that the people working on the products didn't devote
enough time and energy to really study the issues.  (Perhaps they were
too busy arguing about precisely how to support broken code in some
forum somewhere?)

My concern remains: to the extent we spend time trying to accommodate
people who write, and refuse to maintain yet continue to distribute,
*broken* code, we do a *worse* job providing true backwards
compatibility, among many other things that *are*, properly, the job
of GCC (as well as other free-software components) to provide.

However, *in* context, that sentence could be interpreted to suggest
that GCC defaulting to -fno-alias-analysis would constitute
backwards compatibility.

That is false.  Else GCC behavior as of 2.8.1 and previous would
have to be considered a "feature", especially vis-a-vis alias
analysis.

And the whole point some people (like RMS) have been trying to make
is that we should *not* think of this as a "feature".

If it's not a feature, then backwards compatibility is not an issue.

>  In short, and in general, I think it is good policy to, if possible,
>include a warning whenever the behaviour of the compiler changes. I think
>the worst solution possible is the current silent corruption that is
>currently default in gcc.

We *did* issue a warning.  It's in the FAQ and elsewhere in the docs.

It's also in the fact that *every* new release of a compiler is likely
to change its behavior vis-a-vis a previous release.  Generally, that
is the whole *point* of a new release.  The question of "what changes
to behavior are acceptable and what are not" is not as "obvious" as
you might think, else we wouldn't be having these discussions.

And there is no current silent corruption that is default in GCC
as pertains this thread.  If you believe that, you were misinformed,
and should abstain from repeating this misinformation in any other
forum in the future.

The solution for "ordinary" programmers is just *so* simple: if you
like the way a given compiler version compiles your free software,
then offer its assembly output for the hosts you care to support
in lieu of end-user compilation using an arbitrary compiler or version.
(I.e. use "gcc -S" and distribute the .s file along with rules in
your Makefile to compile and link it, rather than the .c file,
when one exists for the target machine.)

Beyond that, you just can't expect the behavior of the compiler to
*not* change as your code is moved to another platform, another
compiler, another compiler version, even another set of libraries.

The whole problem here is simply one of miseducation, or ignorance,
on the part of people who think they know what GCC is.  We need not
change one line of code to fix *that* problem, and if we don't
fix that problem, rewriting GCC from scratch will not fix it either.
Certainly changing a few lines will have no worthwhile overall effect.

(Aside to dje: if you consider the above to be a "strawman" argument,
take a *good* look at what <mjbedy@mtu.edu> and others *recently* wrote
about how GCC should work and what it should do.  If I'm putting up and
knocking down strawmen, then please explain why they're coming from other
people, some of whom I've never met before, even on the Internet.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    And the whole point some people (like RMS) have been trying to make
    is that we should *not* think of this as a "feature".

    If it's not a feature, then backwards compatibility is not an issue.

Backwards compatibility in the sense that applies to features is not
an issue here, because we never advertised as a feature that those
code constructs would work.

But supporting the important programs that have such code in them is
an important practical goal.  It is worth a certain amount of effort,
and since we have found a way to do the job fairly easily, we should
do it.

Re: type based aliasing again

[Richard Stallman]

    And the whole point some people (like RMS) have been trying to make
    is that we should *not* think of this as a "feature".

    If it's not a feature, then backwards compatibility is not an issue.

Backwards compatibility in the sense that applies to features is not
an issue here, because we never advertised as a feature that those
code constructs would work.

But supporting the important programs that have such code in them is
an important practical goal.  It is worth a certain amount of effort,
and since we have found a way to do the job fairly easily, we should
do it.

Re: type based aliasing again

[craig]

>Unfortunatly, it seems that one of
>the worst traits of the community is a rather cavilier attitude towards
>backward compatability. 

I agree wholeheartedly with that statement, taken out of context,
and believe I've raised it earlier in this thread (though perhaps in
private emails -- I've lost track).

My opinion is that the free-software community spends too little time
making sure its software is *engineered* correctly so true backwards
compatibility actually works.  I gather problems upgrading libc on
Linux are examples, as well as Linux-related problems between
versions of gcc.  There are no excuses for the problems I've heard
about, other than that the people working on the products didn't devote
enough time and energy to really study the issues.  (Perhaps they were
too busy arguing about precisely how to support broken code in some
forum somewhere?)

My concern remains: to the extent we spend time trying to accommodate
people who write, and refuse to maintain yet continue to distribute,
*broken* code, we do a *worse* job providing true backwards
compatibility, among many other things that *are*, properly, the job
of GCC (as well as other free-software components) to provide.

However, *in* context, that sentence could be interpreted to suggest
that GCC defaulting to -fno-alias-analysis would constitute
backwards compatibility.

That is false.  Else GCC behavior as of 2.8.1 and previous would
have to be considered a "feature", especially vis-a-vis alias
analysis.

And the whole point some people (like RMS) have been trying to make
is that we should *not* think of this as a "feature".

If it's not a feature, then backwards compatibility is not an issue.

>  In short, and in general, I think it is good policy to, if possible,
>include a warning whenever the behaviour of the compiler changes. I think
>the worst solution possible is the current silent corruption that is
>currently default in gcc.

We *did* issue a warning.  It's in the FAQ and elsewhere in the docs.

It's also in the fact that *every* new release of a compiler is likely
to change its behavior vis-a-vis a previous release.  Generally, that
is the whole *point* of a new release.  The question of "what changes
to behavior are acceptable and what are not" is not as "obvious" as
you might think, else we wouldn't be having these discussions.

And there is no current silent corruption that is default in GCC
as pertains this thread.  If you believe that, you were misinformed,
and should abstain from repeating this misinformation in any other
forum in the future.

The solution for "ordinary" programmers is just *so* simple: if you
like the way a given compiler version compiles your free software,
then offer its assembly output for the hosts you care to support
in lieu of end-user compilation using an arbitrary compiler or version.
(I.e. use "gcc -S" and distribute the .s file along with rules in
your Makefile to compile and link it, rather than the .c file,
when one exists for the target machine.)

Beyond that, you just can't expect the behavior of the compiler to
*not* change as your code is moved to another platform, another
compiler, another compiler version, even another set of libraries.

The whole problem here is simply one of miseducation, or ignorance,
on the part of people who think they know what GCC is.  We need not
change one line of code to fix *that* problem, and if we don't
fix that problem, rewriting GCC from scratch will not fix it either.
Certainly changing a few lines will have no worthwhile overall effect.

(Aside to dje: if you consider the above to be a "strawman" argument,
take a *good* look at what <mjbedy@mtu.edu> and others *recently* wrote
about how GCC should work and what it should do.  If I'm putting up and
knocking down strawmen, then please explain why they're coming from other
people, some of whom I've never met before, even on the Internet.)

        tq vm, (burley)

re: type based aliasing again

[Michael J. Bedy]

*delurk*

  I am a grad student in computer science, who is doing thesis work in the
area of compilers. My main association with gcc (thus far), is however as
a user.

  I have been reading the archives of gcc (and egcs before that) for
probably over a year, and have seen this issue come up many times. As a
user, who also knows a bit about how this whole mess works (not in gcc
specifically, but in compilers in general), I would like to interject my
opinion.

  If it is feasable in gcc to implement warning that the code is invalid
according to ISO rules, and that at some point in the future the ability
of gcc to correctly compile it WILL go away, then I think this is the
correct path. Then the users really can't say that they wern't warned. It
also gives them time to fix the code. If they choose not to fix it, even
given the warnings, then it is indeed "their problem" when it no longer
becomes feasable to support this waring.

  I often find myself at odds with RMS, but in this I think he is right:
We need to be more concerned with what the users needs, especially as far
as something as crucial as gcc.

  One of the great advantages of the Open Source, or Free Software
(whichever you prefer) development model is the greatly reduced lack of
influence the pointy haired boss has on the project. Like anything else,
there is at least a bad side to this; comercial pressures to provide
backward compatability are not there. Unfortunatly, it seems that one of
the worst traits of the community is a rather cavilier attitude towards
backward compatability. 

  While I think the gcc community does a much better job then most at
preserving this backwards compatability, this particular issue seems to be
a hot spot for some reason. I can completely understand the feeling that
the users should just "fix their damn code," but it is not always feasable
to do so immediatly. 

  In addition, if I hadn't been reading this list for so long, I wouldn't
even know about this issue. Perhaps everybody working on gcc is to close
to the problem and doesn't realize that people outside the project don't
know/don't care about this, they just want their code to work. By issueing
a warning whenever possible, the user get real, immediate information that
something is wrong with his/her code.

  In short, and in general, I think it is good policy to, if possible,
include a warning whenever the behaviour of the compiler changes. I think
the worst solution possible is the current silent corruption that is
currently default in gcc.

  To conclude: I want to make sure I thank everybody on the gcc team for
their effort. As a compiler guy myself, I know how much work supporting a
compiler is. This message is not a flame, just an honest opinion from a
(fairly) long time user.

  Include my address in the cc: if you respond plese

   Thanks,
      - Mike
 
(p.s., sorry about the spelling....)

Re: type based aliasing again

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 >  
 >         When the compiler and architecture allow this construct to
 > produce reasonable results and other compilers produce reasonable
 > results and GCC still can produce reasonable results more often when
 > an optional optmization is not applied, then why not allow tihs
 > construct to work unless the user specifically request more aggressive
 > optimization?
 > David

	I have concerns about removing strict aliasing from -O2.

Most users probably use -O2 simply because that's what most people
have learned do, e.g. because autoconf defaults to when -O2 you build
a package.  So I think that strict aliasing will get much less usage
even when it is safe to use it.

Thus two things happen:

1.  The code GCC generates by default performs more poorly.

This has already been discussed.  It may or may not be a big deal
today.  But future opts may hinge on aliasing.

2.  Strict alising gets less real world testing.

IMHO the second concern is a big one.  If an optimization gets less
testing, it is usually more buggy, meaning even less people will use
it.  It is a vicious circle.

E.g. I think the large number of problems we've seen with inlining and
loop unrolling are due in part to the fact that they are not in -O2.
There are reasonable arguments as to why they are not there, (like
they may not make the code faster or may bloat your code) but these
particular arguments don't apply to strict aliasing.

	I haven't decided yet whether the testing issue is enough to
reject doing this, but I thought it should be part of the discussion.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: type based aliasing again

[Nathan Sidwell]

"Kaveh R. Ghazi" wrote:
>         I have concerns about removing strict aliasing from -O2.
> 
> Most users probably use -O2 simply because that's what most people
> have learned do, e.g. because autoconf defaults to when -O2 you build
> a package.  So I think that strict aliasing will get much less usage
> even when it is safe to use it.
Good point, but what if we persuaded the autoconf maintainers to make
the next autoconf release emit -O3? (And gcc then did -fstrict-aliasing
at -O3, not at -O2). Non-maintained packages wouldn't upgrade autoconf
and thus remain at -O2, whereas maintained packages would (presumably)
upgrade autoconf and, if they broke the aliasing rules would then break.
The maintainer would see things compiled at -O3, not -O2 and (hopefully)
think 'Mmm, I wonder what -O3 means'. Similarly, users of autoconf would
see the same difference in their own (unreleased) code.

The trouble with this approach, is what about the next "ISO conformant
optimization that breaks a bogus assumption people make"? The approach
doesn't scale. I suppose we could amend the above to have autoconf emit
`-O2 -strict-aliasing'. (That might be an even bigger clue!)

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Re: type based aliasing again

[Nathan Sidwell]

"Kaveh R. Ghazi" wrote:
>         I have concerns about removing strict aliasing from -O2.
> 
> Most users probably use -O2 simply because that's what most people
> have learned do, e.g. because autoconf defaults to when -O2 you build
> a package.  So I think that strict aliasing will get much less usage
> even when it is safe to use it.
Good point, but what if we persuaded the autoconf maintainers to make
the next autoconf release emit -O3? (And gcc then did -fstrict-aliasing
at -O3, not at -O2). Non-maintained packages wouldn't upgrade autoconf
and thus remain at -O2, whereas maintained packages would (presumably)
upgrade autoconf and, if they broke the aliasing rules would then break.
The maintainer would see things compiled at -O3, not -O2 and (hopefully)
think 'Mmm, I wonder what -O3 means'. Similarly, users of autoconf would
see the same difference in their own (unreleased) code.

The trouble with this approach, is what about the next "ISO conformant
optimization that breaks a bogus assumption people make"? The approach
doesn't scale. I suppose we could amend the above to have autoconf emit
`-O2 -strict-aliasing'. (That might be an even bigger clue!)

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Re: type based aliasing again

[Kaveh R. Ghazi]

 > From: David Edelsohn <dje@watson.ibm.com>
 >  
 >         When the compiler and architecture allow this construct to
 > produce reasonable results and other compilers produce reasonable
 > results and GCC still can produce reasonable results more often when
 > an optional optmization is not applied, then why not allow tihs
 > construct to work unless the user specifically request more aggressive
 > optimization?
 > David

	I have concerns about removing strict aliasing from -O2.

Most users probably use -O2 simply because that's what most people
have learned do, e.g. because autoconf defaults to when -O2 you build
a package.  So I think that strict aliasing will get much less usage
even when it is safe to use it.

Thus two things happen:

1.  The code GCC generates by default performs more poorly.

This has already been discussed.  It may or may not be a big deal
today.  But future opts may hinge on aliasing.

2.  Strict alising gets less real world testing.

IMHO the second concern is a big one.  If an optimization gets less
testing, it is usually more buggy, meaning even less people will use
it.  It is a vicious circle.

E.g. I think the large number of problems we've seen with inlining and
loop unrolling are due in part to the fact that they are not in -O2.
There are reasonable arguments as to why they are not there, (like
they may not make the code faster or may bloat your code) but these
particular arguments don't apply to strict aliasing.

	I haven't decided yet whether the testing issue is enough to
reject doing this, but I thought it should be part of the discussion.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: type based aliasing again

[David Ronis]

Time to add my 2 cents.  

First, several of the posts have questioned how "real" the need is for
some modification/flag/warning associated with -fstrict-aliasing.  In
the last few weeks I've been noticed:

1.  Instabilities in the linux kernel (2.2.xx with xx>10) triggered by
    compiling without -fno-strict-aliasing

2.  Problems with perl-5.00561; specifically, a runaway memory
    condition in the pattern recognition test that crashed my machine.
    To be sure, the crash was my fault for not having limits set on
    memory use.  With -fno-strict-aliasing the problem didn't occur.

3.  Possible problems with the gtk+ libraries.  [I'm less sure here
    since the app I'm trying to build doesn't work yet with or without
    the -fno-strict-aliasing flag].

4.  Some problem with the your own java library (this was mentioned on
    the list a little while ago).

Since these are building-block programs on many systems, I'd call the
problem serious.

Personally, I'd prefer to have the more aggressive optimization on by
default, especially since it is what the legalease in the standard
wants.  On the other hand, given the history, to not have a warning
flag, something like -Waliasing , no matter how imperfect, seems like
cruel and unusual punishment.  Many of us end-users often grab some
poorly maintained legacy code and simply configure/make/make install.
Is the expectation really to trace through thousands of lines of code,
if it doesn't work, in the hope that it might be an aliasing problem?
Even a hint of where suspicious aliases occur would be invaluable in
this event and even if the warning picks up lots of false-alarms.

David

Re: type based aliasing again

[David Ronis]

Time to add my 2 cents.  

First, several of the posts have questioned how "real" the need is for
some modification/flag/warning associated with -fstrict-aliasing.  In
the last few weeks I've been noticed:

1.  Instabilities in the linux kernel (2.2.xx with xx>10) triggered by
    compiling without -fno-strict-aliasing

2.  Problems with perl-5.00561; specifically, a runaway memory
    condition in the pattern recognition test that crashed my machine.
    To be sure, the crash was my fault for not having limits set on
    memory use.  With -fno-strict-aliasing the problem didn't occur.

3.  Possible problems with the gtk+ libraries.  [I'm less sure here
    since the app I'm trying to build doesn't work yet with or without
    the -fno-strict-aliasing flag].

4.  Some problem with the your own java library (this was mentioned on
    the list a little while ago).

Since these are building-block programs on many systems, I'd call the
problem serious.

Personally, I'd prefer to have the more aggressive optimization on by
default, especially since it is what the legalease in the standard
wants.  On the other hand, given the history, to not have a warning
flag, something like -Waliasing , no matter how imperfect, seems like
cruel and unusual punishment.  Many of us end-users often grab some
poorly maintained legacy code and simply configure/make/make install.
Is the expectation really to trace through thousands of lines of code,
if it doesn't work, in the hope that it might be an aliasing problem?
Even a hint of where suspicious aliases occur would be invaluable in
this event and even if the warning picks up lots of false-alarms.

David

Re: type based aliasing again

[Marcel Cox]

Bernd Schmidt <bernds@cygnus.co.uk> wrote:

> If, by "cast to union", you mean code of the form

>    union foo { double a; int b[2]; };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;

> then this is not even going to work with gcc

I used the following test program with the following version of GCC:
gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu

It showed that all union constructs were alias safe when compared to the
plain typecast version

#include <stdio.h>

double transform(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((int *)&x)[1]-=0x100000;
  return x;
}

union foo
   {
      double a;
      int b[2];
   };

double transform1(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return x;
}

double transform2(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  ((union foo *)&x)->a+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return x;
}

double transform3(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return ((union foo *)&x)->a;
}

double transform4(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  ((union foo *)&x)->a+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return ((union foo *)&x)->a;
}

int main()
{
  double x;
  x=2.0;
  printf("0: %f %f\n",x,transform(x));
  printf("1: %f %f\n",x,transform1(x));
  printf("2: %f %f\n",x,transform2(x));
  printf("3: %f %f\n",x,transform3(x));
  printf("4: %f %f\n",x,transform4(x));
  return 0;
}

Re: type based aliasing again

[Bernd Schmidt]

> I used the following test program with the following version of GCC:
> gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu
> 
> It showed that all union constructs were alias safe when compared to the
> plain typecast version

You can't show that something is safe this way.  If your programs work, then
the compiler did not choose to take advantage of its aliasing information
for this input.  That doesn't mean it won't do so for any other program.  It
takes only one counterexample to show that the "cast to union" method is not
safe either, and such an example exists.

Bernd

Re: type based aliasing again

[Marcel Cox]

I know this does not proof it is safe. The fact however that a direct typecast
to int behaves differently from a union typecast shows that the compiler handles
this differently.

Bernd Schmidt wrote:

> > I used the following test program with the following version of GCC:
> > gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu
> >
> > It showed that all union constructs were alias safe when compared to the
> > plain typecast version
>
> You can't show that something is safe this way.  If your programs work, then
> the compiler did not choose to take advantage of its aliasing information
> for this input.  That doesn't mean it won't do so for any other program.  It
> takes only one counterexample to show that the "cast to union" method is not
> safe either, and such an example exists.
>
> Bernd

Re: type based aliasing again

[Jamie Lokier]

Marcel Cox wrote:
> I know this does not proof it is safe. The fact however that a direct
> typecast to int behaves differently from a union typecast shows that
> the compiler handles this differently.

Although it is not a proof, it should be possible to test the alias
rules using a small program where only the type varies, but not the mode
(size) of the types, and where we can be sure the optimiser will always
reorder or remove memory accesses if type alias analysis permits it.

E.g.

T1 test (T1 val1, T1 * var1, T2 val2, T2 * var2)
{
  *var1 = val1;
  *var2 = val2;
  return *var1;
}

I would confidently expect the optimiser to decide *var1 == val1 at the
return point if T1 and T2 cannot alias.

Unfortunately testing the union hack is more complicated than this,
because the compiler has MEM_IN_STRUCT_P alias tests as well, which are
affected by the union.  This might give misleading results from Marcel's
test.

-- Jamie

Re: type based aliasing again

[Jamie Lokier]

Marcel Cox wrote:
> I know this does not proof it is safe. The fact however that a direct
> typecast to int behaves differently from a union typecast shows that
> the compiler handles this differently.

Although it is not a proof, it should be possible to test the alias
rules using a small program where only the type varies, but not the mode
(size) of the types, and where we can be sure the optimiser will always
reorder or remove memory accesses if type alias analysis permits it.

E.g.

T1 test (T1 val1, T1 * var1, T2 val2, T2 * var2)
{
  *var1 = val1;
  *var2 = val2;
  return *var1;
}

I would confidently expect the optimiser to decide *var1 == val1 at the
return point if T1 and T2 cannot alias.

Unfortunately testing the union hack is more complicated than this,
because the compiler has MEM_IN_STRUCT_P alias tests as well, which are
affected by the union.  This might give misleading results from Marcel's
test.

-- Jamie

Re: type based aliasing again

[Marcel Cox]

I know this does not proof it is safe. The fact however that a direct typecast
to int behaves differently from a union typecast shows that the compiler handles
this differently.

Bernd Schmidt wrote:

> > I used the following test program with the following version of GCC:
> > gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu
> >
> > It showed that all union constructs were alias safe when compared to the
> > plain typecast version
>
> You can't show that something is safe this way.  If your programs work, then
> the compiler did not choose to take advantage of its aliasing information
> for this input.  That doesn't mean it won't do so for any other program.  It
> takes only one counterexample to show that the "cast to union" method is not
> safe either, and such an example exists.
>
> Bernd

Re: type based aliasing again

[Bernd Schmidt]

> I used the following test program with the following version of GCC:
> gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu
> 
> It showed that all union constructs were alias safe when compared to the
> plain typecast version

You can't show that something is safe this way.  If your programs work, then
the compiler did not choose to take advantage of its aliasing information
for this input.  That doesn't mean it won't do so for any other program.  It
takes only one counterexample to show that the "cast to union" method is not
safe either, and such an example exists.

Bernd

Re: type based aliasing again

[Marcel Cox]

Bernd Schmidt <bernds@cygnus.co.uk> wrote:

> If, by "cast to union", you mean code of the form

>    union foo { double a; int b[2]; };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;

> then this is not even going to work with gcc

I used the following test program with the following version of GCC:
gcc version 2.96 19990912 (experimental) i486-pc-linux-gnu

It showed that all union constructs were alias safe when compared to the
plain typecast version

#include <stdio.h>

double transform(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((int *)&x)[1]-=0x100000;
  return x;
}

union foo
   {
      double a;
      int b[2];
   };

double transform1(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return x;
}

double transform2(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  ((union foo *)&x)->a+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return x;
}

double transform3(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  x+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return ((union foo *)&x)->a;
}

double transform4(double x)
{
  /* calculates (x+1)/2 */
  /* the division by 2 is done in a dirty way */
  /* this codes works on ix86 processors, but probably not on many other
processors */
  ((union foo *)&x)->a+=1.0;
  ((union foo *)&x)->b[1]-=0x100000;
  return ((union foo *)&x)->a;
}

int main()
{
  double x;
  x=2.0;
  printf("0: %f %f\n",x,transform(x));
  printf("1: %f %f\n",x,transform1(x));
  printf("2: %f %f\n",x,transform2(x));
  printf("3: %f %f\n",x,transform3(x));
  printf("4: %f %f\n",x,transform4(x));
  return 0;
}

Re: type based aliasing again

[N8TM]

> It's certainly within a reasonable "umbrella" approach of having
>  increasing optimization levels be about increasing reliance on
>  the code strictly conforming to the pertinent standard, even its
>  "tricky bits".
>  
>  The biggest problem I see with it right now is that we haven't
>  exactly taken that "umbrella" approach in the past in a consistent
>  way.

And it may not be the most useful scheme either.  With gcc-2.96 we are back 
to -Os being faster running most of the time than -O2 or -O3 on x86, with 
-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
the application) needed for best results.  We would want to continue the 
ability to get strict-aliasing at -Os.   I suppose we have no say on the 
peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
specifically turned off; always off at -Os even when it would save space.

Commercial compilers have completely broken the old scheme of things also.  
They generally accept -O but it doesn't mean much.  Maximum optimization may 
be the default (Lahey) or normal high optimization may take quite a string of 
things like -Ofast 
-OPT:fold_reassociate=OFF:IEEE_comparisons=ON:unroll_times_max=2 -TENV:X=1 
(MipsPro).  So maybe the most confusing thing about gnu is the way the 
options have changed over time without much explanation (except for 
strict-aliasing).

Tim

Re: type based aliasing again

[Marc Espie]

In article < e629bdfd.250f2c9c@aol.com > you write:
>> It's certainly within a reasonable "umbrella" approach of having
>>  increasing optimization levels be about increasing reliance on
>>  the code strictly conforming to the pertinent standard, even its
>>  "tricky bits".
>>  
>>  The biggest problem I see with it right now is that we haven't
>>  exactly taken that "umbrella" approach in the past in a consistent
>>  way.

>And it may not be the most useful scheme either.  With gcc-2.96 we are back 
>to -Os being faster running most of the time than -O2 or -O3 on x86, with 
>-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
>the application) needed for best results.  We would want to continue the 
>ability to get strict-aliasing at -Os.   I suppose we have no say on the 
>peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
>specifically turned off; always off at -Os even when it would save space.

You can always turn strict-aliasing on or off explicitly with
-fstrict-aliasing or -fno-strict-aliasing.

The only issue here is whether it should be turned on by default for -O#.

I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.
The pgcc guys can do what they want... after all, pgcc was touted as a 
very fast, highly experimental compiler. Whereas gcc is supposed to be stable.

Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
good idea. It's an issue of whether we consider this optimization as
`safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
as well, as it should decrease the code size. In the second case, I see
no reason to treat it differently from -ffast-math.

Re: type based aliasing again

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> The only issue here is whether it should be turned on by default for -O#.

Marc> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
Marc> good idea. It's an issue of whether we consider this optimization as
Marc> `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
Marc> as well, as it should decrease the code size. In the second case, I see
Marc> no reason to treat it differently from -ffast-math.

	I think that -ffast-math and the behavior of compilers from other
vendors is good precedent that -fstrict-aliasing should be removed from
the standard -O# optimization levels and accessed orthogonally.  I think
that I and the other members of the GCC Steering Committee had good
intentions, but were mistaken about the impact of including this
optimization in a -O# level. 

David

Re: type based aliasing again

[Richard Earnshaw]

dje@watson.ibm.com said:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed
> from the standard -O# optimization levels and accessed orthogonally. 

-ffast-math doesn't give any precedent at all.  -ffast-math enables 
optimizations that the relevant standards disallow.  -fstrict-aliasing 
does exactly the opposite.

Richard.

Re: type based aliasing again

[Nick Ing-Simmons]

Richard Earnshaw <richard.earnshaw@arm.com> writes:
>dje@watson.ibm.com said:
>> 	I think that -ffast-math and the behavior of compilers from other
>> vendors is good precedent that -fstrict-aliasing should be removed
>> from the standard -O# optimization levels and accessed orthogonally. 
>
>-ffast-math doesn't give any precedent at all.  

Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
which may break existing code.

>-ffast-math enables 
>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>does exactly the opposite.

But the math standard has had much longer to settle in and get adopted
in the existing code base. When new C alias standard has been around as long
as IEEE-754 then it may be time to flip the default...

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> But the math standard has had much longer to settle in and get adopted
Nick> in the existing code base. When new C alias standard has been around as long
Nick> as IEEE-754 then it may be time to flip the default...

	The recent C Standard allows the optimization but does not require
a specific behavior.  If it specified a behavior, then this would not be
an optimization.  As the behavior of this construct is undefined, this
transformation should not be enabled without explicit request from the
user.

	The FSF has stated, only just recently, that not breaking existing
programs because of undefined behavior is a goal that GCC should try to
meet.  Removing -fstrict-aliasing is a simple change that will meet this
goal and not dimish the functionality of this optimization for those who
want to invoke it explicitly.

	I think that GCC should make this simple change.

David

Re: type based aliasing again

[craig]

>	The FSF has stated, only just recently, that not breaking existing
>programs because of undefined behavior is a goal that GCC should try to
>meet.  Removing -fstrict-aliasing is a simple change that will meet this
>goal and not dimish the functionality of this optimization for those who
>want to invoke it explicitly.

I really, really doubt that removing -fstrict-aliasing is the only
change needed that will meet this goal.

I suggest the FSF, and all others who support this interpretation,
read every line of the C, C++, and Fortran standards (just for
starters), highlight every effective denotation of something the
user's code plus data can do as "undefined", and research thoroughly
what it'll take to make GCC not "break" these programs.  Division by
zero?  Square root of negative number?  Dereferencing a NULL pointer?
How about when the result isn't used?  How about writing via a NULL
pointer but never trying to read the result back?  These are all
undefined, in one language or another, and GCC will, by one
definition or another, break existing code that invokes these
undefined behaviors.

(Having spent many years now as a compiler developer, and having
hashed relevant issues out on comp.lang.fortran, I can assure you
of one thing: anyone who says "a compiler should not break an
existing program because of undefined behavior" has *not one clue*
about compiler development or standards and specifications.  If they
did, they would state it this way: "a compiler *can* not break an
existing program because of undefined behavior".  If the behavior is
undefined, nothing the compiler causes the program to do at run time
can be considered "breakage".)

(I won't even get into the stunning news that the FSF has reportedly
just changed the rules of the very difficult job of compiler development,
apparently *since* the EGCS team agreed to become GCC and under the
aegis of the FSF.)

        tq vm, (burley)

P.S. Personally, I'll just assume the FSF was misquoted.

Re: type based aliasing again

[David Edelsohn]

	Of course my description is an over-simplification of the FSF's
request.  The rest of your message describing that this is an impossible
task to get every aspect right so GCC should ignore this requirement
altogether is illogical and unhelpful.

David

Re: type based aliasing again

[David Edelsohn]

	Of course my description is an over-simplification of the FSF's
request.  The rest of your message describing that this is an impossible
task to get every aspect right so GCC should ignore this requirement
altogether is illogical and unhelpful.

David

Re: type based aliasing again

[David Edelsohn]

>>>>> craig  writes:

craig> (I won't even get into the stunning news that the FSF has reportedly
craig> just changed the rules of the very difficult job of compiler development,
craig> apparently *since* the EGCS team agreed to become GCC and under the
craig> aegis of the FSF.)

	How is asking that the compiler try to provide compatibility by
default where it is easy, such as not coupling -fstrict-aliasing to a -O#
level, an unreasonable and burdensome request?  This is a one-line change
removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
are arguing against an interpretation of the request that takes it to an
extreme, not the request itself. 

David

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 06:05:54PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	How is asking that the compiler try to provide compatibility by
> default where it is easy, such as not coupling -fstrict-aliasing to a -O#
> level, an unreasonable and burdensome request?  This is a one-line change

Because it is not useful. The same reasoning can be applied to any new
switch, this effectively stopping any advances in technology.

This is only sensible if a large codebase of existing programs rely on
that feature, and as Gerald has pointed out there is not much actual
breakage, but there are large amounts of opinions.

Any decision must be based on the actual extent of the problem.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 06:05:54PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	How is asking that the compiler try to provide compatibility by
> default where it is easy, such as not coupling -fstrict-aliasing to a -O#
> level, an unreasonable and burdensome request?  This is a one-line change

Because it is not useful. The same reasoning can be applied to any new
switch, this effectively stopping any advances in technology.

This is only sensible if a large codebase of existing programs rely on
that feature, and as Gerald has pointed out there is not much actual
breakage, but there are large amounts of opinions.

Any decision must be based on the actual extent of the problem.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[craig]

>>>>>> craig  writes:
>
>craig> (I won't even get into the stunning news that the FSF has reportedly
>craig> just changed the rules of the very difficult job of compiler development,
>craig> apparently *since* the EGCS team agreed to become GCC and under the
>craig> aegis of the FSF.)
>
>	How is asking that the compiler try to provide compatibility by
>default where it is easy, such as not coupling -fstrict-aliasing to a -O#
>level, an unreasonable and burdensome request?  This is a one-line change
>removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
>are arguing against an interpretation of the request that takes it to an
>extreme, not the request itself. 
[and]
>	Of course my description is an over-simplification of the FSF's
>request.  The rest of your message describing that this is an impossible
>task to get every aspect right so GCC should ignore this requirement
>altogether is illogical and unhelpful.

I am arguing only against the statement you made about what the
FSF now requires of GCC.  You omitted that statement in the
quote.  That statement *clearly* suggested the FSF had recently
introduced additional requirements of GCC.

If you'd like to retract that statement, rather than criticize *me*
for calling attention to the ludicrousness of that statement,
I'd appreciate it if you'd do so.  I offered a gentle hint for you
to do so earlier, instead, you chose to attack me.

Pending that, I'm stunned by the complete lack of integrity you've
shown in trying to shift blame for your unnecessary over-simplification
to me.  That a GCC Steering Committee member would refer to my
entirely true statement as "illogical and unhelpful" is something
I find *extremely* disturbing, sufficient (especially in conjunction
with the *huge* waste of time this discussion has been to date, and
will continue to be, in various forms, until the end of time) to cause
me to question why I bother with *any* sort of GCC development,
especially in the form of offering my input.

The long and short of it is, regardless of whether *you* consider
your statement to have been "of course...an over-simplification",
*many* readers, and, frankly *too* many participants in this discussion,
did *not* recognize it as such, instead interpreting it as support
for their position to "fix" this "problem" in GCC.  I don't need
to identify any such people -- the length of the email discussion here,
and elsewhere, is sufficient to make the veracity of it clear
to those who are paying attention.

That's why I felt it necessary to *clearly* and *unambiguously* identify
the concept as you presented it as a ludicrous one for compiler developers
(or even most programmers, for that matter) to try and follow.

If you can't simply and directly communicate what the FSF, or any
other person, said, without over-simplifying in a way that *increases*
apparent support for your position, I suggest you stay out of these
discussions in the future.  Your demagoguery in this case was definitely
not appreciated by me.  If you have a problem with that, then I'll go
away and not bother this mailing list ever again.


As to your point that users expect -fno-alias-analysis not because
they ever read the standard but because that's how compilers used
to behave:

  Game.

  Set.

  Match.

In other words: RMS has said this wouldn't be interpreted as a "feature".
You've just contradicted that with your attempt to use history to
justify your agreement with his position.  So, as long as GCC tends
to make buggy code appear to work, there will always be the same
degree of justification to *continue* to do so.

If the GCC Steering Committee wishes to restore any sanity to this
situation, it should immediately declare the discussion over, and
the decision to be: use -fno-alias-analysis if your code might
not conform to the pertinent requirements of ISO C.

Period.

People who want warnings can get together and write software that
gives it to them, as I suggested, seemingly, weeks ago.

(I'm not holding my breath.  I'd much rather work on software that
actually implements the pertinent standards and specifications *correctly*,
than watch talented, enthusiastic people sap their energies in
largely irrelevant discussions like this.  That this whole thing
was recently started by RMS, who *should* have a better sense of
proportion vis-a-vis volunteer resources and undefined codes, and
who has veto power over the GCC Steering Committee, is very, very sad.)

        tq vm, (burley)

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 06:36:41AM -0000, craig@jcb-sc.com wrote:
> to me.  That a GCC Steering Committee member would refer to my
> entirely true statement as "illogical and unhelpful" is something
> I find *extremely* disturbing, sufficient (especially in conjunction
> with the *huge* waste of time this discussion has been to date, and
> will continue to be, in various forms, until the end of time) to cause
> me to question why I bother with *any* sort of GCC development,
> especially in the form of offering my input.

Craig, that commitee is not really thaat bad. The great number of
public messages also shows the great concern people have with that new
optimization (it does not show that its a real problem, yet).

But, as the SC is a designated _political_ instrument it has to discuss
and answer these concerns thoroughly.

The discussion has been largely technical in the past, so it was shifted
into the public (again) since the real aliasing experts sit here.

> If the GCC Steering Committee wishes to restore any sanity to this
> situation, it should immediately declare the discussion over, and
> the decision to be: use -fno-alias-analysis if your code might
> not conform to the pertinent requirements of ISO C.

The steering committee could indeed just "decide", but this wouldn't help.

I strongly feel the problem is not understood very good, neither its real
extent nor the possible solutions.

A big problem, for example, with the "just disable it"-approach is that
this kind of alias analysis will very likely become a vital part of more
optimization passes than we currently have, and paralying it to off might
do harm to gcc in the future.

> People who want warnings can get together and write software that
> gives it to them, as I suggested, seemingly, weeks ago.

"Patches are welcome" indeed. The problem of warnings seems to be a big
one, but most probably the correct one (thats my opinion of course ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 06:36:41AM -0000, craig@jcb-sc.com wrote:
> to me.  That a GCC Steering Committee member would refer to my
> entirely true statement as "illogical and unhelpful" is something
> I find *extremely* disturbing, sufficient (especially in conjunction
> with the *huge* waste of time this discussion has been to date, and
> will continue to be, in various forms, until the end of time) to cause
> me to question why I bother with *any* sort of GCC development,
> especially in the form of offering my input.

Craig, that commitee is not really thaat bad. The great number of
public messages also shows the great concern people have with that new
optimization (it does not show that its a real problem, yet).

But, as the SC is a designated _political_ instrument it has to discuss
and answer these concerns thoroughly.

The discussion has been largely technical in the past, so it was shifted
into the public (again) since the real aliasing experts sit here.

> If the GCC Steering Committee wishes to restore any sanity to this
> situation, it should immediately declare the discussion over, and
> the decision to be: use -fno-alias-analysis if your code might
> not conform to the pertinent requirements of ISO C.

The steering committee could indeed just "decide", but this wouldn't help.

I strongly feel the problem is not understood very good, neither its real
extent nor the possible solutions.

A big problem, for example, with the "just disable it"-approach is that
this kind of alias analysis will very likely become a vital part of more
optimization passes than we currently have, and paralying it to off might
do harm to gcc in the future.

> People who want warnings can get together and write software that
> gives it to them, as I suggested, seemingly, weeks ago.

"Patches are welcome" indeed. The problem of warnings seems to be a big
one, but most probably the correct one (thats my opinion of course ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

	Craig, I am sorry about my harsh response to you.

	I still believe that you are writing long-winded responses to your
own strawman proposals instead of responding to the actual proposals on
the table.  If your entire earlier message was intended to point out that
my comment was an oversimplification, then why not just say that and make
a stronger point in a shorter message?

David

Re: type based aliasing again

[Nick Ing-Simmons]

How about making -fstrict-aliasing implied by -ansi/-iso ;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> How about making -fstrict-aliasing implied by -ansi/-iso ;-)

	This is an interesting and good proposal.  The problem that I see
is GCC currently uses that flag differently.  The flag currently disables
GCC extensions that are not allowed by a strictly-conforming ANSI/ISO
program. 

	We already have -Os for space optimiation.  Maybe we need -Oa or
-Oansi or -Oiso for the user to give assurances that the program is
standards-compliant.  This would allow an umbrella optimization flag to
attach many of these optimizations requiring strict conformance to operate
correctly. 

David

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> How about making -fstrict-aliasing implied by -ansi/-iso ;-)

	This is an interesting and good proposal.  The problem that I see
is GCC currently uses that flag differently.  The flag currently disables
GCC extensions that are not allowed by a strictly-conforming ANSI/ISO
program. 

	We already have -Os for space optimiation.  Maybe we need -Oa or
-Oansi or -Oiso for the user to give assurances that the program is
standards-compliant.  This would allow an umbrella optimization flag to
attach many of these optimizations requiring strict conformance to operate
correctly. 

David

Re: type based aliasing again

[Nick Ing-Simmons]

How about making -fstrict-aliasing implied by -ansi/-iso ;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[craig]

>	I still believe that you are writing long-winded responses to your
>own strawman proposals instead of responding to the actual proposals on
>the table.  If your entire earlier message was intended to point out that
>my comment was an oversimplification, then why not just say that and make
>a stronger point in a shorter message?

Because it wasn't clear to me your comment was an over-simplification,
as it might well have been something the FSF said lately.

I was responding to the comment.  I even explained why in my most
recent message.  If my messages are too long for you to read -- to
the PS of the earlier message, or to the explanation for why
I felt the wording you used, *as such* (regardless of whether it
was your oversimplification, or a reasonable approximation of
the FSF's stance), needed to be discredited, then please add me
to your killfile.  I've been told I'm overly verbose for about
three decades.  Clearly that hasn't fixed much of anything, so
don't hold your breath.

In my own defense, I'll point out that my verbosity is frequently
the result of sincere attempts on my part to *not* over-simplify
an argument or point, especially not in an attempt to *add* force
to my argument.  In short, I try *very* hard to *not* use demagoguery
*or* set up straw-men.  I believe I usually do a good job of
writing clearly, but, in discussions where others write sloppily,
as you did, I do tend to challenge the *breadth* of possible meanings
of their writings, which includes having to more precisely define
each meaning or alternative, rather than pick just one.  Because,
in practice, if I pick just one, the author inevitably says something
like "well, then, that's not what I meant, and you knew that" -- and
in a sense, he's right, I'd know that wasn't *necessarily* the one
thing he meant.

So I guess you're saying I should have just said "are you over-
simplifying, do you have a pointer to the statement so we can
judge for ourselves what the FSF said".  But, I figure, you must
have had a reason to put it in your own words, so I assumed
there was some honor and integrity as well as practicality in doing
so, and went from there.  It was therefore natural for me to
reason through the issue on the assumption you were fairly
representing the FSF's position to the rest of us, since that's
what you attempted to undertake, and I assumed you were being
honest and fair.

Further, there was no need to over-simplify in that case vis-a-vis
what the FSF probably *did* say (e.g. "programs that invoke undefined
behavior that is universally recognized as being definable to mean
one thing should not be broken by GCC"), so it didn't exactly
make sense that you would over-simplify just to save a few words,
since that's the most it would have saved.

        tq vm, (burley)

Re: type based aliasing again

[craig]

>	I still believe that you are writing long-winded responses to your
>own strawman proposals instead of responding to the actual proposals on
>the table.  If your entire earlier message was intended to point out that
>my comment was an oversimplification, then why not just say that and make
>a stronger point in a shorter message?

Because it wasn't clear to me your comment was an over-simplification,
as it might well have been something the FSF said lately.

I was responding to the comment.  I even explained why in my most
recent message.  If my messages are too long for you to read -- to
the PS of the earlier message, or to the explanation for why
I felt the wording you used, *as such* (regardless of whether it
was your oversimplification, or a reasonable approximation of
the FSF's stance), needed to be discredited, then please add me
to your killfile.  I've been told I'm overly verbose for about
three decades.  Clearly that hasn't fixed much of anything, so
don't hold your breath.

In my own defense, I'll point out that my verbosity is frequently
the result of sincere attempts on my part to *not* over-simplify
an argument or point, especially not in an attempt to *add* force
to my argument.  In short, I try *very* hard to *not* use demagoguery
*or* set up straw-men.  I believe I usually do a good job of
writing clearly, but, in discussions where others write sloppily,
as you did, I do tend to challenge the *breadth* of possible meanings
of their writings, which includes having to more precisely define
each meaning or alternative, rather than pick just one.  Because,
in practice, if I pick just one, the author inevitably says something
like "well, then, that's not what I meant, and you knew that" -- and
in a sense, he's right, I'd know that wasn't *necessarily* the one
thing he meant.

So I guess you're saying I should have just said "are you over-
simplifying, do you have a pointer to the statement so we can
judge for ourselves what the FSF said".  But, I figure, you must
have had a reason to put it in your own words, so I assumed
there was some honor and integrity as well as practicality in doing
so, and went from there.  It was therefore natural for me to
reason through the issue on the assumption you were fairly
representing the FSF's position to the rest of us, since that's
what you attempted to undertake, and I assumed you were being
honest and fair.

Further, there was no need to over-simplify in that case vis-a-vis
what the FSF probably *did* say (e.g. "programs that invoke undefined
behavior that is universally recognized as being definable to mean
one thing should not be broken by GCC"), so it didn't exactly
make sense that you would over-simplify just to save a few words,
since that's the most it would have saved.

        tq vm, (burley)

Re: type based aliasing again

[David Edelsohn]

	Craig, I am sorry about my harsh response to you.

	I still believe that you are writing long-winded responses to your
own strawman proposals instead of responding to the actual proposals on
the table.  If your entire earlier message was intended to point out that
my comment was an oversimplification, then why not just say that and make
a stronger point in a shorter message?

David

Re: type based aliasing again

[craig]

>>>>>> craig  writes:
>
>craig> (I won't even get into the stunning news that the FSF has reportedly
>craig> just changed the rules of the very difficult job of compiler development,
>craig> apparently *since* the EGCS team agreed to become GCC and under the
>craig> aegis of the FSF.)
>
>	How is asking that the compiler try to provide compatibility by
>default where it is easy, such as not coupling -fstrict-aliasing to a -O#
>level, an unreasonable and burdensome request?  This is a one-line change
>removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
>are arguing against an interpretation of the request that takes it to an
>extreme, not the request itself. 
[and]
>	Of course my description is an over-simplification of the FSF's
>request.  The rest of your message describing that this is an impossible
>task to get every aspect right so GCC should ignore this requirement
>altogether is illogical and unhelpful.

I am arguing only against the statement you made about what the
FSF now requires of GCC.  You omitted that statement in the
quote.  That statement *clearly* suggested the FSF had recently
introduced additional requirements of GCC.

If you'd like to retract that statement, rather than criticize *me*
for calling attention to the ludicrousness of that statement,
I'd appreciate it if you'd do so.  I offered a gentle hint for you
to do so earlier, instead, you chose to attack me.

Pending that, I'm stunned by the complete lack of integrity you've
shown in trying to shift blame for your unnecessary over-simplification
to me.  That a GCC Steering Committee member would refer to my
entirely true statement as "illogical and unhelpful" is something
I find *extremely* disturbing, sufficient (especially in conjunction
with the *huge* waste of time this discussion has been to date, and
will continue to be, in various forms, until the end of time) to cause
me to question why I bother with *any* sort of GCC development,
especially in the form of offering my input.

The long and short of it is, regardless of whether *you* consider
your statement to have been "of course...an over-simplification",
*many* readers, and, frankly *too* many participants in this discussion,
did *not* recognize it as such, instead interpreting it as support
for their position to "fix" this "problem" in GCC.  I don't need
to identify any such people -- the length of the email discussion here,
and elsewhere, is sufficient to make the veracity of it clear
to those who are paying attention.

That's why I felt it necessary to *clearly* and *unambiguously* identify
the concept as you presented it as a ludicrous one for compiler developers
(or even most programmers, for that matter) to try and follow.

If you can't simply and directly communicate what the FSF, or any
other person, said, without over-simplifying in a way that *increases*
apparent support for your position, I suggest you stay out of these
discussions in the future.  Your demagoguery in this case was definitely
not appreciated by me.  If you have a problem with that, then I'll go
away and not bother this mailing list ever again.


As to your point that users expect -fno-alias-analysis not because
they ever read the standard but because that's how compilers used
to behave:

  Game.

  Set.

  Match.

In other words: RMS has said this wouldn't be interpreted as a "feature".
You've just contradicted that with your attempt to use history to
justify your agreement with his position.  So, as long as GCC tends
to make buggy code appear to work, there will always be the same
degree of justification to *continue* to do so.

If the GCC Steering Committee wishes to restore any sanity to this
situation, it should immediately declare the discussion over, and
the decision to be: use -fno-alias-analysis if your code might
not conform to the pertinent requirements of ISO C.

Period.

People who want warnings can get together and write software that
gives it to them, as I suggested, seemingly, weeks ago.

(I'm not holding my breath.  I'd much rather work on software that
actually implements the pertinent standards and specifications *correctly*,
than watch talented, enthusiastic people sap their energies in
largely irrelevant discussions like this.  That this whole thing
was recently started by RMS, who *should* have a better sense of
proportion vis-a-vis volunteer resources and undefined codes, and
who has veto power over the GCC Steering Committee, is very, very sad.)

        tq vm, (burley)

Re: type based aliasing again

[David Edelsohn]

>>>>> craig  writes:

craig> (I won't even get into the stunning news that the FSF has reportedly
craig> just changed the rules of the very difficult job of compiler development,
craig> apparently *since* the EGCS team agreed to become GCC and under the
craig> aegis of the FSF.)

	How is asking that the compiler try to provide compatibility by
default where it is easy, such as not coupling -fstrict-aliasing to a -O#
level, an unreasonable and burdensome request?  This is a one-line change
removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
are arguing against an interpretation of the request that takes it to an
extreme, not the request itself. 

David

Re: type based aliasing again

[craig]

>	The FSF has stated, only just recently, that not breaking existing
>programs because of undefined behavior is a goal that GCC should try to
>meet.  Removing -fstrict-aliasing is a simple change that will meet this
>goal and not dimish the functionality of this optimization for those who
>want to invoke it explicitly.

I really, really doubt that removing -fstrict-aliasing is the only
change needed that will meet this goal.

I suggest the FSF, and all others who support this interpretation,
read every line of the C, C++, and Fortran standards (just for
starters), highlight every effective denotation of something the
user's code plus data can do as "undefined", and research thoroughly
what it'll take to make GCC not "break" these programs.  Division by
zero?  Square root of negative number?  Dereferencing a NULL pointer?
How about when the result isn't used?  How about writing via a NULL
pointer but never trying to read the result back?  These are all
undefined, in one language or another, and GCC will, by one
definition or another, break existing code that invokes these
undefined behaviors.

(Having spent many years now as a compiler developer, and having
hashed relevant issues out on comp.lang.fortran, I can assure you
of one thing: anyone who says "a compiler should not break an
existing program because of undefined behavior" has *not one clue*
about compiler development or standards and specifications.  If they
did, they would state it this way: "a compiler *can* not break an
existing program because of undefined behavior".  If the behavior is
undefined, nothing the compiler causes the program to do at run time
can be considered "breakage".)

(I won't even get into the stunning news that the FSF has reportedly
just changed the rules of the very difficult job of compiler development,
apparently *since* the EGCS team agreed to become GCC and under the
aegis of the FSF.)

        tq vm, (burley)

P.S. Personally, I'll just assume the FSF was misquoted.

Re: type based aliasing again

[Gerald Pfeifer]

Some time ago, Mark wrote:
| Saying "Don't violate ANSI/ISO aliasing rules, or else use
| -fno-strict-aliasing" is a simple, easy-to-follow rule.
and don't really see why this shouldn't be viable.

On Tue, 14 Sep 1999, David Edelsohn wrote:
> I think that GCC should make this simple change.

Instead of removing a nice and rather stable optimization for the
sake of compiling broken code, why can't we 
 1. implement warnings;
 2. document the issue in the FAQ and describe the simple workaround
    of using fno-aliasing;
 3. wait what really happens?

What I *really* wonder is: If this is breaking that much legacy code,
where are the bug reports?

After the GCC 2.95.x releases we had quite a couple of reports concerning
problems on Solaris, but I cannot remember a single one concerning the
aliasing issue!

Apart from OpenBSD which seems to have encountered a real bug, just Perl
and Linux have been mentioned (both of which are actively maintained).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: type based aliasing again

[Gerald Pfeifer]

Some time ago, Mark wrote:
| Saying "Don't violate ANSI/ISO aliasing rules, or else use
| -fno-strict-aliasing" is a simple, easy-to-follow rule.
and don't really see why this shouldn't be viable.

On Tue, 14 Sep 1999, David Edelsohn wrote:
> I think that GCC should make this simple change.

Instead of removing a nice and rather stable optimization for the
sake of compiling broken code, why can't we 
 1. implement warnings;
 2. document the issue in the FAQ and describe the simple workaround
    of using fno-aliasing;
 3. wait what really happens?

What I *really* wonder is: If this is breaking that much legacy code,
where are the bug reports?

After the GCC 2.95.x releases we had quite a couple of reports concerning
problems on Solaris, but I cannot remember a single one concerning the
aliasing issue!

Apart from OpenBSD which seems to have encountered a real bug, just Perl
and Linux have been mentioned (both of which are actively maintained).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> But the math standard has had much longer to settle in and get adopted
Nick> in the existing code base. When new C alias standard has been around as long
Nick> as IEEE-754 then it may be time to flip the default...

	The recent C Standard allows the optimization but does not require
a specific behavior.  If it specified a behavior, then this would not be
an optimization.  As the behavior of this construct is undefined, this
transformation should not be enabled without explicit request from the
user.

	The FSF has stated, only just recently, that not breaking existing
programs because of undefined behavior is a goal that GCC should try to
meet.  Removing -fstrict-aliasing is a simple change that will meet this
goal and not dimish the functionality of this optimization for those who
want to invoke it explicitly.

	I think that GCC should make this simple change.

David

Re: type based aliasing again

[craig]

>Richard Earnshaw <richard.earnshaw@arm.com> writes:
>>-ffast-math enables 
>>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>>does exactly the opposite.

(That might be misinterpreted.  -ffast-math and -fstrict-aliasing both
enable optimizations.  The former enables optimizations that the relevant
standards disallows.  The latter does not.)

>But the math standard has had much longer to settle in and get adopted
>in the existing code base. When new C alias standard has been around as long
>as IEEE-754 then it may be time to flip the default...

There's a confusion in that statement that reveals why, indeed,
-ffast-math is not a precedent.

Before IEEE-754, no code was written that *required* -ffast-math.  IEEE-754
springing into existence caused programmers to start writing code that
required -fno-fast-math, however.  (Some already had been on systems --
CPU + library + compiler -- that effectively offered the same promises.)

So specifying -ffast-math is saying "My code meets requirements above
and beyond the present standards".

Specifying -fstrict-analysis is saying "My code meets the presents
standards".

I don't know the history of the C aliasing requirement, but, offhand,
it strikes me as highly unlikely that it does *not* constitute an
incompatible change vis-a-vis former revisions of the standard.

Even if so, it seems kinda silly for users to have to specify *any*
option that says "My code meets the present standards", especially
vis-a-vis the ISO C standard, when compiling code in a file with a
name like "foo.c".

        tq vm, (burley)

Re: type based aliasing again

[craig]

>I don't know the history of the C aliasing requirement, but, offhand,
>it strikes me as highly unlikely that it does *not* constitute an
>incompatible change vis-a-vis former revisions of the standard.

Too many negatives, I meant "highly unlikely that it constitutes
an incompatible change...".

        tq vm, (burley)

Re: type based aliasing again

[craig]

>I don't know the history of the C aliasing requirement, but, offhand,
>it strikes me as highly unlikely that it does *not* constitute an
>incompatible change vis-a-vis former revisions of the standard.

Too many negatives, I meant "highly unlikely that it constitutes
an incompatible change...".

        tq vm, (burley)

Re: type based aliasing again

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> I don't know the history of the C aliasing requirement,
    craig> but, offhand, it strikes me as highly unlikely that it does
    craig> *not* constitute an incompatible change vis-a-vis former
    craig> revisions of the standard.

Just to clarify, the language in the standard probably dates to the
original C standard.  It is certainly not a new aspect of C9X.

That doesn't have any bearing on our decision about what to do; it's
just a fact.  This is not a change to the standard that GCC rushed to
take advantage of; it's a long-standing aspect of ANSI/ISO C.
Compilers just didn't make use of that information until the past few
years, which is why a lot of programs that broke these rules worked
OK historically.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Toon Moene]

Mark Mitchell wrote:

[ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer ]

> Just to clarify, the language in the standard probably dates to the
> original C standard.  It is certainly not a new aspect of C9X.

But was it new with the ANSI/ISO 89 Standard ?

> That doesn't have any bearing on our decision about what to do; it's
> just a fact.  This is not a change to the standard that GCC rushed to
> take advantage of; it's a long-standing aspect of ANSI/ISO C.

[ I do agree with the first sentence of of the above paragraph ]

The interesting question preceding is:  Did C programmers *ever* have
the opportunity to believe that the following sequence would work:

      int bla(ix)
      int *ix;
      {
         short s;
         ...
         s = (short *) ix;
         ...
      }

I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
of Changes") and nowhere they say these restrictions against using
differently typed pointers "are new with the ANSI/ISO Standard".

I don't have K&R I, so I can't check if you could possibly read into
that text that the above would be legal, or what it would mean in the
first place ...

Does anyone know this ?

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
Toon> of Changes") and nowhere they say these restrictions against using
Toon> differently typed pointers "are new with the ANSI/ISO Standard".

	This viewpoint does not cover large groups of compiler users.
Many programmers wrote code using differently typed pointers -- either
because it was natural or because they wree trying to elicit certain
behavior from the compiler.  This code behaved as expected when compiled
with GCC using default commandline flags until this latest release.  We
easily can change the behavior of GCC so that this class of users will not
be inconvenienced and those who want more aggressive optimization of
conforming code can elicint the behavior they want.  This change is
trivial.  Arguing about C standards and user expectations does not
consider how this and other compilers have behaved for years.  Those
compilers were not behaving incorrectly.

David

Re: type based aliasing again

[Toon Moene]

David Edelsohn wrote:

> >>>>> I wrote:

> Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
> Toon> of Changes") and nowhere they say these restrictions against using
> Toon> differently typed pointers "are new with the ANSI/ISO Standard".

>         This viewpoint does not cover large groups of compiler users.
> Many programmers wrote code using differently typed pointers -- either
> because it was natural or because they wree trying to elicit certain
> behavior from the compiler.  This code behaved as expected when compiled
> with GCC using default commandline flags until this latest release.  

I do not deny that there are programmers who _think_ that that sort of
type-mixing pointing is "allowed" - we can all count the "bug reports"
we get because they do.

What I'm trying to establish is whether those programmers had a right to
believe this was allowed *based on the Standard previous to the current
Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
change with ANSI/ISO C 89, and I am willing to cut the old hands some
slack.

If not - there's a simple compile time option to turn off the unwanted
behaviour.

Perhaps it helps if I explain why I have little patience with this sort
of trickery (with the above caveat in mind):

Every month or so, somebody chastizes Digital's Fortran on
comp.lang.fortran for an "obvious and heinous" bug, because the
following construct doesn't do what they think it should:

      REAL A(N)
      ...
      IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN
      ...

when the compiled code crashes with a Segmentation Violation.

Why ?  Well, simply because the Fortran definition of .AND. doesn't
imply ordering; it's simply a commutative LOGICAL expression (in this
case two, with three operands).  The operands can legally be evaluated
in any order, and as soon as the truth value of the expression can be
determined (because one of the operands evaluates to .FALSE.) no other
evaluation has to take place, but is also not prohibited.

The experts take a deep breath, and explain to the (often experienced
Fortran) programmer that this is completely legal.  I've watched this
now for several years, *and I have never seen the Digital Fortran guys
give in*.  There isn't an advertised optimisation level at which this is
guaranteed not to happen.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I do not deny that there are programmers who _think_ that that sort of
Toon> type-mixing pointing is "allowed" - we can all count the "bug reports"
Toon> we get because they do.

	As far as I can tell, the C standard allowed it to the extent that
its behavior was undefined.  It was not disallowed and was left to the
implementation what result it produced.  Most compilers, including GCC,
have been producing a reasonable result under most circumstances when
faced with this construct.  I think that RMS's interpretation is that if
the limitations of a processor or system made this difficult or
impossible, a compiler writer could defend the lack of functionality by
saying the standard leaves the bahavior undefined. 

	When the compiler and architecture allow this construct to produce
reasonable results and other compilers produce reasonable results and GCC
still can produce reasonable results more often when an optional
optmization is not applied, then why not allow tihs construct to work
unless the user specifically request more aggressive optimization?

David

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	As far as I can tell, the C standard allowed it to the
    David> extent that its behavior was undefined.  It was not
    David> disallowed and was left to the implementation what result
    David> it produced.  Most compilers, including GCC, have been
    David> producing a reasonable result under most circumstances when
    David> faced with this construct.

Although this again has no bearing on what we should *do*, it's worth
nothing that "undefined" has a much strong meaning than what you say
here.  "Implementation-defined" is the term used when the
implementation is expected to pick some behavior.  Undefined means
that program is erroneous, but the implementation is not required to
issue a diagnostic.  Other examples of undefined behavior include
dereferencing the NULL pointer, for example.  The behavior with
respect to accessing different fields in a union is
implementation-defined; the behavior of casting a double* to an int*
and then storing through it when it really points to a double is
undefined.  It would be reasonable (from the point of view of the
standard, not of GCC) to refuse to compile this at all, or to issue an
error at run-time, say.

    David> 	When the compiler and architecture allow this
    David> construct to produce reasonable results and other compilers
    David> produce reasonable results and GCC still can produce
    David> reasonable results more often when an optional optmization
    David> is not applied, then why not allow tihs construct to work
    David> unless the user specifically request more aggressive
    David> optimization?

Many new optimizations will break programs.  For example, if we remove
empty loops, people who wrote them for timing purposes lose.  If we
eliminate dead stores, people who forgot to say `volatile' lose.
Users of inline assembly often lose, if they forgot to mention a
clobber, etc.  People who depend on particular floating-point
computations in languages where the compiler can reorder operands lose
when we do the reordering.  Real programs really depend on all these
things, even though they shouldn't.  So, I don't think this is a very
good argument; it implies, to a first approximation, that no new
optimization is OK.  That's not 100% accurate, but it's not that far
off, either.

That doesn't mean that we shouldn't do what you suggest
w.r.t. -fstrict-aliasing.

There's a fundamental user-interface question here: is the default
behavior to generate fast code for conforming programs, or code that
works even for non-conforming programs?  Both defaults are sensible;
the first because users don't have to use lots of funny options to get
fast code, the second because legacy code doesn't get broken.  There
are broader ramifications as well; some people will reject GCC because
compared to some other `cc -O', `gcc -O' is slower.  Others because
with some other `cc -O' code works while `gcc -O' does not.  There's
no easy answer.

We don't need a global decision on this point; we can do it on an
option-by-option basis.  But, we should have an overall sentiment, or
we will forever have the same debates.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	As far as I can tell, the C standard allowed it to the
    David> extent that its behavior was undefined.  It was not
    David> disallowed and was left to the implementation what result
    David> it produced.  Most compilers, including GCC, have been
    David> producing a reasonable result under most circumstances when
    David> faced with this construct.

Although this again has no bearing on what we should *do*, it's worth
nothing that "undefined" has a much strong meaning than what you say
here.  "Implementation-defined" is the term used when the
implementation is expected to pick some behavior.  Undefined means
that program is erroneous, but the implementation is not required to
issue a diagnostic.  Other examples of undefined behavior include
dereferencing the NULL pointer, for example.  The behavior with
respect to accessing different fields in a union is
implementation-defined; the behavior of casting a double* to an int*
and then storing through it when it really points to a double is
undefined.  It would be reasonable (from the point of view of the
standard, not of GCC) to refuse to compile this at all, or to issue an
error at run-time, say.

    David> 	When the compiler and architecture allow this
    David> construct to produce reasonable results and other compilers
    David> produce reasonable results and GCC still can produce
    David> reasonable results more often when an optional optmization
    David> is not applied, then why not allow tihs construct to work
    David> unless the user specifically request more aggressive
    David> optimization?

Many new optimizations will break programs.  For example, if we remove
empty loops, people who wrote them for timing purposes lose.  If we
eliminate dead stores, people who forgot to say `volatile' lose.
Users of inline assembly often lose, if they forgot to mention a
clobber, etc.  People who depend on particular floating-point
computations in languages where the compiler can reorder operands lose
when we do the reordering.  Real programs really depend on all these
things, even though they shouldn't.  So, I don't think this is a very
good argument; it implies, to a first approximation, that no new
optimization is OK.  That's not 100% accurate, but it's not that far
off, either.

That doesn't mean that we shouldn't do what you suggest
w.r.t. -fstrict-aliasing.

There's a fundamental user-interface question here: is the default
behavior to generate fast code for conforming programs, or code that
works even for non-conforming programs?  Both defaults are sensible;
the first because users don't have to use lots of funny options to get
fast code, the second because legacy code doesn't get broken.  There
are broader ramifications as well; some people will reject GCC because
compared to some other `cc -O', `gcc -O' is slower.  Others because
with some other `cc -O' code works while `gcc -O' does not.  There's
no easy answer.

We don't need a global decision on this point; we can do it on an
option-by-option basis.  But, we should have an overall sentiment, or
we will forever have the same debates.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 07:13:08PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	As far as I can tell, the C standard allowed it to the extent that
> its behavior was undefined.  It was not disallowed and was left to the

Undefined behaviour *is* disallowed and you are no longer writing (ISO)
"C". What you mean is "implementation defined behaviour".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 07:13:08PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	As far as I can tell, the C standard allowed it to the extent that
> its behavior was undefined.  It was not disallowed and was left to the

Undefined behaviour *is* disallowed and you are no longer writing (ISO)
"C". What you mean is "implementation defined behaviour".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I do not deny that there are programmers who _think_ that that sort of
Toon> type-mixing pointing is "allowed" - we can all count the "bug reports"
Toon> we get because they do.

	As far as I can tell, the C standard allowed it to the extent that
its behavior was undefined.  It was not disallowed and was left to the
implementation what result it produced.  Most compilers, including GCC,
have been producing a reasonable result under most circumstances when
faced with this construct.  I think that RMS's interpretation is that if
the limitations of a processor or system made this difficult or
impossible, a compiler writer could defend the lack of functionality by
saying the standard leaves the bahavior undefined. 

	When the compiler and architecture allow this construct to produce
reasonable results and other compilers produce reasonable results and GCC
still can produce reasonable results more often when an optional
optmization is not applied, then why not allow tihs construct to work
unless the user specifically request more aggressive optimization?

David

Re: type based aliasing again

[dvv]

On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:

>What I'm trying to establish is whether those programmers had a right to
>believe this was allowed *based on the Standard previous to the current
>Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
>change with ANSI/ISO C 89, and I am willing to cut the old hands some
>slack.

K&R I (What is it, anyway? Is it the language accepted by the original
dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
things that wouldn't work in the Standard.

>Toon Moene (toon@moene.indiv.nluug.nl)

Dima

Re: type based aliasing again

[Michael Meissner]

On Tue, Sep 14, 1999 at 11:15:06PM +0000, Dima Volodin wrote:
> On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:
> 
> >What I'm trying to establish is whether those programmers had a right to
> >believe this was allowed *based on the Standard previous to the current
> >Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
> >change with ANSI/ISO C 89, and I am willing to cut the old hands some
> >slack.
> 
> K&R I (What is it, anyway? Is it the language accepted by the original
> dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
> things that wouldn't work in the Standard.

And even there its not helpful.  For example, K&R-I explicitly uses a ref/def
model (where you must have one definition of a global variable in separate
files and everything else must be an "extern" reference to it), while the UNIX
C compilers have traditionally implemented the common model for global
variables).  Also, if you go by K&R-I, you cannot derrive pointers to functions
due to a typo in the book.

> >Toon Moene (toon@moene.indiv.nluug.nl)
> 
> Dima

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

Re: type based aliasing again

[Michael Meissner]

On Tue, Sep 14, 1999 at 11:15:06PM +0000, Dima Volodin wrote:
> On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:
> 
> >What I'm trying to establish is whether those programmers had a right to
> >believe this was allowed *based on the Standard previous to the current
> >Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
> >change with ANSI/ISO C 89, and I am willing to cut the old hands some
> >slack.
> 
> K&R I (What is it, anyway? Is it the language accepted by the original
> dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
> things that wouldn't work in the Standard.

And even there its not helpful.  For example, K&R-I explicitly uses a ref/def
model (where you must have one definition of a global variable in separate
files and everything else must be an "extern" reference to it), while the UNIX
C compilers have traditionally implemented the common model for global
variables).  Also, if you go by K&R-I, you cannot derrive pointers to functions
due to a typo in the book.

> >Toon Moene (toon@moene.indiv.nluug.nl)
> 
> Dima

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

Re: type based aliasing again

[Dima Volodin]

On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:

>What I'm trying to establish is whether those programmers had a right to
>believe this was allowed *based on the Standard previous to the current
>Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
>change with ANSI/ISO C 89, and I am willing to cut the old hands some
>slack.

K&R I (What is it, anyway? Is it the language accepted by the original
dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
things that wouldn't work in the Standard.

>Toon Moene (toon@moene.indiv.nluug.nl)

Dima

Re: type based aliasing again

[Toon Moene]

David Edelsohn wrote:

> >>>>> I wrote:

> Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
> Toon> of Changes") and nowhere they say these restrictions against using
> Toon> differently typed pointers "are new with the ANSI/ISO Standard".

>         This viewpoint does not cover large groups of compiler users.
> Many programmers wrote code using differently typed pointers -- either
> because it was natural or because they wree trying to elicit certain
> behavior from the compiler.  This code behaved as expected when compiled
> with GCC using default commandline flags until this latest release.  

I do not deny that there are programmers who _think_ that that sort of
type-mixing pointing is "allowed" - we can all count the "bug reports"
we get because they do.

What I'm trying to establish is whether those programmers had a right to
believe this was allowed *based on the Standard previous to the current
Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
change with ANSI/ISO C 89, and I am willing to cut the old hands some
slack.

If not - there's a simple compile time option to turn off the unwanted
behaviour.

Perhaps it helps if I explain why I have little patience with this sort
of trickery (with the above caveat in mind):

Every month or so, somebody chastizes Digital's Fortran on
comp.lang.fortran for an "obvious and heinous" bug, because the
following construct doesn't do what they think it should:

      REAL A(N)
      ...
      IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN
      ...

when the compiled code crashes with a Segmentation Violation.

Why ?  Well, simply because the Fortran definition of .AND. doesn't
imply ordering; it's simply a commutative LOGICAL expression (in this
case two, with three operands).  The operands can legally be evaluated
in any order, and as soon as the truth value of the expression can be
determined (because one of the operands evaluates to .FALSE.) no other
evaluation has to take place, but is also not prohibited.

The experts take a deep breath, and explain to the (often experienced
Fortran) programmer that this is completely legal.  I've watched this
now for several years, *and I have never seen the Digital Fortran guys
give in*.  There isn't an advertised optimisation level at which this is
guaranteed not to happen.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
Toon> of Changes") and nowhere they say these restrictions against using
Toon> differently typed pointers "are new with the ANSI/ISO Standard".

	This viewpoint does not cover large groups of compiler users.
Many programmers wrote code using differently typed pointers -- either
because it was natural or because they wree trying to elicit certain
behavior from the compiler.  This code behaved as expected when compiled
with GCC using default commandline flags until this latest release.  We
easily can change the behavior of GCC so that this class of users will not
be inconvenienced and those who want more aggressive optimization of
conforming code can elicint the behavior they want.  This change is
trivial.  Arguing about C standards and user expectations does not
consider how this and other compilers have behaved for years.  Those
compilers were not behaving incorrectly.

David

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> Mark Mitchell wrote:

    Toon> [ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer
    Toon> ]

    >> Just to clarify, the language in the standard probably dates to
    >> the original C standard.  It is certainly not a new aspect of
    >> C9X.

    Toon> But was it new with the ANSI/ISO 89 Standard ?

I do not know.  It's an interesting historical question, though.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> Mark Mitchell wrote:

    Toon> [ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer
    Toon> ]

    >> Just to clarify, the language in the standard probably dates to
    >> the original C standard.  It is certainly not a new aspect of
    >> C9X.

    Toon> But was it new with the ANSI/ISO 89 Standard ?

I do not know.  It's an interesting historical question, though.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Toon Moene]

Mark Mitchell wrote:

[ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer ]

> Just to clarify, the language in the standard probably dates to the
> original C standard.  It is certainly not a new aspect of C9X.

But was it new with the ANSI/ISO 89 Standard ?

> That doesn't have any bearing on our decision about what to do; it's
> just a fact.  This is not a change to the standard that GCC rushed to
> take advantage of; it's a long-standing aspect of ANSI/ISO C.

[ I do agree with the first sentence of of the above paragraph ]

The interesting question preceding is:  Did C programmers *ever* have
the opportunity to believe that the following sequence would work:

      int bla(ix)
      int *ix;
      {
         short s;
         ...
         s = (short *) ix;
         ...
      }

I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
of Changes") and nowhere they say these restrictions against using
differently typed pointers "are new with the ANSI/ISO Standard".

I don't have K&R I, so I can't check if you could possibly read into
that text that the above would be legal, or what it would mean in the
first place ...

Does anyone know this ?

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> I don't know the history of the C aliasing requirement,
    craig> but, offhand, it strikes me as highly unlikely that it does
    craig> *not* constitute an incompatible change vis-a-vis former
    craig> revisions of the standard.

Just to clarify, the language in the standard probably dates to the
original C standard.  It is certainly not a new aspect of C9X.

That doesn't have any bearing on our decision about what to do; it's
just a fact.  This is not a change to the standard that GCC rushed to
take advantage of; it's a long-standing aspect of ANSI/ISO C.
Compilers just didn't make use of that information until the past few
years, which is why a lot of programs that broke these rules worked
OK historically.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[craig]

>Richard Earnshaw <richard.earnshaw@arm.com> writes:
>>-ffast-math enables 
>>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>>does exactly the opposite.

(That might be misinterpreted.  -ffast-math and -fstrict-aliasing both
enable optimizations.  The former enables optimizations that the relevant
standards disallows.  The latter does not.)

>But the math standard has had much longer to settle in and get adopted
>in the existing code base. When new C alias standard has been around as long
>as IEEE-754 then it may be time to flip the default...

There's a confusion in that statement that reveals why, indeed,
-ffast-math is not a precedent.

Before IEEE-754, no code was written that *required* -ffast-math.  IEEE-754
springing into existence caused programmers to start writing code that
required -fno-fast-math, however.  (Some already had been on systems --
CPU + library + compiler -- that effectively offered the same promises.)

So specifying -ffast-math is saying "My code meets requirements above
and beyond the present standards".

Specifying -fstrict-analysis is saying "My code meets the presents
standards".

I don't know the history of the C aliasing requirement, but, offhand,
it strikes me as highly unlikely that it does *not* constitute an
incompatible change vis-a-vis former revisions of the standard.

Even if so, it seems kinda silly for users to have to specify *any*
option that says "My code meets the present standards", especially
vis-a-vis the ISO C standard, when compiling code in a file with a
name like "foo.c".

        tq vm, (burley)

Re: type based aliasing again

[Geoff Keating]

Nick Ing-Simmons <nik@tiuk.ti.com> writes:

> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
> which may break existing code.

Every optimisation that changes the ordering of memory accesses may
break existing code, in the presence of threads or signals.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: type based aliasing again

[Nick Ing-Simmons]

Geoff Keating <geoffk@ozemail.com.au> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
>> which may break existing code.
>
>Every optimisation that changes the ordering of memory accesses may
>break existing code, in the presence of threads or signals.

True. But such code while it may "exist" is unlikely to work correctly 
on different architectures with/without -O etc. As such breaking such code
is not as likely to surprise anyone that happens to be using it.

This is a different class of "existing code" than that which is broken 
by acting upon -fstrict-aliasing. Neither Linux kernel, nor perl, nor 
emacs is fragile in that sense. 

The "snag" with -fstrict-aliasing is that what it breaks is a commonly used
"trick" (C as architecture independant assembler) which has become entrenched 
in the code base. There are going to be lots of "close to the machine" bits
of code which have worked fine for years and are not actively maintained
which get bitten.

That said I don't really mind which way the default goes. But having 
it differ between -ON and -ON+1 is going to confuse people more than 
having to say -fno-strict-aliasing. (I would guess about 1/2 of 
./configure generated Makefiles generate -O2 for GCC.)

For new or fixed-up code I would prefer an attribute scheme so that I did 
not have to penalize an entire file just for (ab)use in one hot-spot.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Nick Ing-Simmons]

Geoff Keating <geoffk@ozemail.com.au> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
>> which may break existing code.
>
>Every optimisation that changes the ordering of memory accesses may
>break existing code, in the presence of threads or signals.

True. But such code while it may "exist" is unlikely to work correctly 
on different architectures with/without -O etc. As such breaking such code
is not as likely to surprise anyone that happens to be using it.

This is a different class of "existing code" than that which is broken 
by acting upon -fstrict-aliasing. Neither Linux kernel, nor perl, nor 
emacs is fragile in that sense. 

The "snag" with -fstrict-aliasing is that what it breaks is a commonly used
"trick" (C as architecture independant assembler) which has become entrenched 
in the code base. There are going to be lots of "close to the machine" bits
of code which have worked fine for years and are not actively maintained
which get bitten.

That said I don't really mind which way the default goes. But having 
it differ between -ON and -ON+1 is going to confuse people more than 
having to say -fno-strict-aliasing. (I would guess about 1/2 of 
./configure generated Makefiles generate -O2 for GCC.)

For new or fixed-up code I would prefer an attribute scheme so that I did 
not have to penalize an entire file just for (ab)use in one hot-spot.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Geoff Keating]

Nick Ing-Simmons <nik@tiuk.ti.com> writes:

> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
> which may break existing code.

Every optimisation that changes the ordering of memory accesses may
break existing code, in the presence of threads or signals.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: type based aliasing again

[Nick Ing-Simmons]

Richard Earnshaw <richard.earnshaw@arm.com> writes:
>dje@watson.ibm.com said:
>> 	I think that -ffast-math and the behavior of compilers from other
>> vendors is good precedent that -fstrict-aliasing should be removed
>> from the standard -O# optimization levels and accessed orthogonally. 
>
>-ffast-math doesn't give any precedent at all.  

Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
which may break existing code.

>-ffast-math enables 
>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>does exactly the opposite.

But the math standard has had much longer to settle in and get adopted
in the existing code base. When new C alias standard has been around as long
as IEEE-754 then it may be time to flip the default...

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Richard Earnshaw]

dje@watson.ibm.com said:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed
> from the standard -O# optimization levels and accessed orthogonally. 

-ffast-math doesn't give any precedent at all.  -ffast-math enables 
optimizations that the relevant standards disallow.  -fstrict-aliasing 
does exactly the opposite.

Richard.

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 12:56:26PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed from
> the standard -O# optimization levels and accessed orthogonally.  I think
> that I and the other members of the GCC Steering Committee had good
> intentions, but were mistaken about the impact of including this
> optimization in a -O# level. 

But have we seen much impact yet (disregarding what people *think* should
be done?). Also the issue seems not to be aliasing as such, but that
aliasing might break cases where there is no benefit in doing so.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 12:56:26PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed from
> the standard -O# optimization levels and accessed orthogonally.  I think
> that I and the other members of the GCC Steering Committee had good
> intentions, but were mistaken about the impact of including this
> optimization in a -O# level. 

But have we seen much impact yet (disregarding what people *think* should
be done?). Also the issue seems not to be aliasing as such, but that
aliasing might break cases where there is no benefit in doing so.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> The only issue here is whether it should be turned on by default for -O#.

Marc> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
Marc> good idea. It's an issue of whether we consider this optimization as
Marc> `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
Marc> as well, as it should decrease the code size. In the second case, I see
Marc> no reason to treat it differently from -ffast-math.

	I think that -ffast-math and the behavior of compilers from other
vendors is good precedent that -fstrict-aliasing should be removed from
the standard -O# optimization levels and accessed orthogonally.  I think
that I and the other members of the GCC Steering Committee had good
intentions, but were mistaken about the impact of including this
optimization in a -O# level. 

David

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 01:02:51PM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.

Thats not pgcc's idea. "Unsafe" optimizations are off at all optimization
levels.

The distinction between -O2 and higher is that its easy to test
("experimental compiler"), since bugs with -O2 are most probably gcc bugs.

> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
> good idea. It's an issue of whether we consider this optimization as
> `safe' or `unsafe'.

No, it's an issue wether we define C as ISO C or (some variant).

But putting it at an higher optimization level makes it more special than
it is.

Maybe the _real_ issue is what will break at all? The asm checks "broke"
much more programs (glibc, linux-kernel, other kernels, drivers) then the
aliasing stuff.

At least I believe this until somebody gives me more than the two examples
(linux and openbsd) I have heard of yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Espie]

In article < 19990915020836.M3983@cerebro.laendle > you write:

>Maybe the _real_ issue is what will break at all? The asm checks "broke"
>much more programs (glibc, linux-kernel, other kernels, drivers) then the
>aliasing stuff.

Dubious comparison at best.  Completely off the point, in my opinion.
That you even think of it that way strikes me as a fairly strange, careless
philosophy.  The asm checks broke things in a plain, visible way: code that 
no longer compiles.

Whereas aliasing problems are NOT diagnosed by anything else than programs
suddenly stopping working, or exhibiting subtle bugs.

Granted, these problems are fairly infrequent, but they were subtle enough
that ALL affected programmers have developped some degree of paranoia about
it... and don't forget that we know that checking the code by hand is the only
sure way to find aliasing problems, unless there are prototypes everywhere and
absolutely no casts.

This is an issue of overall system quality.  Stuff that stops working
in obvious ways is simple to take care off.   To wit: I managed to fix the
OpenBSD kernels __asm__ trouble, even though I don't know much about most
platforms we run on.

Right now, the problem we ran into with -strict-aliasing has led us to turn
it off everywhere by default...  this is the only safe approach, as we have
about 200 Mb of code to audit... and it is probably never going to be turned
back on again for packages, as most of these programs are not that nicely
maintained, and there's just too much code to audit.

We'd rather spend our time looking for security holes.

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> Dubious comparison at best.  Completely off the point, in my opinion.
> That you even think of it that way strikes me as a fairly strange, careless
> philosophy.  The asm checks broke things in a plain, visible way: code that 
> no longer compiles.

No, you are wrong. you are talking about the errors that were added at a
later point.

I was unclear, it wasn't, in fact, the asm changes (these were only new
errors), but the changes in other optimizations that made many invalid
asms break where they worked before (unter certain circumstances).

It was only because so many programs broke that the checks have been
added.

Which was a very worthwhile thing to do. Just as warnings for the aliasing
case would be very worthwhile. I think people believed checking the asm
constraints could be very difficult as well.

> Whereas aliasing problems are NOT diagnosed by anything else than programs
> suddenly stopping working, or exhibiting subtle bugs.

Just as the asm breakages.

I think your posting indicates the real problem we have about this issue,
namely that it's largely misunderstood by most people, maybe even by me.

Or not even misunderstood.. it's not clear what the problem is. Whose code
broke?  And why is this different to any other optimization that caused
code to break without any indication (warning, error)?

It might well be the case that a very large part of the software breaks,
in which case it might be a good idea to disable that optimization, unless
we can't come up with good warnings.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> Dubious comparison at best.  Completely off the point, in my opinion.
> That you even think of it that way strikes me as a fairly strange, careless
> philosophy.  The asm checks broke things in a plain, visible way: code that 
> no longer compiles.

No, you are wrong. you are talking about the errors that were added at a
later point.

I was unclear, it wasn't, in fact, the asm changes (these were only new
errors), but the changes in other optimizations that made many invalid
asms break where they worked before (unter certain circumstances).

It was only because so many programs broke that the checks have been
added.

Which was a very worthwhile thing to do. Just as warnings for the aliasing
case would be very worthwhile. I think people believed checking the asm
constraints could be very difficult as well.

> Whereas aliasing problems are NOT diagnosed by anything else than programs
> suddenly stopping working, or exhibiting subtle bugs.

Just as the asm breakages.

I think your posting indicates the real problem we have about this issue,
namely that it's largely misunderstood by most people, maybe even by me.

Or not even misunderstood.. it's not clear what the problem is. Whose code
broke?  And why is this different to any other optimization that caused
code to break without any indication (warning, error)?

It might well be the case that a very large part of the software breaks,
in which case it might be a good idea to disable that optimization, unless
we can't come up with good warnings.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Espie]

In article < 19990915020836.M3983@cerebro.laendle > you write:

>Maybe the _real_ issue is what will break at all? The asm checks "broke"
>much more programs (glibc, linux-kernel, other kernels, drivers) then the
>aliasing stuff.

Dubious comparison at best.  Completely off the point, in my opinion.
That you even think of it that way strikes me as a fairly strange, careless
philosophy.  The asm checks broke things in a plain, visible way: code that 
no longer compiles.

Whereas aliasing problems are NOT diagnosed by anything else than programs
suddenly stopping working, or exhibiting subtle bugs.

Granted, these problems are fairly infrequent, but they were subtle enough
that ALL affected programmers have developped some degree of paranoia about
it... and don't forget that we know that checking the code by hand is the only
sure way to find aliasing problems, unless there are prototypes everywhere and
absolutely no casts.

This is an issue of overall system quality.  Stuff that stops working
in obvious ways is simple to take care off.   To wit: I managed to fix the
OpenBSD kernels __asm__ trouble, even though I don't know much about most
platforms we run on.

Right now, the problem we ran into with -strict-aliasing has led us to turn
it off everywhere by default...  this is the only safe approach, as we have
about 200 Mb of code to audit... and it is probably never going to be turned
back on again for packages, as most of these programs are not that nicely
maintained, and there's just too much code to audit.

We'd rather spend our time looking for security holes.

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 01:02:51PM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.

Thats not pgcc's idea. "Unsafe" optimizations are off at all optimization
levels.

The distinction between -O2 and higher is that its easy to test
("experimental compiler"), since bugs with -O2 are most probably gcc bugs.

> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
> good idea. It's an issue of whether we consider this optimization as
> `safe' or `unsafe'.

No, it's an issue wether we define C as ISO C or (some variant).

But putting it at an higher optimization level makes it more special than
it is.

Maybe the _real_ issue is what will break at all? The asm checks "broke"
much more programs (glibc, linux-kernel, other kernels, drivers) then the
aliasing stuff.

At least I believe this until somebody gives me more than the two examples
(linux and openbsd) I have heard of yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909141102.NAA18232@quatramaran.ens.fr >you write:
  > Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
  > good idea. It's an issue of whether we consider this optimization as
  > `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
  > as well, as it should decrease the code size. In the second case, I see
  > no reason to treat it differently from -ffast-math.
If you write correct code, the compiler will generate correct code with
strict aliasing.  If you write incorrect code, all bets are off.

It's not significantly different than automatic register allocation -- if you
write correct code, automatic register allocation will generate correct code.
If you write incorrect code, all bets are off.

Do you really want to punish people who write correct code just because your
code is not correct?

jeff

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909141102.NAA18232@quatramaran.ens.fr >you write:
  > Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
  > good idea. It's an issue of whether we consider this optimization as
  > `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
  > as well, as it should decrease the code size. In the second case, I see
  > no reason to treat it differently from -ffast-math.
If you write correct code, the compiler will generate correct code with
strict aliasing.  If you write incorrect code, all bets are off.

It's not significantly different than automatic register allocation -- if you
write correct code, automatic register allocation will generate correct code.
If you write incorrect code, all bets are off.

Do you really want to punish people who write correct code just because your
code is not correct?

jeff

Re: type based aliasing again

[Marc Espie]

In article < e629bdfd.250f2c9c@aol.com > you write:
>> It's certainly within a reasonable "umbrella" approach of having
>>  increasing optimization levels be about increasing reliance on
>>  the code strictly conforming to the pertinent standard, even its
>>  "tricky bits".
>>  
>>  The biggest problem I see with it right now is that we haven't
>>  exactly taken that "umbrella" approach in the past in a consistent
>>  way.

>And it may not be the most useful scheme either.  With gcc-2.96 we are back 
>to -Os being faster running most of the time than -O2 or -O3 on x86, with 
>-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
>the application) needed for best results.  We would want to continue the 
>ability to get strict-aliasing at -Os.   I suppose we have no say on the 
>peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
>specifically turned off; always off at -Os even when it would save space.

You can always turn strict-aliasing on or off explicitly with
-fstrict-aliasing or -fno-strict-aliasing.

The only issue here is whether it should be turned on by default for -O#.

I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.
The pgcc guys can do what they want... after all, pgcc was touted as a 
very fast, highly experimental compiler. Whereas gcc is supposed to be stable.

Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
good idea. It's an issue of whether we consider this optimization as
`safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
as well, as it should decrease the code size. In the second case, I see
no reason to treat it differently from -ffast-math.

Re: type based aliasing again

[N8TM]

> It's certainly within a reasonable "umbrella" approach of having
>  increasing optimization levels be about increasing reliance on
>  the code strictly conforming to the pertinent standard, even its
>  "tricky bits".
>  
>  The biggest problem I see with it right now is that we haven't
>  exactly taken that "umbrella" approach in the past in a consistent
>  way.

And it may not be the most useful scheme either.  With gcc-2.96 we are back 
to -Os being faster running most of the time than -O2 or -O3 on x86, with 
-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
the application) needed for best results.  We would want to continue the 
ability to get strict-aliasing at -Os.   I suppose we have no say on the 
peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
specifically turned off; always off at -Os even when it would save space.

Commercial compilers have completely broken the old scheme of things also.  
They generally accept -O but it doesn't mean much.  Maximum optimization may 
be the default (Lahey) or normal high optimization may take quite a string of 
things like -Ofast 
-OPT:fold_reassociate=OFF:IEEE_comparisons=ON:unroll_times_max=2 -TENV:X=1 
(MipsPro).  So maybe the most confusing thing about gnu is the way the 
options have changed over time without much explanation (except for 
strict-aliasing).

Tim

Re: type based aliasing again

[Mike Stump]

> Date: Sat, 11 Sep 1999 03:24:30 -0400
> From: Richard Stallman <rms@gnu.org>

> I agree, too.  When we add a new feature, we should document it
> clearly, and undertake to support it.

> I've made a proposal for a change which is not an extension, not a
> feature--but will give users more of what they expect.  If you're
> thinking of it as a kind of feature, you're not responding to the
> proposal that I made.

Ah, but you're not thinking of this like a user.  As a user, it
_would_ be a feature, and they would expect it.  We already know this
today.  Review the Linux thread as to why a user would consider this a
feature.  All the long time readers of this list know exactly what I
am talking about, they have seen it first hand, and the problems it
creates.  We have been burned (if you will) by this, and we are trying
to avoid being burned by it again.

Re: type based aliasing again

[Richard Stallman]

    Ah, but you're not thinking of this like a user.  As a user, it
    _would_ be a feature, and they would expect it.

I've seen several people have made this claim, but they took
it for granted, rather than trying to justify the claim.
I don't believe it, and here is an argument for why not.

If you believe that the mere fact that some cases "work as expected"
will have this effect, even if we say nothing about it to the users,
then this is happening now.  Maybe half of these cases work as expected
with -O1, and all of them work with -O0.

The only way to prevent this is to implement -fconfound-me.

      Review the Linux thread as to why a user would consider this a
    feature.

If you tell me precisely where to find these messages, I will read
them.  I can barely make the time to have this discussion, and I will
make time to read the messages, but I can't make time to *find* the
messages as well.


You are arguing for a position that rejects the very idea of making an
effort to keep old code working.  Your arguments support a general
conclusion that "If code is not unambiguously valid, it is better to
break the code than to keep it working."

This is not just a harsh policy, it is an explicit policy of being
harsh.  That is, it says, "Be harsh!  Choose the alternative that is
harsh!"  This is the opposite of the way we should treat our users.

I understand that your views are not based on sadism or cruelty; you
think that treating users harshly is better for them.  But your
motivation, like my motivation, is not the issue anyway.  To adopt a
policy of harshness towards people--no matter what justification is
offered for it--is treating them badly.  That is the wrong way to
treat the users.  We must not make GCC decisions based on a policy of
harshness.

I would like future GCC decisions to be based on the policy that
keeping old code working is a good thing to do, when it is practical
of course.

So if any argument leads to the conclusion that one should be harsh to
the users, please recognize where the argument is taking you, and
reject it on the grounds that it is a disguised policy of harshness.

In particular, if it is argued that a policy of kindness has a
disadvantage, and it turns out that the disadvantage is a consequence
of the fact that the users have been treated kindly, it is really a
disguised policy of harshness.

Re: type based aliasing again

[Richard Stallman]

    Ah, but you're not thinking of this like a user.  As a user, it
    _would_ be a feature, and they would expect it.

I've seen several people have made this claim, but they took
it for granted, rather than trying to justify the claim.
I don't believe it, and here is an argument for why not.

If you believe that the mere fact that some cases "work as expected"
will have this effect, even if we say nothing about it to the users,
then this is happening now.  Maybe half of these cases work as expected
with -O1, and all of them work with -O0.

The only way to prevent this is to implement -fconfound-me.

      Review the Linux thread as to why a user would consider this a
    feature.

If you tell me precisely where to find these messages, I will read
them.  I can barely make the time to have this discussion, and I will
make time to read the messages, but I can't make time to *find* the
messages as well.


You are arguing for a position that rejects the very idea of making an
effort to keep old code working.  Your arguments support a general
conclusion that "If code is not unambiguously valid, it is better to
break the code than to keep it working."

This is not just a harsh policy, it is an explicit policy of being
harsh.  That is, it says, "Be harsh!  Choose the alternative that is
harsh!"  This is the opposite of the way we should treat our users.

I understand that your views are not based on sadism or cruelty; you
think that treating users harshly is better for them.  But your
motivation, like my motivation, is not the issue anyway.  To adopt a
policy of harshness towards people--no matter what justification is
offered for it--is treating them badly.  That is the wrong way to
treat the users.  We must not make GCC decisions based on a policy of
harshness.

I would like future GCC decisions to be based on the policy that
keeping old code working is a good thing to do, when it is practical
of course.

So if any argument leads to the conclusion that one should be harsh to
the users, please recognize where the argument is taking you, and
reject it on the grounds that it is a disguised policy of harshness.

In particular, if it is argued that a policy of kindness has a
disadvantage, and it turns out that the disadvantage is a consequence
of the fact that the users have been treated kindly, it is really a
disguised policy of harshness.

Re: type based aliasing again

[Mike Stump]

> Date: Sat, 11 Sep 1999 03:24:30 -0400
> From: Richard Stallman <rms@gnu.org>

> I agree, too.  When we add a new feature, we should document it
> clearly, and undertake to support it.

> I've made a proposal for a change which is not an extension, not a
> feature--but will give users more of what they expect.  If you're
> thinking of it as a kind of feature, you're not responding to the
> proposal that I made.

Ah, but you're not thinking of this like a user.  As a user, it
_would_ be a feature, and they would expect it.  We already know this
today.  Review the Linux thread as to why a user would consider this a
feature.  All the long time readers of this list know exactly what I
am talking about, they have seen it first hand, and the problems it
creates.  We have been burned (if you will) by this, and we are trying
to avoid being burned by it again.

Re: type based aliasing again

[R. Kelley Cook]

On 13 Sep 1999 13:05:39 +0200, Richard Earnshaw wrote:

>
>mark@codesourcery.com said:
>> I think that making -fno-strict-aliasing the default is sensible
>> proposal, and worth debating.
>
>
>It is the default at -O1 or less.  I would be inclined to argue that this 
>should be adequate for "legacy" code and that the higher levels of 
>optimization should be allowed to fully exploit the provisions of the C 
>standard (this is not to suggest that a warning shouldn't be generated if 
>possible).
>
>We are somewhat constrained by our relatively limited number of 
>optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
>mainly because of a user-education issue.  But it would be useful if we 
>could have a level above which we say that we assume that code fully 
>conforms to the C (or other relevant) standard.
>

What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and
have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing").  This would
guarantee all current software and their make files to still generate correct
code, yet still make it extremely easy to enable the optimizations for fully
ISO/ANSI compliant software.

Its seems like far too easy a solution to me.

 -- Kelley Cook

Re: type based aliasing again

[craig]

>What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and
>have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing").  This would
>guarantee all current software and their make files to still generate correct
>code, yet still make it extremely easy to enable the optimizations for fully
>ISO/ANSI compliant software.
>
>Its seems like far too easy a solution to me.

It's certainly within a reasonable "umbrella" approach of having
increasing optimization levels be about increasing reliance on
the code strictly conforming to the pertinent standard, even its
"tricky bits".

The biggest problem I see with it right now is that we haven't
exactly taken that "umbrella" approach in the past in a consistent
way.

If we start now, there'll be some hiccups -- people who currently
compile and run their code quite happily at -O2 or -O3 would
presumably experience a drop in performance when using a new
version of GCC that changes (practically, reverts) to assuming
of -fno-alias-analysis, as compared to 2.95, which assumes
the opposite.

The other problem I see with relying on -O levels to denote
rough degree of conformance to language standard is that we
already use it to (again, roughly) indicate willingness to
tolerate long compile times and (or at least in the past) to
indicate willingness to run recently coded, or not-entirely-trusted,
optimization phases.

The former problem would be short-term, and the latter problem
we could address using some other convention for one or more
of the meanings.  Perhaps we could introduce a general-purpose
option such as `-fconformance=LEVEL', where LEVEL could be "loose",
"typical", "strict", "pristine", in that order, and have -falias-analysis
be triggered at levels "strict" and "pristine".  Not exactly ideal,
but roughly conforms with the general thrust of some of the concerns
expressed in this and other threads....

        tq vm, (burley)

Re: type based aliasing again

[craig]

>What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and
>have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing").  This would
>guarantee all current software and their make files to still generate correct
>code, yet still make it extremely easy to enable the optimizations for fully
>ISO/ANSI compliant software.
>
>Its seems like far too easy a solution to me.

It's certainly within a reasonable "umbrella" approach of having
increasing optimization levels be about increasing reliance on
the code strictly conforming to the pertinent standard, even its
"tricky bits".

The biggest problem I see with it right now is that we haven't
exactly taken that "umbrella" approach in the past in a consistent
way.

If we start now, there'll be some hiccups -- people who currently
compile and run their code quite happily at -O2 or -O3 would
presumably experience a drop in performance when using a new
version of GCC that changes (practically, reverts) to assuming
of -fno-alias-analysis, as compared to 2.95, which assumes
the opposite.

The other problem I see with relying on -O levels to denote
rough degree of conformance to language standard is that we
already use it to (again, roughly) indicate willingness to
tolerate long compile times and (or at least in the past) to
indicate willingness to run recently coded, or not-entirely-trusted,
optimization phases.

The former problem would be short-term, and the latter problem
we could address using some other convention for one or more
of the meanings.  Perhaps we could introduce a general-purpose
option such as `-fconformance=LEVEL', where LEVEL could be "loose",
"typical", "strict", "pristine", in that order, and have -falias-analysis
be triggered at levels "strict" and "pristine".  Not exactly ideal,
but roughly conforms with the general thrust of some of the concerns
expressed in this and other threads....

        tq vm, (burley)

Re: type based aliasing again

[R. Kelley Cook]

On 13 Sep 1999 13:05:39 +0200, Richard Earnshaw wrote:

>
>mark@codesourcery.com said:
>> I think that making -fno-strict-aliasing the default is sensible
>> proposal, and worth debating.
>
>
>It is the default at -O1 or less.  I would be inclined to argue that this 
>should be adequate for "legacy" code and that the higher levels of 
>optimization should be allowed to fully exploit the provisions of the C 
>standard (this is not to suggest that a warning shouldn't be generated if 
>possible).
>
>We are somewhat constrained by our relatively limited number of 
>optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
>mainly because of a user-education issue.  But it would be useful if we 
>could have a level above which we say that we assume that code fully 
>conforms to the C (or other relevant) standard.
>

What would be wrong with -fno-strict-aliasing the default for -O(1,2,3,s) and
have a new -O4 enable it (ie "-O4" == "-O3 -fstrict-aliasing").  This would
guarantee all current software and their make files to still generate correct
code, yet still make it extremely easy to enable the optimizations for fully
ISO/ANSI compliant software.

Its seems like far too easy a solution to me.

 -- Kelley Cook

Re: type based aliasing again

[Josh Stern]

This is an interesting discussion.  I'd like
to throw out a couple of possible approaches which were
not explicitly considered in the discussion.

A1) The current tradition in gcc is to make -Wall a
combination of other, individually specifiable,
warning options.  One possible approach to the current
issue involves either changing this tradition, or 
making a new catch-all option -Wsuper,
which can warn about additional constructs 
"which pertain to usage that we recommend avoiding
and that we believe it is easy to avoid", with the
idea that the type aliasing violations which 
can easily be detected using current technology would be
warned about.  The idea naturally would be to
also warn about other likely problems which don't
get their own individual warning option categoy, 
for whatever reason.
  
Why consider this?  A number of developers have
basically expressed the position that all of the
current proposals amount to either i. penalizing
the (code performance of the) many for the sake 
of the few (ugly bit-twiddlings that break), or
ii. providing a set of warnings which is not
a natural category unto itself and which could lead
to false assumptions about what is and is not detected
by the compiler.  This proposal would allow the compiler
to add warnings about the most egregrious, easily
detectable type aliasing problems, to the simplest
and most convenient user-selectable warning option
without a lot of semantic mess about what to call
the category.   Clearly, the overall appeal of
the idea would very much depend on the extent to
which the proposal would be helpful with other
similar kinds of  issues.  


A2) Add a new feature -CVersion X.YZ meaning the
compiler attempts, on a best effort basis, to
generate correct code for the dialect of
C that yielded correct code with the older
version X.YZ of the compiler (could be useful
for C++ and other languages as well).  If this 
feature is not implemented for version X.YZ, then
either warn or exit with an error.  The 
documentation for this feature would have be
very emphatic about the fact that it is just
provided on a best effort basis, and will not
be 100% correct (even if the category of 
correctness for the feature was precisely
defineable, which it isn't), and perhaps mention
the alternative of -V X.YZ for 100% compatibility,
providing version X.YZ is installed.

Why consider this?  Because a lot, perhaps
a majority. of application programmers rely,
implicitly or explicitly, on their compiler of 
choice as a guide to correctness standards for 
their language of choice.  When that pseudo-standard
changes from version to version of the compiler,
and their code breaks, it causes inconvenience.
If there is a lot of code that breaks and no
maintainer for it, then it can cause a lot
of inconvenience.  This feature also has the
potential to be very convenient from the
vantage point of anyone doing tech support.


- Josh

Re: type based aliasing again

[Josh Stern]

This is an interesting discussion.  I'd like
to throw out a couple of possible approaches which were
not explicitly considered in the discussion.

A1) The current tradition in gcc is to make -Wall a
combination of other, individually specifiable,
warning options.  One possible approach to the current
issue involves either changing this tradition, or 
making a new catch-all option -Wsuper,
which can warn about additional constructs 
"which pertain to usage that we recommend avoiding
and that we believe it is easy to avoid", with the
idea that the type aliasing violations which 
can easily be detected using current technology would be
warned about.  The idea naturally would be to
also warn about other likely problems which don't
get their own individual warning option categoy, 
for whatever reason.
  
Why consider this?  A number of developers have
basically expressed the position that all of the
current proposals amount to either i. penalizing
the (code performance of the) many for the sake 
of the few (ugly bit-twiddlings that break), or
ii. providing a set of warnings which is not
a natural category unto itself and which could lead
to false assumptions about what is and is not detected
by the compiler.  This proposal would allow the compiler
to add warnings about the most egregrious, easily
detectable type aliasing problems, to the simplest
and most convenient user-selectable warning option
without a lot of semantic mess about what to call
the category.   Clearly, the overall appeal of
the idea would very much depend on the extent to
which the proposal would be helpful with other
similar kinds of  issues.  


A2) Add a new feature -CVersion X.YZ meaning the
compiler attempts, on a best effort basis, to
generate correct code for the dialect of
C that yielded correct code with the older
version X.YZ of the compiler (could be useful
for C++ and other languages as well).  If this 
feature is not implemented for version X.YZ, then
either warn or exit with an error.  The 
documentation for this feature would have be
very emphatic about the fact that it is just
provided on a best effort basis, and will not
be 100% correct (even if the category of 
correctness for the feature was precisely
defineable, which it isn't), and perhaps mention
the alternative of -V X.YZ for 100% compatibility,
providing version X.YZ is installed.

Why consider this?  Because a lot, perhaps
a majority. of application programmers rely,
implicitly or explicitly, on their compiler of 
choice as a guide to correctness standards for 
their language of choice.  When that pseudo-standard
changes from version to version of the compiler,
and their code breaks, it causes inconvenience.
If there is a lot of code that breaks and no
maintainer for it, then it can cause a lot
of inconvenience.  This feature also has the
potential to be very convenient from the
vantage point of anyone doing tech support.


- Josh

Re: type based aliasing again

[Richard Stallman]

    If we failed to document this feature (and IMHO, it is a feature),

If you think it is a feature, it seems we are failing to communicate,
because what I have proposed is nothing whatever like a feature.

								       then a
    not-so-wise programmer might assume that the compiler is always going to
    detect violations of ISO aliasing rules, and arrange to work around the
    ISO aliasing violations.

You haven't explained how you reach this conclusion, but it suggests
that the proposal you are considering is not the one I made.  I think
you are considering some kind of idea for a new feature.

Please try to think outside of the "feature" box.  If the only kind of
solution you can entertain is some kind of new feature, you will often
be forced to choose between two undesirable alternatives.  Please try
to entertain another kind of solution.

Re: type based aliasing again

[Richard Stallman]

    If we failed to document this feature (and IMHO, it is a feature),

If you think it is a feature, it seems we are failing to communicate,
because what I have proposed is nothing whatever like a feature.

								       then a
    not-so-wise programmer might assume that the compiler is always going to
    detect violations of ISO aliasing rules, and arrange to work around the
    ISO aliasing violations.

You haven't explained how you reach this conclusion, but it suggests
that the proposal you are considering is not the one I made.  I think
you are considering some kind of idea for a new feature.

Please try to think outside of the "feature" box.  If the only kind of
solution you can entertain is some kind of new feature, you will often
be forced to choose between two undesirable alternatives.  Please try
to entertain another kind of solution.

Re: type based aliasing again

[N8TM]

In a message dated 9/11/99 8:22:15 PM EST, pedwards@jaj.com writes:

> it's not evil (illegal), it's just handicapped or elderly (invalid)?
I would agree with those epithets applied to the source code for struct, but 
it works fine (on linux and unix, not on cygwin) with strict-aliasing.  It 
uses plenty of untyped pointers.  I haven't had to fix any bugs in it for 10 
years.

Tim
tprince@computer.org

Re: type based aliasing again

[N8TM]

In a message dated 9/11/99 8:22:15 PM EST, pedwards@jaj.com writes:

> it's not evil (illegal), it's just handicapped or elderly (invalid)?
I would agree with those epithets applied to the source code for struct, but 
it works fine (on linux and unix, not on cygwin) with strict-aliasing.  It 
uses plenty of untyped pointers.  I haven't had to fix any bugs in it for 10 
years.

Tim
tprince@computer.org

Re: type based aliasing again

[craig]

RMS wrote:
> In C, we cannot divide all user code into "right" and "wrong" in this
> kind of simple way, and certainly not based on the ISO standard.  That
> standard is just the decisions of a certain committee (which I was a
> member of) about what cases conforming compilers should commit to
> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

Saying the standard is "just the decisions of a certain committee" is
like saying C is "just a language made up by bored hackers".

If you're prepared to offer substantial replacements for the care,
consideration, expertise, thoughtfulness, expectation of public
participation in the process, and so on, that the C standards
committee (presumably) provides, fine.

But, I've watched (reasonably carefully) how successful this attitude
of "ignore the standards bodies except when we find them convenient"
has worked since I first heard about GNU using it so many years ago
(at which point I found it *very* persuasive).

To put it simply, it's a failure when it comes to the C language,
as far as I can tell.  The very people who seem most
enthusiastic about their ability and willingness to substitute
their designs for those of a standards body, while insisting on
using the same name that body goes to substantial effort to preserve
as a going concern, are the ones who strike me as least willing
to spend substantial time and effort designing their variant of
the language, specifying it, patiently calling for public comment
and *listening* to it, ensuring it's widely understood in terms of
its differences vis-a-vis its "standard" namesake, and documenting
it.  (If you think documenting and specifying are the same, you're
wrong -- the C standard is a specification, all those books
describing how to write C code is documentation.  If you replace
the standards body, you not only must write the specification yourself,
you must write the first documentation yourself, and, further, give
authors of documentation some incentive to write documents for your
language.  I don't think "C minus the silly aliasing restriction"
is enough incentive, since I don't believe anybody's published
serious end-programmer documentation on the GNU C language, despite
all its extensions.)

So, yes, we support many extensions in GCC, and that's nice, when
looked at in isolation.  But when I think of all the bug reports
I've seen, all the confusion over how these features are supposed
to work, the lack of clear documentation *or* specifications regarding
these extensions and their interactions with each other, and the lack
of adequate testing of many of them, I think that, overall, the attitude
that we can do things our own way has led to an overall failure to
provide a C compiler that users can rely upon *now* and in the *future*
to correctly compile the (GNU C, not just ISO C) code they write.

Particularly insidious is this practice of redefining constructs
that aren't blatantly non-standard in a small chunk of code.  Which
is what RMS (and Linus) appears to want, without users having to specify
-fno-strict-aliasing -- an option that at least gives users *some*
heads-up about the code being in some special dialect, not C.

It's one thing for an expert in ISO C to recognize that
"... __complex__ float x; ..." is obviously not ISO C code.
The "__complex__", or similarly undefined, keyword, gives such
things away.

It's entirely another thing for such an expert to see some code
making references via pointers, see *nothing* wrong with the code
vis-a-vis ISO C, and thus reasonably assume that, since it works
on a wide variety of architectures, that code is playing *no*
aliasing games...and then be proven wrong, because what he *didn't*
know is that the code requires an RMS C compiler to work, because
it *is* playing aliasing games.  By which time, he's devoted many
hours, perhaps days, to making changes to that code (just a portion
of a program, so the *other* portions had to work together with it
to violate the aliasing rules), changes that are then recognized
as a huge waste of time.

If you, the reader, don't grasp what I'm saying there, that's okay,
all it means is you don't understand some basic language-design
principles.  It doesn't mean you're not a great programmer, it just
means you shouldn't be doing language design (e.g. proposing changes
to a language or dialect, especially not pushing for them from
a position of power).

But I'll illustrate (in Fortran, since it's actually clearer) this
concept with an example.  Suppose Barney Super Fortran Programmer
is looking at code like this:

   SUBROUTINE X (A, B)
   ...
   A = B * 2
   ...
   B = B + 9
   ...
   END

No matter what the "call tree" from X down looks like, he *knows*
that, assuming the code is considered "correct" according to the
Fortran standards (and there's no command-line options used to
compile it to say otherwise), e.g. it runs on a wide variety
of platforms, that A *cannot* alias B.

Given that knowledge, he need *not* examine *any* callers of X
to see whether A actually *might* alias B.

That means he can, *legitimately*, change that code to read:

   SUBROUTINE X (A, B)
   ...
   TMPB = B
   B = B + 9
   A = TMPB * 2
   ...
   ...
   END

(All he has to do is ensure that the "..." following A don't explicitly
reference B...the usual sorts of things that programmers check for.)

Never mind why he might want to make that change.  Maybe it's for
performance reasons.

The point is, he *can* make that change because he *knows* A and B don't
alias each other.  Period.  End of story.

But wait!  Turns out this code is always compiled by RMS Fortran.  RMS
decided this aliasing prohibition, put in by the Fortran standards
committee back in the '70s and preserved ever since, was just silly,
so he eliminated it from his dialect.  (Maybe he only *partially*
eliminated it, by saying "let's do a cost/performance analysis each
time we considered breaking code like the above in a given instance",
and the net result was the same -- most RMS Fortran users thinking
there were no alias restrictions in the language, because they always
got away with that, except perhaps in "extremely obvious" instances
such as small self-contained DO loops.)

But he called his dialect "Fortran" anyway, called his compiler
"RMS Fortran" (as versus his operating system, which is called
"...*not* Unix"), and thus set the stage for Barney, our super-programmer,
wasting his time by adding bugs to working code.

How?  Because it turns out X *does* get called with A and B aliased,
that the caller *relies* on the changing of A happening before B is
modified, and that the caller is thus *highly* sensitive to the particular
ordering of the modifications.

In other words, while X looks like it is written in standard Fortran,
and while every single one of X's callers, *in isolation* (without
looking at X itself), might look like *they* are written in standard
Fortran, the reality is, the whole *program* is, in fact, *not* standard
Fortran.  It is RMS Fortran.  The original programmers of that
code got away with it because the compiler happened to avoid ever
reordering things like that, except in instances "everybody" -- meaning
only those RMS Fortran users truly paying attention to these issues -
would agree such reordering was desirable.

And the result is buggy code.

All of the usual responses -- "well, if Barney was so good, why didn't
he read the docs", for example -- would have applied just as well
if RMS hadn't changed the dialect in this way and left it up to
*Fortran* programmers to read the industry-standard *Fortran* specification
and the widely published books on *Fortran* programming.

Further, the *overall* quality of the RMS Fortran product plus RMS
Fortran code is *lower*, because it is less of a good language.
That is, it plays tricks -- appearing to mean one thing, when it
means another, leading people who misunderstand it to break code
written in it.

So, to cater to the mediocre programmers who won't read *any* docs,
not even the widely published ones on the general language they're
using, we *do*, in fact, punish the *great* programmers who *do*
read the *right* docs, but to whom we've given no adequate notice,
in instances such as the above, that there are some *other* docs
they need to go read and study.

(Yes, the quality of those industry-wide specifications and docs
might be low.  That's a separately addressed problem, to be
fixed by offering better ones, *not* by changing the language being
specified.)

If you're going to insist that we continue to chart our own course
for the language GCC compiles vis-a-vis ISO C, then I suggest you
consider renaming *that* language to something else, like "GNU P",
so as to avoid confusing users.

After all, you insisted the EGCS project be named EGCS, not GCC3,
to avoid confusing users.  I suggest you (RMS) apply the Golden Rule
here -- if you were so concerned about EGCS polluting the "good name"
of GCC back then, I suggest you consider how the ISO C people feel
about this continued willingness of the GCC people to say they
compile code written in something called "C", when they're at the
same time so willing to say "ISO C is just a committee" to excuse
ignoring, whenever convenient, what ISO C says about what C "means"
as a language name.

Then, when GNU P has proven to be a better C language than ISO C,
such that the *overall* community prefers it just as it ended up
prefering EGCS to GCC2, we can rename everything back.

No, I'm not arguing for "aggressively breaking bad code", because
I don't think that's wise, taken literally -- and because I
know it's pretty hard to do, and would actually make code *slower*.

I agree with what I think Mark *meant* by that phrase, though, which
is "let's not bother trying to make all sorts of cost/benefit analyses
for every possible conflict between some optimization and whether
that might break some existing bad code out there".  We have better things
to do with our time, like make sure GCC generates *fast* code and that,
when compiled with -fno-strict-aliasing, it generates code that accommodates
the aliasing bug in user code.

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

      The very people who seem most
    enthusiastic about their ability and willingness to substitute
    their designs for those of a standards body, while insisting on
    using the same name that body goes to substantial effort to preserve
    as a going concern, are the ones who strike me as least willing
    to spend substantial time and effort designing their variant of
    the language, specifying it, patiently calling for public comment
    and *listening* to it, ensuring it's widely understood in terms of
    its differences vis-a-vis its "standard" namesake, and documenting
    it.

You are right about this.  I'm the person who designed and implemented
most of the GNU C extensions, and I never even considered going
through that laborious procedure.  There was no need for it.

That painstaking approach is called for in some situations--for
example, when trying to work out an agreement between many compiler
developers and users.  I've sometimes taken some pains to check a
particular decision, though not as much as a standards committee does.
But there is normally no need for that in adding a feature to a
language--if you are capable of doing a good job without it.

    Saying the standard is "just the decisions of a certain committee" is
    like saying C is "just a language made up by bored hackers".

When I say that the standard is just the decisions of the committee,
this is not to denigrate the people on the committee.  (I was one of
them.)  I am saying that the committee's decisions are not sacred
merely because they are called a "standard".  Some of you may have
heard me say that laws are just the decisions of a government.  Laws
can be wrong, and a standard committee's decisions can be wrong too.

I saw the POSIX commitee totally ignore the overwhelming opinion of
the users on one issue, and that's where the POSIXLY_CORRECT
environment variable that affects GNU df and GNU du comes from.  The
leaders of the committee cited legalistic, abstract, and procedural
reasons to ignore the practical issue that the users cared about;
their attitude was utterly rigid.  (Amazingly like a government agency
;-).

It is not only standards committees and government agencies that can
act that way.  There is a great temptation for the developer of a
program to act that way, whether it be an individual, an organized
committee, or an amorphous group such as the people who reach
conclusions on this list.  Any of us could fall into it, unless we
make a conscious effort to guard ourselves from it.

The ANSI C standard was a good job, overall, and there are few places
in it I wanted criticize.  But even when a standard was designed well
*as a standard*, we should not follow it slavishly.  The goals for a
standard are different from the goals of a compiler.

We should follow the standard in the ways that benefit the users.  If
users write programs according to the standard, and GCC does not
handle them according to the standard, the users will find GCC rather
unsatisfactory.  For this reason, with rare exceptions it is essential
to support all the programs that the standard says are valid.

To break all programs because the standard says they are unspecified
is another matter entirely.

Re: type based aliasing again

[Richard Stallman]

      The very people who seem most
    enthusiastic about their ability and willingness to substitute
    their designs for those of a standards body, while insisting on
    using the same name that body goes to substantial effort to preserve
    as a going concern, are the ones who strike me as least willing
    to spend substantial time and effort designing their variant of
    the language, specifying it, patiently calling for public comment
    and *listening* to it, ensuring it's widely understood in terms of
    its differences vis-a-vis its "standard" namesake, and documenting
    it.

You are right about this.  I'm the person who designed and implemented
most of the GNU C extensions, and I never even considered going
through that laborious procedure.  There was no need for it.

That painstaking approach is called for in some situations--for
example, when trying to work out an agreement between many compiler
developers and users.  I've sometimes taken some pains to check a
particular decision, though not as much as a standards committee does.
But there is normally no need for that in adding a feature to a
language--if you are capable of doing a good job without it.

    Saying the standard is "just the decisions of a certain committee" is
    like saying C is "just a language made up by bored hackers".

When I say that the standard is just the decisions of the committee,
this is not to denigrate the people on the committee.  (I was one of
them.)  I am saying that the committee's decisions are not sacred
merely because they are called a "standard".  Some of you may have
heard me say that laws are just the decisions of a government.  Laws
can be wrong, and a standard committee's decisions can be wrong too.

I saw the POSIX commitee totally ignore the overwhelming opinion of
the users on one issue, and that's where the POSIXLY_CORRECT
environment variable that affects GNU df and GNU du comes from.  The
leaders of the committee cited legalistic, abstract, and procedural
reasons to ignore the practical issue that the users cared about;
their attitude was utterly rigid.  (Amazingly like a government agency
;-).

It is not only standards committees and government agencies that can
act that way.  There is a great temptation for the developer of a
program to act that way, whether it be an individual, an organized
committee, or an amorphous group such as the people who reach
conclusions on this list.  Any of us could fall into it, unless we
make a conscious effort to guard ourselves from it.

The ANSI C standard was a good job, overall, and there are few places
in it I wanted criticize.  But even when a standard was designed well
*as a standard*, we should not follow it slavishly.  The goals for a
standard are different from the goals of a compiler.

We should follow the standard in the ways that benefit the users.  If
users write programs according to the standard, and GCC does not
handle them according to the standard, the users will find GCC rather
unsatisfactory.  For this reason, with rare exceptions it is essential
to support all the programs that the standard says are valid.

To break all programs because the standard says they are unspecified
is another matter entirely.

Re: type based aliasing again

[craig]

RMS wrote:
> In C, we cannot divide all user code into "right" and "wrong" in this
> kind of simple way, and certainly not based on the ISO standard.  That
> standard is just the decisions of a certain committee (which I was a
> member of) about what cases conforming compilers should commit to
> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

Saying the standard is "just the decisions of a certain committee" is
like saying C is "just a language made up by bored hackers".

If you're prepared to offer substantial replacements for the care,
consideration, expertise, thoughtfulness, expectation of public
participation in the process, and so on, that the C standards
committee (presumably) provides, fine.

But, I've watched (reasonably carefully) how successful this attitude
of "ignore the standards bodies except when we find them convenient"
has worked since I first heard about GNU using it so many years ago
(at which point I found it *very* persuasive).

To put it simply, it's a failure when it comes to the C language,
as far as I can tell.  The very people who seem most
enthusiastic about their ability and willingness to substitute
their designs for those of a standards body, while insisting on
using the same name that body goes to substantial effort to preserve
as a going concern, are the ones who strike me as least willing
to spend substantial time and effort designing their variant of
the language, specifying it, patiently calling for public comment
and *listening* to it, ensuring it's widely understood in terms of
its differences vis-a-vis its "standard" namesake, and documenting
it.  (If you think documenting and specifying are the same, you're
wrong -- the C standard is a specification, all those books
describing how to write C code is documentation.  If you replace
the standards body, you not only must write the specification yourself,
you must write the first documentation yourself, and, further, give
authors of documentation some incentive to write documents for your
language.  I don't think "C minus the silly aliasing restriction"
is enough incentive, since I don't believe anybody's published
serious end-programmer documentation on the GNU C language, despite
all its extensions.)

So, yes, we support many extensions in GCC, and that's nice, when
looked at in isolation.  But when I think of all the bug reports
I've seen, all the confusion over how these features are supposed
to work, the lack of clear documentation *or* specifications regarding
these extensions and their interactions with each other, and the lack
of adequate testing of many of them, I think that, overall, the attitude
that we can do things our own way has led to an overall failure to
provide a C compiler that users can rely upon *now* and in the *future*
to correctly compile the (GNU C, not just ISO C) code they write.

Particularly insidious is this practice of redefining constructs
that aren't blatantly non-standard in a small chunk of code.  Which
is what RMS (and Linus) appears to want, without users having to specify
-fno-strict-aliasing -- an option that at least gives users *some*
heads-up about the code being in some special dialect, not C.

It's one thing for an expert in ISO C to recognize that
"... __complex__ float x; ..." is obviously not ISO C code.
The "__complex__", or similarly undefined, keyword, gives such
things away.

It's entirely another thing for such an expert to see some code
making references via pointers, see *nothing* wrong with the code
vis-a-vis ISO C, and thus reasonably assume that, since it works
on a wide variety of architectures, that code is playing *no*
aliasing games...and then be proven wrong, because what he *didn't*
know is that the code requires an RMS C compiler to work, because
it *is* playing aliasing games.  By which time, he's devoted many
hours, perhaps days, to making changes to that code (just a portion
of a program, so the *other* portions had to work together with it
to violate the aliasing rules), changes that are then recognized
as a huge waste of time.

If you, the reader, don't grasp what I'm saying there, that's okay,
all it means is you don't understand some basic language-design
principles.  It doesn't mean you're not a great programmer, it just
means you shouldn't be doing language design (e.g. proposing changes
to a language or dialect, especially not pushing for them from
a position of power).

But I'll illustrate (in Fortran, since it's actually clearer) this
concept with an example.  Suppose Barney Super Fortran Programmer
is looking at code like this:

   SUBROUTINE X (A, B)
   ...
   A = B * 2
   ...
   B = B + 9
   ...
   END

No matter what the "call tree" from X down looks like, he *knows*
that, assuming the code is considered "correct" according to the
Fortran standards (and there's no command-line options used to
compile it to say otherwise), e.g. it runs on a wide variety
of platforms, that A *cannot* alias B.

Given that knowledge, he need *not* examine *any* callers of X
to see whether A actually *might* alias B.

That means he can, *legitimately*, change that code to read:

   SUBROUTINE X (A, B)
   ...
   TMPB = B
   B = B + 9
   A = TMPB * 2
   ...
   ...
   END

(All he has to do is ensure that the "..." following A don't explicitly
reference B...the usual sorts of things that programmers check for.)

Never mind why he might want to make that change.  Maybe it's for
performance reasons.

The point is, he *can* make that change because he *knows* A and B don't
alias each other.  Period.  End of story.

But wait!  Turns out this code is always compiled by RMS Fortran.  RMS
decided this aliasing prohibition, put in by the Fortran standards
committee back in the '70s and preserved ever since, was just silly,
so he eliminated it from his dialect.  (Maybe he only *partially*
eliminated it, by saying "let's do a cost/performance analysis each
time we considered breaking code like the above in a given instance",
and the net result was the same -- most RMS Fortran users thinking
there were no alias restrictions in the language, because they always
got away with that, except perhaps in "extremely obvious" instances
such as small self-contained DO loops.)

But he called his dialect "Fortran" anyway, called his compiler
"RMS Fortran" (as versus his operating system, which is called
"...*not* Unix"), and thus set the stage for Barney, our super-programmer,
wasting his time by adding bugs to working code.

How?  Because it turns out X *does* get called with A and B aliased,
that the caller *relies* on the changing of A happening before B is
modified, and that the caller is thus *highly* sensitive to the particular
ordering of the modifications.

In other words, while X looks like it is written in standard Fortran,
and while every single one of X's callers, *in isolation* (without
looking at X itself), might look like *they* are written in standard
Fortran, the reality is, the whole *program* is, in fact, *not* standard
Fortran.  It is RMS Fortran.  The original programmers of that
code got away with it because the compiler happened to avoid ever
reordering things like that, except in instances "everybody" -- meaning
only those RMS Fortran users truly paying attention to these issues -
would agree such reordering was desirable.

And the result is buggy code.

All of the usual responses -- "well, if Barney was so good, why didn't
he read the docs", for example -- would have applied just as well
if RMS hadn't changed the dialect in this way and left it up to
*Fortran* programmers to read the industry-standard *Fortran* specification
and the widely published books on *Fortran* programming.

Further, the *overall* quality of the RMS Fortran product plus RMS
Fortran code is *lower*, because it is less of a good language.
That is, it plays tricks -- appearing to mean one thing, when it
means another, leading people who misunderstand it to break code
written in it.

So, to cater to the mediocre programmers who won't read *any* docs,
not even the widely published ones on the general language they're
using, we *do*, in fact, punish the *great* programmers who *do*
read the *right* docs, but to whom we've given no adequate notice,
in instances such as the above, that there are some *other* docs
they need to go read and study.

(Yes, the quality of those industry-wide specifications and docs
might be low.  That's a separately addressed problem, to be
fixed by offering better ones, *not* by changing the language being
specified.)

If you're going to insist that we continue to chart our own course
for the language GCC compiles vis-a-vis ISO C, then I suggest you
consider renaming *that* language to something else, like "GNU P",
so as to avoid confusing users.

After all, you insisted the EGCS project be named EGCS, not GCC3,
to avoid confusing users.  I suggest you (RMS) apply the Golden Rule
here -- if you were so concerned about EGCS polluting the "good name"
of GCC back then, I suggest you consider how the ISO C people feel
about this continued willingness of the GCC people to say they
compile code written in something called "C", when they're at the
same time so willing to say "ISO C is just a committee" to excuse
ignoring, whenever convenient, what ISO C says about what C "means"
as a language name.

Then, when GNU P has proven to be a better C language than ISO C,
such that the *overall* community prefers it just as it ended up
prefering EGCS to GCC2, we can rename everything back.

No, I'm not arguing for "aggressively breaking bad code", because
I don't think that's wise, taken literally -- and because I
know it's pretty hard to do, and would actually make code *slower*.

I agree with what I think Mark *meant* by that phrase, though, which
is "let's not bother trying to make all sorts of cost/benefit analyses
for every possible conflict between some optimization and whether
that might break some existing bad code out there".  We have better things
to do with our time, like make sure GCC generates *fast* code and that,
when compiled with -fno-strict-aliasing, it generates code that accommodates
the aliasing bug in user code.

        tq vm, (burley)

Re: type based aliasing again

[Alex Rosenberg]

> Well this option would just tell the compiler that there are no aliases,
> guaranteed, on my full responsibility. Like in a function:
>
>    double f(double *x, double *y, long n)
...
>
> when I the programmer happen to know there can't be an alias (the
> memory areas x and y are totally nonoverlapping on the full range)
> but the compiler can't detect that since n could have any value.

IBM's xlC and Apple's MrC use the following syntax for this case:

#pragma disjoint (x,y)

Where any pointer name with any number of dereferences, denoted by an
asterix, can appear in a group.

AFAIK, C9X's restrict keyword doesn't help here since we're only asserting
that these two pointers aren't overlapping, not that they don't overlap with
something else of interest to the compiler.

Another possible solution is a syntax I've seen in Microsoft's VC++:

__assume(x != y);

Where __assume() is usually a non-debug replacement for assert(). This
particular expression doesn't denote lack of overlap, but possibly some
suitable expression can be devised that works. This is also a desirable
general mechanism for other assertions. (If anybody knows of a paper on this
as a general mechanism, I'd love to read it.)

+------------------------------------------------------------+
| Alexander M. Rosenberg           < mailto:alexr@_spies.com > |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: type based aliasing again

[Alex Rosenberg]

> Well this option would just tell the compiler that there are no aliases,
> guaranteed, on my full responsibility. Like in a function:
>
>    double f(double *x, double *y, long n)
...
>
> when I the programmer happen to know there can't be an alias (the
> memory areas x and y are totally nonoverlapping on the full range)
> but the compiler can't detect that since n could have any value.

IBM's xlC and Apple's MrC use the following syntax for this case:

#pragma disjoint (x,y)

Where any pointer name with any number of dereferences, denoted by an
asterix, can appear in a group.

AFAIK, C9X's restrict keyword doesn't help here since we're only asserting
that these two pointers aren't overlapping, not that they don't overlap with
something else of interest to the compiler.

Another possible solution is a syntax I've seen in Microsoft's VC++:

__assume(x != y);

Where __assume() is usually a non-debug replacement for assert(). This
particular expression doesn't denote lack of overlap, but possibly some
suitable expression can be devised that works. This is also a desirable
general mechanism for other assertions. (If anybody knows of a paper on this
as a general mechanism, I'd love to read it.)

+------------------------------------------------------------+
| Alexander M. Rosenberg           < mailto:alexr@_spies.com > |
| Nobody cares what I say. Remove the underscore to mail me. |

type based aliasing again

[Claus Fischer]

Hi,

I wouldn't try to explain the concept of 'aliasing' and its relevance
to the user. The right place for that might be a special chapter in
the info pages but not inlined in the main commandline option
information or in a warning.

Personally I've always liked the linux kernel config saying
'if you don't know what this is all about, choose No'.
Most users probably don't care and don't want to know.

A warning in case the user has already chosen an aliasing option
(knowing the ISO rules or knowing (s)he knows nothing about them)
would be an annoyance. A warning in the no-option case, however,
is extremely desirable.





Here is my very personal wishlist of the compiler behaviour:


1 no flags given
================

   The compiler detects potentially different behaviour under both
   old and new alias detection strategies and gives a warning; the
   warning points the user to the strict-aliasing and
   no-strict-aliasing options.

   I don't care about the default behaviour which the compiler
   assumes.


2 no-strict-aliasing
====================

   Use the old alias detection strategy.

   In the info pages, tell the user 'if you have no clue what this
   is all about, choose this option; it's safe.'


3 strict-aliasing
=================

   Use an ANSI/ISO conformant alias detection strategy, as aggressive
   as possible under the ISO rules. Subject to change between gcc
   releases.

   Tell the user 'by choosing this option you ask the compiler
   to assume that your code conforms to the strict ISO aliasing
   rules; note that this might break your code if you are not
   aware of the ISO rules'.


4 assume-unaliased
==================

   Assume access to memory is never aliased even though it might
   be considered so under the ISO rules. (New flag).

   Tell the user that 'this option will most likely break all your
   code; use this option only if you know what you are doing'.


I personally would love option 4. Presently, a simple Fortran
vector sum is equivalent to various forms of optimum C code,
depending on the machine architecture: some with pointer
arithmetic, some with manual loop unrolling, some using
special assembler instructions. I don't want to learn
assembler to say

     do 1 i=1,10000
 1   a(i) = x*b(i)+y*c(i)

in C without twisting my tongue ;)




Claus

(please CC: me or accept a delay since I read the list on http)

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[David Starner]

On Thu, Sep 09, 1999 at 03:39:08PM -0700, Claus Fischer wrote:
> 1 no flags given
> ================
> 
>    The compiler detects potentially different behaviour under both
>    old and new alias detection strategies and gives a warning; the
>    warning points the user to the strict-aliasing and
>    no-strict-aliasing options.

I don't like this. It's not reasonable to ask users to include
an 15 letter option whenever they invoke the compiler.

> 2 no-strict-aliasing
> ====================
> 
>    Use the old alias detection strategy.
> 
>    In the info pages, tell the user 'if you have no clue what this
>    is all about, choose this option; it's safe.'
It's safer in someways, but it's wrong. We should be out to obsolete
this code, as it's wrong.

> 3 strict-aliasing
> =================
> 
>    Use an ANSI/ISO conformant alias detection strategy, as aggressive
>    as possible under the ISO rules. Subject to change between gcc
>    releases.
It's not subject to change between gcc releases anymore than anyother
part of the compiler. We should be encouraging this as a default.
> 
> 4 assume-unaliased
> ==================
> 
>    Assume access to memory is never aliased even though it might
>    be considered so under the ISO rules. (New flag).
> 
>    Tell the user that 'this option will most likely break all your
>    code; use this option only if you know what you are doing'.
> 
> 
> I personally would love option 4. 
So would I, in some form. After thinking about it, though, that's "restrict",
so that's already in the compiler, in a cleaner, more specific fashion.

David Starner - dstarner98@aasaa.ofe.org

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, David Starner wrote:

  [snip my stuff]
: I don't like this. It's not reasonable to ask users to include
: an 15 letter option whenever they invoke the compiler.

  [snip my stuff]
: It's safer in someways, but it's wrong. We should be out to obsolete
: this code, as it's wrong.

The problem is that the anti-aliasing rules are an especially
difficult and tricky part of the standard. If we demand that
users know these rules that's akin to mandating having a copy of
the standard. While helping people to learn is good, this is more
like imposing difficulties on those that don't want to know.

Amazingly while Fortran uses stricter rules it creates fewer problems
to unexperienced programmers since the language somewhat avoids the
mixture between direct and indirect access to a variable that is one
of the problems in C in this respect (IMHO).


: > 3 strict-aliasing
  [snip my stuff]

: It's not subject to change between gcc releases anymore than anyother
: part of the compiler. We should be encouraging this as a default.

Probably people will develop ever more aggressive optimizations,
exhausting more and more the ISO rules. --strict-aliasing should
be understood as a carte blanche for the compiler to do that,
that's what I wanted to say.

: > 4 assume-unaliased
  [snip my stuff]

: > I personally would love option 4. 
: So would I, in some form. After thinking about it, though, that's "restrict",
: so that's already in the compiler, in a cleaner, more specific fashion.

Yes; an entirely good thing, except it requires reading the
documentation ;) and it's a major hassle to work around when
writing basically ISO conforming code (ifdefs and such).

So, some flag to do that on a per-file basis would still be a nice thing,
say I put the 3% of my code that does matrix/vector operations into
a file and tell the compiler to assume no aliasing for all that stuff.

Claus

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Joe Buck]

> The problem is that the anti-aliasing rules are an especially
> difficult and tricky part of the standard. If we demand that
> users know these rules that's akin to mandating having a copy of
> the standard.

I'm afraid we're just succeeding in scaring the users by tossing
these compiler terms around (aliasing, etc).  It's not as hard as it looks.

I think that we can come up with clear ways of explaining the situation
that will keep people on safe ground.  As Mark Mitchell explained at
one time, the user need not think in terms of aliases.  He or she
simply needs to consider two questions:

1) What is the real type of the object that I am reading or writing?
2) What type am I using to access the object?

If these types differ, the code may be illegal, except for certain
exceptions.  The answer in many cases, to folks doing tricky stuff,
is "use unions, you're then on safe ground."

It's OK to use the signed and unsigned variants of the same integral
type (e.g. unsigned int and int, unsigned short and short).  It's
OK if one of the types of access is of the "raw memory" variety
(e.g. through a char* or void* or unsigned, const, or volatile
variants of these types).  Otherwise it's illegal.

So, this is illegal:
	long word;
	short part1, part2;
	short *pshort = (short *)&word;
	part1 = pshort[0];
	part2 = pshort[1];

We are reading a long as a short.  That's not legal.  You need a union.

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, Joe Buck wrote:

: 1) What is the real type of the object that I am reading or writing?
: 2) What type am I using to access the object?

Well I agree that this is a very good method to make the thing
explainable. And if that were the only result of your discussion
it would IMHO be enough reason do have it.

Also, for a lot of programs that are written purely in C, and that do not
do the types of nasty hardware access like the kernel, it's a non-issue.

However a lot of people use C only for the things they can't do in
other languages. Example situation (from my former workplace):

  User-programs in COBOL (I have no clue about that language)
  Transaction processing software as libraries with C interface

Some C routines are required to fill the COBOL strings with
characters from the messages passed on the network.
The people who are writing this linkage stuff are really having
a hard time from all sides.

Yes I know (1) they should hire someone qualified and (2) they should
do the whole thing in C/C++ and (3) the linkage layer doesn't have to
be optimized and ...

In practice they create the C code by trial and error and once it works
they switch on -O.

You can do a lot of C without knowing the language; the aliasing
might break your neck. Not strictly my beer but one thing I love
about the GNU folks is that try to help everybody. :)

Claus

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, Joe Buck wrote:

: 1) What is the real type of the object that I am reading or writing?
: 2) What type am I using to access the object?

Well I agree that this is a very good method to make the thing
explainable. And if that were the only result of your discussion
it would IMHO be enough reason do have it.

Also, for a lot of programs that are written purely in C, and that do not
do the types of nasty hardware access like the kernel, it's a non-issue.

However a lot of people use C only for the things they can't do in
other languages. Example situation (from my former workplace):

  User-programs in COBOL (I have no clue about that language)
  Transaction processing software as libraries with C interface

Some C routines are required to fill the COBOL strings with
characters from the messages passed on the network.
The people who are writing this linkage stuff are really having
a hard time from all sides.

Yes I know (1) they should hire someone qualified and (2) they should
do the whole thing in C/C++ and (3) the linkage layer doesn't have to
be optimized and ...

In practice they create the C code by trial and error and once it works
they switch on -O.

You can do a lot of C without knowing the language; the aliasing
might break your neck. Not strictly my beer but one thing I love
about the GNU folks is that try to help everybody. :)

Claus

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Joe Buck]

> The problem is that the anti-aliasing rules are an especially
> difficult and tricky part of the standard. If we demand that
> users know these rules that's akin to mandating having a copy of
> the standard.

I'm afraid we're just succeeding in scaring the users by tossing
these compiler terms around (aliasing, etc).  It's not as hard as it looks.

I think that we can come up with clear ways of explaining the situation
that will keep people on safe ground.  As Mark Mitchell explained at
one time, the user need not think in terms of aliases.  He or she
simply needs to consider two questions:

1) What is the real type of the object that I am reading or writing?
2) What type am I using to access the object?

If these types differ, the code may be illegal, except for certain
exceptions.  The answer in many cases, to folks doing tricky stuff,
is "use unions, you're then on safe ground."

It's OK to use the signed and unsigned variants of the same integral
type (e.g. unsigned int and int, unsigned short and short).  It's
OK if one of the types of access is of the "raw memory" variety
(e.g. through a char* or void* or unsigned, const, or volatile
variants of these types).  Otherwise it's illegal.

So, this is illegal:
	long word;
	short part1, part2;
	short *pshort = (short *)&word;
	part1 = pshort[0];
	part2 = pshort[1];

We are reading a long as a short.  That's not legal.  You need a union.

Re: type based aliasing again

[craig]

>The problem is that the anti-aliasing rules are an especially
>difficult and tricky part of the standard. If we demand that
>users know these rules that's akin to mandating having a copy of
>the standard. While helping people to learn is good, this is more
>like imposing difficulties on those that don't want to know.

There are two dominant solutions: 1) Change the standard; 2) Don't
program in C.  *Way* less appropriate than those is 3) Invent dialectal
behaviors and implement them to work around what programmers are
already supposed to know, which is what is being proposed here --
especially when those dialectal behaviors are triggered without the
use of *any* constructs that are clearly syntactically *invalid*
in the standard language.

In short, if people "don't want to know", they shouldn't be let
near a C compiler.  Remember all those pundits who claimed C was
inferior, for regular programmers, to some languages like FORTRAN 77,
because it imposed pointers on them?  This is where you're all supposed
to say "hey, they were right, these pointer thangs are *darn* complicated".

(My off-the-cuff opinion?  C programmers can't handle pointers *combined*
with Fortran-style aliasing prohibitions.  ISO C should have just
mandated straight-ahead, nearly-Java-like behavior for code, and
left optimization to the under-the-hood people.  I'm saying I actually
favor option #1 above.  If we leave things as they are in GCC, we
actually *promote* such a change better than if we cleverly try
to "accommodate" via option 3, and probably even better than if we
emit a nice warning.)

        tq vm, (burley)

Re: type based aliasing again

[craig]

>The problem is that the anti-aliasing rules are an especially
>difficult and tricky part of the standard. If we demand that
>users know these rules that's akin to mandating having a copy of
>the standard. While helping people to learn is good, this is more
>like imposing difficulties on those that don't want to know.

There are two dominant solutions: 1) Change the standard; 2) Don't
program in C.  *Way* less appropriate than those is 3) Invent dialectal
behaviors and implement them to work around what programmers are
already supposed to know, which is what is being proposed here --
especially when those dialectal behaviors are triggered without the
use of *any* constructs that are clearly syntactically *invalid*
in the standard language.

In short, if people "don't want to know", they shouldn't be let
near a C compiler.  Remember all those pundits who claimed C was
inferior, for regular programmers, to some languages like FORTRAN 77,
because it imposed pointers on them?  This is where you're all supposed
to say "hey, they were right, these pointer thangs are *darn* complicated".

(My off-the-cuff opinion?  C programmers can't handle pointers *combined*
with Fortran-style aliasing prohibitions.  ISO C should have just
mandated straight-ahead, nearly-Java-like behavior for code, and
left optimization to the under-the-hood people.  I'm saying I actually
favor option #1 above.  If we leave things as they are in GCC, we
actually *promote* such a change better than if we cleverly try
to "accommodate" via option 3, and probably even better than if we
emit a nice warning.)

        tq vm, (burley)

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, David Starner wrote:

  [snip my stuff]
: I don't like this. It's not reasonable to ask users to include
: an 15 letter option whenever they invoke the compiler.

  [snip my stuff]
: It's safer in someways, but it's wrong. We should be out to obsolete
: this code, as it's wrong.

The problem is that the anti-aliasing rules are an especially
difficult and tricky part of the standard. If we demand that
users know these rules that's akin to mandating having a copy of
the standard. While helping people to learn is good, this is more
like imposing difficulties on those that don't want to know.

Amazingly while Fortran uses stricter rules it creates fewer problems
to unexperienced programmers since the language somewhat avoids the
mixture between direct and indirect access to a variable that is one
of the problems in C in this respect (IMHO).


: > 3 strict-aliasing
  [snip my stuff]

: It's not subject to change between gcc releases anymore than anyother
: part of the compiler. We should be encouraging this as a default.

Probably people will develop ever more aggressive optimizations,
exhausting more and more the ISO rules. --strict-aliasing should
be understood as a carte blanche for the compiler to do that,
that's what I wanted to say.

: > 4 assume-unaliased
  [snip my stuff]

: > I personally would love option 4. 
: So would I, in some form. After thinking about it, though, that's "restrict",
: so that's already in the compiler, in a cleaner, more specific fashion.

Yes; an entirely good thing, except it requires reading the
documentation ;) and it's a major hassle to work around when
writing basically ISO conforming code (ifdefs and such).

So, some flag to do that on a per-file basis would still be a nice thing,
say I put the 3% of my code that does matrix/vector operations into
a file and tell the compiler to assume no aliasing for all that stuff.

Claus

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[David Starner]

On Thu, Sep 09, 1999 at 03:39:08PM -0700, Claus Fischer wrote:
> 1 no flags given
> ================
> 
>    The compiler detects potentially different behaviour under both
>    old and new alias detection strategies and gives a warning; the
>    warning points the user to the strict-aliasing and
>    no-strict-aliasing options.

I don't like this. It's not reasonable to ask users to include
an 15 letter option whenever they invoke the compiler.

> 2 no-strict-aliasing
> ====================
> 
>    Use the old alias detection strategy.
> 
>    In the info pages, tell the user 'if you have no clue what this
>    is all about, choose this option; it's safe.'
It's safer in someways, but it's wrong. We should be out to obsolete
this code, as it's wrong.

> 3 strict-aliasing
> =================
> 
>    Use an ANSI/ISO conformant alias detection strategy, as aggressive
>    as possible under the ISO rules. Subject to change between gcc
>    releases.
It's not subject to change between gcc releases anymore than anyother
part of the compiler. We should be encouraging this as a default.
> 
> 4 assume-unaliased
> ==================
> 
>    Assume access to memory is never aliased even though it might
>    be considered so under the ISO rules. (New flag).
> 
>    Tell the user that 'this option will most likely break all your
>    code; use this option only if you know what you are doing'.
> 
> 
> I personally would love option 4. 
So would I, in some form. After thinking about it, though, that's "restrict",
so that's already in the compiler, in a cleaner, more specific fashion.

David Starner - dstarner98@aasaa.ofe.org

Re: type based aliasing again

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9909091451290.28913-100000@tcadi02.sc.intel.com >you
 write:
  > 
  > 
  > Hi,
  > 
  > I wouldn't try to explain the concept of 'aliasing' and its relevance
  > to the user. The right place for that might be a special chapter in
  > the info pages but not inlined in the main commandline option
  > information or in a warning.
  > 
  > Personally I've always liked the linux kernel config saying
  > 'if you don't know what this is all about, choose No'.
  > Most users probably don't care and don't want to know.
  > 
  > A warning in case the user has already chosen an aliasing option
  > (knowing the ISO rules or knowing (s)he knows nothing about them)
  > would be an annoyance. A warning in the no-option case, however,
  > is extremely desirable.
I think this approach is fundamentally flawed.  In fact, it is this kind of
approach that has led to so many problems between GCC and the Linux kernel's
use of certain GCC extensions.

  > 4 assume-unaliased
  > ==================
  > 
  >    Assume access to memory is never aliased even though it might
  >    be considered so under the ISO rules. (New flag).
  > 
  >    Tell the user that 'this option will most likely break all your
  >    code; use this option only if you know what you are doing'.
  > 
IMHO This is very very bad.  The problem is while you the programmer may not
have created any aliases, the compiler might during the translation down to RTL
and subsequent optimization phases.



jeff

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, Jeffrey A Law wrote:

:   > A warning in case the user has already chosen an aliasing option
:   > (knowing the ISO rules or knowing (s)he knows nothing about them)
:   > would be an annoyance. A warning in the no-option case, however,
:   > is extremely desirable.
: I think this approach is fundamentally flawed.  In fact, it is this kind of
: approach that has led to so many problems between GCC and the Linux kernel's
: use of certain GCC extensions.

Do you think that (1) the warning approach is flawed, since it warns for
perfectly legal ISO-conformant code, or do you think (2) it is flawed to
disable the warning once the user has chosen an aliasing detection option?

I'm not worried about the linux kernel people; after some groaning they
will clean up the thing and go on. But I see a fundamental gap between
highly technical people (skilled programmers) who are able to understand
aliasing issues, and a lot of C programmers out there who will probably
never understand the aliasing issue.

I've once (in a former job) done a C course for former COBOL programmers
and found that C is a very hard language to explain and train. I'm just
a bit worried that maxing out the standard to the letter might give them
a bad time. There should be a possibility for people who are inexperienced
C programmers to still use GCC somewhat successful, and the aliasing issue
might be one of the stop gaps.

Perhaps it would be feasible to do it the other way around: offer a
prominent warning option -Winexperienced-mode which tells the user
that it will warn when it detects potentially complicated things?
Then this option could switch on the warnings that tell the 
user about aliasing?

I don't have a good solution either.



:   > 4 assume-unaliased

: IMHO This is very very bad.  The problem is while you the programmer may not
: have created any aliases, the compiler might during the translation down to RTL
: and subsequent optimization phases.

Well this option would just tell the compiler that there are no aliases,
guaranteed, on my full responsibility. Like in a function:

   double f(double *x, double *y, long n)
   {
       double a = 0;
       long i;
       for (i = 0; i < n; i++) a += x[i] * y[i];
       return a;
   }

when I the programmer happen to know there can't be an alias (the
memory areas x and y are totally nonoverlapping on the full range)
but the compiler can't detect that since n could have any value.

How far down the translation phase that can be upheld, I cannot say.

I just know that 80% of numerical solver stuff boils down to dot
products of some sort. And the C standard is not very helpful in
that.

Claus



-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Claus Fischer]

On Thu, 9 Sep 1999, Jeffrey A Law wrote:

:   > A warning in case the user has already chosen an aliasing option
:   > (knowing the ISO rules or knowing (s)he knows nothing about them)
:   > would be an annoyance. A warning in the no-option case, however,
:   > is extremely desirable.
: I think this approach is fundamentally flawed.  In fact, it is this kind of
: approach that has led to so many problems between GCC and the Linux kernel's
: use of certain GCC extensions.

Do you think that (1) the warning approach is flawed, since it warns for
perfectly legal ISO-conformant code, or do you think (2) it is flawed to
disable the warning once the user has chosen an aliasing detection option?

I'm not worried about the linux kernel people; after some groaning they
will clean up the thing and go on. But I see a fundamental gap between
highly technical people (skilled programmers) who are able to understand
aliasing issues, and a lot of C programmers out there who will probably
never understand the aliasing issue.

I've once (in a former job) done a C course for former COBOL programmers
and found that C is a very hard language to explain and train. I'm just
a bit worried that maxing out the standard to the letter might give them
a bad time. There should be a possibility for people who are inexperienced
C programmers to still use GCC somewhat successful, and the aliasing issue
might be one of the stop gaps.

Perhaps it would be feasible to do it the other way around: offer a
prominent warning option -Winexperienced-mode which tells the user
that it will warn when it detects potentially complicated things?
Then this option could switch on the warnings that tell the 
user about aliasing?

I don't have a good solution either.



:   > 4 assume-unaliased

: IMHO This is very very bad.  The problem is while you the programmer may not
: have created any aliases, the compiler might during the translation down to RTL
: and subsequent optimization phases.

Well this option would just tell the compiler that there are no aliases,
guaranteed, on my full responsibility. Like in a function:

   double f(double *x, double *y, long n)
   {
       double a = 0;
       long i;
       for (i = 0; i < n; i++) a += x[i] * y[i];
       return a;
   }

when I the programmer happen to know there can't be an alias (the
memory areas x and y are totally nonoverlapping on the full range)
but the compiler can't detect that since n could have any value.

How far down the translation phase that can be upheld, I cannot say.

I just know that 80% of numerical solver stuff boils down to dot
products of some sort. And the C standard is not very helpful in
that.

Claus



-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9909091451290.28913-100000@tcadi02.sc.intel.com >you
 write:
  > 
  > 
  > Hi,
  > 
  > I wouldn't try to explain the concept of 'aliasing' and its relevance
  > to the user. The right place for that might be a special chapter in
  > the info pages but not inlined in the main commandline option
  > information or in a warning.
  > 
  > Personally I've always liked the linux kernel config saying
  > 'if you don't know what this is all about, choose No'.
  > Most users probably don't care and don't want to know.
  > 
  > A warning in case the user has already chosen an aliasing option
  > (knowing the ISO rules or knowing (s)he knows nothing about them)
  > would be an annoyance. A warning in the no-option case, however,
  > is extremely desirable.
I think this approach is fundamentally flawed.  In fact, it is this kind of
approach that has led to so many problems between GCC and the Linux kernel's
use of certain GCC extensions.

  > 4 assume-unaliased
  > ==================
  > 
  >    Assume access to memory is never aliased even though it might
  >    be considered so under the ISO rules. (New flag).
  > 
  >    Tell the user that 'this option will most likely break all your
  >    code; use this option only if you know what you are doing'.
  > 
IMHO This is very very bad.  The problem is while you the programmer may not
have created any aliases, the compiler might during the translation down to RTL
and subsequent optimization phases.



jeff

type based aliasing again

[Claus Fischer]

Hi,

I wouldn't try to explain the concept of 'aliasing' and its relevance
to the user. The right place for that might be a special chapter in
the info pages but not inlined in the main commandline option
information or in a warning.

Personally I've always liked the linux kernel config saying
'if you don't know what this is all about, choose No'.
Most users probably don't care and don't want to know.

A warning in case the user has already chosen an aliasing option
(knowing the ISO rules or knowing (s)he knows nothing about them)
would be an annoyance. A warning in the no-option case, however,
is extremely desirable.





Here is my very personal wishlist of the compiler behaviour:


1 no flags given
================

   The compiler detects potentially different behaviour under both
   old and new alias detection strategies and gives a warning; the
   warning points the user to the strict-aliasing and
   no-strict-aliasing options.

   I don't care about the default behaviour which the compiler
   assumes.


2 no-strict-aliasing
====================

   Use the old alias detection strategy.

   In the info pages, tell the user 'if you have no clue what this
   is all about, choose this option; it's safe.'


3 strict-aliasing
=================

   Use an ANSI/ISO conformant alias detection strategy, as aggressive
   as possible under the ISO rules. Subject to change between gcc
   releases.

   Tell the user 'by choosing this option you ask the compiler
   to assume that your code conforms to the strict ISO aliasing
   rules; note that this might break your code if you are not
   aware of the ISO rules'.


4 assume-unaliased
==================

   Assume access to memory is never aliased even though it might
   be considered so under the ISO rules. (New flag).

   Tell the user that 'this option will most likely break all your
   code; use this option only if you know what you are doing'.


I personally would love option 4. Presently, a simple Fortran
vector sum is equivalent to various forms of optimum C code,
depending on the machine architecture: some with pointer
arithmetic, some with manual loop unrolling, some using
special assembler instructions. I don't want to learn
assembler to say

     do 1 i=1,10000
 1   a(i) = x*b(i)+y*c(i)

in C without twisting my tongue ;)




Claus

(please CC: me or accept a delay since I read the list on http)

-- 
claus.fischer@intel.com   Intel Corporation SC12-205 ... not speaking
phone   +1-408-765-6808   2200 Mission College Blvd.           for Intel
fax     +1-408-765-9322   Santa Clara, CA 95052-8119

Re: type based aliasing again

[Mike Stump]

> From: Mark Mitchell <mark@codesourcery.com>
> Date: Wed, 08 Sep 1999 20:29:57 -0700

> There will be cases where A will pessimize code that does not have
> undefined behavior.

I was trying to envision this.  Do you have an example?  I was
thinking Joe meant doing this is cases were we can prove that they in
fact do alias, but for which the types don't match.  Lessor cases were
we cannot prove they alias, would not issue a warning.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    >> From: Mark Mitchell <mark@codesourcery.com> Date: Wed, 08 Sep
    >> 1999 20:29:57 -0700

    >> There will be cases where A will pessimize code that does not
    >> have undefined behavior.

    Mike> I was trying to envision this.  Do you have an example?  I
    Mike> was thinking Joe meant doing this is cases were we can prove
    Mike> that they in fact do alias, but for which the types don't
    Mike> match.  Lessor cases were we cannot prove they alias, would
    Mike> not issue a warning.

How about:
    
  void f (int *x, int *y)
  {
    void *v = malloc (4);
    *x = 1;
    if (*x)
      *((int *) v) = 3;

    *y = !*x;

    if (!*x)
      *((float *) v) = 7.0;
  }

Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
Because that would change the value of *x, which would mean that we
would access `*v' illegally.  Since that would have undefined
behavior, we can decide that `y' and `x' do not point at the same
place.

A bit theoretical, I admit.  But, a less contrived example is probably
also possible along these lines.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Stallman]

    How about:

      void f (int *x, int *y)
      {
	void *v = malloc (4);
	*x = 1;
	if (*x)
	  *((int *) v) = 3;

	*y = !*x;

	if (!*x)
	  *((float *) v) = 7.0;
      }

    Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
    Because that would change the value of *x, which would mean that we
    would access `*v' illegally.  Since that would have undefined
    behavior, we can decide that `y' and `x' do not point at the same
    place.

I agree that this is valid reasoning, and that an optimization based
on this conclusion is in principle valid.  There is a conceivable
possibility that someday GCC might optimize in this way.

But that is not a factor for the decision we have to make today,
because it is a minor issue compared with the real, serious problem
that we have now.

If this theoretical future problem does happen, it will be smaller
than the real problem I propose to solve today.  The present approach
is like amputating a foot today, on the ground that there's a
theoretical possibility that some toe will have to be amputated some
time in the future.

Maintaining a compiler is not like proving theorems; complete rigor is
not the goal.

Re: type based aliasing again

[Jeffrey A Law]

  >     How about:
  > 
  >       void f (int *x, int *y)
  >       {
  > 	void *v = malloc (4);
  > 	*x = 1;
  > 	if (*x)
  > 	  *((int *) v) = 3;
  > 
  > 	*y = !*x;
  > 
  > 	if (!*x)
  > 	  *((float *) v) = 7.0;
  >       }
  > 
  >     Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
  >     Because that would change the value of *x, which would mean that we
  >     would access `*v' illegally.  Since that would have undefined
  >     behavior, we can decide that `y' and `x' do not point at the same
  >     place.
  > 
  > I agree that this is valid reasoning, and that an optimization based
  > on this conclusion is in principle valid.  There is a conceivable
  > possibility that someday GCC might optimize in this way.
This kind of optimization is something we want to be able to do long-term, but
not something we do now, or will do in the near future.


  > But that is not a factor for the decision we have to make today,
  > because it is a minor issue compared with the real, serious problem
  > that we have now.
Agreed.
jeff

Re: type based aliasing again

[Jeffrey A Law]

  >     How about:
  > 
  >       void f (int *x, int *y)
  >       {
  > 	void *v = malloc (4);
  > 	*x = 1;
  > 	if (*x)
  > 	  *((int *) v) = 3;
  > 
  > 	*y = !*x;
  > 
  > 	if (!*x)
  > 	  *((float *) v) = 7.0;
  >       }
  > 
  >     Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
  >     Because that would change the value of *x, which would mean that we
  >     would access `*v' illegally.  Since that would have undefined
  >     behavior, we can decide that `y' and `x' do not point at the same
  >     place.
  > 
  > I agree that this is valid reasoning, and that an optimization based
  > on this conclusion is in principle valid.  There is a conceivable
  > possibility that someday GCC might optimize in this way.
This kind of optimization is something we want to be able to do long-term, but
not something we do now, or will do in the near future.


  > But that is not a factor for the decision we have to make today,
  > because it is a minor issue compared with the real, serious problem
  > that we have now.
Agreed.
jeff

Re: type based aliasing again

[Richard Stallman]

    How about:

      void f (int *x, int *y)
      {
	void *v = malloc (4);
	*x = 1;
	if (*x)
	  *((int *) v) = 3;

	*y = !*x;

	if (!*x)
	  *((float *) v) = 7.0;
      }

    Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
    Because that would change the value of *x, which would mean that we
    would access `*v' illegally.  Since that would have undefined
    behavior, we can decide that `y' and `x' do not point at the same
    place.

I agree that this is valid reasoning, and that an optimization based
on this conclusion is in principle valid.  There is a conceivable
possibility that someday GCC might optimize in this way.

But that is not a factor for the decision we have to make today,
because it is a minor issue compared with the real, serious problem
that we have now.

If this theoretical future problem does happen, it will be smaller
than the real problem I propose to solve today.  The present approach
is like amputating a foot today, on the ground that there's a
theoretical possibility that some toe will have to be amputated some
time in the future.

Maintaining a compiler is not like proving theorems; complete rigor is
not the goal.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    >> From: Mark Mitchell <mark@codesourcery.com> Date: Wed, 08 Sep
    >> 1999 20:29:57 -0700

    >> There will be cases where A will pessimize code that does not
    >> have undefined behavior.

    Mike> I was trying to envision this.  Do you have an example?  I
    Mike> was thinking Joe meant doing this is cases were we can prove
    Mike> that they in fact do alias, but for which the types don't
    Mike> match.  Lessor cases were we cannot prove they alias, would
    Mike> not issue a warning.

How about:
    
  void f (int *x, int *y)
  {
    void *v = malloc (4);
    *x = 1;
    if (*x)
      *((int *) v) = 3;

    *y = !*x;

    if (!*x)
      *((float *) v) = 7.0;
  }

Here, we can conclude that `*y = *!x' does not modify `*x'.  Why?
Because that would change the value of *x, which would mean that we
would access `*v' illegally.  Since that would have undefined
behavior, we can decide that `y' and `x' do not point at the same
place.

A bit theoretical, I admit.  But, a less contrived example is probably
also possible along these lines.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mike Stump]

> From: Mark Mitchell <mark@codesourcery.com>
> Date: Wed, 08 Sep 1999 20:29:57 -0700

> There will be cases where A will pessimize code that does not have
> undefined behavior.

I was trying to envision this.  Do you have an example?  I was
thinking Joe meant doing this is cases were we can prove that they in
fact do alias, but for which the types don't match.  Lessor cases were
we cannot prove they alias, would not issue a warning.

Re: type based aliasing again

[Mike Stump]

My comment is similar to Mark's comment.  Documentation, what can we
document as working?  Can users rely upon it working?

Is it less confusing to a user to have the compiler predictably
generate wrong code, or for it to almost always generate right code,
even for bad code, except in really obscure and hard to understand
cases?

Anway, more questions from me than answers...  Off hand though, if we
can make the compiler generate `right' code in more cases, even if the
users code is wrong, I think we should probably do it.  I say this not
with a language designer's hat on, but as someone that has to support
users with possibly broken code.  Kind of a quick fix to get them to
leave me alone.

Re: type based aliasing again

[Joe Buck]

> My comment is similar to Mark's comment.  Documentation, what can we
> document as working?  Can users rely upon it working?

You misunderstood.  I am not proposing a language extension.  I am
proposing trying to detect that the user is breaking the rules.  If
we catch him, we issue a warning and declare that there is aliasing.
If we don't catch him, the user may lose.  If the user wants to
be assured of winning, she must follow ANSI rules.

(The original idea started in a discussion with RMS, so I shouldn't say
"I" here, but then I am currently writing this, not him).

> Is it less confusing to a user to have the compiler predictably
> generate wrong code, or for it to almost always generate right code,
> even for bad code, except in really obscure and hard to understand
> cases?

In this case, most users don't even know the rule, so they can't predict
that the compiler will generate wrong code.

> Anway, more questions from me than answers...  Off hand though, if we
> can make the compiler generate `right' code in more cases, even if the
> users code is wrong, I think we should probably do it.

Good, we agree.

Re: type based aliasing again

[Joe Buck]

> My comment is similar to Mark's comment.  Documentation, what can we
> document as working?  Can users rely upon it working?

You misunderstood.  I am not proposing a language extension.  I am
proposing trying to detect that the user is breaking the rules.  If
we catch him, we issue a warning and declare that there is aliasing.
If we don't catch him, the user may lose.  If the user wants to
be assured of winning, she must follow ANSI rules.

(The original idea started in a discussion with RMS, so I shouldn't say
"I" here, but then I am currently writing this, not him).

> Is it less confusing to a user to have the compiler predictably
> generate wrong code, or for it to almost always generate right code,
> even for bad code, except in really obscure and hard to understand
> cases?

In this case, most users don't even know the rule, so they can't predict
that the compiler will generate wrong code.

> Anway, more questions from me than answers...  Off hand though, if we
> can make the compiler generate `right' code in more cases, even if the
> users code is wrong, I think we should probably do it.

Good, we agree.

Re: type based aliasing again

[Marc Espie]

In article < 199909090211.TAA03202@kankakee.wrs.com > you write:
>Is it less confusing to a user to have the compiler predictably
>generate wrong code, or for it to almost always generate right code,
>even for bad code, except in really obscure and hard to understand
>cases?

As far as aliasing goes, what would do wonders would be to have a
thorough section of the documentation explaining what goes on, in
understandable english, not standards legalese.

A few examples of code that works, and code that WILL break would help
immensely as well... Specifically, issues with `poor man inheritance in C',
where one casts structure pointers about to more generic classes, and other
instances of concrete code (the kind of which you find in kernels) would
be useful.

... and I won't volunteer for that one, as I am still confused about what
kind of casts are valid and which kinds are not.

For instance, I've been reviewing some m4 source, which uses a stack
declared like this:

union type
	{
	char *string;
	int position;
	} stack[MAX_SIZE];

and then proceeds to cast stack to (char **) and pass this as argv
to a macro processing function.

Is this code actually valid under ANSI aliasing rules ?

(I know that it needs sizeof(char *) == sizeof(union type), but that's
another point)

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909091415.QAA30861@quatramaran.ens.fr >you write:
  > In article < 199909090211.TAA03202@kankakee.wrs.com > you write:
  > >Is it less confusing to a user to have the compiler predictably
  > >generate wrong code, or for it to almost always generate right code,
  > >even for bad code, except in really obscure and hard to understand
  > >cases?
  > 
  > As far as aliasing goes, what would do wonders would be to have a
  > thorough section of the documentation explaining what goes on, in
  > understandable english, not standards legalese.
This has alwasy been the plan.  I'd like see this on the web page handled in
a manner similar to the asm issue.

Ie, we discuss the issue in some general terms, maybe give some code fragments
that are invalid, and a valid translation of those fragments.  Then a separate
faq entry which discusses instances where strict aliasing breaks high 
visibility
software such as the Linux kernel.

Starting with Joe Buck's nice simple summary is probably the way to go.

If someone wants to make a contribution, but isn't a compiler guru, writing
up some of this stuff for an FAQ entry would be an excellent contribution.

jeff

Re: type based aliasing again

[Sudish Joseph]

Jeffrey A Law writes:
>   In message < 199909091415.QAA30861@quatramaran.ens.fr >you write:
>> As far as aliasing goes, what would do wonders would be to have a
>> thorough section of the documentation explaining what goes on, in
>> understandable english, not standards legalese.
> This has alwasy been the plan.  I'd like see this on the web page handled in
> a manner similar to the asm issue.

> Ie, we discuss the issue in some general terms, maybe give some code
> fragments that are invalid, and a valid translation of those
> fragments.  Then a separate faq entry which discusses instances
> where strict aliasing breaks high visibility software such as the
> Linux kernel.

FYI, this is how the Digital Unix 4.0F man page describes the aliasing 
option:

------------------------------------------------------------
  -[no]ansi_alias
      Directs the compiler to assume the ANSI C aliasing rules, and thus
      allows the optimizer to be more aggressive in its optimizations.  The
      -noansi_alias option turns off ANSI C aliasing rules.

      The aliasing rules are explained in Section 3.3, paragraphs 20 and 25
      of the ANSI C Standard, reprinted as follows:

      "An object shall have its stored value accessed only by an lvalue that
      has one of the following types:

        o  The declared type of the object,

        o  A qualified version of the declared type of the object,

        o  A type that is the signed or unsigned type corresponding to the
           declared type of the object,

        o  A type that is the signed or unsigned type corresponding to a
           qualified version of the declared type of the object,

        o  An aggregate or union type that includes one of the aforementioned
           types among its members (including, recursively, a member of a
           subaggregate or contained union), or

        o  A character type."

      If your program does not access the same data through pointers that
      have different types (and for this purpose, signed and qualified ver-
      sions of an otherwise same type are considered to be the same type),
      then assuming ANSI C aliasing rules allows the compiler to generate
      better optimized code.

      If your program does access the same data through pointers that have
      different types (for example, by a "pointer to int" and a "pointer to
      float"), you must not allow the compiler to assume ANSI C aliasing
      rules because these rules can result in the generation of incorrect
      code.

      The default is to assume no ANSI C aliasing rules when compiling with
      the -vaxc, -std, or -std0 option. The default is -ansi_alias when com-
      piling with the -std1 option.

      The -noansi_alias option turns off ANSI C aliasing rules.

      The -[no]ansi_alias option is not available when you use the -oldc
      option.
------------------------------------------------------------

-- 
Sudish Joseph                                          MindSpring Enterprises

Re: type based aliasing again

[Sudish Joseph]

Jeffrey A Law writes:
>   In message < 199909091415.QAA30861@quatramaran.ens.fr >you write:
>> As far as aliasing goes, what would do wonders would be to have a
>> thorough section of the documentation explaining what goes on, in
>> understandable english, not standards legalese.
> This has alwasy been the plan.  I'd like see this on the web page handled in
> a manner similar to the asm issue.

> Ie, we discuss the issue in some general terms, maybe give some code
> fragments that are invalid, and a valid translation of those
> fragments.  Then a separate faq entry which discusses instances
> where strict aliasing breaks high visibility software such as the
> Linux kernel.

FYI, this is how the Digital Unix 4.0F man page describes the aliasing 
option:

------------------------------------------------------------
  -[no]ansi_alias
      Directs the compiler to assume the ANSI C aliasing rules, and thus
      allows the optimizer to be more aggressive in its optimizations.  The
      -noansi_alias option turns off ANSI C aliasing rules.

      The aliasing rules are explained in Section 3.3, paragraphs 20 and 25
      of the ANSI C Standard, reprinted as follows:

      "An object shall have its stored value accessed only by an lvalue that
      has one of the following types:

        o  The declared type of the object,

        o  A qualified version of the declared type of the object,

        o  A type that is the signed or unsigned type corresponding to the
           declared type of the object,

        o  A type that is the signed or unsigned type corresponding to a
           qualified version of the declared type of the object,

        o  An aggregate or union type that includes one of the aforementioned
           types among its members (including, recursively, a member of a
           subaggregate or contained union), or

        o  A character type."

      If your program does not access the same data through pointers that
      have different types (and for this purpose, signed and qualified ver-
      sions of an otherwise same type are considered to be the same type),
      then assuming ANSI C aliasing rules allows the compiler to generate
      better optimized code.

      If your program does access the same data through pointers that have
      different types (for example, by a "pointer to int" and a "pointer to
      float"), you must not allow the compiler to assume ANSI C aliasing
      rules because these rules can result in the generation of incorrect
      code.

      The default is to assume no ANSI C aliasing rules when compiling with
      the -vaxc, -std, or -std0 option. The default is -ansi_alias when com-
      piling with the -std1 option.

      The -noansi_alias option turns off ANSI C aliasing rules.

      The -[no]ansi_alias option is not available when you use the -oldc
      option.
------------------------------------------------------------

-- 
Sudish Joseph                                          MindSpring Enterprises

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909091415.QAA30861@quatramaran.ens.fr >you write:
  > In article < 199909090211.TAA03202@kankakee.wrs.com > you write:
  > >Is it less confusing to a user to have the compiler predictably
  > >generate wrong code, or for it to almost always generate right code,
  > >even for bad code, except in really obscure and hard to understand
  > >cases?
  > 
  > As far as aliasing goes, what would do wonders would be to have a
  > thorough section of the documentation explaining what goes on, in
  > understandable english, not standards legalese.
This has alwasy been the plan.  I'd like see this on the web page handled in
a manner similar to the asm issue.

Ie, we discuss the issue in some general terms, maybe give some code fragments
that are invalid, and a valid translation of those fragments.  Then a separate
faq entry which discusses instances where strict aliasing breaks high 
visibility
software such as the Linux kernel.

Starting with Joe Buck's nice simple summary is probably the way to go.

If someone wants to make a contribution, but isn't a compiler guru, writing
up some of this stuff for an FAQ entry would be an excellent contribution.

jeff

Re: type based aliasing again

[Marc Espie]

In article < 199909090211.TAA03202@kankakee.wrs.com > you write:
>Is it less confusing to a user to have the compiler predictably
>generate wrong code, or for it to almost always generate right code,
>even for bad code, except in really obscure and hard to understand
>cases?

As far as aliasing goes, what would do wonders would be to have a
thorough section of the documentation explaining what goes on, in
understandable english, not standards legalese.

A few examples of code that works, and code that WILL break would help
immensely as well... Specifically, issues with `poor man inheritance in C',
where one casts structure pointers about to more generic classes, and other
instances of concrete code (the kind of which you find in kernels) would
be useful.

... and I won't volunteer for that one, as I am still confused about what
kind of casts are valid and which kinds are not.

For instance, I've been reviewing some m4 source, which uses a stack
declared like this:

union type
	{
	char *string;
	int position;
	} stack[MAX_SIZE];

and then proceeds to cast stack to (char **) and pass this as argv
to a macro processing function.

Is this code actually valid under ANSI aliasing rules ?

(I know that it needs sizeof(char *) == sizeof(union type), but that's
another point)

Re: type based aliasing again

[Richard Stallman]

    My comment is similar to Mark's comment.  Documentation, what can we
    document as working?

We should not even try to document that these cases work.
Documentation is what we do when we add a feature.

I am not proposing this as a feature, just as a way to avoid evitable
trouble for users.  We should not even try to document a class of
cases that are "supposed" to work, because I'm not saying these
are "supposed" to work.  We should just let them work.

    Anway, more questions from me than answers...  Off hand though, if we
    can make the compiler generate `right' code in more cases, even if the
    users code is wrong, I think we should probably do it.

In C, we cannot divide all user code into "right" and "wrong" in this
kind of simple way, and certainly not based on the ISO standard.  That
standard is just the decisions of a certain committee (which I was a
member of) about what cases conforming compilers should commit to
support.  We must not let ourselves start thinking that C code is
"wrong", just because it is not conforming ISO C code.

C programs use many cases that are not conforming, but do work.  This
will be true for as long as C is used, because changing it would
require major changes in the C language.

From time to time, there is a real *need* to make some of these cases
stop working, for the sake of some benefit that users want.  When this
happens, we should do it; the user community will accept it, because
they will see that it is being done for their sake.  Some will
grumble, but the users who appreciate the benefits will convince them.

But when there is no *need* to break these cases, when we can keep
them working fairly easily, we should keep them working.  If we break
them unnecessarily, we invite the legitimate anger of the users.

type based aliasing again

[Joe Buck]

It seems that RMS and Linus have something in common, in that neither
is happy with the way type-based aliasing is used in gcc 2.95.

RMS has a proposal to do something about it that I'd like to discuss
with you all.  It would be nice if RMS had the bandwidth to take this
up himself, but there seem to be some sensitivities among some developers
over RMS telling them what to do, so it'll probably just go smoother
if I pass the thing on.  Besides, I like his idea.  (Please keep the
cc to RMS on replies).


Some background, for those unfamiliar with the issue: in the past, Fortran
compilers typically generated much faster code than C compilers for
essentially the same code in part because of Fortran's aliasing rules: the
arguments to a Fortran subroutine can never overlap, so the compiler
doesn't have to worry that writing to one array argument will change
another, so loops can keep more stuff in registers.  In C, on the other
hand, it's common to pass two pointers to the same array to a function.

So the ANSI C folks came up with the type-aliasing rule: the compiler
is entitled to assume that accesses (possibly via a pointer) to memory
of one type can't alter memory of another type (they made an exception
for char* pointers and void* pointers, also const char, unsigned char,
etc).  The rule basically makes it illegal to access a value of one
type through a pointer of another type (except for a list of exceptions,
e.g. signed and unsigned flavors of the same integral type).

(For a more precise statement of the rule, see the mail archive).

As of gcc 2.95, optimizations that take advantage of this rule are turned
on by default.  The problem is that there is a good deal of
technically-invalid code out there (that, for example, reads and writes
long data as pairs of shorts, without using unions).  gcc 2.95 may
malfunction on such code unless the flag -fno-strict-aliasing is provided.

The question that has been asked by a number of people is whether we
can make some of the more "obvious" cases work correctly, or somehow
help users find and clean up such cases, and there were a number of
technical proposals, some of which were infeasible, some of which just
weren't satisfactory.

RMS came up with a proposal that I think is reasonable, though we should
have expert input on it.  The idea goes like this: currently, we do
the type-based check first: if two references are of different types,
they do not alias.  If they are of the same or compatible types, we
then proceed to ask (to oversimplify things) whether the references
can collide.  We obtain a three-way answer: yes, we know they collide
(aliasing); no, they never collide (no aliasing), or maybe, we can't tell
(assume aliasing to be safe).  Generally speaking, we do this analysis
by seeing if two references are both offsets from the same base address
and then look at the offsets.

The change is simply to postpone the type-based check until after the
other analysis is done.  If we detect that the references collide, but
the types say that we can assume they don't, we issue a warning and
then tell the compiler that there is aliasing.  (A variant is to silently
accept the code, but I would prefer issuing a warning).  If we fall into
the "maybe" case, we assume no aliasing if the types don't match.

Some questions:

- Can anyone tell me why this is not feasible?

- For those of you with code that is impacted by -fstrict-aliasing, can
  you look and see whether this modification would give you a warning?
  (That is, can the compiler see based on purely local information that
  the true address and the pointed-to object overlap)?

- Should we do this?

Joe

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    Joe> The change is simply to postpone the type-based check until
    Joe> after the other analysis is done.  If we detect that the
    Joe> references collide, but the types say that we can assume they
    Joe> don't, we issue a warning and then tell the compiler that
    Joe> there is aliasing.  (A variant is to silently accept the
    Joe> code, but I would prefer issuing a warning).  If we fall into
    Joe> the "maybe" case, we assume no aliasing if the types don't
    Joe> match.

I'd thought vaguely about this alternative in the past.  It is indeed
technically feasible.

However, I have a rather serious objection: it means that users cannot
tell whether their code is valid, even according to the GCC rules,
without knowing the internals of the compiler.  (It's dependent on
what the compiler can figure out about two addresses aliasing.  If the
compiler gets dumber, code breaks.  The compiler shouldn't get dumber,
in general, but it might in certain situations, while getting smarter
in others.  For example, if we replace some optimization algorithm
with another, we might do better in the average case, but worse in
some particular case.  Things that we used to know aliased we're now
not sure about.  Programs break.)

However, I do think this might be a good way to get useful warnings.
So, I would amend your proposal to "issue a warning and then tell the
compiler that there is no aliasing."  This would make it easier for
users to tell that there is a problem, which would indeed be a major
benefit.

The compiler should continue to aggressively break code that
misbehaves in this way.  Because we cannot (for technical reasons)
guarantee behavior in the future, we should break programs now; that
will make for fewer surprises down the road.

Coding like this is really no different than, say, assuming that you
call a varargs function without a prototype in sight.  It used to work
on most systems, and it still works on some.  But, it's not portable,
and people shouldn't do it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

>     Joe> The change is simply to postpone the type-based check until
>     Joe> after the other analysis is done.  If we detect that the
>     Joe> references collide, but the types say that we can assume they
>     Joe> don't, we issue a warning and then tell the compiler that
>     Joe> there is aliasing.  (A variant is to silently accept the
>     Joe> code, but I would prefer issuing a warning).  If we fall into
>     Joe> the "maybe" case, we assume no aliasing if the types don't
>     Joe> match.

Mark Mitchell writes:
> I'd thought vaguely about this alternative in the past.  It is indeed
> technically feasible.
> 
> However, I have a rather serious objection: it means that users cannot
> tell whether their code is valid, even according to the GCC rules,
> without knowing the internals of the compiler.

This is only true if we say that code for which we issue the warning is
valid under the GCC rules.  We could just as well say that it is *invalid*
and we are issuing the warning to help the user.  So I don't see how
doing this could cause any harm.  Yes, we won't catch all cases, but
we'll be educating users.  They'll see the warning occasionally, ask
about it, and learn.

> However, I do think this might be a good way to get useful warnings.
> So, I would amend your proposal to "issue a warning and then tell the
> compiler that there is no aliasing."  This would make it easier for
> users to tell that there is a problem, which would indeed be a major
> benefit.

This is fine with me, in fact that is really what I am proposing. (RMS
might have wanted to just accept it, but he said that a warning would
be OK with him).

> The compiler should continue to aggressively break code that
> misbehaves in this way.

This is a philosophical issue.  If you change "break" to "warn about"
I could go along, but some users may be depending on code that they
cannot fix immediately.

Re: type based aliasing again

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> The compiler should continue to aggressively break code that
Mark> misbehaves in this way.

>>>>> Joe Buck writes:

Joe> This is a philosophical issue.  If you change "break" to "warn about"
Joe> I could go along, but some users may be depending on code that they
Joe> cannot fix immediately.

	A user who cannot fix his or her code immediately can use
-fno-strict-aliasing, right?

	I think that GCC should continue to aggressively optimize code,
including code that mis-behaves.  If we can do a better job of warning
than other commercial compilers that support aliasing optimizations, then
we truly have a unique and beneficial features which helps users and gives
GCC an advantage.

David

Re: type based aliasing again

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> The compiler should continue to aggressively break code that
Mark> misbehaves in this way.

>>>>> Joe Buck writes:

Joe> This is a philosophical issue.  If you change "break" to "warn about"
Joe> I could go along, but some users may be depending on code that they
Joe> cannot fix immediately.

	A user who cannot fix his or her code immediately can use
-fno-strict-aliasing, right?

	I think that GCC should continue to aggressively optimize code,
including code that mis-behaves.  If we can do a better job of warning
than other commercial compilers that support aliasing optimizations, then
we truly have a unique and beneficial features which helps users and gives
GCC an advantage.

David

Re: type based aliasing again

[Joe Buck]

>     Joe> The change is simply to postpone the type-based check until
>     Joe> after the other analysis is done.  If we detect that the
>     Joe> references collide, but the types say that we can assume they
>     Joe> don't, we issue a warning and then tell the compiler that
>     Joe> there is aliasing.  (A variant is to silently accept the
>     Joe> code, but I would prefer issuing a warning).  If we fall into
>     Joe> the "maybe" case, we assume no aliasing if the types don't
>     Joe> match.

Mark Mitchell writes:
> I'd thought vaguely about this alternative in the past.  It is indeed
> technically feasible.
> 
> However, I have a rather serious objection: it means that users cannot
> tell whether their code is valid, even according to the GCC rules,
> without knowing the internals of the compiler.

This is only true if we say that code for which we issue the warning is
valid under the GCC rules.  We could just as well say that it is *invalid*
and we are issuing the warning to help the user.  So I don't see how
doing this could cause any harm.  Yes, we won't catch all cases, but
we'll be educating users.  They'll see the warning occasionally, ask
about it, and learn.

> However, I do think this might be a good way to get useful warnings.
> So, I would amend your proposal to "issue a warning and then tell the
> compiler that there is no aliasing."  This would make it easier for
> users to tell that there is a problem, which would indeed be a major
> benefit.

This is fine with me, in fact that is really what I am proposing. (RMS
might have wanted to just accept it, but he said that a warning would
be OK with him).

> The compiler should continue to aggressively break code that
> misbehaves in this way.

This is a philosophical issue.  If you change "break" to "warn about"
I could go along, but some users may be depending on code that they
cannot fix immediately.

Re: type based aliasing again

[Joe Buck]

Sorry, I responded to Mark's message too quickly and didn't grasp
a key point.

> However, I do think this might be a good way to get useful warnings.
> So, I would amend your proposal to "issue a warning and then tell the
> compiler that there is no aliasing."

Sigh.  If we can tell the user's intent, we should try to do the right thing.
If we're going to deliberately do the wrong thing, it would be best
to just issue a hard error.  The compiler shouldn't go on to do something
that we know has a good chance of generating bogus code.

So we have three variants.

A).  If we detect a rule violation, issue a warning and tell the compiler
     to assume aliasing.

B).  If we detect a rule violation, issue a warning and tell the compiler
     to assume no aliasing. (That is, produce bad code).

C).  If we detect a rule violation, issue an error and don't go on.

I think that only A) and C) are reasonable.  B) is not.  I would prefer
A).

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> A).  If we detect a rule violation, issue a warning and tell
    Joe> the compiler to assume aliasing.

    Joe> B).  If we detect a rule violation, issue a warning and tell
    Joe> the compiler to assume no aliasing. (That is, produce bad
    Joe> code).

    Joe> C).  If we detect a rule violation, issue an error and don't
    Joe> go on.

    Joe> I think that only A) and C) are reasonable.  B) is not.  I
    Joe> would prefer A).

I agree that C is reasonable.  But, it is not technically viable at
compile-time; the violation of the rule is a dynamic property.  For
example, consider:

  if (0) {
    /* Do illegal aliasing stuff.  */
  }

If we do dead-code elimination late, we might ask questions about the
aliasing in the conditional code.  Since that code never executes,
ANSI says there's no violation.  Warning here is sensible, though,
just as warning on `*((int*) 0) = 3' in the conditional code would be
sensible.

There will be cases where A will pessimize code that does not have
undefined behavior.  So, in fact, C is impossible, and A penalizes
conforming code.  Thus, B is the only remaining sensible option.

A technical problem is giving an intelligent warning; we no longer
know the types of the variables involved, by the time we could warn.
We are in RTL-land at that point.  But, even 

  warning: type-based alias analysis suggests your code is nonconforming
           (use -fno-strict-aliasing to disable type-based alias analysis)

might be better than nothing, especially if we could give a
line-number.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

Mark Mitchell writes:
> There will be cases where A will pessimize code that does not have
> undefined behavior.  So, in fact, C is impossible, and A penalizes
> conforming code.  Thus, B is the only remaining sensible option.

Your conclusion does not follow from the premise, unless you add
extra assumptions, like "It is not sensible to ever pessimize any
conforming program the least little bit, no matter how rare such
programs might be."

Could you give an example of such a case?  It seems that it could
only occur if

1. There is an illegal access, but
2. It can never be reached, but
3. We can't tell that it will never be reached.

If 1 is not true, the issue doesn't arise; if 2 is not true, the program
has undefined behavior; if 3 is not true, we've killed the affected code
in any case.

Do we really care if there is a marginal slowdown of code that satisfies
all three conditions?

Re: type based aliasing again

[Mark Mitchell]

  Mark Mitchell writes:
  > There will be cases where A will pessimize code that does not have
  > undefined behavior.  So, in fact, C is impossible, and A penalizes
  > conforming code.  Thus, B is the only remaining sensible option.

  Your conclusion does not follow from the premise, unless you add
  extra assumptions, like "It is not sensible to ever pessimize any
  conforming program the least little bit, no matter how rare such
  programs might be."

Agreed, modulo the strength of the statement.  Yes, I assumed it is
not sensible to pessimize conforming programs, and, yes, affected
conforming programs are probably semi-rare.

  Could you give an example of such a case?  It seems that it could
  only occur if

  1. There is an illegal access, but
  2. It can never be reached, but
  3. We can't tell that it will never be reached.

Right.  That's probably not as uncommon as it sounds.

One of your assumptions is that the only times we ask `does x alias y'
are when it is sensible to do so. :-)  We likely do so at other times
as well; I didn't point this out, but should have.  Consider:

  void *v = malloc (4);
  if (p)
    * ((float *) v) = 3;
  else
    * ((int *) v) = 7;

This code is conforming.  I don't mind terribly if we warn on this
code; I bet the number of false positives will be small.  But, we
shouldn't force the compiler to go slower in this case.  

Why might we want to know if these locations alias?  Hard to say.
But, we might.  For example, we might want to know if both values
could be live; type-based alias analysis says that at most one can be,
precisely because they are different types at the same address.

You might convince me that B is *not* sensible.  But, I doubt you will
convince me that A *is* sensible.  I really, really don't want to have
people complaining in a few years when we break some program that used
to work, just because we made our alias analysis behave slightly
differently.  I want all these programs to break today, so they get
fixed, rather than slowly break them one by one over the next several
years.

You asked users with nonconformant code whether local analysis would
spot the bugs.  In some cases it will.  In others, it won't.  In some,
it will depend on what the compiler does.  For example, does it inline
some function?  If so, more things become local.  So, now you have
programs that might work with -O3 but might break with -O2.  (It's not
that that can't already happen, but we shouldn't introduce gratuitous
ways of doing it.)  What some user thinks of as a local property GCC
may not.  Frightening though it is, people are sure to depend on the
warning as indicating that their code is *correct*; they will then
complain when it stops working, even though we were warning them it
was broken.

Saying "Don't violate ANSI/ISO aliasing rules, or else use
-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
we should muddy that with confusing semantics depending on GCC
internals.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

> One of your assumptions is that the only times we ask `does x alias y'
> are when it is sensible to do so. :-)  We likely do so at other times
> as well; I didn't point this out, but should have.  Consider:
> 
>   void *v = malloc (4);
>   if (p)
>     * ((float *) v) = 3;
>   else
>     * ((int *) v) = 7;
> 
> This code is conforming.  I don't mind terribly if we warn on this
> code; I bet the number of false positives will be small.  But, we
> shouldn't force the compiler to go slower in this case.  

I guess I am missing something in this example.  Could you explain
why we would get a warning?  The accesses are legal.  Yes, if you
check whether the two assignments alias there would be the possibility
of a false warning if you aren't careful.

> You asked users with nonconformant code whether local analysis would
> spot the bugs.  In some cases it will.  In others, it won't.  In some,
> it will depend on what the compiler does.  For example, does it inline
> some function?  If so, more things become local.  So, now you have
> programs that might work with -O3 but might break with -O2.

But this is just the reverse of what happens now; since -O2 will do
more reordering than -O, we already have programs that work with -O
and don't work with -O2 because of type-based aliasing.

> Saying "Don't violate ANSI/ISO aliasing rules, or else use
> -fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
> we should muddy that with confusing semantics depending on GCC
> internals.

I don't disagree.  You see, my code is silent in the presence of -Wall,
so in that sense the choice of A vs B would be a no-op for me; either
way, I would find and fix the aliasing bug.  If we issue a warning,
and the users never bother to clean up the warning, it is the user's
loss when the code later breaks.

So, if I can only have your amended proposal, I suppose I'll take it.
It's better than nothing.

	

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    >> One of your assumptions is that the only times we ask `does x
    >> alias y' are when it is sensible to do so. :-) We likely do so
    >> at other times as well; I didn't point this out, but should
    >> have.  Consider:
    >> 
    >> void *v = malloc (4); if (p) * ((float *) v) = 3; else * ((int
    >> *) v) = 7;
    >> 
    >> This code is conforming.  I don't mind terribly if we warn on
    >> this code; I bet the number of false positives will be small.
    >> But, we shouldn't force the compiler to go slower in this case.

    Joe> I guess I am missing something in this example.  Could you
    Joe> explain why we would get a warning?  The accesses are legal.
    Joe> Yes, if you check whether the two assignments alias there
    Joe> would be the possibility of a false warning if you aren't
    Joe> careful.

As you presented it, the algorithm was:

  o Whenever we check if two things alias,
  o First check to see if they definitely do,
  * Then, if there types would say they cannot, complain.

So, here, to avoid the warning/error, we must never check.  That's a
tough burden for the compiler.  

For example, it might be sensible to precompute an all-pairs aliasing
matrix for the RTL in the function, if we found that we were
recomputing the same data all the time.  (The (n,m) entry is whether
or not the Nth one can alias the Mth one.)  Merely computing that
matrix would trigger the warning.

    Joe> So, if I can only have your amended proposal, I suppose I'll
    Joe> take it.  It's better than nothing.

I agree.  Perhaps someone will implement it? :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    >> One of your assumptions is that the only times we ask `does x
    >> alias y' are when it is sensible to do so. :-) We likely do so
    >> at other times as well; I didn't point this out, but should
    >> have.  Consider:
    >> 
    >> void *v = malloc (4); if (p) * ((float *) v) = 3; else * ((int
    >> *) v) = 7;
    >> 
    >> This code is conforming.  I don't mind terribly if we warn on
    >> this code; I bet the number of false positives will be small.
    >> But, we shouldn't force the compiler to go slower in this case.

    Joe> I guess I am missing something in this example.  Could you
    Joe> explain why we would get a warning?  The accesses are legal.
    Joe> Yes, if you check whether the two assignments alias there
    Joe> would be the possibility of a false warning if you aren't
    Joe> careful.

As you presented it, the algorithm was:

  o Whenever we check if two things alias,
  o First check to see if they definitely do,
  * Then, if there types would say they cannot, complain.

So, here, to avoid the warning/error, we must never check.  That's a
tough burden for the compiler.  

For example, it might be sensible to precompute an all-pairs aliasing
matrix for the RTL in the function, if we found that we were
recomputing the same data all the time.  (The (n,m) entry is whether
or not the Nth one can alias the Mth one.)  Merely computing that
matrix would trigger the warning.

    Joe> So, if I can only have your amended proposal, I suppose I'll
    Joe> take it.  It's better than nothing.

I agree.  Perhaps someone will implement it? :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909090502.WAA24772@atrus.synopsys.com >you write:
  > > One of your assumptions is that the only times we ask `does x alias y'
  > > are when it is sensible to do so. :-)  We likely do so at other times
  > > as well; I didn't point this out, but should have.  Consider:
  > > 
  > >   void *v = malloc (4);
  > >   if (p)
  > >     * ((float *) v) = 3;
  > >   else
  > >     * ((int *) v) = 7;
  > > 
  > > This code is conforming.  I don't mind terribly if we warn on this
  > > code; I bet the number of false positives will be small.  But, we
  > > shouldn't force the compiler to go slower in this case.  
  > 
  > I guess I am missing something in this example.  Could you explain
  > why we would get a warning?  The accesses are legal.  Yes, if you
  > check whether the two assignments alias there would be the possibility
  > of a false warning if you aren't careful.
In general, we are going to be doing alias checks across basic blocks in
support of global optimizations.  So we can't assume that just because
two memory reerences are in different blocks that we will not ask about the
aliasing relationship between them.

Global load/store motions, speculative load motions, software pipelining,
cross block scheduling are good examples of optimizations which will be
making these kinds of alias queries.

Global LSM in particular is likely to trigger the warning since it needs to
compute for any given block what expressions are killed by that block.  I do
not believe that simple example can trigger, but I believe one with more
complex flow control could.

  > > You asked users with nonconformant code whether local analysis would
  > > spot the bugs.  In some cases it will.  In others, it won't.  In some,
  > > it will depend on what the compiler does.  For example, does it inline
  > > some function?  If so, more things become local.  So, now you have
  > > programs that might work with -O3 but might break with -O2.
  > 
  > But this is just the reverse of what happens now; since -O2 will do
  > more reordering than -O, we already have programs that work with -O
  > and don't work with -O2 because of type-based aliasing.
But the opposite can also happen.  inlining might also result in hiding the
linear relationship that the compiler was able to find when some call was
not inlined.  

And that strikes at the core issue in my mind.  Whether or not you get the
warning is going to be rather unpredictable, similarly whether or not gcc
arranges to compensate for invalid code is going to be highly unpredictable
too.

W have found over time, if we put an extension in the compiler, people will
come to depend on it and will complain loudly if the extension stops working
for any reason -- even if their code is broken.

This situation is bad enough when we can accurately document the extension,
but given an extension like this which can not be adequately documented it's
a long term liability and a series of complaints waiting to happen.

Also note that the code is not currently structured to be able to make the
kinds of queries we want.  ie, we can make the query "may these two references
alias each other".  To implement this we need "must these two references alias
each other".  This is not a reason to reject the proposal, but merely a note
to anyone that wants to work on an implementation.


jeff

Re: type based aliasing again

[Joe Buck]

Jeff writes:

> In general, we are going to be doing alias checks across basic blocks in
> support of global optimizations.  So we can't assume that just because
> two memory reerences are in different blocks that we will not ask about the
> aliasing relationship between them.

This, and Mark's examples, make clear that just because we see two
references to the same address that are of different (non-char *)
types, we can't conclude automatically that the user has violated
the rules.  We'd have to know somehow that one of the references
represents the true dynamic type and the other represents some other
type.  This makes things a little trickier.

I think we're going to need to try out some patches so that we can
do some experimentation.  How many false triggers would we get if
we followed my original naive approach (perhaps using Mark's
alterative B modification: issue the warning but proceed using
the ANSI rules)?

I don't think it's appropriate for us to throw up our hands and say
the problem is too hard.  There's a lot of code out there that breaks
the rules, and users will need at least some help finding it.
Otherwise people will just start putting -fno-strict-aliasing
in all their Makefiles, and Mark's work will not benefit users.

Re: type based aliasing again

[John Vickers]

Joe Buck wrote:
> 
> Jeff writes:
> 
> > In general, we are going to be doing alias checks across basic blocks in
> > support of global optimizations.  So we can't assume that just because
> > two memory reerences are in different blocks that we will not ask about the
> > aliasing relationship between them.
> 
> This, and Mark's examples, make clear that just because we see two
> references to the same address that are of different (non-char *)
> types, we can't conclude automatically that the user has violated
> the rules.  We'd have to know somehow that one of the references
> represents the true dynamic type and the other represents some other
> type.  This makes things a little trickier.
> 
> I think we're going to need to try out some patches so that we can
> do some experimentation.  How many false triggers would we get if
> we followed my original naive approach (perhaps using Mark's
> alterative B modification: issue the warning but proceed using
> the ANSI rules)?
> 

> I don't think it's appropriate for us to throw up our hands and say
> the problem is too hard.  

> There's a lot of code out there that breaks
> the rules, and users will need at least some help finding it.
> Otherwise people will just start putting -fno-strict-aliasing
> in all their Makefiles, and Mark's work will not benefit users.

This is the real problem.

A lot of the code - proprietary or otherwise - which people expect to
just "work" with gcc has no active maintainer.  Maybe it has no
maintainer
precisely because this same code has been working fine for years.

Linus has confused matters.  Linux is actively maintained.  Linus should
put up
or shut up.  If the folks who write linux & approve linux patches don't
understand
ANSI C that's their problem.  It's not as if ANSI/ISO C was something
new.
But the fuss he has made has diverted attention from the fact that a
vastly larger
body of semi-maintained software is now liable to break.

On the warning side, in practice it seems that many offending constructs
involve creating a single local variable, taking it's address, and
casting that address
to a different pointer type.  If even just that usage, within a single
basic block, were
diagnosed,  maybe a useful proportion of the problem cases would be
caught.

Regards,

John.

Re: type based aliasing again

[Joe Buck]

John Vickers writes:

> A lot of the code - proprietary or otherwise - which people expect to
> just "work" with gcc has no active maintainer.  Maybe it has no
> maintainer precisely because this same code has been working fine for
> years.

Yup.

[ Unnecessary shots at Linus deleted ]

> On the warning side, in practice it seems that many offending constructs
> involve creating a single local variable, taking it's address, and
> casting that address to a different pointer type.  If even just that
> usage, within a single basic block, were diagnosed, maybe a useful
> proportion of the problem cases would be caught.

Exactly; post violations I've seen are of that type.  I can't aspire to
the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
missing this point: a whole lot of the errors we've seen are of this
extremely simple form, with the entire error appearing in two or three
adjacent lines of code.  We know the exact offsets of each address and
can clearly see that they collide.

Re: type based aliasing again

[John Vickers]

Hi.

Joe Buck wrote:
> 
> [ Unnecessary shots at Linus deleted ]

O.K.

Excessive perhaps, but I don't think entirely unnecessary.

I think his intervention, and his general manner,
polarised & confused matters - but that's not entirely
his fault.

Regards,

John.

Re: type based aliasing again

[John Vickers]

Hi.

Joe Buck wrote:
> 
> [ Unnecessary shots at Linus deleted ]

O.K.

Excessive perhaps, but I don't think entirely unnecessary.

I think his intervention, and his general manner,
polarised & confused matters - but that's not entirely
his fault.

Regards,

John.

Re: type based aliasing again

[Joe Buck]

John Vickers writes:

> A lot of the code - proprietary or otherwise - which people expect to
> just "work" with gcc has no active maintainer.  Maybe it has no
> maintainer precisely because this same code has been working fine for
> years.

Yup.

[ Unnecessary shots at Linus deleted ]

> On the warning side, in practice it seems that many offending constructs
> involve creating a single local variable, taking it's address, and
> casting that address to a different pointer type.  If even just that
> usage, within a single basic block, were diagnosed, maybe a useful
> proportion of the problem cases would be caught.

Exactly; post violations I've seen are of that type.  I can't aspire to
the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
missing this point: a whole lot of the errors we've seen are of this
extremely simple form, with the entire error appearing in two or three
adjacent lines of code.  We know the exact offsets of each address and
can clearly see that they collide.

Re: type based aliasing again

[John Vickers]

Joe Buck wrote:
> 
> Jeff writes:
> 
> > In general, we are going to be doing alias checks across basic blocks in
> > support of global optimizations.  So we can't assume that just because
> > two memory reerences are in different blocks that we will not ask about the
> > aliasing relationship between them.
> 
> This, and Mark's examples, make clear that just because we see two
> references to the same address that are of different (non-char *)
> types, we can't conclude automatically that the user has violated
> the rules.  We'd have to know somehow that one of the references
> represents the true dynamic type and the other represents some other
> type.  This makes things a little trickier.
> 
> I think we're going to need to try out some patches so that we can
> do some experimentation.  How many false triggers would we get if
> we followed my original naive approach (perhaps using Mark's
> alterative B modification: issue the warning but proceed using
> the ANSI rules)?
> 

> I don't think it's appropriate for us to throw up our hands and say
> the problem is too hard.  

> There's a lot of code out there that breaks
> the rules, and users will need at least some help finding it.
> Otherwise people will just start putting -fno-strict-aliasing
> in all their Makefiles, and Mark's work will not benefit users.

This is the real problem.

A lot of the code - proprietary or otherwise - which people expect to
just "work" with gcc has no active maintainer.  Maybe it has no
maintainer
precisely because this same code has been working fine for years.

Linus has confused matters.  Linux is actively maintained.  Linus should
put up
or shut up.  If the folks who write linux & approve linux patches don't
understand
ANSI C that's their problem.  It's not as if ANSI/ISO C was something
new.
But the fuss he has made has diverted attention from the fact that a
vastly larger
body of semi-maintained software is now liable to break.

On the warning side, in practice it seems that many offending constructs
involve creating a single local variable, taking it's address, and
casting that address
to a different pointer type.  If even just that usage, within a single
basic block, were
diagnosed,  maybe a useful proportion of the problem cases would be
caught.

Regards,

John.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909091748.KAA14096@atrus.synopsys.com >you write:
  > I think we're going to need to try out some patches so that we can
  > do some experimentation.  How many false triggers would we get if
  > we followed my original naive approach (perhaps using Mark's
  > alterative B modification: issue the warning but proceed using
  > the ANSI rules)?
Yes.  And I think it's important that to get good results for us to use the
code which ties alias analysis into the gcse pass.  Otherwise we won't be
exercising the most likely cause of getting the false positives.

  > I don't think it's appropriate for us to throw up our hands and say
  > the problem is too hard.  There's a lot of code out there that breaks
  > the rules, and users will need at least some help finding it.
  > Otherwise people will just start putting -fno-strict-aliasing
  > in all their Makefiles, and Mark's work will not benefit users.
I'm not suggesting we give up, only that the problem is not as simple as 
some people seem to think. 

jeff

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909091748.KAA14096@atrus.synopsys.com >you write:
  > I think we're going to need to try out some patches so that we can
  > do some experimentation.  How many false triggers would we get if
  > we followed my original naive approach (perhaps using Mark's
  > alterative B modification: issue the warning but proceed using
  > the ANSI rules)?
Yes.  And I think it's important that to get good results for us to use the
code which ties alias analysis into the gcse pass.  Otherwise we won't be
exercising the most likely cause of getting the false positives.

  > I don't think it's appropriate for us to throw up our hands and say
  > the problem is too hard.  There's a lot of code out there that breaks
  > the rules, and users will need at least some help finding it.
  > Otherwise people will just start putting -fno-strict-aliasing
  > in all their Makefiles, and Mark's work will not benefit users.
I'm not suggesting we give up, only that the problem is not as simple as 
some people seem to think. 

jeff

Re: type based aliasing again

[Joe Buck]

Jeff writes:

> In general, we are going to be doing alias checks across basic blocks in
> support of global optimizations.  So we can't assume that just because
> two memory reerences are in different blocks that we will not ask about the
> aliasing relationship between them.

This, and Mark's examples, make clear that just because we see two
references to the same address that are of different (non-char *)
types, we can't conclude automatically that the user has violated
the rules.  We'd have to know somehow that one of the references
represents the true dynamic type and the other represents some other
type.  This makes things a little trickier.

I think we're going to need to try out some patches so that we can
do some experimentation.  How many false triggers would we get if
we followed my original naive approach (perhaps using Mark's
alterative B modification: issue the warning but proceed using
the ANSI rules)?

I don't think it's appropriate for us to throw up our hands and say
the problem is too hard.  There's a lot of code out there that breaks
the rules, and users will need at least some help finding it.
Otherwise people will just start putting -fno-strict-aliasing
in all their Makefiles, and Mark's work will not benefit users.

Re: type based aliasing again

[Richard Stallman]

    W have found over time, if we put an extension in the compiler, people will
    come to depend on it

I agree with you about this, but I am not proposing an extension.
Features have to be judged this way, but I am not proposing to add a
feature.  If you are thinking about this as a proposal for a feature,
I think you have not really understood the issue on the table.

Re: type based aliasing again

[Richard Stallman]

    W have found over time, if we put an extension in the compiler, people will
    come to depend on it

I agree with you about this, but I am not proposing an extension.
Features have to be judged this way, but I am not proposing to add a
feature.  If you are thinking about this as a proposal for a feature,
I think you have not really understood the issue on the table.

Re: type based aliasing again

[Richard Stallman]

People seem to be arguing that a new warning has a drawback
because it might sometimes happen for valid code.

Perhaps it will--but if so, that is not really a problem.  Other
warnings can also happen for valid code.  This is normal.

If the warning happens *often* for valid code, that could be a
significant practical nuisance.  But the cases people are discussing
are obscure, and should be rare enough that there will be no real
nuisance.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909100635.CAA01885@psilocin.gnu.org >you write:
  > People seem to be arguing that a new warning has a drawback
  > because it might sometimes happen for valid code.
  > 
  > Perhaps it will--but if so, that is not really a problem.  Other
  > warnings can also happen for valid code.  This is normal.
  > 
  > If the warning happens *often* for valid code, that could be a
  > significant practical nuisance.  But the cases people are discussing
  > are obscure, and should be rare enough that there will be no real
  > nuisance.
Agreed.  We'll have a much better idea how significant this issue is once
we have some code to play with.

I'll provide the bits to hook alias.c & gcse.c together since I suspect that's
the most likely place where we are likely to trigger the false positives.

jeff

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909100635.CAA01885@psilocin.gnu.org >you write:
  > People seem to be arguing that a new warning has a drawback
  > because it might sometimes happen for valid code.
  > 
  > Perhaps it will--but if so, that is not really a problem.  Other
  > warnings can also happen for valid code.  This is normal.
  > 
  > If the warning happens *often* for valid code, that could be a
  > significant practical nuisance.  But the cases people are discussing
  > are obscure, and should be rare enough that there will be no real
  > nuisance.
Agreed.  We'll have a much better idea how significant this issue is once
we have some code to play with.

I'll provide the bits to hook alias.c & gcse.c together since I suspect that's
the most likely place where we are likely to trigger the false positives.

jeff

Re: type based aliasing again

[Richard Stallman]

People seem to be arguing that a new warning has a drawback
because it might sometimes happen for valid code.

Perhaps it will--but if so, that is not really a problem.  Other
warnings can also happen for valid code.  This is normal.

If the warning happens *often* for valid code, that could be a
significant practical nuisance.  But the cases people are discussing
are obscure, and should be rare enough that there will be no real
nuisance.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909090502.WAA24772@atrus.synopsys.com >you write:
  > > One of your assumptions is that the only times we ask `does x alias y'
  > > are when it is sensible to do so. :-)  We likely do so at other times
  > > as well; I didn't point this out, but should have.  Consider:
  > > 
  > >   void *v = malloc (4);
  > >   if (p)
  > >     * ((float *) v) = 3;
  > >   else
  > >     * ((int *) v) = 7;
  > > 
  > > This code is conforming.  I don't mind terribly if we warn on this
  > > code; I bet the number of false positives will be small.  But, we
  > > shouldn't force the compiler to go slower in this case.  
  > 
  > I guess I am missing something in this example.  Could you explain
  > why we would get a warning?  The accesses are legal.  Yes, if you
  > check whether the two assignments alias there would be the possibility
  > of a false warning if you aren't careful.
In general, we are going to be doing alias checks across basic blocks in
support of global optimizations.  So we can't assume that just because
two memory reerences are in different blocks that we will not ask about the
aliasing relationship between them.

Global load/store motions, speculative load motions, software pipelining,
cross block scheduling are good examples of optimizations which will be
making these kinds of alias queries.

Global LSM in particular is likely to trigger the warning since it needs to
compute for any given block what expressions are killed by that block.  I do
not believe that simple example can trigger, but I believe one with more
complex flow control could.

  > > You asked users with nonconformant code whether local analysis would
  > > spot the bugs.  In some cases it will.  In others, it won't.  In some,
  > > it will depend on what the compiler does.  For example, does it inline
  > > some function?  If so, more things become local.  So, now you have
  > > programs that might work with -O3 but might break with -O2.
  > 
  > But this is just the reverse of what happens now; since -O2 will do
  > more reordering than -O, we already have programs that work with -O
  > and don't work with -O2 because of type-based aliasing.
But the opposite can also happen.  inlining might also result in hiding the
linear relationship that the compiler was able to find when some call was
not inlined.  

And that strikes at the core issue in my mind.  Whether or not you get the
warning is going to be rather unpredictable, similarly whether or not gcc
arranges to compensate for invalid code is going to be highly unpredictable
too.

W have found over time, if we put an extension in the compiler, people will
come to depend on it and will complain loudly if the extension stops working
for any reason -- even if their code is broken.

This situation is bad enough when we can accurately document the extension,
but given an extension like this which can not be adequately documented it's
a long term liability and a series of complaints waiting to happen.

Also note that the code is not currently structured to be able to make the
kinds of queries we want.  ie, we can make the query "may these two references
alias each other".  To implement this we need "must these two references alias
each other".  This is not a reason to reject the proposal, but merely a note
to anyone that wants to work on an implementation.


jeff

Re: type based aliasing again

[Richard Stallman]

    But this is just the reverse of what happens now; since -O2 will do
    more reordering than -O, we already have programs that work with -O
    and don't work with -O2 because of type-based aliasing.

There may also be some that work now with -O2 and not with -O.  I
don't know any examples, but if there are two instructions that could
be compiled in either order, it could be that -O chooses the order the
user doesn't want, and -O2 for random reasons chooses the order the
user does want.

In general, for any set of options, there will be a fairly large
number of cases of invalid aliasing that just happen to work,
because the optimizers decide not to do the possible optimizations
that could have changed the behavior.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> There may also be some that work now with -O2 and not
    Richard> with -O.  I don't know any examples, but if there are two
    Richard> instructions that could be compiled in either order, it
    Richard> could be that -O chooses the order the user doesn't want,
    Richard> and -O2 for random reasons chooses the order the user
    Richard> does want.

Naturally.  But, this proposal is odd in that it will *in general*
make programs work better at higher optimizations, because it is
likely that the optimizer will compute more information about what
aliases what.  In other words, this behavior will not be random; it
will be predictable.  It will be hard for people to figure out why
their programs work with -O3 but not with -O2.  They will likely
conclude, in fact, that the compiler has a bug.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

[ re: warn about bad aliasing ]

> Naturally.  But, this proposal is odd in that it will *in general*
> make programs work better at higher optimizations, because it is
> likely that the optimizer will compute more information about what
> aliases what.  In other words, this behavior will not be random; it
> will be predictable.  It will be hard for people to figure out why
> their programs work with -O3 but not with -O2.  They will likely
> conclude, in fact, that the compiler has a bug.

At least until they read the FAQ, where we will explain what is going
on.

Re: type based aliasing again

[Joe Buck]

[ re: warn about bad aliasing ]

> Naturally.  But, this proposal is odd in that it will *in general*
> make programs work better at higher optimizations, because it is
> likely that the optimizer will compute more information about what
> aliases what.  In other words, this behavior will not be random; it
> will be predictable.  It will be hard for people to figure out why
> their programs work with -O3 but not with -O2.  They will likely
> conclude, in fact, that the compiler has a bug.

At least until they read the FAQ, where we will explain what is going
on.

Re: type based aliasing again

[Richard Stallman]

    Naturally.  But, this proposal is odd in that it will *in general*
    make programs work better at higher optimizations, because it is
    likely that the optimizer will compute more information about what
    aliases what.

I think that will happen rarely if at all.  I think so because I think
almost all of these cases will be totally obvious, and GCC with -O1
or -O2 will do enough alias testing to prevent the optimizations
that would make them not work as intended.

But there could be some cases where this happens.

      It will be hard for people to figure out why
    their programs work with -O3 but not with -O2.  They will likely
    conclude, in fact, that the compiler has a bug.

We can live with a few users blaming us for mistakes that we did not
make.  Those who really care will send bug reports, and someone will
explain to them why the code is not valid, and then they will change it.

Right now, we have many users blaming us for a decision that the GCC
maintainers did knowingly make.

Re: type based aliasing again

[Richard Stallman]

    Naturally.  But, this proposal is odd in that it will *in general*
    make programs work better at higher optimizations, because it is
    likely that the optimizer will compute more information about what
    aliases what.

I think that will happen rarely if at all.  I think so because I think
almost all of these cases will be totally obvious, and GCC with -O1
or -O2 will do enough alias testing to prevent the optimizations
that would make them not work as intended.

But there could be some cases where this happens.

      It will be hard for people to figure out why
    their programs work with -O3 but not with -O2.  They will likely
    conclude, in fact, that the compiler has a bug.

We can live with a few users blaming us for mistakes that we did not
make.  Those who really care will send bug reports, and someone will
explain to them why the code is not valid, and then they will change it.

Right now, we have many users blaming us for a decision that the GCC
maintainers did knowingly make.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> There may also be some that work now with -O2 and not
    Richard> with -O.  I don't know any examples, but if there are two
    Richard> instructions that could be compiled in either order, it
    Richard> could be that -O chooses the order the user doesn't want,
    Richard> and -O2 for random reasons chooses the order the user
    Richard> does want.

Naturally.  But, this proposal is odd in that it will *in general*
make programs work better at higher optimizations, because it is
likely that the optimizer will compute more information about what
aliases what.  In other words, this behavior will not be random; it
will be predictable.  It will be hard for people to figure out why
their programs work with -O3 but not with -O2.  They will likely
conclude, in fact, that the compiler has a bug.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Stallman]

    But this is just the reverse of what happens now; since -O2 will do
    more reordering than -O, we already have programs that work with -O
    and don't work with -O2 because of type-based aliasing.

There may also be some that work now with -O2 and not with -O.  I
don't know any examples, but if there are two instructions that could
be compiled in either order, it could be that -O chooses the order the
user doesn't want, and -O2 for random reasons chooses the order the
user does want.

In general, for any set of options, there will be a fairly large
number of cases of invalid aliasing that just happen to work,
because the optimizers decide not to do the possible optimizations
that could have changed the behavior.

Re: type based aliasing again

[Joe Buck]

> One of your assumptions is that the only times we ask `does x alias y'
> are when it is sensible to do so. :-)  We likely do so at other times
> as well; I didn't point this out, but should have.  Consider:
> 
>   void *v = malloc (4);
>   if (p)
>     * ((float *) v) = 3;
>   else
>     * ((int *) v) = 7;
> 
> This code is conforming.  I don't mind terribly if we warn on this
> code; I bet the number of false positives will be small.  But, we
> shouldn't force the compiler to go slower in this case.  

I guess I am missing something in this example.  Could you explain
why we would get a warning?  The accesses are legal.  Yes, if you
check whether the two assignments alias there would be the possibility
of a false warning if you aren't careful.

> You asked users with nonconformant code whether local analysis would
> spot the bugs.  In some cases it will.  In others, it won't.  In some,
> it will depend on what the compiler does.  For example, does it inline
> some function?  If so, more things become local.  So, now you have
> programs that might work with -O3 but might break with -O2.

But this is just the reverse of what happens now; since -O2 will do
more reordering than -O, we already have programs that work with -O
and don't work with -O2 because of type-based aliasing.

> Saying "Don't violate ANSI/ISO aliasing rules, or else use
> -fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
> we should muddy that with confusing semantics depending on GCC
> internals.

I don't disagree.  You see, my code is silent in the presence of -Wall,
so in that sense the choice of A vs B would be a no-op for me; either
way, I would find and fix the aliasing bug.  If we issue a warning,
and the users never bother to clean up the warning, it is the user's
loss when the code later breaks.

So, if I can only have your amended proposal, I suppose I'll take it.
It's better than nothing.

	

Re: type based aliasing again

[Richard Henderson]

On Wed, Sep 08, 1999 at 09:49:11PM -0700, Mark Mitchell wrote:
>   void *v = malloc (4);
>   if (p)
>     * ((float *) v) = 3;
>   else
>     * ((int *) v) = 7;
> 
> This code is conforming.  I don't mind terribly if we warn on this
> code; I bet the number of false positives will be small.

FYI, we can easily screw this up at the moment (or at least a variant
of it; probably something a bit more complicated than this): 

    if (p)
	* ((int *) v) = &i;		[bb 1]
    else
	* ((short *) v) = &s;		[bb 3]

We'll have two insns

	(set (mem:SI (reg:SI 100) 1) (symbol_ref:SI "i"))
	(set (mem:SI (reg:SI 100) 2) (symbol_ref:SI "s"))

We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
same expression number. 

HOWEVER: when computing antloc for the expression in bb3, we'll
see that (mem .. 2) cannot possibly alias our expression (mem .. 1),
so we'll consider antloc true.

I've got an example c++ program that triggers this with compiler
generated temporaries and inline functions.  The symptom is that
lcm hoists a load out of a loop because it doesn't recognize the
store as aliasing.  I hadn't previously thought of a conforming
example that might do it without compiler temporaries.

Hmm...


r~

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> I've got an example c++ program that triggers this with
    Richard> compiler generated temporaries and inline functions.  The
    Richard> symptom is that lcm hoists a load out of a loop because
    Richard> it doesn't recognize the store as aliasing.

Oh, dear.  Well, I take solace only in that I guess it's not the
type-based aliasing code *itself* that's screwed up.  :-)

  We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
  we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
  same expression number. 

I don't know this code at all, but shouldn't we not think these match?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Henderson]

On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell wrote:
>   We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
>   we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
>   same expression number. 
> 
> I don't know this code at all, but shouldn't we not think these match?

It's been a week or two since I poked at this -- at the time
there was some line of reasoning that led me to believe that
that would simply cause a different sort of failure.

Jeff, do you remember?


r~

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell
    Richard> wrote:
    >> We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression
    >> tables, we'll see that (mem:SI (reg:SI 100) 2) matches it, and
    >> reuse the same expression number.
    >> 
    >> I don't know this code at all, but shouldn't we not think these
    >> match?

    Richard> It's been a week or two since I poked at this -- at the
    Richard> time there was some line of reasoning that led me to
    Richard> believe that that would simply cause a different sort of
    Richard> failure.

One would hope, naively, that telling GCSE things are *not* the same
should be the conservative case.  But, I've got no idea what I'm
talking about at all, so I should just shut up.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell
    Richard> wrote:
    >> We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression
    >> tables, we'll see that (mem:SI (reg:SI 100) 2) matches it, and
    >> reuse the same expression number.
    >> 
    >> I don't know this code at all, but shouldn't we not think these
    >> match?

    Richard> It's been a week or two since I poked at this -- at the
    Richard> time there was some line of reasoning that led me to
    Richard> believe that that would simply cause a different sort of
    Richard> failure.

One would hope, naively, that telling GCSE things are *not* the same
should be the conservative case.  But, I've got no idea what I'm
talking about at all, so I should just shut up.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Jeffrey A Law]

  In message < 19990908234259.A23715@cygnus.com >you write:
  > On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell wrote:
  > >   We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
  > >   we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
  > >   same expression number. 
  > > 
  > > I don't know this code at all, but shouldn't we not think these match?
  > 
  > It's been a week or two since I poked at this -- at the time
  > there was some line of reasoning that led me to believe that
  > that would simply cause a different sort of failure.
  > 
  > Jeff, do you remember?
It's real fuzzy now.  I thought we were looking at the stack slot reuse
code as the culprit.

But given the way we do alias analysis we have two mems with different alias,
thus they're assumed not to alias.

I wasn't aware that we were putting the two memory references into the same
slot in the expression table.  That's interesting and would cause problems.
It seems to me that two memory references with different alias sets need to
be two different expressions.

The question then becomes what happens when we try to hoist these two
expressions.  In particular can we ever hoist them into the same block.

I'm 99% certain the answer is no if we can split critical edges.  The
answer is yes if we can not split critical edges.

Also note, gcse would currently do nothing with that case since you're
talking about assignment motion, not expression motion.  ie, we currently
move expression evaluations.  Not assignments.

Assignment motion is in the long term plans, particularly once we have the new
gcse code from Andrew.  Conceptually it's a simple extension to our existing
expression motion and involves moving assignments upwards in the cfg) to expose
more redundancies.

Also note that given the downward store motion support Andrew is doing, plus
assignment motion support, then we can do partial dead code elimination
(which involves moving assignments down in the cfg to expose code which is
dead, but only on certain paths through the cfg).

jeff

Re: type based aliasing again

[Jeffrey A Law]

  In message < 19990908234259.A23715@cygnus.com >you write:
  > On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell wrote:
  > >   We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
  > >   we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
  > >   same expression number. 
  > > 
  > > I don't know this code at all, but shouldn't we not think these match?
  > 
  > It's been a week or two since I poked at this -- at the time
  > there was some line of reasoning that led me to believe that
  > that would simply cause a different sort of failure.
  > 
  > Jeff, do you remember?
It's real fuzzy now.  I thought we were looking at the stack slot reuse
code as the culprit.

But given the way we do alias analysis we have two mems with different alias,
thus they're assumed not to alias.

I wasn't aware that we were putting the two memory references into the same
slot in the expression table.  That's interesting and would cause problems.
It seems to me that two memory references with different alias sets need to
be two different expressions.

The question then becomes what happens when we try to hoist these two
expressions.  In particular can we ever hoist them into the same block.

I'm 99% certain the answer is no if we can split critical edges.  The
answer is yes if we can not split critical edges.

Also note, gcse would currently do nothing with that case since you're
talking about assignment motion, not expression motion.  ie, we currently
move expression evaluations.  Not assignments.

Assignment motion is in the long term plans, particularly once we have the new
gcse code from Andrew.  Conceptually it's a simple extension to our existing
expression motion and involves moving assignments upwards in the cfg) to expose
more redundancies.

Also note that given the downward store motion support Andrew is doing, plus
assignment motion support, then we can do partial dead code elimination
(which involves moving assignments down in the cfg to expose code which is
dead, but only on certain paths through the cfg).

jeff

Re: type based aliasing again

[Richard Henderson]

On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell wrote:
>   We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
>   we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
>   same expression number. 
> 
> I don't know this code at all, but shouldn't we not think these match?

It's been a week or two since I poked at this -- at the time
there was some line of reasoning that led me to believe that
that would simply cause a different sort of failure.

Jeff, do you remember?


r~

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> I've got an example c++ program that triggers this with
    Richard> compiler generated temporaries and inline functions.  The
    Richard> symptom is that lcm hoists a load out of a loop because
    Richard> it doesn't recognize the store as aliasing.

Oh, dear.  Well, I take solace only in that I guess it's not the
type-based aliasing code *itself* that's screwed up.  :-)

  We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
  we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
  same expression number. 

I don't know this code at all, but shouldn't we not think these match?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Henderson]

On Wed, Sep 08, 1999 at 09:49:11PM -0700, Mark Mitchell wrote:
>   void *v = malloc (4);
>   if (p)
>     * ((float *) v) = 3;
>   else
>     * ((int *) v) = 7;
> 
> This code is conforming.  I don't mind terribly if we warn on this
> code; I bet the number of false positives will be small.

FYI, we can easily screw this up at the moment (or at least a variant
of it; probably something a bit more complicated than this): 

    if (p)
	* ((int *) v) = &i;		[bb 1]
    else
	* ((short *) v) = &s;		[bb 3]

We'll have two insns

	(set (mem:SI (reg:SI 100) 1) (symbol_ref:SI "i"))
	(set (mem:SI (reg:SI 100) 2) (symbol_ref:SI "s"))

We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
same expression number. 

HOWEVER: when computing antloc for the expression in bb3, we'll
see that (mem .. 2) cannot possibly alias our expression (mem .. 1),
so we'll consider antloc true.

I've got an example c++ program that triggers this with compiler
generated temporaries and inline functions.  The symptom is that
lcm hoists a load out of a loop because it doesn't recognize the
store as aliasing.  I hadn't previously thought of a conforming
example that might do it without compiler temporaries.

Hmm...


r~

Re: type based aliasing again

[Mark Mitchell]

  Mark Mitchell writes:
  > There will be cases where A will pessimize code that does not have
  > undefined behavior.  So, in fact, C is impossible, and A penalizes
  > conforming code.  Thus, B is the only remaining sensible option.

  Your conclusion does not follow from the premise, unless you add
  extra assumptions, like "It is not sensible to ever pessimize any
  conforming program the least little bit, no matter how rare such
  programs might be."

Agreed, modulo the strength of the statement.  Yes, I assumed it is
not sensible to pessimize conforming programs, and, yes, affected
conforming programs are probably semi-rare.

  Could you give an example of such a case?  It seems that it could
  only occur if

  1. There is an illegal access, but
  2. It can never be reached, but
  3. We can't tell that it will never be reached.

Right.  That's probably not as uncommon as it sounds.

One of your assumptions is that the only times we ask `does x alias y'
are when it is sensible to do so. :-)  We likely do so at other times
as well; I didn't point this out, but should have.  Consider:

  void *v = malloc (4);
  if (p)
    * ((float *) v) = 3;
  else
    * ((int *) v) = 7;

This code is conforming.  I don't mind terribly if we warn on this
code; I bet the number of false positives will be small.  But, we
shouldn't force the compiler to go slower in this case.  

Why might we want to know if these locations alias?  Hard to say.
But, we might.  For example, we might want to know if both values
could be live; type-based alias analysis says that at most one can be,
precisely because they are different types at the same address.

You might convince me that B is *not* sensible.  But, I doubt you will
convince me that A *is* sensible.  I really, really don't want to have
people complaining in a few years when we break some program that used
to work, just because we made our alias analysis behave slightly
differently.  I want all these programs to break today, so they get
fixed, rather than slowly break them one by one over the next several
years.

You asked users with nonconformant code whether local analysis would
spot the bugs.  In some cases it will.  In others, it won't.  In some,
it will depend on what the compiler does.  For example, does it inline
some function?  If so, more things become local.  So, now you have
programs that might work with -O3 but might break with -O2.  (It's not
that that can't already happen, but we shouldn't introduce gratuitous
ways of doing it.)  What some user thinks of as a local property GCC
may not.  Frightening though it is, people are sure to depend on the
warning as indicating that their code is *correct*; they will then
complain when it stops working, even though we were warning them it
was broken.

Saying "Don't violate ANSI/ISO aliasing rules, or else use
-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
we should muddy that with confusing semantics depending on GCC
internals.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

Mark Mitchell writes:
> There will be cases where A will pessimize code that does not have
> undefined behavior.  So, in fact, C is impossible, and A penalizes
> conforming code.  Thus, B is the only remaining sensible option.

Your conclusion does not follow from the premise, unless you add
extra assumptions, like "It is not sensible to ever pessimize any
conforming program the least little bit, no matter how rare such
programs might be."

Could you give an example of such a case?  It seems that it could
only occur if

1. There is an illegal access, but
2. It can never be reached, but
3. We can't tell that it will never be reached.

If 1 is not true, the issue doesn't arise; if 2 is not true, the program
has undefined behavior; if 3 is not true, we've killed the affected code
in any case.

Do we really care if there is a marginal slowdown of code that satisfies
all three conditions?

Re: type based aliasing again

[Joe Buck]

One more thought:

[ C means that we declare an error if we detect illegal aliasing ]

Mark writes:
> I agree that C is reasonable.  But, it is not technically viable at
> compile-time; the violation of the rule is a dynamic property.  For
> example, consider:
> 
>   if (0) {
>     /* Do illegal aliasing stuff.  */
>   }
> 
> If we do dead-code elimination late, we might ask questions about the
> aliasing in the conditional code.  Since that code never executes,
> ANSI says there's no violation.

Careful.  Are you sure that ANSI says that we can't call this an error?
Is the language describing the type rules for accesses distinct from
other language like

	const int foo = 3;
	if (0) {
		foo = 4;
	}

?  It's illegal to assign to a const, but here we are not assigning to
a const, because the code is unreachable.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    >> I agree that C is reasonable.  But, it is not technically
    >> viable at compile-time; the violation of the rule is a dynamic
    >> property.  For example, consider:
    >> 
    >> if (0) { /* Do illegal aliasing stuff.  */ }
    >> 
    >> If we do dead-code elimination late, we might ask questions
    >> about the aliasing in the conditional code.  Since that code
    >> never executes, ANSI says there's no violation.

    Joe> Careful.  Are you sure that ANSI says that we can't call this
    Joe> an error?

Here's a little language from [intro.execution] in the C++ standard.
(It's the same, in spirit, as the C standard.)

  However, if any such execution sequence contains an undefined
  operation, this International Standard places no requirement on the
  implementation executing that program with that input (not even with
  regard to operations preceding the first undefined operation).

There's no execution sequence that causes the illegal behvaior.  (Your
example, with const, is ill-formed, which is different.)  

Someone might care to argume otherwise, though; the standard isn't
crystal clear in this respect. 

But, that still leaves the problem mentioned in my other email; giving
an error here would require that we only ask whether two things alias
when that's sensible; the 

  if (x)
    *((short *) v) = 3;
  else
    *((int *) v) = 7;

example would then be one in which we *must* not ask whether these two
things alias.  That's an unreasonable technical restriction on the
compiler.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    >> I agree that C is reasonable.  But, it is not technically
    >> viable at compile-time; the violation of the rule is a dynamic
    >> property.  For example, consider:
    >> 
    >> if (0) { /* Do illegal aliasing stuff.  */ }
    >> 
    >> If we do dead-code elimination late, we might ask questions
    >> about the aliasing in the conditional code.  Since that code
    >> never executes, ANSI says there's no violation.

    Joe> Careful.  Are you sure that ANSI says that we can't call this
    Joe> an error?

Here's a little language from [intro.execution] in the C++ standard.
(It's the same, in spirit, as the C standard.)

  However, if any such execution sequence contains an undefined
  operation, this International Standard places no requirement on the
  implementation executing that program with that input (not even with
  regard to operations preceding the first undefined operation).

There's no execution sequence that causes the illegal behvaior.  (Your
example, with const, is ill-formed, which is different.)  

Someone might care to argume otherwise, though; the standard isn't
crystal clear in this respect. 

But, that still leaves the problem mentioned in my other email; giving
an error here would require that we only ask whether two things alias
when that's sensible; the 

  if (x)
    *((short *) v) = 3;
  else
    *((int *) v) = 7;

example would then be one in which we *must* not ask whether these two
things alias.  That's an unreasonable technical restriction on the
compiler.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Martin v. Loewis]

> Careful.  Are you sure that ANSI says that we can't call this an error?
> Is the language describing the type rules for accesses distinct from
> other language like
> 
> 	const int foo = 3;
> 	if (0) {
> 		foo = 4;
> 	}
> 
> ?  It's illegal to assign to a const, but here we are not assigning to
> a const, because the code is unreachable.

There's a difference between ill-formed code (which typically must be
diagnosed), and code exhibiting undefined behaviour. Your example is
of the former category; the aliasing stuff is of the latter.

Of course, the compiler may produce warnings which are not
diagnostics; it must still accept a well-formed program afterwards.

Regards,
Martin

Re: type based aliasing again

[Martin v. Loewis]

> Careful.  Are you sure that ANSI says that we can't call this an error?
> Is the language describing the type rules for accesses distinct from
> other language like
> 
> 	const int foo = 3;
> 	if (0) {
> 		foo = 4;
> 	}
> 
> ?  It's illegal to assign to a const, but here we are not assigning to
> a const, because the code is unreachable.

There's a difference between ill-formed code (which typically must be
diagnosed), and code exhibiting undefined behaviour. Your example is
of the former category; the aliasing stuff is of the latter.

Of course, the compiler may produce warnings which are not
diagnostics; it must still accept a well-formed program afterwards.

Regards,
Martin

Re: type based aliasing again

[Richard Stallman]

If we use the term "illegal" to describe user code, it carries the
implication that the users who wrote it are evildoers and ought to be
punished.

That's why there is a GNU convention of describing code which
doesn't follow the language rules as "invalid", not "illegal".

Especially in this discussion, it is important to follow that
convention, because the word "illegal" tends to support
a harsh attitude towards these users, and that tends to mean
a bad decision.

Re: type based aliasing again

[Richard Stallman]

If we use the term "illegal" to describe user code, it carries the
implication that the users who wrote it are evildoers and ought to be
punished.

That's why there is a GNU convention of describing code which
doesn't follow the language rules as "invalid", not "illegal".

Especially in this discussion, it is important to follow that
convention, because the word "illegal" tends to support
a harsh attitude towards these users, and that tends to mean
a bad decision.

Re: type based aliasing again

[Joe Buck]

One more thought:

[ C means that we declare an error if we detect illegal aliasing ]

Mark writes:
> I agree that C is reasonable.  But, it is not technically viable at
> compile-time; the violation of the rule is a dynamic property.  For
> example, consider:
> 
>   if (0) {
>     /* Do illegal aliasing stuff.  */
>   }
> 
> If we do dead-code elimination late, we might ask questions about the
> aliasing in the conditional code.  Since that code never executes,
> ANSI says there's no violation.

Careful.  Are you sure that ANSI says that we can't call this an error?
Is the language describing the type rules for accesses distinct from
other language like

	const int foo = 3;
	if (0) {
		foo = 4;
	}

?  It's illegal to assign to a const, but here we are not assigning to
a const, because the code is unreachable.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 19990908202957F.mitchell@codesourcery.com >you write:
  > I agree that C is reasonable.  But, it is not technically viable at
  > compile-time; the violation of the rule is a dynamic property.  For
  > example, consider:
  > 
  >   if (0) {
  >     /* Do illegal aliasing stuff.  */
  >   }
  > 
  > If we do dead-code elimination late, we might ask questions about the
  > aliasing in the conditional code.  Since that code never executes,
  > ANSI says there's no violation.  Warning here is sensible, though,
  > just as warning on `*((int*) 0) = 3' in the conditional code would be
  > sensible.
FYI, this kind of code could be deleted at a variety of stages in compilation
depending on what optimization exposed the unreachable code (terminology
note, this is unreachable code, not dead code ;-)

For example, "if (0)" at the source level would probably be zapped by the
first jump pass.  I do not believe we do any aliasing checks before jump1.

cse can expose code like this, and we do aliasing queries in cse.  When
CSE exposes this code it is eliminated immediately after cse by a jump pass.

gcse can also expose code like this.  The current snapshots do not have any
aliasing tied into gcse.  However, basic global load motion is done and will
be donated as soon as I can find some time.  At that point gcse will be doing
alias queries.  Also note global store motion is also in the pipeline.
If gcse exposes any code like this it will be deleted by a jump pass after
gcse.

etc etc etc.


  > A technical problem is giving an intelligent warning; we no longer
  > know the types of the variables involved, by the time we could warn.
  > We are in RTL-land at that point.  But, even 
Right, no types.  Getting line numbers may not be particularly easy either
depending on the pass.

The current way I've handling aliasing issues in gcse would make it
straight forward to get the line number for the two memory references.
[ Remember, we're comparing two values, which could come from different
  lines. ]

jeff

Re: type based aliasing again

[craig]

>  In message < 19990908202957F.mitchell@codesourcery.com >you write:
>  > I agree that C is reasonable.  But, it is not technically viable at
>  > compile-time; the violation of the rule is a dynamic property.  For
>  > example, consider:
>  > 
>  >   if (0) {
>  >     /* Do illegal aliasing stuff.  */
>  >   }
>  > 
>  > If we do dead-code elimination late, we might ask questions about the
>  > aliasing in the conditional code.  Since that code never executes,
>  > ANSI says there's no violation.  Warning here is sensible, though,
>  > just as warning on `*((int*) 0) = 3' in the conditional code would be
>  > sensible.
>FYI, this kind of code could be deleted at a variety of stages in compilation
>depending on what optimization exposed the unreachable code (terminology
>note, this is unreachable code, not dead code ;-)
[...]

IMO, when you are considering stuff like this, please replace

  if (0)

with

  scanf ("%d", &i);  /* or whatever, i hate scanf anyway, think READ *, I. */
  if (i)

and the programmer's "out-of-band" promise that anytime that that particular
scanf executes, it will always read a 0 (from stdin).

I'm not *sure* about this, but it looks like this discussion is going
in the direction of "we can do something not quite kosher by finding
all cases of suspect code that won't actually be reached in practice".

If that's the case, it's wrong.

BTW, I agree 100% with this contribution from Mark:

>Saying "Don't violate ANSI/ISO aliasing rules, or else use
>-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
>we should muddy that with confusing semantics depending on GCC
>internals.

I also agree a warning where we *can* detect potential aliasing violations
would be nice.  Leave it to the usual "discovery process" to determine
whether it should be the default, the default for -Wall, whatever.

However, it's my impression that the mere printing, even requesting,
of a warning should make *no* difference in the generated code.  Just
like gcc promises for -g, except, here, I mean no difference in
the generated assembler output, not just the code within that.

In that case, it would be wrong to connect to the printing of a warning
(or the user requesting that type of warning) doing something like
turning off alias analysis.  GCC doesn't, upon warning about
a possible uninitialized variable, silently insert an initialization,
does it?  (By which I mean, we don't document that it does that, right?)

Note that falling back to the "let's just generate a warning" position
isn't a panacea:

  #!/bin/sh, or some approximation thereof

  # Compile $1 vis-a-vis gcc's annoying aliasing behavior and options in $2.
  gcc -Walias $2 -c $1 2>diagnostics.out
  status=$?
  if [ $status != 0 ]
  then
    exit $status
  fi

  # See if any alias warnings were issued, and recompile without alias
  # analysis if so.
  grep -q alias diagnostics.out
  if [ $? = 0 ]
  then
    gcc -fno-alias-analysis $2 -c $1
    status = $?
  fi
  rm diagnostics.out
  exit $status

People who think GCC should have done what has been recommended here,
i.e. revert to no alias analysis upon detecting possible violations
(and warning about them), will probably use a script like the above
to get the desired behavior themselves.

And, they will complain just as loudly when it "stops working", which
will mean, to them, either "no longer catches a particular aliasing
violation in my code, leading to hours of my time tracking down this
GCC bug causing a failure to correctly warn" or "now warns about something
that isn't really a problem, leading to hours of my time tracking
down this loss of performance".

(I'm not saying this sort of end-user behavior is to be expected for
all instances of generating warnings about not-strictly-correct code.
But given the huge amount of attention this problem, which has long
had the simple -fno-strict-aliasing workaround, has gotten on this
list during just this year, I think *this* particular warning is
a candidate for this sort of treatment.)

        tq vm, (burley)

Re: type based aliasing again

[Joe Buck]

Craig writes:
> I'm not *sure* about this, but it looks like this discussion is going
> in the direction of "we can do something not quite kosher by finding
> all cases of suspect code that won't actually be reached in practice".

That is not my intention.

> People who think GCC should have done what has been recommended here,
> i.e. revert to no alias analysis upon detecting possible violations
> (and warning about them), will probably use a script like the above
> to get the desired behavior themselves.

Let's get out of the mode of treating the user like an opponent.
We need to make clear that the fact that we issue warnings for some
type violations is not a guarantee that code not warned about is safe.

The perfect is often the enemy of the good.  By adding a warning, we
will get people to fix some more bugs.  The fact that the warning won't
catch all cases is just life.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> Let's get out of the mode of treating the user like an
    Joe> opponent.  We need to make clear that the fact that we issue
    Joe> warnings for some type violations is not a guarantee that
    Joe> code not warned about is safe.

I do think that the warning, if we can figure out how to make it
useful, is a good thing.  (As we've discussed, doing that is
non-trivial technically, even though it is certainly theoretically
possible.)  (It's easy to say "something in this function might be
bogus"; harder to give a more intelligent message complete with types,
line numbers, etc.)

But, while the user is not an opponent, and while I'm not sure people
would really make the kinds of scripts Craig mentioned, I do think
Craig and I agree on the fact that a poorly-specified extension will
frustruate users in two respects: 

  o Why doesn't the compiler know that these two things, which 
    "obviously" refer to the same location, alias?  Why don't I
    get the warning (and hence safe code) in that case?  Why,
    when I make the following "insignificant" change, does the
    compiler figure out then?

    People will complain about this.  And people will submit patches
    to help the compiler "know" these things.  (If these patches
    consist of genuinely improved alias analysis, that will be good;
    if they are just hacks to get old broken code to work, that will
    be bad.)

  o Why, when six months ago my code worked fine, and now I upgraded
    GCC, did it break?

    People are unlikely to notice that some warning *went away*, and
    that therefore their code is *more* likely to break.  (They don't
    even tend to notice *new* warnings, but I, for one, can't imagine
    myself noticing that my favorite software package compiled with
    fewer warnings.  And if I did, I can't imagine being *worried*.)

I do think the warning could be valuable, especially if it could say:

  `x' and `y' have different types, but seem to refer to the same 
  memory location

Right now the only easy thing to print for `x' and `y' is going to be
a pile of RTL; not useful to the average person.  We could save the
types used to create the alias sets (especially now that we have GC,
and therefore it's easy to keep them around); then it would be simple
to say 

  `double' and `int' have different types, but you seem to have memory
  that has both of these types at once

But, that's about as good as we could without some kind of major
infrastructure overhaul.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Stallman]

    Craig and I agree on the fact that a poorly-specified extension will
    frustruate users in two respects: 

I agree, too.  When we add a new feature, we should document it
clearly, and undertake to support it.

I've made a proposal for a change which is not an extension,
not a feature--but will give users more of what they expect.
If you're thinking of it as a kind of feature, you're not
responding to the proposal that I made.

Re: type based aliasing again

[Richard Stallman]

    Craig and I agree on the fact that a poorly-specified extension will
    frustruate users in two respects: 

I agree, too.  When we add a new feature, we should document it
clearly, and undertake to support it.

I've made a proposal for a change which is not an extension,
not a feature--but will give users more of what they expect.
If you're thinking of it as a kind of feature, you're not
responding to the proposal that I made.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> Let's get out of the mode of treating the user like an
    Joe> opponent.  We need to make clear that the fact that we issue
    Joe> warnings for some type violations is not a guarantee that
    Joe> code not warned about is safe.

I do think that the warning, if we can figure out how to make it
useful, is a good thing.  (As we've discussed, doing that is
non-trivial technically, even though it is certainly theoretically
possible.)  (It's easy to say "something in this function might be
bogus"; harder to give a more intelligent message complete with types,
line numbers, etc.)

But, while the user is not an opponent, and while I'm not sure people
would really make the kinds of scripts Craig mentioned, I do think
Craig and I agree on the fact that a poorly-specified extension will
frustruate users in two respects: 

  o Why doesn't the compiler know that these two things, which 
    "obviously" refer to the same location, alias?  Why don't I
    get the warning (and hence safe code) in that case?  Why,
    when I make the following "insignificant" change, does the
    compiler figure out then?

    People will complain about this.  And people will submit patches
    to help the compiler "know" these things.  (If these patches
    consist of genuinely improved alias analysis, that will be good;
    if they are just hacks to get old broken code to work, that will
    be bad.)

  o Why, when six months ago my code worked fine, and now I upgraded
    GCC, did it break?

    People are unlikely to notice that some warning *went away*, and
    that therefore their code is *more* likely to break.  (They don't
    even tend to notice *new* warnings, but I, for one, can't imagine
    myself noticing that my favorite software package compiled with
    fewer warnings.  And if I did, I can't imagine being *worried*.)

I do think the warning could be valuable, especially if it could say:

  `x' and `y' have different types, but seem to refer to the same 
  memory location

Right now the only easy thing to print for `x' and `y' is going to be
a pile of RTL; not useful to the average person.  We could save the
types used to create the alias sets (especially now that we have GC,
and therefore it's easy to keep them around); then it would be simple
to say 

  `double' and `int' have different types, but you seem to have memory
  that has both of these types at once

But, that's about as good as we could without some kind of major
infrastructure overhaul.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[craig]

>Let's get out of the mode of treating the user like an opponent.

I find it disturbing that you consider my thoughtful treatise
about how to ensure GCC is well-engineered as "treating the user
like an opponent".

Perhaps I shouldn't have chimed in at all.

        tq vm, (burley)

Re: type based aliasing again

[Joe Buck]

> >Let's get out of the mode of treating the user like an opponent.
> 
> I find it disturbing that you consider my thoughtful treatise
> about how to ensure GCC is well-engineered as "treating the user
> like an opponent".

I apologize if I caused any offense.

> Perhaps I shouldn't have chimed in at all.

On the contrary, please chime in.  Your contribution is valuable.

Re: type based aliasing again

[Joe Buck]

> >Let's get out of the mode of treating the user like an opponent.
> 
> I find it disturbing that you consider my thoughtful treatise
> about how to ensure GCC is well-engineered as "treating the user
> like an opponent".

I apologize if I caused any offense.

> Perhaps I shouldn't have chimed in at all.

On the contrary, please chime in.  Your contribution is valuable.

Re: type based aliasing again

[craig]

>Let's get out of the mode of treating the user like an opponent.

I find it disturbing that you consider my thoughtful treatise
about how to ensure GCC is well-engineered as "treating the user
like an opponent".

Perhaps I shouldn't have chimed in at all.

        tq vm, (burley)

Re: type based aliasing again

[Joe Buck]

Craig writes:
> I'm not *sure* about this, but it looks like this discussion is going
> in the direction of "we can do something not quite kosher by finding
> all cases of suspect code that won't actually be reached in practice".

That is not my intention.

> People who think GCC should have done what has been recommended here,
> i.e. revert to no alias analysis upon detecting possible violations
> (and warning about them), will probably use a script like the above
> to get the desired behavior themselves.

Let's get out of the mode of treating the user like an opponent.
We need to make clear that the fact that we issue warnings for some
type violations is not a guarantee that code not warned about is safe.

The perfect is often the enemy of the good.  By adding a warning, we
will get people to fix some more bugs.  The fact that the warning won't
catch all cases is just life.

Re: type based aliasing again

[craig]

>  In message < 19990908202957F.mitchell@codesourcery.com >you write:
>  > I agree that C is reasonable.  But, it is not technically viable at
>  > compile-time; the violation of the rule is a dynamic property.  For
>  > example, consider:
>  > 
>  >   if (0) {
>  >     /* Do illegal aliasing stuff.  */
>  >   }
>  > 
>  > If we do dead-code elimination late, we might ask questions about the
>  > aliasing in the conditional code.  Since that code never executes,
>  > ANSI says there's no violation.  Warning here is sensible, though,
>  > just as warning on `*((int*) 0) = 3' in the conditional code would be
>  > sensible.
>FYI, this kind of code could be deleted at a variety of stages in compilation
>depending on what optimization exposed the unreachable code (terminology
>note, this is unreachable code, not dead code ;-)
[...]

IMO, when you are considering stuff like this, please replace

  if (0)

with

  scanf ("%d", &i);  /* or whatever, i hate scanf anyway, think READ *, I. */
  if (i)

and the programmer's "out-of-band" promise that anytime that that particular
scanf executes, it will always read a 0 (from stdin).

I'm not *sure* about this, but it looks like this discussion is going
in the direction of "we can do something not quite kosher by finding
all cases of suspect code that won't actually be reached in practice".

If that's the case, it's wrong.

BTW, I agree 100% with this contribution from Mark:

>Saying "Don't violate ANSI/ISO aliasing rules, or else use
>-fno-strict-aliasing" is a simple, easy-to-follow rule.  I don't think
>we should muddy that with confusing semantics depending on GCC
>internals.

I also agree a warning where we *can* detect potential aliasing violations
would be nice.  Leave it to the usual "discovery process" to determine
whether it should be the default, the default for -Wall, whatever.

However, it's my impression that the mere printing, even requesting,
of a warning should make *no* difference in the generated code.  Just
like gcc promises for -g, except, here, I mean no difference in
the generated assembler output, not just the code within that.

In that case, it would be wrong to connect to the printing of a warning
(or the user requesting that type of warning) doing something like
turning off alias analysis.  GCC doesn't, upon warning about
a possible uninitialized variable, silently insert an initialization,
does it?  (By which I mean, we don't document that it does that, right?)

Note that falling back to the "let's just generate a warning" position
isn't a panacea:

  #!/bin/sh, or some approximation thereof

  # Compile $1 vis-a-vis gcc's annoying aliasing behavior and options in $2.
  gcc -Walias $2 -c $1 2>diagnostics.out
  status=$?
  if [ $status != 0 ]
  then
    exit $status
  fi

  # See if any alias warnings were issued, and recompile without alias
  # analysis if so.
  grep -q alias diagnostics.out
  if [ $? = 0 ]
  then
    gcc -fno-alias-analysis $2 -c $1
    status = $?
  fi
  rm diagnostics.out
  exit $status

People who think GCC should have done what has been recommended here,
i.e. revert to no alias analysis upon detecting possible violations
(and warning about them), will probably use a script like the above
to get the desired behavior themselves.

And, they will complain just as loudly when it "stops working", which
will mean, to them, either "no longer catches a particular aliasing
violation in my code, leading to hours of my time tracking down this
GCC bug causing a failure to correctly warn" or "now warns about something
that isn't really a problem, leading to hours of my time tracking
down this loss of performance".

(I'm not saying this sort of end-user behavior is to be expected for
all instances of generating warnings about not-strictly-correct code.
But given the huge amount of attention this problem, which has long
had the simple -fno-strict-aliasing workaround, has gotten on this
list during just this year, I think *this* particular warning is
a candidate for this sort of treatment.)

        tq vm, (burley)

Re: type based aliasing again

[Jeffrey A Law]

  In message < 19990908202957F.mitchell@codesourcery.com >you write:
  > I agree that C is reasonable.  But, it is not technically viable at
  > compile-time; the violation of the rule is a dynamic property.  For
  > example, consider:
  > 
  >   if (0) {
  >     /* Do illegal aliasing stuff.  */
  >   }
  > 
  > If we do dead-code elimination late, we might ask questions about the
  > aliasing in the conditional code.  Since that code never executes,
  > ANSI says there's no violation.  Warning here is sensible, though,
  > just as warning on `*((int*) 0) = 3' in the conditional code would be
  > sensible.
FYI, this kind of code could be deleted at a variety of stages in compilation
depending on what optimization exposed the unreachable code (terminology
note, this is unreachable code, not dead code ;-)

For example, "if (0)" at the source level would probably be zapped by the
first jump pass.  I do not believe we do any aliasing checks before jump1.

cse can expose code like this, and we do aliasing queries in cse.  When
CSE exposes this code it is eliminated immediately after cse by a jump pass.

gcse can also expose code like this.  The current snapshots do not have any
aliasing tied into gcse.  However, basic global load motion is done and will
be donated as soon as I can find some time.  At that point gcse will be doing
alias queries.  Also note global store motion is also in the pipeline.
If gcse exposes any code like this it will be deleted by a jump pass after
gcse.

etc etc etc.


  > A technical problem is giving an intelligent warning; we no longer
  > know the types of the variables involved, by the time we could warn.
  > We are in RTL-land at that point.  But, even 
Right, no types.  Getting line numbers may not be particularly easy either
depending on the pass.

The current way I've handling aliasing issues in gcse would make it
straight forward to get the line number for the two memory references.
[ Remember, we're comparing two values, which could come from different
  lines. ]

jeff

Re: type based aliasing again

[Richard Stallman]

	Joe> A).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume aliasing.

	Joe> B).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume no aliasing. (That is, produce bad
	Joe> code).

	Joe> C).  If we detect a rule violation, issue an error and don't
	Joe> go on.

	Joe> I think that only A) and C) are reasonable.  B) is not.  I
	Joe> would prefer A).

Mark wrote:

    There will be cases where A will pessimize code that does not have
    undefined behavior.  So, in fact, C is impossible, and A penalizes
    conforming code.  Thus, B is the only remaining sensible option.

This reasoning is based on an assumption about priorities: that
efficiency is far far more important than not breaking users' code.

Those priorities are not well chosen.  Efficiency is important because
it makes users happy.  Not breaking users' code is important because
it makes users happy.

In general, they are both important.  But they are not (in general)
equally important in how they affect any specific issue.  To decide
each issue, we have to look at how MUCH efficiency is to be gained and
in which cases, how MANY (and which, and how important) cases will
break, and so on.  That way we can estimate how each alternative will
affect the users.

In this specific issue, we can unbreak many programs, with almost no
penalty in efficiency.  In this specific issue, unbreaking the
programs wins.  In another issue, it might be the other way around.

Re: type based aliasing again

[Richard Stallman]

	Joe> A).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume aliasing.

	Joe> B).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume no aliasing. (That is, produce bad
	Joe> code).

	Joe> C).  If we detect a rule violation, issue an error and don't
	Joe> go on.

	Joe> I think that only A) and C) are reasonable.  B) is not.  I
	Joe> would prefer A).

Mark wrote:

    There will be cases where A will pessimize code that does not have
    undefined behavior.  So, in fact, C is impossible, and A penalizes
    conforming code.  Thus, B is the only remaining sensible option.

This reasoning is based on an assumption about priorities: that
efficiency is far far more important than not breaking users' code.

Those priorities are not well chosen.  Efficiency is important because
it makes users happy.  Not breaking users' code is important because
it makes users happy.

In general, they are both important.  But they are not (in general)
equally important in how they affect any specific issue.  To decide
each issue, we have to look at how MUCH efficiency is to be gained and
in which cases, how MANY (and which, and how important) cases will
break, and so on.  That way we can estimate how each alternative will
affect the users.

In this specific issue, we can unbreak many programs, with almost no
penalty in efficiency.  In this specific issue, unbreaking the
programs wins.  In another issue, it might be the other way around.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> A).  If we detect a rule violation, issue a warning and tell
    Joe> the compiler to assume aliasing.

    Joe> B).  If we detect a rule violation, issue a warning and tell
    Joe> the compiler to assume no aliasing. (That is, produce bad
    Joe> code).

    Joe> C).  If we detect a rule violation, issue an error and don't
    Joe> go on.

    Joe> I think that only A) and C) are reasonable.  B) is not.  I
    Joe> would prefer A).

I agree that C is reasonable.  But, it is not technically viable at
compile-time; the violation of the rule is a dynamic property.  For
example, consider:

  if (0) {
    /* Do illegal aliasing stuff.  */
  }

If we do dead-code elimination late, we might ask questions about the
aliasing in the conditional code.  Since that code never executes,
ANSI says there's no violation.  Warning here is sensible, though,
just as warning on `*((int*) 0) = 3' in the conditional code would be
sensible.

There will be cases where A will pessimize code that does not have
undefined behavior.  So, in fact, C is impossible, and A penalizes
conforming code.  Thus, B is the only remaining sensible option.

A technical problem is giving an intelligent warning; we no longer
know the types of the variables involved, by the time we could warn.
We are in RTL-land at that point.  But, even 

  warning: type-based alias analysis suggests your code is nonconforming
           (use -fno-strict-aliasing to disable type-based alias analysis)

might be better than nothing, especially if we could give a
line-number.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

Sorry, I responded to Mark's message too quickly and didn't grasp
a key point.

> However, I do think this might be a good way to get useful warnings.
> So, I would amend your proposal to "issue a warning and then tell the
> compiler that there is no aliasing."

Sigh.  If we can tell the user's intent, we should try to do the right thing.
If we're going to deliberately do the wrong thing, it would be best
to just issue a hard error.  The compiler shouldn't go on to do something
that we know has a good chance of generating bogus code.

So we have three variants.

A).  If we detect a rule violation, issue a warning and tell the compiler
     to assume aliasing.

B).  If we detect a rule violation, issue a warning and tell the compiler
     to assume no aliasing. (That is, produce bad code).

C).  If we detect a rule violation, issue an error and don't go on.

I think that only A) and C) are reasonable.  B) is not.  I would prefer
A).

Re: type based aliasing again

[Richard Stallman]

    However, I have a rather serious objection: it means that users cannot
    tell whether their code is valid, even according to the GCC rules,
    without knowing the internals of the compiler.

This has always been true.  It is true in the current version of GCC
with regard to aliasing, even when -fstrict-aliasing is used.  It is
part of the nature of C.

The goal of trying to avoid it is unrealistic and misguided; it can't
be done.  So this cannot be a valid reason to reject a change.

    The compiler should continue to aggressively break code that
    misbehaves in this way.

This proposes to break users' code, just to bully them into changing
it.  That is a callous and harsh attitude towards the users of GCC.
No wonder users are angry.  They know that the problems are not due to
necessity, but due to callous disregard for them.

We cannot do everything all users want, and sometimes a maintainer has
to say no to users.  "You cannot please everyone," as the saying goes.
There are many kinds of reasons which can sometimes be good reasons to
say no.

But maintainers should always say no reluctantly--never eagerly.  We
should never aggressively cause trouble for users today, just because
someday it might be necessary.  That is like amputating limbs because
someday they might be crushed.

This treatment of users brings shame on the GNU Project.  I ask
everyone therefore not to suggest that we should treat users this way.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> The goal of trying to avoid it is unrealistic and
    Richard> misguided; it can't be done.  So this cannot be a valid
    Richard> reason to reject a change.

You are right that it cannot be done.  However, it is good to strive
for things which are good, even if they are impossible to achieve.
(For example, we strive to make GCC a bug-free compiler, even though
that will never happen.)

You've chosen to respond to a long conversation all at once.  Let me
try to sum up the current state, as I see it:

  o We all agree that if it is technically feasible to warn about
    invalid code, we should.  It will be difficult to produce
    a useful warning, but, if someone can figure out how, I don't
    think there's any debate that this is worthwhile.  Even if
    there are some false positives.

  o Code which will "work" with the proposed change may (will) 
    break with future releases of GCC.  This will lead to worse
    headaches for users than the simple rule: don't treat memory
    as having multiple types, or else use -fno-strict-aliasing.
    Users will be particularly at risk because when the behavior
    gets worse (from their point of view) warnings will go away,
    not appear.

    Mark> The compiler should continue to aggressively break
    Mark> code that misbehaves in this way.

    Richard> This proposes to break users' code, just to bully them
    Richard> into changing it.  That is a callous and harsh attitude
    Richard> towards the users of GCC.  No wonder users are angry.
    Richard> They know that the problems are not due to necessity, but
    Richard> due to callous disregard for them.

That is a harsh statement, which I take personally.  I have
volunteered a lot of time and effort responding directly to users
needs and wishes.  You should not read intent into statements, without
asking the speaker to clarify first.  Please treat me with the same
respect I have shown Joe Buck and others who have raised this issue,
including those who have called me nasty names in the past.

There is no way that we can guarantee the long-term viability of this
variety of invalid code.  Seemingly minor changes to the compiler will
change the set of programs which "work", with your proposal.  Other
compilers are already doing these optimizations.  Thus, portable code,
including most GNU project code, simply must not contain these invalid
constructs.  I firmly belive that it is better for users to have a
simple, easy to follow guideline, than a shifting, confusing one.
Perhaps that is where you and I differ, but it does not imply that
either of us have disregard for users.

I have spent a good deal of time considering not only this proposal,
but many others that have appeared on this list.  Thus, I have
*reluctantly* concluded that there is no graceful failure mode.  Of
course, I am willing to be persuaded.

There is a lot of code out there that assumes bitfields are unsigned.
That's not always true; such code breaks in those situations.  Users
must know, when compiling such code, that they must specify
-funsigned-bitfields.  This situation is similar: users must know that
they must specify -fno-strict-aliasing when compiling these programs.

If we can figure out how to do the warning, we should; that's more
than we can offer in many other similar cases (like in the bitfield
case).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

Mark Mitchell writes:

> There is no way that we can guarantee the long-term viability of this
> variety of invalid code.  Seemingly minor changes to the compiler will
> change the set of programs which "work", with your proposal.  

My intent, which may be different from RMS's intent, is to help users
get rid of this variety of invalid code, not to perpetuate it.
I prefer what we called proposal A to proposal B because I think we
should do what the user means if we can tell, but we definitely
should let the user know that they are doing something very risky.

> Other
> compilers are already doing these optimizations.  Thus, portable code,
> including most GNU project code, simply must not contain these invalid
> constructs.

Agreed.  If not, within two years, I predict that it won't be possible to
build GNU tools with compilers other than gcc.  The Merced architecture in
particular will require very aggressive compilation techniques, with loads
of reordering of operations, to take full advantage of it.

Re: type based aliasing again

[Richard Stallman]

    > Other
    > compilers are already doing these optimizations.  Thus, portable code,
    > including most GNU project code, simply must not contain these invalid
    > constructs.

People who want to support other compilers might want to remove these
constructs, for this reason.  But not everyone cares about compilation
with other compilers.  Is Linux ever compiled with anything other than GCC?

And then there are all the existing programs which don't have
maintainers...

Re: type based aliasing again

[Richard Stallman]

    > Other
    > compilers are already doing these optimizations.  Thus, portable code,
    > including most GNU project code, simply must not contain these invalid
    > constructs.

People who want to support other compilers might want to remove these
constructs, for this reason.  But not everyone cares about compilation
with other compilers.  Is Linux ever compiled with anything other than GCC?

And then there are all the existing programs which don't have
maintainers...

Re: type based aliasing again

[Joe Buck]

Mark Mitchell writes:

> There is no way that we can guarantee the long-term viability of this
> variety of invalid code.  Seemingly minor changes to the compiler will
> change the set of programs which "work", with your proposal.  

My intent, which may be different from RMS's intent, is to help users
get rid of this variety of invalid code, not to perpetuate it.
I prefer what we called proposal A to proposal B because I think we
should do what the user means if we can tell, but we definitely
should let the user know that they are doing something very risky.

> Other
> compilers are already doing these optimizations.  Thus, portable code,
> including most GNU project code, simply must not contain these invalid
> constructs.

Agreed.  If not, within two years, I predict that it won't be possible to
build GNU tools with compilers other than gcc.  The Merced architecture in
particular will require very aggressive compilation techniques, with loads
of reordering of operations, to take full advantage of it.

Re: type based aliasing again

[Richard Stallman]

I am sorry that you took it personally, because I did not mean it that
way.  So please accept my apology for hurting your feelings.  I'm not
angry at you personally, and the issue is not a personal one.

Theb issue is the pattern of assumptions that several GCC developers
have cited as the basis for their views on this question.  It is a
pattern of assumptions that treats real problems for real users 
as secondary to abstract criteria of purity.

Re: type based aliasing again

[Richard Stallman]

I am sorry that you took it personally, because I did not mean it that
way.  So please accept my apology for hurting your feelings.  I'm not
angry at you personally, and the issue is not a personal one.

Theb issue is the pattern of assumptions that several GCC developers
have cited as the basis for their views on this question.  It is a
pattern of assumptions that treats real problems for real users 
as secondary to abstract criteria of purity.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard> The goal of trying to avoid it is unrealistic and
    Richard> misguided; it can't be done.  So this cannot be a valid
    Richard> reason to reject a change.

You are right that it cannot be done.  However, it is good to strive
for things which are good, even if they are impossible to achieve.
(For example, we strive to make GCC a bug-free compiler, even though
that will never happen.)

You've chosen to respond to a long conversation all at once.  Let me
try to sum up the current state, as I see it:

  o We all agree that if it is technically feasible to warn about
    invalid code, we should.  It will be difficult to produce
    a useful warning, but, if someone can figure out how, I don't
    think there's any debate that this is worthwhile.  Even if
    there are some false positives.

  o Code which will "work" with the proposed change may (will) 
    break with future releases of GCC.  This will lead to worse
    headaches for users than the simple rule: don't treat memory
    as having multiple types, or else use -fno-strict-aliasing.
    Users will be particularly at risk because when the behavior
    gets worse (from their point of view) warnings will go away,
    not appear.

    Mark> The compiler should continue to aggressively break
    Mark> code that misbehaves in this way.

    Richard> This proposes to break users' code, just to bully them
    Richard> into changing it.  That is a callous and harsh attitude
    Richard> towards the users of GCC.  No wonder users are angry.
    Richard> They know that the problems are not due to necessity, but
    Richard> due to callous disregard for them.

That is a harsh statement, which I take personally.  I have
volunteered a lot of time and effort responding directly to users
needs and wishes.  You should not read intent into statements, without
asking the speaker to clarify first.  Please treat me with the same
respect I have shown Joe Buck and others who have raised this issue,
including those who have called me nasty names in the past.

There is no way that we can guarantee the long-term viability of this
variety of invalid code.  Seemingly minor changes to the compiler will
change the set of programs which "work", with your proposal.  Other
compilers are already doing these optimizations.  Thus, portable code,
including most GNU project code, simply must not contain these invalid
constructs.  I firmly belive that it is better for users to have a
simple, easy to follow guideline, than a shifting, confusing one.
Perhaps that is where you and I differ, but it does not imply that
either of us have disregard for users.

I have spent a good deal of time considering not only this proposal,
but many others that have appeared on this list.  Thus, I have
*reluctantly* concluded that there is no graceful failure mode.  Of
course, I am willing to be persuaded.

There is a lot of code out there that assumes bitfields are unsigned.
That's not always true; such code breaks in those situations.  Users
must know, when compiling such code, that they must specify
-funsigned-bitfields.  This situation is similar: users must know that
they must specify -fno-strict-aliasing when compiling these programs.

If we can figure out how to do the warning, we should; that's more
than we can offer in many other similar cases (like in the bitfield
case).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Marc Lehmann]

On Fri, Sep 10, 1999 at 02:34:28AM -0400, Richard Stallman <rms@gnu.org> wrote:
>     The compiler should continue to aggressively break code that
>     misbehaves in this way.
> 
> This proposes to break users' code, just to bully them into changing
> it.  That is a callous and harsh attitude towards the users of GCC.
> No wonder users are angry.  They know that the problems are not due to
> necessity, but due to callous disregard for them.

This is a view of the problem that isn't really correct. Gcc is generally
trying to be helpful for users to write portable code (portable even among
gcc versions).

Agressively breaking code actually helps. It's like compiling abort() into a
program where it stumbles into undefined behaviour - it helps the user to
catch the error as early as possible.

Trying to preserve invalid code just because the compiler can do it in most
cases will result in a much larger disaster for future revisions, when the
compiler might just optimize the program away for _valid_ reasons.

If gcc had broken that program early on (because is was invalid) the error
would have been fixed earlier. "Aggressively breaking code" just means
"try to behave as close as possible to future versions".

Viable solutions for aliasing problems are:

- try to spit out warnings, wherever possible. Do not try to salvage invalid
  programs, though.
- for old code use the corresponding compiler flag.

> This treatment of users brings shame on the GNU Project.

To the contrary, it will help the users to write better programs that have a
lower chance to break in the future. If they don't want to they can switch of
aliasing assumptions in the compiler.

What's needed is documentation (e.g. the FAQ entry for that).

On Fri, Sep 10, 1999 at 02:34:30AM -0400, Richard Stallman <rms@gnu.org> wrote:
> I am not proposing this as a feature, just as a way to avoid evitable
> trouble for users.  We should not even try to document a class of
> cases that are "supposed" to work, because I'm not saying these
> are "supposed" to work.  We should just let them work.

In other words: "hey, people, this happens to work, but it will most
certainly not work with any other compiler, nor with future releases of
gcc. It's also impossible to tell you what may break or what may survive at
the moment."

Trying to spit out warnings is the way to go. Trying to salvage programs
that will definitely break at some later date is not useful. We could
just as well say "well, you can always store and calulcate years with two
digits only, but be advised that might not work for some cases".

> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

However, the ISO C *defines* what is C. Not more and not less.

We can opt to *implement* our own version of C, and we can even call it
"C" (as we did), but failing to *define* its semantics is not going to
help anybody.

A language with unclear semantics (or semantics that will change with
compiler revisions) is not of practical use, IMHO.

All this, however, does not say we should try to aggressively warn people
about their code.

> C programs use many cases that are not conforming, but do work.

Now, and on this platform. If gcc would only available for, say, x86, we
could go on with that. But I conjecture that many of these "invalid but
works" programs will deifnitely break with gcc on some current or future
architecture.

IA64 was mentioned, for example. There it is of paramount importance to
aggressively optimize - otherwise performance will be unusable. So this
might mean, in the not-so-far-future "your programs works fine, except on
Merced or the E2k".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Fri, Sep 10, 1999 at 02:34:28AM -0400, Richard Stallman <rms@gnu.org> wrote:
>     The compiler should continue to aggressively break code that
>     misbehaves in this way.
> 
> This proposes to break users' code, just to bully them into changing
> it.  That is a callous and harsh attitude towards the users of GCC.
> No wonder users are angry.  They know that the problems are not due to
> necessity, but due to callous disregard for them.

This is a view of the problem that isn't really correct. Gcc is generally
trying to be helpful for users to write portable code (portable even among
gcc versions).

Agressively breaking code actually helps. It's like compiling abort() into a
program where it stumbles into undefined behaviour - it helps the user to
catch the error as early as possible.

Trying to preserve invalid code just because the compiler can do it in most
cases will result in a much larger disaster for future revisions, when the
compiler might just optimize the program away for _valid_ reasons.

If gcc had broken that program early on (because is was invalid) the error
would have been fixed earlier. "Aggressively breaking code" just means
"try to behave as close as possible to future versions".

Viable solutions for aliasing problems are:

- try to spit out warnings, wherever possible. Do not try to salvage invalid
  programs, though.
- for old code use the corresponding compiler flag.

> This treatment of users brings shame on the GNU Project.

To the contrary, it will help the users to write better programs that have a
lower chance to break in the future. If they don't want to they can switch of
aliasing assumptions in the compiler.

What's needed is documentation (e.g. the FAQ entry for that).

On Fri, Sep 10, 1999 at 02:34:30AM -0400, Richard Stallman <rms@gnu.org> wrote:
> I am not proposing this as a feature, just as a way to avoid evitable
> trouble for users.  We should not even try to document a class of
> cases that are "supposed" to work, because I'm not saying these
> are "supposed" to work.  We should just let them work.

In other words: "hey, people, this happens to work, but it will most
certainly not work with any other compiler, nor with future releases of
gcc. It's also impossible to tell you what may break or what may survive at
the moment."

Trying to spit out warnings is the way to go. Trying to salvage programs
that will definitely break at some later date is not useful. We could
just as well say "well, you can always store and calulcate years with two
digits only, but be advised that might not work for some cases".

> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

However, the ISO C *defines* what is C. Not more and not less.

We can opt to *implement* our own version of C, and we can even call it
"C" (as we did), but failing to *define* its semantics is not going to
help anybody.

A language with unclear semantics (or semantics that will change with
compiler revisions) is not of practical use, IMHO.

All this, however, does not say we should try to aggressively warn people
about their code.

> C programs use many cases that are not conforming, but do work.

Now, and on this platform. If gcc would only available for, say, x86, we
could go on with that. But I conjecture that many of these "invalid but
works" programs will deifnitely break with gcc on some current or future
architecture.

IA64 was mentioned, for example. There it is of paramount importance to
aggressively optimize - otherwise performance will be unusable. So this
might mean, in the not-so-far-future "your programs works fine, except on
Merced or the E2k".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909100634.CAA01812@psilocin.gnu.org >you write:
  >     However, I have a rather serious objection: it means that users cannot
  >     tell whether their code is valid, even according to the GCC rules,
  >     without knowing the internals of the compiler.
  > 
  > This has always been true.  It is true in the current version of GCC
  > with regard to aliasing, even when -fstrict-aliasing is used.  It is
  > part of the nature of C.
  > 
  > The goal of trying to avoid it is unrealistic and misguided; it can't
  > be done.  So this cannot be a valid reason to reject a change.
Agreed.  However, unlike many other decisions we make in the compiler this
change is explicitly detecting invalid code and working around it.

Like it or not, people will come to depend on this feature, especially if we
do not thoroughly document it, which in turn will lead to more complaints later
if GCC fails to work around some broken code that it fixed before.

Thus, I think it is an absolute requirement that we document this behavior.
Anything else is just asking for more problems in the long run.


jeff

Re: type based aliasing again

[Nick Ing-Simmons]

Jeffrey A Law <law@cygnus.com> writes:
>
>Like it or not, people will come to depend on this feature, 

They could be discoraged:

  warning("*** >>> DUBIUOS FEATURE USED <<< ***");
  sleep(15); 

;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Nick Ing-Simmons]

Jeffrey A Law <law@cygnus.com> writes:
>
>Like it or not, people will come to depend on this feature, 

They could be discoraged:

  warning("*** >>> DUBIUOS FEATURE USED <<< ***");
  sleep(15); 

;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Richard Stallman]

    Like it or not, people will come to depend on this feature, 

My proposal is not a feature.  When you call it a "feature", you're
not considering the proposal I made.

The argument about "people depending on this" is flawed
in the idea that such dependency would be due to my proposal.
It has already happened, and it is still happening.

People already depend on the invalid code we are talking about.  It
exists in various programs today.

People may also be writing more such code even today.  With GCC 2.95,
such code will always work as expected if -O0 is used, and that may
even be true if -O1 is used.

In GCC 2.95, when -fstrict-aliasing is used, some of these cases work
as expected, and some will not.  With my proposal, that would still be
the overall situation.  The only difference would be that a larger
fraction of them would work as expected.

This difference would reduce the pain caused today, but as regards the
potential problems you are worried about, it would not change things
much.

Re: type based aliasing again

[Richard Stallman]

    Like it or not, people will come to depend on this feature, 

My proposal is not a feature.  When you call it a "feature", you're
not considering the proposal I made.

The argument about "people depending on this" is flawed
in the idea that such dependency would be due to my proposal.
It has already happened, and it is still happening.

People already depend on the invalid code we are talking about.  It
exists in various programs today.

People may also be writing more such code even today.  With GCC 2.95,
such code will always work as expected if -O0 is used, and that may
even be true if -O1 is used.

In GCC 2.95, when -fstrict-aliasing is used, some of these cases work
as expected, and some will not.  With my proposal, that would still be
the overall situation.  The only difference would be that a larger
fraction of them would work as expected.

This difference would reduce the pain caused today, but as regards the
potential problems you are worried about, it would not change things
much.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909100634.CAA01812@psilocin.gnu.org >you write:
  >     However, I have a rather serious objection: it means that users cannot
  >     tell whether their code is valid, even according to the GCC rules,
  >     without knowing the internals of the compiler.
  > 
  > This has always been true.  It is true in the current version of GCC
  > with regard to aliasing, even when -fstrict-aliasing is used.  It is
  > part of the nature of C.
  > 
  > The goal of trying to avoid it is unrealistic and misguided; it can't
  > be done.  So this cannot be a valid reason to reject a change.
Agreed.  However, unlike many other decisions we make in the compiler this
change is explicitly detecting invalid code and working around it.

Like it or not, people will come to depend on this feature, especially if we
do not thoroughly document it, which in turn will lead to more complaints later
if GCC fails to work around some broken code that it fixed before.

Thus, I think it is an absolute requirement that we document this behavior.
Anything else is just asking for more problems in the long run.


jeff

Re: type based aliasing again

[Richard Stallman]

    However, I have a rather serious objection: it means that users cannot
    tell whether their code is valid, even according to the GCC rules,
    without knowing the internals of the compiler.

This has always been true.  It is true in the current version of GCC
with regard to aliasing, even when -fstrict-aliasing is used.  It is
part of the nature of C.

The goal of trying to avoid it is unrealistic and misguided; it can't
be done.  So this cannot be a valid reason to reject a change.

    The compiler should continue to aggressively break code that
    misbehaves in this way.

This proposes to break users' code, just to bully them into changing
it.  That is a callous and harsh attitude towards the users of GCC.
No wonder users are angry.  They know that the problems are not due to
necessity, but due to callous disregard for them.

We cannot do everything all users want, and sometimes a maintainer has
to say no to users.  "You cannot please everyone," as the saying goes.
There are many kinds of reasons which can sometimes be good reasons to
say no.

But maintainers should always say no reluctantly--never eagerly.  We
should never aggressively cause trouble for users today, just because
someday it might be necessary.  That is like amputating limbs because
someday they might be crushed.

This treatment of users brings shame on the GNU Project.  I ask
everyone therefore not to suggest that we should treat users this way.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    Joe> The change is simply to postpone the type-based check until
    Joe> after the other analysis is done.  If we detect that the
    Joe> references collide, but the types say that we can assume they
    Joe> don't, we issue a warning and then tell the compiler that
    Joe> there is aliasing.  (A variant is to silently accept the
    Joe> code, but I would prefer issuing a warning).  If we fall into
    Joe> the "maybe" case, we assume no aliasing if the types don't
    Joe> match.

I'd thought vaguely about this alternative in the past.  It is indeed
technically feasible.

However, I have a rather serious objection: it means that users cannot
tell whether their code is valid, even according to the GCC rules,
without knowing the internals of the compiler.  (It's dependent on
what the compiler can figure out about two addresses aliasing.  If the
compiler gets dumber, code breaks.  The compiler shouldn't get dumber,
in general, but it might in certain situations, while getting smarter
in others.  For example, if we replace some optimization algorithm
with another, we might do better in the average case, but worse in
some particular case.  Things that we used to know aliased we're now
not sure about.  Programs break.)

However, I do think this might be a good way to get useful warnings.
So, I would amend your proposal to "issue a warning and then tell the
compiler that there is no aliasing."  This would make it easier for
users to tell that there is a problem, which would indeed be a major
benefit.

The compiler should continue to aggressively break code that
misbehaves in this way.  Because we cannot (for technical reasons)
guarantee behavior in the future, we should break programs now; that
will make for fewer surprises down the road.

Coding like this is really no different than, say, assuming that you
call a varargs function without a prototype in sight.  It used to work
on most systems, and it still works on some.  But, it's not portable,
and people shouldn't do it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joe Buck]

I made an oops:

> As of gcc 2.95, optimizations that take advantage of this rule are turned
> on by default.  The problem is that there is a good deal of
> technically-invalid code out there (that, for example, reads and writes
> long data as pairs of shorts, without using unions).  gcc 2.95 may
> malfunction on such code unless the flag -fno-strict-aliasing is provided.

As has been pointed out to me, "malfunction" implies a compiler bug,
while the bug is in the invalid code.  I hope that this didn't cause
any confusion; I know of no bugs in the type-based aliasing code.

Re: type based aliasing again

[Joe Buck]

I made an oops:

> As of gcc 2.95, optimizations that take advantage of this rule are turned
> on by default.  The problem is that there is a good deal of
> technically-invalid code out there (that, for example, reads and writes
> long data as pairs of shorts, without using unions).  gcc 2.95 may
> malfunction on such code unless the flag -fno-strict-aliasing is provided.

As has been pointed out to me, "malfunction" implies a compiler bug,
while the bug is in the invalid code.  I hope that this didn't cause
any confusion; I know of no bugs in the type-based aliasing code.

Re: type based aliasing again

[Alexandre Oliva]

On Sep  8, 1999, Joe Buck <jbuck@synopsys.COM> wrote:

> The question that has been asked by a number of people is whether we
> can make some of the more "obvious" cases work correctly

I don't think we can draw a line that separates the ``obvious'' cases
from the non-obvious ones.

> The change is simply to postpone the type-based check until after the
> other analysis is done.  If we detect that the references collide, but
> the types say that we can assume they don't, we issue a warning and
> then tell the compiler that there is aliasing.

I don't think this can detect cases in which pointers are passed into
functions.  But I haven't thought very thoroughly about it.

Methinks it would be much easier to just issue a warning whenever we
find a type cast to a type that couldn't alias the original type.  Of
course one may cheat and introduce an intermediate cast to void* or
char*, to silence the compiler (would this remove the aliasing problem
too?), but the right fix would be to cast to the appropriate union
type.  This warning would catch most (all?) cases of dangerous type
cases, and require the user to take action to work around them, and it
would take place early enough in the compiler that we could issue good
warning messages.


BTW, it seems to me that this `cast to union' is something particular
to gcc, not a general solution, right?  I mean, other compilers might
not pay as much attention to the unions as gcc does, since accessing
any type other than the one that was actually stored in the union is
undefined behavior anyway.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: type based aliasing again

[Bernd Schmidt]

> BTW, it seems to me that this `cast to union' is something particular
> to gcc, not a general solution, right?  I mean, other compilers might
> not pay as much attention to the unions as gcc does, since accessing
> any type other than the one that was actually stored in the union is
> undefined behavior anyway.

If, by "cast to union", you mean code of the form

   union foo
   {
      double a;
      int b[2];
   };
   double x;
   x = 2.0;
   ((union foo *)&x)->b[1] = 0;

then this is not even going to work with gcc, regardless of whether
-fstrict-aliasing is on or not.  We found code like this in some math
library code here at Cygnus a few weeks ago.  The problem is that gcc's
MEM_IN_STRUCT/MEM_SCALAR_P alias analysis will catch cases like this and
determine that the integer memory access can't alias the variable x.
The code should be written

   union foo
   {
      double a;
      int b[2];
   };
   union foo x;
   x.a = 2.0;
   x.b[1] = 0;

The guarantee that this will work is a gcc extension.

Bernd

Re: type based aliasing again

[Alexandre Oliva]

On Sep 14, 1999, Bernd Schmidt <bernds@cygnus.co.uk> wrote:

> If, by "cast to union", you mean code of the form

>    union foo { double a; int b[2]; };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;

> then this is not even going to work with gcc

But isn't exactly this work-around that we've have been recommending
to the Linux folks?  Houston, we have a problem! :-) / 2

How about:

     double x;
     ((union foo *)&x)->a = 2.0;
     ((union foo *)&x)->b[1] = 0;

Would this work?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: type based aliasing again

[Bernd Schmidt]

> 
> But isn't exactly this work-around that we've have been recommending
> to the Linux folks?  Houston, we have a problem! :-) / 2
> 
> How about:
> 
>      double x;
>      ((union foo *)&x)->a = 2.0;
>      ((union foo *)&x)->b[1] = 0;
> 
> Would this work?

It might just.  (Note I'm being cautious ;-)
The accesses are all through a union, so it's covered by our extension
(quickly "verified" by compiling and checking all the alias sets are zero in
the rtl dump), and since x isn't accessed in its own type, it shouldn't
trigger the MEM_IN_STRUCT/MEM_SCALAR_P tests either.  Still, declaring x as a
union is probably safer.

Bernd

Re: type based aliasing again

[Bernd Schmidt]

> 
> But isn't exactly this work-around that we've have been recommending
> to the Linux folks?  Houston, we have a problem! :-) / 2
> 
> How about:
> 
>      double x;
>      ((union foo *)&x)->a = 2.0;
>      ((union foo *)&x)->b[1] = 0;
> 
> Would this work?

It might just.  (Note I'm being cautious ;-)
The accesses are all through a union, so it's covered by our extension
(quickly "verified" by compiling and checking all the alias sets are zero in
the rtl dump), and since x isn't accessed in its own type, it shouldn't
trigger the MEM_IN_STRUCT/MEM_SCALAR_P tests either.  Still, declaring x as a
union is probably safer.

Bernd

Re: type based aliasing again

[Rask Ingemann Lambertsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Den 14-Sep-99 13:44:38 skrev Alexandre Oliva følgende om "Re: type based aliasing again":
> On Sep 14, 1999, Bernd Schmidt <bernds@cygnus.co.uk> wrote:

>> If, by "cast to union", you mean code of the form

>>    union foo { double a; int b[2]; };
>>    double x;
>>    x = 2.0;
>>    ((union foo *)&x)->b[1] = 0;

>> then this is not even going to work with gcc

> But isn't exactly this work-around that we've have been recommending
> to the Linux folks?  Houston, we have a problem! :-) / 2

   The recommendation in the GCC manual, if that is anything to go by, is
not to "cast to union" but to use a union. I.e. something like

    union foo { double a; int b[2]; };
    foo.a = 2.0;
    foo.b[1] = 0;

   This is documented to work, actually works, is shorter, is not
write-only, etc.

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen       | E-mail: mailto:rask@kampsax.k-net.dk  |
| Registered Phase5 developer    | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 866 kkeys/s (RC5-64)    | "ThrustMe" on XPilot, ARCnet and IRC  |
| If a train station is where a train stops, what is a workstation then? |

Re: type based aliasing again

[Jamie Lokier]

Rask Ingemann Lambertsen wrote:
>    The recommendation in the GCC manual, if that is anything to go by, is
> not to "cast to union" but to use a union. I.e. something like
> 
>     union foo { double a; int b[2]; };
>     foo.a = 2.0;
>     foo.b[1] = 0;
> 
>    This is documented to work, actually works, is shorter, is not
> write-only, etc.

The problem is that you have to change all the code which uses a `foo',
when you decide you want a particular piece of code to access it as an
`int'.  That means changing all the type declarations (previously might
have been `double'), and every place where the type is accessed.

That is often unworkable.

With some variation on anonymous unions, it might be workable.
Is that worth pursuing?

-- Jamie

Re: type based aliasing again

[Jamie Lokier]

Rask Ingemann Lambertsen wrote:
>    The recommendation in the GCC manual, if that is anything to go by, is
> not to "cast to union" but to use a union. I.e. something like
> 
>     union foo { double a; int b[2]; };
>     foo.a = 2.0;
>     foo.b[1] = 0;
> 
>    This is documented to work, actually works, is shorter, is not
> write-only, etc.

The problem is that you have to change all the code which uses a `foo',
when you decide you want a particular piece of code to access it as an
`int'.  That means changing all the type declarations (previously might
have been `double'), and every place where the type is accessed.

That is often unworkable.

With some variation on anonymous unions, it might be workable.
Is that worth pursuing?

-- Jamie

Re: type based aliasing again

[Rask Ingemann Lambertsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Den 14-Sep-99 13:44:38 skrev Alexandre Oliva følgende om "Re: type based aliasing again":
> On Sep 14, 1999, Bernd Schmidt <bernds@cygnus.co.uk> wrote:

>> If, by "cast to union", you mean code of the form

>>    union foo { double a; int b[2]; };
>>    double x;
>>    x = 2.0;
>>    ((union foo *)&x)->b[1] = 0;

>> then this is not even going to work with gcc

> But isn't exactly this work-around that we've have been recommending
> to the Linux folks?  Houston, we have a problem! :-) / 2

   The recommendation in the GCC manual, if that is anything to go by, is
not to "cast to union" but to use a union. I.e. something like

    union foo { double a; int b[2]; };
    foo.a = 2.0;
    foo.b[1] = 0;

   This is documented to work, actually works, is shorter, is not
write-only, etc.

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen       | E-mail: mailto:rask@kampsax.k-net.dk  |
| Registered Phase5 developer    | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 866 kkeys/s (RC5-64)    | "ThrustMe" on XPilot, ARCnet and IRC  |
| If a train station is where a train stops, what is a workstation then? |

Re: type based aliasing again

[Alexandre Oliva]

On Sep 14, 1999, Bernd Schmidt <bernds@cygnus.co.uk> wrote:

> If, by "cast to union", you mean code of the form

>    union foo { double a; int b[2]; };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;

> then this is not even going to work with gcc

But isn't exactly this work-around that we've have been recommending
to the Linux folks?  Houston, we have a problem! :-) / 2

How about:

     double x;
     ((union foo *)&x)->a = 2.0;
     ((union foo *)&x)->b[1] = 0;

Would this work?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: type based aliasing again

[Andi Kleen]

bernds@cygnus.co.uk (Bernd Schmidt) writes:

> > BTW, it seems to me that this `cast to union' is something particular
> > to gcc, not a general solution, right?  I mean, other compilers might
> > not pay as much attention to the unions as gcc does, since accessing
> > any type other than the one that was actually stored in the union is
> > undefined behavior anyway.
> 
> If, by "cast to union", you mean code of the form
> 
>    union foo
>    {
>       double a;
>       int b[2];
>    };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;
> 
> then this is not even going to work with gcc, regardless of whether
> -fstrict-aliasing is on or not.  We found code like this in some math
> library code here at Cygnus a few weeks ago.  The problem is that gcc's
> MEM_IN_STRUCT/MEM_SCALAR_P alias analysis will catch cases like this and
> determine that the integer memory access can't alias the variable x.

Sigh. I fixed the TCP code in the Linux kernel to (mostly) do that. It
is also compiled with -fno-strict-aliasing. If I understood you and
Jonathan right it may be misoptimized even in with that option, because it 
is not dependent on the type based analysis.

Any chance to fix that problem, or at least offer a flag to turn that
additional alias checking off?

-Andi

-- 
This is like TV. I don't like TV.

Re: type based aliasing again

[Andi Kleen]

bernds@cygnus.co.uk (Bernd Schmidt) writes:

> > BTW, it seems to me that this `cast to union' is something particular
> > to gcc, not a general solution, right?  I mean, other compilers might
> > not pay as much attention to the unions as gcc does, since accessing
> > any type other than the one that was actually stored in the union is
> > undefined behavior anyway.
> 
> If, by "cast to union", you mean code of the form
> 
>    union foo
>    {
>       double a;
>       int b[2];
>    };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;
> 
> then this is not even going to work with gcc, regardless of whether
> -fstrict-aliasing is on or not.  We found code like this in some math
> library code here at Cygnus a few weeks ago.  The problem is that gcc's
> MEM_IN_STRUCT/MEM_SCALAR_P alias analysis will catch cases like this and
> determine that the integer memory access can't alias the variable x.

Sigh. I fixed the TCP code in the Linux kernel to (mostly) do that. It
is also compiled with -fno-strict-aliasing. If I understood you and
Jonathan right it may be misoptimized even in with that option, because it 
is not dependent on the type based analysis.

Any chance to fix that problem, or at least offer a flag to turn that
additional alias checking off?

-Andi

-- 
This is like TV. I don't like TV.

Re: type based aliasing again

[Bernd Schmidt]

> BTW, it seems to me that this `cast to union' is something particular
> to gcc, not a general solution, right?  I mean, other compilers might
> not pay as much attention to the unions as gcc does, since accessing
> any type other than the one that was actually stored in the union is
> undefined behavior anyway.

If, by "cast to union", you mean code of the form

   union foo
   {
      double a;
      int b[2];
   };
   double x;
   x = 2.0;
   ((union foo *)&x)->b[1] = 0;

then this is not even going to work with gcc, regardless of whether
-fstrict-aliasing is on or not.  We found code like this in some math
library code here at Cygnus a few weeks ago.  The problem is that gcc's
MEM_IN_STRUCT/MEM_SCALAR_P alias analysis will catch cases like this and
determine that the integer memory access can't alias the variable x.
The code should be written

   union foo
   {
      double a;
      int b[2];
   };
   union foo x;
   x.a = 2.0;
   x.b[1] = 0;

The guarantee that this will work is a gcc extension.

Bernd

Re: type based aliasing again

[Richard Stallman]

    > The question that has been asked by a number of people is whether we
    > can make some of the more "obvious" cases work correctly

    I don't think we can draw a line that separates the ``obvious'' cases
    from the non-obvious ones.

We do not need to draw a line.  If we were implementing a new
feature, we might want one.  But the goal here is to make SOME
of these cases work as the users intended.  We do not want to tell
the users which cases these are, because we are not going to encourage
users to rely on them.

    > The change is simply to postpone the type-based check until after the
    > other analysis is done.  If we detect that the references collide, but
    > the types say that we can assume they don't, we issue a warning and
    > then tell the compiler that there is aliasing.

    I don't think this can detect cases in which pointers are passed into
    functions.

You are right, it can't.  But the change does its job pretty well anyway.

Re: type based aliasing again

[Richard Stallman]

    > The question that has been asked by a number of people is whether we
    > can make some of the more "obvious" cases work correctly

    I don't think we can draw a line that separates the ``obvious'' cases
    from the non-obvious ones.

We do not need to draw a line.  If we were implementing a new
feature, we might want one.  But the goal here is to make SOME
of these cases work as the users intended.  We do not want to tell
the users which cases these are, because we are not going to encourage
users to rely on them.

    > The change is simply to postpone the type-based check until after the
    > other analysis is done.  If we detect that the references collide, but
    > the types say that we can assume they don't, we issue a warning and
    > then tell the compiler that there is aliasing.

    I don't think this can detect cases in which pointers are passed into
    functions.

You are right, it can't.  But the change does its job pretty well anyway.

Re: type based aliasing again

[Alexandre Oliva]

On Sep  8, 1999, Joe Buck <jbuck@synopsys.COM> wrote:

> The question that has been asked by a number of people is whether we
> can make some of the more "obvious" cases work correctly

I don't think we can draw a line that separates the ``obvious'' cases
from the non-obvious ones.

> The change is simply to postpone the type-based check until after the
> other analysis is done.  If we detect that the references collide, but
> the types say that we can assume they don't, we issue a warning and
> then tell the compiler that there is aliasing.

I don't think this can detect cases in which pointers are passed into
functions.  But I haven't thought very thoroughly about it.

Methinks it would be much easier to just issue a warning whenever we
find a type cast to a type that couldn't alias the original type.  Of
course one may cheat and introduce an intermediate cast to void* or
char*, to silence the compiler (would this remove the aliasing problem
too?), but the right fix would be to cast to the appropriate union
type.  This warning would catch most (all?) cases of dangerous type
cases, and require the user to take action to work around them, and it
would take place early enough in the compiler that we could issue good
warning messages.


BTW, it seems to me that this `cast to union' is something particular
to gcc, not a general solution, right?  I mean, other compilers might
not pay as much attention to the unions as gcc does, since accessing
any type other than the one that was actually stored in the union is
undefined behavior anyway.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

type based aliasing again

[Joe Buck]

It seems that RMS and Linus have something in common, in that neither
is happy with the way type-based aliasing is used in gcc 2.95.

RMS has a proposal to do something about it that I'd like to discuss
with you all.  It would be nice if RMS had the bandwidth to take this
up himself, but there seem to be some sensitivities among some developers
over RMS telling them what to do, so it'll probably just go smoother
if I pass the thing on.  Besides, I like his idea.  (Please keep the
cc to RMS on replies).


Some background, for those unfamiliar with the issue: in the past, Fortran
compilers typically generated much faster code than C compilers for
essentially the same code in part because of Fortran's aliasing rules: the
arguments to a Fortran subroutine can never overlap, so the compiler
doesn't have to worry that writing to one array argument will change
another, so loops can keep more stuff in registers.  In C, on the other
hand, it's common to pass two pointers to the same array to a function.

So the ANSI C folks came up with the type-aliasing rule: the compiler
is entitled to assume that accesses (possibly via a pointer) to memory
of one type can't alter memory of another type (they made an exception
for char* pointers and void* pointers, also const char, unsigned char,
etc).  The rule basically makes it illegal to access a value of one
type through a pointer of another type (except for a list of exceptions,
e.g. signed and unsigned flavors of the same integral type).

(For a more precise statement of the rule, see the mail archive).

As of gcc 2.95, optimizations that take advantage of this rule are turned
on by default.  The problem is that there is a good deal of
technically-invalid code out there (that, for example, reads and writes
long data as pairs of shorts, without using unions).  gcc 2.95 may
malfunction on such code unless the flag -fno-strict-aliasing is provided.

The question that has been asked by a number of people is whether we
can make some of the more "obvious" cases work correctly, or somehow
help users find and clean up such cases, and there were a number of
technical proposals, some of which were infeasible, some of which just
weren't satisfactory.

RMS came up with a proposal that I think is reasonable, though we should
have expert input on it.  The idea goes like this: currently, we do
the type-based check first: if two references are of different types,
they do not alias.  If they are of the same or compatible types, we
then proceed to ask (to oversimplify things) whether the references
can collide.  We obtain a three-way answer: yes, we know they collide
(aliasing); no, they never collide (no aliasing), or maybe, we can't tell
(assume aliasing to be safe).  Generally speaking, we do this analysis
by seeing if two references are both offsets from the same base address
and then look at the offsets.

The change is simply to postpone the type-based check until after the
other analysis is done.  If we detect that the references collide, but
the types say that we can assume they don't, we issue a warning and
then tell the compiler that there is aliasing.  (A variant is to silently
accept the code, but I would prefer issuing a warning).  If we fall into
the "maybe" case, we assume no aliasing if the types don't match.

Some questions:

- Can anyone tell me why this is not feasible?

- For those of you with code that is impacted by -fstrict-aliasing, can
  you look and see whether this modification would give you a warning?
  (That is, can the compiler see based on purely local information that
  the true address and the pointed-to object overlap)?

- Should we do this?

Joe

Re: type based aliasing again

[Joe Buck]

RMS writes:

> In C, we cannot divide all user code into "right" and "wrong" in this
> kind of simple way, and certainly not based on the ISO standard.  That
> standard is just the decisions of a certain committee (which I was a
> member of) about what cases conforming compilers should commit to
> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

While I have some sympathy for that point of view, the reason that
the type aliasing rules were added was to give scientific programmers
what they were asking for: C that runs about as fast as Fortran.

I don't want to break users' code when we can TELL what they mean,
and many examples seem to fall into that category.  But where we
can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias)
or not (-fno-strict-alias).

In the end, if your argument is carried too far, the only solution
would be to make -fno-strict-alias the default.  But that penalizes
the users that make the effort to learn the rule.

I think that we don't disagree on general philosophy, only where to draw
the line.

Re: type based aliasing again

[craig]

If a warning is simple enough to add that it takes only a few lines
occurs in an obvious place, and doesn't experience a change in its
"envelope" due to reasonable changes in how a compiler internally
represents things, I'm all for it in a product like GCC.

That's not my impression as to how *this* proposed warning is likely to be
implemented.  That's why I'm not in favor of it, along with the fact
that this issue is already taking up far more valuable time on these
lists than it *ever* deserved.

[Joe wrote:]
>Exactly; post violations I've seen are of that type.  I can't aspire to
>the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
>missing this point: a whole lot of the errors we've seen are of this
>extremely simple form, with the entire error appearing in two or three
>adjacent lines of code.  We know the exact offsets of each address and
>can clearly see that they collide.

Let me see if I can explain my concerns here.

If we introduce the proposed new warning in GCC, it will require not
only some significant changes to implement, it *will* require extra
work to maintain.  Forever.  Until the end of time.

That's because the mere *apparent* promise that GCC will warn about
suspicious constructs will be enough to persuade too many people that
they don't need to audit their code, line by line, and fix the problem.

[Joe later wrote:]
>My intent, which may be different from RMS's intent, is to help users
>get rid of this variety of invalid code, not to perpetuate it.

I agree 100%.  I believe this proposed warning will be interpreted by
much of the user base as a reliable indicator of when to turn off
alias analysis rather than of when to fix their code, based on how
this issue has been treated in these discussions.

So those people will rely on GCC holding their hands.  Most of the time
it might be correct.  Too often, it will be wrong.  We will blamed
when it is, just as we've been blamed *already* for providing a *correct*
compiler with a *simple* workaround for buggy code.

Remember, some of you have already been seriously considering having
the mere *warning* trigger a *different* code-generation strategy.
Why?

I think the answer is pretty clear -- it's because you already know,
deep, down inside, that the real agenda here is to make it easy for
people who think GCC really *should* support their alias-concern-free
variant of the C language to continue to write code *their* way.
Then they'll just ignore, or filter out, the warnings.  (If the FAQ
could say "don't do that", then it could just as well say "use
-fno-strict-aliasing".  Hey!!  It already does!  Then why are we
having this discussion, if we are going to assume people will read
the docs?)

If that's not the case, then please end all discussion of the warning
turning off aliasing.  That's no more sensible than having the
uninitialized-variable warning triggering the automatic bzero-ing of
the stack frame upon entry to every procedure, along with all sorts
of other "friendly" things for warnings to do.

Now, I already *know* all the counterarguments to this concern.

But every one of them can be applied to the *current* situation,
where we have *no* warnings, -fstrict-aliasing is the default,
and users have the -fno-strict-aliasing option:

  -  "We can tell people not to rely on the warnings, or lack thereof,
      as any sort of substitute for fixing their code."

     Oh sure, tell them to read the docs.  Sorry: that didn't work
     in the first place to get them to write ANSI/ISO-conforming
     code *or* to get them to use -fno-strict-aliasing.  If you think
     they'll go away just because a new warning appears, please
     cite your evidence for that tactic working under similar
     circumstances -- I'd love to see it.  (Having worked on g77,
     which has a *far* more forgiving audience, in this sense, than
     gcc, I know firsthand how new warnings are received, no matter
     how well they're documented.  They're no panacea.  And I suggest
     the g77 warnings I'm thinking of are, and have generally been,
     *vastly* better documented than GCC warnings -- so if you think
     you're going to avoid a substantial number of complaints and real
     problems with this warning, you'll have to document it better
     than g77 documents any of *its* warnings, IMO.)

  -  "It's important to catch *all* the possible problems somehow,
     so as to avoid generating bad code."

     Not only is the warning idea going to *fail* at that, there's
     *already* -fno-strict-aliasing.  That is the most reliable
     method we're going to ever offer.  Period.

  -  "We're just trying to address certain common cases that occur
     within only a few lines of code, not get at all the problems
     at once."

     A much more reasonable stance.  I suggest someone write a few
     lines of Perl, Scheme, or some such thing to do the job.  Please
     leave it out of GCC internals, though it could be shipped with GCC.

  -  "But people expect GCC to do all these things for them."

     It can't and won't, so we should pick and choose the things it'll
     do best.  That Perl/Scheme script?  Using the time/energy spent
     conducting pro-munging-GCC campaigns on these lists, I'm sure
     a "clever programmer" or two could not only have written it,
     but tested it *and* distributed it, perhaps two or three versions
     by now.

     What the C community needs is a tool to find this particularly
     gnarly problem.  It should view it as a use-once-and-fix-thereby
     tool.  Fixing this problem is like fixing the Y2K problem.  Do
     it once, and do it right.  Putting the same functionality in
     GCC suggests more of an ad-hoc approach to deciding whether to
     tolerate, fix, or ignore the problem.

     And the users who supposedly need this solution *now* could get it
     *now* if you'd (whoever you are) just go and write it, distribute
     it, and not make them wait (even longer) for GCC 3.0.  (Longer
     because of the time it'll take to add, document, and write test
     cases for this new warning.  And what happens when, one month
     before scheduled release, someone notices that the warning doesn't
     work right on *one* platform, like the uninitialized-variable
     warning awhile ago on Alphas?  Do we delay the release to fix
     this warning, which is supposedly so crucial we've spent all this
     time discussing and installing it, or blow off the importance of
     helping those poor, confused C programmers on a major platform?)

  -  "It's much easier to change GCC to warn about this than to write
     a new script, especially when it comes to certain cases."

     I suggest that if a simple script can't catch the problem, a GCC
     warning, even if it worked, wouldn't help users catch the problem
     any more than they're helped now using -fno-strict-analysis.  (That
     is, such users have *already* claimed they're not going to fix
     code where the problem is strewn throughout.  I'm thinking of Linux
     here.  And whatever the Linux cognescenti decide, many thousands
     of programmers will surely do as well.  In that sense, Linus and
     David Miller have given us tremendously valuable input -- a preview
     of what, say, 1000 programmers will be screaming at us about one
     year after Merced, or McKinley, comes out.)

     But, if you like, snarf a copy of GCC, strip out all the code
     generation, and add the patch you think is so easy to warn
     about the problem.  Make it a separate product, on its own
     release schedule.  Same reasons as above.

     In other words, have GCC distribute not only cc1, protoize, and
     unprotoize, but findalias as well.

  -  "But the proposed warning won't make GCC much more complex."

     Perhaps not, but every little addition like this requires all *future*
     maintainers of GCC to cope with that much more state, that much
     more complexity, and, most difficult for new, enthusiastic
     developers to cope with, more "quiet expectation" that the "envelope"
     of the warning (the circumstances under which it is and is not
     issued) will never change or, at least, will only "get better".
     With *this* proposed warning, I think that's going to be particularly
     challenging, based on the discussions of the technical aspects of
     it.

The wording Joe used earlier, "the mode of treating the user like
an opponent", bothered me because it implied that any refusal to
add new "features" constituted opposing users.

That is probably not what Joe intended, but, let me say, the willingness
to add any new feature asked for by users *can* constitute opposing
the ability of your "e-descendants" to continue to maintain the
product as a going concern.

So, while a warning (that has no effect on code generation) *might* be
a good idea, I tend to think that, in this case, it is not, based on
a rather quick reading of the original (recent) proposal.

As back-up to my positions, I suggest readers review archives (wish
they could do so of the gcc2 postings I remember from years back)
vis-a-vis complaints and hassles when much simpler (conceptually)
warnings didn't behave as expected, such as uninitialized-variable
warnings; and vis-a-vis claims about how GCC should cater to "clever
programmers" (their own words) by providing essentially endless,
detailed control over every aspect of code generation, even if doing
so is at the expense of delivering a robust, high-performance,
predictable compiler for "non-clever" programmers who actually
follow the standards, read the documentation, and rely on much more
than "well, it always worked that way before" to justify their
requests.

In the end, it's a question of what kind of users we want to cater to.
I've found it much easier to cater to people who "read the directions",
so to speak, than those who ride by the seat of their pants.  YMMV,
but it should be easy to see why catering directly to the former
allows the latter to continue to operate however they like -- catering
to the latter makes the product worse for direction-followers and
only encourages the direction-ignorers to take even more risks.  (Which
was the point I was trying to make with my previous post containing
the shell script -- exactly the sort of thing a "clever programmer"
would invent *and* expect to always work.)

        tq vm, (burley)

Re: type based aliasing again

[Jonathan Larmour]

In article < 19990910152622.9143.qmail@deer > you write:
>But every one of them can be applied to the *current* situation,
>where we have *no* warnings, -fstrict-aliasing is the default,
>and users have the -fno-strict-aliasing option:

Just to add a bit of extra spice, I don't believe users do have the
-fno-strict-aliasing option as a panacea. User code can fail if it casts
between struct/union types and scalar types, but not because of the alias
analysis (so -fno-strict-aliasing doesn't help).

Instead the scheduler performs some optimizations based on MEM_IN_STRUCT
vs. MEM_SCALAR_P tests. If the user code casts between structs and scalars,
the instructions can be reordered the wrong way round.

So, even with -fno-strict-aliasing this class of problem can't necessarily
be worked around.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: type based aliasing again

[craig]

>Just to add a bit of extra spice, I don't believe users do have the
>-fno-strict-aliasing option as a panacea. User code can fail if it casts
>between struct/union types and scalar types, but not because of the alias
>analysis (so -fno-strict-aliasing doesn't help).
>
>Instead the scheduler performs some optimizations based on MEM_IN_STRUCT
>vs. MEM_SCALAR_P tests. If the user code casts between structs and scalars,
>the instructions can be reordered the wrong way round.
>
>So, even with -fno-strict-aliasing this class of problem can't necessarily
>be worked around.

If that's the case, we should be working on fixing *that*, rather
than discussing niceties of default code-generation.

        tq vm, (burley)

Re: type based aliasing again

[craig]

>Just to add a bit of extra spice, I don't believe users do have the
>-fno-strict-aliasing option as a panacea. User code can fail if it casts
>between struct/union types and scalar types, but not because of the alias
>analysis (so -fno-strict-aliasing doesn't help).
>
>Instead the scheduler performs some optimizations based on MEM_IN_STRUCT
>vs. MEM_SCALAR_P tests. If the user code casts between structs and scalars,
>the instructions can be reordered the wrong way round.
>
>So, even with -fno-strict-aliasing this class of problem can't necessarily
>be worked around.

If that's the case, we should be working on fixing *that*, rather
than discussing niceties of default code-generation.

        tq vm, (burley)

Re: type based aliasing again

[Jonathan Larmour]

In article < 19990910152622.9143.qmail@deer > you write:
>But every one of them can be applied to the *current* situation,
>where we have *no* warnings, -fstrict-aliasing is the default,
>and users have the -fno-strict-aliasing option:

Just to add a bit of extra spice, I don't believe users do have the
-fno-strict-aliasing option as a panacea. User code can fail if it casts
between struct/union types and scalar types, but not because of the alias
analysis (so -fno-strict-aliasing doesn't help).

Instead the scheduler performs some optimizations based on MEM_IN_STRUCT
vs. MEM_SCALAR_P tests. If the user code casts between structs and scalars,
the instructions can be reordered the wrong way round.

So, even with -fno-strict-aliasing this class of problem can't necessarily
be worked around.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: type based aliasing again

[Richard Stallman]

    That's because the mere *apparent* promise that GCC will warn about
    suspicious constructs will be enough to persuade too many people that
    they don't need to audit their code, line by line, and fix the problem.

Many people will conclude *now* that they don't need to do this.  All
they need to do is add -fno-strict-aliasing.

If we keep the old code (in most cases) working, but add a warning for
many (even if not all) of the problem cases, people will be far more
likely to change their code, instead of using -fno-strict-aliasing.

    Remember, some of you have already been seriously considering having
    the mere *warning* trigger a *different* code-generation strategy.

Maybe someone is considering this, but it isn't what I'm proposing.

I say we should keep user code found in real programs working, as long
as that is easy to do.  Sometimes it is necessary or important to
break code people use, and then it's worth doing so.  But when we have
an easy and painless way to keep certain code working, then breaking
it is not necessary or important, so we shouldn't.

I think the warning is a good idea too.

Re: type based aliasing again

[craig]

>I say we should keep user code found in real programs working, as long
>as that is easy to do.  Sometimes it is necessary or important to
>break code people use, and then it's worth doing so.  But when we have
>an easy and painless way to keep certain code working, then breaking
>it is not necessary or important, so we shouldn't.

I don't really disagree with this.  The "easy to do" part is important.

One thing I notice about, e.g., Tim Prince's occasional posts about
g77 vis-a-vis commercial compilers is that, while it sometimes suffers
in a performance comparison, it tends to more often choose code paths
(implementation alternatives might be a better terminology) consistent
with how the code actually looks.

I haven't investigated any of his examples that I can think of, so
perhaps one has to do with the other.

But if it's easy for the GCC middle/back ends to generate the "natural"
implementation, based on the input code stream (and assuming the front
end doesn't obscure that stream), in the absence of a clear preference
based on, for example, optimization, then IMO it's better for GCC
to default to that approach than otherwise.

That's because while, indeed, such a choice might (as Marc correctly
points out) generate the impression that user code works better than
it otherwise would, or will, on future architectures, better compilers,
*different* compilers, and so on, given the width and breadth of
code compiled by GCC and the programmers who write (and have written
and will write) such code, a compiler that tends to implement
code the "natural" way when there's no clear choice as to which is
best will be more apt to help the *industry* deploy more immediately
stable products overall.

I want to emphasize that "easy to do", in RMS's terms, means to me
that the compiler should *itself* never make this assessment.  It should
be made only by compiler writers, based on a cursory examination.

So I'm not suggesting anyone change GCC to implement "foo(i++,i++,i++);"
to evaluate the arguments left-to-right instead of right-to-left if *it*
can reckon there'd be no substantial performance penalty for doing so.

But I'm suggesting perhaps it *should* so implement it if there's
no *general* likelihood of a performance penalty for left-to-right
order vs. right-to-left order.  (If it's just a matter of a tm.h
macro definition or some such thing.)

It is so difficult to explain this so users don't misunderstand this
as some sort of promise for a long-term accommodation of certain sorts
of broken code, that I don't suggest we do it in anything that appears
to be user documentation.  Internal documentation, or recommendations
for how GCC (or GNU) programmers should code things?  Fine -- users
who are interested in implementation internals should read that.  Let
them therefore recognize that one of the benefits of free-software
products is that their development process is necessarily more open,
so that they aren't likely to have similar access to internal info
on proprietary software.  (If we make such statements in *user* docs,
we encourage proprietary-software makers to make similar *promises*,
which might, in the absence of internal docs, actually lead some
users to believe them.)

That being said, I've long wanted an option that I'll call, for the moment,
`-fconfound-me', that directs code generators, interpreters, and so
on to, wherever they are prepared to (and allowed by the relevant
specifications), do things in an "unexpected", rather than "natural", way,
so I could evaluate whether my code stands up to such "abuse".

That option might not reverse order of argument evaluation on an
architecture where one order will be generally more optimal than
another.

But it would cause the compiler to choose, where choices of "naturalness"
have been consciously made vis-a-vis the option, the "unnatural" path.
(In the g77 front end, this would do simple things like reverse the
order of operands in "A+B" as it presents them to the back end.  Of course,
if the back end also supports the option and reverses them.... ;-)

I'm not asking for GCC to implement this option, even as a stub for
whoever might want to start testing it within their middle/back-end
code in the future, though.

That's because, having long *wanted* such an option, I've long envisioned
what a compiler architected to support this option (and others I'd
like) would look like internally.  It's not exactly trivial, and the
complexity it would add to GCC in particular, over the long haul, could
be one of the many straws in the camel's back making it unmaintainable.

My awareness of the possible desirability of such an option might
also explain to some why I'm so hesitant about us doing anything
that might make *users* of GCC think we will always manage to
accommodate their less-than-perfect coding techniques.

In particular, once my proposed option existed and started getting
used, "clever" programmers might start to reason "well, now you can
have the compiler make better choices as to what *is* natural,
based on *dynamic* assessment of the various choices and their costs,
because that'll help support -fconfound-me too -- it can make
more-confounding choices based on recognizing their lack of substantial
performance impact on a dynamic basis".  (There are lots more
things that fall out of this, that are at least as reasonable -- I
won't go into them here, but some of them are *way* cool.)

It'd be at least as hard *then* to resist that logic as it is *now*
to resist the logic of the statement "GCC should choose the more
natural implementation unless there's a clear win for choosing some
other implementation" (which is *not* what RMS is saying, thankfully).

So I view RMS's statement about how GCC should behave, vis-a-vis
what users should expect, the way I view "the separation of church
and state" vis-a-vis the legislative/executive branches versus the
judicial branch of the US government -- the legislative/executive should
take up the standard so as to reduce the friction resulting from the
judicial stepping a tad out of line, but the latter should *never* use
that strict a standard to force the former back into line.  (NB I said
that's how *I* view that standard vis-a-vis government: I'm not
in any way asking others to view it the same way.  I might suggest
it'd lead to less friction and more freedom if the respective branches
of government viewed their responsibilities accordingly, based on
a more engineering-like view of "tolerance".  But I haven't read
the legislative and judicial history of the standard itself, so
my analysis is not a "legal" one.)

I.e. we should decide for *ourselves* as GCC developers (and of course
users can send in patches if they like) to what degree we can and
should support "naturalness".  As long as we make a good-faith
attempt to do so, reasonable, even *slightly* extreme, users will
ultimately appreciate our efforts.

But when *users* claim GCC didn't choose a "natural" implementation
for some construct and thus broke (or, more precisely, exposed breakage
in) their code, we should, as developers, make it clear *to users*
(even if we might go the extra mile ourselves to help) that it is
up to *them* to show that the choice GCC made couldn't have benefited
performance in any general circumstance *and* is easy for GCC to
choose differently.  The default response should be "GCC is generating
code in line with the pertinent standards and specifications, which
is all you should expect", so that any extra help we give is clearly
seen to proceed from that basis.

In the end, the caveat "easy to do" carries with it so much more
than mere ease of coding, or even ease of decision-making, when
*implementing* the compiler.  If we in any way make this promise
to *users* of GCC, we invite negative feedback in so many potential
cases, that the end result could be that *very* little "naturalness"
ends up as "easy to do" -- thanks to all the hassles of getting
into discussions like this over every little implementation detail.

So, if the GCC Steering Committee decided to drop RMS's advice for now,
on the basis that GCC wasn't yet close to meeting the *basic* promises
of standards conformance and adequate specification of extensions,
so all effort needed to be concentrated there and not at low-level
implementation details (and discussions arising therefrom), I wouldn't
disagree with that either.  (Though I think g77 is meeting FORTRAN 77
standards conformance well enough already, and probably the same is
true for the C compiler as well...but g++, I don't know.  And we're
mostly in the same boat here: if the g++ people are still working
hard just to conform to a moving-target standard *and* their work
requires getting basic conformance in the middle/back end *and* that
affects gcc/g77, then it might indeed be wise to not attempt to meet
RMS's standard vis-a-vis even gcc and g77 until things "settle down"
in the middle/back end.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    >I say we should keep user code found in real programs working, as long
    >as that is easy to do.  Sometimes it is necessary or important to
    >break code people use, and then it's worth doing so.  But when we have
    >an easy and painless way to keep certain code working, then breaking
    >it is not necessary or important, so we shouldn't.

    I don't really disagree with this.  The "easy to do" part is important.

It is beyond important, it is the point of the idea.  That is where
this alternative differs from the others that people have been
considering.

    I want to emphasize that "easy to do", in RMS's terms, means to me
    that the compiler should *itself* never make this assessment.  It should
    be made only by compiler writers, based on a cursory examination.

That's what I have in mind, too.  The thing that might or might not
be "easy to do" is the *change* in GCC, that people could write.

    It is so difficult to explain this so users don't misunderstand this
    as some sort of promise for a long-term accommodation of certain sorts
    of broken code, that I don't suggest we do it in anything that appears
    to be user documentation.

That's what I have in mind, too.

It looks like people have until now rejected consideration of all but
these two alternatives:

1. Document these cases as a feature, and keep it working
come hell or high water.

2. Make absolutely no effort to keep these cases working.

These are two extremes in a continuum.  If we really had only these
two choices, #2 would be better, for the reasons others have given.
But if we admit the intermediate possibilities, we can usually find
one that is better than either extreme:

3. Make a little effort to keep these cases working today.

Actually, in some sense #2 is not the ultimate extreme.  We could go
even further:

4. Make damned sure these cases will not behave as expected.

This would be a subcase of the -fconfound-me option you proposed.  I
mention it to show how #2 is different from this--and what that
implies.

Some people argue that users will "get the wrong ideas" if any of
these cases do work.  Well, if that is possible, it is happening now,
because some of these cases do work.  With -O0, they all work.  Unless
we do #4, some of them will always work.


I'm not the GCC maintainer any more, and I don't have time to get
involved in more than a handful of the technical decisions about GCC,
even if I wanted to.  This particular issue is important because many
users are unhappy with it.  But there's a bigger question at stake:
what is the right basis for making such decisions about GCC?  That
question is crucial for this issue now, and will be crucial for other
issues in the future.

To do a good job, we must consider option #3.  On some issues, there
will be a good way to use option #3; on others, there won't be.  But
if we don't use it when there is a way, we will make GCC a harsh
compiler.  Please, always consider option #3.

Re: type based aliasing again

[craig]

>Some people argue that users will "get the wrong ideas" if any of
>these cases do work.  Well, if that is possible, it is happening now,
>because some of these cases do work.  With -O0, they all work.  Unless
>we do #4, some of them will always work.

Right.  My feeling is, it's better, as long as it's reasonably easy
and doesn't hurt performance, for the default to be consistent with
what users (who don't know the standard inside and out) expect.

If we could be sure we had a "captive audience" that would respond
to our completely ignoring the not-quite-standard code as buggy and
needing fixing, we might indeed help the industry as a whole, and
GCC in particular, become "better".  I.e. users would have no
choice but to fix their code, and, for codes that are likely to
outlast IA32 (vs. Merced/McKinley), the sooner the better, given
the typical "depreciation" on expertise on any given chunk of code.

But we don't have that big a captive audience.  Among other things,
GCC needs as much widespread, volunteer testing done on it as possible,
and the more code it "captures" by working and performing reasonably
well on it, even if it isn't perfectly standard code, the better GCC
becomes.

That some of that code will appear to stop working when ported to
new architectures will be perceived by some as GCC being "wrong",
putting us right back in today's boat vis-a-vis those users.

In the meantime, GCC will have become better, and hopefully better-
respected, before that happens, thus reducing the percentage of
its users who decide GCC has truly "stopped working" rather than
(finally) go and fix the code.  That might be enough to convince
as many people as would ever be feasible anyway that the broken code,
not GCC, finally needed fixing.

So if we worry less about accommodating that code now, we risk losing
more of it *now* to volunteer testing and gaining market share.

But, if we worry much more about accommodating that code, we risk
spending time on that rather than actually making GCC work for
correct code, which can *also* lose us lots of users and code.

It's that latter drop-off I'm more concerned about, if not so much
in number of lines of legacy code, in number of lines of new code
that gets written.  But the former drop-off isn't something we
can completely ignore.

(This is basically the same rationale as one of the ones I was using
to explain my support for doing 80-bit floating-point spills on IA32,
in case anyone was wondering.  One important difference between the
two issues is that at least one viable and effective specification
exists saying that 80-bit spills *should* be done, whereas a
standard exists saying that accommodating C code playing alias
games need *not* be done.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    But, if we worry much more about accommodating that code, we risk
    spending time on that rather than actually making GCC work for
    correct code, which can *also* lose us lots of users and code.

For accommodating code that isn't strictly valid, I think it is
sufficient if we do this when we can do it without much work, and
without losing any noticeable amount of speed.

If the GCC maintainers sincerely undertake to do this, I am sure they
can judge how much time to spend on it.  Often there is a way that
is easy to find when you look for one in this spirit.  If you make
a proper effort to look, and you don't see one, then you don't
do anything.

Re: type based aliasing again

[Richard Stallman]

    But, if we worry much more about accommodating that code, we risk
    spending time on that rather than actually making GCC work for
    correct code, which can *also* lose us lots of users and code.

For accommodating code that isn't strictly valid, I think it is
sufficient if we do this when we can do it without much work, and
without losing any noticeable amount of speed.

If the GCC maintainers sincerely undertake to do this, I am sure they
can judge how much time to spend on it.  Often there is a way that
is easy to find when you look for one in this spirit.  If you make
a proper effort to look, and you don't see one, then you don't
do anything.

Re: type based aliasing again

[craig]

>Some people argue that users will "get the wrong ideas" if any of
>these cases do work.  Well, if that is possible, it is happening now,
>because some of these cases do work.  With -O0, they all work.  Unless
>we do #4, some of them will always work.

Right.  My feeling is, it's better, as long as it's reasonably easy
and doesn't hurt performance, for the default to be consistent with
what users (who don't know the standard inside and out) expect.

If we could be sure we had a "captive audience" that would respond
to our completely ignoring the not-quite-standard code as buggy and
needing fixing, we might indeed help the industry as a whole, and
GCC in particular, become "better".  I.e. users would have no
choice but to fix their code, and, for codes that are likely to
outlast IA32 (vs. Merced/McKinley), the sooner the better, given
the typical "depreciation" on expertise on any given chunk of code.

But we don't have that big a captive audience.  Among other things,
GCC needs as much widespread, volunteer testing done on it as possible,
and the more code it "captures" by working and performing reasonably
well on it, even if it isn't perfectly standard code, the better GCC
becomes.

That some of that code will appear to stop working when ported to
new architectures will be perceived by some as GCC being "wrong",
putting us right back in today's boat vis-a-vis those users.

In the meantime, GCC will have become better, and hopefully better-
respected, before that happens, thus reducing the percentage of
its users who decide GCC has truly "stopped working" rather than
(finally) go and fix the code.  That might be enough to convince
as many people as would ever be feasible anyway that the broken code,
not GCC, finally needed fixing.

So if we worry less about accommodating that code now, we risk losing
more of it *now* to volunteer testing and gaining market share.

But, if we worry much more about accommodating that code, we risk
spending time on that rather than actually making GCC work for
correct code, which can *also* lose us lots of users and code.

It's that latter drop-off I'm more concerned about, if not so much
in number of lines of legacy code, in number of lines of new code
that gets written.  But the former drop-off isn't something we
can completely ignore.

(This is basically the same rationale as one of the ones I was using
to explain my support for doing 80-bit floating-point spills on IA32,
in case anyone was wondering.  One important difference between the
two issues is that at least one viable and effective specification
exists saying that 80-bit spills *should* be done, whereas a
standard exists saying that accommodating C code playing alias
games need *not* be done.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    >I say we should keep user code found in real programs working, as long
    >as that is easy to do.  Sometimes it is necessary or important to
    >break code people use, and then it's worth doing so.  But when we have
    >an easy and painless way to keep certain code working, then breaking
    >it is not necessary or important, so we shouldn't.

    I don't really disagree with this.  The "easy to do" part is important.

It is beyond important, it is the point of the idea.  That is where
this alternative differs from the others that people have been
considering.

    I want to emphasize that "easy to do", in RMS's terms, means to me
    that the compiler should *itself* never make this assessment.  It should
    be made only by compiler writers, based on a cursory examination.

That's what I have in mind, too.  The thing that might or might not
be "easy to do" is the *change* in GCC, that people could write.

    It is so difficult to explain this so users don't misunderstand this
    as some sort of promise for a long-term accommodation of certain sorts
    of broken code, that I don't suggest we do it in anything that appears
    to be user documentation.

That's what I have in mind, too.

It looks like people have until now rejected consideration of all but
these two alternatives:

1. Document these cases as a feature, and keep it working
come hell or high water.

2. Make absolutely no effort to keep these cases working.

These are two extremes in a continuum.  If we really had only these
two choices, #2 would be better, for the reasons others have given.
But if we admit the intermediate possibilities, we can usually find
one that is better than either extreme:

3. Make a little effort to keep these cases working today.

Actually, in some sense #2 is not the ultimate extreme.  We could go
even further:

4. Make damned sure these cases will not behave as expected.

This would be a subcase of the -fconfound-me option you proposed.  I
mention it to show how #2 is different from this--and what that
implies.

Some people argue that users will "get the wrong ideas" if any of
these cases do work.  Well, if that is possible, it is happening now,
because some of these cases do work.  With -O0, they all work.  Unless
we do #4, some of them will always work.


I'm not the GCC maintainer any more, and I don't have time to get
involved in more than a handful of the technical decisions about GCC,
even if I wanted to.  This particular issue is important because many
users are unhappy with it.  But there's a bigger question at stake:
what is the right basis for making such decisions about GCC?  That
question is crucial for this issue now, and will be crucial for other
issues in the future.

To do a good job, we must consider option #3.  On some issues, there
will be a good way to use option #3; on others, there won't be.  But
if we don't use it when there is a way, we will make GCC a harsh
compiler.  Please, always consider option #3.

Re: type based aliasing again

[craig]

>I say we should keep user code found in real programs working, as long
>as that is easy to do.  Sometimes it is necessary or important to
>break code people use, and then it's worth doing so.  But when we have
>an easy and painless way to keep certain code working, then breaking
>it is not necessary or important, so we shouldn't.

I don't really disagree with this.  The "easy to do" part is important.

One thing I notice about, e.g., Tim Prince's occasional posts about
g77 vis-a-vis commercial compilers is that, while it sometimes suffers
in a performance comparison, it tends to more often choose code paths
(implementation alternatives might be a better terminology) consistent
with how the code actually looks.

I haven't investigated any of his examples that I can think of, so
perhaps one has to do with the other.

But if it's easy for the GCC middle/back ends to generate the "natural"
implementation, based on the input code stream (and assuming the front
end doesn't obscure that stream), in the absence of a clear preference
based on, for example, optimization, then IMO it's better for GCC
to default to that approach than otherwise.

That's because while, indeed, such a choice might (as Marc correctly
points out) generate the impression that user code works better than
it otherwise would, or will, on future architectures, better compilers,
*different* compilers, and so on, given the width and breadth of
code compiled by GCC and the programmers who write (and have written
and will write) such code, a compiler that tends to implement
code the "natural" way when there's no clear choice as to which is
best will be more apt to help the *industry* deploy more immediately
stable products overall.

I want to emphasize that "easy to do", in RMS's terms, means to me
that the compiler should *itself* never make this assessment.  It should
be made only by compiler writers, based on a cursory examination.

So I'm not suggesting anyone change GCC to implement "foo(i++,i++,i++);"
to evaluate the arguments left-to-right instead of right-to-left if *it*
can reckon there'd be no substantial performance penalty for doing so.

But I'm suggesting perhaps it *should* so implement it if there's
no *general* likelihood of a performance penalty for left-to-right
order vs. right-to-left order.  (If it's just a matter of a tm.h
macro definition or some such thing.)

It is so difficult to explain this so users don't misunderstand this
as some sort of promise for a long-term accommodation of certain sorts
of broken code, that I don't suggest we do it in anything that appears
to be user documentation.  Internal documentation, or recommendations
for how GCC (or GNU) programmers should code things?  Fine -- users
who are interested in implementation internals should read that.  Let
them therefore recognize that one of the benefits of free-software
products is that their development process is necessarily more open,
so that they aren't likely to have similar access to internal info
on proprietary software.  (If we make such statements in *user* docs,
we encourage proprietary-software makers to make similar *promises*,
which might, in the absence of internal docs, actually lead some
users to believe them.)

That being said, I've long wanted an option that I'll call, for the moment,
`-fconfound-me', that directs code generators, interpreters, and so
on to, wherever they are prepared to (and allowed by the relevant
specifications), do things in an "unexpected", rather than "natural", way,
so I could evaluate whether my code stands up to such "abuse".

That option might not reverse order of argument evaluation on an
architecture where one order will be generally more optimal than
another.

But it would cause the compiler to choose, where choices of "naturalness"
have been consciously made vis-a-vis the option, the "unnatural" path.
(In the g77 front end, this would do simple things like reverse the
order of operands in "A+B" as it presents them to the back end.  Of course,
if the back end also supports the option and reverses them.... ;-)

I'm not asking for GCC to implement this option, even as a stub for
whoever might want to start testing it within their middle/back-end
code in the future, though.

That's because, having long *wanted* such an option, I've long envisioned
what a compiler architected to support this option (and others I'd
like) would look like internally.  It's not exactly trivial, and the
complexity it would add to GCC in particular, over the long haul, could
be one of the many straws in the camel's back making it unmaintainable.

My awareness of the possible desirability of such an option might
also explain to some why I'm so hesitant about us doing anything
that might make *users* of GCC think we will always manage to
accommodate their less-than-perfect coding techniques.

In particular, once my proposed option existed and started getting
used, "clever" programmers might start to reason "well, now you can
have the compiler make better choices as to what *is* natural,
based on *dynamic* assessment of the various choices and their costs,
because that'll help support -fconfound-me too -- it can make
more-confounding choices based on recognizing their lack of substantial
performance impact on a dynamic basis".  (There are lots more
things that fall out of this, that are at least as reasonable -- I
won't go into them here, but some of them are *way* cool.)

It'd be at least as hard *then* to resist that logic as it is *now*
to resist the logic of the statement "GCC should choose the more
natural implementation unless there's a clear win for choosing some
other implementation" (which is *not* what RMS is saying, thankfully).

So I view RMS's statement about how GCC should behave, vis-a-vis
what users should expect, the way I view "the separation of church
and state" vis-a-vis the legislative/executive branches versus the
judicial branch of the US government -- the legislative/executive should
take up the standard so as to reduce the friction resulting from the
judicial stepping a tad out of line, but the latter should *never* use
that strict a standard to force the former back into line.  (NB I said
that's how *I* view that standard vis-a-vis government: I'm not
in any way asking others to view it the same way.  I might suggest
it'd lead to less friction and more freedom if the respective branches
of government viewed their responsibilities accordingly, based on
a more engineering-like view of "tolerance".  But I haven't read
the legislative and judicial history of the standard itself, so
my analysis is not a "legal" one.)

I.e. we should decide for *ourselves* as GCC developers (and of course
users can send in patches if they like) to what degree we can and
should support "naturalness".  As long as we make a good-faith
attempt to do so, reasonable, even *slightly* extreme, users will
ultimately appreciate our efforts.

But when *users* claim GCC didn't choose a "natural" implementation
for some construct and thus broke (or, more precisely, exposed breakage
in) their code, we should, as developers, make it clear *to users*
(even if we might go the extra mile ourselves to help) that it is
up to *them* to show that the choice GCC made couldn't have benefited
performance in any general circumstance *and* is easy for GCC to
choose differently.  The default response should be "GCC is generating
code in line with the pertinent standards and specifications, which
is all you should expect", so that any extra help we give is clearly
seen to proceed from that basis.

In the end, the caveat "easy to do" carries with it so much more
than mere ease of coding, or even ease of decision-making, when
*implementing* the compiler.  If we in any way make this promise
to *users* of GCC, we invite negative feedback in so many potential
cases, that the end result could be that *very* little "naturalness"
ends up as "easy to do" -- thanks to all the hassles of getting
into discussions like this over every little implementation detail.

So, if the GCC Steering Committee decided to drop RMS's advice for now,
on the basis that GCC wasn't yet close to meeting the *basic* promises
of standards conformance and adequate specification of extensions,
so all effort needed to be concentrated there and not at low-level
implementation details (and discussions arising therefrom), I wouldn't
disagree with that either.  (Though I think g77 is meeting FORTRAN 77
standards conformance well enough already, and probably the same is
true for the C compiler as well...but g++, I don't know.  And we're
mostly in the same boat here: if the g++ people are still working
hard just to conform to a moving-target standard *and* their work
requires getting basic conformance in the middle/back end *and* that
affects gcc/g77, then it might indeed be wise to not attempt to meet
RMS's standard vis-a-vis even gcc and g77 until things "settle down"
in the middle/back end.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    That's because the mere *apparent* promise that GCC will warn about
    suspicious constructs will be enough to persuade too many people that
    they don't need to audit their code, line by line, and fix the problem.

Many people will conclude *now* that they don't need to do this.  All
they need to do is add -fno-strict-aliasing.

If we keep the old code (in most cases) working, but add a warning for
many (even if not all) of the problem cases, people will be far more
likely to change their code, instead of using -fno-strict-aliasing.

    Remember, some of you have already been seriously considering having
    the mere *warning* trigger a *different* code-generation strategy.

Maybe someone is considering this, but it isn't what I'm proposing.

I say we should keep user code found in real programs working, as long
as that is easy to do.  Sometimes it is necessary or important to
break code people use, and then it's worth doing so.  But when we have
an easy and painless way to keep certain code working, then breaking
it is not necessary or important, so we shouldn't.

I think the warning is a good idea too.

Re: type based aliasing again

[craig]

If a warning is simple enough to add that it takes only a few lines
occurs in an obvious place, and doesn't experience a change in its
"envelope" due to reasonable changes in how a compiler internally
represents things, I'm all for it in a product like GCC.

That's not my impression as to how *this* proposed warning is likely to be
implemented.  That's why I'm not in favor of it, along with the fact
that this issue is already taking up far more valuable time on these
lists than it *ever* deserved.

[Joe wrote:]
>Exactly; post violations I've seen are of that type.  I can't aspire to
>the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
>missing this point: a whole lot of the errors we've seen are of this
>extremely simple form, with the entire error appearing in two or three
>adjacent lines of code.  We know the exact offsets of each address and
>can clearly see that they collide.

Let me see if I can explain my concerns here.

If we introduce the proposed new warning in GCC, it will require not
only some significant changes to implement, it *will* require extra
work to maintain.  Forever.  Until the end of time.

That's because the mere *apparent* promise that GCC will warn about
suspicious constructs will be enough to persuade too many people that
they don't need to audit their code, line by line, and fix the problem.

[Joe later wrote:]
>My intent, which may be different from RMS's intent, is to help users
>get rid of this variety of invalid code, not to perpetuate it.

I agree 100%.  I believe this proposed warning will be interpreted by
much of the user base as a reliable indicator of when to turn off
alias analysis rather than of when to fix their code, based on how
this issue has been treated in these discussions.

So those people will rely on GCC holding their hands.  Most of the time
it might be correct.  Too often, it will be wrong.  We will blamed
when it is, just as we've been blamed *already* for providing a *correct*
compiler with a *simple* workaround for buggy code.

Remember, some of you have already been seriously considering having
the mere *warning* trigger a *different* code-generation strategy.
Why?

I think the answer is pretty clear -- it's because you already know,
deep, down inside, that the real agenda here is to make it easy for
people who think GCC really *should* support their alias-concern-free
variant of the C language to continue to write code *their* way.
Then they'll just ignore, or filter out, the warnings.  (If the FAQ
could say "don't do that", then it could just as well say "use
-fno-strict-aliasing".  Hey!!  It already does!  Then why are we
having this discussion, if we are going to assume people will read
the docs?)

If that's not the case, then please end all discussion of the warning
turning off aliasing.  That's no more sensible than having the
uninitialized-variable warning triggering the automatic bzero-ing of
the stack frame upon entry to every procedure, along with all sorts
of other "friendly" things for warnings to do.

Now, I already *know* all the counterarguments to this concern.

But every one of them can be applied to the *current* situation,
where we have *no* warnings, -fstrict-aliasing is the default,
and users have the -fno-strict-aliasing option:

  -  "We can tell people not to rely on the warnings, or lack thereof,
      as any sort of substitute for fixing their code."

     Oh sure, tell them to read the docs.  Sorry: that didn't work
     in the first place to get them to write ANSI/ISO-conforming
     code *or* to get them to use -fno-strict-aliasing.  If you think
     they'll go away just because a new warning appears, please
     cite your evidence for that tactic working under similar
     circumstances -- I'd love to see it.  (Having worked on g77,
     which has a *far* more forgiving audience, in this sense, than
     gcc, I know firsthand how new warnings are received, no matter
     how well they're documented.  They're no panacea.  And I suggest
     the g77 warnings I'm thinking of are, and have generally been,
     *vastly* better documented than GCC warnings -- so if you think
     you're going to avoid a substantial number of complaints and real
     problems with this warning, you'll have to document it better
     than g77 documents any of *its* warnings, IMO.)

  -  "It's important to catch *all* the possible problems somehow,
     so as to avoid generating bad code."

     Not only is the warning idea going to *fail* at that, there's
     *already* -fno-strict-aliasing.  That is the most reliable
     method we're going to ever offer.  Period.

  -  "We're just trying to address certain common cases that occur
     within only a few lines of code, not get at all the problems
     at once."

     A much more reasonable stance.  I suggest someone write a few
     lines of Perl, Scheme, or some such thing to do the job.  Please
     leave it out of GCC internals, though it could be shipped with GCC.

  -  "But people expect GCC to do all these things for them."

     It can't and won't, so we should pick and choose the things it'll
     do best.  That Perl/Scheme script?  Using the time/energy spent
     conducting pro-munging-GCC campaigns on these lists, I'm sure
     a "clever programmer" or two could not only have written it,
     but tested it *and* distributed it, perhaps two or three versions
     by now.

     What the C community needs is a tool to find this particularly
     gnarly problem.  It should view it as a use-once-and-fix-thereby
     tool.  Fixing this problem is like fixing the Y2K problem.  Do
     it once, and do it right.  Putting the same functionality in
     GCC suggests more of an ad-hoc approach to deciding whether to
     tolerate, fix, or ignore the problem.

     And the users who supposedly need this solution *now* could get it
     *now* if you'd (whoever you are) just go and write it, distribute
     it, and not make them wait (even longer) for GCC 3.0.  (Longer
     because of the time it'll take to add, document, and write test
     cases for this new warning.  And what happens when, one month
     before scheduled release, someone notices that the warning doesn't
     work right on *one* platform, like the uninitialized-variable
     warning awhile ago on Alphas?  Do we delay the release to fix
     this warning, which is supposedly so crucial we've spent all this
     time discussing and installing it, or blow off the importance of
     helping those poor, confused C programmers on a major platform?)

  -  "It's much easier to change GCC to warn about this than to write
     a new script, especially when it comes to certain cases."

     I suggest that if a simple script can't catch the problem, a GCC
     warning, even if it worked, wouldn't help users catch the problem
     any more than they're helped now using -fno-strict-analysis.  (That
     is, such users have *already* claimed they're not going to fix
     code where the problem is strewn throughout.  I'm thinking of Linux
     here.  And whatever the Linux cognescenti decide, many thousands
     of programmers will surely do as well.  In that sense, Linus and
     David Miller have given us tremendously valuable input -- a preview
     of what, say, 1000 programmers will be screaming at us about one
     year after Merced, or McKinley, comes out.)

     But, if you like, snarf a copy of GCC, strip out all the code
     generation, and add the patch you think is so easy to warn
     about the problem.  Make it a separate product, on its own
     release schedule.  Same reasons as above.

     In other words, have GCC distribute not only cc1, protoize, and
     unprotoize, but findalias as well.

  -  "But the proposed warning won't make GCC much more complex."

     Perhaps not, but every little addition like this requires all *future*
     maintainers of GCC to cope with that much more state, that much
     more complexity, and, most difficult for new, enthusiastic
     developers to cope with, more "quiet expectation" that the "envelope"
     of the warning (the circumstances under which it is and is not
     issued) will never change or, at least, will only "get better".
     With *this* proposed warning, I think that's going to be particularly
     challenging, based on the discussions of the technical aspects of
     it.

The wording Joe used earlier, "the mode of treating the user like
an opponent", bothered me because it implied that any refusal to
add new "features" constituted opposing users.

That is probably not what Joe intended, but, let me say, the willingness
to add any new feature asked for by users *can* constitute opposing
the ability of your "e-descendants" to continue to maintain the
product as a going concern.

So, while a warning (that has no effect on code generation) *might* be
a good idea, I tend to think that, in this case, it is not, based on
a rather quick reading of the original (recent) proposal.

As back-up to my positions, I suggest readers review archives (wish
they could do so of the gcc2 postings I remember from years back)
vis-a-vis complaints and hassles when much simpler (conceptually)
warnings didn't behave as expected, such as uninitialized-variable
warnings; and vis-a-vis claims about how GCC should cater to "clever
programmers" (their own words) by providing essentially endless,
detailed control over every aspect of code generation, even if doing
so is at the expense of delivering a robust, high-performance,
predictable compiler for "non-clever" programmers who actually
follow the standards, read the documentation, and rely on much more
than "well, it always worked that way before" to justify their
requests.

In the end, it's a question of what kind of users we want to cater to.
I've found it much easier to cater to people who "read the directions",
so to speak, than those who ride by the seat of their pants.  YMMV,
but it should be easy to see why catering directly to the former
allows the latter to continue to operate however they like -- catering
to the latter makes the product worse for direction-followers and
only encourages the direction-ignorers to take even more risks.  (Which
was the point I was trying to make with my previous post containing
the shell script -- exactly the sort of thing a "clever programmer"
would invent *and* expect to always work.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    While I have some sympathy for that point of view, the reason that
    the type aliasing rules were added was to give scientific programmers
    what they were asking for: C that runs about as fast as Fortran.

We should certainly make of these rules to generate faster code.  But
while we do this, we can still look for ways to keep old code working
right--when we find ways to do this with little pain and little cost.

    I don't want to break users' code when we can TELL what they mean,
    and many examples seem to fall into that category.  But where we
    can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias)
    or not (-fno-strict-alias).

When we can't easily tell "what was meant", I think we should take
advantage of the ISO rules, and carry out the optimizations that are
possible.

    In the end, if your argument is carried too far, the only solution
    would be to make -fno-strict-alias the default.

The whole point of this idea is that we don't try to carry the idea
too far--just a certain amount.  What we need here is moderation; we
need to find the balance between the various goals that matter to the
users.

Re: type based aliasing again

[Mark Mitchell]

Someone (not RMS, but I have lost track of who, originally) wrote:

    In the end, if your argument is carried too far, the
    only solution would be to make -fno-strict-alias the
    default.

I think that making -fno-strict-aliasing the default is sensible
proposal, and worth debating.

Whether or not it is the default should be based on a variety of
considerations, including how many programs are "broken" by the more
correct behavior, how many of those can and will be easily fixed, and
how many are actively maintained.

For example, the Linux kernel is not a good reason to change the
default; it is easy for this actively maintained project to simply add
-fno-strict-aliasing to their Makefiles, if appropriate.  But, if it
is true that most, or at least a lot, of programs do not follow the
ISO rules, then it may be that we have set the default incorrectly.
In my experience, there are not too many such programs; I have only
seen one such cases in our customer's code, and that was very easily
fixed.  However, I make no claim that this code base is reprsentative
of things compiled with GCC.

I would much rather see us change the default, if that is really
necessary, than muddy the waters with confusing semantics, semantics
that will change due to minor adjustments to the compiler.  Yes, this
would mean that users cannot have their cake and eat it too: they
cannot have the benefits of -fstrict-alaising and still not follow the
ISO rules.  But, they are no worse off than before we added the
aliasing optimizations.

The best strategy at this point, in my opinion, would be for someone
to implement the warning.  (Note that this is non-trivial.)  Then, we
can get some idea as to how much code is breaking the rules, and then
judge whether or not he default is correct.  We must also weigh the
risk that people will not fix the code, unless we break it, and that
we will therefore never be able to make -fstrict-aliasing the default.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> I think that making -fno-strict-aliasing the default is sensible
Mark> proposal, and worth debating.

Mark> I would much rather see us change the default, if that is really
Mark> necessary, than muddy the waters with confusing semantics, semantics
Mark> that will change due to minor adjustments to the compiler.  Yes, this
Mark> would mean that users cannot have their cake and eat it too: they
Mark> cannot have the benefits of -fstrict-alaising and still not follow the
Mark> ISO rules.  But, they are no worse off than before we added the
Mark> aliasing optimizations.

	FYI, IBM's AIX compiler does not enable "ANSI aliasing" by default
when the compiler is invoked with "cc".  AIX "cc" essentially is "gcc
-fno-strict-alias -fwriteable-strings"; AIX "xlc" command enables alias
optimizations and creates read-only constants.

David

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	FYI, IBM's AIX compiler does not enable "ANSI
    David> aliasing" by default when the compiler is invoked with
    David> "cc".  AIX "cc" essentially is "gcc -fno-strict-alias
    David> -fwriteable-strings"; AIX "xlc" command enables alias
    David> optimizations and creates read-only constants.

Someone reported something similar for the DEC copmiler; `cc' is
-fno-strict-aliasing, while some more progressive-sounding compiler
name is -fstrict-aliasing.

One thing important about these data points, though, is that major
vendors must be finding that not too many programs use the invalid
constructs in question.  Otherwise, they would not have dared to
enable these options.  (Of course, they could have the kind of
behavior Joe and RMS are suggesting, I suppose.  And their code-bases
may be different than GCC's.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Sudish Joseph]

Mark Mitchell writes:
> Someone reported something similar for the DEC copmiler; `cc' is
> -fno-strict-aliasing, while some more progressive-sounding compiler
> name is -fstrict-aliasing.

Yes, but more so. :-)  DEC cc doesn't enable its -ansi_aliases flag
implicitly unless you specify either -std1, thus stating that your
code is completely standards compliant, or -fast, thus asking for
extremely aggressive optimizations.

In particular, -ansi_alias isn't automatically enabled for any `n' in
-On.  The user must specify -std1, -fast, or -ansi_alias.

Here're some more excerpts from the DU 4.0D cc (V5.9-005) man page.
(I re-filled the paragraphs to fit, so you'll see some mid-line
hyphenation.)

-fast also implies -O3 in addition to what's listed below.

------------------------------------------------------------
  -std1
      Selects the strict ANSI language mode. Strictly enforces the
      ANSI C standard and all its prohibitions (such as those that
      apply to the han- dling of void types, the definition of lvalues
      in expressions, the mix- ing of integrals and pointers, and the
      modification of rvalues).

      This option does not restrict the Tru64 UNIX name space (for
      example, the names defined in system header files).  To restrict
      that name space so that only ANSI C reserved names are visible
      from the ANSI C header files, use the _ANSI_C_SOURCE macro. See
      standards(5) for more details.  This option causes the macro
      __STDC_ to be defined to 1. Note that this option also affects
      linker-defined symbols.  See ld(1) for more infor- mation.

      This option turns on ANSI aliasing rules (-ansi_alias option).

[...]

-O[n]
      Determines the level of optimization. The following table lists the
      types of optimizations that can be performed at each level:

      ---------------------------------------------------------------
      Level                 Optimization
      ---------------------------------------------------------------
      -O0                   None
      -O1                   Local optimizations and recognition of
                            common subexpressions. Global
                            optimizations, including code motion,
                            strength reduction and test replacement,
                            split lifetime analysis, and code
                            scheduling.
      -O2, -O               Inline expansion of static procedures. 
                            Additional global optimizations that
                            improve speed (at the cost of extra code
                            size), such as integer multiplication and
                            division expansion (using shifts), loop
                            unrolling, and code replication to
                            eliminate branches.
      -O3                   Inline expansion of global procedures.
      -O4                   Software pipelining using dependency
                            analysis, vector- ization of some loops on
                            8-bit and 16-bit data (char and short),
                            and insertion of NOP instructions to
                            improve scheduling.
      ---------------------------------------------------------------

      If your application will be built into a shared library, avoid
      using the -O3 and -O4 options, because these levels may inhibit
      the ability to preempt symbols. Also, benchmarking is
      recommended to determine if -O4 is better than -O3 for your
      particular application, as this is not always true.

[...]

 -fast
      Provides a single method for turning on a collection of
      optimizations for increased performance.

      Note that the -fast option can produce different results for
      floating- point arithmetic and math functions, although most
      programs are not sensitive to these differences.

      The -fast option defines the following compiler options and
      symbols to improve run-time performance. You can adjust the
      optimizations by spec- ifying the negation of any given option.

      -ansi_alias
          Directs the compiler to assume the ANSI C aliasing rules,
          and thus allows the optimizer to be more aggressive in its
          optimizations.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -ansi_args
          Tells the compiler that the source code follows all ANSI
          rules about arguments; that is, whether the type of an
          argument matches the type of the parameter in the called
          function, or whether a function prototype is present so the
          compiler can automatically perform the expected type
          conversion.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -assume nomath_errno
          Allows the compiler to reorder or combine computations to
          improve the performance of those math functions that it
          recognizes as intrinsic functions.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -assume trusted_short_alignment
          Specifies that any short accessed through a pointer is
          naturally aligned.  This generates the fastest code, but can
          silently gener- ate the wrong results if any of the short
          objects cross a quadword boundary.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -D_INTRINSICS
          This option affects the compilation of a number of system
          header files, causing them to compile #pragma intrinsic
          directives for certain functions that they declare.  The
          exact functions affected may vary depending on the language
          mode and other macro defini- tions.  See the header files
          math.h, stdio.h, stdlib.h, string.h, and strings.h for
          details. The exact effect of each #pragma intrin- sic varies
          by function, by optimization options, and by other com-
          pile-time options.  The basic effect is to inform the
          compiler that the function specified in the pragma is the
          one by that name whose behavior is known to the compiler
          (that is, it is a standard C or commonly-used library
          function rather than a user-written external function).
          This gives the compiler license to perform additional checks
          on the usage of the function and issue diagnostics, and to
          optimize and/or rewrite calls to it based on the compiler's
          under- standing of what the function does.  Some possible
          optimizations include generating complete inline code,
          generating partial inline code with calls to one or more
          different functions, or just using characteristics of the
          function to move the call site or avoid some of the overhead
          triggered by an external call.

      -D_INLINE_INTRINSICS
          This option affects the compilation of stdio.h in two ways:

            o  Whenever the header file would otherwise define getc
               and putc as preprocessor macros expanding into code to
               access the _cnt and _ptr members of the referenced FILE
               object directly, instead these macros are defined to
               invoke inlined static functions defined in the header
               file. The use of an inlined static function instead of
               a simple macro prevents the argu- ment from being
               evaluated more than once (so arguments con- taining
               side effects do not cause a problem), and the function
               generally will produce better code because it uses
               local dec- larations to avoid aliasing assumptions that
               the compiler has to make when analyzing the traditional
               macro expansions of getc and putc.  Note that getc and
               putc are not expanded inline when i/o locking is
               required, as is normally the case for reentrant or
               thread-safe compilations.

            o  If -D_INTRINSICS was also specified, making printf and
               fprintf intrinsic functions, then certain of the
               low-level runtime support routines that may be called
               for special cases of for- mat strings are defined as
               inline static functions in the header file, avoiding
               external calls to these routines in libc.

      -D_FASTMATH
          Causes the /usr/include/math.h file to redefine the names of
          cer- tain common math routines, including sqrt and exp, so
          that faster but slightly less accurate functions are
          used. The fast math rou- tines do not support IEEE
          exceptional behavior.

      -float
          Tells the compiler that it is not necessary to promote
          expressions of type float to type double.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -fp_reorder
          Allows floating-point operations to be reordered during
          optimiza- tion.

          See the description of this option elsewhere in this
          reference page
------------------------------------------------------------

-- 
Sudish Joseph                                          MindSpring Enterprises

Re: type based aliasing again

[Sudish Joseph]

Mark Mitchell writes:
> Someone reported something similar for the DEC copmiler; `cc' is
> -fno-strict-aliasing, while some more progressive-sounding compiler
> name is -fstrict-aliasing.

Yes, but more so. :-)  DEC cc doesn't enable its -ansi_aliases flag
implicitly unless you specify either -std1, thus stating that your
code is completely standards compliant, or -fast, thus asking for
extremely aggressive optimizations.

In particular, -ansi_alias isn't automatically enabled for any `n' in
-On.  The user must specify -std1, -fast, or -ansi_alias.

Here're some more excerpts from the DU 4.0D cc (V5.9-005) man page.
(I re-filled the paragraphs to fit, so you'll see some mid-line
hyphenation.)

-fast also implies -O3 in addition to what's listed below.

------------------------------------------------------------
  -std1
      Selects the strict ANSI language mode. Strictly enforces the
      ANSI C standard and all its prohibitions (such as those that
      apply to the han- dling of void types, the definition of lvalues
      in expressions, the mix- ing of integrals and pointers, and the
      modification of rvalues).

      This option does not restrict the Tru64 UNIX name space (for
      example, the names defined in system header files).  To restrict
      that name space so that only ANSI C reserved names are visible
      from the ANSI C header files, use the _ANSI_C_SOURCE macro. See
      standards(5) for more details.  This option causes the macro
      __STDC_ to be defined to 1. Note that this option also affects
      linker-defined symbols.  See ld(1) for more infor- mation.

      This option turns on ANSI aliasing rules (-ansi_alias option).

[...]

-O[n]
      Determines the level of optimization. The following table lists the
      types of optimizations that can be performed at each level:

      ---------------------------------------------------------------
      Level                 Optimization
      ---------------------------------------------------------------
      -O0                   None
      -O1                   Local optimizations and recognition of
                            common subexpressions. Global
                            optimizations, including code motion,
                            strength reduction and test replacement,
                            split lifetime analysis, and code
                            scheduling.
      -O2, -O               Inline expansion of static procedures. 
                            Additional global optimizations that
                            improve speed (at the cost of extra code
                            size), such as integer multiplication and
                            division expansion (using shifts), loop
                            unrolling, and code replication to
                            eliminate branches.
      -O3                   Inline expansion of global procedures.
      -O4                   Software pipelining using dependency
                            analysis, vector- ization of some loops on
                            8-bit and 16-bit data (char and short),
                            and insertion of NOP instructions to
                            improve scheduling.
      ---------------------------------------------------------------

      If your application will be built into a shared library, avoid
      using the -O3 and -O4 options, because these levels may inhibit
      the ability to preempt symbols. Also, benchmarking is
      recommended to determine if -O4 is better than -O3 for your
      particular application, as this is not always true.

[...]

 -fast
      Provides a single method for turning on a collection of
      optimizations for increased performance.

      Note that the -fast option can produce different results for
      floating- point arithmetic and math functions, although most
      programs are not sensitive to these differences.

      The -fast option defines the following compiler options and
      symbols to improve run-time performance. You can adjust the
      optimizations by spec- ifying the negation of any given option.

      -ansi_alias
          Directs the compiler to assume the ANSI C aliasing rules,
          and thus allows the optimizer to be more aggressive in its
          optimizations.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -ansi_args
          Tells the compiler that the source code follows all ANSI
          rules about arguments; that is, whether the type of an
          argument matches the type of the parameter in the called
          function, or whether a function prototype is present so the
          compiler can automatically perform the expected type
          conversion.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -assume nomath_errno
          Allows the compiler to reorder or combine computations to
          improve the performance of those math functions that it
          recognizes as intrinsic functions.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -assume trusted_short_alignment
          Specifies that any short accessed through a pointer is
          naturally aligned.  This generates the fastest code, but can
          silently gener- ate the wrong results if any of the short
          objects cross a quadword boundary.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -D_INTRINSICS
          This option affects the compilation of a number of system
          header files, causing them to compile #pragma intrinsic
          directives for certain functions that they declare.  The
          exact functions affected may vary depending on the language
          mode and other macro defini- tions.  See the header files
          math.h, stdio.h, stdlib.h, string.h, and strings.h for
          details. The exact effect of each #pragma intrin- sic varies
          by function, by optimization options, and by other com-
          pile-time options.  The basic effect is to inform the
          compiler that the function specified in the pragma is the
          one by that name whose behavior is known to the compiler
          (that is, it is a standard C or commonly-used library
          function rather than a user-written external function).
          This gives the compiler license to perform additional checks
          on the usage of the function and issue diagnostics, and to
          optimize and/or rewrite calls to it based on the compiler's
          under- standing of what the function does.  Some possible
          optimizations include generating complete inline code,
          generating partial inline code with calls to one or more
          different functions, or just using characteristics of the
          function to move the call site or avoid some of the overhead
          triggered by an external call.

      -D_INLINE_INTRINSICS
          This option affects the compilation of stdio.h in two ways:

            o  Whenever the header file would otherwise define getc
               and putc as preprocessor macros expanding into code to
               access the _cnt and _ptr members of the referenced FILE
               object directly, instead these macros are defined to
               invoke inlined static functions defined in the header
               file. The use of an inlined static function instead of
               a simple macro prevents the argu- ment from being
               evaluated more than once (so arguments con- taining
               side effects do not cause a problem), and the function
               generally will produce better code because it uses
               local dec- larations to avoid aliasing assumptions that
               the compiler has to make when analyzing the traditional
               macro expansions of getc and putc.  Note that getc and
               putc are not expanded inline when i/o locking is
               required, as is normally the case for reentrant or
               thread-safe compilations.

            o  If -D_INTRINSICS was also specified, making printf and
               fprintf intrinsic functions, then certain of the
               low-level runtime support routines that may be called
               for special cases of for- mat strings are defined as
               inline static functions in the header file, avoiding
               external calls to these routines in libc.

      -D_FASTMATH
          Causes the /usr/include/math.h file to redefine the names of
          cer- tain common math routines, including sqrt and exp, so
          that faster but slightly less accurate functions are
          used. The fast math rou- tines do not support IEEE
          exceptional behavior.

      -float
          Tells the compiler that it is not necessary to promote
          expressions of type float to type double.

          See the description of this option elsewhere in this
          reference page for more detailed information about this
          operation.

      -fp_reorder
          Allows floating-point operations to be reordered during
          optimiza- tion.

          See the description of this option elsewhere in this
          reference page
------------------------------------------------------------

-- 
Sudish Joseph                                          MindSpring Enterprises

Re: type based aliasing again

[Robert Lipe]

Mark Mitchell wrote:
> >>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
> 
>     David> 	FYI, IBM's AIX compiler does not enable "ANSI
>     David> aliasing" by default when the compiler is invoked with
> 
> Someone reported something similar for the DEC copmiler; `cc' is
> -fno-strict-aliasing, while some more progressive-sounding compiler
> name is -fstrict-aliasing.
> 
> One thing important about these data points, though, is that major
> vendors must be finding that not too many programs use the invalid
> constructs in question.  Otherwise, they would not have dared to
> enable these options.  (Of course, they could have the kind of

The SCO UnixWare (and therefore, UDK) compilers for IA32 do perform this
at high levels of optimization.

The Intel C Compiler performs this optimization, but only if you
explictly add the '-distype' flag.

I can't recall having been bitten by either (I uses the UW compiler much
more than icc) but I don't really know how aggressively either optimizes
this specific construct.  OTOH, the UW compiler frequently generates
better code than GCC so I'm inclined to say if there's an optimization
opportunity it probably grabs it.

RJL

Re: type based aliasing again

[Robert Lipe]

Mark Mitchell wrote:
> >>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
> 
>     David> 	FYI, IBM's AIX compiler does not enable "ANSI
>     David> aliasing" by default when the compiler is invoked with
> 
> Someone reported something similar for the DEC copmiler; `cc' is
> -fno-strict-aliasing, while some more progressive-sounding compiler
> name is -fstrict-aliasing.
> 
> One thing important about these data points, though, is that major
> vendors must be finding that not too many programs use the invalid
> constructs in question.  Otherwise, they would not have dared to
> enable these options.  (Of course, they could have the kind of

The SCO UnixWare (and therefore, UDK) compilers for IA32 do perform this
at high levels of optimization.

The Intel C Compiler performs this optimization, but only if you
explictly add the '-distype' flag.

I can't recall having been bitten by either (I uses the UW compiler much
more than icc) but I don't really know how aggressively either optimizes
this specific construct.  OTOH, the UW compiler frequently generates
better code than GCC so I'm inclined to say if there's an optimization
opportunity it probably grabs it.

RJL

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	FYI, IBM's AIX compiler does not enable "ANSI
    David> aliasing" by default when the compiler is invoked with
    David> "cc".  AIX "cc" essentially is "gcc -fno-strict-alias
    David> -fwriteable-strings"; AIX "xlc" command enables alias
    David> optimizations and creates read-only constants.

Someone reported something similar for the DEC copmiler; `cc' is
-fno-strict-aliasing, while some more progressive-sounding compiler
name is -fstrict-aliasing.

One thing important about these data points, though, is that major
vendors must be finding that not too many programs use the invalid
constructs in question.  Otherwise, they would not have dared to
enable these options.  (Of course, they could have the kind of
behavior Joe and RMS are suggesting, I suppose.  And their code-bases
may be different than GCC's.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Stallman]

Changing the default to -fno-strict-aliasing would certainly solve the
immediate problem.  If people are happy with that, as a more or less
permanent decision, I think it avoids most of the need to do anything
else.  (An added warning might be desirable, though, even with
-fno-strict-aliasing.)

The importance of considering option #3 goes beyond this particular
issue.  Other issues will arise where optimization runs over old code
that people use.  Option #3 is not guaranteed to be workable for
all these other issues, but it will be workable for some of them.

So even if we deal with this issue in a different way, and that makes
option #3 unnecessary here, we should keep it in mind for the future.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
  > Changing the default to -fno-strict-aliasing would certainly solve the
  > immediate problem.  If people are happy with that, as a more or less
  > permanent decision, I think it avoids most of the need to do anything
  > else.  (An added warning might be desirable, though, even with
  > -fno-strict-aliasing.)
I strongly feel this is the wrong approach.

It penalizes those programmers who write correct code to cater to the
programmers that do not write correct code.  That to me is short sighted and
counter-productive.

jeff

Re: type based aliasing again

[Nick Ing-Simmons]

Jeffrey A Law <law@cygnus.com> writes:
>  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
>  > Changing the default to -fno-strict-aliasing would certainly solve the
>  > immediate problem.  If people are happy with that, as a more or less
>  > permanent decision, I think it avoids most of the need to do anything
>  > else.  (An added warning might be desirable, though, even with
>  > -fno-strict-aliasing.)
>I strongly feel this is the wrong approach.
>
>It penalizes those programmers who write correct code to cater to the
>programmers that do not write correct code.  

No, it allows _programmers_ that know what they are doing to get the 
benefit of their knowledge by the simple expedient of adding -fstrict-aliasing
to Makefile.in and forgetting about it.

While protecting sys-admins and users of open-source products that just 
build but do not write them from the bad habits that not-so-good/or
too-clever-for-their-own-good programmers have developed over the decades.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909151501.QAA26239@tiuk.ti.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > >  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
  > >  > Changing the default to -fno-strict-aliasing would certainly solve the
  > >  > immediate problem.  If people are happy with that, as a more or less
  > >  > permanent decision, I think it avoids most of the need to do anything
  > >  > else.  (An added warning might be desirable, though, even with
  > >  > -fno-strict-aliasing.)
  > >I strongly feel this is the wrong approach.
  > >
  > >It penalizes those programmers who write correct code to cater to the
  > >programmers that do not write correct code.  
  > 
  > No, it allows _programmers_ that know what they are doing to get the 
  > benefit of their knowledge by the simple expedient of adding -fstrict-alias
  > ing
  > to Makefile.in and forgetting about it.
  > 
  > While protecting sys-admins and users of open-source products that just 
  > build but do not write them from the bad habits that not-so-good/or
  > too-clever-for-their-own-good programmers have developed over the decades.
So are you going to propose next that we turn off automatic register allocation
because some programmers don't have enough of a clue to write correct code?
(yes, automatic register allocation will cause programs to behave in an
unexpected manner if the programmer does stupid things like not initializing
automatics, or not using volatile for variables live across setjmp).

Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
clueless programmer violated the assumptions for that optimization?

Hell, while you're at it, you might as well turn off any optimization that
might have a bug.

jeff

Re: type based aliasing again

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> So are you going to propose next that we turn off automatic register allocation
Jeff> because some programmers don't have enough of a clue to write correct code?
Jeff> (yes, automatic register allocation will cause programs to behave in an
Jeff> unexpected manner if the programmer does stupid things like not initializing
Jeff> automatics, or not using volatile for variables live across setjmp).

Jeff> Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
Jeff> clueless programmer violated the assumptions for that optimization?

Jeff> Hell, while you're at it, you might as well turn off any optimization that
Jeff> might have a bug.

	This is arguing by generalization and generalizing to the
extreme.  Different cases require different analysis and consideration.

David

Re: type based aliasing again

[craig]

>	This is arguing by generalization and generalizing to the
>extreme.  Different cases require different analysis and consideration.

So we can conclude that the expense (time and effort) needed to
address this *one* issue is:

  -  representative of what we're likely to expend over similar issues
     that *will* arise

  -  unlikely to serve as a boilerplate for analysis and consideration
     over those issues, sufficient that it significantly reduces the
     resources needed to analyse them

  -  not going to ameliorate problems users have compiling arbitrary
     C code off the 'net using GCC, since we'll likely come to different
     decisions than always defaulting to -fno-strict-analysis, even if
     we decide to do that now

  -  not going to serve too well in re-assessing whatever decision we
     make (*especially* one to change the default to -fno-...) in
     the future, since the future will hold all sorts of new
     information, thus leading to "different analysis and consideration"

Therefore, as I said near the very beginning of this most recent 'fest,
we shouldn't waste any time discussing issues like this.  Period.  We
should invoke the simplifying assumption that code which is violates
ISO C conformance rules is not worth bothering about.  That'll save
tons of resources (especially avoiding lots of wasted discussion) right
there.

Further, I realized, last night, that hoping that code needing this
special consideration will have finally been mothballed by the time
the default *has* to be changed (no question, no discussion worth
having) to accommodate Merced or McKinley amounts to entertaining
the same hopes, and therefore similar scaling of costs, as the
Y2K problem.  Most programmers who put Y2K bugs into code probably
just *knew* their code would be mothballed by 1995 or so anyway....

So people can either fix their code now, or fix it later.

Which is going to be more expensive for the industry as a whole?

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    So we can conclude that the expense (time and effort) needed to
    address this *one* issue is:

      -  representative of what we're likely to expend over similar issues
	 that *will* arise

If subsequent issues are like this one, finding a way to improve the
situatin will be fairly easy, but persuading certain people to accept
an improvement may be difficult.

But if people accept the principle of making small and easy efforts to
keep old code working, subsequent issues will only involve the
comparatively easy job of figuring out how to do that.

In effect, your argument is that this proposal is a bad idea because
Craig Burley and others will spend time arguing against it.  I do not
think that the proposal can be held responsible for that ;-).

    So people can either fix their code now, or fix it later.

I notice a pattern that people arguing against concern for the users
tend to exaggerate the situation in this particular way: they change
"some of this code may break, may need to be changed" into "all of
this code will break, will need to be changed."

    having) to accommodate Merced or McKinley amounts to entertaining
    the same hopes, and therefore similar scaling of costs, as the
    Y2K problem.

Compilers did not give warnings for Y2K problems, but we will
make GCC give a warning for most of these problems.  So these situations
are hardly similar.

Re: type based aliasing again

[craig]

>But if people accept the principle of making small and easy efforts to
>keep old code working, subsequent issues will only involve the
>comparatively easy job of figuring out how to do that.

Yes, having made this decision in *this* direction tempts one to
believe future decisions will be made more easily.  For all intents
and purposes, that's not true -- this decision was probably *well*
within the bounds set by many prior decisions to make similar, or
even more justifiable, accommodations, yet the discussion ensued
regardless.  (I can't think of any such decisions that ultimately
went the other way, offhand.  So those of us arguing against
the accommodations have been, in effect, trying to reign in this
historical willingness to make them.)

I believe that's because not all of us agree on the importance of
having GCC capable of strictly conforming to standards; the importance
of it doing so in a bug-free manner; and the degree to which doing
so should be the default behavior of GCC, versus defaulting to
dialectal/historical behaviors.  (There are other factors, like
short memories, but it seems like most of those objecting to the
accommodating proposals have demonstrated both better understanding
of what ISO C actually says *and* long-term memories of GCC developments
and discussions in the past, as compared to those calling for GCC to
make the proposed accommodations.)

So I don't see how accepting "the principle of making small and
easy efforts to keep old code working" simplifies things substantially.
(Particularly revealing is that I, myself, probably would have been
much more willing to accept it in this case a few years ago -- which
indicates the possibility that others might change their views as
they, as I have, continue to try and maintain a complicated product
in an ever-changing environment while coping with all sorts of demands
from users.)

Being a *strong* enthusiast for the *concept* of some accommodations
(the engineering concept of tolerance, which gave us CDs with well
over 74 minutes of music), I nevertheless accept that, for N individuals
working on a project, there will be, at any given time, N definitions
of "small", N of "easy", and N of "old code" (as versus "broken code").

The reason I increasingly promote the idea of taking the public,
and the default internal, stance of serving up ISO C and not a jot
more, in some manner (e.g. no discussion of adding non-ISO-C accommodations;
but a patch that plainly simplifies the ISO-C code-paths of GCC,
and *happens* to include code that can make such accommodations,
is not ruled out on that basis), is that, among those same N people,
there are likely to be far *fewer* than N definitions of "ISO C",
especially as it applies to any given construct, such as this
one.

Sure enough, nearly everyone gave different criteria and/or indicated
different "decision envelopes", including: make GCC more actively break
broken aliasing code; drop -fno-alias-analysis; status quo; warn when
trivially detectable; warn when sophisticatedly detectable; make
GCC more actively support broken aliasing code out of the box;
make GCC always default to supporting it; etc.  (Yes, I probably made
at least two or three of these myself.  ;-)

Yet almost everyone made the *same* judgement about whether the code,
itself, was broken.  I believe all the active GCC developers, especially
core developers, said "yes" or abstained from the discussion, anyway.

Now *that's* a simplifying assumption: work to a standard most people
are likely to understand and agree on.  (I still accept that ISO C
isn't ideal as a standard, but it's better than anything else we have
for a C-like language, AFAIK.)

In other words, I believe I can more reliably predict how Mark Mitchell
and Craig Burley (in the latter case, independent of the fact that I
am he *now*; I'm speaking objectively hear), among the few others
campaigning for no accommodation citing ISO C, will assess most *future*
requests for similar accommodations.

But I cannot predict how you or many others will assess those, because
your "simple"/"easy"/"old" variables are just too fuzzily defined.

So what we'll learn from future discussions is how those variables
are defined for pro-accommodation people at that moment, for the
issue de jure, even assuming nobody actually *changes* their particular
variables (i.e. they're constants, just fuzzily defined to the
outside world).  Whereas we basically already *know* these constants
for the anti-accommodation people.  (Who knows, maybe we already
knew those of *others*, who have not participated, from past
discussions.)

If you haven't done a thorough analysis of the efforts needed to discuss
this issue now and in the past, I suggest you do one, or, better yet,
hire an experienced consultant from the management-efficiency field
(or whatever they're calling it these days) to do so.

Then put up the results here for us to discuss, to encourage us all
to ask the question "is this amount of effort appropriate for
an issue like this?", as well as "could this effort have been
better directed towards other, more core, issues regarding GCC?"

That involves substantial time and effort, of course, but result
*could* be a *huge* improvement in reducing the time and effort
taken to discuss issues like this.  (Whether it'll convince more
or less of the anti-accommodation crowd than the pro-accommodation
crowd doesn't really matter, as long as the data being presented
was honestly collected and presented.)

>In effect, your argument is that this proposal is a bad idea because
>Craig Burley and others will spend time arguing against it.  I do not
>think that the proposal can be held responsible for that ;-).

If you view it that way, especially as a spokesman for the GNU project,
which controls GCC, you are saying that the only real cost, in terms
of added complexity, to being willing to consider changing the compiler
to better accommodate broken code is that there will be some people
who openly disagree with that policy and/or with the specifics of
the proposal.  (Assuming my argument is correct, of course...which it
is, since I made it.  ;-)

In effect, you are telling me that if I don't want GCC to become even
more complicated and hard to maintain than necessary, or have bugs fixed
in it less speedily due to long-drawn-out discussions like this, I should
no longer participate in discussions like this, except perhaps to
grunt things like "okay by me" or "no way".

That's certainly something I've considered, so having the GNU project
leader basically tell it to me outright simplifies *my* world -- I
no longer need to make an assessment *myself* as to how valuable
my input *might* be considered to keep GCC simple, maintainable, and
to increase its quality.  In a sense, your statement takes on the
role of the ISO C standard vis-a-vis this discussion, and I obediently
follow it, so I certainly appreciate the argument for simplicity you
are making.

However, I will point out that you have effectively told not just me,
but several others, the same thing.

If they interpret your statement the same way as I do, and thus avoid
objecting to future requests for accommodations in GCC, someday the
day will come when lots of users, not yet weaned from depending on
GCC as some sort of "free-software install tool", demand things of GCC
that even *you* wish to not (or cannot) accommodate.

At that point, you might find it suddenly very difficult to gain support
for your unwillingness to accommodate those demands, and, I predict,
find it similarly difficult to find people enthusiastic about doing
what is necessary to meet them (since a larger percentage of GCC users
will be of the unweaned variety, thus not really capable of improving
GCC themselves, than if we were to have drawn the line in the sand *here*
and *now*).

And a big part of the reason I've participated so forcefully in
this discussion is that there have been quite a number of statements
made that are either incorrect in fact or incomplete in portraying
cost/benefit analyses vis-a-vis this issue.  Since *most* of those
statements have been made to promote accommodation, I've leaned
towards no accommodation (or at least presenting myself as such).

That is, as I'm sure Linux developers will attest from *their* experiences
(based on my impressions), the risk of submitting a request for
coming to an agreement, rather than submitting a patch to implement
it, of course.  ;-)

>    So people can either fix their code now, or fix it later.
>
>I notice a pattern that people arguing against concern for the users
>tend to exaggerate the situation in this particular way: they change
>"some of this code may break, may need to be changed" into "all of
>this code will break, will need to be changed."

I didn't say that.  But, for the purposes of assessing these issues,
that's how people maintaining their code should *think*.  (Ever hear
of Murphy's Law?)

In particular, nobody (but hackers) using GCC should seriously entertain
*any* hopes that GCC will manage to accommodate bugs hiding in their
code, when it comes to assessing the long-term viability of their project,
even though they might recognize (as most of us do) how the practicalities
of compiler engineering make it *unlikely* certain bugs will be exposed
over a certain lifetime.

(And hackers shouldn't care what GCC does in the long haul, as I pointed
out earlier.)

Programmers should view bugs in their code like termites.  It doesn't
matter that, within one square mile of their home, billions of termites
will *never* contribute to the downfall of that home.  What *does* matter
is that there are probably enough to bring it down, and that there's
no way, ahead of time, to predict exactly which ones will, and which
ones won't.  All one can do is make educated guesses, and use those
to best direct one's efforts towards eradicating "suspect" termites.

But if one wishes the home to not fall, one either does not build it out of
wood in the first place or adopts a zero-tolerance approach to termites
(meaning constant watchfulness, for example, or locating one's home
in a climate that has no termites).

That way, one does not blame one's friend for happening to let in
*the* termites that finally brought down the home when he was feeding
the pets during one's vacation.  Nor does one waste even two minutes
trying to convince his friends that *they* must become termite-free,
despite their having chosen to live in more secure dwellings themselves,
because that's two minutes that could have been spent fighting the
termites in or very near the home.

>    having) to accommodate Merced or McKinley amounts to entertaining
>    the same hopes, and therefore similar scaling of costs, as the
>    Y2K problem.
>
>Compilers did not give warnings for Y2K problems, but we will
>make GCC give a warning for most of these problems.  So these situations
>are hardly similar.

Compiles *have* given warnings for Y2K problems.  g77 surely does, as
of EGCS 1.1 IIRC.  And, I've heard proprietary compilers (like Compaq's,
formerly Digital's) do quite a bit more in that direction than g77,
though I haven't researched the issue further than to figure out
what g77 could easily do.

But that wasn't my point, anyway.  What these situations *do* share
*is* related to my point: in both cases, no automaton can reliably warn
about all instances of the problem.  So there's no silver bullet other than
programmers fixing their code or *knowing* (not just hoping, guessing,
pretending, etc.) that their programs will be mothballed before the
bug wall hits.  (For Y2K, that's usually around 2000-01-01.  For this bug,
that's probably Merced or McKinley on desktops in quantities of a few
million or so.)

From the point of view of the free-software industry, the analysis
includes considering the risk of losing expertise over time as
the bug-wall approaches versus the opportunity to not be hit by
it at all due to mothballing.

But, I believe the analysis for GCC *itself* is *much* simpler:
conform to the pertinent ANSI/ISO standards, etc.

(People designing new languages and environments -- like Guile, GNOME,
KDE, and so on -- are the ones especially needing to evaluate the
larger context in which their *designs* will be used, since long-term
acceptance of them depends on the *aggregate* usability, reliability,
etc. of systems built on them.  The advantages of using off-the-shelf
languages and environments like ISO C and POSIX include not having
to bother with such evaluations; the dangers include thinking one
can get away with "mini-evaluations" for extensions and accommodations
outside of those specified for, and by, off-the-shelf components.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

You have written a long message, as you often do.  It contains a
number of points that I disagree with, but I don't have time to
respond to them all.  So I have chosen the few that seem most
important.

    >I notice a pattern that people arguing against concern for the users
    >tend to exaggerate the situation in this particular way: they change
    >"some of this code may break, may need to be changed" into "all of
    >this code will break, will need to be changed."

    I didn't say that.  But, for the purposes of assessing these issues,
    that's how people maintaining their code should *think*.

It is a mistake to judge everything by worst-case costs instead of
likely costs.  That leads to decisions that increase the expected
costs.  In situations like this, it leads to a pattern of skewed
judgement, consistently being too harsh to users.

I wonder if some of the other people who have argued for harshness on
this issue are also making a conscious assumption of calculating costs
based on the worst case for kindness.  They are not assuming the worst
case for harshness!

    >In effect, your argument is that this proposal is a bad idea because
    >Craig Burley and others will spend time arguing against it.  I do not
    >think that the proposal can be held responsible for that ;-).

    If you view it that way, especially as a spokesman for the GNU project,
    which controls GCC, you are saying that the only real cost, in terms
    of added complexity, to being willing to consider changing the compiler
    to better accommodate broken code is that there will be some people
    who openly disagree with that policy and/or with the specifics of
    the proposal.

Yes.  Once people accept the principle of doing this kind of
accommodation, actually doing it will be easy.  The idea is that you
only spend a limited amount of time looking for a solution, and only
do something if you find an easy way.  This always has to be easy.

The only thing that is hard is when people argue, as you are doing,
against the very idea of accommodation.  So please don't do that.

    In effect, you are telling me that if I don't want GCC to become even
    more complicated and hard to maintain than necessary, or have bugs fixed
    in it less speedily due to long-drawn-out discussions like this, I should
    no longer participate in discussions like this, except perhaps to
    grunt things like "okay by me" or "no way".

Those thoughts are yours, not mine.  I am just asking you and others
to stop arguing for a policy of harshness toward the user--to stop
arguing against the very idea of trying to accommodate old undefined
code.

If you don't want GCC to be more complicated or for the work to go
slower, then you share my feelings on that issue.  That's why I looked
for a simple change that is clearly correct and will be easy to
implement.  In the future, I would like the GCC developers to look for
such changes, because this is what the GNU Project needs GCC to do.

    this discussion is that there have been quite a number of statements
    made that are either incorrect in fact or incomplete in portraying
    cost/benefit analyses vis-a-vis this issue.  Since *most* of those
    statements have been made to promote accommodation, 

I have seen a regular pattern of exaggeration in the messages arguing
for harshness.  The worst always can happen, but it is very unlikely
to happen always.

    Programmers should view bugs in their code like termites.

I think you are partly right, but not entirely, because you are
demanding a strictness that is more trouble that it's worth for many
projects, and is also more work than most free software developers can
manage to do.  Fortunately, a somewhat more relaxed approach works
pretty well.

Be that as it may, that question is a side issue.  You are talking
about programmers running GCC on code that they are developing.  Those
are just some of the users of GCC.  Only some of the people running
GCC are running it on code they understand, or could attempt to debug.

We must not make GCC decisions with only those people in mind.

    But, I believe the analysis for GCC *itself* is *much* simpler:
    conform to the pertinent ANSI/ISO standards, etc.

GCC does conform to these standards, when used with the proper set of
options.  However, technical standards are not a moral authority.  The
GNU Project policy is that we pay close attention to official
standards, but we don't slavishly obey them.

In this case, the issue is not even whether GCC complies with the C
standard.  It concerns the behavior of GCC in a case which the C
standard does not specify.

Re: type based aliasing again

[Richard Stallman]

You have written a long message, as you often do.  It contains a
number of points that I disagree with, but I don't have time to
respond to them all.  So I have chosen the few that seem most
important.

    >I notice a pattern that people arguing against concern for the users
    >tend to exaggerate the situation in this particular way: they change
    >"some of this code may break, may need to be changed" into "all of
    >this code will break, will need to be changed."

    I didn't say that.  But, for the purposes of assessing these issues,
    that's how people maintaining their code should *think*.

It is a mistake to judge everything by worst-case costs instead of
likely costs.  That leads to decisions that increase the expected
costs.  In situations like this, it leads to a pattern of skewed
judgement, consistently being too harsh to users.

I wonder if some of the other people who have argued for harshness on
this issue are also making a conscious assumption of calculating costs
based on the worst case for kindness.  They are not assuming the worst
case for harshness!

    >In effect, your argument is that this proposal is a bad idea because
    >Craig Burley and others will spend time arguing against it.  I do not
    >think that the proposal can be held responsible for that ;-).

    If you view it that way, especially as a spokesman for the GNU project,
    which controls GCC, you are saying that the only real cost, in terms
    of added complexity, to being willing to consider changing the compiler
    to better accommodate broken code is that there will be some people
    who openly disagree with that policy and/or with the specifics of
    the proposal.

Yes.  Once people accept the principle of doing this kind of
accommodation, actually doing it will be easy.  The idea is that you
only spend a limited amount of time looking for a solution, and only
do something if you find an easy way.  This always has to be easy.

The only thing that is hard is when people argue, as you are doing,
against the very idea of accommodation.  So please don't do that.

    In effect, you are telling me that if I don't want GCC to become even
    more complicated and hard to maintain than necessary, or have bugs fixed
    in it less speedily due to long-drawn-out discussions like this, I should
    no longer participate in discussions like this, except perhaps to
    grunt things like "okay by me" or "no way".

Those thoughts are yours, not mine.  I am just asking you and others
to stop arguing for a policy of harshness toward the user--to stop
arguing against the very idea of trying to accommodate old undefined
code.

If you don't want GCC to be more complicated or for the work to go
slower, then you share my feelings on that issue.  That's why I looked
for a simple change that is clearly correct and will be easy to
implement.  In the future, I would like the GCC developers to look for
such changes, because this is what the GNU Project needs GCC to do.

    this discussion is that there have been quite a number of statements
    made that are either incorrect in fact or incomplete in portraying
    cost/benefit analyses vis-a-vis this issue.  Since *most* of those
    statements have been made to promote accommodation, 

I have seen a regular pattern of exaggeration in the messages arguing
for harshness.  The worst always can happen, but it is very unlikely
to happen always.

    Programmers should view bugs in their code like termites.

I think you are partly right, but not entirely, because you are
demanding a strictness that is more trouble that it's worth for many
projects, and is also more work than most free software developers can
manage to do.  Fortunately, a somewhat more relaxed approach works
pretty well.

Be that as it may, that question is a side issue.  You are talking
about programmers running GCC on code that they are developing.  Those
are just some of the users of GCC.  Only some of the people running
GCC are running it on code they understand, or could attempt to debug.

We must not make GCC decisions with only those people in mind.

    But, I believe the analysis for GCC *itself* is *much* simpler:
    conform to the pertinent ANSI/ISO standards, etc.

GCC does conform to these standards, when used with the proper set of
options.  However, technical standards are not a moral authority.  The
GNU Project policy is that we pay close attention to official
standards, but we don't slavishly obey them.

In this case, the issue is not even whether GCC complies with the C
standard.  It concerns the behavior of GCC in a case which the C
standard does not specify.

Re: type based aliasing again

[craig]

>But if people accept the principle of making small and easy efforts to
>keep old code working, subsequent issues will only involve the
>comparatively easy job of figuring out how to do that.

Yes, having made this decision in *this* direction tempts one to
believe future decisions will be made more easily.  For all intents
and purposes, that's not true -- this decision was probably *well*
within the bounds set by many prior decisions to make similar, or
even more justifiable, accommodations, yet the discussion ensued
regardless.  (I can't think of any such decisions that ultimately
went the other way, offhand.  So those of us arguing against
the accommodations have been, in effect, trying to reign in this
historical willingness to make them.)

I believe that's because not all of us agree on the importance of
having GCC capable of strictly conforming to standards; the importance
of it doing so in a bug-free manner; and the degree to which doing
so should be the default behavior of GCC, versus defaulting to
dialectal/historical behaviors.  (There are other factors, like
short memories, but it seems like most of those objecting to the
accommodating proposals have demonstrated both better understanding
of what ISO C actually says *and* long-term memories of GCC developments
and discussions in the past, as compared to those calling for GCC to
make the proposed accommodations.)

So I don't see how accepting "the principle of making small and
easy efforts to keep old code working" simplifies things substantially.
(Particularly revealing is that I, myself, probably would have been
much more willing to accept it in this case a few years ago -- which
indicates the possibility that others might change their views as
they, as I have, continue to try and maintain a complicated product
in an ever-changing environment while coping with all sorts of demands
from users.)

Being a *strong* enthusiast for the *concept* of some accommodations
(the engineering concept of tolerance, which gave us CDs with well
over 74 minutes of music), I nevertheless accept that, for N individuals
working on a project, there will be, at any given time, N definitions
of "small", N of "easy", and N of "old code" (as versus "broken code").

The reason I increasingly promote the idea of taking the public,
and the default internal, stance of serving up ISO C and not a jot
more, in some manner (e.g. no discussion of adding non-ISO-C accommodations;
but a patch that plainly simplifies the ISO-C code-paths of GCC,
and *happens* to include code that can make such accommodations,
is not ruled out on that basis), is that, among those same N people,
there are likely to be far *fewer* than N definitions of "ISO C",
especially as it applies to any given construct, such as this
one.

Sure enough, nearly everyone gave different criteria and/or indicated
different "decision envelopes", including: make GCC more actively break
broken aliasing code; drop -fno-alias-analysis; status quo; warn when
trivially detectable; warn when sophisticatedly detectable; make
GCC more actively support broken aliasing code out of the box;
make GCC always default to supporting it; etc.  (Yes, I probably made
at least two or three of these myself.  ;-)

Yet almost everyone made the *same* judgement about whether the code,
itself, was broken.  I believe all the active GCC developers, especially
core developers, said "yes" or abstained from the discussion, anyway.

Now *that's* a simplifying assumption: work to a standard most people
are likely to understand and agree on.  (I still accept that ISO C
isn't ideal as a standard, but it's better than anything else we have
for a C-like language, AFAIK.)

In other words, I believe I can more reliably predict how Mark Mitchell
and Craig Burley (in the latter case, independent of the fact that I
am he *now*; I'm speaking objectively hear), among the few others
campaigning for no accommodation citing ISO C, will assess most *future*
requests for similar accommodations.

But I cannot predict how you or many others will assess those, because
your "simple"/"easy"/"old" variables are just too fuzzily defined.

So what we'll learn from future discussions is how those variables
are defined for pro-accommodation people at that moment, for the
issue de jure, even assuming nobody actually *changes* their particular
variables (i.e. they're constants, just fuzzily defined to the
outside world).  Whereas we basically already *know* these constants
for the anti-accommodation people.  (Who knows, maybe we already
knew those of *others*, who have not participated, from past
discussions.)

If you haven't done a thorough analysis of the efforts needed to discuss
this issue now and in the past, I suggest you do one, or, better yet,
hire an experienced consultant from the management-efficiency field
(or whatever they're calling it these days) to do so.

Then put up the results here for us to discuss, to encourage us all
to ask the question "is this amount of effort appropriate for
an issue like this?", as well as "could this effort have been
better directed towards other, more core, issues regarding GCC?"

That involves substantial time and effort, of course, but result
*could* be a *huge* improvement in reducing the time and effort
taken to discuss issues like this.  (Whether it'll convince more
or less of the anti-accommodation crowd than the pro-accommodation
crowd doesn't really matter, as long as the data being presented
was honestly collected and presented.)

>In effect, your argument is that this proposal is a bad idea because
>Craig Burley and others will spend time arguing against it.  I do not
>think that the proposal can be held responsible for that ;-).

If you view it that way, especially as a spokesman for the GNU project,
which controls GCC, you are saying that the only real cost, in terms
of added complexity, to being willing to consider changing the compiler
to better accommodate broken code is that there will be some people
who openly disagree with that policy and/or with the specifics of
the proposal.  (Assuming my argument is correct, of course...which it
is, since I made it.  ;-)

In effect, you are telling me that if I don't want GCC to become even
more complicated and hard to maintain than necessary, or have bugs fixed
in it less speedily due to long-drawn-out discussions like this, I should
no longer participate in discussions like this, except perhaps to
grunt things like "okay by me" or "no way".

That's certainly something I've considered, so having the GNU project
leader basically tell it to me outright simplifies *my* world -- I
no longer need to make an assessment *myself* as to how valuable
my input *might* be considered to keep GCC simple, maintainable, and
to increase its quality.  In a sense, your statement takes on the
role of the ISO C standard vis-a-vis this discussion, and I obediently
follow it, so I certainly appreciate the argument for simplicity you
are making.

However, I will point out that you have effectively told not just me,
but several others, the same thing.

If they interpret your statement the same way as I do, and thus avoid
objecting to future requests for accommodations in GCC, someday the
day will come when lots of users, not yet weaned from depending on
GCC as some sort of "free-software install tool", demand things of GCC
that even *you* wish to not (or cannot) accommodate.

At that point, you might find it suddenly very difficult to gain support
for your unwillingness to accommodate those demands, and, I predict,
find it similarly difficult to find people enthusiastic about doing
what is necessary to meet them (since a larger percentage of GCC users
will be of the unweaned variety, thus not really capable of improving
GCC themselves, than if we were to have drawn the line in the sand *here*
and *now*).

And a big part of the reason I've participated so forcefully in
this discussion is that there have been quite a number of statements
made that are either incorrect in fact or incomplete in portraying
cost/benefit analyses vis-a-vis this issue.  Since *most* of those
statements have been made to promote accommodation, I've leaned
towards no accommodation (or at least presenting myself as such).

That is, as I'm sure Linux developers will attest from *their* experiences
(based on my impressions), the risk of submitting a request for
coming to an agreement, rather than submitting a patch to implement
it, of course.  ;-)

>    So people can either fix their code now, or fix it later.
>
>I notice a pattern that people arguing against concern for the users
>tend to exaggerate the situation in this particular way: they change
>"some of this code may break, may need to be changed" into "all of
>this code will break, will need to be changed."

I didn't say that.  But, for the purposes of assessing these issues,
that's how people maintaining their code should *think*.  (Ever hear
of Murphy's Law?)

In particular, nobody (but hackers) using GCC should seriously entertain
*any* hopes that GCC will manage to accommodate bugs hiding in their
code, when it comes to assessing the long-term viability of their project,
even though they might recognize (as most of us do) how the practicalities
of compiler engineering make it *unlikely* certain bugs will be exposed
over a certain lifetime.

(And hackers shouldn't care what GCC does in the long haul, as I pointed
out earlier.)

Programmers should view bugs in their code like termites.  It doesn't
matter that, within one square mile of their home, billions of termites
will *never* contribute to the downfall of that home.  What *does* matter
is that there are probably enough to bring it down, and that there's
no way, ahead of time, to predict exactly which ones will, and which
ones won't.  All one can do is make educated guesses, and use those
to best direct one's efforts towards eradicating "suspect" termites.

But if one wishes the home to not fall, one either does not build it out of
wood in the first place or adopts a zero-tolerance approach to termites
(meaning constant watchfulness, for example, or locating one's home
in a climate that has no termites).

That way, one does not blame one's friend for happening to let in
*the* termites that finally brought down the home when he was feeding
the pets during one's vacation.  Nor does one waste even two minutes
trying to convince his friends that *they* must become termite-free,
despite their having chosen to live in more secure dwellings themselves,
because that's two minutes that could have been spent fighting the
termites in or very near the home.

>    having) to accommodate Merced or McKinley amounts to entertaining
>    the same hopes, and therefore similar scaling of costs, as the
>    Y2K problem.
>
>Compilers did not give warnings for Y2K problems, but we will
>make GCC give a warning for most of these problems.  So these situations
>are hardly similar.

Compiles *have* given warnings for Y2K problems.  g77 surely does, as
of EGCS 1.1 IIRC.  And, I've heard proprietary compilers (like Compaq's,
formerly Digital's) do quite a bit more in that direction than g77,
though I haven't researched the issue further than to figure out
what g77 could easily do.

But that wasn't my point, anyway.  What these situations *do* share
*is* related to my point: in both cases, no automaton can reliably warn
about all instances of the problem.  So there's no silver bullet other than
programmers fixing their code or *knowing* (not just hoping, guessing,
pretending, etc.) that their programs will be mothballed before the
bug wall hits.  (For Y2K, that's usually around 2000-01-01.  For this bug,
that's probably Merced or McKinley on desktops in quantities of a few
million or so.)

From the point of view of the free-software industry, the analysis
includes considering the risk of losing expertise over time as
the bug-wall approaches versus the opportunity to not be hit by
it at all due to mothballing.

But, I believe the analysis for GCC *itself* is *much* simpler:
conform to the pertinent ANSI/ISO standards, etc.

(People designing new languages and environments -- like Guile, GNOME,
KDE, and so on -- are the ones especially needing to evaluate the
larger context in which their *designs* will be used, since long-term
acceptance of them depends on the *aggregate* usability, reliability,
etc. of systems built on them.  The advantages of using off-the-shelf
languages and environments like ISO C and POSIX include not having
to bother with such evaluations; the dangers include thinking one
can get away with "mini-evaluations" for extensions and accommodations
outside of those specified for, and by, off-the-shelf components.)

        tq vm, (burley)

Re: type based aliasing again

[Richard Stallman]

    So we can conclude that the expense (time and effort) needed to
    address this *one* issue is:

      -  representative of what we're likely to expend over similar issues
	 that *will* arise

If subsequent issues are like this one, finding a way to improve the
situatin will be fairly easy, but persuading certain people to accept
an improvement may be difficult.

But if people accept the principle of making small and easy efforts to
keep old code working, subsequent issues will only involve the
comparatively easy job of figuring out how to do that.

In effect, your argument is that this proposal is a bad idea because
Craig Burley and others will spend time arguing against it.  I do not
think that the proposal can be held responsible for that ;-).

    So people can either fix their code now, or fix it later.

I notice a pattern that people arguing against concern for the users
tend to exaggerate the situation in this particular way: they change
"some of this code may break, may need to be changed" into "all of
this code will break, will need to be changed."

    having) to accommodate Merced or McKinley amounts to entertaining
    the same hopes, and therefore similar scaling of costs, as the
    Y2K problem.

Compilers did not give warnings for Y2K problems, but we will
make GCC give a warning for most of these problems.  So these situations
are hardly similar.

Re: type based aliasing again

[craig]

>	This is arguing by generalization and generalizing to the
>extreme.  Different cases require different analysis and consideration.

So we can conclude that the expense (time and effort) needed to
address this *one* issue is:

  -  representative of what we're likely to expend over similar issues
     that *will* arise

  -  unlikely to serve as a boilerplate for analysis and consideration
     over those issues, sufficient that it significantly reduces the
     resources needed to analyse them

  -  not going to ameliorate problems users have compiling arbitrary
     C code off the 'net using GCC, since we'll likely come to different
     decisions than always defaulting to -fno-strict-analysis, even if
     we decide to do that now

  -  not going to serve too well in re-assessing whatever decision we
     make (*especially* one to change the default to -fno-...) in
     the future, since the future will hold all sorts of new
     information, thus leading to "different analysis and consideration"

Therefore, as I said near the very beginning of this most recent 'fest,
we shouldn't waste any time discussing issues like this.  Period.  We
should invoke the simplifying assumption that code which is violates
ISO C conformance rules is not worth bothering about.  That'll save
tons of resources (especially avoiding lots of wasted discussion) right
there.

Further, I realized, last night, that hoping that code needing this
special consideration will have finally been mothballed by the time
the default *has* to be changed (no question, no discussion worth
having) to accommodate Merced or McKinley amounts to entertaining
the same hopes, and therefore similar scaling of costs, as the
Y2K problem.  Most programmers who put Y2K bugs into code probably
just *knew* their code would be mothballed by 1995 or so anyway....

So people can either fix their code now, or fix it later.

Which is going to be more expensive for the industry as a whole?

        tq vm, (burley)

Re: type based aliasing again

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> So are you going to propose next that we turn off automatic register allocation
Jeff> because some programmers don't have enough of a clue to write correct code?
Jeff> (yes, automatic register allocation will cause programs to behave in an
Jeff> unexpected manner if the programmer does stupid things like not initializing
Jeff> automatics, or not using volatile for variables live across setjmp).

Jeff> Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
Jeff> clueless programmer violated the assumptions for that optimization?

Jeff> Hell, while you're at it, you might as well turn off any optimization that
Jeff> might have a bug.

	This is arguing by generalization and generalizing to the
extreme.  Different cases require different analysis and consideration.

David

Re: type based aliasing again

[Nick Ing-Simmons]

What you repeatedly miss is that there are many many more
people that use gcc as the "free software install tool" than there are 
who actually write programs. 

Having the "new improved" gcc break previously stable and trusted
free software does the movement as a whole no good at all.


Jeffrey A Law <law@cygnus.com> writes:
>  > No, it allows _programmers_ that know what they are doing to get the 
>  > benefit of their knowledge by the simple expedient of adding -fstrict-alias
>  > ing
>  > to Makefile.in and forgetting about it.
>  > 
>  > While protecting sys-admins and users of open-source products that just 
>  > build but do not write them from the bad habits that not-so-good/or
>  > too-clever-for-their-own-good programmers have developed over the decades.
>So are you going to propose next that we turn off automatic register allocation
>because some programmers don't have enough of a clue to write correct code?

Of course not. 
The code I am talking about has been working fine for years, and obviously 
has no problems with register allocation and similar "old hat" optimizations.

My entire argument is based on the fact that there are 
free/opensource applications "out there" which work fine with 
gcc-1.3 .. gcc-2.8.1 which break with late egcs-1.1.* and gcc-2.95.*

Now when 'sys-admin@clueless.org' sends in a bug report on perl (say)
we say "get new release" or "add -fno-strict-aliasing to ccflags".
At best we make them spend 10s of minutes doing a rebuild and they are just 
grumpy. At worst the tell their collegues/manager "this free software is 
fragile, if any bit changes you have to go re-build everything" or similar.

And then there are packages out there which are not actively maintained...

> not using volatile for variables live across setjmp).

There is a warning for that. And if it is going to fail it will have failed
and so existing packages have it "right enough".

>
>Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
>clueless programmer violated the assumptions for that optimization?

No, no 1000 times no. I don't care about "clueless" programmers - I care 
about USERS of applications written by clever programmers that (ab)used aliasing 
to get a job done.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[craig]

>What you repeatedly miss is that there are many many more
>people that use gcc as the "free software install tool" than there are 
>who actually write programs. 

What you, and others, repeatedly miss is that GCC is a compiler,
not a free-software install tool.

If I wanted to work on a free-software install tool, I'd work on RPM
or something like that.

>Having the "new improved" gcc break previously stable and trusted
>free software does the movement as a whole no good at all.

Please stop lying about GCC breaking anything.  It is the *code*
that is broken.  The programmers must fix it.  That is the division
of labor that the industry, as well as nature, have chosen.

If you think the problem is so bad, then go and fix *it* in all the
code you think is too "stable and trusted" to be permitted to fail
due to its own bugs.  Do not make GCC worse by having it paper over
the problem for any amount of time.  That does a long-term disservice
to users.  I refuse to participate in pandering to users' short-term
wants by threatening our ability to meet their long-term *needs*.

        tq vm, (burley)

Re: type based aliasing again

[Nick Ing-Simmons]

<craig@jcb-sc.com> writes:
>>What you repeatedly miss is that there are many many more
>>people that use gcc as the "free software install tool" than there are 
>>who actually write programs. 
>
>What you, and others, repeatedly miss is that GCC is a compiler,
>not a free-software install tool.

It can be both - let us agree to differ.

>
>Please stop lying about GCC breaking anything.  It is the *code*
>that is broken.  

It is now we are forced to use C rather than "the language supported by 
gcc-2.8.1" ;-)

>The programmers must fix it.  That is the division
>of labor that the industry, as well as nature, have chosen.

Help from the compiler (warnings) would make the programmers job easier.
Warnings/errors would also make the "other" users of the compiler suspicious
and make them track down and punish the programmers.

>
>If you think the problem is so bad, then go and fix *it* in all the
>code you think is too "stable and trusted" to be permitted to fail
>due to its own bugs.  

Quick fix (add the flag) has been done for perl. We are looking at how to 
do the clean fix without performance hit - not to mention tracking down
exactly where all the bugs actually are which is not always obvious.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[craig]

><craig@jcb-sc.com> writes:
>>>What you repeatedly miss is that there are many many more
>>>people that use gcc as the "free software install tool" than there are 
>>>who actually write programs. 
>>
>>What you, and others, repeatedly miss is that GCC is a compiler,
>>not a free-software install tool.
>
>It can be both - let us agree to differ.

Yes, we'll agree to disagree.  To the extent you try to make it a
free-software install tool, you'll break it as a compiler.  And,
during this discussion, less effort has been expended to *fix* it
as a compiler than otherwise would have been.

>>Please stop lying about GCC breaking anything.  It is the *code*
>>that is broken.  
>
>It is now we are forced to use C rather than "the language supported by 
>gcc-2.8.1" ;-)

The same can be said for every time code gets compiled by a new compiler,
a new version of a compiler, or for a new architecture.

        tq vm, (burley)

Re: type based aliasing again

[craig]

><craig@jcb-sc.com> writes:
>>>What you repeatedly miss is that there are many many more
>>>people that use gcc as the "free software install tool" than there are 
>>>who actually write programs. 
>>
>>What you, and others, repeatedly miss is that GCC is a compiler,
>>not a free-software install tool.
>
>It can be both - let us agree to differ.

Yes, we'll agree to disagree.  To the extent you try to make it a
free-software install tool, you'll break it as a compiler.  And,
during this discussion, less effort has been expended to *fix* it
as a compiler than otherwise would have been.

>>Please stop lying about GCC breaking anything.  It is the *code*
>>that is broken.  
>
>It is now we are forced to use C rather than "the language supported by 
>gcc-2.8.1" ;-)

The same can be said for every time code gets compiled by a new compiler,
a new version of a compiler, or for a new architecture.

        tq vm, (burley)

Re: type based aliasing again

[Nick Ing-Simmons]

<craig@jcb-sc.com> writes:
>>What you repeatedly miss is that there are many many more
>>people that use gcc as the "free software install tool" than there are 
>>who actually write programs. 
>
>What you, and others, repeatedly miss is that GCC is a compiler,
>not a free-software install tool.

It can be both - let us agree to differ.

>
>Please stop lying about GCC breaking anything.  It is the *code*
>that is broken.  

It is now we are forced to use C rather than "the language supported by 
gcc-2.8.1" ;-)

>The programmers must fix it.  That is the division
>of labor that the industry, as well as nature, have chosen.

Help from the compiler (warnings) would make the programmers job easier.
Warnings/errors would also make the "other" users of the compiler suspicious
and make them track down and punish the programmers.

>
>If you think the problem is so bad, then go and fix *it* in all the
>code you think is too "stable and trusted" to be permitted to fail
>due to its own bugs.  

Quick fix (add the flag) has been done for perl. We are looking at how to 
do the clean fix without performance hit - not to mention tracking down
exactly where all the bugs actually are which is not always obvious.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Andi Kleen]

craig@jcb-sc.com writes:

> >What you repeatedly miss is that there are many many more
> >people that use gcc as the "free software install tool" than there are 
> >who actually write programs. 
> 
> What you, and others, repeatedly miss is that GCC is a compiler,
> not a free-software install tool.
> 
> If I wanted to work on a free-software install tool, I'd work on RPM
> or something like that.

Just reading the GCC installation document proves you wrong on this one
(GCC definitely uses itself as a free-software install tool). Lots of
other software does too. For example it is the standard installation
method of GNU software as distributed on ftp.gnu.org.

Just ignoring that common use of the compiler just does not serve the
user base, nor I think the GNU project, well.

> If you think the problem is so bad, then go and fix *it* in all the
> code you think is too "stable and trusted" to be permitted to fail
> due to its own bugs.  Do not make GCC worse by having it paper over
> the problem for any amount of time.  That does a long-term disservice
> to users.  I refuse to participate in pandering to users' short-term
> wants by threatening our ability to meet their long-term *needs*.

Because fixing it often needs major data structure changes (overlap ->
explicit union), which are often just impossible to submit into a
stable code freezed production release mainteance tree. Because of
gcc's lack of anonymous unions in C it usually requires changes to
every user of that possible overlapped data structure, it is not possible
to encapsulate it.

If I tried to tell Jeff to change all users of e.g. tree or rtx in
the stable freezed gcc branch to fix some obscure[1] bug caused by
behaviour change in third party software he would laugh me out of the list.

-Andi

[1] Obscure as in "Joe Programmer never heard of it before"

-- 
This is like TV. I don't like TV.

Re: type based aliasing again

[Joern Rennecke]

> Because fixing it often needs major data structure changes (overlap ->
> explicit union), which are often just impossible to submit into a
> stable code freezed production release mainteance tree. Because of
> gcc's lack of anonymous unions in C it usually requires changes to
> every user of that possible overlapped data structure, it is not possible
> to encapsulate it.

I suppose that means we should get the typealias feature into a erlease soon,
so that people can use it to make their code work with gcc's strict aliasing
without large code changes.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    Joern> I suppose that means we should get the typealias feature
    Joern> into a erlease soon, so that people can use it to make
    Joern> their code work with gcc's strict aliasing without large
    Joern> code changes.

That's one approach.  However, rather than add another extension, we
could just not use the strict-aliasing optimizations with that code.
(Either by turning it off by default, or by having the people
compiling the code use -fno-strict-aliasing.)

I'm not convinced we need to provide a "have your cake and eat it too"
mode where you can get the benefits of the optimization without having
conforming code.  Even if you go to the troule of adding some extra
type-qualifiers, attributes, etc., somewhere.  

Especially now that people are providing implementations of helpful
warnings, it seems fair to say "use -fno-strict-aliasing (either
because that's the default, or otherwise) or else write conforming
code".

Historically, most of our language extensions have proven
ill-specified, to have slightly odd behavior, to significantly
complicate the compiler, etc..  I'm not commenting on any specific
proposal, but it's very, very hard to get new language features right.
There tends to be a huge maintenance cost.

IMO, the last thing we want to do is to make GNU C a dialect even more
divergent from ANSI/ISO C.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    Joern> I suppose that means we should get the typealias feature
    Joern> into a erlease soon, so that people can use it to make
    Joern> their code work with gcc's strict aliasing without large
    Joern> code changes.

That's one approach.  However, rather than add another extension, we
could just not use the strict-aliasing optimizations with that code.
(Either by turning it off by default, or by having the people
compiling the code use -fno-strict-aliasing.)

I'm not convinced we need to provide a "have your cake and eat it too"
mode where you can get the benefits of the optimization without having
conforming code.  Even if you go to the troule of adding some extra
type-qualifiers, attributes, etc., somewhere.  

Especially now that people are providing implementations of helpful
warnings, it seems fair to say "use -fno-strict-aliasing (either
because that's the default, or otherwise) or else write conforming
code".

Historically, most of our language extensions have proven
ill-specified, to have slightly odd behavior, to significantly
complicate the compiler, etc..  I'm not commenting on any specific
proposal, but it's very, very hard to get new language features right.
There tends to be a huge maintenance cost.

IMO, the last thing we want to do is to make GNU C a dialect even more
divergent from ANSI/ISO C.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Joern Rennecke]

> Because fixing it often needs major data structure changes (overlap ->
> explicit union), which are often just impossible to submit into a
> stable code freezed production release mainteance tree. Because of
> gcc's lack of anonymous unions in C it usually requires changes to
> every user of that possible overlapped data structure, it is not possible
> to encapsulate it.

I suppose that means we should get the typealias feature into a erlease soon,
so that people can use it to make their code work with gcc's strict aliasing
without large code changes.

Re: type based aliasing again

[craig]

>craig@jcb-sc.com writes:
>
>> >What you repeatedly miss is that there are many many more
>> >people that use gcc as the "free software install tool" than there are 
>> >who actually write programs. 
>> 
>> What you, and others, repeatedly miss is that GCC is a compiler,
>> not a free-software install tool.
>> 
>> If I wanted to work on a free-software install tool, I'd work on RPM
>> or something like that.
>
>Just reading the GCC installation document proves you wrong on this one
>(GCC definitely uses itself as a free-software install tool). Lots of
>other software does too. For example it is the standard installation
>method of GNU software as distributed on ftp.gnu.org.

Please quote where the GCC install documents claim GCC is a free-software
install tool.

My understanding of the GCC installation procedure is that GCC is used
to compile *itself* as well as a few other components that are shipped
with *it*.  Therefore it is the responsibility of the GCC maintainers
to ensure those *tools* are properly coded with respect to the same
standard (extended ISO C) compiled by GCC.

I'll note that, in past incarnations of this discussion, it has
been pointed out that there are (at least apparent) instances
of the bug in GCC code itself, and that I cannot recall a *single*
instance in which a GCC developer said "well, that's not really
a bug so much as the compiler breaking existing code".

>Just ignoring that common use of the compiler just does not serve the
>user base, nor I think the GNU project, well.

I never said anything about "ignoring" a common use of the compiler.

I strongly suggest people stop claiming GCC is a free-software install
tool.  It is not.  It is a compiler.  Free-software install *procedures*
may well *use* it as a tool, but that leaves the responsibility
of correctly invoking it to compile C code (e.g. providing
the -fno-alias-analysis option) entirely in the hands of the maintainers
of those *procedures*.

>> If you think the problem is so bad, then go and fix *it* in all the
>> code you think is too "stable and trusted" to be permitted to fail
>> due to its own bugs.  Do not make GCC worse by having it paper over
>> the problem for any amount of time.  That does a long-term disservice
>> to users.  I refuse to participate in pandering to users' short-term
>> wants by threatening our ability to meet their long-term *needs*.
>
>Because fixing it often needs major data structure changes (overlap ->
>explicit union), which are often just impossible to submit into a
>stable code freezed production release mainteance tree. Because of
>gcc's lack of anonymous unions in C it usually requires changes to
>every user of that possible overlapped data structure, it is not possible
>to encapsulate it.

That's why we offer -fno-alias-analysis, which is going beyond
the strict mandate of an ISO C compiler to compile ISO C code.

>If I tried to tell Jeff to change all users of e.g. tree or rtx in
>the stable freezed gcc branch to fix some obscure[1] bug caused by
>behaviour change in third party software he would laugh me out of the list.

I doubt that.  We (not he) would probably limit our course of action
to one of two responses:

  -  Delay the release to fix the code (or at least work around the
     problem, i.e. the equivalent of supplying -fno-alias-analysis).

  -  Document that the third-party software in question is not supported
     by this new release (ideally by disabling it so it won't appear
     to work even to users who don't read docs)

The response you and others would offer, "scream loudly about how
that behavior change in third-party software broke working code like
GCC and therefore must be changed back", would not be offered by
anyone taken seriously as a core developer for a product like GCC.

        tq vm, (burley)

Re: type based aliasing again

[Andi Kleen]

On Thu, Sep 16, 1999 at 08:49:13PM +0200, craig@jcb-sc.com wrote:
> >Because fixing it often needs major data structure changes (overlap ->
> >explicit union), which are often just impossible to submit into a
> >stable code freezed production release mainteance tree. Because of
> >gcc's lack of anonymous unions in C it usually requires changes to
> >every user of that possible overlapped data structure, it is not possible
> >to encapsulate it.
> 
> That's why we offer -fno-alias-analysis, which is going beyond
> the strict mandate of an ISO C compiler to compile ISO C code.

Apparently not. Or what was that MEM_IN_STRUCT_P thing that cannot be turned 
off again?

Also gcc's first mandate is to compile GCC code. ISO C is only a option :)


-A.

Re: type based aliasing again

[Andi Kleen]

On Thu, Sep 16, 1999 at 08:49:13PM +0200, craig@jcb-sc.com wrote:
> >Because fixing it often needs major data structure changes (overlap ->
> >explicit union), which are often just impossible to submit into a
> >stable code freezed production release mainteance tree. Because of
> >gcc's lack of anonymous unions in C it usually requires changes to
> >every user of that possible overlapped data structure, it is not possible
> >to encapsulate it.
> 
> That's why we offer -fno-alias-analysis, which is going beyond
> the strict mandate of an ISO C compiler to compile ISO C code.

Apparently not. Or what was that MEM_IN_STRUCT_P thing that cannot be turned 
off again?

Also gcc's first mandate is to compile GCC code. ISO C is only a option :)


-A.

Re: type based aliasing again

[craig]

>craig@jcb-sc.com writes:
>
>> >What you repeatedly miss is that there are many many more
>> >people that use gcc as the "free software install tool" than there are 
>> >who actually write programs. 
>> 
>> What you, and others, repeatedly miss is that GCC is a compiler,
>> not a free-software install tool.
>> 
>> If I wanted to work on a free-software install tool, I'd work on RPM
>> or something like that.
>
>Just reading the GCC installation document proves you wrong on this one
>(GCC definitely uses itself as a free-software install tool). Lots of
>other software does too. For example it is the standard installation
>method of GNU software as distributed on ftp.gnu.org.

Please quote where the GCC install documents claim GCC is a free-software
install tool.

My understanding of the GCC installation procedure is that GCC is used
to compile *itself* as well as a few other components that are shipped
with *it*.  Therefore it is the responsibility of the GCC maintainers
to ensure those *tools* are properly coded with respect to the same
standard (extended ISO C) compiled by GCC.

I'll note that, in past incarnations of this discussion, it has
been pointed out that there are (at least apparent) instances
of the bug in GCC code itself, and that I cannot recall a *single*
instance in which a GCC developer said "well, that's not really
a bug so much as the compiler breaking existing code".

>Just ignoring that common use of the compiler just does not serve the
>user base, nor I think the GNU project, well.

I never said anything about "ignoring" a common use of the compiler.

I strongly suggest people stop claiming GCC is a free-software install
tool.  It is not.  It is a compiler.  Free-software install *procedures*
may well *use* it as a tool, but that leaves the responsibility
of correctly invoking it to compile C code (e.g. providing
the -fno-alias-analysis option) entirely in the hands of the maintainers
of those *procedures*.

>> If you think the problem is so bad, then go and fix *it* in all the
>> code you think is too "stable and trusted" to be permitted to fail
>> due to its own bugs.  Do not make GCC worse by having it paper over
>> the problem for any amount of time.  That does a long-term disservice
>> to users.  I refuse to participate in pandering to users' short-term
>> wants by threatening our ability to meet their long-term *needs*.
>
>Because fixing it often needs major data structure changes (overlap ->
>explicit union), which are often just impossible to submit into a
>stable code freezed production release mainteance tree. Because of
>gcc's lack of anonymous unions in C it usually requires changes to
>every user of that possible overlapped data structure, it is not possible
>to encapsulate it.

That's why we offer -fno-alias-analysis, which is going beyond
the strict mandate of an ISO C compiler to compile ISO C code.

>If I tried to tell Jeff to change all users of e.g. tree or rtx in
>the stable freezed gcc branch to fix some obscure[1] bug caused by
>behaviour change in third party software he would laugh me out of the list.

I doubt that.  We (not he) would probably limit our course of action
to one of two responses:

  -  Delay the release to fix the code (or at least work around the
     problem, i.e. the equivalent of supplying -fno-alias-analysis).

  -  Document that the third-party software in question is not supported
     by this new release (ideally by disabling it so it won't appear
     to work even to users who don't read docs)

The response you and others would offer, "scream loudly about how
that behavior change in third-party software broke working code like
GCC and therefore must be changed back", would not be offered by
anyone taken seriously as a core developer for a product like GCC.

        tq vm, (burley)

Re: type based aliasing again

[Andi Kleen]

craig@jcb-sc.com writes:

> >What you repeatedly miss is that there are many many more
> >people that use gcc as the "free software install tool" than there are 
> >who actually write programs. 
> 
> What you, and others, repeatedly miss is that GCC is a compiler,
> not a free-software install tool.
> 
> If I wanted to work on a free-software install tool, I'd work on RPM
> or something like that.

Just reading the GCC installation document proves you wrong on this one
(GCC definitely uses itself as a free-software install tool). Lots of
other software does too. For example it is the standard installation
method of GNU software as distributed on ftp.gnu.org.

Just ignoring that common use of the compiler just does not serve the
user base, nor I think the GNU project, well.

> If you think the problem is so bad, then go and fix *it* in all the
> code you think is too "stable and trusted" to be permitted to fail
> due to its own bugs.  Do not make GCC worse by having it paper over
> the problem for any amount of time.  That does a long-term disservice
> to users.  I refuse to participate in pandering to users' short-term
> wants by threatening our ability to meet their long-term *needs*.

Because fixing it often needs major data structure changes (overlap ->
explicit union), which are often just impossible to submit into a
stable code freezed production release mainteance tree. Because of
gcc's lack of anonymous unions in C it usually requires changes to
every user of that possible overlapped data structure, it is not possible
to encapsulate it.

If I tried to tell Jeff to change all users of e.g. tree or rtx in
the stable freezed gcc branch to fix some obscure[1] bug caused by
behaviour change in third party software he would laugh me out of the list.

-Andi

[1] Obscure as in "Joe Programmer never heard of it before"

-- 
This is like TV. I don't like TV.

Re: type based aliasing again

[Richard Stallman]

    >What you repeatedly miss is that there are many many more
    >people that use gcc as the "free software install tool" than there are 
    >who actually write programs. 

    What you, and others, repeatedly miss is that GCC is a compiler,
    not a free-software install tool.

GCC is a compiler, and it is often run by users to compile programs
that they did not write and would not know how to maintain, as well
as by the people who are writing a program.

Speaking for the GNU Project, it is important for us that GCC support
those users well, in addition to supporting programmers well.  Please
consider good support for them to be *one of* the primary goals of GCC
development.

Re: type based aliasing again

[Richard Stallman]

    >What you repeatedly miss is that there are many many more
    >people that use gcc as the "free software install tool" than there are 
    >who actually write programs. 

    What you, and others, repeatedly miss is that GCC is a compiler,
    not a free-software install tool.

GCC is a compiler, and it is often run by users to compile programs
that they did not write and would not know how to maintain, as well
as by the people who are writing a program.

Speaking for the GNU Project, it is important for us that GCC support
those users well, in addition to supporting programmers well.  Please
consider good support for them to be *one of* the primary goals of GCC
development.

Re: type based aliasing again

[craig]

>What you repeatedly miss is that there are many many more
>people that use gcc as the "free software install tool" than there are 
>who actually write programs. 

What you, and others, repeatedly miss is that GCC is a compiler,
not a free-software install tool.

If I wanted to work on a free-software install tool, I'd work on RPM
or something like that.

>Having the "new improved" gcc break previously stable and trusted
>free software does the movement as a whole no good at all.

Please stop lying about GCC breaking anything.  It is the *code*
that is broken.  The programmers must fix it.  That is the division
of labor that the industry, as well as nature, have chosen.

If you think the problem is so bad, then go and fix *it* in all the
code you think is too "stable and trusted" to be permitted to fail
due to its own bugs.  Do not make GCC worse by having it paper over
the problem for any amount of time.  That does a long-term disservice
to users.  I refuse to participate in pandering to users' short-term
wants by threatening our ability to meet their long-term *needs*.

        tq vm, (burley)

Re: type based aliasing again

[Nick Ing-Simmons]

What you repeatedly miss is that there are many many more
people that use gcc as the "free software install tool" than there are 
who actually write programs. 

Having the "new improved" gcc break previously stable and trusted
free software does the movement as a whole no good at all.


Jeffrey A Law <law@cygnus.com> writes:
>  > No, it allows _programmers_ that know what they are doing to get the 
>  > benefit of their knowledge by the simple expedient of adding -fstrict-alias
>  > ing
>  > to Makefile.in and forgetting about it.
>  > 
>  > While protecting sys-admins and users of open-source products that just 
>  > build but do not write them from the bad habits that not-so-good/or
>  > too-clever-for-their-own-good programmers have developed over the decades.
>So are you going to propose next that we turn off automatic register allocation
>because some programmers don't have enough of a clue to write correct code?

Of course not. 
The code I am talking about has been working fine for years, and obviously 
has no problems with register allocation and similar "old hat" optimizations.

My entire argument is based on the fact that there are 
free/opensource applications "out there" which work fine with 
gcc-1.3 .. gcc-2.8.1 which break with late egcs-1.1.* and gcc-2.95.*

Now when 'sys-admin@clueless.org' sends in a bug report on perl (say)
we say "get new release" or "add -fno-strict-aliasing to ccflags".
At best we make them spend 10s of minutes doing a rebuild and they are just 
grumpy. At worst the tell their collegues/manager "this free software is 
fragile, if any bit changes you have to go re-build everything" or similar.

And then there are packages out there which are not actively maintained...

> not using volatile for variables live across setjmp).

There is a warning for that. And if it is going to fail it will have failed
and so existing packages have it "right enough".

>
>Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
>clueless programmer violated the assumptions for that optimization?

No, no 1000 times no. I don't care about "clueless" programmers - I care 
about USERS of applications written by clever programmers that (ab)used aliasing 
to get a job done.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909151501.QAA26239@tiuk.ti.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > >  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
  > >  > Changing the default to -fno-strict-aliasing would certainly solve the
  > >  > immediate problem.  If people are happy with that, as a more or less
  > >  > permanent decision, I think it avoids most of the need to do anything
  > >  > else.  (An added warning might be desirable, though, even with
  > >  > -fno-strict-aliasing.)
  > >I strongly feel this is the wrong approach.
  > >
  > >It penalizes those programmers who write correct code to cater to the
  > >programmers that do not write correct code.  
  > 
  > No, it allows _programmers_ that know what they are doing to get the 
  > benefit of their knowledge by the simple expedient of adding -fstrict-alias
  > ing
  > to Makefile.in and forgetting about it.
  > 
  > While protecting sys-admins and users of open-source products that just 
  > build but do not write them from the bad habits that not-so-good/or
  > too-clever-for-their-own-good programmers have developed over the decades.
So are you going to propose next that we turn off automatic register allocation
because some programmers don't have enough of a clue to write correct code?
(yes, automatic register allocation will cause programs to behave in an
unexpected manner if the programmer does stupid things like not initializing
automatics, or not using volatile for variables live across setjmp).

Or are you going to propose that we turn off MEM_IN_STRUCT_P because some
clueless programmer violated the assumptions for that optimization?

Hell, while you're at it, you might as well turn off any optimization that
might have a bug.

jeff

Re: type based aliasing again

[Nick Ing-Simmons]

Jeffrey A Law <law@cygnus.com> writes:
>  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
>  > Changing the default to -fno-strict-aliasing would certainly solve the
>  > immediate problem.  If people are happy with that, as a more or less
>  > permanent decision, I think it avoids most of the need to do anything
>  > else.  (An added warning might be desirable, though, even with
>  > -fno-strict-aliasing.)
>I strongly feel this is the wrong approach.
>
>It penalizes those programmers who write correct code to cater to the
>programmers that do not write correct code.  

No, it allows _programmers_ that know what they are doing to get the 
benefit of their knowledge by the simple expedient of adding -fstrict-aliasing
to Makefile.in and forgetting about it.

While protecting sys-admins and users of open-source products that just 
build but do not write them from the bad habits that not-so-good/or
too-clever-for-their-own-good programmers have developed over the decades.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Richard Stallman]

      > Changing the default to -fno-strict-aliasing would certainly solve the
      > immediate problem.
    I strongly feel this is the wrong approach.

    It penalizes those programmers who write correct code to cater to
    the programmers that do not write correct code.

Whether this is good or bad depends on how much penalty it causes for
the one group, and how painful a problem we cater to for the other.

Having programs run a little more slowly is a small problem, in most
cases, whereas having them not work at all or produce wrong results is
a serious problem.

The way you have stated the issue neglects this disparity, and
implicitly argues for an absolutist policy which disregards it.  That
cannot possibly be right.  We should not make GCC decisions that way.

When we consider at the severity of these two disadvantages, the
proposal to change the default comes out reasonable.  But there
remains the other alternative that I proposed.  It would cause no
significant slowdown in the execution of valid standard C programs.

Re: type based aliasing again

[Richard Stallman]

      > Changing the default to -fno-strict-aliasing would certainly solve the
      > immediate problem.
    I strongly feel this is the wrong approach.

    It penalizes those programmers who write correct code to cater to
    the programmers that do not write correct code.

Whether this is good or bad depends on how much penalty it causes for
the one group, and how painful a problem we cater to for the other.

Having programs run a little more slowly is a small problem, in most
cases, whereas having them not work at all or produce wrong results is
a serious problem.

The way you have stated the issue neglects this disparity, and
implicitly argues for an absolutist policy which disregards it.  That
cannot possibly be right.  We should not make GCC decisions that way.

When we consider at the severity of these two disadvantages, the
proposal to change the default comes out reasonable.  But there
remains the other alternative that I proposed.  It would cause no
significant slowdown in the execution of valid standard C programs.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909130757.DAA05910@psilocin.gnu.org >you write:
  > Changing the default to -fno-strict-aliasing would certainly solve the
  > immediate problem.  If people are happy with that, as a more or less
  > permanent decision, I think it avoids most of the need to do anything
  > else.  (An added warning might be desirable, though, even with
  > -fno-strict-aliasing.)
I strongly feel this is the wrong approach.

It penalizes those programmers who write correct code to cater to the
programmers that do not write correct code.  That to me is short sighted and
counter-productive.

jeff

Re: type based aliasing again

[Richard Stallman]

Changing the default to -fno-strict-aliasing would certainly solve the
immediate problem.  If people are happy with that, as a more or less
permanent decision, I think it avoids most of the need to do anything
else.  (An added warning might be desirable, though, even with
-fno-strict-aliasing.)

The importance of considering option #3 goes beyond this particular
issue.  Other issues will arise where optimization runs over old code
that people use.  Option #3 is not guaranteed to be workable for
all these other issues, but it will be workable for some of them.

So even if we deal with this issue in a different way, and that makes
option #3 unnecessary here, we should keep it in mind for the future.

Re: type based aliasing again

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> I think that making -fno-strict-aliasing the default is sensible
Mark> proposal, and worth debating.

Mark> I would much rather see us change the default, if that is really
Mark> necessary, than muddy the waters with confusing semantics, semantics
Mark> that will change due to minor adjustments to the compiler.  Yes, this
Mark> would mean that users cannot have their cake and eat it too: they
Mark> cannot have the benefits of -fstrict-alaising and still not follow the
Mark> ISO rules.  But, they are no worse off than before we added the
Mark> aliasing optimizations.

	FYI, IBM's AIX compiler does not enable "ANSI aliasing" by default
when the compiler is invoked with "cc".  AIX "cc" essentially is "gcc
-fno-strict-alias -fwriteable-strings"; AIX "xlc" command enables alias
optimizations and creates read-only constants.

David

Re: type based aliasing again

[Jonathan Larmour]

In article < 19990911152505P.mitchell@codesourcery.com > you write:
>
>Someone (not RMS, but I have lost track of who, originally) wrote:
>
>    In the end, if your argument is carried too far, the
>    only solution would be to make -fno-strict-alias the
>    default.
>
>I think that making -fno-strict-aliasing the default is sensible
>proposal, and worth debating.

Also remember that -fno-strict-aliasing may not be enough to make user
code that breaks the alias rules work. As I said elsewhere, I believe
the instruction scheduler makes assumptions about aliasing of scalars
and structs.

For that reason, I think the warning may be a better way to go because
it may be able to catch these cases as well.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: type based aliasing again

[Jonathan Larmour]

In article < 19990911152505P.mitchell@codesourcery.com > you write:
>
>Someone (not RMS, but I have lost track of who, originally) wrote:
>
>    In the end, if your argument is carried too far, the
>    only solution would be to make -fno-strict-alias the
>    default.
>
>I think that making -fno-strict-aliasing the default is sensible
>proposal, and worth debating.

Also remember that -fno-strict-aliasing may not be enough to make user
code that breaks the alias rules work. As I said elsewhere, I believe
the instruction scheduler makes assumptions about aliasing of scalars
and structs.

For that reason, I think the warning may be a better way to go because
it may be able to catch these cases as well.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: type based aliasing again

[Richard Stallman]

    I would much rather see us change the default, if that is really
    necessary, than muddy the waters with confusing semantics, semantics
    that will change due to minor adjustments to the compiler.

Changing the default may be a good solution for this issue.  But when
you describe option #3 as "confusing semantics", I think that means
you still judging this as if it were a proposal for a feature.

Features have semantics, which may be confusing or clear.
If it isn't clear, that is an argument against the feature.

But option #3 is not a feature.  It does not have semantics.
To ask whether its semantics are clear or not is to treat it
like a feature, which is a misunderstanding of the basic idea.

There will be other occasions in the future to consider using option
#3, so it is essential for decisions about GCC to be made with clear
understanding of this alternative.

Re: type based aliasing again

[Richard Stallman]

    I would much rather see us change the default, if that is really
    necessary, than muddy the waters with confusing semantics, semantics
    that will change due to minor adjustments to the compiler.

Changing the default may be a good solution for this issue.  But when
you describe option #3 as "confusing semantics", I think that means
you still judging this as if it were a proposal for a feature.

Features have semantics, which may be confusing or clear.
If it isn't clear, that is an argument against the feature.

But option #3 is not a feature.  It does not have semantics.
To ask whether its semantics are clear or not is to treat it
like a feature, which is a misunderstanding of the basic idea.

There will be other occasions in the future to consider using option
#3, so it is essential for decisions about GCC to be made with clear
understanding of this alternative.

Re: type based aliasing again

[Richard Earnshaw]

mark@codesourcery.com said:
> I think that making -fno-strict-aliasing the default is sensible
> proposal, and worth debating.


It is the default at -O1 or less.  I would be inclined to argue that this 
should be adequate for "legacy" code and that the higher levels of 
optimization should be allowed to fully exploit the provisions of the C 
standard (this is not to suggest that a warning shouldn't be generated if 
possible).

We are somewhat constrained by our relatively limited number of 
optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
mainly because of a user-education issue.  But it would be useful if we 
could have a level above which we say that we assume that code fully 
conforms to the C (or other relevant) standard.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909131102.MAA25960@sun52.NIS.cambridge >you write:
  > 
  > mark@codesourcery.com said:
  > > I think that making -fno-strict-aliasing the default is sensible
  > > proposal, and worth debating.
  > 
  > 
  > It is the default at -O1 or less.  I would be inclined to argue that this 
  > should be adequate for "legacy" code and that the higher levels of 
  > optimization should be allowed to fully exploit the provisions of the C 
  > standard (this is not to suggest that a warning shouldn't be generated if 
  > possible).
Good point.


  > We are somewhat constrained by our relatively limited number of 
  > optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
  > mainly because of a user-education issue.  But it would be useful if we 
  > could have a level above which we say that we assume that code fully 
  > conforms to the C (or other relevant) standard.
We really need to make some space in the -O namespace.  So we shouldn't let
that problem stop us if people think it's a reasonable thing to do.

Right now -O3 is just -O2 + -finline-functions.

I've got no objection to moving -finline-functions to some higher -O level to
give us some room to add optimizations which may depend on strict adherence of
code to the ANSI/ISO standards or which may take more memory/time (load/store
motion would be a good example).

Yes there's a user education issue, but it's a hell of a lot smaller than the
"how to write conforming code" education issue.


jeff

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909131102.MAA25960@sun52.NIS.cambridge >you write:
  > 
  > mark@codesourcery.com said:
  > > I think that making -fno-strict-aliasing the default is sensible
  > > proposal, and worth debating.
  > 
  > 
  > It is the default at -O1 or less.  I would be inclined to argue that this 
  > should be adequate for "legacy" code and that the higher levels of 
  > optimization should be allowed to fully exploit the provisions of the C 
  > standard (this is not to suggest that a warning shouldn't be generated if 
  > possible).
Good point.


  > We are somewhat constrained by our relatively limited number of 
  > optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
  > mainly because of a user-education issue.  But it would be useful if we 
  > could have a level above which we say that we assume that code fully 
  > conforms to the C (or other relevant) standard.
We really need to make some space in the -O namespace.  So we shouldn't let
that problem stop us if people think it's a reasonable thing to do.

Right now -O3 is just -O2 + -finline-functions.

I've got no objection to moving -finline-functions to some higher -O level to
give us some room to add optimizations which may depend on strict adherence of
code to the ANSI/ISO standards or which may take more memory/time (load/store
motion would be a good example).

Yes there's a user education issue, but it's a hell of a lot smaller than the
"how to write conforming code" education issue.


jeff

Re: type based aliasing again

[Richard Earnshaw]

mark@codesourcery.com said:
> I think that making -fno-strict-aliasing the default is sensible
> proposal, and worth debating.


It is the default at -O1 or less.  I would be inclined to argue that this 
should be adequate for "legacy" code and that the higher levels of 
optimization should be allowed to fully exploit the provisions of the C 
standard (this is not to suggest that a warning shouldn't be generated if 
possible).

We are somewhat constrained by our relatively limited number of 
optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, 
mainly because of a user-education issue.  But it would be useful if we 
could have a level above which we say that we assume that code fully 
conforms to the C (or other relevant) standard.

Re: type based aliasing again

[Mark Mitchell]

Someone (not RMS, but I have lost track of who, originally) wrote:

    In the end, if your argument is carried too far, the
    only solution would be to make -fno-strict-alias the
    default.

I think that making -fno-strict-aliasing the default is sensible
proposal, and worth debating.

Whether or not it is the default should be based on a variety of
considerations, including how many programs are "broken" by the more
correct behavior, how many of those can and will be easily fixed, and
how many are actively maintained.

For example, the Linux kernel is not a good reason to change the
default; it is easy for this actively maintained project to simply add
-fno-strict-aliasing to their Makefiles, if appropriate.  But, if it
is true that most, or at least a lot, of programs do not follow the
ISO rules, then it may be that we have set the default incorrectly.
In my experience, there are not too many such programs; I have only
seen one such cases in our customer's code, and that was very easily
fixed.  However, I make no claim that this code base is reprsentative
of things compiled with GCC.

I would much rather see us change the default, if that is really
necessary, than muddy the waters with confusing semantics, semantics
that will change due to minor adjustments to the compiler.  Yes, this
would mean that users cannot have their cake and eat it too: they
cannot have the benefits of -fstrict-alaising and still not follow the
ISO rules.  But, they are no worse off than before we added the
aliasing optimizations.

The best strategy at this point, in my opinion, would be for someone
to implement the warning.  (Note that this is non-trivial.)  Then, we
can get some idea as to how much code is breaking the rules, and then
judge whether or not he default is correct.  We must also weigh the
risk that people will not fix the code, unless we break it, and that
we will therefore never be able to make -fstrict-aliasing the default.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: type based aliasing again

[Richard Stallman]

    While I have some sympathy for that point of view, the reason that
    the type aliasing rules were added was to give scientific programmers
    what they were asking for: C that runs about as fast as Fortran.

We should certainly make of these rules to generate faster code.  But
while we do this, we can still look for ways to keep old code working
right--when we find ways to do this with little pain and little cost.

    I don't want to break users' code when we can TELL what they mean,
    and many examples seem to fall into that category.  But where we
    can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias)
    or not (-fno-strict-alias).

When we can't easily tell "what was meant", I think we should take
advantage of the ISO rules, and carry out the optimizations that are
possible.

    In the end, if your argument is carried too far, the only solution
    would be to make -fno-strict-alias the default.

The whole point of this idea is that we don't try to carry the idea
too far--just a certain amount.  What we need here is moderation; we
need to find the balance between the various goals that matter to the
users.

Re: type based aliasing again

[Joe Buck]

RMS writes:

> In C, we cannot divide all user code into "right" and "wrong" in this
> kind of simple way, and certainly not based on the ISO standard.  That
> standard is just the decisions of a certain committee (which I was a
> member of) about what cases conforming compilers should commit to
> support.  We must not let ourselves start thinking that C code is
> "wrong", just because it is not conforming ISO C code.

While I have some sympathy for that point of view, the reason that
the type aliasing rules were added was to give scientific programmers
what they were asking for: C that runs about as fast as Fortran.

I don't want to break users' code when we can TELL what they mean,
and many examples seem to fall into that category.  But where we
can't tell, we have to either exploit the ISO rules (e.g. -fstrict-alias)
or not (-fno-strict-alias).

In the end, if your argument is carried too far, the only solution
would be to make -fno-strict-alias the default.  But that penalizes
the users that make the effort to learn the rule.

I think that we don't disagree on general philosophy, only where to draw
the line.

Re: type based aliasing again

[Richard Stallman]

    My comment is similar to Mark's comment.  Documentation, what can we
    document as working?

We should not even try to document that these cases work.
Documentation is what we do when we add a feature.

I am not proposing this as a feature, just as a way to avoid evitable
trouble for users.  We should not even try to document a class of
cases that are "supposed" to work, because I'm not saying these
are "supposed" to work.  We should just let them work.

    Anway, more questions from me than answers...  Off hand though, if we
    can make the compiler generate `right' code in more cases, even if the
    users code is wrong, I think we should probably do it.

In C, we cannot divide all user code into "right" and "wrong" in this
kind of simple way, and certainly not based on the ISO standard.  That
standard is just the decisions of a certain committee (which I was a
member of) about what cases conforming compilers should commit to
support.  We must not let ourselves start thinking that C code is
"wrong", just because it is not conforming ISO C code.

C programs use many cases that are not conforming, but do work.  This
will be true for as long as C is used, because changing it would
require major changes in the C language.

From time to time, there is a real *need* to make some of these cases
stop working, for the sake of some benefit that users want.  When this
happens, we should do it; the user community will accept it, because
they will see that it is being done for their sake.  Some will
grumble, but the users who appreciate the benefits will convince them.

But when there is no *need* to break these cases, when we can keep
them working fairly easily, we should keep them working.  If we break
them unnecessarily, we invite the legitimate anger of the users.

Re: type based aliasing again

[Mike Stump]

My comment is similar to Mark's comment.  Documentation, what can we
document as working?  Can users rely upon it working?

Is it less confusing to a user to have the compiler predictably
generate wrong code, or for it to almost always generate right code,
even for bad code, except in really obscure and hard to understand
cases?

Anway, more questions from me than answers...  Off hand though, if we
can make the compiler generate `right' code in more cases, even if the
users code is wrong, I think we should probably do it.  I say this not
with a language designer's hat on, but as someone that has to support
users with possibly broken code.  Kind of a quick fix to get them to
leave me alone.