Hello, FPC developers' list.

I can't build FPC today. Executable is always differ by one byte with the previous and cmp don't let me continue after make cycle:

D:/programming/fpc_2_4/bin/i386-win32/cmp.exe -i218 ppc3.exe ppc386.exe ppc3.exe ppc386.exe differ: char 6036742, line 17491

If I do a manual compare then:

D:\programming\fpc\compiler>fc ppc2.exe ppc3.exe /b comparing files ppc2.exe and PPC3.EXE
005C1D05: C8 E8

D:\programming\fpc\compiler>fc ppc3.exe ppc386.exe /b comparing files ppc3.exe and PPC386.EXE
005C1D05: E8 00

Looks like some random byte is generated at this address.

Paul Ishenin wrote

Looks like some random byte is generated at this address.

Maybe r17285? Although I don't immediately see a problem with it, I can't see any other revision from yesterday that could introduce such a bug.

Jonas

Can you please test if r17285 is the reason?

Florian Klämpfl wrote

Can you please test if r17285 is the reason?

17285 is the reason. 17284 compiles without the error.

Best regards,
Paul Ishenin

11.04.2011 20:29, Jonas Maebe пишет:

I also reviewed and can't see a problem there too.

Anyway, the merge touch more files than it should: /trunk/packages/fcl-xml/tests/README_DOM.txt
/trunk/packages/unzip/src/unzip51g.pp
/trunk/packages/winunits-base/src/dwmapi.pp

Also I noticed that ppu structer has changed but ppu version is not increased and ppudump is not adapted. But this can't affect the compilation the way it do.

Best regards,
Paul Ishenin

In our previous episode, Paul Ishenin said:

(unzip51g is a different problem probably. It is a package whose properties went wrong during branching or shortly thereafter. IIRC it has separate mergeinfo property.

I fixed this about half an year ago for the main branches, but forward branches might still contain it.

The change in unzip51g is the updating of the mergeinfo)

How do you start compilation? Because I cannot reproduce it on Windows 7/win32.

Florian Klämpfl wrote

How do you start compilation? Because I cannot reproduce it on Windows 7/win32.

make clean all OPT="-g -gl -gw -godwarfsets"

I do it also on Windows 7/win32.

I tried both 2.4.4 and 2.5.1 as the starting compiler.

Best regards,
Paul Ishenin

this compiles: make clean all
this does not: make clean all OPT="-gwl"

Best regards,
Paul Ishenin

I made another trial to find the reason today. In dbgdwarf.pas in TDebugInfoDwarf.appendsym_const_member I commented the next lines of code:

constset:
begin
   AddConstToAbbrev(ord(DW_FORM_block1));
current_asmdata.asmlists[al_dwarf_info].concat(tai_const.create_8bit(usedef.size));
{
   i:=0;
   size:=sym.constdef.size;
   while (i<size) do
     begin
current_asmdata.asmlists[al_dwarf_info].concat(tai_const.create_8bit((pbyte(sym.value.valueptr+i)^)));
       inc(i);
     end;
}
end;

After that make cycle finished without errors. I found this piece of code because the byte which differ every time was located after "ENDTOKENS" string in the executable.

ENDTOKENS is declared in pbase.pas as
const
  endtokens = [_SEMICOLON,_END,_ELSE,_UNTIL,_EXCEPT,_FINALLY];

Maybe this happen because ttoken contains > 256 elements and we do pbyte(sym.value.valueptr+i)^ ?

Best regards,
Paul Ishenin

My further research:

All tsetdef.size except endtokens have size = 4 or 32. endtokens has size = 33.

Compiler uses pconstset for valueptr in case of set. pconstset = ^set of 0..255 => max size = 32

Therefore for endtokens we go after the end of allocated value_ptr^ and of course we get random data there (I suppose in some cases we get access violation).

I for the reason of size = 33 and found the
next line:
savesize:=(high+7) div 8

Looks like as our case: if high = 257 then savesize = 33.

Best regards,
Paul Ishenin

Hello,
I have just a little question about expressions and types/cast management in FreePascal.

if I have a mixed expression with:
i, j, n : byte
k : word

n := i + k - j;

in this case, how does the compiler handle this situation? it evaluated
Add i , k -> result
and then
sub result, j

how the types are handled?
does the compiler cast i to a word, add it (word addition) to k, and cast j to word, do substraction and then the result is tranformed back to a Byte to do the assignment?

What I mean, does the compiler handle types locally by casting at each node, and force the cast at assignment node?
or does it do like C compiler, i.e. check the LValue at left of the assignement, take its type, and cast each BinOp node to this type systematically (which in the previous example means that k is casted to byte and only byte operations are done).

Regards and thank you for your time :)

Everything is evaluated with the native integer size, when assigning, the expression is converted and range checked if needed.

how the types are handled?

Thumb rules:
* evaluate ordinal expressions with the native integer size of the cpu, this is also what standard pascal does
* use a type which contains both involved operand types
* the result type of an expression does not depend on it's context Unfortunatly, these rules have a lot of exceptions but the meta rule is to avoid that joe programmer can shoot himself into the foot.

Yes.

It's a bug in the compiler that it accepts that set constant declaration. Sets are only allowed to contain values up to ord(255). Anything more is not supported, although things may work at the code generation level depending on how the set is used and how many elements it has.

Jonas

IMO the compiler converts operands to the "bigger" (wider) of the involved operand types, for every single operator. Possible overflows usually are ignored, i.e. the coder would have to cast one operand to an type, that allows to compute even intermediate results without overflows. Only the *detection* of actual overflows can be enforced by the overflow check compiler directive.

Furthermore the compiler is free in the order of evaluation, i.e. might here produce word(i-j)+k (not sure about the concrete FPC implementation and optimization options).

Finally a range check can be enforced, before the calculated value is stored in (truncated to the type-size of) the result variable.

What I mean, does the compiler handle types locally by casting at each node, and force the cast at assignment node? or does it do like C compiler, i.e. check the LValue at left of the assignement, take its type, and cast each BinOp node to this type

I doubt that a C compiler behaves as you describe. Consider the obvious case of boolean expressions, where it doesn't make sense to convert the *operands* of "if (a<b)" into something like a bit or byte, only because the result of the comparison can be represented by a single bit or CPU status flag. A compiler typically is allowed only to *widen" the operand types automatically, but not to narrow them down. AFAIR implicit downcasts can occur with assignment operators (in C), where the intermediate result is truncated to the size of the assignment variable, and evaluation continues with the type of that variable.

DoDi

Jonas Maebe wrote

It's a bug in the compiler that it accepts that set constant declaration. Sets are only allowed to contain values up to ord(255). Anything more is not supported, although things may work at the code generation level depending on how the set is used and how many elements it has.

For delphi mode there was a trick in the compiler to work with sets built on big enumeartions. For other modes it worked by accident I suppose.

I attached a patch. Please review and commit it. With this patch compiler finally builds here without errors.

Best regards,
Paul Ishenin.

I think it's ok, feel free to commit.

Jonas