align-0.1 and other problems

[Craig Burley]

I've already found a bug in the automatic-array checking that
caused overwriting the stack (showed up on Alpha, not on Intel)
and uploaded the fixed version to:

  < ftp://alpha.gnu.org/gnu/g77/align/align-0.1.tar.gz >

Meanwhile, as over-engineered as this little tool is, and as
much time as I spent on it (sometimes thinking "too much"), it
turns out to have been worthwhile.

Seems there's been some bad bugs in g77 for years now that
I guess nobody has had the misfortunate of running into
(or realizing they've done), and, while trying to debug some
*other* problems `align' suggests are in g77 somewhere, I found
those new bad bugs.  All this happened on the Alpha, but the new
bad bugs definitely can afflict pretty much any system g77
runs on.

Fortunately, rare is the code likely to trigger these bugs, but
when it does -- well, the bugs mainly have to do with g77 not
allocating quite enough memory for certain weirdly-constructed
COMMON and EQUIVALENCE aggregates, so just think about what happens
when stores to *beyond* the end of such aggregates happen, and
you get the idea: apparently unrelated stuff gets ovewritten!

The bugs are basically that g77 decides the aggregate needs
"initial padding" of, usually, 4 bytes (e.g. because a double-precision,
64-bit-aligned item is forced onto an odd-numbered offset from
the beginning of the aggregate), but forgets to add this
initial padding into the size computation.  This can happen
on any system with differing alignment requirements for types,
even involving double-precision on x86 if using -malign-double.

I've got fixes for these in progress already, but have been
finding some related improvements to make, plus I still have
to fix related bugs in that g77 forgets to account for the
initial padding when emitting initial values for aggregates.

The original bug I was looking into, and still have to chase down,
is that, apparently, sometimes g77 forgets to account for the
initial padding at all, and ends up producing code that makes
unaligned references.  (On my Alpha that means messages to the
console.)  This probably causes conforming, even portable, code
to crash on SPARCs, but I haven't tried that out yet.

(Yes, I intend to write simple test cases for all this stuff soon,
to avoid regressions in the future.  And, of course, all the
pertinent bug fixes will go into g77 0.5.24 and egcs 1.1.)

Anyway, as tedious as writing the `align' package was, having
it point me to these long-lurking bugs made it all worthwhile,
even ignoring whether it'll help anyone improving g77's (gcc's)
alignment of double-precision variables on, e.g., x86.

Certainly it was more productive spending lots of time writing
some useful, if over-engineered, package, than spending lots of
time (someday) in an unscheduled fashion debugging some difficult-
to-reproduce bug, given that the end result (finding and fixing
these bugs) was the same!

        tq vm, (burley)