From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,13f10cac2d21b84f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-26 15:20:35 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Is this a GNAT bug??? Date: 26 Apr 2002 15:20:34 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0204261420.4be419fb@posting.google.com> References: <3CC992D6.A87A3443@raytheon.com> NNTP-Posting-Host: 205.232.38.244 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1019859634 21163 127.0.0.1 (26 Apr 2002 22:20:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 26 Apr 2002 22:20:34 GMT Xref: archiver1.google.com comp.lang.ada:23158 Date: 2002-04-26T22:20:34+00:00 List-Id: Mark Johnson 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