GNAT 4.4.5 Record Bit_Order Endian issues

[awdorrin <awdorrin@gmail.com>]

I have a record with specification definition that starts, using big endian notation, with:

for TRACK_RECORD_TYPE use
 record
  TRACK_ID at 0 range 0 .. 11;
  TRACK_ID_CNT at 1 range 4 .. 9;
   ...


The meaning being that the first 12 bits hold a track id and the next 6 bits hold the Count value.

I have had success in the past, using the gnat 4.4.5 compiler under Debian 6.0.6, to use the directive: for TRACK_RECORD_TYPE'Bit_Order use System.High_Order_First;
In order to continue using the definition in the big endian notation.

From the build output, the Bit_Order flag at first appears to be processed correctly, with the built compiler flags displaying to translated little endian definition as:

for TRACK_RECORD_TYPE use
 record
  TRACK_ID at 0 range 4 .. 15;
  TRACK_ID_CNT at 1 range 11 .. 6;
   ...

But the TRACK_ID_CNT range does not provide the proper definition.
I believe it should be: TRACK_ID_CNT at 1 range 5 .. 0

Using the following code:

TRK_REC.TRACK_ID := 1;
Text_IO.Put_Line("A: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID));
TRK_REC.TRACK_ID_CNT := 1;
Text_IO.Put_Line("B: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID));

The output displayed is:

A: TRK_REC.TRACK_ID = 1
B: TRK_REC.TRACK_ID = 1025

Apparently because the TRACK_ID field is being read as a 16-bit value where:

"0000 0100 0000 0001" -> "BBBB CCAA AAAA AAAA"
where the 'A' bits are the TRACK_ID and the B bits are part of the TRACK_ID_CNT field, and the 'C' bits are an overlap of the second variable, due to the improper definition translation.

Not sure if this 'bug' would be fixed in a newer version of the GNAT compiler or not.