Re: type based aliasing again

Re: type based aliasing again

[N8TM]

> It's certainly within a reasonable "umbrella" approach of having
>  increasing optimization levels be about increasing reliance on
>  the code strictly conforming to the pertinent standard, even its
>  "tricky bits".
>  
>  The biggest problem I see with it right now is that we haven't
>  exactly taken that "umbrella" approach in the past in a consistent
>  way.

And it may not be the most useful scheme either.  With gcc-2.96 we are back 
to -Os being faster running most of the time than -O2 or -O3 on x86, with 
-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
the application) needed for best results.  We would want to continue the 
ability to get strict-aliasing at -Os.   I suppose we have no say on the 
peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
specifically turned off; always off at -Os even when it would save space.

Commercial compilers have completely broken the old scheme of things also.  
They generally accept -O but it doesn't mean much.  Maximum optimization may 
be the default (Lahey) or normal high optimization may take quite a string of 
things like -Ofast 
-OPT:fold_reassociate=OFF:IEEE_comparisons=ON:unroll_times_max=2 -TENV:X=1 
(MipsPro).  So maybe the most confusing thing about gnu is the way the 
options have changed over time without much explanation (except for 
strict-aliasing).

Tim

Re: type based aliasing again

[Marc Espie]

In article < e629bdfd.250f2c9c@aol.com > you write:
>> It's certainly within a reasonable "umbrella" approach of having
>>  increasing optimization levels be about increasing reliance on
>>  the code strictly conforming to the pertinent standard, even its
>>  "tricky bits".
>>  
>>  The biggest problem I see with it right now is that we haven't
>>  exactly taken that "umbrella" approach in the past in a consistent
>>  way.

>And it may not be the most useful scheme either.  With gcc-2.96 we are back 
>to -Os being faster running most of the time than -O2 or -O3 on x86, with 
>-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
>the application) needed for best results.  We would want to continue the 
>ability to get strict-aliasing at -Os.   I suppose we have no say on the 
>peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
>specifically turned off; always off at -Os even when it would save space.

You can always turn strict-aliasing on or off explicitly with
-fstrict-aliasing or -fno-strict-aliasing.

The only issue here is whether it should be turned on by default for -O#.

I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.
The pgcc guys can do what they want... after all, pgcc was touted as a 
very fast, highly experimental compiler. Whereas gcc is supposed to be stable.

Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
good idea. It's an issue of whether we consider this optimization as
`safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
as well, as it should decrease the code size. In the second case, I see
no reason to treat it differently from -ffast-math.

Re: type based aliasing again

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> The only issue here is whether it should be turned on by default for -O#.

Marc> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
Marc> good idea. It's an issue of whether we consider this optimization as
Marc> `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
Marc> as well, as it should decrease the code size. In the second case, I see
Marc> no reason to treat it differently from -ffast-math.

	I think that -ffast-math and the behavior of compilers from other
vendors is good precedent that -fstrict-aliasing should be removed from
the standard -O# optimization levels and accessed orthogonally.  I think
that I and the other members of the GCC Steering Committee had good
intentions, but were mistaken about the impact of including this
optimization in a -O# level. 

David

Re: type based aliasing again

[Richard Earnshaw]

dje@watson.ibm.com said:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed
> from the standard -O# optimization levels and accessed orthogonally. 

-ffast-math doesn't give any precedent at all.  -ffast-math enables 
optimizations that the relevant standards disallow.  -fstrict-aliasing 
does exactly the opposite.

Richard.

Re: type based aliasing again

[Nick Ing-Simmons]

Richard Earnshaw <richard.earnshaw@arm.com> writes:
>dje@watson.ibm.com said:
>> 	I think that -ffast-math and the behavior of compilers from other
>> vendors is good precedent that -fstrict-aliasing should be removed
>> from the standard -O# optimization levels and accessed orthogonally. 
>
>-ffast-math doesn't give any precedent at all.  

Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
which may break existing code.

>-ffast-math enables 
>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>does exactly the opposite.

But the math standard has had much longer to settle in and get adopted
in the existing code base. When new C alias standard has been around as long
as IEEE-754 then it may be time to flip the default...

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> But the math standard has had much longer to settle in and get adopted
Nick> in the existing code base. When new C alias standard has been around as long
Nick> as IEEE-754 then it may be time to flip the default...

	The recent C Standard allows the optimization but does not require
a specific behavior.  If it specified a behavior, then this would not be
an optimization.  As the behavior of this construct is undefined, this
transformation should not be enabled without explicit request from the
user.

	The FSF has stated, only just recently, that not breaking existing
programs because of undefined behavior is a goal that GCC should try to
meet.  Removing -fstrict-aliasing is a simple change that will meet this
goal and not dimish the functionality of this optimization for those who
want to invoke it explicitly.

	I think that GCC should make this simple change.

David

Re: type based aliasing again

[craig]

>Richard Earnshaw <richard.earnshaw@arm.com> writes:
>>-ffast-math enables 
>>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>>does exactly the opposite.

(That might be misinterpreted.  -ffast-math and -fstrict-aliasing both
enable optimizations.  The former enables optimizations that the relevant
standards disallows.  The latter does not.)

>But the math standard has had much longer to settle in and get adopted
>in the existing code base. When new C alias standard has been around as long
>as IEEE-754 then it may be time to flip the default...

There's a confusion in that statement that reveals why, indeed,
-ffast-math is not a precedent.

Before IEEE-754, no code was written that *required* -ffast-math.  IEEE-754
springing into existence caused programmers to start writing code that
required -fno-fast-math, however.  (Some already had been on systems --
CPU + library + compiler -- that effectively offered the same promises.)

So specifying -ffast-math is saying "My code meets requirements above
and beyond the present standards".

Specifying -fstrict-analysis is saying "My code meets the presents
standards".

I don't know the history of the C aliasing requirement, but, offhand,
it strikes me as highly unlikely that it does *not* constitute an
incompatible change vis-a-vis former revisions of the standard.

Even if so, it seems kinda silly for users to have to specify *any*
option that says "My code meets the present standards", especially
vis-a-vis the ISO C standard, when compiling code in a file with a
name like "foo.c".

        tq vm, (burley)

Re: type based aliasing again

[craig]

>	The FSF has stated, only just recently, that not breaking existing
>programs because of undefined behavior is a goal that GCC should try to
>meet.  Removing -fstrict-aliasing is a simple change that will meet this
>goal and not dimish the functionality of this optimization for those who
>want to invoke it explicitly.

I really, really doubt that removing -fstrict-aliasing is the only
change needed that will meet this goal.

I suggest the FSF, and all others who support this interpretation,
read every line of the C, C++, and Fortran standards (just for
starters), highlight every effective denotation of something the
user's code plus data can do as "undefined", and research thoroughly
what it'll take to make GCC not "break" these programs.  Division by
zero?  Square root of negative number?  Dereferencing a NULL pointer?
How about when the result isn't used?  How about writing via a NULL
pointer but never trying to read the result back?  These are all
undefined, in one language or another, and GCC will, by one
definition or another, break existing code that invokes these
undefined behaviors.

(Having spent many years now as a compiler developer, and having
hashed relevant issues out on comp.lang.fortran, I can assure you
of one thing: anyone who says "a compiler should not break an
existing program because of undefined behavior" has *not one clue*
about compiler development or standards and specifications.  If they
did, they would state it this way: "a compiler *can* not break an
existing program because of undefined behavior".  If the behavior is
undefined, nothing the compiler causes the program to do at run time
can be considered "breakage".)

(I won't even get into the stunning news that the FSF has reportedly
just changed the rules of the very difficult job of compiler development,
apparently *since* the EGCS team agreed to become GCC and under the
aegis of the FSF.)

        tq vm, (burley)

P.S. Personally, I'll just assume the FSF was misquoted.

Re: type based aliasing again

[craig]

>I don't know the history of the C aliasing requirement, but, offhand,
>it strikes me as highly unlikely that it does *not* constitute an
>incompatible change vis-a-vis former revisions of the standard.

Too many negatives, I meant "highly unlikely that it constitutes
an incompatible change...".

        tq vm, (burley)

Re: type based aliasing again

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> I don't know the history of the C aliasing requirement,
    craig> but, offhand, it strikes me as highly unlikely that it does
    craig> *not* constitute an incompatible change vis-a-vis former
    craig> revisions of the standard.

Just to clarify, the language in the standard probably dates to the
original C standard.  It is certainly not a new aspect of C9X.

That doesn't have any bearing on our decision about what to do; it's
just a fact.  This is not a change to the standard that GCC rushed to
take advantage of; it's a long-standing aspect of ANSI/ISO C.
Compilers just didn't make use of that information until the past few
years, which is why a lot of programs that broke these rules worked
OK historically.

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

Re: type based aliasing again

[Gerald Pfeifer]

Some time ago, Mark wrote:
| Saying "Don't violate ANSI/ISO aliasing rules, or else use
| -fno-strict-aliasing" is a simple, easy-to-follow rule.
and don't really see why this shouldn't be viable.

On Tue, 14 Sep 1999, David Edelsohn wrote:
> I think that GCC should make this simple change.

Instead of removing a nice and rather stable optimization for the
sake of compiling broken code, why can't we 
 1. implement warnings;
 2. document the issue in the FAQ and describe the simple workaround
    of using fno-aliasing;
 3. wait what really happens?

What I *really* wonder is: If this is breaking that much legacy code,
where are the bug reports?

After the GCC 2.95.x releases we had quite a couple of reports concerning
problems on Solaris, but I cannot remember a single one concerning the
aliasing issue!

Apart from OpenBSD which seems to have encountered a real bug, just Perl
and Linux have been mentioned (both of which are actively maintained).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: type based aliasing again

[David Edelsohn]

	Of course my description is an over-simplification of the FSF's
request.  The rest of your message describing that this is an impossible
task to get every aspect right so GCC should ignore this requirement
altogether is illogical and unhelpful.

David

Re: type based aliasing again

[Toon Moene]

Mark Mitchell wrote:

[ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer ]

> Just to clarify, the language in the standard probably dates to the
> original C standard.  It is certainly not a new aspect of C9X.

But was it new with the ANSI/ISO 89 Standard ?

> That doesn't have any bearing on our decision about what to do; it's
> just a fact.  This is not a change to the standard that GCC rushed to
> take advantage of; it's a long-standing aspect of ANSI/ISO C.

[ I do agree with the first sentence of of the above paragraph ]

The interesting question preceding is:  Did C programmers *ever* have
the opportunity to believe that the following sequence would work:

      int bla(ix)
      int *ix;
      {
         short s;
         ...
         s = (short *) ix;
         ...
      }

I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
of Changes") and nowhere they say these restrictions against using
differently typed pointers "are new with the ANSI/ISO Standard".

I don't have K&R I, so I can't check if you could possibly read into
that text that the above would be legal, or what it would mean in the
first place ...

Does anyone know this ?

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
Toon> of Changes") and nowhere they say these restrictions against using
Toon> differently typed pointers "are new with the ANSI/ISO Standard".

	This viewpoint does not cover large groups of compiler users.
Many programmers wrote code using differently typed pointers -- either
because it was natural or because they wree trying to elicit certain
behavior from the compiler.  This code behaved as expected when compiled
with GCC using default commandline flags until this latest release.  We
easily can change the behavior of GCC so that this class of users will not
be inconvenienced and those who want more aggressive optimization of
conforming code can elicint the behavior they want.  This change is
trivial.  Arguing about C standards and user expectations does not
consider how this and other compilers have behaved for years.  Those
compilers were not behaving incorrectly.

David

Re: type based aliasing again

[David Edelsohn]

>>>>> craig  writes:

craig> (I won't even get into the stunning news that the FSF has reportedly
craig> just changed the rules of the very difficult job of compiler development,
craig> apparently *since* the EGCS team agreed to become GCC and under the
craig> aegis of the FSF.)

	How is asking that the compiler try to provide compatibility by
default where it is easy, such as not coupling -fstrict-aliasing to a -O#
level, an unreasonable and burdensome request?  This is a one-line change
removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
are arguing against an interpretation of the request that takes it to an
extreme, not the request itself. 

David

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> Mark Mitchell wrote:

    Toon> [ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer
    Toon> ]

    >> Just to clarify, the language in the standard probably dates to
    >> the original C standard.  It is certainly not a new aspect of
    >> C9X.

    Toon> But was it new with the ANSI/ISO 89 Standard ?

I do not know.  It's an interesting historical question, though.

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

Re: type based aliasing again

[Toon Moene]

David Edelsohn wrote:

> >>>>> I wrote:

> Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
> Toon> of Changes") and nowhere they say these restrictions against using
> Toon> differently typed pointers "are new with the ANSI/ISO Standard".

>         This viewpoint does not cover large groups of compiler users.
> Many programmers wrote code using differently typed pointers -- either
> because it was natural or because they wree trying to elicit certain
> behavior from the compiler.  This code behaved as expected when compiled
> with GCC using default commandline flags until this latest release.  

I do not deny that there are programmers who _think_ that that sort of
type-mixing pointing is "allowed" - we can all count the "bug reports"
we get because they do.

What I'm trying to establish is whether those programmers had a right to
believe this was allowed *based on the Standard previous to the current
Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
change with ANSI/ISO C 89, and I am willing to cut the old hands some
slack.

If not - there's a simple compile time option to turn off the unwanted
behaviour.

Perhaps it helps if I explain why I have little patience with this sort
of trickery (with the above caveat in mind):

Every month or so, somebody chastizes Digital's Fortran on
comp.lang.fortran for an "obvious and heinous" bug, because the
following construct doesn't do what they think it should:

      REAL A(N)
      ...
      IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN
      ...

when the compiled code crashes with a Segmentation Violation.

Why ?  Well, simply because the Fortran definition of .AND. doesn't
imply ordering; it's simply a commutative LOGICAL expression (in this
case two, with three operands).  The operands can legally be evaluated
in any order, and as soon as the truth value of the expression can be
determined (because one of the operands evaluates to .FALSE.) no other
evaluation has to take place, but is also not prohibited.

The experts take a deep breath, and explain to the (often experienced
Fortran) programmer that this is completely legal.  I've watched this
now for several years, *and I have never seen the Digital Fortran guys
give in*.  There isn't an advertised optimisation level at which this is
guaranteed not to happen.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I do not deny that there are programmers who _think_ that that sort of
Toon> type-mixing pointing is "allowed" - we can all count the "bug reports"
Toon> we get because they do.

	As far as I can tell, the C standard allowed it to the extent that
its behavior was undefined.  It was not disallowed and was left to the
implementation what result it produced.  Most compilers, including GCC,
have been producing a reasonable result under most circumstances when
faced with this construct.  I think that RMS's interpretation is that if
the limitations of a processor or system made this difficult or
impossible, a compiler writer could defend the lack of functionality by
saying the standard leaves the bahavior undefined. 

	When the compiler and architecture allow this construct to produce
reasonable results and other compilers produce reasonable results and GCC
still can produce reasonable results more often when an optional
optmization is not applied, then why not allow tihs construct to work
unless the user specifically request more aggressive optimization?

David

Re: type based aliasing again

[dvv]

On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:

>What I'm trying to establish is whether those programmers had a right to
>believe this was allowed *based on the Standard previous to the current
>Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
>change with ANSI/ISO C 89, and I am willing to cut the old hands some
>slack.

K&R I (What is it, anyway? Is it the language accepted by the original
dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
things that wouldn't work in the Standard.

>Toon Moene (toon@moene.indiv.nluug.nl)

Dima

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	As far as I can tell, the C standard allowed it to the
    David> extent that its behavior was undefined.  It was not
    David> disallowed and was left to the implementation what result
    David> it produced.  Most compilers, including GCC, have been
    David> producing a reasonable result under most circumstances when
    David> faced with this construct.

Although this again has no bearing on what we should *do*, it's worth
nothing that "undefined" has a much strong meaning than what you say
here.  "Implementation-defined" is the term used when the
implementation is expected to pick some behavior.  Undefined means
that program is erroneous, but the implementation is not required to
issue a diagnostic.  Other examples of undefined behavior include
dereferencing the NULL pointer, for example.  The behavior with
respect to accessing different fields in a union is
implementation-defined; the behavior of casting a double* to an int*
and then storing through it when it really points to a double is
undefined.  It would be reasonable (from the point of view of the
standard, not of GCC) to refuse to compile this at all, or to issue an
error at run-time, say.

    David> 	When the compiler and architecture allow this
    David> construct to produce reasonable results and other compilers
    David> produce reasonable results and GCC still can produce
    David> reasonable results more often when an optional optmization
    David> is not applied, then why not allow tihs construct to work
    David> unless the user specifically request more aggressive
    David> optimization?

Many new optimizations will break programs.  For example, if we remove
empty loops, people who wrote them for timing purposes lose.  If we
eliminate dead stores, people who forgot to say `volatile' lose.
Users of inline assembly often lose, if they forgot to mention a
clobber, etc.  People who depend on particular floating-point
computations in languages where the compiler can reorder operands lose
when we do the reordering.  Real programs really depend on all these
things, even though they shouldn't.  So, I don't think this is a very
good argument; it implies, to a first approximation, that no new
optimization is OK.  That's not 100% accurate, but it's not that far
off, either.

That doesn't mean that we shouldn't do what you suggest
w.r.t. -fstrict-aliasing.

There's a fundamental user-interface question here: is the default
behavior to generate fast code for conforming programs, or code that
works even for non-conforming programs?  Both defaults are sensible;
the first because users don't have to use lots of funny options to get
fast code, the second because legacy code doesn't get broken.  There
are broader ramifications as well; some people will reject GCC because
compared to some other `cc -O', `gcc -O' is slower.  Others because
with some other `cc -O' code works while `gcc -O' does not.  There's
no easy answer.

We don't need a global decision on this point; we can do it on an
option-by-option basis.  But, we should have an overall sentiment, or
we will forever have the same debates.

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

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 12:56:26PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed from
> the standard -O# optimization levels and accessed orthogonally.  I think
> that I and the other members of the GCC Steering Committee had good
> intentions, but were mistaken about the impact of including this
> optimization in a -O# level. 

But have we seen much impact yet (disregarding what people *think* should
be done?). Also the issue seems not to be aliasing as such, but that
aliasing might break cases where there is no benefit in doing so.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 01:02:51PM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.

Thats not pgcc's idea. "Unsafe" optimizations are off at all optimization
levels.

The distinction between -O2 and higher is that its easy to test
("experimental compiler"), since bugs with -O2 are most probably gcc bugs.

> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
> good idea. It's an issue of whether we consider this optimization as
> `safe' or `unsafe'.

No, it's an issue wether we define C as ISO C or (some variant).

But putting it at an higher optimization level makes it more special than
it is.

Maybe the _real_ issue is what will break at all? The asm checks "broke"
much more programs (glibc, linux-kernel, other kernels, drivers) then the
aliasing stuff.

At least I believe this until somebody gives me more than the two examples
(linux and openbsd) I have heard of yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 06:05:54PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	How is asking that the compiler try to provide compatibility by
> default where it is easy, such as not coupling -fstrict-aliasing to a -O#
> level, an unreasonable and burdensome request?  This is a one-line change

Because it is not useful. The same reasoning can be applied to any new
switch, this effectively stopping any advances in technology.

This is only sensible if a large codebase of existing programs rely on
that feature, and as Gerald has pointed out there is not much actual
breakage, but there are large amounts of opinions.

Any decision must be based on the actual extent of the problem.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Michael Meissner]

On Tue, Sep 14, 1999 at 11:15:06PM +0000, Dima Volodin wrote:
> On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:
> 
> >What I'm trying to establish is whether those programmers had a right to
> >believe this was allowed *based on the Standard previous to the current
> >Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
> >change with ANSI/ISO C 89, and I am willing to cut the old hands some
> >slack.
> 
> K&R I (What is it, anyway? Is it the language accepted by the original
> dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
> things that wouldn't work in the Standard.

And even there its not helpful.  For example, K&R-I explicitly uses a ref/def
model (where you must have one definition of a global variable in separate
files and everything else must be an "extern" reference to it), while the UNIX
C compilers have traditionally implemented the common model for global
variables).  Also, if you go by K&R-I, you cannot derrive pointers to functions
due to a typo in the book.

> >Toon Moene (toon@moene.indiv.nluug.nl)
> 
> Dima

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 07:13:08PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	As far as I can tell, the C standard allowed it to the extent that
> its behavior was undefined.  It was not disallowed and was left to the

Undefined behaviour *is* disallowed and you are no longer writing (ISO)
"C". What you mean is "implementation defined behaviour".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[craig]

>>>>>> craig  writes:
>
>craig> (I won't even get into the stunning news that the FSF has reportedly
>craig> just changed the rules of the very difficult job of compiler development,
>craig> apparently *since* the EGCS team agreed to become GCC and under the
>craig> aegis of the FSF.)
>
>	How is asking that the compiler try to provide compatibility by
>default where it is easy, such as not coupling -fstrict-aliasing to a -O#
>level, an unreasonable and burdensome request?  This is a one-line change
>removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
>are arguing against an interpretation of the request that takes it to an
>extreme, not the request itself. 
[and]
>	Of course my description is an over-simplification of the FSF's
>request.  The rest of your message describing that this is an impossible
>task to get every aspect right so GCC should ignore this requirement
>altogether is illogical and unhelpful.

I am arguing only against the statement you made about what the
FSF now requires of GCC.  You omitted that statement in the
quote.  That statement *clearly* suggested the FSF had recently
introduced additional requirements of GCC.

If you'd like to retract that statement, rather than criticize *me*
for calling attention to the ludicrousness of that statement,
I'd appreciate it if you'd do so.  I offered a gentle hint for you
to do so earlier, instead, you chose to attack me.

Pending that, I'm stunned by the complete lack of integrity you've
shown in trying to shift blame for your unnecessary over-simplification
to me.  That a GCC Steering Committee member would refer to my
entirely true statement as "illogical and unhelpful" is something
I find *extremely* disturbing, sufficient (especially in conjunction
with the *huge* waste of time this discussion has been to date, and
will continue to be, in various forms, until the end of time) to cause
me to question why I bother with *any* sort of GCC development,
especially in the form of offering my input.

The long and short of it is, regardless of whether *you* consider
your statement to have been "of course...an over-simplification",
*many* readers, and, frankly *too* many participants in this discussion,
did *not* recognize it as such, instead interpreting it as support
for their position to "fix" this "problem" in GCC.  I don't need
to identify any such people -- the length of the email discussion here,
and elsewhere, is sufficient to make the veracity of it clear
to those who are paying attention.

That's why I felt it necessary to *clearly* and *unambiguously* identify
the concept as you presented it as a ludicrous one for compiler developers
(or even most programmers, for that matter) to try and follow.

If you can't simply and directly communicate what the FSF, or any
other person, said, without over-simplifying in a way that *increases*
apparent support for your position, I suggest you stay out of these
discussions in the future.  Your demagoguery in this case was definitely
not appreciated by me.  If you have a problem with that, then I'll go
away and not bother this mailing list ever again.


As to your point that users expect -fno-alias-analysis not because
they ever read the standard but because that's how compilers used
to behave:

  Game.

  Set.

  Match.

In other words: RMS has said this wouldn't be interpreted as a "feature".
You've just contradicted that with your attempt to use history to
justify your agreement with his position.  So, as long as GCC tends
to make buggy code appear to work, there will always be the same
degree of justification to *continue* to do so.

If the GCC Steering Committee wishes to restore any sanity to this
situation, it should immediately declare the discussion over, and
the decision to be: use -fno-alias-analysis if your code might
not conform to the pertinent requirements of ISO C.

Period.

People who want warnings can get together and write software that
gives it to them, as I suggested, seemingly, weeks ago.

(I'm not holding my breath.  I'd much rather work on software that
actually implements the pertinent standards and specifications *correctly*,
than watch talented, enthusiastic people sap their energies in
largely irrelevant discussions like this.  That this whole thing
was recently started by RMS, who *should* have a better sense of
proportion vis-a-vis volunteer resources and undefined codes, and
who has veto power over the GCC Steering Committee, is very, very sad.)

        tq vm, (burley)

Re: type based aliasing again

[Geoff Keating]

Nick Ing-Simmons <nik@tiuk.ti.com> writes:

> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
> which may break existing code.

Every optimisation that changes the ordering of memory accesses may
break existing code, in the presence of threads or signals.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: type based aliasing again

[Marc Espie]

In article < 19990915020836.M3983@cerebro.laendle > you write:

>Maybe the _real_ issue is what will break at all? The asm checks "broke"
>much more programs (glibc, linux-kernel, other kernels, drivers) then the
>aliasing stuff.

Dubious comparison at best.  Completely off the point, in my opinion.
That you even think of it that way strikes me as a fairly strange, careless
philosophy.  The asm checks broke things in a plain, visible way: code that 
no longer compiles.

Whereas aliasing problems are NOT diagnosed by anything else than programs
suddenly stopping working, or exhibiting subtle bugs.

Granted, these problems are fairly infrequent, but they were subtle enough
that ALL affected programmers have developped some degree of paranoia about
it... and don't forget that we know that checking the code by hand is the only
sure way to find aliasing problems, unless there are prototypes everywhere and
absolutely no casts.

This is an issue of overall system quality.  Stuff that stops working
in obvious ways is simple to take care off.   To wit: I managed to fix the
OpenBSD kernels __asm__ trouble, even though I don't know much about most
platforms we run on.

Right now, the problem we ran into with -strict-aliasing has led us to turn
it off everywhere by default...  this is the only safe approach, as we have
about 200 Mb of code to audit... and it is probably never going to be turned
back on again for packages, as most of these programs are not that nicely
maintained, and there's just too much code to audit.

We'd rather spend our time looking for security holes.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909141102.NAA18232@quatramaran.ens.fr >you write:
  > Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
  > good idea. It's an issue of whether we consider this optimization as
  > `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
  > as well, as it should decrease the code size. In the second case, I see
  > no reason to treat it differently from -ffast-math.
If you write correct code, the compiler will generate correct code with
strict aliasing.  If you write incorrect code, all bets are off.

It's not significantly different than automatic register allocation -- if you
write correct code, automatic register allocation will generate correct code.
If you write incorrect code, all bets are off.

Do you really want to punish people who write correct code just because your
code is not correct?

jeff

Re: type based aliasing again

[Nick Ing-Simmons]

Geoff Keating <geoffk@ozemail.com.au> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
>> which may break existing code.
>
>Every optimisation that changes the ordering of memory accesses may
>break existing code, in the presence of threads or signals.

True. But such code while it may "exist" is unlikely to work correctly 
on different architectures with/without -O etc. As such breaking such code
is not as likely to surprise anyone that happens to be using it.

This is a different class of "existing code" than that which is broken 
by acting upon -fstrict-aliasing. Neither Linux kernel, nor perl, nor 
emacs is fragile in that sense. 

The "snag" with -fstrict-aliasing is that what it breaks is a commonly used
"trick" (C as architecture independant assembler) which has become entrenched 
in the code base. There are going to be lots of "close to the machine" bits
of code which have worked fine for years and are not actively maintained
which get bitten.

That said I don't really mind which way the default goes. But having 
it differ between -ON and -ON+1 is going to confuse people more than 
having to say -fno-strict-aliasing. (I would guess about 1/2 of 
./configure generated Makefiles generate -O2 for GCC.)

For new or fixed-up code I would prefer an attribute scheme so that I did 
not have to penalize an entire file just for (ab)use in one hot-spot.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 06:36:41AM -0000, craig@jcb-sc.com wrote:
> to me.  That a GCC Steering Committee member would refer to my
> entirely true statement as "illogical and unhelpful" is something
> I find *extremely* disturbing, sufficient (especially in conjunction
> with the *huge* waste of time this discussion has been to date, and
> will continue to be, in various forms, until the end of time) to cause
> me to question why I bother with *any* sort of GCC development,
> especially in the form of offering my input.

Craig, that commitee is not really thaat bad. The great number of
public messages also shows the great concern people have with that new
optimization (it does not show that its a real problem, yet).

But, as the SC is a designated _political_ instrument it has to discuss
and answer these concerns thoroughly.

The discussion has been largely technical in the past, so it was shifted
into the public (again) since the real aliasing experts sit here.

> If the GCC Steering Committee wishes to restore any sanity to this
> situation, it should immediately declare the discussion over, and
> the decision to be: use -fno-alias-analysis if your code might
> not conform to the pertinent requirements of ISO C.

The steering committee could indeed just "decide", but this wouldn't help.

I strongly feel the problem is not understood very good, neither its real
extent nor the possible solutions.

A big problem, for example, with the "just disable it"-approach is that
this kind of alias analysis will very likely become a vital part of more
optimization passes than we currently have, and paralying it to off might
do harm to gcc in the future.

> People who want warnings can get together and write software that
> gives it to them, as I suggested, seemingly, weeks ago.

"Patches are welcome" indeed. The problem of warnings seems to be a big
one, but most probably the correct one (thats my opinion of course ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> Dubious comparison at best.  Completely off the point, in my opinion.
> That you even think of it that way strikes me as a fairly strange, careless
> philosophy.  The asm checks broke things in a plain, visible way: code that 
> no longer compiles.

No, you are wrong. you are talking about the errors that were added at a
later point.

I was unclear, it wasn't, in fact, the asm changes (these were only new
errors), but the changes in other optimizations that made many invalid
asms break where they worked before (unter certain circumstances).

It was only because so many programs broke that the checks have been
added.

Which was a very worthwhile thing to do. Just as warnings for the aliasing
case would be very worthwhile. I think people believed checking the asm
constraints could be very difficult as well.

> Whereas aliasing problems are NOT diagnosed by anything else than programs
> suddenly stopping working, or exhibiting subtle bugs.

Just as the asm breakages.

I think your posting indicates the real problem we have about this issue,
namely that it's largely misunderstood by most people, maybe even by me.

Or not even misunderstood.. it's not clear what the problem is. Whose code
broke?  And why is this different to any other optimization that caused
code to break without any indication (warning, error)?

It might well be the case that a very large part of the software breaks,
in which case it might be a good idea to disable that optimization, unless
we can't come up with good warnings.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

	Craig, I am sorry about my harsh response to you.

	I still believe that you are writing long-winded responses to your
own strawman proposals instead of responding to the actual proposals on
the table.  If your entire earlier message was intended to point out that
my comment was an oversimplification, then why not just say that and make
a stronger point in a shorter message?

David

Re: type based aliasing again

[Nick Ing-Simmons]

How about making -fstrict-aliasing implied by -ansi/-iso ;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[craig]

>	I still believe that you are writing long-winded responses to your
>own strawman proposals instead of responding to the actual proposals on
>the table.  If your entire earlier message was intended to point out that
>my comment was an oversimplification, then why not just say that and make
>a stronger point in a shorter message?

Because it wasn't clear to me your comment was an over-simplification,
as it might well have been something the FSF said lately.

I was responding to the comment.  I even explained why in my most
recent message.  If my messages are too long for you to read -- to
the PS of the earlier message, or to the explanation for why
I felt the wording you used, *as such* (regardless of whether it
was your oversimplification, or a reasonable approximation of
the FSF's stance), needed to be discredited, then please add me
to your killfile.  I've been told I'm overly verbose for about
three decades.  Clearly that hasn't fixed much of anything, so
don't hold your breath.

In my own defense, I'll point out that my verbosity is frequently
the result of sincere attempts on my part to *not* over-simplify
an argument or point, especially not in an attempt to *add* force
to my argument.  In short, I try *very* hard to *not* use demagoguery
*or* set up straw-men.  I believe I usually do a good job of
writing clearly, but, in discussions where others write sloppily,
as you did, I do tend to challenge the *breadth* of possible meanings
of their writings, which includes having to more precisely define
each meaning or alternative, rather than pick just one.  Because,
in practice, if I pick just one, the author inevitably says something
like "well, then, that's not what I meant, and you knew that" -- and
in a sense, he's right, I'd know that wasn't *necessarily* the one
thing he meant.

So I guess you're saying I should have just said "are you over-
simplifying, do you have a pointer to the statement so we can
judge for ourselves what the FSF said".  But, I figure, you must
have had a reason to put it in your own words, so I assumed
there was some honor and integrity as well as practicality in doing
so, and went from there.  It was therefore natural for me to
reason through the issue on the assumption you were fairly
representing the FSF's position to the rest of us, since that's
what you attempted to undertake, and I assumed you were being
honest and fair.

Further, there was no need to over-simplify in that case vis-a-vis
what the FSF probably *did* say (e.g. "programs that invoke undefined
behavior that is universally recognized as being definable to mean
one thing should not be broken by GCC"), so it didn't exactly
make sense that you would over-simplify just to save a few words,
since that's the most it would have saved.

        tq vm, (burley)

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> How about making -fstrict-aliasing implied by -ansi/-iso ;-)

	This is an interesting and good proposal.  The problem that I see
is GCC currently uses that flag differently.  The flag currently disables
GCC extensions that are not allowed by a strictly-conforming ANSI/ISO
program. 

	We already have -Os for space optimiation.  Maybe we need -Oa or
-Oansi or -Oiso for the user to give assurances that the program is
standards-compliant.  This would allow an umbrella optimization flag to
attach many of these optimizations requiring strict conformance to operate
correctly. 

David

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> But the math standard has had much longer to settle in and get adopted
Nick> in the existing code base. When new C alias standard has been around as long
Nick> as IEEE-754 then it may be time to flip the default...

	The recent C Standard allows the optimization but does not require
a specific behavior.  If it specified a behavior, then this would not be
an optimization.  As the behavior of this construct is undefined, this
transformation should not be enabled without explicit request from the
user.

	The FSF has stated, only just recently, that not breaking existing
programs because of undefined behavior is a goal that GCC should try to
meet.  Removing -fstrict-aliasing is a simple change that will meet this
goal and not dimish the functionality of this optimization for those who
want to invoke it explicitly.

	I think that GCC should make this simple change.

David

Re: type based aliasing again

[Gerald Pfeifer]

Some time ago, Mark wrote:
| Saying "Don't violate ANSI/ISO aliasing rules, or else use
| -fno-strict-aliasing" is a simple, easy-to-follow rule.
and don't really see why this shouldn't be viable.

On Tue, 14 Sep 1999, David Edelsohn wrote:
> I think that GCC should make this simple change.

Instead of removing a nice and rather stable optimization for the
sake of compiling broken code, why can't we 
 1. implement warnings;
 2. document the issue in the FAQ and describe the simple workaround
    of using fno-aliasing;
 3. wait what really happens?

What I *really* wonder is: If this is breaking that much legacy code,
where are the bug reports?

After the GCC 2.95.x releases we had quite a couple of reports concerning
problems on Solaris, but I cannot remember a single one concerning the
aliasing issue!

Apart from OpenBSD which seems to have encountered a real bug, just Perl
and Linux have been mentioned (both of which are actively maintained).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
Toon> of Changes") and nowhere they say these restrictions against using
Toon> differently typed pointers "are new with the ANSI/ISO Standard".

	This viewpoint does not cover large groups of compiler users.
Many programmers wrote code using differently typed pointers -- either
because it was natural or because they wree trying to elicit certain
behavior from the compiler.  This code behaved as expected when compiled
with GCC using default commandline flags until this latest release.  We
easily can change the behavior of GCC so that this class of users will not
be inconvenienced and those who want more aggressive optimization of
conforming code can elicint the behavior they want.  This change is
trivial.  Arguing about C standards and user expectations does not
consider how this and other compilers have behaved for years.  Those
compilers were not behaving incorrectly.

David

Re: type based aliasing again

[David Edelsohn]

>>>>> Toon Moene writes:

Toon> I do not deny that there are programmers who _think_ that that sort of
Toon> type-mixing pointing is "allowed" - we can all count the "bug reports"
Toon> we get because they do.

	As far as I can tell, the C standard allowed it to the extent that
its behavior was undefined.  It was not disallowed and was left to the
implementation what result it produced.  Most compilers, including GCC,
have been producing a reasonable result under most circumstances when
faced with this construct.  I think that RMS's interpretation is that if
the limitations of a processor or system made this difficult or
impossible, a compiler writer could defend the lack of functionality by
saying the standard leaves the bahavior undefined. 

	When the compiler and architecture allow this construct to produce
reasonable results and other compilers produce reasonable results and GCC
still can produce reasonable results more often when an optional
optmization is not applied, then why not allow tihs construct to work
unless the user specifically request more aggressive optimization?

David

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 06:36:41AM -0000, craig@jcb-sc.com wrote:
> to me.  That a GCC Steering Committee member would refer to my
> entirely true statement as "illogical and unhelpful" is something
> I find *extremely* disturbing, sufficient (especially in conjunction
> with the *huge* waste of time this discussion has been to date, and
> will continue to be, in various forms, until the end of time) to cause
> me to question why I bother with *any* sort of GCC development,
> especially in the form of offering my input.

Craig, that commitee is not really thaat bad. The great number of
public messages also shows the great concern people have with that new
optimization (it does not show that its a real problem, yet).

But, as the SC is a designated _political_ instrument it has to discuss
and answer these concerns thoroughly.

The discussion has been largely technical in the past, so it was shifted
into the public (again) since the real aliasing experts sit here.

> If the GCC Steering Committee wishes to restore any sanity to this
> situation, it should immediately declare the discussion over, and
> the decision to be: use -fno-alias-analysis if your code might
> not conform to the pertinent requirements of ISO C.

The steering committee could indeed just "decide", but this wouldn't help.

I strongly feel the problem is not understood very good, neither its real
extent nor the possible solutions.

A big problem, for example, with the "just disable it"-approach is that
this kind of alias analysis will very likely become a vital part of more
optimization passes than we currently have, and paralying it to off might
do harm to gcc in the future.

> People who want warnings can get together and write software that
> gives it to them, as I suggested, seemingly, weeks ago.

"Patches are welcome" indeed. The problem of warnings seems to be a big
one, but most probably the correct one (thats my opinion of course ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

	Of course my description is an over-simplification of the FSF's
request.  The rest of your message describing that this is an impossible
task to get every aspect right so GCC should ignore this requirement
altogether is illogical and unhelpful.

David

Re: type based aliasing again

[Michael Meissner]

On Tue, Sep 14, 1999 at 11:15:06PM +0000, Dima Volodin wrote:
> On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:
> 
> >What I'm trying to establish is whether those programmers had a right to
> >believe this was allowed *based on the Standard previous to the current
> >Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
> >change with ANSI/ISO C 89, and I am willing to cut the old hands some
> >slack.
> 
> K&R I (What is it, anyway? Is it the language accepted by the original
> dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
> things that wouldn't work in the Standard.

And even there its not helpful.  For example, K&R-I explicitly uses a ref/def
model (where you must have one definition of a global variable in separate
files and everything else must be an "extern" reference to it), while the UNIX
C compilers have traditionally implemented the common model for global
variables).  Also, if you go by K&R-I, you cannot derrive pointers to functions
due to a typo in the book.

> >Toon Moene (toon@moene.indiv.nluug.nl)
> 
> Dima

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

Re: type based aliasing again

[N8TM]

> It's certainly within a reasonable "umbrella" approach of having
>  increasing optimization levels be about increasing reliance on
>  the code strictly conforming to the pertinent standard, even its
>  "tricky bits".
>  
>  The biggest problem I see with it right now is that we haven't
>  exactly taken that "umbrella" approach in the past in a consistent
>  way.

And it may not be the most useful scheme either.  With gcc-2.96 we are back 
to -Os being faster running most of the time than -O2 or -O3 on x86, with 
-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
the application) needed for best results.  We would want to continue the 
ability to get strict-aliasing at -Os.   I suppose we have no say on the 
peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
specifically turned off; always off at -Os even when it would save space.

Commercial compilers have completely broken the old scheme of things also.  
They generally accept -O but it doesn't mean much.  Maximum optimization may 
be the default (Lahey) or normal high optimization may take quite a string of 
things like -Ofast 
-OPT:fold_reassociate=OFF:IEEE_comparisons=ON:unroll_times_max=2 -TENV:X=1 
(MipsPro).  So maybe the most confusing thing about gnu is the way the 
options have changed over time without much explanation (except for 
strict-aliasing).

Tim

Re: type based aliasing again

[Marc Espie]

In article < e629bdfd.250f2c9c@aol.com > you write:
>> It's certainly within a reasonable "umbrella" approach of having
>>  increasing optimization levels be about increasing reliance on
>>  the code strictly conforming to the pertinent standard, even its
>>  "tricky bits".
>>  
>>  The biggest problem I see with it right now is that we haven't
>>  exactly taken that "umbrella" approach in the past in a consistent
>>  way.

>And it may not be the most useful scheme either.  With gcc-2.96 we are back 
>to -Os being faster running most of the time than -O2 or -O3 on x86, with 
>-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
>the application) needed for best results.  We would want to continue the 
>ability to get strict-aliasing at -Os.   I suppose we have no say on the 
>peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
>specifically turned off; always off at -Os even when it would save space.

You can always turn strict-aliasing on or off explicitly with
-fstrict-aliasing or -fno-strict-aliasing.

The only issue here is whether it should be turned on by default for -O#.

I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.
The pgcc guys can do what they want... after all, pgcc was touted as a 
very fast, highly experimental compiler. Whereas gcc is supposed to be stable.

Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
good idea. It's an issue of whether we consider this optimization as
`safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
as well, as it should decrease the code size. In the second case, I see
no reason to treat it differently from -ffast-math.

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 01:02:51PM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.

Thats not pgcc's idea. "Unsafe" optimizations are off at all optimization
levels.

The distinction between -O2 and higher is that its easy to test
("experimental compiler"), since bugs with -O2 are most probably gcc bugs.

> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
> good idea. It's an issue of whether we consider this optimization as
> `safe' or `unsafe'.

No, it's an issue wether we define C as ISO C or (some variant).

But putting it at an higher optimization level makes it more special than
it is.

Maybe the _real_ issue is what will break at all? The asm checks "broke"
much more programs (glibc, linux-kernel, other kernels, drivers) then the
aliasing stuff.

At least I believe this until somebody gives me more than the two examples
(linux and openbsd) I have heard of yet.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Lehmann]

On Wed, Sep 15, 1999 at 11:03:19AM +0200, Marc Espie <espie@quatramaran.ens.fr> wrote:
> Dubious comparison at best.  Completely off the point, in my opinion.
> That you even think of it that way strikes me as a fairly strange, careless
> philosophy.  The asm checks broke things in a plain, visible way: code that 
> no longer compiles.

No, you are wrong. you are talking about the errors that were added at a
later point.

I was unclear, it wasn't, in fact, the asm changes (these were only new
errors), but the changes in other optimizations that made many invalid
asms break where they worked before (unter certain circumstances).

It was only because so many programs broke that the checks have been
added.

Which was a very worthwhile thing to do. Just as warnings for the aliasing
case would be very worthwhile. I think people believed checking the asm
constraints could be very difficult as well.

> Whereas aliasing problems are NOT diagnosed by anything else than programs
> suddenly stopping working, or exhibiting subtle bugs.

Just as the asm breakages.

I think your posting indicates the real problem we have about this issue,
namely that it's largely misunderstood by most people, maybe even by me.

Or not even misunderstood.. it's not clear what the problem is. Whose code
broke?  And why is this different to any other optimization that caused
code to break without any indication (warning, error)?

It might well be the case that a very large part of the software breaks,
in which case it might be a good idea to disable that optimization, unless
we can't come up with good warnings.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[craig]

>I don't know the history of the C aliasing requirement, but, offhand,
>it strikes me as highly unlikely that it does *not* constitute an
>incompatible change vis-a-vis former revisions of the standard.

Too many negatives, I meant "highly unlikely that it constitutes
an incompatible change...".

        tq vm, (burley)

Re: type based aliasing again

[craig]

>	The FSF has stated, only just recently, that not breaking existing
>programs because of undefined behavior is a goal that GCC should try to
>meet.  Removing -fstrict-aliasing is a simple change that will meet this
>goal and not dimish the functionality of this optimization for those who
>want to invoke it explicitly.

I really, really doubt that removing -fstrict-aliasing is the only
change needed that will meet this goal.

I suggest the FSF, and all others who support this interpretation,
read every line of the C, C++, and Fortran standards (just for
starters), highlight every effective denotation of something the
user's code plus data can do as "undefined", and research thoroughly
what it'll take to make GCC not "break" these programs.  Division by
zero?  Square root of negative number?  Dereferencing a NULL pointer?
How about when the result isn't used?  How about writing via a NULL
pointer but never trying to read the result back?  These are all
undefined, in one language or another, and GCC will, by one
definition or another, break existing code that invokes these
undefined behaviors.

(Having spent many years now as a compiler developer, and having
hashed relevant issues out on comp.lang.fortran, I can assure you
of one thing: anyone who says "a compiler should not break an
existing program because of undefined behavior" has *not one clue*
about compiler development or standards and specifications.  If they
did, they would state it this way: "a compiler *can* not break an
existing program because of undefined behavior".  If the behavior is
undefined, nothing the compiler causes the program to do at run time
can be considered "breakage".)

(I won't even get into the stunning news that the FSF has reportedly
just changed the rules of the very difficult job of compiler development,
apparently *since* the EGCS team agreed to become GCC and under the
aegis of the FSF.)

        tq vm, (burley)

P.S. Personally, I'll just assume the FSF was misquoted.

Re: type based aliasing again

[David Edelsohn]

	Craig, I am sorry about my harsh response to you.

	I still believe that you are writing long-winded responses to your
own strawman proposals instead of responding to the actual proposals on
the table.  If your entire earlier message was intended to point out that
my comment was an oversimplification, then why not just say that and make
a stronger point in a shorter message?

David

Re: type based aliasing again

[craig]

>>>>>> craig  writes:
>
>craig> (I won't even get into the stunning news that the FSF has reportedly
>craig> just changed the rules of the very difficult job of compiler development,
>craig> apparently *since* the EGCS team agreed to become GCC and under the
>craig> aegis of the FSF.)
>
>	How is asking that the compiler try to provide compatibility by
>default where it is easy, such as not coupling -fstrict-aliasing to a -O#
>level, an unreasonable and burdensome request?  This is a one-line change
>removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
>are arguing against an interpretation of the request that takes it to an
>extreme, not the request itself. 
[and]
>	Of course my description is an over-simplification of the FSF's
>request.  The rest of your message describing that this is an impossible
>task to get every aspect right so GCC should ignore this requirement
>altogether is illogical and unhelpful.

I am arguing only against the statement you made about what the
FSF now requires of GCC.  You omitted that statement in the
quote.  That statement *clearly* suggested the FSF had recently
introduced additional requirements of GCC.

If you'd like to retract that statement, rather than criticize *me*
for calling attention to the ludicrousness of that statement,
I'd appreciate it if you'd do so.  I offered a gentle hint for you
to do so earlier, instead, you chose to attack me.

Pending that, I'm stunned by the complete lack of integrity you've
shown in trying to shift blame for your unnecessary over-simplification
to me.  That a GCC Steering Committee member would refer to my
entirely true statement as "illogical and unhelpful" is something
I find *extremely* disturbing, sufficient (especially in conjunction
with the *huge* waste of time this discussion has been to date, and
will continue to be, in various forms, until the end of time) to cause
me to question why I bother with *any* sort of GCC development,
especially in the form of offering my input.

The long and short of it is, regardless of whether *you* consider
your statement to have been "of course...an over-simplification",
*many* readers, and, frankly *too* many participants in this discussion,
did *not* recognize it as such, instead interpreting it as support
for their position to "fix" this "problem" in GCC.  I don't need
to identify any such people -- the length of the email discussion here,
and elsewhere, is sufficient to make the veracity of it clear
to those who are paying attention.

That's why I felt it necessary to *clearly* and *unambiguously* identify
the concept as you presented it as a ludicrous one for compiler developers
(or even most programmers, for that matter) to try and follow.

If you can't simply and directly communicate what the FSF, or any
other person, said, without over-simplifying in a way that *increases*
apparent support for your position, I suggest you stay out of these
discussions in the future.  Your demagoguery in this case was definitely
not appreciated by me.  If you have a problem with that, then I'll go
away and not bother this mailing list ever again.


As to your point that users expect -fno-alias-analysis not because
they ever read the standard but because that's how compilers used
to behave:

  Game.

  Set.

  Match.

In other words: RMS has said this wouldn't be interpreted as a "feature".
You've just contradicted that with your attempt to use history to
justify your agreement with his position.  So, as long as GCC tends
to make buggy code appear to work, there will always be the same
degree of justification to *continue* to do so.

If the GCC Steering Committee wishes to restore any sanity to this
situation, it should immediately declare the discussion over, and
the decision to be: use -fno-alias-analysis if your code might
not conform to the pertinent requirements of ISO C.

Period.

People who want warnings can get together and write software that
gives it to them, as I suggested, seemingly, weeks ago.

(I'm not holding my breath.  I'd much rather work on software that
actually implements the pertinent standards and specifications *correctly*,
than watch talented, enthusiastic people sap their energies in
largely irrelevant discussions like this.  That this whole thing
was recently started by RMS, who *should* have a better sense of
proportion vis-a-vis volunteer resources and undefined codes, and
who has veto power over the GCC Steering Committee, is very, very sad.)

        tq vm, (burley)

Re: type based aliasing again

[Toon Moene]

David Edelsohn wrote:

> >>>>> I wrote:

> Toon> I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
> Toon> of Changes") and nowhere they say these restrictions against using
> Toon> differently typed pointers "are new with the ANSI/ISO Standard".

>         This viewpoint does not cover large groups of compiler users.
> Many programmers wrote code using differently typed pointers -- either
> because it was natural or because they wree trying to elicit certain
> behavior from the compiler.  This code behaved as expected when compiled
> with GCC using default commandline flags until this latest release.  

I do not deny that there are programmers who _think_ that that sort of
type-mixing pointing is "allowed" - we can all count the "bug reports"
we get because they do.

What I'm trying to establish is whether those programmers had a right to
believe this was allowed *based on the Standard previous to the current
Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
change with ANSI/ISO C 89, and I am willing to cut the old hands some
slack.

If not - there's a simple compile time option to turn off the unwanted
behaviour.

Perhaps it helps if I explain why I have little patience with this sort
of trickery (with the above caveat in mind):

Every month or so, somebody chastizes Digital's Fortran on
comp.lang.fortran for an "obvious and heinous" bug, because the
following construct doesn't do what they think it should:

      REAL A(N)
      ...
      IF (I .GT. 0 .AND. I .LE. N .AND. A(I) .GT. 0.0) THEN
      ...

when the compiled code crashes with a Segmentation Violation.

Why ?  Well, simply because the Fortran definition of .AND. doesn't
imply ordering; it's simply a commutative LOGICAL expression (in this
case two, with three operands).  The operands can legally be evaluated
in any order, and as soon as the truth value of the expression can be
determined (because one of the operands evaluates to .FALSE.) no other
evaluation has to take place, but is also not prohibited.

The experts take a deep breath, and explain to the (often experienced
Fortran) programmer that this is completely legal.  I've watched this
now for several years, *and I have never seen the Digital Fortran guys
give in*.  There isn't an advertised optimisation level at which this is
guaranteed not to happen.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 07:13:08PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	As far as I can tell, the C standard allowed it to the extent that
> its behavior was undefined.  It was not disallowed and was left to the

Undefined behaviour *is* disallowed and you are no longer writing (ISO)
"C". What you mean is "implementation defined behaviour".

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> I don't know the history of the C aliasing requirement,
    craig> but, offhand, it strikes me as highly unlikely that it does
    craig> *not* constitute an incompatible change vis-a-vis former
    craig> revisions of the standard.

Just to clarify, the language in the standard probably dates to the
original C standard.  It is certainly not a new aspect of C9X.

That doesn't have any bearing on our decision about what to do; it's
just a fact.  This is not a change to the standard that GCC rushed to
take advantage of; it's a long-standing aspect of ANSI/ISO C.
Compilers just didn't make use of that information until the past few
years, which is why a lot of programs that broke these rules worked
OK historically.

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

Re: type based aliasing again

[Nick Ing-Simmons]

How about making -fstrict-aliasing implied by -ansi/-iso ;-)

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 12:56:26PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed from
> the standard -O# optimization levels and accessed orthogonally.  I think
> that I and the other members of the GCC Steering Committee had good
> intentions, but were mistaken about the impact of including this
> optimization in a -O# level. 

But have we seen much impact yet (disregarding what people *think* should
be done?). Also the issue seems not to be aliasing as such, but that
aliasing might break cases where there is no benefit in doing so.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[David Edelsohn]

>>>>> Nick Ing-Simmons writes:

Nick> How about making -fstrict-aliasing implied by -ansi/-iso ;-)

	This is an interesting and good proposal.  The problem that I see
is GCC currently uses that flag differently.  The flag currently disables
GCC extensions that are not allowed by a strictly-conforming ANSI/ISO
program. 

	We already have -Os for space optimiation.  Maybe we need -Oa or
-Oansi or -Oiso for the user to give assurances that the program is
standards-compliant.  This would allow an umbrella optimization flag to
attach many of these optimizations requiring strict conformance to operate
correctly. 

David

Re: type based aliasing again

[Nick Ing-Simmons]

Geoff Keating <geoffk@ozemail.com.au> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
>> which may break existing code.
>
>Every optimisation that changes the ordering of memory accesses may
>break existing code, in the presence of threads or signals.

True. But such code while it may "exist" is unlikely to work correctly 
on different architectures with/without -O etc. As such breaking such code
is not as likely to surprise anyone that happens to be using it.

This is a different class of "existing code" than that which is broken 
by acting upon -fstrict-aliasing. Neither Linux kernel, nor perl, nor 
emacs is fragile in that sense. 

The "snag" with -fstrict-aliasing is that what it breaks is a commonly used
"trick" (C as architecture independant assembler) which has become entrenched 
in the code base. There are going to be lots of "close to the machine" bits
of code which have worked fine for years and are not actively maintained
which get bitten.

That said I don't really mind which way the default goes. But having 
it differ between -ON and -ON+1 is going to confuse people more than 
having to say -fno-strict-aliasing. (I would guess about 1/2 of 
./configure generated Makefiles generate -O2 for GCC.)

For new or fixed-up code I would prefer an attribute scheme so that I did 
not have to penalize an entire file just for (ab)use in one hot-spot.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	As far as I can tell, the C standard allowed it to the
    David> extent that its behavior was undefined.  It was not
    David> disallowed and was left to the implementation what result
    David> it produced.  Most compilers, including GCC, have been
    David> producing a reasonable result under most circumstances when
    David> faced with this construct.

Although this again has no bearing on what we should *do*, it's worth
nothing that "undefined" has a much strong meaning than what you say
here.  "Implementation-defined" is the term used when the
implementation is expected to pick some behavior.  Undefined means
that program is erroneous, but the implementation is not required to
issue a diagnostic.  Other examples of undefined behavior include
dereferencing the NULL pointer, for example.  The behavior with
respect to accessing different fields in a union is
implementation-defined; the behavior of casting a double* to an int*
and then storing through it when it really points to a double is
undefined.  It would be reasonable (from the point of view of the
standard, not of GCC) to refuse to compile this at all, or to issue an
error at run-time, say.

    David> 	When the compiler and architecture allow this
    David> construct to produce reasonable results and other compilers
    David> produce reasonable results and GCC still can produce
    David> reasonable results more often when an optional optmization
    David> is not applied, then why not allow tihs construct to work
    David> unless the user specifically request more aggressive
    David> optimization?

Many new optimizations will break programs.  For example, if we remove
empty loops, people who wrote them for timing purposes lose.  If we
eliminate dead stores, people who forgot to say `volatile' lose.
Users of inline assembly often lose, if they forgot to mention a
clobber, etc.  People who depend on particular floating-point
computations in languages where the compiler can reorder operands lose
when we do the reordering.  Real programs really depend on all these
things, even though they shouldn't.  So, I don't think this is a very
good argument; it implies, to a first approximation, that no new
optimization is OK.  That's not 100% accurate, but it's not that far
off, either.

That doesn't mean that we shouldn't do what you suggest
w.r.t. -fstrict-aliasing.

There's a fundamental user-interface question here: is the default
behavior to generate fast code for conforming programs, or code that
works even for non-conforming programs?  Both defaults are sensible;
the first because users don't have to use lots of funny options to get
fast code, the second because legacy code doesn't get broken.  There
are broader ramifications as well; some people will reject GCC because
compared to some other `cc -O', `gcc -O' is slower.  Others because
with some other `cc -O' code works while `gcc -O' does not.  There's
no easy answer.

We don't need a global decision on this point; we can do it on an
option-by-option basis.  But, we should have an overall sentiment, or
we will forever have the same debates.

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

Re: type based aliasing again

[Richard Earnshaw]

dje@watson.ibm.com said:
> 	I think that -ffast-math and the behavior of compilers from other
> vendors is good precedent that -fstrict-aliasing should be removed
> from the standard -O# optimization levels and accessed orthogonally. 

-ffast-math doesn't give any precedent at all.  -ffast-math enables 
optimizations that the relevant standards disallow.  -fstrict-aliasing 
does exactly the opposite.

Richard.

Re: type based aliasing again

[Mark Mitchell]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

    Toon> Mark Mitchell wrote:

    Toon> [ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer
    Toon> ]

    >> Just to clarify, the language in the standard probably dates to
    >> the original C standard.  It is certainly not a new aspect of
    >> C9X.

    Toon> But was it new with the ANSI/ISO 89 Standard ?

I do not know.  It's an interesting historical question, though.

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

Re: type based aliasing again

[Dima Volodin]

On Wed, 15 Sep 1999 00:58:24 +0200, you wrote:

>What I'm trying to establish is whether those programmers had a right to
>believe this was allowed *based on the Standard previous to the current
>Standard*, namely K&R I.  If K&R I allowed it, it is an incompatible
>change with ANSI/ISO C 89, and I am willing to cut the old hands some
>slack.

K&R I (What is it, anyway? Is it the language accepted by the original
dmr's compiler? Or by the pcc by S.C.Johnson? Or what?) allowed a lot of
things that wouldn't work in the Standard.

>Toon Moene (toon@moene.indiv.nluug.nl)

Dima

Re: type based aliasing again

[craig]

>	I still believe that you are writing long-winded responses to your
>own strawman proposals instead of responding to the actual proposals on
>the table.  If your entire earlier message was intended to point out that
>my comment was an oversimplification, then why not just say that and make
>a stronger point in a shorter message?

Because it wasn't clear to me your comment was an over-simplification,
as it might well have been something the FSF said lately.

I was responding to the comment.  I even explained why in my most
recent message.  If my messages are too long for you to read -- to
the PS of the earlier message, or to the explanation for why
I felt the wording you used, *as such* (regardless of whether it
was your oversimplification, or a reasonable approximation of
the FSF's stance), needed to be discredited, then please add me
to your killfile.  I've been told I'm overly verbose for about
three decades.  Clearly that hasn't fixed much of anything, so
don't hold your breath.

In my own defense, I'll point out that my verbosity is frequently
the result of sincere attempts on my part to *not* over-simplify
an argument or point, especially not in an attempt to *add* force
to my argument.  In short, I try *very* hard to *not* use demagoguery
*or* set up straw-men.  I believe I usually do a good job of
writing clearly, but, in discussions where others write sloppily,
as you did, I do tend to challenge the *breadth* of possible meanings
of their writings, which includes having to more precisely define
each meaning or alternative, rather than pick just one.  Because,
in practice, if I pick just one, the author inevitably says something
like "well, then, that's not what I meant, and you knew that" -- and
in a sense, he's right, I'd know that wasn't *necessarily* the one
thing he meant.

So I guess you're saying I should have just said "are you over-
simplifying, do you have a pointer to the statement so we can
judge for ourselves what the FSF said".  But, I figure, you must
have had a reason to put it in your own words, so I assumed
there was some honor and integrity as well as practicality in doing
so, and went from there.  It was therefore natural for me to
reason through the issue on the assumption you were fairly
representing the FSF's position to the rest of us, since that's
what you attempted to undertake, and I assumed you were being
honest and fair.

Further, there was no need to over-simplify in that case vis-a-vis
what the FSF probably *did* say (e.g. "programs that invoke undefined
behavior that is universally recognized as being definable to mean
one thing should not be broken by GCC"), so it didn't exactly
make sense that you would over-simplify just to save a few words,
since that's the most it would have saved.

        tq vm, (burley)

Re: type based aliasing again

[Geoff Keating]

Nick Ing-Simmons <nik@tiuk.ti.com> writes:

> Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
> which may break existing code.

Every optimisation that changes the ordering of memory accesses may
break existing code, in the presence of threads or signals.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: type based aliasing again

[David Edelsohn]

>>>>> craig  writes:

craig> (I won't even get into the stunning news that the FSF has reportedly
craig> just changed the rules of the very difficult job of compiler development,
craig> apparently *since* the EGCS team agreed to become GCC and under the
craig> aegis of the FSF.)

	How is asking that the compiler try to provide compatibility by
default where it is easy, such as not coupling -fstrict-aliasing to a -O#
level, an unreasonable and burdensome request?  This is a one-line change
removing flag_strict_aliasing from optimize >= 2 stanza in toplev.c.  You
are arguing against an interpretation of the request that takes it to an
extreme, not the request itself. 

David

Re: type based aliasing again

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> The only issue here is whether it should be turned on by default for -O#.

Marc> Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
Marc> good idea. It's an issue of whether we consider this optimization as
Marc> `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
Marc> as well, as it should decrease the code size. In the second case, I see
Marc> no reason to treat it differently from -ffast-math.

	I think that -ffast-math and the behavior of compilers from other
vendors is good precedent that -fstrict-aliasing should be removed from
the standard -O# optimization levels and accessed orthogonally.  I think
that I and the other members of the GCC Steering Committee had good
intentions, but were mistaken about the impact of including this
optimization in a -O# level. 

David

Re: type based aliasing again

[craig]

>Richard Earnshaw <richard.earnshaw@arm.com> writes:
>>-ffast-math enables 
>>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>>does exactly the opposite.

(That might be misinterpreted.  -ffast-math and -fstrict-aliasing both
enable optimizations.  The former enables optimizations that the relevant
standards disallows.  The latter does not.)

>But the math standard has had much longer to settle in and get adopted
>in the existing code base. When new C alias standard has been around as long
>as IEEE-754 then it may be time to flip the default...

There's a confusion in that statement that reveals why, indeed,
-ffast-math is not a precedent.

Before IEEE-754, no code was written that *required* -ffast-math.  IEEE-754
springing into existence caused programmers to start writing code that
required -fno-fast-math, however.  (Some already had been on systems --
CPU + library + compiler -- that effectively offered the same promises.)

So specifying -ffast-math is saying "My code meets requirements above
and beyond the present standards".

Specifying -fstrict-analysis is saying "My code meets the presents
standards".

I don't know the history of the C aliasing requirement, but, offhand,
it strikes me as highly unlikely that it does *not* constitute an
incompatible change vis-a-vis former revisions of the standard.

Even if so, it seems kinda silly for users to have to specify *any*
option that says "My code meets the present standards", especially
vis-a-vis the ISO C standard, when compiling code in a file with a
name like "foo.c".

        tq vm, (burley)

Re: type based aliasing again

[Toon Moene]

Mark Mitchell wrote:

[ C aliasing-or-not-determined-by-type-of-pointee-vs-pointer ]

> Just to clarify, the language in the standard probably dates to the
> original C standard.  It is certainly not a new aspect of C9X.

But was it new with the ANSI/ISO 89 Standard ?

> That doesn't have any bearing on our decision about what to do; it's
> just a fact.  This is not a change to the standard that GCC rushed to
> take advantage of; it's a long-standing aspect of ANSI/ISO C.

[ I do agree with the first sentence of of the above paragraph ]

The interesting question preceding is:  Did C programmers *ever* have
the opportunity to believe that the following sequence would work:

      int bla(ix)
      int *ix;
      {
         short s;
         ...
         s = (short *) ix;
         ...
      }

I reread K&R II (Chapter 5 "Pointers and Arrays" and Appendix C "Summary
of Changes") and nowhere they say these restrictions against using
differently typed pointers "are new with the ANSI/ISO Standard".

I don't have K&R I, so I can't check if you could possibly read into
that text that the above would be legal, or what it would mean in the
first place ...

Does anyone know this ?

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: type based aliasing again

[Nick Ing-Simmons]

Richard Earnshaw <richard.earnshaw@arm.com> writes:
>dje@watson.ibm.com said:
>> 	I think that -ffast-math and the behavior of compilers from other
>> vendors is good precedent that -fstrict-aliasing should be removed
>> from the standard -O# optimization levels and accessed orthogonally. 
>
>-ffast-math doesn't give any precedent at all.  

Yes it does. Both -ffast-math and -fstrict-aliasing turn on optimizations
which may break existing code.

>-ffast-math enables 
>optimizations that the relevant standards disallow.  -fstrict-aliasing 
>does exactly the opposite.

But the math standard has had much longer to settle in and get adopted
in the existing code base. When new C alias standard has been around as long
as IEEE-754 then it may be time to flip the default...

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: type based aliasing again

[Marc Lehmann]

On Tue, Sep 14, 1999 at 06:05:54PM -0400, David Edelsohn <dje@watson.ibm.com> wrote:
> 	How is asking that the compiler try to provide compatibility by
> default where it is easy, such as not coupling -fstrict-aliasing to a -O#
> level, an unreasonable and burdensome request?  This is a one-line change

Because it is not useful. The same reasoning can be applied to any new
switch, this effectively stopping any advances in technology.

This is only sensible if a large codebase of existing programs rely on
that feature, and as Gerald has pointed out there is not much actual
breakage, but there are large amounts of opinions.

Any decision must be based on the actual extent of the problem.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: type based aliasing again

[Marc Espie]

In article < 19990915020836.M3983@cerebro.laendle > you write:

>Maybe the _real_ issue is what will break at all? The asm checks "broke"
>much more programs (glibc, linux-kernel, other kernels, drivers) then the
>aliasing stuff.

Dubious comparison at best.  Completely off the point, in my opinion.
That you even think of it that way strikes me as a fairly strange, careless
philosophy.  The asm checks broke things in a plain, visible way: code that 
no longer compiles.

Whereas aliasing problems are NOT diagnosed by anything else than programs
suddenly stopping working, or exhibiting subtle bugs.

Granted, these problems are fairly infrequent, but they were subtle enough
that ALL affected programmers have developped some degree of paranoia about
it... and don't forget that we know that checking the code by hand is the only
sure way to find aliasing problems, unless there are prototypes everywhere and
absolutely no casts.

This is an issue of overall system quality.  Stuff that stops working
in obvious ways is simple to take care off.   To wit: I managed to fix the
OpenBSD kernels __asm__ trouble, even though I don't know much about most
platforms we run on.

Right now, the problem we ran into with -strict-aliasing has led us to turn
it off everywhere by default...  this is the only safe approach, as we have
about 200 Mb of code to audit... and it is probably never going to be turned
back on again for packages, as most of these programs are not that nicely
maintained, and there's just too much code to audit.

We'd rather spend our time looking for security holes.

Re: type based aliasing again

[Jeffrey A Law]

  In message < 199909141102.NAA18232@quatramaran.ens.fr >you write:
  > Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
  > good idea. It's an issue of whether we consider this optimization as
  > `safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
  > as well, as it should decrease the code size. In the second case, I see
  > no reason to treat it differently from -ffast-math.
If you write correct code, the compiler will generate correct code with
strict aliasing.  If you write incorrect code, all bets are off.

It's not significantly different than automatic register allocation -- if you
write correct code, automatic register allocation will generate correct code.
If you write incorrect code, all bets are off.

Do you really want to punish people who write correct code just because your
code is not correct?

jeff

[GCC 3.0] Bad regression, binary size

[Marc Espie]

After fixing a few warnings, I've managed to compile OpenBSD kernels.
The results are BAD:

2.95.3 + peephole to handle stack adjustment, backported from current:
-rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd

3.0:
-rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd


Exact same source. Both are using -O2 -Os to compile.

This is on an i386.

This is pretty bad. Basically, it means we can't switch to 3.0 at all.

I'm going to look at the corresponding generated files, see if I can spot
some pattern.

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

In article < 20010705163930.A29149@schutzenberger.liafa.jussieu.fr > you write:

>2.95.3 + peephole to handle stack adjustment, backported from current:
>-rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd

>3.0:
>-rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd


>Exact same source. Both are using -O2 -Os to compile.

Hum, this is weird... the corresponding object sizes are not that far...
Anyone has any idea as to a linking issue that may explain that problem ?

Re: [GCC 3.0] Bad regression, binary size

[Joern Rennecke]

> Anyone has any idea as to a linking issue that may explain that problem ?

The shared libgcc contains a lot of functions that are never used.

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Thu, Jul 05, 2001 at 04:07:42PM +0100, Joern Rennecke wrote:
> > Anyone has any idea as to a linking issue that may explain that problem ?
> 
> The shared libgcc contains a lot of functions that are never used.

static binary. In fact -nostdlib, I forgot to say (bsd kernel).

Re: [GCC 3.0] Bad regression, binary size

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> In article < 20010705163930.A29149@schutzenberger.liafa.jussieu.fr > you write:
>> 2.95.3 + peephole to handle stack adjustment, backported from current:
>> -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd

>> 3.0:
>> -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd


>> Exact same source. Both are using -O2 -Os to compile.

Marc> Hum, this is weird... the corresponding object sizes are not that far...
Marc> Anyone has any idea as to a linking issue that may explain that problem ?

	Alignment?  Libraries (does OpenBSD link with libgcc.a?)?

David

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Thu, Jul 05, 2001 at 11:17:05AM -0400, David Edelsohn wrote:
> 	Alignment?  Libraries (does OpenBSD link with libgcc.a?)?

This is probably an alignment issue... Both binaries link by hand, using
ld -z -Ttext E0100000 -e start -x -o bsd ${SYSTEM_OBJ} vers.o


On gcc 3.0, total object size (wc -c) is 5459492, vs. 5450269  on 
gcc 2.95.3...

Next thing I do is I'm going to mix and match object files from both, see
if I notice a pattern.

Sorry if I give details slowly, this thing is confusing me a lot...
I really wouldn't have expected the size difference to show up that way.

Re: [GCC 3.0] Bad regression, binary size

[Geoff Keating]

Marc Espie <espie@schutzenberger.liafa.jussieu.fr> writes:

> After fixing a few warnings, I've managed to compile OpenBSD kernels.
> The results are BAD:
> 
> 2.95.3 + peephole to handle stack adjustment, backported from current:
> -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd
> 
> 3.0:
> -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
> 
> 
> Exact same source. Both are using -O2 -Os to compile.
> 
> This is on an i386.
> 
> This is pretty bad. Basically, it means we can't switch to 3.0 at all.
> 
> I'm going to look at the corresponding generated files, see if I can spot
> some pattern.

You might consider looking at the ix86_*_alignment functions in
i386.c.  From what I can see, they don't honour -Os at all.

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

Re: [GCC 3.0] Bad regression, binary size

[Richard Henderson]

On Thu, Jul 05, 2001 at 04:39:30PM +0200, Marc Espie wrote:
> 2.95.3 + peephole to handle stack adjustment, backported from current:
> -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd
> 
> 3.0:
> -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
> 
> Exact same source. Both are using -O2 -Os to compile.

Also try -mpreferred-stack-boundary=2.  The default is 16 byte
alignment, which your kernel almost certainly doesn't need, and
there is extra code to maintain that alignment.


r~

Re: [GCC 3.0] Bad regression, binary size

[Jamie Lokier]

Richard Henderson wrote:
> > -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd
> > 
> > 3.0:
> > -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
> > 
> > Exact same source. Both are using -O2 -Os to compile.
> 
> Also try -mpreferred-stack-boundary=2.  The default is 16 byte
> alignment, which your kernel almost certainly doesn't need, and
> there is extra code to maintain that alignment.

By the way, is this 16 byte stack alignment going to be a permanent
feature?

As far as I can tell, it is not necessary to 16-byte align all functions
just to help the performance of a few.  Instead, functions which pass
aligned arguments or use aligned locals, and which don't receive any
aligned argument, could use "and" to align the stack themselves.  It is
necessary to record the original stack pointer, but that is easy enough.

(The one case where this rule isn't perfect is variadic functions, but
alignment-related performance is not really an issue for those).

It seems to me this would improve performance, code density, and reduce
stack usage of functions which do not need the extra alignment, while at
the same time allow functions which do benefit from stack alignment to
perform as well as they do now.

This would also have the benefit that if a larger alignment is required
for some object, for example some structures like to be cache-line
aligned, then that can be accomodated too.

cheers,
-- Jamie

Re: [GCC 3.0] Bad regression, binary size

[Richard Henderson]

On Sat, Jul 07, 2001 at 11:41:48PM +0200, Jamie Lokier wrote:
> By the way, is this 16 byte stack alignment going to be a permanent
> feature?

Yes.

> As far as I can tell, it is not necessary to 16-byte align all functions
> just to help the performance of a few.  Instead, functions which pass
> aligned arguments or use aligned locals, and which don't receive any
> aligned argument, could use "and" to align the stack themselves.  It is
> necessary to record the original stack pointer, but that is easy enough.

Yes, this can be done, but it is _really_ expensive.  You can
no longer directly address stack arguments, and wind up burning
yet another register to address them.

The one thing that really ought to happen is to notice that
leaf functions don't need extra alignment.  Then remember
alignment required by previously compiled functions.


r~

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

In article < 20010707164531.C2847@redhat.com > you write:
>On Sat, Jul 07, 2001 at 11:41:48PM +0200, Jamie Lokier wrote:
>> By the way, is this 16 byte stack alignment going to be a permanent
>> feature?
>
>Yes.

Ugh.  It's a bad, bad, misoptimization.

99% of all code tends to be pretty much integer only.  You do not get
any wins from the alignment, and you do get clear losses.  For one,
function calls are clearly more expensive, and your dcache isn't as
dense. 

So you optimize for the 1% of benchmarks that care, at the expense of
the 99% of real-life code that doesn't?

>> As far as I can tell, it is not necessary to 16-byte align all functions
>> just to help the performance of a few.  Instead, functions which pass
>> aligned arguments or use aligned locals, and which don't receive any
>> aligned argument, could use "and" to align the stack themselves.  It is
>> necessary to record the original stack pointer, but that is easy enough.
>
>Yes, this can be done, but it is _really_ expensive.  You can
>no longer directly address stack arguments, and wind up burning
>yet another register to address them.

You can fix it in three easy-ish steps (famous last words):
 - require that functions that have alignment requirements have a frame
   pointer
 - make a "align frame pointer prologue" (which is not that different
   from the existing one - one extra "and")
 - load all alignment-wanting arguments into pseudos in the prologue
   after aliging the frame pointer (and let the normal spill code spill
   them if required - now they are aligned or are cached in registers). 

This would not have any negative impact on most code, and I don't see it
as being noticeably slower than the "always align" even for the FP-heavy
code. Especially as gcc _already_ defaults to having a frame pointer
even when optimizing.

gcc-3.0 already gets complaints for generating slower and more bloated
code than previous gcc releases. That should tell people something.

		Linus

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

In article < 200107082128.f68LS4x08156@penguin.transmeta.com > you write:
>gcc-3.0 already gets complaints for generating slower and more bloated
>code than previous gcc releases. That should tell people something.

Try not to jumble things together, please. The ix86 alignment properties
is nothing new at all. You can't really use the `gcc 3.0 is slower 
than previous releases' argument as a lever against it.

If gcc 3.0 is a problem for you, please dig deeper, and get the stack
alignment issues in a separate thread.

Re: [GCC 3.0] Bad regression, binary size

[Tim Prince]

----- Original Message -----
From: "Marc Espie" <espie@quatramaran.ens.fr>
To: <torvalds@transmeta.com>
Cc: <gcc@gcc.gnu.org>
Sent: Sunday, July 08, 2001 11:59 PM
Subject: Re: [GCC 3.0] Bad regression, binary size


> In article < 200107082128.f68LS4x08156@penguin.transmeta.com > you
write:
> >gcc-3.0 already gets complaints for generating slower and more
bloated
> >code than previous gcc releases. That should tell people something.
>
> Try not to jumble things together, please. The ix86 alignment
properties
> is nothing new at all. You can't really use the `gcc 3.0 is slower
> than previous releases' argument as a lever against it.
>
> If gcc 3.0 is a problem for you, please dig deeper, and get the stack
> alignment issues in a separate thread.

Several commercial compilers have options to make the stack 4- 8-, or
maybe 16- byte aligned.  I'd rather pay the occasional price of a
16-byte aligned stack than continue with the current dilemma of certain
g++ implementations breaking with more than 4-byte alignment, and the
consequent poor performance on larger objects.  In spite of public
pronouncements that gcc is not meant to support technical computing,
there are people who use 64-bit or larger objects.  gcc on linux has not
followed the MS tactic of disabling support for long double,  for
example.

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 9 Jul 2001, Marc Espie wrote:
>
> In article < 200107082128.f68LS4x08156@penguin.transmeta.com > you write:
> >gcc-3.0 already gets complaints for generating slower and more bloated
> >code than previous gcc releases. That should tell people something.
>
> Try not to jumble things together, please. The ix86 alignment properties
> is nothing new at all.

Hmm.. It was reported as the potential reason for the bigger OpenBSD
kernel.

Now, that report may obviously have been bogus, of course. There may be
something else going on. Linux uses "-mpreferred-stack-boundary=2" exactly
because the default behaviour of newer gcc's is very much suboptimal
(certainly for the kernel, and I will bet that it is for most applications
compiled with gcc).

		Linus

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Mon, Jul 09, 2001 at 09:09:08AM -0700, Linus Torvalds wrote:
> 
> On Mon, 9 Jul 2001, Marc Espie wrote:
> >
> > In article < 200107082128.f68LS4x08156@penguin.transmeta.com > you write:
> > >gcc-3.0 already gets complaints for generating slower and more bloated
> > >code than previous gcc releases. That should tell people something.
> >
> > Try not to jumble things together, please. The ix86 alignment properties
> > is nothing new at all.
> 
> Hmm.. It was reported as the potential reason for the bigger OpenBSD
> kernel.

No, you read this a bit too quick. Someone suggested to use
-mpreferred-stack-boundary to get the size back down, which actually does
work, but still does not give me any idea why my kernel is suddenly bigger.

The actual object sizes is +10K,
The resulting kernel is +60K,
compressed size difference is even larger.

As far as I know, my linker gets confused and no longer merges stuff it
used to, which I now wish to find.

Now, the rationale for keeping -mpreferred-stack-boundary `high' by default
is that  mixed code (`normal' code + floating point code) does need that
boundary by default, so if you turn that off, say in library code, then
all floating point code loses (because it's somewhat inefficient to regain
proper boundary, and the compiler does not really know when to emit that
code, e.g., where is the boundary between floating point code and
non-floating point code, since this is global stuff that isn't even
`fixed').

Kernels are special beasts, since they are completely isolated from
userland, and hence their stack boundary issues are very well isolated.

All this is even documented in the gcc documentation (e.g., 
preferred-stack-boundary is marked as a beneficial tweak for embedded
systems).


I can hardly fault the gcc team on preferred-stack-boundary...

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 9 Jul 2001, Marc Espie wrote:
>
> No, you read this a bit too quick. Someone suggested to use
> -mpreferred-stack-boundary to get the size back down, which actually does
> work, but still does not give me any idea why my kernel is suddenly bigger.

Ahh, ok.

> The actual object sizes is +10K,
> The resulting kernel is +60K,
> compressed size difference is even larger.

Bad compression? Doesn't sound like alignment or lack of merging. Although
the code alignment is using the "multi-byte nops", which might not
compress that well. If the default architecture has changed..

> Now, the rationale for keeping -mpreferred-stack-boundary `high' by default
> is that  mixed code (`normal' code + floating point code) does need that
> boundary by default, so if you turn that off, say in library code, then
> all floating point code loses (because it's somewhat inefficient to regain
> proper boundary, and the compiler does not really know when to emit that
> code, e.g., where is the boundary between floating point code and
> non-floating point code, since this is global stuff that isn't even
> `fixed').

But that's a bogus argument.

The compiler _does_ know when to emit the code. You only need to emit the
code when:
 - you have floating point arguments to a function you're calling (so that
   you can try to align the arguments - but realize that none of the x86
   ABI's really allow for true alignment ANYWAY)
 - you need to spill floating point

If you add these rules together, you also know that
 - you are already aligned if you got a floating point argument.

(Exchange "large object" for "floating point" - I realize that things like
XMM etc also want alignment. Also, you may want to modify the rule about
fp arguments - maybe not try to keep the stack itself aligned, but keep
instead the first fp argument aligned).

Now, floating point doesn't just happen on its own. When you have floating
point spills, I will bet you that in most cases you have floating point
arguments to your function too. Which means that with the above two
heuristics (and the rule you can infer from them), you will probably see
very little "unnecessary" alignment generation.

And the win? You see _no_ unnecessary alignment for the normal case.

And remember: you're supposed to optimize for the normal case. That's
rule#1 in optimization. Always.

> Kernels are special beasts, since they are completely isolated from
> userland, and hence their stack boundary issues are very well isolated.

I agree that kernels tend to have more well-defined behaviour, and for
that reason kernels (and embedded projects) can often use rules that are
illegal in general. HOWEVER, I disagree strongly that kernels are that
"special".

I would argue that floating point is a lot more special than kernels are.
I bet the code generation and optimization issues for kernels tend to be
closer to most programs than FP code tends to be. Which is why I think it
is the FP code that should be special-cased, not the kernel.

> I can hardly fault the gcc team on preferred-stack-boundary...

Why? Do you argue that it makes code better on average? I seriously doubt
it. And if you don't argue that, then why just accept the "we will always
do this thing" decision?

Now, I can accept the fact that some people may think it is _easier_ to
just always keep the stack aligned. That's a technical judgement, and
likely to be true. But if THAT is the reason for the alignment, then I
would still fault rth for saying "it will always be so". Maybe somebody
comes along and is willing to fix it, and I would hope that the gcc
developers would jump for joy, instead of being set on a course of bad
code generation for the default case.

		Linus

Re: [GCC 3.0] Bad regression, binary size

[Paolo Carlini]

Hi,

Linus Torvalds wrote:

> Now, that report may obviously have been bogus, of course. There may be
> something else going on. Linux uses "-mpreferred-stack-boundary=2" exactly
> because the default behaviour of newer gcc's is very much suboptimal
> (certainly for the kernel, and I will bet that it is for most applications
> compiled with gcc).

The "flops" benchmark (f.i., http://ftp.sunet.se/pub2/benchmark/aburto/flops/ )
clearly demostrates this point: just try building it with 3.0.x with and
without -mpreferred-stack-boundary=2. The difference is impressive.

My two cents,
Paolo Carlini.

Re: [GCC 3.0] Bad regression, binary size

[Richard Henderson]

On Sun, Jul 08, 2001 at 02:28:04PM -0700, Linus Torvalds wrote:
> You can fix it in three easy-ish steps (famous last words):

Oh, no.  You can't get away that easily.

>  - make a "align frame pointer prologue" (which is not that different
>    from the existing one - one extra "and")

Not quite -- you have to play games to get a proper pointer 
to the argument list so that you can do your step 3.

>  - load all alignment-wanting arguments into pseudos in the prologue
>    after aliging the frame pointer (and let the normal spill code spill
>    them if required - now they are aligned or are cached in registers). 

Which might work ok for small numbers of arguments, but
is going to be excruciating when someone passes in 30
arguments, or worse, passes a structure by value.

> This would not have any negative impact on most code,
> and I don't see it as being noticeably slower than the
> "always align" even for the FP-heavy code.

I think you'd be surprised how ugly forced stack alignment
is in practice.


r~

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

In article < 20010709144855.B10117@redhat.com > you write:
>On Sun, Jul 08, 2001 at 02:28:04PM -0700, Linus Torvalds wrote:
>> You can fix it in three easy-ish steps (famous last words):
>
>Oh, no.  You can't get away that easily.
>
>>  - make a "align frame pointer prologue" (which is not that different
>>    from the existing one - one extra "and")
>
>Not quite -- you have to play games to get a proper pointer 
>to the argument list so that you can do your step 3.

Ehh, what's wrong with just

        pushl %ebp
        movl %esp,%ebp
        subl $needed+16,%esp
        andl $-15,%esp

which is just one instruction longer than the current regular frame 
prologue, and leaves you with a aligned stack pointer AND a perfectly   
      
good way to get to the argument frame (the frame pointer).

Sure, if people use "alloca()" or other fancy stuff (variable-sized
automatic variables etc), then you might need an extra instruction or   
two to actually align the stack. How common is that? That case does need
some extra work, I agree.
  
>>  - load all alignment-wanting arguments into pseudos in the prologue
>>    after aliging the frame pointer (and let the normal spill code spill
>>    them if required - now they are aligned or are cached in registers). 
>
>Which might work ok for small numbers of arguments, but
>is going to be excruciating when someone passes in 30
>arguments, or worse, passes a structure by value.

Anyway, there's a simpler approach for that: when passing in values that
need alignment, we align the stack in the caller.  That way you know
that your frame is always as aligned as it can be, AND the callee has
the additional knowledge that because it was passed in a FP value it
doesn't need to do the extra alignment itself.

So the only reason to ever do the above alignment stuff is
 - you haven't been passed in a aligned value, but you need to spill
   one, or you need to call one with one on the stack.

Statistics, anyone? I bet heavy FP code has FP arguments, which means
that the stack needs alignment very seldom indeed. Same is probably true
for XMM etc too.

			Linus

Re: [GCC 3.0] Bad regression, binary size

[Joern Rennecke]

> >Not quite -- you have to play games to get a proper pointer 
> >to the argument list so that you can do your step 3.
> 
> Ehh, what's wrong with just
> 
>         pushl %ebp
>         movl %esp,%ebp
>         subl $needed+16,%esp
>         andl $-15,%esp
> 
> which is just one instruction longer than the current regular frame 
> prologue, and leaves you with a aligned stack pointer AND a perfectly   
>       
> good way to get to the argument frame (the frame pointer).
> 
> Sure, if people use "alloca()" or other fancy stuff (variable-sized
> automatic variables etc), then you might need an extra instruction or   
> two to actually align the stack. How common is that? That case does need
> some extra work, I agree.

You can only ause your prologue variant when you could otherwide use
-fomit-frame-pointer.  And you also pay the price of having prefix bytes
for all the variable accesses on the stack.  Yet you won't get the benefit
of using %ebp as a general purpose registers.

> Anyway, there's a simpler approach for that: when passing in values that
> need alignment, we align the stack in the caller.  That way you know
> that your frame is always as aligned as it can be, AND the callee has
> the additional knowledge that because it was passed in a FP value it
> doesn't need to do the extra alignment itself.

IMHO marking functions in libc that have callbacks to user code or that
generally call - directly or indirectly - functions that do floating point
processing or callbacks, so that these specifically preserve 16 byte
alignment, should go a long way to avoid misalignment slowdown for programs
that want alignment, while not significantly slowing down integer code due
to data cahe misses.

Re: [GCC 3.0] Bad regression, binary size

[Richard Henderson]

On Mon, Jul 09, 2001 at 03:22:09PM -0700, Linus Torvalds wrote:
> Ehh, what's wrong with just
> 
>         pushl %ebp
>         movl %esp,%ebp
>         subl $needed+16,%esp
>         andl $-15,%esp
> 
> which is just one instruction longer than the current regular frame 
> prologue, and leaves you with a aligned stack pointer AND a perfectly   
> good way to get to the argument frame (the frame pointer).

Hmm.  Normally we eliminate all stack frame references to EBP.
This would work ok except when alloca is used.

> Sure, if people use "alloca()" or other fancy stuff (variable-sized
> automatic variables etc), then you might need an extra instruction or   
> two to actually align the stack. How common is that?

It's not uncommon, but certainly less common than needing
aligned stack frames.

> Statistics, anyone? I bet heavy FP code has FP arguments, which means
> that the stack needs alignment very seldom indeed. Same is probably true
> for XMM etc too.

It'd be a decent thing to collect.

That said, for the newest processors, P4, Athlon, and x86-64,
it's a win to allocate all of the outgoing argument space in
the prologue and use mov instaed of push.  At which point keeping
the stack aligned takes zero extra instructions.


r~

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 9 Jul 2001, Joern Rennecke wrote:
>
> You can only ause your prologue variant when you could otherwide use
> -fomit-frame-pointer.

No. Read the thing again. It's a perfectly fine prologue - it's kind of
what gcc does already for alloca.

But I already stated that yes, this basically ends up using a frame
pointer for FP stuff. gcc does that anyway, even for -O2, so considering
hat we speed up everything else that sounds like a really good tradeoff.

Have you seen some of the benchmarks, and how much the stack alignment
hits newer gcc's?

		Linus

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 9 Jul 2001, Richard Henderson wrote:
>
> That said, for the newest processors, P4, Athlon, and x86-64,
> it's a win to allocate all of the outgoing argument space in
> the prologue and use mov instaed of push.  At which point keeping
> the stack aligned takes zero extra instructions.

Hmm. It's obviously not true at least for one case: functions that do not
need a frame and that call other functions without arguments. But at that
point it might not matter any more.

		Linus

size_t printf warnings and preprocessor

[Marc Espie]

I would love to get size_t warnings for printf out of gcc.
I've already noticed that 3.0 is much better at following typeinfo than
2.95 used to.

I would like to have a switch such that 
size_t var;
printf(format, var);

invariably ends in an error, as there can't be a single format that works
with size_t.

Understandably, this warning ought to be tunable, as somebody may be 
playing macro-processor tricks to ensure the format does indeed match size_t
on the machine at hand.

Okay so far, I think I can write all this.

Now, for the next trick: since the new preprocessor is somewhat better 
integrated with gcc, would it be possible to pass string information
along.

Say, if you have a specific format specifier for size_t, say
FMT_SIZE_T (I think there's even such a specifier as part of C9X),
and the format used with printf is obtained through ansi string concatenation,
then all that would be needed would be to mark this string as special
(in the preprocessor) so that gcc knows better when to drop the warning.

It could either be achieved by passing stuff behind the scene, or
maybe emitting an extra attribute: (extends gcc grammar slightly ?) so that
one could mark substrings and such...

I haven't looked where ansi string folding occurs, but you could mark a
string as being `suitable for size_t' (say, 
#define FMT_SIZE_T "%lu" __attribute__((size_t_format))
and string concatenation would retain that property (possibly, each `folded'
string would have to keep a list of annotated strings around, so that
format checking could become much more precise.

In my opinion, this could become VERY useful with C9X...

Re: size_t printf warnings and preprocessor

[Andreas Jaeger]

Marc Espie <espie@quatramaran.ens.fr> writes:

> I would love to get size_t warnings for printf out of gcc.
> I've already noticed that 3.0 is much better at following typeinfo than
> 2.95 used to.
> 
> I would like to have a switch such that 
> size_t var;
> printf(format, var);
> 
> invariably ends in an error, as there can't be a single format that works
> with size_t.

"%z" is specified by ISO C 99 for size_t.  So what's wrong with printf
("%z\n", var) ?

Sorry, I'm lost with your proposal.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: size_t printf warnings and preprocessor

[Marc Espie]

On Thu, Jul 12, 2001 at 05:48:52PM +0200, Andreas Jaeger wrote:
> Marc Espie <espie@quatramaran.ens.fr> writes:
> 
> > I would love to get size_t warnings for printf out of gcc.
> > I've already noticed that 3.0 is much better at following typeinfo than
> > 2.95 used to.
> > 
> > I would like to have a switch such that 
> > size_t var;
> > printf(format, var);
> > 
> > invariably ends in an error, as there can't be a single format that works
> > with size_t.
> 
> "%z" is specified by ISO C 99 for size_t.  So what's wrong with printf
> ("%z\n", var) ?
> 
> Sorry, I'm lost with your proposal.

Nothing is wrong, I don't have the C99 proposal with me... :)

Okay, what I'm proposing still makes sense in the legacy case, for people
who have written code before %z and who would like it checked.

Also, in pedantic C99 mode, do we warn when size_t is used without %z ?

Re: size_t printf warnings and preprocessor

[Andreas Jaeger]

Marc Espie <espie@schutzenberger.liafa.jussieu.fr> writes:

> On Thu, Jul 12, 2001 at 05:48:52PM +0200, Andreas Jaeger wrote:
>> Marc Espie <espie@quatramaran.ens.fr> writes:
>> 
>> > I would love to get size_t warnings for printf out of gcc.
>> > I've already noticed that 3.0 is much better at following typeinfo than
>> > 2.95 used to.
>> > 
>> > I would like to have a switch such that 
>> > size_t var;
>> > printf(format, var);
>> > 
>> > invariably ends in an error, as there can't be a single format that works
>> > with size_t.
>> 
>> "%z" is specified by ISO C 99 for size_t.  So what's wrong with printf
>> ("%z\n", var) ?
>> 
>> Sorry, I'm lost with your proposal.
> 
> Nothing is wrong, I don't have the C99 proposal with me... :)
> 
> Okay, what I'm proposing still makes sense in the legacy case, for people
> who have written code before %z and who would like it checked.
> 
> Also, in pedantic C99 mode, do we warn when size_t is used without %z ?

Now I get it - you do it the other way round.  You want to allow
size_t only with %z and forbid e.g. "%ld", var or even "%ld",(long)var.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: size_t printf warnings and preprocessor

[Joseph S. Myers]

On Thu, 12 Jul 2001, Marc Espie wrote:

> I would like to have a switch such that 
> size_t var;
> printf(format, var);
> 
> invariably ends in an error, as there can't be a single format that works
> with size_t.

With C99, people should just use %zu, which will work.  C89 programmers,
if conscientious, will have been casting size_t to (unsigned long) and
using %lu.

If you want warnings for other formats, arrange for size_t to be the
magical sizetype node everywhere, and for this to be a proper extended
integer type - but that is the opposite direction to the way things have
been going (ensuring that sizetype doesn't appear as a type in user code,
only c_size_type_node) and non-conforming to C89, in which size_t must be
one of the standard integer types (DR#067).

I think attempting to track where the format strings came from and whether
there might be problems on other systems is too much complexity for too
little gain.  You can analyse programs for bugs with a compiler, and this
will only examine the code that applies on the system you use; or you can
analyse them with separate analysis tools, which may handle #ifdef-ed out
code and portability issues, but can't leverage compiler internals in the
same way.

Attributes on string literals could be useful, but for such purposes as
putting them in special sections rather than marking their format
properties.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 23 Jul 2001 dewar@gnat.com wrote:
>
> <<My argument is really the same, but with a twist: keep it alive, but
> don't make it the default if it makes non-FP code bigger.
> >>
>
> It is always tricky to argue about defaults. One critical issue with defaults
> is to make benchmarks work better out of the box, but the default of -O0
> seriously undermines this design criterion in any case.

I suspect that everybody who does benchmarking are so aware of the -O flag
that the "default" to not optimize is not really a default at all except
in a very theoretical sense. Although maybe gcc could make the default -O
a bit stronger.

But talking about the -O flag, I _really_ think that the fact that -O3
generally generates much worse code than -O2 is non-intuitive and can
really throw some people.

Why does -O3 imply "-finline-functions", when it's been shown again and
again to just make things worse? Now the current gcc seems to have fixed
this to some degree by just making "-finline-functions" much weaker
(good), but still, shouldn't we always have the rule that higher
optimization numbers tends to make code run faster for at least a
meaningful subset of the word "code" ;)

If somebody wants to pessimize their code by inlining everything, let them
use -O-1 ("inline everything, but don't bother with things like CSE" ;^),
or jst explicitly say "-finline".

This certainly threw me the first time I used gcc. I remember how the
original Linux makefiles used "-O6" because some place had (incorrectly)
mentioned that -Ox modified gcc behaviour up to the value 6, and I assumed
that -O6 would be better than -O2.

I think it would make much more sense if -O3 meant everything that -O2
does, plus the things we don't do because it makes debugging harder (ie
-fomit-frame-pointer and similar). That actually speeds things up and
makes code visibly smaller at times. Unlike the current fairly strange
thing -O3 does..

(Yeah, I know, we already turn on -fomit-frame-pointer for -O, but only on
the few targets where it doesn't hurt debugging. I'm just saying that
maybe we should do it for everything once you hit -O3, and then gently
warn about the combination of -O3 and -g).

		Linus

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<My argument is really the same, but with a twist: keep it alive, but
don't make it the default if it makes non-FP code bigger.
>>

It is always tricky to argue about defaults. One critical issue with defaults
is to make benchmarks work better out of the box, but the default of -O0
seriously undermines this design criterion in any case.

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

In article < 200107231146.NAA11586@mach.thp.univie.ac.at > you write:
>In message <URL: http://gcc.gnu.org/ml/gcc/2001-07/msg00617.html >,
>Linus Torvalds <torvalds at transmeta dot com> wrote
>> I would argue that floating point is a lot more special than kernels are.
>> I bet the code generation and optimization issues for kernels tend to be
>> closer to most programs than FP code tends to be. Which is why I think it
>> is the FP code that should be special-cased, not the kernel.
>
>I think this is a fundamental philosophical point... with which I
>strongly disagree.  The problem is that referring to "most" programs
>begs the question of just which sort of workload you're sampling.
>
>I'd like to put in a voice to urge that fp performance continue to be
>treated as "important".  Indeed, the integer programs that _I_ use
>(including OS kernels, shells, web browsers, not to mention gcc itself)
>are generally either not CPU-bound, or are already "fast enough", so
>I really don't care very much about integer performance.  But the fp
>codes I develop and use for a living are all painfully slow, and the
>science I'm doing with them would be a lot better if they were faster,
>so I care a lot about fp performance.

I'm absolutely not arguing against you.

I would, for example, suspect that a "correct" optimization strategy for
99% of all real-world cases (not benchmarks) is:

 - if it doesn't have floating point, optimize for the smallest size
   possible. Never do loop unrolling or anything fancy like that. 

 - if it has floating point or MMX, go wild at that point.

(And make the "has floating point" decision something more clever than
just "oh, I saw a fp reg here").

>So please, keep those fp-performance options (eg 16-byte stack alignment
>without having to always use a frame pointer on x86) alive for those of
>us who care!

My argument is really the same, but with a twist: keep it alive, but
don't make it the default if it makes non-FP code bigger.

Think of it this way: the single biggest slowdown that people react to
badly on most machines is the initial loading time for a binary. There
really aren't that many machines made today that "feel slow" from a CPU
standpoint.

Which means that loop optimizations seldom make sense for most things. 
Most integer workloads have fairly low repeat-rates: we're talking
hundreds or maybe few thousand repeats of most loops.  You have to make
those loops a heck of a lot faster to make up for a single page-fault
brought on by making the code larger.  Even just a single icache miss
(and you're pretty much _guaranteed_ an icache miss on program startup)
tends to be enough to the advantage of a win of a cycle or two. 

Most programs have become _less_ loopy, and the loops have grown much
bigger. 

The exception is FP and vector-integer stuff (MMX, AltiVec, whatever you
call it). 

		Linus

Re: [GCC 3.0] Bad regression, binary size

[Jonathan Thornburg]

In message <URL: http://gcc.gnu.org/ml/gcc/2001-07/msg00617.html >,
Linus Torvalds <torvalds at transmeta dot com> wrote
> I would argue that floating point is a lot more special than kernels are.
> I bet the code generation and optimization issues for kernels tend to be
> closer to most programs than FP code tends to be. Which is why I think it
> is the FP code that should be special-cased, not the kernel.

I think this is a fundamental philosophical point... with which I
strongly disagree.  The problem is that referring to "most" programs
begs the question of just which sort of workload you're sampling.

I'd like to put in a voice to urge that fp performance continue to be
treated as "important".  Indeed, the integer programs that _I_ use
(including OS kernels, shells, web browsers, not to mention gcc itself)
are generally either not CPU-bound, or are already "fast enough", so
I really don't care very much about integer performance.  But the fp
codes I develop and use for a living are all painfully slow, and the
science I'm doing with them would be a lot better if they were faster,
so I care a lot about fp performance.

And yes, there are people doing serious fp on x86.  It may be a kludge
of an architecture, but sometimes money talks... and the newer x86 cpus
have significantly improved fp over older ones.

So please, keep those fp-performance options (eg 16-byte stack alignment
without having to always use a frame pointer on x86) alive for those of
us who care!

-- 
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany             http://www.aei.mpg.de/~jthorn/home.html
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

Re: [GCC 3.0] Bad regression, binary size

[Daniel Berlin]

Phil Edwards <pedwards@disaster.jaj.com> writes:

> On Mon, Jul 09, 2001 at 02:54:21PM -0700, Justin Guyett wrote:
>> I dunno about the 1minute+ helloworld compile time someone just suggested,
>> but this is disturbing:
>> (v2.95) g++ -o hello hello.cc  0.15s user 0.03s system 96% cpu 0.186 total
>> (v3.0)  g++ -o hello hello.cc  2.04s user 0.06s system 99% cpu 2.102 total
>> 
>> if there's a 2 second loading overhead for g++v3, that's 2 seconds * (#
>> files) which can be quite a lot in large trees.  Is this simply from
>> linking in the new libstdc++?
> 
> Parsing the libstdc++ headers takes time, mostly because nearly all the
> code is in the headers.  Once we have 'export' this should be
> better.

This isn't the trouble, it's the inlining.
We expand something from 300 insns to 15k insns, which itself takes
time, memory, and then the backend has to deal with a lot more.

Parsing took < 5 seconds on my example.
It was the rest of compilation that took > 30 seconds.
Without inlining, it took 5 seconds at -O3 total.
There must be a happy medium.

 
> 
> Phil
> 
> -- 
> Would I had phrases that are not known, utterances that are strange, in
> new language that has not been used, free from repetition, not an utterance
> which has grown stale, which men of old have spoken.
>                                      - anonymous Egyptian scribe, c.1700 BC

-- 
"I put tape on the mirrors in my house so I don't accidentally
walk through into another dimension.
"-Steven Wright

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Mon, Jul 09, 2001 at 06:00:15PM -0400, Phil Edwards wrote:

> Parsing the libstdc++ headers takes time, mostly because nearly all the
> code is in the headers.  Once we have 'export' this should be better.

Right, sometimes this century maybe, hopefully...

I wouldn't bitch too much about C++... it's probably going to be a
nightmare when compiling kde (which already takes insanely long), but C
code apparently goes slightly slower, maybe 10%...

Much less worse than 2.8 -> 2.95.

Anyways, I hope 3.1 is going to be faster than 3.0, for a change...

Re: [GCC 3.0] Bad regression, binary size

[Phil Edwards]

On Mon, Jul 09, 2001 at 02:54:21PM -0700, Justin Guyett wrote:
> I dunno about the 1minute+ helloworld compile time someone just suggested,
> but this is disturbing:
> (v2.95) g++ -o hello hello.cc  0.15s user 0.03s system 96% cpu 0.186 total
> (v3.0)  g++ -o hello hello.cc  2.04s user 0.06s system 99% cpu 2.102 total
> 
> if there's a 2 second loading overhead for g++v3, that's 2 seconds * (#
> files) which can be quite a lot in large trees.  Is this simply from
> linking in the new libstdc++?

Parsing the libstdc++ headers takes time, mostly because nearly all the
code is in the headers.  Once we have 'export' this should be better.


Phil

-- 
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
                                     - anonymous Egyptian scribe, c.1700 BC

Re: [GCC 3.0] Bad regression, binary size

[Justin Guyett]

On Mon, 9 Jul 2001, Neil Booth wrote:

> Gerald Pfeifer wrote:-
>
> > Indeed, GCC 3.0 takes an order of magnitude longer to compile my sources,
>
> That's not fair - it's not compiling the same sources if you're
> talking about C++ with the standard library, which I presume you are.

I dunno about the 1minute+ helloworld compile time someone just suggested,
but this is disturbing:
(v2.95) g++ -o hello hello.cc  0.15s user 0.03s system 96% cpu 0.186 total
(v3.0)  g++ -o hello hello.cc  2.04s user 0.06s system 99% cpu 2.102 total

if there's a 2 second loading overhead for g++v3, that's 2 seconds * (#
files) which can be quite a lot in large trees.  Is this simply from
linking in the new libstdc++?

c performance is still fine afaict

openssl 0.9.6a (probably not the best choice in the world, but it'll do):

v3.0 (733)
(O3, m486)       make  183.20s user 10.17s system 98% cpu 3:16:49 total
(O2, march=i686) make  177.66s user 10.44s system 99% cpu 3:08.32 total
(-O -march=i686) make  144.05s user 9.64s  system 99% cpu 2:33:84 total

vs v2.95 (850) (but slower hdd)
(O3, m486)       make  130.88s user 15.06s system 90% cpu 2:41.03 total
(O2, march=i686) make  128.23s user 15.73s system 92% cpu 2:36.26 total
(-O -march=i686) make  128.82s user 15.17s system 92% cpu 2:35.58 total

A better rebuttal for c compilation might be that gcc 3.0 is slower with
significant optimization, but 2.95 doesn't seem to be doing much more
optimizing in -O2 vs -O.  Keep in mind the CPU speed difference.

If you're compiling so much, perhaps the better model would be to use -O
or -O0 until you need a release-speed build to do stress testing with, at
which point it makes sense to spend longer compiling for incrementally
smaller code speed increases.  It may not have made very much difference
in 2.95, but it makes sense that it _should_, given a compiler that
actually does significantly more processing for higher optimization
levels.


justin

Re: [GCC 3.0] Bad regression, binary size

[Bobby McNulty]

----- Original Message -----
From: "Gerald Pfeifer" <pfeifer@dbai.tuwien.ac.at>
To: "Neil Booth" <neil@daikokuya.demon.co.uk>
Cc: "Marc Espie" <espie@quatramaran.ens.fr>; <gcc@gcc.gnu.org>
Sent: Monday, July 09, 2001 4:13 PM
Subject: Re: [GCC 3.0] Bad regression, binary size


> On Mon, 9 Jul 2001, Neil Booth wrote:
> >> Indeed, GCC 3.0 takes an order of magnitude longer to compile my
sources,
> > That's not fair - it's not compiling the same sources if you're
> > talking about C++ with the standard library, which I presume you are.
>
> Well, yes. As I wrote "Plus, a lot of that slowdown probably is due to
> libstdc++-v3 and its much more standards compliant implementation of
> iterators etc."
>
> But, frankly, as I user I'm mainly seeing the following: It's exactly
> the same source that compiles without warning under both compilers, and
> one compiler takes significantly more time and more memory to generate a
> binary that is both larger and slower.
>
> Gerald
> --
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at
http://www.dbai.tuwien.ac.at/~pfeifer/
>
I noticed in Linux Mandrake 8.0, with GCC 3.0.1 prerelease, the C++ took
about a minute to compile a simple "Hello, World" program, but GCC took less
than a second. BTW I did not recompile GLIBC or the Kernel.
Now, I'm back with Windows 98 and Cygwin. I was just reading the list when I
found the slowdown messages.
Perhaps the size does play a lot with it.
        Bobby McNulty
        Computer Enthusiest.

Re: [GCC 3.0] Bad regression, binary size

[Gerald Pfeifer]

On Mon, 9 Jul 2001, Neil Booth wrote:
>> Indeed, GCC 3.0 takes an order of magnitude longer to compile my sources,
> That's not fair - it's not compiling the same sources if you're
> talking about C++ with the standard library, which I presume you are.

Well, yes. As I wrote "Plus, a lot of that slowdown probably is due to
libstdc++-v3 and its much more standards compliant implementation of
iterators etc."

But, frankly, as I user I'm mainly seeing the following: It's exactly
the same source that compiles without warning under both compilers, and
one compiler takes significantly more time and more memory to generate a
binary that is both larger and slower.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: [GCC 3.0] Bad regression, binary size

[Neil Booth]

Gerald Pfeifer wrote:-

> Indeed, GCC 3.0 takes an order of magnitude longer to compile my sources,

That's not fair - it's not compiling the same sources if you're
talking about C++ with the standard library, which I presume you are.

Neil.

Re: [GCC 3.0] Bad regression, binary size

[Gerald Pfeifer]

On Mon, 9 Jul 2001, Marc Espie wrote:
> <devil's advocate>
> Err... New compilers are supposed to be BETTER than old ones. Ideally, there
> should be no regression at all ! What's the damn point of -Os if successive
> releases of the compiler keep getting out larger and larger code ?

Indeed, GCC 3.0 takes an order of magnitude longer to compile my sources,
about three times as much of memory, and the generated code runs slower
(on ia32, one of the platforms most improved for GCC 3.0).

> In fact, what's the point of adding and adding more optimizing passes to
> the compiler if all it does is keep the code size mostly identical, keep
> the running time mostly identical, and slow the compiler down even more ?

That's a question I've asked myself as well, yes. :-(

On point, and a crucial so, is infrastructure. The new C++ inliner got us
rid of a lot of bugs and will allow for significant improvements in the
near future. Plus, a lot of that slowdown probably is due to libstdc++-v3
and its much more standards compliant implementation of iterators etc.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds]

On Mon, 9 Jul 2001 dewar@gnat.com wrote:
>
> <<I would argue that floating point is a lot more special than kernels are.
> I bet the code generation and optimization issues for kernels tend to be
> closer to most programs than FP code tends to be. Which is why I think it
> is the FP code that should be special-cased, not the kernel.
> >>
>
> But it is not just floating-point, it is any 8 or 16 byte object, such
> as a 64-bit integer, or a struct with two 32-bit fields.

Structs with two 32-bit fields? Why? They are accessed with 32-bit
operations, they don't need any alignment.

Using MMX opcodes for moving 8-byte entities around is _stupid_. You get
FP save/restore exceptions everywhere. The break-even point for using MMX
(and trust me, the kernel people have done the numbers) tends to be in the
kilobyte range. So something like memcpy()/memset() will use it, but as it
only makes sense with large areas and with XMM anyway (and XMM has support
for unaligned start/end stuff), I seriously doubt it's an issue.

But read my email again: I did say that "floating point" is "any large
object". Yes it happens. But yes, it also tends to be very localized.
Whether we're talking about "long long" or "long double" or
"xmm_fp_type_t". And I claim that my heuristic should work rather
efficiently.

There are numbers to back up the problems with stack alignment. Just
search the archives on this list.

Show me the numbers that back up the fact that stack alignment is globally
necessary. I doubt you will find a _single_ benchmark that would hurt from
doing it just locally.

I have the numbers for the current practice being BAD. You show me yours
to back up YOUR claims.  Until you do, you're just spouting opinions and
hot air.

And that's not how you should do optimization work.

		Linus

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<I would argue that floating point is a lot more special than kernels are.
I bet the code generation and optimization issues for kernels tend to be
closer to most programs than FP code tends to be. Which is why I think it
is the FP code that should be special-cased, not the kernel.
>>

But it is not just floating-point, it is any 8 or 16 byte object, such
as a 64-bit integer, or a struct with two 32-bit fields.

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<If it causes us not to be able to switch to gcc 3.0.x six months from now,
it is quite serious, from my point of view...
>>

There are many reasons why a specific project might not want to switch
to a new version of the compiler, but that does not mean there is a serious
regression. For example, a project might be depending on a bug, now fixed,
and thus be delayed in switching versions of the compiler, but that does
not make it a regression.

it is really helpful NOT to overuse the technical term regression, which
simply means that *with respect to the target specifications* there is
an instance of failing to meet specs where before the spec was met.

THat's not the case here, there was no spec that your particular program
generate 0.98X space instead of 1.00X space

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Mon, Jul 09, 2001 at 10:17:54AM -0400, dewar@gnat.com wrote:

> The issue is with calling this a "serious regression", that's obviously
> inappropriate.

If it causes us not to be able to switch to gcc 3.0.x six months from now,
it is quite serious, from my point of view...

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<Err... New compilers are supposed to be BETTER than old ones. Ideally, there
should be no regression at all ! What's the damn point of -Os if successive
releases of the compiler keep getting out larger and larger code ?
>>

A requirement that -Os not increase code size for any possible program is
clearly unreasonable. It may well be that some particular *size* optimization
helps nearly all programs, but not that particular one.

Or, as discussed in the thread on alignment, a change in ABI conventions
may cause code size increases that are justified in terms of general
performance improvement (obviously -Os should not affect the ABI).

<<In fact, as I stated already, this seems to be a weird linker/compiler
interaction, which I'm going to try to figure out.
>>

Well of course anytime we see some anomolous behavior like this, we should
try to understand it, and if in fact the behavior can be improved, then we
should indeed fix it. No one argues with that.

The issue is with calling this a "serious regression", that's obviously
inappropriate.

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

In article < 20010705154207.74D63F2B5E@nile.gnat.com > you write:
><<This is a significant regression from 2.95.2. Fortunately, it does seem to
>come from some linker issue which I hope to figure out, but be assured this
>kind of problem is very serious.

>I really can't agree that a 2% difference in object size is a significant
>regression. Optimization is a trade off between size and execution speed,
>and you may well get variations in this range from one version of a compiler
>to another.

<devil's advocate>
Err... New compilers are supposed to be BETTER than old ones. Ideally, there
should be no regression at all ! What's the damn point of -Os if successive
releases of the compiler keep getting out larger and larger code ?

In fact, what's the point of adding and adding more optimizing passes to
the compiler if all it does is keep the code size mostly identical, keep
the running time mostly identical, and slow the compiler down even more ?

And I'm not even talking some obscure, half-supported platform like m68k,
which has had ICEs every new release since 2.8, but i386...

One issue is that updating is necessary to get work-in-progress progress 
on real important things, like C++ support. Why does this have to come
with plain old C regressions ?
</devil's advocate>

In fact, as I stated already, this seems to be a weird linker/compiler 
interaction, which I'm going to try to figure out.

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<This is a significant regression from 2.95.2. Fortunately, it does seem to
come from some linker issue which I hope to figure out, but be assured this
kind of problem is very serious.
>>

I really can't agree that a 2% difference in object size is a significant
regression. Optimization is a trade off between size and execution speed,
and you may well get variations in this range from one version of a compiler
to another.

An embedded system with only 2% headroom is an abomination.

As for fitting on a floppy, that really entirely marginal. it sounds like
you have been desparately close the floppy limit for a while, and at this
stage nothing gets distributed on floppies anyway.

Re: [GCC 3.0] Bad regression, binary size

[Marc Espie]

On Thu, Jul 05, 2001 at 11:31:35AM -0400, dewar@gnat.com wrote:
> <<2.95.3 + peephole to handle stack adjustment, backported from current:
> -rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd

> 3.0:
> -rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
> >>

> I don't understand, are you saying that the less than 2% increase in
> size is so worrisome that you cannot switch? If so, that's an odd
> claim indeed.

Think `embedded systems'. In the case at hand, being able to fit a
compressed image on a floppy or not makes all the difference in the world.

This is a significant regression from 2.95.2. Fortunately, it does seem to
come from some linker issue which I hope to figure out, but be assured this
kind of problem is very serious.

Re: [GCC 3.0] Bad regression, binary size

[dewar]

<<2.95.3 + peephole to handle stack adjustment, backported from current:
-rwxr-xr-x   1 espie    wheel     3994332 Jul  5 16:08 bsd

3.0:
-rwxr-xr-x   1 espie    wheel     4068067 Jul  5 16:35 bsd
>>

I don't understand, are you saying that the less than 2% increase in
size is so worrisome that you cannot switch? If so, that's an odd
claim indeed.