Re: type based aliasing again

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]

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

[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

[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

__typealias qualifier (was Re: type based aliasing again)

[patl]

>>>>> "mark" == Mark Mitchell <mark@codesourcery.com> writes:

 mark> I'm not convinced we need to provide a "have your cake and eat
 mark> it too" mode where you can get the benefits of the optimization
 mark> without having conforming code.  Even if you go to the troule
 mark> of adding some extra type-qualifiers, attributes, etc.,
 mark> somewhere.

Are you prepared to be convinced, or have you already made up your
mind?

 mark> Especially now that people are providing implementations of
 mark> helpful warnings, it seems fair to say "use
 mark> -fno-strict-aliasing (either because that's the default, or
 mark> otherwise) or else write conforming code".

At least a few users (e.g., Linus) disagree with you.  The code where
`__typealias' is most useful is precisely the most
performance-critical, where the programmer wants to get at memory as
raw bytes.  On a modern machine, you do this with int *, not char *.

 mark> Historically, most of our language extensions have proven
 mark> ill-specified, to have slightly odd behavior, to significantly
 mark> complicate the compiler, etc.  

I would prefer for the `__typealias' proposal to be judged on its own
merits, not on its ethnic group.

Of course, history is a useful guide.  I agree that this extension
needs be well-specified, have well-thought-out behavior, and to have a
benefit which is worth the maintenance cost.  So let's discuss these!

 mark> I'm not commenting on any specific proposal, but it's very,
 mark> very hard to get new language features right.  There tends to
 mark> be a huge maintenance cost.

But we *have* a specific proposal, with a precise spec, a prototype
implementation, and a fair rationale.  Why not debate that proposal,
instead of resorting to general arguments?

 mark> IMO, the last thing we want to do is to make GNU C a dialect
 mark> even more divergent from ANSI/ISO C.

This argues against any new extension whatsoever.  If this is the only
argument against `__typealias' and it turns out to be suffient, you
should probably document somewhere that no new GCC extensions will
ever be accepted.  It would save people's time.

 - Pat

Re: __typealias qualifier (was Re: type based aliasing again)

[Mark Mitchell]

>>>>> "Patrick" == Patrick J LoPresti <patl@cag.lcs.mit.edu> writes:

    mark> I'm not convinced we need to provide a "have your cake and
    mark> eat it too" mode where you can get the benefits of the
    mark> optimization without having conforming code.  Even if you go
    mark> to the troule of adding some extra type-qualifiers,
    mark> attributes, etc., somewhere.

    Patrick> Are you prepared to be convinced, or have you already
    Patrick> made up your mind?

The former, but I am strongly disinclined on general principles.  As
if, say, you generally find that when you ride a bicycle you tend to
hurt yourself, but now someone promises you won't hurt yourself on
this particular snazzy bicycle.  I'm willing to listen, but my
experience tells me bicycles are dangerous, speaking metaphorically.

    mark> I'm not commenting on any specific proposal, but it's very,
    mark> very hard to get new language features right.  There tends
    mark> to be a huge maintenance cost.

    Patrick> But we *have* a specific proposal, with a precise spec, a
    Patrick> prototype implementation, and a fair rationale.  Why not
    Patrick> debate that proposal, instead of resorting to general
    Patrick> arguments?

I've been embroiled in *another* debate.  My time is limited; I can
only devote so much of it to debating.

However, I will say that I have yet to see an example that convinces
me that even the Linux kernel needs to have its cake and eat it too.
THe fast memcpy thing is a bad example; you should work on getting GCC
to optimize this for you, instead, via its support for builtin
functions, I think.  We need the example before even beginning to
consider the extension itself.  And we need to know why no other
alternative already supported by GCC (such as standard ANSI/ISO C, or
inline assembly) will do the trick in a satisfactory way.

    Patrick> This argues against any new extension whatsoever.  If
    Patrick> this is the only argument against `__typealias' and it
    Patrick> turns out to be suffient, you should probably document
    Patrick> somewhere that no new GCC extensions will ever be
    Patrick> accepted.  It would save people's time.

I think there are very, very few new extensions that we should accept.
Especially until we do a really good job implementing and optimizing
ANSI/ISO C and C++.  It is not in the best interests of the compiler
or our users to promulgate odd extensions to GNU C.

Portability is an issue, even for GNU programs.  Practially, they are
sometimes compiled with non-GCC compilers, which often give better
performance.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: __typealias qualifier (was Re: type based aliasing again)

[Mark Mitchell]

>>>>> "Patrick" == Patrick J LoPresti <patl@cag.lcs.mit.edu> writes:

    mark> I'm not convinced we need to provide a "have your cake and
    mark> eat it too" mode where you can get the benefits of the
    mark> optimization without having conforming code.  Even if you go
    mark> to the troule of adding some extra type-qualifiers,
    mark> attributes, etc., somewhere.

    Patrick> Are you prepared to be convinced, or have you already
    Patrick> made up your mind?

The former, but I am strongly disinclined on general principles.  As
if, say, you generally find that when you ride a bicycle you tend to
hurt yourself, but now someone promises you won't hurt yourself on
this particular snazzy bicycle.  I'm willing to listen, but my
experience tells me bicycles are dangerous, speaking metaphorically.

    mark> I'm not commenting on any specific proposal, but it's very,
    mark> very hard to get new language features right.  There tends
    mark> to be a huge maintenance cost.

    Patrick> But we *have* a specific proposal, with a precise spec, a
    Patrick> prototype implementation, and a fair rationale.  Why not
    Patrick> debate that proposal, instead of resorting to general
    Patrick> arguments?

I've been embroiled in *another* debate.  My time is limited; I can
only devote so much of it to debating.

However, I will say that I have yet to see an example that convinces
me that even the Linux kernel needs to have its cake and eat it too.
THe fast memcpy thing is a bad example; you should work on getting GCC
to optimize this for you, instead, via its support for builtin
functions, I think.  We need the example before even beginning to
consider the extension itself.  And we need to know why no other
alternative already supported by GCC (such as standard ANSI/ISO C, or
inline assembly) will do the trick in a satisfactory way.

    Patrick> This argues against any new extension whatsoever.  If
    Patrick> this is the only argument against `__typealias' and it
    Patrick> turns out to be suffient, you should probably document
    Patrick> somewhere that no new GCC extensions will ever be
    Patrick> accepted.  It would save people's time.

I think there are very, very few new extensions that we should accept.
Especially until we do a really good job implementing and optimizing
ANSI/ISO C and C++.  It is not in the best interests of the compiler
or our users to promulgate odd extensions to GNU C.

Portability is an issue, even for GNU programs.  Practially, they are
sometimes compiled with non-GCC compilers, which often give better
performance.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

__typealias qualifier (was Re: type based aliasing again)

[Patrick J. LoPresti]

>>>>> "mark" == Mark Mitchell <mark@codesourcery.com> writes:

 mark> I'm not convinced we need to provide a "have your cake and eat
 mark> it too" mode where you can get the benefits of the optimization
 mark> without having conforming code.  Even if you go to the troule
 mark> of adding some extra type-qualifiers, attributes, etc.,
 mark> somewhere.

Are you prepared to be convinced, or have you already made up your
mind?

 mark> Especially now that people are providing implementations of
 mark> helpful warnings, it seems fair to say "use
 mark> -fno-strict-aliasing (either because that's the default, or
 mark> otherwise) or else write conforming code".

At least a few users (e.g., Linus) disagree with you.  The code where
`__typealias' is most useful is precisely the most
performance-critical, where the programmer wants to get at memory as
raw bytes.  On a modern machine, you do this with int *, not char *.

 mark> Historically, most of our language extensions have proven
 mark> ill-specified, to have slightly odd behavior, to significantly
 mark> complicate the compiler, etc.  

I would prefer for the `__typealias' proposal to be judged on its own
merits, not on its ethnic group.

Of course, history is a useful guide.  I agree that this extension
needs be well-specified, have well-thought-out behavior, and to have a
benefit which is worth the maintenance cost.  So let's discuss these!

 mark> I'm not commenting on any specific proposal, but it's very,
 mark> very hard to get new language features right.  There tends to
 mark> be a huge maintenance cost.

But we *have* a specific proposal, with a precise spec, a prototype
implementation, and a fair rationale.  Why not debate that proposal,
instead of resorting to general arguments?

 mark> IMO, the last thing we want to do is to make GNU C a dialect
 mark> even more divergent from ANSI/ISO C.

This argues against any new extension whatsoever.  If this is the only
argument against `__typealias' and it turns out to be suffient, you
should probably document somewhere that no new GCC extensions will
ever be accepted.  It would save people's time.

 - Pat

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.