Re: Is this a GNAT bug???

[dewar@gnat.com (Robert Dewar)]

Mark Johnson <mark_h_johnson@raytheon.com> wrote in message news:<3CC992D6.A87A3443@raytheon.com>...

> You may also find that pragma Pack does not do as much in GNAT as you
> might hope. I have a long running argument w/ Robert Dewar on a
> relatively recent change in GNAT 3.15 that caused some of our packed
> arrays to grow in size. He points to text in 13.2 which states "the
> implementation may, but need not, reorder components or cross aligned
> word boundaries to improve packing".

Actually you should not in general use Pack to specify a specific
layout.
In some very restricted cases (arrays with component sizes 1,2,4) the
effect of pragma Pack is defined, but in all other cases (records, and
arrays with
other component sizes), the effect of Pack is very much implementation
dependent. Basically what Pack says is "favor space in doing your
tradeoffs
between space and speed", but it is not any more definite than that.

If the exact layout is critical, you should use component size for
arrays
or a record representation clause for records. You should also be
careful
to specify sizes *AND* alignments for types where layout is critical
(Mark's
packed arrays got larger in GNAT 3.15 because there were some
instances of
records with no alignment clause, and GNAT 3.15 tends to favor speed
over
space when choosing default alignments (that's because modern
architectures
are *SO* dependent on alignment, we have programs that run ten times
faster
on 3.15 than on 3.14, just because of alignment. GNAT also likes to
maintain
alignment wherever possible, and does NOT let pragma Pack override an 
alignment in cases where this would degrade the code.

The moral of this story is that if you want to control things
yourself, rather
than rely on the default compiler choices, then take advantage of a
feature
that Ada has (and C sorely lacks). Specify your own sizes and
alignments and
don't depend on default choices of the compiler. The trouble with the
default
choices is that they will never satisfy everyone, and of course the
defaults
may change. We don't casually change defaults, but in this case, the
gain was
so huge that it seemed worthwhile, and we found only two or three
customers
whose code was depending on default alignment choices, with the fix
being to
specify the missing alignment clause.

Mark is right in his analysis of this particular case. This is by the
way another case where people should read the manual. Don't use rep
clauses in
GNAT without reading the section on rep clauses is a reasonable rule.

Oh, and this is also a good lesson in not approximating when you post
code to
CLA. You don't know what is important and what is not. In this case
the difference between 5 and 65 bits was a huge one. Read the manual
to understand
why!

Robert Dewar
Ada Core Technologies