[fpc-devel] Bitpacked Record Bug

[Willibald Krenn]

Hi!

I stumbled accross a bug in fpc that manifests itself when working with 
bitpacked records that have fields with pos and size mod 8 == 0; For 
example:

type
   TField = bitpacked record
     case boolean of
     true:  (value : integer);
     false: (
             data: 0 .. $FFFFFF;             // 24 bits
             operation: 0 .. $7F;            // 7 bits
             binop: Boolean                  // one bit
            )
   end;

var
    a, b: integer;
    instr: TField;
begin
   //instr.value := $01000004;
   a := instr.data ; //and $FFFFFF; // bug in fpc
   b := instr.data + 1;
end.


will generate asm like

mov    0x37ab3(%rip),%eax        # 0x439020 <U_P$PROJECT1_INSTR>
mov    %eax,0x37a8d(%rip)        # 0x439000 <U_P$PROJECT1_A>
mov    0x37aa7(%rip),%eax        # 0x439020 <U_P$PROJECT1_INSTR>
and    $0xffffff,%rax
and    $0xffffffff,%eax
inc    %rax

which is wrong for the first assignment and not very clever for the 
second one.

I've tracked the issue down to the following check in ncv.pas:

ncv.pas (~ 265)
if equal_defs(p.resultdef,def) and
    not is_bitpacked_access(p) then
  p.resultdef:=def

The function is_bitpacked_access (relevant parts) is defined as follows.

in nutils.pas (~ 1155)
subscriptn:
result:= is_packed_record_or_object(tsubscriptnode(n).left.resultdef)
           and (
           (tsubscriptnode(n).vs.vardef.packedbitsize mod 8 <> 0) or
           (tsubscriptnode(n).vs.fieldoffset mod 8 <>0));

Now, my question is why is an access with a size mod 8 and an offset mod 
8 considered NOT bitpacked? Or is the code in ncv.pas to blame?

Cheers,
   Willi