Hi!

I think there is a more errors in fpc v1.1 (even after recent patch for ECX) What is the problem?

I can not perform fpc 1.1 make cycle with OPT=-CR option: ppc2 is crashed when it try to compile system.pp

I found that this is because tdictionery.rename do not return a nil (but a rundom value) when it can not find old node.

But as I understand, we must always find an old node???? (After patching a tdictionery.rename to return a nil when we do not find a old node, ppc2 start droping a job in another place)

Regards,
Sergey Korshunoff

Sergey Korshunoff wrote

I think there is a more errors in fpc v1.1 (even after recent patch for ECX) What is the problem?

I don't know :(

No, not in the case that causes the error I think.

(After patching a tdictionery.rename to return a nil when we do not find a old node, ppc2 start droping a job in another place)

The strange thing is that this crash happens in different places and if you try to reproduce it by recompiling the file in which the crash occurred, it doesn't happen anymore :( Also, the value of the instruction pointer is invalid when the crash occurs: points to the middle of some instruction.

Jonas

How a dictionery.rename used in other parts of compiler? It is called only when we shure old node is in dictionery? Or we do not check a dictionery before renaming?

The more stange thing is that why this crash always in ppc2.... Why not in ppc1 ?! We can assume fpc generates wrong code only when it is compiled with -CR ...

May be there is error in realization part of -CR? Because -Cr do not cause a problem and -CR work normally for FPC v1.0, then error may be in n386cal.pas or in i386.inc ...

Regards,
Sergey Korshunoff

Regards,
Sergey Korshunoff

Sergey Korshunoff wrote

> No, not in the case that causes the error I think. How a dictionery.rename used in other parts of compiler?

I don't know by heart.

It is called only when we shure old node is in dictionery? Or we do not check a dictionery before renaming?

In the case where it crashed, we don't check indeed. The rename procedure is there called just in case the symbol was already used before (with the old name).

The more stange thing is that why this crash always in ppc2.... Why not in ppc1 ?! We can assume fpc generates wrong code only when it is compiled with -CR ...

We'll have to do some generated assembler code comparisons to find out...

May be there is error in realization part of -CR? Because -Cr do not cause a problem and -CR work normally for FPC v1.0, then error may be in n386cal.pas or in i386.inc ...

I think -CR was recently extended by Peter so that it calls "fpc_do_as" for classes in some cases. Or is that for -Cr?

Jonas

FWIW: I also get a crash in ppc1 sometimes.

Jonas

That is correct -CR also adds runtime checks for class typecasts like

tclass1(class2).field=2

this will with -CR implicitly changed to the following sequence:

(class2 as tclass1).field=2

Maybe there is a problem with that code. It's not that well tested

Why did you remove the compilerproc construct and added a manually coded pass_2 for tcgasnode? fpc_do_as returns the instance as function result so that you could use it in the middle of an expression. I don't see the advantage of or need for a manually coded pass_2. There's a bug in it (it doesn't save/restore the register variables), but that can't cause the crashes since they also happen without -Or.

Jonas

Sorry.

     rename:=nil;

solved a problem. I do not understand why I got other errors after this patch before.

Regards,
Sergey Korshunoff
.

Jonas Maebe wrote

Why did you remove the compilerproc construct and added a manually coded pass_2 for tcgasnode?

I've found the answer: otherwise constructs like

with tclasstype(some_var) do
  begin
     inc(field_of_somvar);
  end;

don't work with -CR (since the compiler traets the type conversion as normal call then, so the result can't be an rvalue). I'm trying to work around this problem so that we can still use a compilerproc construction, that should be much less error prone.

Jonas

I have INTEL variant of my code:

{$ASMMODE INTEL}
begin
asm
    add ecx, offset @@k
@@k:
end
end.

in disasm i get next code: add ecx, 00418440

But, i need this code in AT&T syntax.

I try write next code:

addl .Lk,%ecx

but disasm get: add ecx, dword ptr [00418440]

What's my problem?

P.S: FPC 1.0.6

Kind Regards,
Michail.
_________________________________
Michail A.Baikov,
Linderdaum Team
http://www.gamedot.ru
http://linderdaum.gamedot.ru

You need

addl $.Lk,%ecx

The $ tells the assembler that you want the value OF the address and not the value AT the address.

Jonas

Thanks. Jonas, you guru in AT&T syntax =)

Thanks you!

mmsystem.pas(2465) Warning: stuff\out\mmsystem.ppw Interface CRC changed -154616
6811-334088799

What's wrong?

Kind Regards,
Michail.
_________________________________
Michail A.Baikov,
Linderdaum Team
http://www.gamedot.ru
http://linderdaum.gamedot.ru

[ Charset KOI8-R unsupported, converting... ]

- Old unit files in your -Fu path,
- multiple sources of mmsystem in your -Fu path or
- (unlikely) some circular import problem

k
Do you get this warning while compiling the mmsystem unit? In that case, it's most likely an error in the unit where a procedure is defined differently in the interface and in the implementation, but that error is not caught by the compiler.

I don't know whether the following example is still possible, but you could get this e.g. with

***
unit test;
interface
procedure t;
implementation;
procedure t; cdecl; external;
end.
***

The reason is that when the interface is parsed, the compiler thinks it's a normal procedure and thus uses a mangled name like U_TEST_$$_T or something for the procedure. In the implementation it turns out it's a function from a C library and thus the magled name is changed to 't'. This changes the interface of the unit after it has been completely parsed, so you get the above warning.

Jonas