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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
