Am 23.10.2010 15:47, schrieb 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?
I'am not sure about the change, it is Jonas' code. Can you please create a bug report with this information, so it won't be forgotten? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel