Re: module level flags

Re: module level flags

[Robert Dewar]

Joe sent a message addressed to me in which it looked as if I said

> <<It's not a matter of not wanting to learn the rules.  It's a matter
> of dealing with massive amounts of legacy code written before the
> aliasing optimizations were devised.  This is a change in the C
> language that is only a very few years old.  Silently biting people
> isn't the way to do it.
> >>

I trust everyone reaslizes that this is not the case, I was quoting from
the one person in this thread who has this viewpoint :-) :-)

Re: module level flags

[Gabriel Dos Reis]

Nathan Sidwell <nathan@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| > kaih@khms.westfalen.de (Kai Henningsen) writes:
| > | -Wsuspicious-casts?
| >    -Wtype-punning
| I think it should be -Wstrict-aliasing, as it goes with -fstrict-aliasing.

Excellent.  Thanks!

-- Gaby

Re: module level flags

[Nathan Sidwell]

Gabriel Dos Reis wrote:
> kaih@khms.westfalen.de (Kai Henningsen) writes:
> | -Wsuspicious-casts?
>    -Wtype-punning
I think it should be -Wstrict-aliasing, as it goes with -fstrict-aliasing.
I'm implementing that. (it will be a member of -Wall)

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: module level flags

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

[...]

| -Wsuspicious-casts?

Well, I very don't like anything along the lines "legal, illegal,
suspicious" with diagnotics.  

What about 

   -Wtype-punning

since type-punning seems to be the consacreated name?


-- Gaby

Re: module level flags

[Kai Henningsen]

geoffk@geoffk.org (Geoff Keating)  wrote on 01.10.02 in <jmd6quugp0.fsf@desire.geoffk.org>:

> int *ip = (int *)dp;

> I think that generally, such warnings are helpful even if they aren't
> 100% perfect.  The usual reason such errors are introduced into
> programs are not that the programmer made a mistake in applying the
> appropriate rule, it's that the programmer wasn't aware that the rule
> existed.  Thus, the warnings help to educate programmers, and
> hopefully they will be educated enough that they don't make the
> mistakes that the compiler can't catch.

-Wsuspicious-casts?

MfG Kai

Re: module level flags

[Toon Moene]

Robert Dewar wrote:

 > Bruce Korb wrote:

> <<It's not a matter of not wanting to learn the rules.  It's a matter
> of dealing with massive amounts of legacy code written before the
> aliasing optimizations were devised.  This is a change in the C
> language that is only a very few years old.  Silently biting people
> isn't the way to do it.

> -fno-strict-aliasing is precicsely meant to deal with ":massive
> amounts of legacy code written before the aliasing o[ptimziations were devised".
> Why should you be reluctant to use it.

The interesting thing about this discussion is that we went through it 3 
years ago (in 1999) and no *new* argument has been brought up so far.

[ adequately summarized by Robert Dewar. ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: module level flags

[Richard Henderson]

On Thu, Oct 03, 2002 at 04:50:40PM -0700, Zack Weinberg wrote:
> I believe that in other such cases, current practice is to issue a
> warning and replace just the offending operation with a call to
> abort(), which is nice and conservative.  For instance, look at stmt.c
> (expand_nl_goto_receivers).  I thought there was a case like this in
> the C++ front end but I can't find it just now.

There's one in the va_arg code.


r~

Re: module level flags

[Zack Weinberg]

On Wed, Oct 02, 2002 at 12:13:25PM -0700, Joe Buck wrote:
> 
> My suggestion was that in cases that are always an error (assuming that
> the function gets called at all), we might as well issue a hard error.
> "But the function might never be called", you reply.  So what?  In
> principle the compiler could replace the whole function by abort(),
> but I see no practical (as opposed to pedantic) reason why issuing a hard
> error in such cases is not allowed.

I believe that in other such cases, current practice is to issue a
warning and replace just the offending operation with a call to
abort(), which is nice and conservative.  For instance, look at stmt.c
(expand_nl_goto_receivers).  I thought there was a case like this in
the C++ front end but I can't find it just now.

zw

Re: module level flags

[Joe Buck]

> > At least in the case where the bad code is always reached if the
> > function is called, a hard error might be reasonable.

Alexandre Oliva writes:
> Nope.  Consider a function that would only be called with arguments
> that were known not to run into any aliasing problems.  When the
> compiler can't tell, it is required to translate the code.

You possibly misunderstand.  I was ony suggesting a hard error for a case
that would invoke undefined behavior for *any* choice of arguments.

That is, for any analysis question that runs into the halting problem,
or is just too complex to solve, one can write a heuristic that gives
a three-way answer: always an error, never an error, or "can't tell".
But there are plenty of "always an error" cases, where you can tell
by inspection that an object is accessed with the wrong type.

My suggestion was that in cases that are always an error (assuming that
the function gets called at all), we might as well issue a hard error.
"But the function might never be called", you reply.  So what?  In
principle the compiler could replace the whole function by abort(),
but I see no practical (as opposed to pedantic) reason why issuing a hard
error in such cases is not allowed.

Re: module level flags

[Michael Matz]

Hi,

On Tue, 1 Oct 2002, Joe Buck wrote:

> Can any folks from Red Hat or elsewhere comment on how many violations
> they found when they first switched to compilers that implement
> strict-aliasing by default?

I can't comment on all of SuSE's packages, but at least we didn't run into
_that_ many failures, or at least didn't noticed them yet (OTOH we went
straight from 2.95.3 to 3.2, so some of them might have been fixed at that
time already).  But XFree86 (or at least some drivers of it) definitely
violates aliasing rules, and IIRC an interpreter of a functional language
(don't remember which, but it isn't an rpm on the distribution).  A quick
grep through all our .spec files and diffs over most of the current
packages reveals for instance, that only sendmail and xf86 are compiled
with no-strict-aliasing currently.  The kernel of course too.


Ciao,
Michael.

Re: module level flags

[Joe Buck]

> <<It's not a matter of not wanting to learn the rules.  It's a matter
> of dealing with massive amounts of legacy code written before the
> aliasing optimizations were devised.  This is a change in the C
> language that is only a very few years old.  Silently biting people
> isn't the way to do it.
> >>

This is incorrect: similar language is in the C89 standard (though someone
quoted you the version in C99).  It's 13 years old.

> Neither is deoptimizing the code in a manner that results in 
> not taking advantage of this feature of the standard.
> 
> -fno-strict-aliasing is precicsely meant to deal with ":massive
> amounts of legacy code written before the aliasing o[ptimziations were devised".
> Why should you be reluctant to use it.
> 
> Mind you, the code we are talking about here is not "massive amounts of legacy
> code written before ...", but jsut one program with an obvious bug
> that is easily fixed!

Can any folks from Red Hat or elsewhere comment on how many violations
they found when they first switched to compilers that implement
strict-aliasing by default?

Re: module level flags

[Alexandre Oliva]

On Oct  1, 2002, Joe Buck <Joe.Buck@synopsys.com> wrote:

> In practice, the case for unions will be supported by all compilers that
> are acceptable to users: code to use unions to get at the bit-level
> representation of floating-point numbers is required, and it is
> well-understood to be implementation-dependent.  Without the ability to
> write unions one way and read them another way, it's not possible to
> write IEEE isnan() or isinf() routines in C; assembly would be needed.

Unless you use volatile.

>> A hard error would probably be inappropriate, since the compiler can't
>> tell in general whether the code in question would actually be
>> executed, a condition necessary for the undefined behavior to actually
>> be invoked.

> At least in the case where the bad code is always reached if the
> function is called, a hard error might be reasonable.

Nope.  Consider a function that would only be called with arguments
that were known not to run into any aliasing problems.  When the
compiler can't tell, it is required to translate the code.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: module level flags

[Alexandre Oliva]

On Oct  1, 2002, Bruce Korb <bkorb@pacbell.net> wrote:

> This is a change in the C language

AFAIK, it has always been undefined behavior.  It's just that
compilers used not to take advantage of it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: module level flags

[Robert Dewar]

<<It's not a matter of not wanting to learn the rules.  It's a matter
of dealing with massive amounts of legacy code written before the
aliasing optimizations were devised.  This is a change in the C
language that is only a very few years old.  Silently biting people
isn't the way to do it.
>>

Neither is deoptimizing the code in a manner that results in 
not taking advantage of this feature of the standard.

-fno-strict-aliasing is precicsely meant to deal with ":massive
amounts of legacy code written before the aliasing o[ptimziations were devised".
Why should you be reluctant to use it.

Mind you, the code we are talking about here is not "massive amounts of legacy
code written before ...", but jsut one program with an obvious bug
that is easily fixed!

Re: module level flags

[Bruce Korb]

Joe Buck wrote:

> Use -fno-strict-aliasing if you don't want to learn the rules.
> Your code may be slower, but no matter.

It's not a matter of not wanting to learn the rules.  It's a matter
of dealing with massive amounts of legacy code written before the
aliasing optimizations were devised.  This is a change in the C
language that is only a very few years old.  Silently biting people
isn't the way to do it.

Re: module level flags

[Geoff Keating]

Joe Buck <Joe.Buck@synopsys.com> writes:

> There is an argument for attempting to detect obvious cases of error, and
> this would help users.  Some developers have objected that because not all
> errors can be detected, this would give users a false sense of security
> when they don't see any aliasing warnings.

No-one has objected to someone adding a flag that detects certain
"obvious" cases of violating the aliasing rules.  At least one patch
was posted in 1999 by Zack, but it never quite worked well enough to
go in the tree.

In fact, I believe there was some consensus that it's even OK to warn
about such constructs as:

double *dp;
int *ip = (int *)dp;

even though that's not an immediate problem, since it is at least very
suspicious.  The flag would not be on by default, of course.

Amusingly, it used to be that GCC had lots of constructs like that,
but I think I've cleaned up many of them as part of the new GC work.


I think that generally, such warnings are helpful even if they aren't
100% perfect.  The usual reason such errors are introduced into
programs are not that the programmer made a mistake in applying the
appropriate rule, it's that the programmer wasn't aware that the rule
existed.  Thus, the warnings help to educate programmers, and
hopefully they will be educated enough that they don't make the
mistakes that the compiler can't catch.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: module level flags

[Joe Buck]

[ aliasing rules ]
> FWIW, the fact that it works for unions is a GCC extension.  It is not
> guaranteed to work by the ISO C Standard, since, by the Standard,
> using a member of the union that was not the one that you initialized
> also invokes undefined behavior (unless you're accessing a common
> prefix of two different structs, yadda, yadda).

In practice, the case for unions will be supported by all compilers that
are acceptable to users: code to use unions to get at the bit-level
representation of floating-point numbers is required, and it is
well-understood to be implementation-dependent.  Without the ability to
write unions one way and read them another way, it's not possible to
write IEEE isnan() or isinf() routines in C; assembly would be needed.

> > So, to protect users from this catastrophe, you silently destroy
> > the efficacy of a pointer causing their programs to head south
> > without a discernible error or even a warning.
> 
> The program in question is wrong, and such errors can't be detected in
> general.  Of course detecting it in the few situations in which it is
> possible would be a useful contribution to GCC, but the cases in which
> it's really not obvious where the error is, the compiler is very
> unlikely to be able to figure it out either, because it would require
> information from multiple translation units.
> 
> > That's not a sufficient excuse for throwing up your
> > hands on being helpful and silently generate trash.
> 
> Garbage in, garbage out.

There is an argument for attempting to detect obvious cases of error, and
this would help users.  Some developers have objected that because not all
errors can be detected, this would give users a false sense of security
when they don't see any aliasing warnings.

> > either emit working code (as I suggest), or emit a hard error.

Use -fno-strict-aliasing if you don't want to learn the rules.  Your code
may be slower, but no matter.

> A hard error would probably be inappropriate, since the compiler can't
> tell in general whether the code in question would actually be
> executed, a condition necessary for the undefined behavior to actually
> be invoked.

At least in the case where the bad code is always reached if the function
is called, a hard error might be reasonable.

Re: module level flags

[Bruce Korb]

Alexandre Oliva wrote:
> 
> On Sep 29, 2002, Bruce Korb <bkorb@pacbell.net> wrote:
> 
> > In this case, the issue is that the aliasing analysis is incomplete.
> > If a routine contains explicit code to cast the address of an object
> > of type 'a' to pointers to type b, then in the context of that
> > routine it is reasonable to presume a '*b' can refer an object 'a'.
> > They are equivalent.
> 
> Now what if you factor the code that uses *b into a separate function?

You have that problem with "void*" aliasing or any other kind of
aliasing.  Some you are required to guard against (assume aliasing),
some not.  My claim is that ANSI ought to have considered intptr_t
as being potentially aliased by arbitrary pointers, _exactly_ the
same way void* values are treated.  And, my argument went on, if
you aren't going to support "obvious" cases such as this, then you
should support hard errors on obvious cases.  It is clear you cannot
warn about all potential cases.

> All of a sudden, the code stops working because within that separate
> function it is not known that *b may alias an object of type stumble?

So, to protect users from this catastrophe, you silently destroy
the efficacy of a pointer causing their programs to head south
without a discernible error or even a warning.  Phooey.  It is true
you can stretch stuff into improbable cases whereby you cannot
effectively warn; you cannot detect the aliasing; and you wind up
with a bug.  That's not a sufficient excuse for throwing up your
hands on being helpful and silently generate trash.

Here's what it comes down to:  where feasible (99% of cases),
either emit working code (as I suggest), or emit a hard error.
But at least warn.  Currently, it's none of these.

Re: module level flags

[Alexandre Oliva]

On Sep 29, 2002, Bruce Korb <bkorb@pacbell.net> wrote:

> In this case, the issue is that the aliasing analysis is incomplete.
> If a routine contains explicit code to cast the address of an object
> of type 'a' to pointers to type b, then in the context of that
> routine it is reasonable to presume a '*b' can refer an object 'a'.
> They are equivalent.

Now what if you factor the code that uses *b into a separate function?
All of a sudden, the code stops working because within that separate
function it is not known that *b may alias an object of type stumble?

Now you try to fix this, and you end up either giving up any possible
optimization that the aliasing rules were designed to offer, or
something that is not uniformly consistent, or you choose the behavior
that may seem wrong if you don't take the aliasing rules into account.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: module level flags

[Tom Tromey]

>>>>> "Bruce" == Bruce Korb <bkorb@pacbell.net> writes:

Bruce> 2.  lobby for automake to support spitting out specialized
Bruce> rules when it sees ``autogen_defReduce_c_CFLAGS = -O0''.

This is PR automake/321.

Bruce> Hopefully, it (or libtool) is smart enough to strip extra
Bruce> optimizer specs for compilers that choke and respell them for
Bruce> other compilers.

I find it unlikely that this will ever happen.

Tom

Re: module level flags

[Geoff Keating]

Bruce Korb <bkorb@pacbell.net> writes:

> Zack Weinberg wrote:
> 
> > I'm afraid the compiler is working as designed.
> > 
> > >          YYSTYPE  def,
> > >          YYSTYPE  list )
> > >  {
> > > +    tDefEntry*  ret   = (tDefEntry*)list;
> > >      tDefEntry*  pDef  = (tDefEntry*)def;
> > > -    tDefEntry*  pScn  = (tDefEntry*)list;
> > > -    tDefEntry** ppT   = (tDefEntry**)&list;
> > > +    tDefEntry*  pScn  = ret;
> > > +    tDefEntry** ppT   = &ret;
> > 
> > In the original code, the type-based aliasing rules permit the
> > compiler to assume that assignment to ppT does not modify list
> > EVEN THOUGH IT IS OBVIOUS TO A HUMAN THAT IT DOES.
> > 
> > Your fix is the right way to correct your code.  By immediately
> > assigning list to a temporary with its true type, you show the
> > compiler what's really going on.
> 
> That is completely goofy.  Is that really the intent of the
> official standard, or GCC's interpretation?

Yes, that's the intent of the official standard.

There's no guarantee that two pointers to different types have the
same representation.  For instance, if you have

tDefEntry foo;
void *x;

*(tDefEntry **)&x = &foo;
if (x != (void *)&foo)
  abort();

this could call abort, or do anything else (since it invokes undefined
behavior).

In fact, there's no guarantee even that 'sizeof (void *)' is the same
as 'sizeof (tDefEntry *)'.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: module level flags

[Russ Allbery]

Robert Dewar <dewar@gnat.com> writes:

> By the way it certainly seems that YACC is incorrect here in its
> approach, and at the very least should discuss the implications of its
> choice for YYSTYPE.

A simple define of YYSTYPE to a single C type is only appropriate for very
simple parsers where all tokens return the same type data.  Any more
complex parser should use the %union directive, which declares YYSTYPE as
a union type.  This is stated in the bison manual, although not in
precisely that way (instead, the bison manual shows using %union
everywhere and only mentions in one side page that for very simple parsers
you can define YYSTYPE instad).

By using a simple YYSTYPE when YYSTYPE is actually storing multiple
different data types, you're lying to the compiler, and it's unsurprising
that things break.  It's not portable, may not work at all on platforms
where pointers can not be stored safely in integral types, requires
unnecessary casts, and destroys what type checking the C compiler is able
to do, even apart from the aliasing concerns.

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

Re: module level flags

[Russ Allbery]

Bruce Korb <bkorb@pacbell.net> writes:

> On which platform?  The answer is:  it depends.
> On my particular platform, the compliler "t_word".
> It has previously seen, "typedef int t_word;".
> On my Solaris 2.8 box, it would be a 64 bit sized bucket.

It sounds like your yacc source file is missing a %union directive.  If
you add one and make the corresponding changes to your source code, I
believe that gcc will understand what you're intending to do because the
result will be correct C code.

This was how I was taught to write yacc parsers nearly ten years ago.
It's certainly not a new concept.

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

Re: module level flags

[Robert Dewar]

I completely agree with Zack when he says

>  This is my last word on the subject - I don't have time for the
>  argument.  However, your repeated assertion that "the intended use" of
>  YYSTYPE is in a manner incompatible with the C standard is
>  indefensible.  You've *chosen* to define YYSTYPE as "int" in a parser
>  that actually wants to store one of several different pointer types in
>  that data type.  You should never have expected this to work.  The
>  Bison manual could perhaps be worded more strongly, but it is clear
>  enough that one must use %union and %type in a parser of this form.
>  (These directives are supported by all modern versions of Yacc, so
>  portability is not an excuse here.)

my comment that there was an error in the YACC approach was entirely
incorrect, sorry about that confusion!

Re: module level flags

[Zack Weinberg]

This is my last word on the subject - I don't have time for the
argument.  However, your repeated assertion that "the intended use" of
YYSTYPE is in a manner incompatible with the C standard is
indefensible.  You've *chosen* to define YYSTYPE as "int" in a parser
that actually wants to store one of several different pointer types in
that data type.  You should never have expected this to work.  The
Bison manual could perhaps be worded more strongly, but it is clear
enough that one must use %union and %type in a parser of this form.
(These directives are supported by all modern versions of Yacc, so
portability is not an excuse here.)

Fix your code.

zw

Re: module level flags

[Robert Dewar]

By the way it certainly seems that YACC is incorrect here in its approach,
and at the very least should discuss the implications
of its choice for YYSTYPE.

Re: module level flags

[Robert Dewar]

<<On which platform?  The answer is:  it depends.
On my particular platform, the compliler "t_word".
It has previously seen, "typedef int t_word;".
On my Solaris 2.8 box, it would be a 64 bit sized bucket.
>>

Right, and clearly for this definition yoru code was incorrect from the
standard. If you don't like this semantics,clearly document that you are not writing
in C, and turn off strict aliasing.

Re: module level flags

[Bruce Korb]

Robert Dewar wrote:
> 
> <<YYSTYPE is a bucket designed by YACC (Bison) to carry
> either a pointer (of any sort) or a scalar.
> >>
> 
> Well that sure evaded the question!
> What is the type definition of YYSTYPE?

On which platform?  The answer is:  it depends.
On my particular platform, the compliler "t_word".
It has previously seen, "typedef int t_word;".
On my Solaris 2.8 box, it would be a 64 bit sized bucket.

Re: module level flags

[Robert Dewar]

<<YYSTYPE is a bucket designed by YACC (Bison) to carry
either a pointer (of any sort) or a scalar.
>>

Well that sure evaded the question!
What is the type definition of YYSTYPE?

Re: module level flags

[Daniel Jacobowitz]

On Sun, Sep 29, 2002 at 01:06:34PM -0700, Bruce Korb wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Sun, Sep 29, 2002 at 10:22:16AM -0700, Bruce Korb wrote:
> > > Gabriel Dos Reis wrote:
> > > > | If the standard says otherwise, then this construct:
> > > > |
> > > > |    (mumble*)&stumble
> > > > |
> > > > | where 'stumble' is not of type 'mumble' must be deemed a
> > > > | hard error.
> > > >
> > > > Not necessarily.  The C abstract machine has a notion of "effective
> > > > type" and "compatible type".
> > >
> > > By golly, YYSTYPE darn well better be compatible with
> > > arbitrary pointers or there are real problems.
> > 
> > What is a YYSTYPE?  A union pointer?  A char *?  If it's a char *, as
> > the language suggests it should be, then you're OK.  If it's a union*
> > you should be accessing the appropriate union member, not casting.
> 
> YYSTYPE is a bucket designed by YACC (Bison) to carry
> either a pointer (of any sort) or a scalar.

I'm aware of that.  But what is the underlying type that it uses?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: module level flags

[Bruce Korb]

Zack Weinberg wrote:
> For reference, I believe the relevant section of C99 is section 6.5,
> paragraphs 6 and 7, and associated footnotes:
> 
>   6 ...
>   7 ...
> The code under discussion took the form
> 
> T foo (T arg)
> {
>   U *ptr = (U *) &arg;
>   *ptr = new_value();
>   return arg;
> }
> 
> where T and U are incompatible types.  The construct clearly does not
> satisfy any of the possibilities in 6.5p7, so undefined behavior
> results.
> 
> Bruce argues that since it is obvious what 'ptr' points to, that
> information should override the rules in 6.5p7.  The trouble with this
> argument is defining what qualifies as obvious.

I was meaning to argue that since a type 'T' was specifically cast
into a 'U', that within the context of 'foo', 'T' and 'U' should
be construed as aliasable.  "Seems obvious to me."  :-)

Failing that, 'T' is really compatible with any pointer type,
much like 'void*'.  The example is really:

> T foo (T arg)
> {
>   U**ptr = (U**) &arg;
>   while ((*ptr) -> next) != NULL)  ptr = (*ptr) -> next;
>   *ptr = new_value();
>   return arg;
> }

and that this is the intended usage for YYSTYPE (er, 'T').
So, if the first proposal is "too hard", then the backup
is to consider all scalars where ``sizeof(scalar)'' is
that of ``sizeof(void*)'' to be aliasable by any pointer.
This is *exactly* equivalent to the current aliasing 
treatment of ``void*'' and ``char*''.

What it really boils down to is this:  programming is hard.
Anything that makes understanding slippery or obtuse needs
to be reduced or eliminated to the greatest degree possible.
When you make an assignment like this:

>   U**ptr = (U**) &arg;

*especially* since it is encouraged by YACC, it is not obvious
that the compiler is going to take it upon itself to render the
pointer useless.  Worse, sometimes it will, sometimes it won't.
Worse still, it accepts it as completely valid and destroys
the result, leaving a program producing inscrutable results.

> I'd also like to point out that we have had this argument before.  See
> e.g. http://gcc.gnu.org/ml/gcc/1999-09/msg00316.html and the very long
> thread which followed, and please notice that the subject line is
> "type based aliasing *again*" (emphasis mine).

In that thread:
http://gcc.gnu.org/ml/gcc/1999-09/msg00323.html
Joe Buck wrote:
> 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)

It seems we have chosen "B".  That's why I am squawking.

And John Vickers:(msg00381.html)
> 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.

Joe Buck:(msg00383.html)
> 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.

RMS & Jeff Law(msg00400.html)
>   > 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.

Now, you do.  Programs using YACC or tools with a similar interfaces
are suspect.  Just make pointer sized scalars aliasable by pointers.
"enhance" the ANSI spec.

RMS wrote:
http://gcc.gnu.org/ml/gcc/1999-09/msg00398.html
Yes!
http://gcc.gnu.org/ml/gcc/1999-09/msg00393.html
And yes again!

I'm tired now.  If GCC won't change and Bison produces non-aliasable
arguments, then I'll mess with autoconf/automake to have it suppress
alias analysis.  Trouble is, it would apply only to GCC 3.x and
following compilers.  What a waste.

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net

Re: module level flags

[Bruce Korb]

Daniel Jacobowitz wrote:
> 
> On Sun, Sep 29, 2002 at 10:22:16AM -0700, Bruce Korb wrote:
> > Gabriel Dos Reis wrote:
> > > | If the standard says otherwise, then this construct:
> > > |
> > > |    (mumble*)&stumble
> > > |
> > > | where 'stumble' is not of type 'mumble' must be deemed a
> > > | hard error.
> > >
> > > Not necessarily.  The C abstract machine has a notion of "effective
> > > type" and "compatible type".
> >
> > By golly, YYSTYPE darn well better be compatible with
> > arbitrary pointers or there are real problems.
> 
> What is a YYSTYPE?  A union pointer?  A char *?  If it's a char *, as
> the language suggests it should be, then you're OK.  If it's a union*
> you should be accessing the appropriate union member, not casting.

YYSTYPE is a bucket designed by YACC (Bison) to carry
either a pointer (of any sort) or a scalar.

Re: module level flags

[Daniel Jacobowitz]

On Sun, Sep 29, 2002 at 10:22:16AM -0700, Bruce Korb wrote:
> Gabriel Dos Reis wrote:
> > | If the standard says otherwise, then this construct:
> > |
> > |    (mumble*)&stumble
> > |
> > | where 'stumble' is not of type 'mumble' must be deemed a
> > | hard error.
> > 
> > Not necessarily.  The C abstract machine has a notion of "effective
> > type" and "compatible type".
> 
> By golly, YYSTYPE darn well better be compatible with
> arbitrary pointers or there are real problems.

What is a YYSTYPE?  A union pointer?  A char *?  If it's a char *, as
the language suggests it should be, then you're OK.  If it's a union*
you should be accessing the appropriate union member, not casting.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: module level flags

[Zack Weinberg]

On Sun, Sep 29, 2002 at 05:40:01AM -0400, Robert Dewar wrote:
> <<In the original code, the type-based aliasing rules permit the
> compiler to assume that assignment to ppT does not modify list
> EVEN THOUGH IT IS OBVIOUS TO A HUMAN THAT IT DOES.
> >>
> 
> Zack, as far as I can tell, the compiler was not only "working as designed",
> but is in fact correctly implementing the language. A human may think
> that this code should work, but that just comes from not knowing the language
> properly. A lot of people have a low level semantic model that unfortunately
> does not correspond to the actual semantics.
> 
> I know you know this, but the wording of your message could still leave
> the impression that the compiler was somehow malfunctoining, which is
> not the case.

Yes, my wording was poorly chosen.  I did mean to convey that the
current behavior is a correct implementation of the language standard.

For reference, I believe the relevant section of C99 is section 6.5,
paragraphs 6 and 7, and associated footnotes:

  6 The effective type of an object for an access to its stored value
    is the declared type of the object, if any.(72) If a value is
    stored into an object having no declared type through an lvalue
    having a type that is not a character type, then the type of the
    lvalue becomes the effective type of the object for that access
    and for subsequent accesses that do not modify the stored value.
    If a value is copied into an object having no declared type using
    memcpy or memmove, or is copied as an array of character type,
    then the effective type of the modified object for that access and
    for subsequent accesses that do not modify the value is the
    effective type of the object from which the value is copied, if it
    has one. For all other accesses to an object having no declared
    type, the effective type of the object is simply the type of the
    lvalue used for the access.

  7 An object shall have its stored value accessed only by an lvalue
    expression that has one of the following types:(73)
      -- a type compatible with the effective type of the object,
      -- a qualified version of a type compatible with the effective
         type of the object,
      -- a type that is the signed or unsigned type corresponding to
         the effective type of the object,
      -- a type that is the signed or unsigned type corresponding to a
         qualified version of the effective type of the object,
      -- 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
      -- a character type.

  footnotes
  72) Allocated objects have no declared type.
  73) The intent of this list is to specify those circumstances in
      which an object may or may not be aliased.

The code under discussion took the form

T foo (T arg)
{
  U *ptr = (U *) &arg;

  *ptr = new_value();

  return arg;
}

where T and U are incompatible types.  The construct clearly does not
satisfy any of the possibilities in 6.5p7, so undefined behavior
results.

Bruce argues that since it is obvious what 'ptr' points to, that
information should override the rules in 6.5p7.  The trouble with this
argument is defining what qualifies as obvious.  Data flow analysis
can determine this sort of fact, with difficulty ranging from easy (as
in this example) to undecidable (in the general case).  The C
committee decided not to make the correctness of a program depend on
how clever the optimizer is.  IMHO, this was the right decision from
their point of view.

I'd also like to point out that we have had this argument before.  See
e.g. http://gcc.gnu.org/ml/gcc/1999-09/msg00316.html and the very long
thread which followed, and please notice that the subject line is
"type based aliasing *again*" (emphasis mine).

zw

Re: module level flags

[Gabriel Dos Reis]

Bruce Korb <bkorb@pacbell.net> writes:

| Gabriel Dos Reis wrote:
| > | If the standard says otherwise, then this construct:
| > |
| > |    (mumble*)&stumble
| > |
| > | where 'stumble' is not of type 'mumble' must be deemed a
| > | hard error.
| > 
| > Not necessarily.  The C abstract machine has a notion of "effective
| > type" and "compatible type".
| 
| By golly, YYSTYPE darn well better be compatible with
| arbitrary pointers or there are real problems.

How so?

-- Gaby

Re: module level flags

[Russ Allbery]

Bruce Korb <bkorb@pacbell.net> writes:

> Just because something is in the standard doesn't mean it is right.

I believe the flag -fno-strict-aliasing continues to be supported for
people who hold this position.

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

Re: module level flags

[Robert Dewar]

<<By golly, YYSTYPE darn well better be compatible with
arbitrary pointers or there are real problems.
>>

I don't see how you conclude that it is compatible from the rules in
the standard. Please enlighten. If you are just saying that you think
it should be compatible regardless of the standard rules, then that's a comment
on the language not on GCC. But I must say I don't in this case clearly 
understand your proposed modification to the rules in the standard (have
you looked at them?)

Re: module level flags

[Bruce Korb]

Gabriel Dos Reis wrote:
> | If the standard says otherwise, then this construct:
> |
> |    (mumble*)&stumble
> |
> | where 'stumble' is not of type 'mumble' must be deemed a
> | hard error.
> 
> Not necessarily.  The C abstract machine has a notion of "effective
> type" and "compatible type".

By golly, YYSTYPE darn well better be compatible with
arbitrary pointers or there are real problems.

> It is dereferencing
> the resulting pointer that could be deemed an error if stumble isn't
> really a mumble nor of type compatible with mumble.

That's why I went on to say,

> Of course, what is particularly obnoxious about [this]
> circumstance is that the object that triggered the issue
> is a YYSTYPE.  This is a YACC/Bison anonymous bucket.  It is
> specifically intended that it be recast as a scalar or a
> pointer to arbitrary objects.  Perhaps most of the real world
> problems would be solved by adding ``intptr_t'' and ``uintptr_t''
> to the list of ``void*'' and ``char*'' types that can be
> aliased by pointers to arbitrary things.

Re: module level flags

[Robert Dewar]

<<where 'stumble' is not of type 'mumble' must be deemed a
hard error.  If it is both not a hard error and the compiler
is reserving the "right" (??) to render the resulting pointer
ineffective, then GCC is reserving the right to destroy
the workings of a program.  This is wrong.  I don't care
if the standard says otherwise.
>>


Surely if you take this attitude you should just turn off aliasing analysis.
Really we expect gcc to implement C by default, not C + "fixes" to the
standard that Bruce Korb thinks are obviously correct.

GCC is not "reserving the right to destroy the workings of a program", 
since this program simply does not meet the semantics of C. Just because
you expect some program whose semantics is not defined by the standard
to do something, does not mean that a C compiler wlil agree with your
analysis. 

There are lots of respects in which people write non-standard C and expect 
it to work. This particular case seems to me to be one that should never
have been expected to work (i.e. I don't see any formal definition of C
that guarantees this program will work -- if I am wrong on this, please point out the document,
but do not expect me to be impressed by what some individual *thinks* the 
language should be. That's not decisive :-)

Robert Dewar

Re: module level flags

[Gabriel Dos Reis]

Bruce Korb <bkorb@pacbell.net> writes:


[...]

| If the standard says otherwise, then this construct:
| 
|    (mumble*)&stumble
| 
| where 'stumble' is not of type 'mumble' must be deemed a
| hard error.

Not necessarily.  The C abstract machine has a notion of "effective
type" and "compatible type". The cast by itself is not an error (and I
see no reason why it should be considered such).  It is dereferencing
the resulting pointer that could be deemed an error if stumble isn't
really a mumble nor of type compatible with mumble.

-- Gaby

Re: module level flags

[Bruce Korb]

Robert Dewar wrote:

> Can you justify this position from the standard?

Just because something is in the standard doesn't mean it is
right.  The committees make mistakes.  In this case, the issue is
that the aliasing analysis is incomplete.  If a routine contains
explicit code to cast the address of an object of type 'a' to
pointers to type b, then in the context of that routine it is
reasonable to presume a '*b' can refer an object 'a'.  They are
equivalent.  If the standard says otherwise, then this construct:

   (mumble*)&stumble

where 'stumble' is not of type 'mumble' must be deemed a
hard error.  If it is both not a hard error and the compiler
is reserving the "right" (??) to render the resulting pointer
ineffective, then GCC is reserving the right to destroy
the workings of a program.  This is wrong.  I don't care
if the standard says otherwise.

Of course, what is particularly obnoxious about the particular
circumstance is that the object that triggered the issue
is a YYSTYPE.  This is a YACC/Bison anonymous bucket.  It is
specifically intended that it be recast as a scalar or a
pointer to arbitrary objects.  Perhaps most of the real world
problems would be solved by adding ``intptr_t'' and ``uintptr_t''
to the list of ``void*'' and ``char*'' types that can be
aliased by pointers to arbitrary things.  That would solve my
specific problem, but I think the proper solution is to have
specific casts enable multi-type aliasing within the context
of the specific routine.

Re: module level flags

[Robert Dewar]

<<Any other interpretation is too confusing to be able to remember.
In other words, wrong.
>>

Can you justify this position from the standard?

Re: module level flags

[Robert Dewar]

<<In the original code, the type-based aliasing rules permit the
compiler to assume that assignment to ppT does not modify list
EVEN THOUGH IT IS OBVIOUS TO A HUMAN THAT IT DOES.
>>


Zack, as far as I can tell, the compiler was not only "working as designed",
but is in fact correctly implementing the language. A human may think
that this code should work, but that just comes from not knowing the language
properly. A lot of people have a low level semantic model that unfortunately
does not correspond to the actual semantics.

I know you know this, but the wording of your message could still leave
the impression that the compiler was somehow malfunctoining, which is
not the case.

Re: module level flags

[Bruce Korb]

Zack Weinberg wrote:

> I'm afraid the compiler is working as designed.
> 
> >          YYSTYPE  def,
> >          YYSTYPE  list )
> >  {
> > +    tDefEntry*  ret   = (tDefEntry*)list;
> >      tDefEntry*  pDef  = (tDefEntry*)def;
> > -    tDefEntry*  pScn  = (tDefEntry*)list;
> > -    tDefEntry** ppT   = (tDefEntry**)&list;
> > +    tDefEntry*  pScn  = ret;
> > +    tDefEntry** ppT   = &ret;
> 
> In the original code, the type-based aliasing rules permit the
> compiler to assume that assignment to ppT does not modify list
> EVEN THOUGH IT IS OBVIOUS TO A HUMAN THAT IT DOES.
> 
> Your fix is the right way to correct your code.  By immediately
> assigning list to a temporary with its true type, you show the
> compiler what's really going on.

That is completely goofy.  Is that really the intent of the
official standard, or GCC's interpretation?  This method of
dealing with untyped buckets should be entirely equivalent
to retyped void* pointers -- viz., disabling aliasing optimizations.
Any other interpretation is too confusing to be able to remember.
In other words, wrong.

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net

Re: module level flags

[Zack Weinberg]

On Sat, Sep 28, 2002 at 05:00:34PM -0700, Bruce Korb wrote:
> Zack Weinberg wrote:
> > 
> > On Sat, Sep 28, 2002 at 04:46:21PM -0700, Bruce Korb wrote:
> 
> > If you've found an optimizer bug in 3.[12] not present in 3.0 and
> > prior, you could have the courtesy to *tell us what it is* so we can
> > *fix* it.
> 
> OK:  :-)  Meanwhile, I have determined it was caused by failing
> to recognize a valid alias.

I'm afraid the compiler is working as designed.

>          YYSTYPE  def,
>          YYSTYPE  list )
>  {
> +    tDefEntry*  ret   = (tDefEntry*)list;
>      tDefEntry*  pDef  = (tDefEntry*)def;
> -    tDefEntry*  pScn  = (tDefEntry*)list;
> -    tDefEntry** ppT   = (tDefEntry**)&list;
> +    tDefEntry*  pScn  = ret;
> +    tDefEntry** ppT   = &ret;

In the original code, the type-based aliasing rules permit the
compiler to assume that assignment to ppT does not modify list
EVEN THOUGH IT IS OBVIOUS TO A HUMAN THAT IT DOES.

Your fix is the right way to correct your code.  By immediately
assigning list to a temporary with its true type, you show the
compiler what's really going on.

zw

Re: module level flags

[Bruce Korb]

Zack Weinberg wrote:
> 
> On Sat, Sep 28, 2002 at 04:46:21PM -0700, Bruce Korb wrote:

> If you've found an optimizer bug in 3.[12] not present in 3.0 and
> prior, you could have the courtesy to *tell us what it is* so we can
> *fix* it.

OK:  :-)  Meanwhile, I have determined it was caused by failing
to recognize a valid alias.  By tweaking the code, I've gotten
around the issue, so turning off optimization is not required.

==================

Thank you very much for your problem report.
It has the internal identification `c/8083'.
The individual assigned to look at your
report is: unassigned. 

>Category:       c
>Responsible:    unassigned
>Synopsis:       GCC 3.2 Optimization bug
>Arrival-Date:   Sat Sep 28 14:56:00 PDT 2002

Re: module level flags

[Zack Weinberg]

On Sat, Sep 28, 2002 at 04:46:21PM -0700, Bruce Korb wrote:
> 
> For the time being, I'll test for GCC 3.[12] and disable
> optimization for that compiler, I guess.  :-(

If you've found an optimizer bug in 3.[12] not present in 3.0 and
prior, you could have the courtesy to *tell us what it is* so we can
*fix* it.

zw

Re: module level flags

[Bruce Korb]

Tim Prince wrote:
> 
> On Saturday 28 September 2002 16:05, Bruce Korb wrote:
> > As best as I can determine, there is no easy way to say, "do
> > not optimize this particular module".  The best way would be
> > with a #pragma around the problematical function, but I'll
> > be happy with anything that does not disable optimization for
> > the entire program and does not prevent someone from overriding
> > CFLAGS for that module, either.  Suggestions?  Thanks!
> So you've ruled out the old-fashioned way of dividing your source into
> separate files, and specifying specific compile flags for the one you don't
> want optimized?  Every make-like compiler driver supports this.  Certain
> compilers support in-file specification of compile flags, subroutine by
> subroutine, and more may do so.  Do you mean something which works with all
> Fortran compilers, past, present, and future, since you haven't specified?

I was trying to do several things without getting excessively verbose.
Insead I was probably obtuse:

1.  lobby for GCC to have #pragma push_optimize 0/#pragma pop_optimize
2.  lobby for automake to support spitting out specialized rules
    when it sees ``autogen_defReduce_c_CFLAGS = -O0''.  Hopefully,
    it (or libtool) is smart enough to strip extra optimizer specs
    for compilers that choke and respell them for other compilers.
3.  not force the compilers with working optimizers to use -O0
    (This is a GCC-3.x issue.  Prior releases and other compilers
    do not have this problem.)
4.  Query the community for usual and customary practices for
    working around the issue, if there are any.

So, yes, I know about making a specialized rule.  The problem is
it also gets all tangled up in configury issues.  e.g., Sun
spells "optimize 2" as ``-xO2''.  Yummy.

For the time being, I'll test for GCC 3.[12] and disable
optimization for that compiler, I guess.  :-(

Re: module level flags

[Tim Prince]

On Saturday 28 September 2002 16:05, Bruce Korb wrote:
> As best as I can determine, there is no easy way to say, "do
> not optimize this particular module".  The best way would be
> with a #pragma around the problematical function, but I'll
> be happy with anything that does not disable optimization for
> the entire program and does not prevent someone from overriding
> CFLAGS for that module, either.  Suggestions?  Thanks!
So you've ruled out the old-fashioned way of dividing your source into 
separate files, and specifying specific compile flags for the one you don't 
want optimized?  Every make-like compiler driver supports this.  Certain 
compilers support in-file specification of compile flags, subroutine by 
subroutine, and more may do so.  Do you mean something which works with all 
Fortran compilers, past, present, and future, since you haven't specified?
-- 
Tim Prince

module level flags

[Bruce Korb]

As best as I can determine, there is no easy way to say, "do
not optimize this particular module".  The best way would be
with a #pragma around the problematical function, but I'll
be happy with anything that does not disable optimization for
the entire program and does not prevent someone from overriding
CFLAGS for that module, either.  Suggestions?  Thanks!