egcs-1.1 release schedule

egcs-1.1 release schedule

[Jeffrey A Law]

                                  egcs-1.1
                                      
   The egcs project is rapidly approaching its second major release
   (egcs-1.1).
   
   This page is meant to provide information about the current schedule
   for egcs-1.1, the testing/release criteria for egcs-1.1, new features
   to be found in egcs-1.1, etc.
   
   The tenative schedule for the egcs-1.1 release is:
     * July 3, 1998. Feature freeze date.
       All new features, optimizations, etc need to be submitted by this
       date. It is very likely we will not be able to integrate all the
       submissions, but we want to have all of them available for
       evaluation by this date.
       It is also possible some patches which have been submitted and are
       accepted for egcs-1.1 will not have been installed by this date
       due to EOQ committments for many of the Cygnus volunteers.
       After July 3, 1998, only bugfix submissions will be considered for
       the egcs-1.1 release.
       By July 3, 1998, we also want to have a testing plan and release
       criteria in place.
     * July 11, 1998. Branch Creation & Testing.
       We will create the egcs-1.1 branch on this date and snapshots will
       occur from the egcs-1.1 branch instead of the mainline sources.
       By this date we'd like to have all the new features,
       optimizations, etc slated for the egcs-1.1 release installed in
       the source tree.
       We also expect wide scale, focused testing to start on July 11th.
     * July 31, 1998. Critial Bug Freeze Date.
       If at all possible we would like to see the release sources freeze
       except for critical bug fixes by July 31st. This may be overly
       optimistic, but it's important to have a goal to shoot for.
       
   I would like to release as soon as possible in early August.
   
   Note that we have the ability to install changes into the mainline
   sources during this process. However, I personally will be focusing
   more and more on egcs-1.1 specific issues.
   
   It is highly likely we will have some minor releases based on
   egcs-1.1; we will cross that bridge when the time comes.
   
   I also want to do a post-release review of the proposed schedule vs
   the actual schedule used for egcs-1.1 so that we can improve the
   process in the future.
   
This message (and future updates) is available on
http://www.cygnus.com/egcs/egcs-1.1.html

Re: egcs-1.1 release schedule

[Gerald Pfeifer]

On Wed, 17 Jun 1998, Jeffrey A Law wrote:
> This page is meant to provide information about the current schedule
> for egcs-1.1, the testing/release criteria for egcs-1.1, new features
> to be found in egcs-1.1, etc.

Jeff,

I tripped over that new page before receiving your mail announcement and
-- while for most of us on the mailing lists that is quite immediate --
I guess the "I" is quite confusing for those not closely following the
project.

(Specifically, there is no mention on the page who that "I" really is.)

Perhaps you could an <ADDRESS> at the end of the page or replace the "I"
by "We"?

Hope this helps,
Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: egcs-1.1 release schedule

[Jeffrey A Law]

  In message <Pine.GSO.3.96.980619151159.28850B-100000@markab.dbai.tuwien.ac.atyou write:
  > On Wed, 17 Jun 1998, Jeffrey A Law wrote:
  > I tripped over that new page before receiving your mail announcement and
  > -- while for most of us on the mailing lists that is quite immediate --
  > I guess the "I" is quite confusing for those not closely following the
  > project.
Good point.  I have an overly informal writing style.  I tried to
clean up the worst of the problems.

Further suggestions/patches are certainly welcome :-)

jeff

Re: egcs-1.1 release schedule

[Dave Love]

_Please_ include some means of allowing Fortran (at least) to get
stack-allocated doubles double-aligned on x86 (modulo libc).  (I hope
I haven't missed this going in at some stage!)  The one-line patch for
STACK_BOUNDARY used by g77 0.5.22 is good enough.

Re: egcs-1.1 release schedule

[Craig Burley]

>_Please_ include some means of allowing Fortran (at least) to get
>stack-allocated doubles double-aligned on x86 (modulo libc).  (I hope
>I haven't missed this going in at some stage!)  The one-line patch for
>STACK_BOUNDARY used by g77 0.5.22 is good enough.

I agree this is important to fix, but ideally fix right.  I'll look
into this again when a more recent snapshot appears, but my experiments
this past week didn't revealed any easy wins, though I don't recall
trying the STACK_BOUNDARY fix.

(By "fix right" I mean get 64-bit alignment for doubles as long as
that won't break any ABIs.  I don't mind special-casing some of this
in g77, but imagine that's not the hard part.  Basically all local
and static VAR_DECLs should be 64-bit aligned when they're DFmode,
but should remain 32-bit aligned when they're FIELD_DECLs and in
the TYPE_DECL for the type as seen elsewhere, so g77 gets its common
block and equivalence alignments right.)

I've put together a Fortran program to report on these issues,
but need to do a bit more work on it first before sending it along.

        tq vm, (burley)

Re: egcs-1.1 release schedule

[Jeffrey A Law]

  In message < rzqaf79nru7.fsf@djlvig.dl.ac.uk >you write:
  > _Please_ include some means of allowing Fortran (at least) to get
  > stack-allocated doubles double-aligned on x86 (modulo libc).  (I hope
  > I haven't missed this going in at some stage!)  The one-line patch for
  > STACK_BOUNDARY used by g77 0.5.22 is good enough.
I'm still waiting on some kind of solution that doesn't totally break
the ABI.

To do this "right" you have to:

	* Make sure gcc always allocates stack in multiples of 8 bytes,
	  adding dummy outgoing args as necessary to keep the stack
	  properly aligned at call points.

	  You can't do this with STACK_BOUNDARY since that says we
	  will 100% always have a properly aligned stack, which can
	  never be true since we might be linking in code from
	  another compiler which didn't keep the stack suitably
	  aligned.

	  If the stack gets mis-aligned relative to STACK_BOUNDARY
	  combine could end up removing a seemingly useless
	  stack operation/address calculation.

	  The idea is to make sure the stack is 8 byte aligned in the
	  common cases, but not absolutely rely on it for correct code
	  generation.


	* Second, assuming that gcc always keeps the pointer aligned
	  for itself, then arrange for doubles to end up 8 byte
	  aligned relative to the stack pointer.

	  If the stack gets mis-aligned due to an old module, then
	  our doubles won't be aligned correctly, but the vast majority
	  of the time they will be suitably aligned.

	  I don't think there's any mechanism to do this when the
	  desired alignment is less than STACK_BOUNDARY.  I fact
	  I know that to be the case since I worked on a similar
	  problem recently.

	* The ABI is still going to mandate that some doubles in
	  argument lists are going to be mis-aligned.  We'd have
	  to arrange to copy them from the arglist into a suitable
	  stack slot.  This may be more trouble than its worth.



Note that some non-ABI breaking changes to align doubles and other
values have gone into the x86 compiler.  In particular we should be
properly aligning all data in the static store.

jeff

Re: egcs-1.1 release schedule

[David S. Miller]

   Date: Sun, 21 Jun 1998 22:31:31 -0600
   From: Jeffrey A Law <law@cygnus.com>

	   * The ABI is still going to mandate that some doubles in
	     argument lists are going to be mis-aligned.  We'd have
	     to arrange to copy them from the arglist into a suitable
	     stack slot.  This may be more trouble than its worth.

And there are still going to be issues with equivalence statements.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: egcs-1.1 release schedule

[Dave Love]

>>>>> "David" == David S Miller <davem@dm.cobaltmicro.com> writes:

 David> And there are still going to be issues with equivalence statements.

I'm not sure specifically about equivalence with g77, but Fortran
which depends on storage association which forces double precision
variables to be misaligned is inherently non-portable (even if
standard-conforming).  For instance, g77 on SPARC (like other
compilers and other systems) pads common blocks if necessary, the same
as you get with -malign-double on x86; the canonical 20-year-old code
breaks.  Compilers do warn you, though many users choose to disbelieve
them...

Re: egcs-1.1 release schedule

[Toon Moene]

[ Welcome to the world of the 32-bit wonders of incongruence ]

David "Sparc" Miller wrote:

>     Date: Sun, 21 Jun 1998 22:31:31 -0600 From: Jeffrey
>     A Law <law@cygnus.com>

>  	   * The ABI is still going to mandate that some
>  	   doubles in
>  	     argument lists are going to be mis-aligned.
>  	     We'd have to arrange to copy them from the
>  	     arglist into a suitable stack slot.  This
>  	     may be more trouble than its worth.

>  And there are still going to be issues with equivalence
>  statements.

Sure.  But folks doing that should *know* they're invoking  
suboptimal behaviour.

OTOH, this way we could teach them ;-)

Cheers,
Toon.

PS: I agree with Jeff (even I don't know all the details - but I  
love to have them to get my little brother finish his PhD thesis in  
time :-) that the general problem simply is too hard (just consider  
an odd number of arguments-passed-by-reference).

Re: egcs-1.1 release schedule

[Jeffrey A Law]

  In message < 9806222039.AA04066@moene.indiv.nluug.nl >you write:
  > PS: I agree with Jeff (even I don't know all the details
Quick lesson then :-)  Ignore if you're not really interested in
the guts of why increasing STACK_BOUNDARY is a bad idea.

GCC assumes that the stack pointer must always be a multiple of
STACK_BOUNDARY.  And it even has optimizations which use that info.

combine will actually notice cases where the masking off of low bits
should be unnecessary due to the value of STACK_BOUNDARY.  ie if
STACK_BOUNDARY is 64, then ((sp + x) & 0xfffffffc)) can be resolved
to just (sp + x) (assuming X is a multiple of STACK_BOUNDARY).

This optimization will generate code which does not work if somehow
we get into a function where the stack is improperly aligned.  The
canonical example would be a callback from libc like the comparison
routine for qsort.


jeff

ix86 double alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

>   Date: Sun, 21 Jun 1998 22:31:31 -0600
>   From: Jeffrey A Law <law@cygnus.com>
>
>	   * The ABI is still going to mandate that some doubles in
>	     argument lists are going to be mis-aligned.  We'd have
>	     to arrange to copy them from the arglist into a suitable
>	     stack slot.  This may be more trouble than its worth.
>
>And there are still going to be issues with equivalence statements.

Well, I'm willing to not try to do any special aligning for
EQUIVALENCE and COMMON for now.  If we can just get 64-bit
alignment for stack-allocated VAR_DECLs -- which generally
won't include EQUIVALENCE (and certainly not COMMON) -- we'll
have made a *huge* improvement in g77 performance, especially
its *repeatability* of performance measurements.

(Without this improvement, egcs 1.1 will often appear *substantially*
worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of
widely used Fortran code, assuming users are using -malign-double.)

I hope to have a fairly thorough sample program put together soon
(tomorrow?) to illustrate this, but the simple cases we want
to align for now are like

	subroutine x
	double precision a
	...
	end

and:

	subroutine y(n)
	double precision a(n)
	...
	end

The latter uses automatic arrays (which gcc and g77 support), it'd
be great to get those 64-bit aligned as well.  The former is the
most important thing we *aren't* aligning, currently, even with
`-malign-double'.  (It should be aligned especially if `a' is an
array, of course.)

A case we can't 64-bit align is:

	real r(2)
	double precision d1, d2
	equivalence (r(1),d1)
	equivalence (r(2),d2)

Regardless of whether this is stack, static, or even part of a common
block, we can't 64-bit align both d1 and d2.  (Well, not without
an option to completely change the way we implement Fortran; I wonder
if Sun does that to support weird-but-conforming code on SPARCs,
such as the above.)

What we *can* do is *implement* the above, perhaps warning about
the suboptimal alignment.  That is, there's no reason we can't
go ahead and 32-bit align d1 and d2, so one of them is not
64-bit aligned.  The programmer asked for it, after all!

What we can also 64-bit align is this:

	real r(2)
	double precision d
	equivalence (r(2),d)

We can do that because we can see that there are no actual *conflicts*
of alignment.  We can implement this by either inserting a dummy
unused 32-bit variable before r(1) and aligning *that* to a 64-bit
boundary (stack or static, doesn't matter), or, if we have a
smart-enough back end (or linker, for static memory I guess), simply
use a directive that means "align to a 64-bit boundary on bit 32".

But it's not *important* to 64-bit align the above EQUIVALENCE case,
certainly not for egcs 1.1.

And what we also need to continue to support is stuff like

	real r1, r2
	real s(6)
	double precision d1, d2
	common r1, d1, r2, d2
	equivalence (r1,s)

which requires that s(1) overlays r1, s(2) and s(3) overlay d1, s(4)
overlays r2, and s(5) and s(6) overlays d2.

Again, we can do this by seeing that there are no "hard" conflicts
(at the machine or ABI level), and punting (and warning?) over the
fact that the "soft" conflicts (the ideal 64-bit alignment of
double for performance reasons) prevent "ideal" alignment.  Again,
"so what", the programmer has specified no 64-bit alignment, so
we don't give it to him in cases like that -- but we can still
compile correct, and fairly fast, ABI-compatible, code.

Note that I suggested the gcc architecture (machine descriptions,
etc.) be modified to include a more fine-grained expression of
alignment requirements.  E.g. distinguishing hardware requirements
(even instruction requirements, such as `ld' vs. `ldd' on SPARCv8)
from ABI requirements from ideal performance settings.  But this
suggestion was turned down at the time -- some seven years ago!

Maybe it's time we finally got this all "right", and I'm sure
willing to help.  But I think we can only manage to get a bit of
it "right" to improve x86 performance for egcs 1.1.

        tq vm, (burley)

Re: ix86 double alignment (was Re: egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 199806221829.OAA07477@melange.gnu.org >you write:
  > Well, I'm willing to not try to do any special aligning for
  > EQUIVALENCE and COMMON for now.  If we can just get 64-bit
  > alignment for stack-allocated VAR_DECLs -- which generally
  > won't include EQUIVALENCE (and certainly not COMMON) -- we'll
  > have made a *huge* improvement in g77 performance, especially
  > its *repeatability* of performance measurements.
Yup.  But considering the release schedule, I'd be happy if we could
just get the stack aligned properly without breaking the ABI, then
iterate to getting automatic variables aligned relative to the stack.

If we can get more done before the release, then great, but I wouldn't
want to hold things up on this issue if we can avoid it.

  > (Without this improvement, egcs 1.1 will often appear *substantially*
  > worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of
  > widely used Fortran code, assuming users are using -malign-double.)
Well, we still have -malign-double as an option for the x86 port, so
if they use it they presumably would see comparable performance, right?

Actually, I'd expect generally better performance because we do  handle 
alignments for static store items in a reasonable manner, which is a
significant improvement by itself).

  > Note that I suggested the gcc architecture (machine descriptions,
  > etc.) be modified to include a more fine-grained expression of
  > alignment requirements.  E.g. distinguishing hardware requirements
  > (even instruction requirements, such as `ld' vs. `ldd' on SPARCv8)
  > from ABI requirements from ideal performance settings.  But this
  > suggestion was turned down at the time -- some seven years ago!
Sigh.  Yea, it really seems like something we should have -- then
again, there's been little gcc emphasis on the x86 in the past and
it's the most likely benefactor of such stuff.

jeff

Re: ix86 double alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

[Need to study your later email with more technical issues more
carefully next, but here are some quick points.]

>  In message < 199806221829.OAA07477@melange.gnu.org >you write:
>  > Well, I'm willing to not try to do any special aligning for
>  > EQUIVALENCE and COMMON for now.  If we can just get 64-bit
>  > alignment for stack-allocated VAR_DECLs -- which generally
>  > won't include EQUIVALENCE (and certainly not COMMON) -- we'll
>  > have made a *huge* improvement in g77 performance, especially
>  > its *repeatability* of performance measurements.
>Yup.  But considering the release schedule, I'd be happy if we could
>just get the stack aligned properly without breaking the ABI, then
>iterate to getting automatic variables aligned relative to the stack.

I'd say getting the stack aligned properly without breaking the ABI
and *also* getting VAR_DECLs that are type `double' aligned within
those frames (whether arrays or scalars) is not only the most
important combination, but solves ~95% of the problems the g77
user community sees.

At least getting this to work when -malign-double is specified
would be kind of a "minimum" for making egcs 1.1 not noticably
much worse than g77 0.5.21 and 0.5.22 were.

>If we can get more done before the release, then great, but I wouldn't
>want to hold things up on this issue if we can avoid it.

I, hesitantly, agree.  Dave rightly points out that he and others
have been yelling about this for, well, it seems like years now.
I still have email from him (weeks ago) asking me to make a more
noticable push for this on the egcs list, and am now sorry I didn't
take his advice sooner.  I can only plead insanity, I guess it's
all those soccer balls I hit with my head playing for Scotland that
makes my brain mushy (just kidding, that's another Craig Burley ;-).

>  > (Without this improvement, egcs 1.1 will often appear *substantially*
>  > worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of
>  > widely used Fortran code, assuming users are using -malign-double.)
>Well, we still have -malign-double as an option for the x86 port, so
>if they use it they presumably would see comparable performance, right?

No.  I haven't yet finished up my totally-over-engineered diagnostic
program to expose all this, but the preliminary results are:

g77 0.5.21, 0.5.22:

  -  Without -malign-double, basically no doubles get aligned properly,
     with the exception of doubles that can be lazily aligned in COMMON
     (without conflicts; and I'm not quite sure why this is, maybe my
     program isn't working quite right, it could easily be an accident
     that these appear to be aligned, the sort of accident the new
     version of my program should make much less likely).

  -  With -malign-double, stack-based doubles still not aligned
     properly, but static/COMMON ones are (even if it breaks the
     COMMON ABI).

  -  With -malign-double -O, all doubles are aligned properly.  This is
     surprising; I didn't realize one needed -O to get this.  (And, yes,
     this breaks the COMMON ABI, etc.)

g77 0.5.23, egcs 1.0.3:

  -  Without -malign-double, no doubles get aligned properly.

  -  With -malign-double, static and automatic doubles get aligned,
     but not stack.  (Automatic are stack-based with dynamic size.)
     -O makes no difference.

egcs 19980615:

  -  Without -malign-double, only static doubles (and non-conflicting
     COMMON doubles) get aligned properly, the rest don't.

  -  With -malign-double, same as g77 0.5.23 and egcs 1.0.3.

So, the one huge improvement we should try to make for 1.1 is, IMO,
to achieve this:

  -  Without -malign-double, static, stack, and automatic doubles
     get aligned properly, but not if they're in EQUIVALENCE or
     COMMON blocks.  (Basically, any VAR_DECL the back end sees.)

  -  With -malign-double, same as g77 0.5.21 and 0.5.22 when -O is
     specified, except -O wouldn't be needed here.

The ideal situation would be to align all doubles that aren't
involved in ABI issues, but I think just doing the non-aggregate
ones handles ~95% of the important performance cases (as I've said,
and that's a *real* seat-of-the-pants guess).

Then, the only reason to use -malign-double is when the user knows
ABI issues are consistent across all pertinent modules (e.g. they're
all compiled with -malign-double) and the last ounce of performance
is needed.

>Actually, I'd expect generally better performance because we do  handle 
>alignments for static store items in a reasonable manner, which is a
>significant improvement by itself).

Right, which makes egcs *default* to better performance than the *default*
for 0.5.22, but to *worse* performance than 0.5.22 with -malign-double,
*even if -malign-double is used for egcs*.

The reason is that egcs nor gcc 2.8 will align stack-based doubles
(except automatics, i.e. dynamically-sized stack doubles).

So that's the main performance "regression" we currently have, which
means that at least getting -malign-double to align all doubles,
including stack-based ones, would seem to be worth making a
"required" item for egcs 1.1.

But I still would prefer it if we wouldn't effectively persuade most
users to risk using -malign-double just to get stack-based doubles
aligned for reasonable performance, and the way to do that is to make
alignment of stack-based (and automatic) doubles the default, again,
as long as the ABI isn't broken.

So not needing to use -malign-double to align stack-based doubles would
be a *huge* win, making egcs 1.1 *obviously* better than g77 0.5.21,
0.5.22, or 0.5.23 for most g77 users on x86.  That's because lots of
g77 users probably benchmark without reading up on (or feeling safe about
using) -malign-double.

>  > Note that I suggested the gcc architecture (machine descriptions,
>  > etc.) be modified to include a more fine-grained expression of
>  > alignment requirements.  E.g. distinguishing hardware requirements
>  > (even instruction requirements, such as `ld' vs. `ldd' on SPARCv8)
>  > from ABI requirements from ideal performance settings.  But this
>  > suggestion was turned down at the time -- some seven years ago!
>Sigh.  Yea, it really seems like something we should have -- then
>again, there's been little gcc emphasis on the x86 in the past and
>it's the most likely benefactor of such stuff.

When I asked for it, I thought it would have helped with the SPARC
system I was working on at the time.  Though, I might have been
wrong.  The x86 surely seems to have the most variety of alignment
flavors I've ever seen for any given type: e.g. `double' alone has
at least three alignments, 1 byte (minimum hardware alignment),
4 bytes (ABI alignment), and 8 bytes (ideal performance alignment)!

If you really want to see how sick I am about this "let's architect
the thing right so programmers have distinct things to specify,
instead of one-size-fits-all straitjackets", take a look at the
(now-ancient) g77 internals in this area.  E.g. egcs/gcc/f/target.h.

You'll find it not only tracks the alignment for each type, but
the "modulo".  That is, g77 can be taught (if given a suitable
back end ;-) that a given type is to be aligned such that it begins
on byte M of an N-byte-aligned block.  gcc and other tools
are architected to always align on byte 0 of an N-byte-aligned
block, but before I had worked on g77, I had some awareness of
the possibility of, e.g., a 10-byte type whose *last* 8 bytes
had to be 8-byte aligned, so the object as a whole would have
to be aligned to byte 6 of an 8-byte block.

Of course, this proved useful when cutting the code to handle
oddly-alignable aggregates, though never yet for fundamental
types.  Specifically, aligning an EQUIVALENCE block such that
REAL R must be immediately followed by DOUBLE PRECISION D fits
neatly into this scheme.  E.g. "EQUIVALENCE (R,S(1)), (D,S(2))"
is something g77 can and does handle by intuiting that the
entire EQUIVALENCE block must be aligned to byte 4 of an 8-byte-
aligned block (assuming compiling for a SPARC, or with -malign-double
on an x86, or any machine with 8-byte-aligned doubles and 4-byte
long floats).  That means g77 can also handle "COMMON C, D",
where C is CHARACTER*1 and D is DOUBLE PRECISION, though it warns
that it has to insert pre-padding (of 7 bytes, usually) between
the linker's idea of where the common block starts and where
it actually starts (where C starts).  (The warning is in case
the same common area is declared with a different type layout,
resulting in a different pre-padding being used, e.g. none.)

And, by "sick" I mean I designed it this way back around 1988,
before seeing barely a shred of GNU code!  My usual philosophy
is: if I can't think of *one* clear-cut meaning for a value,
that usually means I shouldn't be using just *one* value (or
constant or macro or whatever).  gcc's DECL_ALIGN field, and
the relevant muck, violates that principle in spades, of course.

        tq vm, (burley)

Re: ix86 double alignment (was Re: egcs-1.1 release schedule)

[David S. Miller]

   Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT)
   From: Craig Burley <burley@gnu.org>

   A case we can't 64-bit align is:

	   real r(2)
	   double precision d1, d2
	   equivalence (r(1),d1)
	   equivalence (r(2),d2)

   Regardless of whether this is stack, static, or even part of a common
   block, we can't 64-bit align both d1 and d2.  (Well, not without
   an option to completely change the way we implement Fortran; I wonder
   if Sun does that to support weird-but-conforming code on SPARCs,
   such as the above.)

I can give some insight to this on certain cases on the Sparc.

The UltraSparc has specific high performance trap vectors dedicated to
handling the case where a double float load is done to an address
which is not aligned correctly.  The UltraSparc users manual suggests
that if the compiler can determine that the likelyhood of bad
alignment is 50/50 or less, if should output the double float loads.

However there is an OS level side issue to this.  Sparc is rather
strict about unaligned loads by default on most systems I know about.
However, most systems provide some way to tell the OS to "allow
unaligned memory accesses, and fix them up for the program".

This would need some investigation before such a scheme is enable in
egcs, so I'd say defer thinking about it until after the 1.1 release
happens.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: ix86 double alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

>   Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT)
>   From: Craig Burley <burley@gnu.org>
>
>   A case we can't 64-bit align is:
>
>	   real r(2)
>	   double precision d1, d2
>	   equivalence (r(1),d1)
>	   equivalence (r(2),d2)
>
>   Regardless of whether this is stack, static, or even part of a common
>   block, we can't 64-bit align both d1 and d2.  (Well, not without
>   an option to completely change the way we implement Fortran; I wonder
>   if Sun does that to support weird-but-conforming code on SPARCs,
>   such as the above.)
>
>I can give some insight to this on certain cases on the Sparc.
[...]
>This would need some investigation before such a scheme is enable in
>egcs, so I'd say defer thinking about it until after the 1.1 release
>happens.

Yes, let me make this clear.  I brought up SPARC only to illustrate
my awareness that this issue is a general one for all gcc targets
in theory at least and in practice for at least two targets (x86
and SPARC), probably others as well (`sh', whatever that is, already
seems to have its own work done in this area...can someone send me
a `sh' machine please? ;-).

I am *not* recommending any of the changes we're discussing actually
applying to code generation on SPARCs at all, at least not in the
short term (1.1).

In particular, while this align-doubles-properly-or-performance-will-
really-really-suck issue has *frequently* come to my attention for
the x86 architecture, basically *never* can I recall anyone complaining
about not being able to compile real Fortran code using standard-
conforming (but, as Dave Love rightly points out, nonportable due
to machines like SPARC) constructs like the one I illustrated above.

My impression: SPARC users, even of g77, have already been "trained"
by Sun to not expect some weird force-bad-alignment code to work
on that architecture.  So they don't complain to us, either.

(And, yes, there is a way to "fix" this problem: provide a command-line
option that the compiler handles by making all ints and floats 64-bit,
all doubles 128-bit, and adjusting the run-time libraries and so on
accordingly.  Not that the *precision* goes up, just that the Fortran
INTEGER, LOGICAL, and REAL types suddenly have 32 useful bits and 32
junk bits in 64 bits of space, DOUBLE PRECISION and COMPLEX have 64+64
bits, and so on.  With only a relatively small amount of hair, this
makes full Fortran standards conformance possible, and makes most
data needs expand by a factor of two with no increase in precision or
range and a general decrease in run-time performance.  A great way to
discourage people from insisting that their old codes run without
modification.  Can't recall what I've been told, if anything, about
whether Sun provides such an option in any of its Fortran compilers.
Perhaps just the *threat* of "solving" this problem this way is all
that has ever been needed, like the cold-war MAD policy regarding use
of nuclear armaments.  But I can't recall anybody asking for this option
in g77, though I might be so quick to say "fine, send us lots of money"
that I forgot all about any such requests.  :)

So, the tempting thing some people have thought is "well, SPARC
users are used to a `broken' Fortran implementation for years,
being happier with the performance gains; why not foist this on
Intel users?"  Unfortunately, the existing user base, library
code, and iron base makes this worth solving for only newer
instances of those, but not worth breaking for the older ones.

The upshot: when [56]86 users aren't using "dangerous" options like
`-malign-double', we still need to do 64-bit alignment wherever
possible but without breaking compatibility to get decent
performance.

BTW, as much as I want this problem "cured" for [56]86 users in egcs
1.1, I *really* hope the libm performance problems on Alpha are
generally fixed by the time such a version of egcs is released,
because it disturbs me a bit that we might make [56]86 appear
even better price/performance-wise than Alphas than they have in
the past, especially since we *know* we can speed up the Alphas
more than the [56]86 just by fixing just the software.  (And,
intentionally, I've kept the Alpha architecture manual within
reach, but not the ix86 one so, for over a year now.  :)

        tq vm, (burley)

Re: egcs-1.1 release schedule

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:

 Jeff> 	  You can't do this with STACK_BOUNDARY since that says we
 Jeff> 	  will 100% always have a properly aligned stack, 

I guess we've just been lucky with the previous g77.  (BTW, perhaps
the documentation of the alignment macros could be reviewed?)  I
thought there was an agreed patch available to do things right, too,
which presumably I misunderstod about.

 Jeff> 	* The ABI is still going to mandate that some doubles in
 Jeff> 	  argument lists are going to be mis-aligned.

Fortunately that isn't much of an issue for Fortran :-).

 Jeff> Note that some non-ABI breaking changes to align doubles and
 Jeff> other values have gone into the x86 compiler.  In particular we
 Jeff> should be properly aligning all data in the static store.

Does that make -malign-double redundant?

[In case people don't know, the point of this is that mis-aligned
doubles on PIIs (with which some people want to do supercomputing) can
apparently cost a factor of 2-3 in speed for real numerical code.]

Re: egcs-1.1 release schedule

[Jeffrey A Law]

  In message < rzqiultp90m.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:
  > 
  >  Jeff> 	  You can't do this with STACK_BOUNDARY since that says we
  >  Jeff> 	  will 100% always have a properly aligned stack, 
  > 
  > I guess we've just been lucky with the previous g77.  (BTW, perhaps
  > the documentation of the alignment macros could be reviewed?)  I
  > thought there was an agreed patch available to do things right, too,
  > which presumably I misunderstod about.
I went back and reviewed Marc's patch.  It had ABI issues to contend
with.  It was my mistake to say it didn't have ABI isssues a few months
ago.

Well, the optimizations which eliminate useless masks were in older
versions of gcc, but they were much less aggressive.  Kenner spent
quite some time making them more aggressive (since I think it really
helps the alpha).

  >  Jeff> 	* The ABI is still going to mandate that some doubles in
  >  Jeff> 	  argument lists are going to be mis-aligned.
  > 
  > Fortunately that isn't much of an issue for Fortran :-).
True, but it is an issue for  C :-)

  >  Jeff> Note that some non-ABI breaking changes to align doubles and
  >  Jeff> other values have gone into the x86 compiler.  In particular we
  >  Jeff> should be properly aligning all data in the static store.
  > 
  > Does that make -malign-double redundant?
I don't think so.  I think -malign-double also effects stuff like alignment
of doubles in structures and the like.

jeff

Re: egcs-1.1 release schedule

[H.J. Lu]

> 
> 
>   In message < rzqiultp90m.fsf@djlvig.dl.ac.uk >you write:
>   > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:
>   > 
>   >  Jeff> 	  You can't do this with STACK_BOUNDARY since that says we
>   >  Jeff> 	  will 100% always have a properly aligned stack, 
>   > 
>   > I guess we've just been lucky with the previous g77.  (BTW, perhaps
>   > the documentation of the alignment macros could be reviewed?)  I
>   > thought there was an agreed patch available to do things right, too,
>   > which presumably I misunderstod about.
> I went back and reviewed Marc's patch.  It had ABI issues to contend
> with.  It was my mistake to say it didn't have ABI isssues a few months
> ago.
> 

I believe Marc's patch doesn't change ABI by default. But you can
turn on some optimizations by hand which will change ABI. But if
the user is warned, it shouldn't be a problem. Besides, he/she
recompile libraries with the new ABI if Linux/xxxxBSD is used.


H.J.

Re: x86 double alignment (was egcs-1.1 release schedule)

[Marc Lehmann]

On Tue, Jun 23, 1998 at 07:47:24AM -0700, H.J. Lu wrote:
> 
> I believe Marc's patch doesn't change ABI by default. But you can

Sorry for me first sending the patch and then reading the list ;) I actually
have a backlog of >600 messages on egcs and just found this thread when
Bernd asked me about the double-alignment patch.

> turn on some optimizations by hand which will change ABI. But if

The original patch turned on -mstack-align-double, which I thought is safe,
but it isn't. I got a report from a windows user that it breaks most windows
function semantics, as these functions deallocate the stack themselves. In
this case, -mstack-align-double will break the program.

If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
(like qsort or __libc_start) with it, so the problem of combine breaking code
is solved, so we can either

- document that -mno-stack-align-double should be used when linking against third-party-libs
- not making it on by default.

there are also speed issues, i.e. in integer-only programs, -mstack-align-double
slows down code (a bit), so it should probably be disabled anyway.

-marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY
is effectively ignored on calls, but not within the called function), and
breaks the abi, and was thus always optional. (it would align doubles in the
argument area, this _severely_ breaks the abi, of course)

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

Re: x86 double alignment (was egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 19980624192457.45730@cerebro.laendle >you write:
  > If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
  > (like qsort or __libc_start) with it, so the problem of combine breaking code
  > is solved, so we can either
Actually, if I remember the problem you described correctly, combine was
doing the right thing.

jeff

Re: x86 double alignment (was egcs-1.1 release schedule)

[Marc Lehmann]

On Thu, Jun 25, 1998 at 01:21:57AM -0600, Jeffrey A Law wrote:
> 
> 
>   In message < 19980624192457.45730@cerebro.laendle >you write:
>   > If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
>   > (like qsort or __libc_start) with it, so the problem of combine breaking code
>   > is solved, so we can either
> Actually, if I remember the problem you described correctly, combine was
> doing the right thing.

Combine is doing the right thing, yes. It does an unsafe optimization,
but the machine description clearly says it can.

I meant if egcs _had_ this switch, the functions using callback-functions
could be compiled with it, so code that is compiled with
-mstack-align-double is safe, even if called from libc.

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

Re: x86 double alignment (was egcs-1.1 release schedule)

[PÃ¥l-Kristian Engstad]

Hi!

Although double-alignment on stack variables would be a bad idea (for
most situations), it would make perfect sense in certain situations.

For instance, leaf functions could certainly benefit from being stack
aligned. Also, functions which only call leaf functions that are stack
aligned can use stack alignment.

Would it be possible to do something like that?

Also, if we are in a situation where we can not stack-align, the 
default behaviour for often used variables would be to make a copy
onto the stack (double-aligned), and use this instead (unless it is
only used as a register).

PKE.

Re: x86 double alignment (was egcs-1.1 release schedule)

[Marc Lehmann]

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

On Thu, Jun 25, 1998 at 11:13:45AM -0700, PÃ¥l-Kristian Engstad wrote:
> Hi!
> 
> Although double-alignment on stack variables would be a bad idea (for
> most situations), it would make perfect sense in certain situations.
> 
> For instance, leaf functions could certainly benefit from being stack
> aligned. Also, functions which only call leaf functions that are stack
> aligned can use stack alignment.

I don't see why this is only beneficial for leaf functions? Any functions
using doubles heavily benefits from this optimization. Unfortunately,
its almost impossible to enforce stack alignment only for leaf functions..


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

Re: x86 double alignment (was egcs-1.1 release schedule)

[Craig Burley]

>The original patch turned on -mstack-align-double, which I thought is safe,
>but it isn't. I got a report from a windows user that it breaks most windows
>function semantics, as these functions deallocate the stack themselves. In
>this case, -mstack-align-double will break the program.

Wait, how can these functions deallocate the stack themselves when
the *caller* also is deallocating the stack, as is normally the
case for x86-ABI code?  Aren't these functions essentially violating
the ABI in a way the compiler producing code that calls them *must*
know about?

What I haven't looked into yet is whether subtracting 4 from %esp
before pushing args might upset some varargs/stdargs implementation
on the callee side (that the caller doesn't know about), i.e. if
that can even happen.

>If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
>(like qsort or __libc_start) with it, so the problem of combine breaking code
>is solved, so we can either
>
>- document that -mno-stack-align-double should be used when linking against third-party-libs
>- not making it on by default.

If it's not on by default, it's of only limited benefit, though that'd
still take care of lots of Fortran users who are willing to learn about
and use an option like -mstack-align-double.

My feeling is that if -mstack-align-double doesn't break the ABI,
then make it the default.  Any bugs resulting from this are thus
likely to be because *other* code breaks the ABI.  Our compiler
should be "told" about those codes explicitly anyway, via attributes
or something.

>there are also speed issues, i.e. in integer-only programs, -mstack-align-double
>slows down code (a bit), so it should probably be disabled anyway.

I was thinking earlier this week that, for example, the Linux kernel
perhaps would run faster if -mno-stack-align-double was specified
for compiling it.

But, the problem is that if we don't make -mstack-align-double the
default, lots of code that uses `double' will not get proper
alignment and will continue have *big* performance degradation.

>-marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY
>is effectively ignored on calls, but not within the called function), and
>breaks the abi, and was thus always optional. (it would align doubles in the
>argument area, this _severely_ breaks the abi, of course)

Yup, we pretty much ended up concluding this (I should say, I finally
understood what others were saying).

        tq vm, (burley)

Re: x86 double alignment (was egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 199806251615.MAA12029@melange.gnu.org >you write:

  > What I haven't looked into yet is whether subtracting 4 from %esp
  > before pushing args might upset some varargs/stdargs implementation
  > on the callee side (that the caller doesn't know about), i.e. if
  > that can even happen.
I'm pretty sure it's safe.  Even for varargs/stdarg.  Basically think
of it as having an extra int argument at the end of the arglist
(remember we push back to front).  An extra argument never hurt anyone :-)

We do have to be careful and make sure we don't screw RETURN_POPS_ARGS 
support though.  I'd forgotten about that.  Though I do not think
that adds any significant complexity to the problem.


jeff

Re: x86 double alignment (was egcs-1.1 release schedule)

[Marc Lehmann]

On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote:
> >The original patch turned on -mstack-align-double, which I thought is safe,
> >but it isn't. I got a report from a windows user that it breaks most windows
> >function semantics, as these functions deallocate the stack themselves. In
> >this case, -mstack-align-double will break the program.
> 
> Wait, how can these functions deallocate the stack themselves when
> the *caller* also is deallocating the stack, as is normally the

it isn't: __attribute__((stdcall)).

> case for x86-ABI code?  Aren't these functions essentially violating
> the ABI in a way the compiler producing code that calls them *must*
> know about?

the problem is we can't change the windows kernel. its a third-party
product I'd really like to recompile ;)

> >- document that -mno-stack-align-double should be used when linking against third-party-libs
> >- not making it on by default.
> 
> If it's not on by default, it's of only limited benefit, though that'd
> still take care of lots of Fortran users who are willing to learn about
> and use an option like -mstack-align-double.

I had this on by default for half a year in pgcc (until I was told about
windows having problems). It isn't beneficial for integer programs, and
there are a great many of them around. I'm not happy with the idea
of punishing a whole class of functions.

If all third-party libraries (e.g. libc) were compiled with this switch (we
only need to have this on for functions using callbacks), we could leave the
choice up to the individual program.

> My feeling is that if -mstack-align-double doesn't break the ABI, then
> make it the default.  Any bugs resulting from this are thus likely to be
> because *other* code breaks the ABI.  Our compiler should be "told" about
> those codes explicitly anyway, via attributes or something.

these codes are already available, and already used (in windows, at least,
which means nothing too important to me, since code for that platform won't
be distrivuted in binary to other systems I believe).

The problem is mostly speed loss.

> But, the problem is that if we don't make -mstack-align-double the
> default, lots of code that uses `double' will not get proper
> alignment and will continue have *big* performance degradation.

Educate your users. I thought that way for a great long time, maybe I'm
used to tweaking switches, but thats _already_ the case with loop unrolling
or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most
programs use -O2 when -O3 is faster?

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

Re: x86 double alignment (was egcs-1.1 release schedule)

[Martin Kahlert]

Quoting Marc Lehmann (pcg@goof.com):
> On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote:
> > >The original patch turned on -mstack-align-double, which I thought is safe,
> > >but it isn't. I got a report from a windows user that it breaks most windows
> > >function semantics, as these functions deallocate the stack themselves. In
> > >this case, -mstack-align-double will break the program.
> > 
> > Wait, how can these functions deallocate the stack themselves when
> > the *caller* also is deallocating the stack, as is normally the
> 
> it isn't: __attribute__((stdcall)).
> 
> > case for x86-ABI code?  Aren't these functions essentially violating
> > the ABI in a way the compiler producing code that calls them *must*
> > know about?
> 
> the problem is we can't change the windows kernel. its a third-party
> product I'd really like to recompile ;)
> 

A small dummy question: Is it possible without big efford, 
to only align automatic (local) double vars 
and leave all function parameters untouched? So no ABI gets violatet.
Most time critical calculations aren't performed on stack doubles,
i would imagine.

Just a silly question.

Bye,
Martin.

-- 
What is the difference between Jurassic Park and Microsoft?
One is an over-rated high tech theme park based on prehistoric 
information and populated mostly by dinosaurs, 
the other is a Steven Spielberg movie.

Re: x86 double alignment (was egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 19980629141934.A18433@keksy.mchp.siemens.de >you write:
  > A small dummy question: Is it possible without big efford, 
  > to only align automatic (local) double vars 
  > and leave all function parameters untouched? So no ABI gets violatet.
  > Most time critical calculations aren't performed on stack doubles,
  > i would imagine.
That is the current goal.  "big effort" is a matter of interpretation :-)

jeff

Re: x86 double alignment (was egcs-1.1 release schedule)

[Craig Burley]

>A small dummy question: Is it possible without big efford, 
>to only align automatic (local) double vars 
>and leave all function parameters untouched? So no ABI gets violatet.
>Most time critical calculations aren't performed on stack doubles,
>i would imagine.

I think that's what we've been concensing on over the past week
already -- 1) get the outgoing stack pointer aligned, so the
callee gets an aligned stack frame of the caller had an aligned
incoming %esp; 2) get double vars aligned within the stack frame;
3) don't do anything different with double vars passed to a
called procedure, since otherwise we'd seriously break the ABI;
4) *maybe* use aligned, frame-based locations for *spills* of
incoming double var args (so instead of spilling by not writing
and just re-reading the original var from the arglist, spill
by writing to an aligned stack temp slot and reading from that;
which costs an extra write, but for lots of reads, gains from
having those reads aligned).

        tq vm, (burley)

Re: x86 double alignment (was egcs-1.1 release schedule)

[Craig Burley]

>On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote:
>> >The original patch turned on -mstack-align-double, which I thought is safe,
>> >but it isn't. I got a report from a windows user that it breaks most windows
>> >function semantics, as these functions deallocate the stack themselves. In
>> >this case, -mstack-align-double will break the program.
>> 
>> Wait, how can these functions deallocate the stack themselves when
>> the *caller* also is deallocating the stack, as is normally the
>
>it isn't: __attribute__((stdcall)).

So you are saying gcc knows when it calls a function that the function
will do the deallocating?  (I'm not sure I fully understand your
response, since you didn't explain it particularly carefully.  Is
that attribute on a function definition or declaration, for example?)

In that case, why isn't it simply a bug that -mstack-align-double isn't
handling that attribute correctly, and a (fairly) easily fixable bug
at that?

>> case for x86-ABI code?  Aren't these functions essentially violating
>> the ABI in a way the compiler producing code that calls them *must*
>> know about?
>
>the problem is we can't change the windows kernel. its a third-party
>product I'd really like to recompile ;)

I meant what apparently you said about attribute(stdcall) or
whatever -- that, if gcc compiles code that calls a non-ABI-
obeying function, it *must* be told about that.

In other words, there's really no reason -mstack-align-double should
have any problems vis-a-vis ABI conformance.  If it does, that's
just a bug that needs fixing.  E.g. for a function with the
attribute saying "this is a Windows function that breaks the ABI",
it simply doesn't attempt to aligning the outgoing stack frame, or,
upon returning, it pseudo-pops the pseudo-pushed 32-bit word.

>> >- document that -mno-stack-align-double should be used when linking against third-party-libs
>> >- not making it on by default.
>> 
>> If it's not on by default, it's of only limited benefit, though that'd
>> still take care of lots of Fortran users who are willing to learn about
>> and use an option like -mstack-align-double.
>
>I had this on by default for half a year in pgcc (until I was told about
>windows having problems). It isn't beneficial for integer programs, and
>there are a great many of them around. I'm not happy with the idea
>of punishing a whole class of functions.

Neither am I.  But how much does integer stuff slow down?  2% on
average?  5% max?  Compare that with double-precision speed-ups,
which I've been hearing are on the order of in the tens of
percents average, as much as 200 or 300%.  I still think it's a bit
of a tough call, even given that, but others might well disagree
and say it's a clear win for always doing alignment.  That's the
direction in which I lean as well.

>If all third-party libraries (e.g. libc) were compiled with this switch (we
>only need to have this on for functions using callbacks), we could leave the
>choice up to the individual program.

Ideally, we'd just leave it up to link-time optimizations, which are
(nearly) ideal for properly handling this sort of thing.  (Of course,
that assumes object files don't contain such nailed-down assembly
code.)  But that's a *huge* project, and in the meantime, we're
getting killed by compilers that do the right thing without needing
all sorts of special options, from what I hear.  (Can anyone confirm
this?)

>The problem is mostly speed loss.

How much?  Especially, how much *peak* loss?  IMO, if there are any
at-least-moderately-widely-used codes out there that'd suffer
more than a 5% slowdown, then this should be taken very seriously,
in terms of whether we want to impose that, by default, on users
of egcs 1.1.

>> But, the problem is that if we don't make -mstack-align-double the
>> default, lots of code that uses `double' will not get proper
>> alignment and will continue have *big* performance degradation.
>
>Educate your users. I thought that way for a great long time, maybe I'm
>used to tweaking switches, but thats _already_ the case with loop unrolling
>or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most
>programs use -O2 when -O3 is faster?

Gee, thanks.  We've spent a couple of years or so already trying
to teach them when and how to use -malign-double, and now you're
saying we should spend even more time and energy teaching them how
and when to use -mstack-align-double (though that's greatly eased
by it not breaking the ABI).

In the meantime, the "education" misses a huge part of the user
base no matter what we do, as we've learned (and expected anyway)
over the past several years.

Why not just educate *your* users that if they want that last 2 or 3%
of performance and they're using no double-precision data, and not
calling any procedures (e.g. user-supplied) that might, they should
use -mno-stack-align-double?

After all, who do you think is more likely to scrutinize the
documentation -- people who *really need* that last 2 or 3%,
or people who *might* notice (or not, and just explain away as
"slow") a 2x or 3x drop in performance compared to *other*
x86 compilers out there?  In particular, if they *don't* notice
a 2-3% slowdown, then they don't care; if they *do*, they'll
probably know to read the docs.  But users of gcc have hardly
ever seen even adequate double-precision performance (unless
they happened to use one or two now-obsolete versions of g77,
with the dangerous stack-alignment patch), so they are less
likely to think the compiler has "gotten" slower, more likely
to think it just "is" slow.

AFAIK, nobody has ever claimed g77 is "slow" compared to other
compilers because it produces code that is 2-3% slower than a
competitor.  But they often do when that drop is greater than 10%,
and too often without reading the docs to see how they might get
better performance.

Apparently that's because other vendors often make the "right"
choices about numerical performance (though it'd be worthwhile
to research just how some x86 Fortran vendors handle the
64-bit-alignment problem vis-a-vis "alien" code), so users of
those vendors' compilers don't have to study long lists of
possibly useful options to get remotely in the ballpark of
decent performance.

And apparently many users doing benchmarks consider that a
quality issue -- how good performance is using *vanilla*
options like -O, without having to read tons of docs (especially
in the case of gcc/g77, which, as portable products, have
tons of machine-specific optimization options).

Whereas, that seems to be what you're asking gcc/g77/g++/GNAT
users to do -- to get double-precision performance that's even
within 2x or 3x of performance (even with *moderate* optimization),
they have to learn about and compile with -mstack-align-double
throughout their program.  That's not even a portable option
(across machines gcc supports).

As far as why loop unrolling and other things are the way they are,
there's a variety of reasons.  One is that sometimes the code is
considered insufficiently tested to enable for the default
optimization level (-O1).  Another is that it can greatly inflate
some types of code and/or data structures.  Another is that it can
greatly increase the amount of time the compiler takes to compile
some types of code.  Another is that it can actually slow down certain
types of code, sometimes greatly, maybe even *most* types of code.

Without having info on how much slower integer codes really get,
I'm assuming the only pertinent reason that applies to making
-mstack-align-double the default is the first -- that the code
is insufficiently tested.

However, that's mitigated by the fact that this isn't an optimization
"pass" in the usual sense -- in fact, it's got to be used *widely* to
even begin to see any benefits from it, so if it isn't enabled
by default, IMO it probably won't get used by more than 1% of the
entire user base.  Hence, it won't be tested, and gcc will continue
to appear to be a poor performer.  (Most people who'd use it will
just use -malign-double to get "all" the performance, is my guess.)

In fact, without having certain important libraries compiled with
this option enabled by default, the *entire* exercise is pointless
for about 99% of the users who *would* see big performance
improvements if we made it the default.

That's why, IMO, -mstack-align-double should be the default *period*,
including for unoptimized code (-O0).

I'd love to see gcc taught to effectively avoid doing this stuff in
cases where it's clear no double-precision arithmetic is involved,
though.  E.g. leaf functions with no DP vars, and functions that
have no DP vars and call only leaf functions of that sort or of
their own sort.  That might restore much of the apparent lossage
from making -mstack-align-double the default.

Another approach is to make -mno-stack-align-double the default
and teach gcc to special-case any function *not* meeting the
above requirements (e.g. functions with DP vars, or that might
call those with them) by somehow forcibly aligning the incoming
stack frame (if local DP vars exist).  That'd require conditionally
moving the incoming args collectively by 4 bytes (if the frame
is unaligned), and dealing with the fallout of this (it might affect
profiling, exceptions, debugging, etc.).

But either of the above approaches is going to take quite a bit
more time, well beyond the 1.1 timeframe.

So the question for 1.1 is: assuming we *can* make -mstack-align-double
the default (and my quick tests of it didn't seem too promising,
but then I realized some of that might be due to the g77 bugs I
think I've finally found and fixed as of a couple of hours ago),
*should* we for 1.1?  Should we default to as much as 300% speedups
in double-precision code and as much as 2-5% (?) slowdowns in
non-DP code, or continue "straining" to get the last few percentages
points for non-DP code at the *huge* (and embarrassing) expense of
DP code?

        tq vm, (burley)

Re: x86 double alignment (was egcs-1.1 release schedule)

[Jeffrey A Law]

  > So the question for 1.1 is: assuming we *can* make -mstack-align-double
  > the default (and my quick tests of it didn't seem too promising,
  > but then I realized some of that might be due to the g77 bugs I
  > think I've finally found and fixed as of a couple of hours ago),
  > *should* we for 1.1?  Should we default to as much as 300% speedups
  > in double-precision code and as much as 2-5% (?) slowdowns in
  > non-DP code, or continue "straining" to get the last few percentages
  > points for non-DP code at the *huge* (and embarrassing) expense of
  > DP code?
I think we need to answer this question once we've got some code to
get the stack and VAR_DECLs aligned properly so that we can measure
the benefit on some code *and* measure the loss on integer code.

We all have gut feelings about what we're going to find, but it would
really be to our advantage to get some hard data.

jeff

gcc2 merge

[H.J. Lu]

There is a new gcc2 snapshot. Should we take a look to see if there
are any bug fixes?

H.J.

Re: gcc2 merge

[Jeffrey A Law]

  In message <m0yr2BR-000266C@ocean.lucon.org>you write:
  > There is a new gcc2 snapshot. Should we take a look to see if there
  > are any bug fixes?
I thought about just importing/merging it since it's only 2 weeks of low
volume changes.  Too bad it was made right after I had 90% of the
merge from 980609 done :( 

jeff

Re: x86 double alignment (was egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 19980628214914.40045@cerebro.laendle >you write:
  > I had this on by default for half a year in pgcc (until I was told about
  > windows having problems). It isn't beneficial for integer programs, and
  > there are a great many of them around. I'm not happy with the idea
  > of punishing a whole class of functions.
  > 
  > If all third-party libraries (e.g. libc) were compiled with this switch (we
  > only need to have this on for functions using callbacks), we could leave the
  > choice up to the individual program.
I'm not particularly happy with it either, but sometimes that's the
tradeoff we have to make.

What we have to do is quantify the integer slowdowns and the floating
point speedups and make a value decision about which is more important.

This is a common thing to have to do when optimizing code -- few things
are always going to be a win.  So you have to evaluate how often they
win vs how often they lose -- you do this both with benchmarks and 
instinct.

The other thing to do is look for cases where you can mitigate the
losses.  The example that has come up is leaf functions.

I must admit that I'm curious how much slowdown we're going to see
for integer code.  I'd expect it to be rather small, but I must admit
that I don't really know for sure.

  > Educate your users. I thought that way for a great long time, maybe I'm
  > used to tweaking switches, but thats _already_ the case with loop unrolling
  > or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most
  > programs use -O2 when -O3 is faster?
That's fine for a hacker community.  That doesn't work for a the larger
developer community.

Loop unrolling is very much a hit or miss proposition.  It's just as
likely to make things worse as it is to make them better.

-O3 can make code run slower, it can make the compiler run slower,
it makes debugging even harder.  It can also make things run faster,
it really depends on the code.

jeff

Re: egcs-1.1 release schedule

[Craig Burley]

> Jeff> Note that some non-ABI breaking changes to align doubles and
> Jeff> other values have gone into the x86 compiler.  In particular we
> Jeff> should be properly aligning all data in the static store.
>
>Does that make -malign-double redundant?

See my just-emailed long answer, but the short answer is "no".

With -malign-double, g77 0.5.23, egcs 1.0, and the 19980615 snapshot
align automatic and COMMON doubles.  Without it, they don't.  And,
without it, g77 0.5.23 and egcs 1.0 don't even align static doubles!

So the improvement in egcs 1.1-in-development is that -malign-double
is not needed to align the static doubles, but there's still the
automatic and, for okay-to-break-ABI cases, COMMON doubles to align,
not to mention all those stack-based doubles (IMO probably the most
important of the lot, but maybe you or others know better).

However, none of these newer g77's align stack-based doubles *regardless*
of -malign-double.  That, *at least*, should be fixed in egcs 1.1,
as it represents a serious regression even for performance-hungry
g77 users who use -malign-double against g77 0.5.21 and 0.5.22.
(Though with 0.5.2[12] they really have to use -O as well, though
of course they would be anyway.  I don't know why -O makes a
difference, offhand.)

        tq vm, (burley)

ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

>  In message < rzqaf79nru7.fsf@djlvig.dl.ac.uk >you write:
>  > _Please_ include some means of allowing Fortran (at least) to get
>  > stack-allocated doubles double-aligned on x86 (modulo libc).  (I hope
>  > I haven't missed this going in at some stage!)  The one-line patch for
>  > STACK_BOUNDARY used by g77 0.5.22 is good enough.
>I'm still waiting on some kind of solution that doesn't totally break
>the ABI.

I'm willing to do some serious work to make this happen for 1.1,
which assumes it can be done in the next couple of weeks, right?

>To do this "right" you have to:
>
>	* Make sure gcc always allocates stack in multiples of 8 bytes,
>	  adding dummy outgoing args as necessary to keep the stack
>	  properly aligned at call points.
>
>	  You can't do this with STACK_BOUNDARY since that says we
>	  will 100% always have a properly aligned stack, which can
>	  never be true since we might be linking in code from
>	  another compiler which didn't keep the stack suitably
>	  aligned.

For Fortran code, we can usually hand-wave that; this case would
only come up when the call tree has an *embedded* procedure
that doesn't maintain proper alignment, and since the big
computational problem with g77 performance is in code compiled
by g77, and such code is rarely called by C code, I don't think
this would represent a huge deficiency.

>	  If the stack gets mis-aligned relative to STACK_BOUNDARY
>	  combine could end up removing a seemingly useless
>	  stack operation/address calculation.

I don't understand this, but presumably I need to look into it
further.

>	  The idea is to make sure the stack is 8 byte aligned in the
>	  common cases, but not absolutely rely on it for correct code
>	  generation.

Absolutely.

>	* Second, assuming that gcc always keeps the pointer aligned
>	  for itself, then arrange for doubles to end up 8 byte
>	  aligned relative to the stack pointer.
>
>	  If the stack gets mis-aligned due to an old module, then
>	  our doubles won't be aligned correctly, but the vast majority
>	  of the time they will be suitably aligned.
>
>	  I don't think there's any mechanism to do this when the
>	  desired alignment is less than STACK_BOUNDARY.  I fact
>	  I know that to be the case since I worked on a similar
>	  problem recently.

Okay, that makes sense to me.  We want to hit a majority of cases
anyway.  We don't care (for now) about cases where users are
combining multiple languages in weird ways, for example.

>	* The ABI is still going to mandate that some doubles in
>	  argument lists are going to be mis-aligned.  We'd have
>	  to arrange to copy them from the arglist into a suitable
>	  stack slot.  This may be more trouble than its worth.

I'm not sure how this can ever happen in the x86 architecture?

Well, I mean, not when passing argument by reference, which is
generally how g77 works anyway.

>Note that some non-ABI breaking changes to align doubles and other
>values have gone into the x86 compiler.  In particular we should be
>properly aligning all data in the static store.

Right.  The Next Big Thing is to, by default, 64-bit-align any
stack-based VAR_DECLs.  Just doing that would be Great.

What I'd like to see, and think wouldn't be too hard, is a change
that'd leave TYPE_ALIGN for doubles at 32, so g77 would still
be able to produce COMMON and EQUIVALENCE blocks ("aggregates")
containing doubles without breaking the ABI or rejecting
standard-conforming code.  (Never mind that g77 already does this
for systems like SPARC; SPARC users expect that, apparently,
while x86 users don't, mostly.)

But this change would set DECL_ALIGN for stack-based VAR_DECLs
to 64, and implement that, presumably by assuring that the
stack frame is itself 64-bit aligned.

What I don't know (having not looked into it in any detail) is
how best to ensure the stack frame is 64-bit aligned.  Presumably
%sp will always be 32-bit aligned upon entry to any procedure
(according to the ABI; perhaps the hardware?).  Is it reasonable
to just subtract an extra 8 bytes when creating the frame
pointer upon procedure entry and then NAND it with 7 to align
it?  Or would that make for problems with debugger, profiling,
and/or exception support, or is there no quick way to NAND the
frame pointer on the x86?

It seems like everyone else thinks the right way to do this is
to try to always assure %sp is 64-bit aligned across calls by
modifying all the code that is in the procedure-call chain.
That probably means an extra dummy push before odd-number-of-args
calls, etc., right?

The reason I'd generally prefer the former approach to the latter
is that either one is likely to cost some performance, but the
latter *always* costs performance since the caller doesn't know
whether the callee uses doubles, whereas the former costs only
when the procedure doing the extra dance actually uses doubles.
(Whether we can teach gcc to not do the NAND(%fp,7) if there
are no doubles on the stack is another issue.)

        tq vm, (burley)

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 199806221811.OAA07410@melange.gnu.org >you write:
  > For Fortran code, we can usually hand-wave that; this case would
  > only come up when the call tree has an *embedded* procedure
  > that doesn't maintain proper alignment, and since the big
  > computational problem with g77 performance is in code compiled
  > by g77, and such code is rarely called by C code, I don't think
  > this would represent a huge deficiency.
Right, but changing STACK_BOUNDARY is not an option because it does
effect C code.


  > >	  If the stack gets mis-aligned relative to STACK_BOUNDARY
  > >	  combine could end up removing a seemingly useless
  > >	  stack operation/address calculation.
  > 
  > I don't understand this, but presumably I need to look into it
  > further.
I explained it a little in a message to Toon.  Basically combine knows
have to remove a rundant "and" operation which just turns off some
low order bits in an address.  If the stack isn't aligned to
STACK_BOUNDARY, then combine could end up removing a mask operation
that wasn't redundant.



  > Okay, that makes sense to me.  We want to hit a majority of cases
  > anyway.  We don't care (for now) about cases where users are
  > combining multiple languages in weird ways, for example.
Well, we care about it from a correctness standpoint.  Things still
have to work if they're combining .o files from old compilers,
callback from the library like qsort, etc.  But we aren't really
worred about performance in those cases.

  > 
  > >	* The ABI is still going to mandate that some doubles in
  > >	  argument lists are going to be mis-aligned.  We'd have
  > >	  to arrange to copy them from the arglist into a suitable
  > >	  stack slot.  This may be more trouble than its worth.
  > 
  > I'm not sure how this can ever happen in the x86 architecture?
Sure.  Think about cases where the alignment of the double in the
arglist isn't naturally aligned (think C, pass by value :-).

foo (double, int)

we push args back to front.

So we push the int on the stack, which means the double will be
at only a 4 byte aligned stack address if we assume our stack
was 8 byte aligned before we pushed the args.

You might think we could compensate for this by pushing an extra 
dummy word before the first integer to ensure the double gets 
aligned.  But that loses if we have:

foo (int2, double, int1)

If we pushed an extra 4 byte hunk before int1, then the total 
size of the arglist would be 20 bytes -- not a multiple of 8.

And as I'll explain below, we must always make sure to allocate
in 8 byte lumps -- we can't depend on the callee to round the stack.


  > Is it reasonable
  > to just subtract an extra 8 bytes when creating the frame
  > pointer upon procedure entry and then NAND it with 7 to align
  > it?  Or would that make for problems with debugger, profiling,
  > and/or exception support, or is there no quick way to NAND the
  > frame pointer on the x86?
Nope.  Because you then don't have a constant offset to get to the
arguments that were passed to the function.    To make this work
you'd have to dedicate a hard register to serve as an argument
pointer, which will be horrible.

[ Think about it, how can you generate code to find an argument if
  at entry to the procedure you may adjust the stack by a varying
  value (0 or 4). ]

Instead we must make sure that we always allocate stacks in 8 byte
hunks in the prologue *and* that we push an extra dummy word on the stack
when performing function calls where the arg list + return pointer
are not a multiple of 8 bytes in size.

[ Remember, the call itself will push a 4 byte word on the stack
  too, so we have to account for it too. ]


  > It seems like everyone else thinks the right way to do this is
  > to try to always assure %sp is 64-bit aligned across calls by
  > modifying all the code that is in the procedure-call chain.
  > That probably means an extra dummy push before odd-number-of-args
  > calls, etc., right?
Close.  It's not the number of args, but the total size of the arg
list.  If the size of the arg list is a multiple of 8 bytes, then
we have to push a dummy arg. so that in the stack is 8 byte aligned
when we enter the callee.


jeff

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

>  > >	  If the stack gets mis-aligned relative to STACK_BOUNDARY
>  > >	  combine could end up removing a seemingly useless
>  > >	  stack operation/address calculation.
>  > 
>  > I don't understand this, but presumably I need to look into it
>  > further.
>I explained it a little in a message to Toon.  Basically combine knows
>have to remove a rundant "and" operation which just turns off some
>low order bits in an address.  If the stack isn't aligned to
>STACK_BOUNDARY, then combine could end up removing a mask operation
>that wasn't redundant.

I'm a little curious, though, how such an operation comes to pass.
Is it only likely because the user code does something like
"&foo & 7", or are there internally-generated reasons?  It's okay
if you can't think of any examples; I agree with the overall
sentiment that we don't want to lie to the compiler in this area,
even if we can't come up with a reason it'd bite us right away!

>  > Okay, that makes sense to me.  We want to hit a majority of cases
>  > anyway.  We don't care (for now) about cases where users are
>  > combining multiple languages in weird ways, for example.
>Well, we care about it from a correctness standpoint.  Things still
>have to work if they're combining .o files from old compilers,
>callback from the library like qsort, etc.  But we aren't really
>worred about performance in those cases.

I came up with worse examples.  If STACK_BOUNDARY (or anything that
might break the ABI) is adjusted based on whether the processor
is [56]86 vs. [34]86, then code/libraries that happen to be compiled
on different variants of the x86 architecture could be magically
incompatible, producing subtly wrong results.

The other bad one is if we made only the g77 compiler "break" the
ABI to get this performance the "easy way", then some poor user
believed the g77 docs about f2c compatibility and tried to link
f2c-and-gcc-compiled code with g77-compiled code.  Even on the
same machine with the same version of gcc/g77 (egcs 1.1, if we
went down this rat-hole :), the result would be a subtly broken
executable, because the g77-compiled code would lay out its
COMMON areas differently than the f2c-and-gcc-compiled code!

>Sure.  Think about cases where the alignment of the double in the
>arglist isn't naturally aligned (think C, pass by value :-).
>
>foo (double, int)
>
>we push args back to front.
>
>So we push the int on the stack, which means the double will be
>at only a 4 byte aligned stack address if we assume our stack
>was 8 byte aligned before we pushed the args.

Note that, in practice, what g77 most often does is:

foo (double *, int *)

But, aside from that...

My question is, just why, *conceptually*, is it a problem on the
x86 architecture to try to align the argument list so the caller
frame is 64-bit aligned *and* at least some of the doubles in
the list are 64-bit aligned, but some aren't?

That is, is there a reason that x86 code *must* be generated either
to always assume doubles are 32-bit aligned *or* are always
64-bit aligned?  I can't think of any.

If that's the case, then IMO this whole problem is indeed, as I
thought, the result of gcc just not having a flexible-enough
architecture, that is, its "housekeeping staff" can't cope with
meeting these meetable requirements.

So can we at least come up with a short-term way to say "*try*
to align outgoing doubles to 64-bits, but don't assume incoming
doubles are 64-bit aligned", and in the long run make a better
overall architecture for representing alignments?  (Do I need
to write a "white paper" on what I mean by all this -- would
that help anyone understand what I'm talking about?  I've thought
it through quite a bit lately, so I could probably bang it out
with a few days' work.)

>You might think we could compensate for this by pushing an extra 
>dummy word before the first integer to ensure the double gets 
>aligned.  But that loses if we have:
>
>foo (int2, double, int1)
>
>If we pushed an extra 4 byte hunk before int1, then the total 
>size of the arglist would be 20 bytes -- not a multiple of 8.
>
>And as I'll explain below, we must always make sure to allocate
>in 8 byte lumps -- we can't depend on the callee to round the stack.

Again, what is the *real* problem with just doing what is currently
done for that case, ending up with a misaligned double arg for
the incoming procedure -- must it really assume its double is
64-bit aligned?  Or is this really just an internal problem with
gcc's housekeeping?

(Guess I should start reading my 486 handbook again!  :)

>  > Is it reasonable
>  > to just subtract an extra 8 bytes when creating the frame
>  > pointer upon procedure entry and then NAND it with 7 to align
>  > it?  Or would that make for problems with debugger, profiling,
>  > and/or exception support, or is there no quick way to NAND the
>  > frame pointer on the x86?
>Nope.  Because you then don't have a constant offset to get to the
>arguments that were passed to the function.    To make this work
>you'd have to dedicate a hard register to serve as an argument
>pointer, which will be horrible.
>
>[ Think about it, how can you generate code to find an argument if
>  at entry to the procedure you may adjust the stack by a varying
>  value (0 or 4). ]

Duh, okay, that's right.  That's my limited SPARC/VLIW thinking
tripping me up again.  Even though they have the same problem, I
don't think about it, because so often all the incoming arguments
arrive in registers.  (I have spent most of the last 13 years or
so working on machines that have registers; I'd forgotten my
earlier experiences working on machines with hardly any, sorry.  :)

>Instead we must make sure that we always allocate stacks in 8 byte
>hunks in the prologue *and* that we push an extra dummy word on the stack
>when performing function calls where the arg list + return pointer
>are not a multiple of 8 bytes in size.
>
>[ Remember, the call itself will push a 4 byte word on the stack
>  too, so we have to account for it too. ]

Right.  Okay.

>  > It seems like everyone else thinks the right way to do this is
>  > to try to always assure %sp is 64-bit aligned across calls by
>  > modifying all the code that is in the procedure-call chain.
>  > That probably means an extra dummy push before odd-number-of-args
>  > calls, etc., right?
>Close.  It's not the number of args, but the total size of the arg
>list.  If the size of the arg list is a multiple of 8 bytes, then
>we have to push a dummy arg. so that in the stack is 8 byte aligned
>when we enter the callee.

Well, if we can arrange for internal gcc housekeeping to do this
by default, *without* having other gcc housekeeping assume that
incoming double arguments, or the stack frame itself, are aligned,
is that basically enough to cover what I've been asking for?

(Note that, ideally, -malign-double would not be needed to do the
above.  I wouldn't mind a new option to disable that new behavior,
but IMO it should be enabled by default.)

Also, presumably we don't actually have to *push* an arg, but just
subtract 4 from %esp, right?

I am quite willing to do this work myself.  But I say that well-
knowing I'm not the best person for the job; just someone sufficiently
enthused, with a spot of time, a Pentium II, a trackball, and
half the g77 user base hounding me for the past couple of years,
etc. etc. etc.  So I'd need some initial hand-holding, probably.  :)

        tq vm, (burley)

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 199806230722.DAA02276@melange.gnu.org >you write:
  > I'm a little curious, though, how such an operation comes to pass.
The code to implement va_arg has address masking of this nature.  I
also believe it occurs internally to handle memory accesses smaller
than 32bits on the alpha.

  > I came up with worse examples.  If STACK_BOUNDARY (or anything that
  > might break the ABI) is adjusted based on whether the processor
  > is [56]86 vs. [34]86, then code/libraries that happen to be compiled
  > on different variants of the x86 architecture could be magically
  > incompatible, producing subtly wrong results.
Yes.  Though I would strongly recommend against ABI things changing
based on the processor for this exact reason :-)

  > My question is, just why, *conceptually*, is it a problem on the
  > x86 architecture to try to align the argument list so the caller
  > frame is 64-bit aligned *and* at least some of the doubles in
  > the list are 64-bit aligned, but some aren't?
  > 
  > That is, is there a reason that x86 code *must* be generated either
  > to always assume doubles are 32-bit aligned *or* are always
  > 64-bit aligned?  I can't think of any.
It's not an architecture issue, but an ABI issue.  The architecture
should be able to handle just about an alignment we throw at it.

Basically the ABI just mandates a 4 byte alignment, we get better
performance if we could get the args 8 byte aligned.  But  I'll be
a little suprised if we can do this without having the callee copy
it out of the arglist to an aligned memory slot.

There is an interesting problem from a gcc internals standpoint that
we may hit if we ever tried to align doubles relative to the start of
the argument list.  I ran into it on the v850 a couple years ago, but
I don't remember the details.  Basically the info we needed to do
this wasn't available and the scheme broke down when handling 
varargs/stdarg.


  > So can we at least come up with a short-term way to say "*try*
  > to align outgoing doubles to 64-bits, but don't assume incoming
  > doubles are 64-bit aligned", and in the long run make a better
  > overall architecture for representing alignments?
Let's defer trying to align arglists until we get the stack pointer
itself aligned and until after we're aligning auto variables relative
to the stack pointer and possibly stack slots for pseudos that don't
get hard registers aligned :-)

My gut tells me aligning variables inside the arglist isn't going to
win as much as the other cases noted above.

  > >You might think we could compensate for this by pushing an extra 
  > >dummy word before the first integer to ensure the double gets 
  > >aligned.  But that loses if we have:
  > >
  > >foo (int2, double, int1)
  > >
  > >If we pushed an extra 4 byte hunk before int1, then the total 
  > >size of the arglist would be 20 bytes -- not a multiple of 8.
  > >
  > >And as I'll explain below, we must always make sure to allocate
  > >in 8 byte lumps -- we can't depend on the callee to round the stack.
  > 
  > Again, what is the *real* problem with just doing what is currently
  > done for that case, ending up with a misaligned double arg for
  > the incoming procedure -- must it really assume its double is
  > 64-bit aligned?  Or is this really just an internal problem with
  > gcc's housekeeping?
There's no problem other than the performance issues.  The code will
still work.  Maybe that's where we're mis-communicating :-)

Before we can do *anything* about the alignment of args and autos we
first need to get the stack pointer aligned at all times.  Let's deal
with that first, then try to come up with solutions for the auto and
argument alignment afterwards.


  > >Instead we must make sure that we always allocate stacks in 8 byte
  > >hunks in the prologue *and* that we push an extra dummy word on the stack
  > >when performing function calls where the arg list + return pointer
  > >are not a multiple of 8 bytes in size.
  > >
  > >[ Remember, the call itself will push a 4 byte word on the stack
  > >  too, so we have to account for it too. ]
  > 
  > Right.  Okay.
OK.  We agree on this.  And since any work which involves trying to
align autos depends on first getting the stack aligned let's solve the
alignment of the stack pointer problem first.  That work can happen
while we debate the other issues :-)


  > Also, presumably we don't actually have to *push* an arg, but just
  > subtract 4 from %esp, right?
Right.  We don't actually have to make the memory reference, just allocate
an extra outgoing arg slot before we push any of the real outgoing
arguments.

  > I am quite willing to do this work myself.  But I say that well-
  > knowing I'm not the best person for the job; just someone sufficiently
  > enthused, with a spot of time, a Pentium II, a trackball, and
  > half the g77 user base hounding me for the past couple of years,
  > etc. etc. etc.  So I'd need some initial hand-holding, probably.  :)
Well, I don't have the time to tackle it myself, but I can try to help
you (or anyone else) through the twisty maze of ABI related code in
gcc to try and make this happen.

jeff

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Craig Burley]

>Basically the ABI just mandates a 4 byte alignment, we get better
>performance if we could get the args 8 byte aligned.  But  I'll be
>a little suprised if we can do this without having the callee copy
>it out of the arglist to an aligned memory slot.

I guess we shouldn't try aligning outoing/incoming doubles passed
"by value" (C style) at all, now that I think about it more.  It'd
surely break the ABI.

>My gut tells me aligning variables inside the arglist isn't going to
>win as much as the other cases noted above.

Especially not for Fortran, since g77 doesn't generally pass doubles
(or anything) by value, with some exceptions for the run-time
library.

And, I suspect the real performance penalties come mostly from arrays
and such inside loops anyway.  People don't pass arrays by value
(not usually ;-), and if an incoming by-value double is used
frequently in a loop, all that's really needed is to make the
compiler smart enough to make an aligned copy of that argument...but
let's wait until we see real code that could benefit from that.

>  > Again, what is the *real* problem with just doing what is currently
>  > done for that case, ending up with a misaligned double arg for
>  > the incoming procedure -- must it really assume its double is
>  > 64-bit aligned?  Or is this really just an internal problem with
>  > gcc's housekeeping?
>There's no problem other than the performance issues.  The code will
>still work.  Maybe that's where we're mis-communicating :-)

Oh, okay, good, indeed we were.  My priorities here are first to
make sure nothing that does work stops working; second to make
sure nothing reasonable suddenly goes lots slower; third to
make lots of stuff go faster.  Its the third priority we're discussing,
of course, but some of the solutions that have been proposed
(including, I though, mine) might violate the first two.

But I now don't see how we can align doubles in an arglist while
both aligning the callee's incoming stack frame *and* meeting the
ABI requirements.  After all, any arglist consisting of arbitrary
float, double, and int (32-bit) must be laid out with no padding
between args and no padding between the last-pushed arg (the
first arg and the return address `call' pushes), right?  The only
way to ensure that the incoming stack frame is aligned is to
optionally reserve a 4-byte pad before pushing any of the args,
as we've discussed.

So, AFAICT, the doubles end up where they end up, either aligned
or not, and there's nothing we can do about it at that point.

Of course, the callee can, as you point out, copy them to aligned
locations on its stack frame and use that, which is worthwhile
if it sees the potential for frequent references during the call.

>Before we can do *anything* about the alignment of args and autos we
>first need to get the stack pointer aligned at all times.  Let's deal
>with that first, then try to come up with solutions for the auto and
>argument alignment afterwards.

Uh-guh-reed!  :)

        tq vm, (burley)

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Jeffrey A Law]

  In message < 199806241507.LAA11762@melange.gnu.org >you write:
  > >Basically the ABI just mandates a 4 byte alignment, we get better
  > >performance if we could get the args 8 byte aligned.  But  I'll be
  > >a little suprised if we can do this without having the callee copy
  > >it out of the arglist to an aligned memory slot.
  > 
  > I guess we shouldn't try aligning outoing/incoming doubles passed
  > "by value" (C style) at all, now that I think about it more.  It'd
  > surely break the ABI.
Right.  That's basically what I was trying to explain in one or more
of those longer messages.  You can't align stuff in the arglist without
either breaking the ABI or blowing away the alignment we want for the
stack pointer.

  > And, I suspect the real performance penalties come mostly from arrays
  > and such inside loops anyway.  People don't pass arrays by value
  > (not usually ;-), and if an incoming by-value double is used
  > frequently in a loop, all that's really needed is to make the
  > compiler smart enough to make an aligned copy of that argument...but
  > let's wait until we see real code that could benefit from that.
Right.  It may also be the case that we'll need to align stack slots
for pseudos that don't get hard regs.  But that can wait until we
determine its important.


  > So, AFAICT, the doubles end up where they end up, either aligned
  > or not, and there's nothing we can do about it at that point.
Right.


  > >Before we can do *anything* about the alignment of args and autos we
  > >first need to get the stack pointer aligned at all times.  Let's deal
  > >with that first, then try to come up with solutions for the auto and
  > >argument alignment afterwards.
  > 
  > Uh-guh-reed!  :) 
Yeppers. :-)  

jeff

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Tim Hollebeek]

Jeffrey A Law writes ...
> 
> Right.  That's basically what I was trying to explain in one or more
> of those longer messages.  You can't align stuff in the arglist without
> either breaking the ABI or blowing away the alignment we want for the
> stack pointer.

Would it be possible to have the argument read from its unaligned
location the first time it is used, but if it is ever spilled out of a
register before it goes dead to have it written to an aligned
location?  This seems like a workable idea which is half way between
the 'copy to an aligned location' and the 'always use the unaligned
value' ideas.  Might be a bitch to implement, though.

---------------------------------------------------------------------------
Tim Hollebeek                           | "Everything above is a true
email: tim@wfn-shop.princeton.edu       |  statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim |  false values of true."

Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Marc Lehmann]

On Wed, Jun 24, 1998 at 06:11:55PM -0600, Jeffrey A Law wrote:

>   > "by value" (C style) at all, now that I think about it more.  It'd
>   > surely break the ABI.
> Right.  That's basically what I was trying to explain in one or more
> of those longer messages.  You can't align stuff in the arglist without
> either breaking the ABI or blowing away the alignment we want for the
> stack pointer.

-malign-double already breaks the abi, and is reeeealy useful. considerung
it doesn't cost anything at all to implement -marg-align-double (except
fixing a bug/deficiency in calls.c). I'd guess people would be happy for the
additional 1%.

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

egcs-1.1 release schedule

[Gabriel Dos Reis]

Is there any project to improve alias analysis (C++) and const
reference optimization to be included in egcs-1.1 ? 

-- Gaby
"Abstraction is selective ignorance." 
	-- Andrew Koenig

Re: egcs-1.1 release schedule

[Joe Buck]

> Is there any project to improve alias analysis (C++) and const
> reference optimization to be included in egcs-1.1 ? 

egcs-1.1 is unlikely to contain anything that isn't in the current
snapshot (except for simple bug fixes).  It will have ADDRESSOF,
which can improve some simple cases (passing a struct or class with one
field by const reference to an inlined function, for example).

Re: egcs-1.1 release schedule

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    >> Is there any project to improve alias analysis (C++) and const
    >> reference optimization to be included in egcs-1.1 ?

    Joe> egcs-1.1 is unlikely to contain anything that isn't in the
    Joe> current snapshot (except for simple bug fixes).  It will have

Well, I did submit code to type-based alias analysis about a week
ago.  I'm hoping that code will be in the 1.1. release; that will
depend on a) Jeff's availability to look at the code and b) whether
he thinks I did a good job or not.

This code makes a huge difference on some scientific computing
benchmarks one of my customers is using.

You can look through the egcs-patches archive if you're interested in
trying out the patch.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: egcs-1.1 release schedule

[Jeffrey A Law]

  In message < 199806201335.PAA13904@piano.dptmaths.ens-cachan.fr >you write:
  > 
  > 
  > Is there any project to improve alias analysis (C++) and const
  > reference optimization to be included in egcs-1.1 ? 
Interestingly enough Mark Mitchell posted some code to improve alias
analysis very recently.  I haven't had a chance to look at it yet.

It would also be helpful if John Carr could take a looksie since he
owns our current backend alias code.  :-)

jeff

gcc2 merge

[Jeffrey A Law]

I've just checked in the long delayed merge from gcc2 snapshot 980929.

The major change brought over in this merge is the initial i18n support for
gcc.

If you've ever thought about calling warn, pedwarn, fatal, fprintf etc, then I
recommend you read ABOUT-GCC-NLS and ABOUT-NLS which describe the basic
concepts.

i18n support is far from complete.  I suspect there's some error/warning
messages we've added that may need to be tweaked.  Each front end will need
to be converted as well as backends which emit any kind of errors/warnings.
Oh what fun.

The "intl" subdirectory itself will probably move out of the gcc directory
at some point in the future.  It can/should be shared across various tools
that already have some i18n support like texinfo, binutils, & gas.


The rs6000/ppc port has not been merged.  The changes from gcc are merely
formatting changes. David Edelson and I are still discussing ways to handle
them.  Hopefully we'll reach an agreement soon.

Aside from i18n the changes for this snapshot were relatively minor.  You
can find the details in FSFChangeLog and a few tidbits in ChangeLog.

The tags "before-merge-gcc2-980929" and "after-merge-gcc2-980929" mark the
state of the tree immediately before and immediately after the merge.

It is possible this merge will introduce some short term instability.  I'm
going to run through a matrix of builds again starting tomorrow night (-O0,
-O2, -O9) to try and sweep out any dusty corners.

jeff

Re: gcc2 merge

[Andreas Jaeger]

Hi Jeff,

you added neither the po nor the intl subdirs in your merge.  Both are 
referenced in FSFChangeLog.  Is this ok?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: gcc2 merge

[Alexandre Oliva]

On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:

> you added neither the po nor the intl subdirs in your merge.  Both are 
> referenced in FSFChangeLog.  Is this ok?

cvs update -d ?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: gcc2 merge

[Andreas Jaeger]

>>>>> Alexandre Oliva writes:

Alexandre> On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
>> you added neither the po nor the intl subdirs in your merge.  Both are 
>> referenced in FSFChangeLog.  Is this ok?

Alexandre> cvs update -d ?
Yes (always enabled via .cvsrc).

Oh shame on me:-(.  The intl subdirectory is already there - and
filled - since 17th December.  I expected to see it *now* but it must
have found it's way earlier in my directories.

Sorry about that,
Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: gcc2 merge

[Andreas Jaeger]

>>>>> Alexandre Oliva writes:

Alexandre> On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
>> you added neither the po nor the intl subdirs in your merge.  Both are 
>> referenced in FSFChangeLog.  Is this ok?

Alexandre> cvs update -d ?
Yes (always enabled via .cvsrc).

Oh shame on me:-(.  The intl subdirectory is already there - and
filled - since 17th December.  I expected to see it *now* but it must
have found it's way earlier in my directories.

Sorry about that,
Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: gcc2 merge

[H.J. Lu]

> 
> On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
> 
> > you added neither the po nor the intl subdirs in your merge.  Both are 
> > referenced in FSFChangeLog.  Is this ok?
> 
> cvs update -d ?
> 

I have been using

# cvs co egcs

It picks up all new files and deletes the old ones. Anything wrong
with that?

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc2 merge

[Nick Burrett]

hjl@lucon.org (H.J. Lu) writes:

> > 
> > On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
> > 
> > > you added neither the po nor the intl subdirs in your merge.  Both are 
> > > referenced in FSFChangeLog.  Is this ok?
> > 
> > cvs update -d ?
> > 
> 
> I have been using
> 
> # cvs co egcs
> 
> It picks up all new files and deletes the old ones. Anything wrong
> with that?

Yes. It's a total waste of time and bandwidth. Use:
   cvs update -Pd

This will delete empty directories and get new ones.

Nick.

Re: gcc2 merge

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > > 
> > > On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
> > > 
> > > > you added neither the po nor the intl subdirs in your merge.  Both are 
> > > > referenced in FSFChangeLog.  Is this ok?
> > > 
> > > cvs update -d ?
> > > 
> > 
> > I have been using
> > 
> > # cvs co egcs
> > 
> > It picks up all new files and deletes the old ones. Anything wrong
> > with that?
> 
> Yes. It's a total waste of time and bandwidth. Use:

As far as I can tell, it only updates those files are changed.

-- 
H.J. Lu (hjl@gnu.org)

Re: gcc2 merge

[Nick Burrett]

hjl@lucon.org (H.J. Lu) writes:

> > 
> > hjl@lucon.org (H.J. Lu) writes:
> > 
> > > > 
> > > > On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
> > > > 
> > > > > you added neither the po nor the intl subdirs in your merge.  Both are 
> > > > > referenced in FSFChangeLog.  Is this ok?
> > > > 
> > > > cvs update -d ?
> > > > 
> > > 
> > > I have been using
> > > 
> > > # cvs co egcs
> > > 
> > > It picks up all new files and deletes the old ones. Anything wrong
> > > with that?
> > 
> > Yes. It's a total waste of time and bandwidth. Use:
> 
> As far as I can tell, it only updates those files are changed.

Correct! And that is the intention.

The option is to either download an entire egcs tarball (some 20Mb+) or
do a cvs update and get just the changes, say 1Mb.

Re: gcc2 merge

[Matthew Kirkwood]

On Fri, 29 Jan 1999, H.J. Lu wrote:

> > > > cvs update -d ?

> > > # cvs co egcs
> > >
> > > It picks up all new files and deletes the old ones. Anything wrong
> > > with that?
> >
> > Yes. It's a total waste of time and bandwidth. Use:
>
> As far as I can tell, it only updates those files are changed.

Indeed.  I believe that in old versions of CVS, co would grab everything,
but now it's more clever (mostly, I guess, for this reason).

Matthew.

Re: gcc2 merge

[Jean-Pierre Radley]

Matthew Kirkwood averred (on Fri, Jan 29, 1999 at 02:32:38PM +0000):
| On Fri, 29 Jan 1999, H.J. Lu wrote:
| 
| > > > > cvs update -d ?
| 
| > > > # cvs co egcs
| > > >
| > > > It picks up all new files and deletes the old ones. Anything wrong
| > > > with that?
| > >
| > > Yes. It's a total waste of time and bandwidth. Use:
| >
| > As far as I can tell, it only updates those files are changed.
| 
| Indeed.  I believe that in old versions of CVS, co would grab everything,
| but now it's more clever (mostly, I guess, for this reason).

In my egcs directory, I type c*/e*. That expands to contrib/egcs-update,
a convenient shell script.

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: gcc2 merge

[Zack Weinberg]

On Fri, 29 Jan 1999 05:52:12 -0800 (PST), H.J. Lu wrote:
>> 
>> hjl@lucon.org (H.J. Lu) writes:
>> 
>> > > 
>> > > On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:
>> > > 
>> > > > you added neither the po nor the intl subdirs in your merge.  Both are
> 
>> > > > referenced in FSFChangeLog.  Is this ok?
>> > > 
>> > > cvs update -d ?
>> > > 
>> > 
>> > I have been using
>> > 
>> > # cvs co egcs
>> > 
>> > It picks up all new files and deletes the old ones. Anything wrong
>> > with that?
>> 
>> Yes. It's a total waste of time and bandwidth. Use:
>
>As far as I can tell, it only updates those files are changed.

Nope, it pulls the entire tree and throws away what it doesn't need.
It just doesn't tell you that.

zw

Re: gcc2 merge

[Jeffrey A Law]

  In message < 199901291435.JAA01892@blastula.phys.columbia.edu >you write:
  > Nope, it pulls the entire tree and throws away what it doesn't need.
  > It just doesn't tell you that.
That has not been my experience.  From what I've been able to tell (from
checkout times) cvs co blah will DTRT and not throw away existing stuff.

Note from cvs.texinfo:
Create or update a working directory containing copies of the
source files specified by @var{modules}.  You must execute
@code{checkout} before using most of the other @sc{cvs}
commands, since most of them operate on your working
directory.

[ ... ]


Note that running @code{checkout} on a directory that was already
built by a prior @code{checkout} is also permitted.
This is similar to specifying the @samp{-d} option
to the @code{update} command in the sense that new
directories that have been created in the repository
will appear in your work area.

jeff

Re: gcc2 merge

[Gerald Pfeifer]

On Fri, 29 Jan 1999, H.J. Lu wrote:
>> cvs update -d ?
> I have been using
> 
> # cvs co egcs
> 
> It picks up all new files and deletes the old ones. Anything wrong
> with that?

Yup. This won't pick up new *directories* (unless you have some special
setting somewhere else):

Re: gcc2 merge

[Gerald Pfeifer]

On Fri, 29 Jan 1999, Gerald Pfeifer wrote:
> On Fri, 29 Jan 1999, H.J. Lu wrote:
>>> cvs update -d ?
>> # cvs co egcs
>> 
>> It picks up all new files and deletes the old ones. Anything wrong
>> with that?
> Yup. This won't pick up new *directories* (unless you have some special
> setting somewhere else):

<argl> Sorry, I somehow misread "co" as "up"! (I guess I should be
more careful when having slept only two hours... :-( )

Please accept my apologies! 
Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: gcc2 merge

[Alexandre Oliva]

On Jan 27, 1999, Andreas Jaeger <aj@arthur.rhein-neckar.de> wrote:

> you added neither the po nor the intl subdirs in your merge.  Both are 
> referenced in FSFChangeLog.  Is this ok?

cvs update -d ?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: gcc2 merge

[Andreas Jaeger]

Hi Jeff,

you added neither the po nor the intl subdirs in your merge.  Both are 
referenced in FSFChangeLog.  Is this ok?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

gcc2 merge

[Jeffrey A Law]

I've just checked in the long delayed merge from gcc2 snapshot 980929.

The major change brought over in this merge is the initial i18n support for
gcc.

If you've ever thought about calling warn, pedwarn, fatal, fprintf etc, then I
recommend you read ABOUT-GCC-NLS and ABOUT-NLS which describe the basic
concepts.

i18n support is far from complete.  I suspect there's some error/warning
messages we've added that may need to be tweaked.  Each front end will need
to be converted as well as backends which emit any kind of errors/warnings.
Oh what fun.

The "intl" subdirectory itself will probably move out of the gcc directory
at some point in the future.  It can/should be shared across various tools
that already have some i18n support like texinfo, binutils, & gas.


The rs6000/ppc port has not been merged.  The changes from gcc are merely
formatting changes. David Edelson and I are still discussing ways to handle
them.  Hopefully we'll reach an agreement soon.

Aside from i18n the changes for this snapshot were relatively minor.  You
can find the details in FSFChangeLog and a few tidbits in ChangeLog.

The tags "before-merge-gcc2-980929" and "after-merge-gcc2-980929" mark the
state of the tree immediately before and immediately after the merge.

It is possible this merge will introduce some short term instability.  I'm
going to run through a matrix of builds again starting tomorrow night (-O0,
-O2, -O9) to try and sweep out any dusty corners.

jeff

Re: gcc2 merge

[Mike Stump]

> Date: Wed, 27 Jan 1999 02:46:59 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> I've just checked in the long delayed merge from gcc2 snapshot 980929.

Congratulations...  I'll start up a bootstrap/test on a machine or two
to try and shake out any bugs I can find, be done with the first in 1
hour 37 minutes.

Re: gcc2 merge

[Mike Stump]

> Date: Wed, 27 Jan 1999 02:46:59 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> I've just checked in the long delayed merge from gcc2 snapshot 980929.

Congratulations...  I'll start up a bootstrap/test on a machine or two
to try and shake out any bugs I can find, be done with the first in 1
hour 37 minutes.

Re: gcc2 merge

[Mike Stump]

> Date: Wed, 27 Jan 1999 05:44:33 -0800
> From: mrs@wrs.com (Mike Stump)

> Congratulations...  I'll start up a bootstrap/test on a machine or two
> to try and shake out any bugs I can find, be done with the first in 1
> hour 37 minutes.

First problem, everyone be sure to cvs update with -d, things won't
build without it!  I hate to point this out, but I do in hopes of
forestalling a small flood of why can't I build it anymore messages.

You can update like this:

	    egcs/contrib/egcs_update -d

Re: gcc2 merge

[Toon Moene]

Mike Stump wrote:

> First problem, everyone be sure to cvs update with -d, things won't
> build without it!  I hate to point this out, but I do in hopes of
> forestalling a small flood of why can't I build it anymore messages.

Thanks.

That seems to work over here -

[toon@moene toon]$ /usr/snp/bin/gcc -v
Reading specs from
/usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
gcc version egcs-2.93.03 19990127 (gcc2 ss-980929 experimental)

I am now running the LAPACK test suite (assuming that there are enough
people with the above mentioned target who can run the regular test set
first) ~ crunch ~ crunch ~ crunch .... DONE.

Hmmm, I18N ...

Uw rekentuig heeft een onwettige opdracht uitgevoerd.
Wenst U hem:
1. De Blauwe Dood.
2. Een Schop tegen de Rode Knop.
3. Opnieuw tot leven te wekken met Drie Vingers.
Uw Keuze: _

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: gcc2 merge

[Toon Moene]

Mike Stump wrote:

> First problem, everyone be sure to cvs update with -d, things won't
> build without it!  I hate to point this out, but I do in hopes of
> forestalling a small flood of why can't I build it anymore messages.

Thanks.

That seems to work over here -

[toon@moene toon]$ /usr/snp/bin/gcc -v
Reading specs from
/usr/snp/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.03/specs
gcc version egcs-2.93.03 19990127 (gcc2 ss-980929 experimental)

I am now running the LAPACK test suite (assuming that there are enough
people with the above mentioned target who can run the regular test set
first) ~ crunch ~ crunch ~ crunch .... DONE.

Hmmm, I18N ...

Uw rekentuig heeft een onwettige opdracht uitgevoerd.
Wenst U hem:
1. De Blauwe Dood.
2. Een Schop tegen de Rode Knop.
3. Opnieuw tot leven te wekken met Drie Vingers.
Uw Keuze: _

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: gcc2 merge

[Mike Stump]

> Date: Wed, 27 Jan 1999 05:44:33 -0800
> From: mrs@wrs.com (Mike Stump)

> Congratulations...  I'll start up a bootstrap/test on a machine or two
> to try and shake out any bugs I can find, be done with the first in 1
> hour 37 minutes.

First problem, everyone be sure to cvs update with -d, things won't
build without it!  I hate to point this out, but I do in hopes of
forestalling a small flood of why can't I build it anymore messages.

You can update like this:

	    egcs/contrib/egcs_update -d

Re: gcc2 merge

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 > I've just checked in the long delayed merge from gcc2 snapshot 980929.
 > 
 > The major change brought over in this merge is the initial i18n support for
 > gcc.
 > 
 > It is possible this merge will introduce some short term instability.  I'm
 > going to run through a matrix of builds again starting tomorrow night (-O0,
 > -O2, -O9) to try and sweep out any dusty corners.
 > jeff

	Briefly looking over the changes, it looks like some bogus
stuff creeped in.

1.  I think I disagree with putting the PRINTF_PROTO_* stuff go into
system.h.  It was only used by cccp.c and cexp.y and it got nuked from
cccp.c.  I think we should deprecate this form and we should be using
the "PVPROTO ((...)) ATTRIBUTE_PRINTF" style instead.  This is a cleanup
issue, not a serous problem though. 

2.  However, when PRINTF_PROTO_* was removed from cccp.c, the vararg
prototypes in that file no longer will get __attribute__ ((__printf__)). 
So they must have ATTRIBUTE_PRINTF_* added to their prototypes or no
format checks are done. 

3.  All the vararg prototypes in cccp.c incorrectly switched from
PRINTF_PROTO_* to VPROTO.  This is completely wrong since VPROTO is only
valid on function _definitions_ not prototype declarations.  One must
use PVPROTO in prototypes.  This mistake causes a bootstrap failure for
any stage1 compiler which doesn't default to ANSI.  I.e. OSF4 cc and
SunOS4 cc. 

	I'll see about making a patch, but in the mean time, here is
the output from OSF4 cc.

		--Kaveh


 > cc -DIN_GCC -DHAIFA -g -DHAVE_CONFIG_H -I. -I. -I./config
 >   -I./../include
 >   -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/include\"
 >   -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../..`echo
 >   /usr/local | sed -e 's|^/usr/local||' -e 's|/[^/]*|/..|g'`/include/g++-2\"
 >   -DLOCAL_INCLUDE_DIR=\"/usr/local/include\"
 >   -DCROSS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../../alphaev5-dec-osf4.0b/sys-include\"
 >   -DTOOL_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../../alphaev5-dec-osf4.0b/include\"
 >   -c `echo ./cccp.c | sed 's,^\./,,'`
 > cc: Error: cccp.c, line 988: Missing "{".
 > static void notice VPROTO((char *, ...));
 > ----------------------------------------^
 > cc: Error: cccp.c, line 989: Invalid statement.
 > static void vnotice PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 990: Invalid statement.
 > void error VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 991: Invalid statement.
 > void verror PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 992: Invalid statement.
 > static void error_from_errno PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 993: Invalid statement.
 > void warning VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 994: Invalid statement.
 > static void vwarning PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 995: Invalid statement.
 > static void error_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 996: Invalid statement.
 > static void verror_with_line PROTO((int, char *, va_list));
 > ^
 > cc: Error: cccp.c, line 997: Invalid statement.
 > static void vwarning_with_line PROTO((int, char *, va_list));
 > ^
 > cc: Error: cccp.c, line 998: Invalid statement.
 > static void warning_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 999: Invalid statement.
 > void pedwarn VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 1000: Invalid statement.
 > void pedwarn_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 1001: Invalid statement.
 > static void pedwarn_with_file_and_line VPROTO((char *, size_t, int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 1002: Invalid statement.
 > static void pedwarn_strange_white_space PROTO((int));
 > ^
 > cc: Error: cccp.c, line 1004: Invalid statement.
 > static void print_containing_files PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1006: Invalid statement.
 > static int line_for_error PROTO((int));
 > ^
 > cc: Error: cccp.c, line 1007: Invalid statement.
 > static int grow_outbuf PROTO((FILE_BUF *, int));
 > ^
 > cc: Error: cccp.c, line 1009: Invalid statement.
 > static HASHNODE *install PROTO((U_CHAR *, int, enum node_type, char *, int));
 > ^
 > cc: Error: cccp.c, line 1011: Invalid statement.
 > static void delete_macro PROTO((HASHNODE *));
 > ^
 > cc: Error: cccp.c, line 1012: Invalid statement.
 > static int hashf PROTO((U_CHAR *, int, int));
 > ^
 > cc: Error: cccp.c, line 1014: Invalid statement.
 > static void dump_single_macro PROTO((HASHNODE *, FILE *));
 > ^
 > cc: Error: cccp.c, line 1015: Invalid statement.
 > static void dump_all_macros PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1016: Invalid statement.
 > static void dump_defn_1 PROTO((U_CHAR *, int, int, FILE *));
 > ^
 > cc: Error: cccp.c, line 1017: Invalid statement.
 > static void dump_arg_n PROTO((DEFINITION *, int, FILE *));
 > ^
 > cc: Error: cccp.c, line 1019: Invalid statement.
 > static void initialize_char_syntax PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1020: Invalid statement.
 > static void initialize_builtins PROTO((FILE_BUF *, FILE_BUF *));
 > ^
 > cc: Error: cccp.c, line 1022: Invalid statement.
 > static void make_definition PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 1023: Invalid statement.
 > static void make_undef PROTO((char *, FILE_BUF *));
 > ^
 > cc: Error: cccp.c, line 1025: Invalid statement.
 > static void make_assertion PROTO((char *, char *));
 > ^
 > cc: Error: cccp.c, line 1027: Invalid statement.
 > static struct file_name_list *new_include_prefix PROTO((struct file_name_list *, const char *, const char *, const char *));
 > ^
 > cc: Error: cccp.c, line 1028: Invalid statement.
 > static void append_include_chain PROTO((struct file_name_list *, struct file_name_list *));
 > ^
 > cc: Error: cccp.c, line 1030: Invalid statement.
 > static int quote_string_for_make PROTO((char *, char *));
 > ^
 > cc: Error: cccp.c, line 1031: Invalid statement.
 > static void deps_output PROTO((char *, int));
 > ^
 > cc: Error: cccp.c, line 1033: Invalid statement.
 > static void fatal VPROTO((char *, ...)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1034: Invalid statement.
 > void fancy_abort PROTO((void)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1035: Invalid statement.
 > static void perror_with_name PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 1036: Invalid statement.
 > static void pfatal_with_name PROTO((char *)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1037: Invalid statement.
 > static void pipe_closed PROTO((int)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1039: Invalid statement.
 > static void memory_full PROTO((void)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1040: Invalid statement.
 > static void print_help PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1048: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 1051: Invalid statement.
 >      char *ptr;
 > -----^
 > cc: Error: cccp.c, line 1052: Invalid statement.
 >      int len;
 > -----^
 > cc: Error: cccp.c, line 1084: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1087: Invalid statement.
 >      char *ptr;
 > -----^
 > cc: Error: cccp.c, line 1088: Invalid statement.
 >      int len;
 > -----^
 > cc: Error: cccp.c, line 1119: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1122: Missing ";".
 >      size_t length;
 > ------------^
 > cc: Error: cccp.c, line 1140: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1210: Invalid statement.
 > int
 > ^
 > cc: Error: cccp.c, line 1213: Invalid statement.
 >      char **argv;
 > -----^
 > cc: Error: cccp.c, line 2343: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2380: Invalid statement.
 > static U_CHAR *
 > ^
 > cc: Error: cccp.c, line 2383: Invalid statement.
 >      int c;
 > -----^
 > cc: Error: cccp.c, line 2384: Missing ";".
 >      size_t n;
 > ------------^
 > cc: Error: cccp.c, line 2411: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2485: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2518: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2557: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 2560: Invalid statement.
 >      register U_CHAR *limit;
 > -----^
 > cc: Error: cccp.c, line 2562: Invalid statement.
 >      int *arglen, *cmdlen;	/* how long they are */
 > -----^
 > cc: Error: cccp.c, line 2638: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2641: Invalid statement.
 >      int output_marks;
 > -----^
 > cc: Error: cccp.c, line 3707: Invalid statement.
 > static FILE_BUF
 > ^
 > cc: Error: cccp.c, line 3710: Invalid statement.
 >      int output_marks, assertions;
 > -----^
 > cc: Error: cccp.c, line 3797: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4218: Invalid statement.
 > static struct tm *
 > ^
 > cc: Error: cccp.c, line 4229: Invalid statement.
 > static char *monthnames[] = {"Jan", "Feb", "Mar", "Apr", "May", "Jun",
 > ^
 > cc: Error: cccp.c, line 4231: Invalid expression.
 > 			    };
 > ----------------------------^
 > cc: Error: cccp.c, line 4238: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 4422: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4426: Invalid statement.
 >      struct directive *keyword;
 > -----^
 > cc: Error: cccp.c, line 4873: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4888: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 4913: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4942: Invalid statement.
 > static size_t
 > ^
 > cc: Error: cccp.c, line 5012: Invalid statement.
 > struct file_name_map
 > ^
 > cc: Error: cccp.c, line 5024: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5057: Invalid statement.
 > static struct file_name_map *
 > ^
 > cc: Error: cccp.c, line 5153: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 5156: Invalid statement.
 >      struct file_name_list *searchptr;
 > -----^
 > cc: Error: cccp.c, line 5158: Invalid statement.
 >      struct include_file **pinc;
 > -----^
 > cc: Error: cccp.c, line 5231: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5234: Invalid statement.
 >      struct file_name_list *searchptr;
 > -----^
 > cc: Error: cccp.c, line 5279: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 5307: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5310: Invalid statement.
 >      struct include_file *inc;
 > -----^
 > cc: Error: cccp.c, line 5312: Invalid statement.
 >      int system_header_p;
 > -----^
 > cc: Error: cccp.c, line 5313: Invalid statement.
 >      struct file_name_list *dirptr;
 > -----^
 > cc: Error: cccp.c, line 5420: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5441: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5444: Invalid statement.
 >      struct stat *st;
 > -----^
 > cc: Error: cccp.c, line 5445: Invalid statement.
 >      char *fname ATTRIBUTE_UNUSED;
 > -----^
 > cc: Error: cccp.c, line 5446: Invalid statement.
 >      char **limit;
 > -----^
 > cc: Error: cccp.c, line 5497: Invalid statement.
 > static int 
 > ^
 > cc: Error: cccp.c, line 5557: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5673: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5687: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5740: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5744: Invalid statement.
 >      struct directive *keyword;
 > -----^
 > cc: Error: cccp.c, line 5744: More than 100 errors were encountered in the course of compilation.
 >      struct directive *keyword;
 > -----^
 > make[2]: *** [cccp.o] Error 1
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: gcc2 merge

[Jeffrey A Law]

  In message < 199901281501.KAA18437@caip.rutgers.edu >you write:
  > 	Briefly looking over the changes, it looks like some bogus
  > stuff creeped in.
It's certainly possible.  All the error handling code was hit very hard by
these changes.  Combine that with all our work on the error handling routines
and we've got the potential for some stuff to sneak by.

The good news is we only have to go through this once for each major hunk of
code which outputs diagnostics.  That stuff doesn't tend to change a whole
lot over time.


  > 1.  I think I disagree with putting the PRINTF_PROTO_* stuff go into
  > system.h.  It was only used by cccp.c and cexp.y and it got nuked from
  > cccp.c.  I think we should deprecate this form and we should be using
  > the "PVPROTO ((...)) ATTRIBUTE_PRINTF" style instead.  This is a cleanup
  > issue, not a serous problem though. 
Fine.  Awaiting patch.


  > 2.  However, when PRINTF_PROTO_* was removed from cccp.c, the vararg
  > prototypes in that file no longer will get __attribute__ ((__printf__)). 
  > So they must have ATTRIBUTE_PRINTF_* added to their prototypes or no
  > format checks are done. 
OK.  I assume you'll fix that too ;-)



  > 3.  All the vararg prototypes in cccp.c incorrectly switched from
  > PRINTF_PROTO_* to VPROTO.  This is completely wrong since VPROTO is only
  > valid on function _definitions_ not prototype declarations.  One must
  > use PVPROTO in prototypes.  This mistake causes a bootstrap failure for
  > any stage1 compiler which doesn't default to ANSI.  I.e. OSF4 cc and
  > SunOS4 cc. 
  > 
  > 	I'll see about making a patch, but in the mean time, here is
  > the output from OSF4 cc.
Eagerly awaiting a patch :-)


jeff

Re: gcc2 merge

[Jeffrey A Law]

  In message < 199901281501.KAA18437@caip.rutgers.edu >you write:
  > 	Briefly looking over the changes, it looks like some bogus
  > stuff creeped in.
It's certainly possible.  All the error handling code was hit very hard by
these changes.  Combine that with all our work on the error handling routines
and we've got the potential for some stuff to sneak by.

The good news is we only have to go through this once for each major hunk of
code which outputs diagnostics.  That stuff doesn't tend to change a whole
lot over time.


  > 1.  I think I disagree with putting the PRINTF_PROTO_* stuff go into
  > system.h.  It was only used by cccp.c and cexp.y and it got nuked from
  > cccp.c.  I think we should deprecate this form and we should be using
  > the "PVPROTO ((...)) ATTRIBUTE_PRINTF" style instead.  This is a cleanup
  > issue, not a serous problem though. 
Fine.  Awaiting patch.


  > 2.  However, when PRINTF_PROTO_* was removed from cccp.c, the vararg
  > prototypes in that file no longer will get __attribute__ ((__printf__)). 
  > So they must have ATTRIBUTE_PRINTF_* added to their prototypes or no
  > format checks are done. 
OK.  I assume you'll fix that too ;-)



  > 3.  All the vararg prototypes in cccp.c incorrectly switched from
  > PRINTF_PROTO_* to VPROTO.  This is completely wrong since VPROTO is only
  > valid on function _definitions_ not prototype declarations.  One must
  > use PVPROTO in prototypes.  This mistake causes a bootstrap failure for
  > any stage1 compiler which doesn't default to ANSI.  I.e. OSF4 cc and
  > SunOS4 cc. 
  > 
  > 	I'll see about making a patch, but in the mean time, here is
  > the output from OSF4 cc.
Eagerly awaiting a patch :-)


jeff

Re: gcc2 merge

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 > I've just checked in the long delayed merge from gcc2 snapshot 980929.
 > 
 > The major change brought over in this merge is the initial i18n support for
 > gcc.
 > 
 > It is possible this merge will introduce some short term instability.  I'm
 > going to run through a matrix of builds again starting tomorrow night (-O0,
 > -O2, -O9) to try and sweep out any dusty corners.
 > jeff

	Briefly looking over the changes, it looks like some bogus
stuff creeped in.

1.  I think I disagree with putting the PRINTF_PROTO_* stuff go into
system.h.  It was only used by cccp.c and cexp.y and it got nuked from
cccp.c.  I think we should deprecate this form and we should be using
the "PVPROTO ((...)) ATTRIBUTE_PRINTF" style instead.  This is a cleanup
issue, not a serous problem though. 

2.  However, when PRINTF_PROTO_* was removed from cccp.c, the vararg
prototypes in that file no longer will get __attribute__ ((__printf__)). 
So they must have ATTRIBUTE_PRINTF_* added to their prototypes or no
format checks are done. 

3.  All the vararg prototypes in cccp.c incorrectly switched from
PRINTF_PROTO_* to VPROTO.  This is completely wrong since VPROTO is only
valid on function _definitions_ not prototype declarations.  One must
use PVPROTO in prototypes.  This mistake causes a bootstrap failure for
any stage1 compiler which doesn't default to ANSI.  I.e. OSF4 cc and
SunOS4 cc. 

	I'll see about making a patch, but in the mean time, here is
the output from OSF4 cc.

		--Kaveh


 > cc -DIN_GCC -DHAIFA -g -DHAVE_CONFIG_H -I. -I. -I./config
 >   -I./../include
 >   -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/include\"
 >   -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../..`echo
 >   /usr/local | sed -e 's|^/usr/local||' -e 's|/[^/]*|/..|g'`/include/g++-2\"
 >   -DLOCAL_INCLUDE_DIR=\"/usr/local/include\"
 >   -DCROSS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../../alphaev5-dec-osf4.0b/sys-include\"
 >   -DTOOL_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alphaev5-dec-osf4.0b/egcs-2.93.03/../../../../alphaev5-dec-osf4.0b/include\"
 >   -c `echo ./cccp.c | sed 's,^\./,,'`
 > cc: Error: cccp.c, line 988: Missing "{".
 > static void notice VPROTO((char *, ...));
 > ----------------------------------------^
 > cc: Error: cccp.c, line 989: Invalid statement.
 > static void vnotice PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 990: Invalid statement.
 > void error VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 991: Invalid statement.
 > void verror PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 992: Invalid statement.
 > static void error_from_errno PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 993: Invalid statement.
 > void warning VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 994: Invalid statement.
 > static void vwarning PROTO((char *, va_list));
 > ^
 > cc: Error: cccp.c, line 995: Invalid statement.
 > static void error_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 996: Invalid statement.
 > static void verror_with_line PROTO((int, char *, va_list));
 > ^
 > cc: Error: cccp.c, line 997: Invalid statement.
 > static void vwarning_with_line PROTO((int, char *, va_list));
 > ^
 > cc: Error: cccp.c, line 998: Invalid statement.
 > static void warning_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 999: Invalid statement.
 > void pedwarn VPROTO((char *, ...));
 > ^
 > cc: Error: cccp.c, line 1000: Invalid statement.
 > void pedwarn_with_line VPROTO((int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 1001: Invalid statement.
 > static void pedwarn_with_file_and_line VPROTO((char *, size_t, int, char *, ...));
 > ^
 > cc: Error: cccp.c, line 1002: Invalid statement.
 > static void pedwarn_strange_white_space PROTO((int));
 > ^
 > cc: Error: cccp.c, line 1004: Invalid statement.
 > static void print_containing_files PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1006: Invalid statement.
 > static int line_for_error PROTO((int));
 > ^
 > cc: Error: cccp.c, line 1007: Invalid statement.
 > static int grow_outbuf PROTO((FILE_BUF *, int));
 > ^
 > cc: Error: cccp.c, line 1009: Invalid statement.
 > static HASHNODE *install PROTO((U_CHAR *, int, enum node_type, char *, int));
 > ^
 > cc: Error: cccp.c, line 1011: Invalid statement.
 > static void delete_macro PROTO((HASHNODE *));
 > ^
 > cc: Error: cccp.c, line 1012: Invalid statement.
 > static int hashf PROTO((U_CHAR *, int, int));
 > ^
 > cc: Error: cccp.c, line 1014: Invalid statement.
 > static void dump_single_macro PROTO((HASHNODE *, FILE *));
 > ^
 > cc: Error: cccp.c, line 1015: Invalid statement.
 > static void dump_all_macros PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1016: Invalid statement.
 > static void dump_defn_1 PROTO((U_CHAR *, int, int, FILE *));
 > ^
 > cc: Error: cccp.c, line 1017: Invalid statement.
 > static void dump_arg_n PROTO((DEFINITION *, int, FILE *));
 > ^
 > cc: Error: cccp.c, line 1019: Invalid statement.
 > static void initialize_char_syntax PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1020: Invalid statement.
 > static void initialize_builtins PROTO((FILE_BUF *, FILE_BUF *));
 > ^
 > cc: Error: cccp.c, line 1022: Invalid statement.
 > static void make_definition PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 1023: Invalid statement.
 > static void make_undef PROTO((char *, FILE_BUF *));
 > ^
 > cc: Error: cccp.c, line 1025: Invalid statement.
 > static void make_assertion PROTO((char *, char *));
 > ^
 > cc: Error: cccp.c, line 1027: Invalid statement.
 > static struct file_name_list *new_include_prefix PROTO((struct file_name_list *, const char *, const char *, const char *));
 > ^
 > cc: Error: cccp.c, line 1028: Invalid statement.
 > static void append_include_chain PROTO((struct file_name_list *, struct file_name_list *));
 > ^
 > cc: Error: cccp.c, line 1030: Invalid statement.
 > static int quote_string_for_make PROTO((char *, char *));
 > ^
 > cc: Error: cccp.c, line 1031: Invalid statement.
 > static void deps_output PROTO((char *, int));
 > ^
 > cc: Error: cccp.c, line 1033: Invalid statement.
 > static void fatal VPROTO((char *, ...)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1034: Invalid statement.
 > void fancy_abort PROTO((void)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1035: Invalid statement.
 > static void perror_with_name PROTO((char *));
 > ^
 > cc: Error: cccp.c, line 1036: Invalid statement.
 > static void pfatal_with_name PROTO((char *)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1037: Invalid statement.
 > static void pipe_closed PROTO((int)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1039: Invalid statement.
 > static void memory_full PROTO((void)) __attribute__ ((noreturn));
 > ^
 > cc: Error: cccp.c, line 1040: Invalid statement.
 > static void print_help PROTO((void));
 > ^
 > cc: Error: cccp.c, line 1048: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 1051: Invalid statement.
 >      char *ptr;
 > -----^
 > cc: Error: cccp.c, line 1052: Invalid statement.
 >      int len;
 > -----^
 > cc: Error: cccp.c, line 1084: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1087: Invalid statement.
 >      char *ptr;
 > -----^
 > cc: Error: cccp.c, line 1088: Invalid statement.
 >      int len;
 > -----^
 > cc: Error: cccp.c, line 1119: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1122: Missing ";".
 >      size_t length;
 > ------------^
 > cc: Error: cccp.c, line 1140: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 1210: Invalid statement.
 > int
 > ^
 > cc: Error: cccp.c, line 1213: Invalid statement.
 >      char **argv;
 > -----^
 > cc: Error: cccp.c, line 2343: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2380: Invalid statement.
 > static U_CHAR *
 > ^
 > cc: Error: cccp.c, line 2383: Invalid statement.
 >      int c;
 > -----^
 > cc: Error: cccp.c, line 2384: Missing ";".
 >      size_t n;
 > ------------^
 > cc: Error: cccp.c, line 2411: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2485: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2518: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2557: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 2560: Invalid statement.
 >      register U_CHAR *limit;
 > -----^
 > cc: Error: cccp.c, line 2562: Invalid statement.
 >      int *arglen, *cmdlen;	/* how long they are */
 > -----^
 > cc: Error: cccp.c, line 2638: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 2641: Invalid statement.
 >      int output_marks;
 > -----^
 > cc: Error: cccp.c, line 3707: Invalid statement.
 > static FILE_BUF
 > ^
 > cc: Error: cccp.c, line 3710: Invalid statement.
 >      int output_marks, assertions;
 > -----^
 > cc: Error: cccp.c, line 3797: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4218: Invalid statement.
 > static struct tm *
 > ^
 > cc: Error: cccp.c, line 4229: Invalid statement.
 > static char *monthnames[] = {"Jan", "Feb", "Mar", "Apr", "May", "Jun",
 > ^
 > cc: Error: cccp.c, line 4231: Invalid expression.
 > 			    };
 > ----------------------------^
 > cc: Error: cccp.c, line 4238: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 4422: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4426: Invalid statement.
 >      struct directive *keyword;
 > -----^
 > cc: Error: cccp.c, line 4873: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4888: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 4913: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 4942: Invalid statement.
 > static size_t
 > ^
 > cc: Error: cccp.c, line 5012: Invalid statement.
 > struct file_name_map
 > ^
 > cc: Error: cccp.c, line 5024: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5057: Invalid statement.
 > static struct file_name_map *
 > ^
 > cc: Error: cccp.c, line 5153: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 5156: Invalid statement.
 >      struct file_name_list *searchptr;
 > -----^
 > cc: Error: cccp.c, line 5158: Invalid statement.
 >      struct include_file **pinc;
 > -----^
 > cc: Error: cccp.c, line 5231: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5234: Invalid statement.
 >      struct file_name_list *searchptr;
 > -----^
 > cc: Error: cccp.c, line 5279: Invalid statement.
 > static int
 > ^
 > cc: Error: cccp.c, line 5307: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5310: Invalid statement.
 >      struct include_file *inc;
 > -----^
 > cc: Error: cccp.c, line 5312: Invalid statement.
 >      int system_header_p;
 > -----^
 > cc: Error: cccp.c, line 5313: Invalid statement.
 >      struct file_name_list *dirptr;
 > -----^
 > cc: Error: cccp.c, line 5420: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5441: Invalid statement.
 > static char *
 > ^
 > cc: Error: cccp.c, line 5444: Invalid statement.
 >      struct stat *st;
 > -----^
 > cc: Error: cccp.c, line 5445: Invalid statement.
 >      char *fname ATTRIBUTE_UNUSED;
 > -----^
 > cc: Error: cccp.c, line 5446: Invalid statement.
 >      char **limit;
 > -----^
 > cc: Error: cccp.c, line 5497: Invalid statement.
 > static int 
 > ^
 > cc: Error: cccp.c, line 5557: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5673: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5687: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5740: Invalid statement.
 > static void
 > ^
 > cc: Error: cccp.c, line 5744: Invalid statement.
 >      struct directive *keyword;
 > -----^
 > cc: Error: cccp.c, line 5744: More than 100 errors were encountered in the course of compilation.
 >      struct directive *keyword;
 > -----^
 > make[2]: *** [cccp.o] Error 1
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

gcc2 merge

[Jeffrey A Law]

I'm in the process of doing a merge from the final gcc2 snapshot (990109).
It's bootstrapping and I'm re-testing after fixing a regression.

Not a lot of changes worth noting.  A handful of simple bugfixes, a few
new minor optimizations, some formatting fixes and some more conversion of
code to gen_rtx_FOO (particularly for some of the less active backends).

I expect to get it checked in tonight or tomorrow.

Richard Kenner will then be working to merge the remaining changes made to the
gcc2 tree after the last snapshot.

jeff

gcc2 merge

[Jeffrey A Law]

I'm in the process of doing a merge from the final gcc2 snapshot (990109).
It's bootstrapping and I'm re-testing after fixing a regression.

Not a lot of changes worth noting.  A handful of simple bugfixes, a few
new minor optimizations, some formatting fixes and some more conversion of
code to gen_rtx_FOO (particularly for some of the less active backends).

I expect to get it checked in tonight or tomorrow.

Richard Kenner will then be working to merge the remaining changes made to the
gcc2 tree after the last snapshot.

jeff