Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2013-10

strange error "checksum changed" in package, when compiling project.

7 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

Just checking, if there may be a simple fault on my side, or if I stumbled on a bug (fpc 2.6.2 and trunk (from a few weeks ago))

It happens with circular unit references via uses in implementation. (I know "not advisable design", but a valid language feature)

The circle is in a package, the package compiles fine.

When I compile a project, using the package (therefore only path to ppu files)

Hint: Start of reading config file
C:\FPC\rel_2_6_2\gw\bin\i386-win32\fpc.cfg
Hint: End of reading config file C:\FPC\rel_2_6_2\gw\bin\i386-win32\fpc.cfg Free Pascal Compiler version 2.6.2 [2013/02/16] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling FpTest.lpr
Compiling testpascalparser.pas
PPU Loading
B:\lazarus_latest\components\fpdebug\lib\i386-win32\fpdbgdwarf.ppu PPU Source: fpdbgdwarf.pas not found
PPU Loading
B:\lazarus_latest\components\fpdebug\lib\i386-win32\fpdbgdwarf.ppu PPU Source: fpdbgdwarf.pas not found
Recompiling FpDbgDwarf, checksum changed for FpDbgClasses ..\fpdbgclasses.pp(331,13) Fatal: Can't find unit FpDbgDwarf used by FpDbgClasses

Project is
lazarus\components\fpdebug\test\FpTest.lpr

based on Revision: 43291
with modifications http://pastebin.com/8bTNcdjC

Reply by email

Martin
to Jonas Maebe
Jonas Maebe wrote 7 lines
On 20 Oct 2013, at 17:30, Martin wrote: > Just checking, if there may be a simple fault on my side, or if I stumbled on a bug (fpc 2.6.2 and trunk (from a few weeks ago)) > > It happens with circular unit references via uses in implementation. (I know "not advisable design", but a valid language feature) http://lists.freepascal.org/lists/fpc-devel/2011-July/024974.html

Ok, thanks.
This at least helped me to get it working again. (I had to remove some "inline").

It still leaves me curious, how does an inline change the interface?

And does that mean it is considered a bug or not.
It still looks like a bug to me. After all as far as I know, it is valid code. (and therefore should compile).

---------
As for the exact changes in this case. Lazarus revision 43293 will compile ( lazarus\components\fpdebug\test\FpTest.lpr )

in components\fpdebug\fpdbgclasses.pp line 140 and 141 are 2 commented "inline".

If uncommented compilation breaks.

Reply by email

Jonas Maebe
to Martin
Martin wrote 15 lines
On 20/10/2013 17:21, Jonas Maebe wrote: > On 20 Oct 2013, at 17:30, Martin wrote: > >> Just checking, if there may be a simple fault on my side, or if I stumbled on a bug (fpc 2.6.2 and trunk (from a few weeks ago)) >> >> It happens with circular unit references via uses in implementation. (I know "not advisable design", but a valid language feature) > http://lists.freepascal.org/lists/fpc-devel/2011-July/024974.html > Ok, thanks. This at least helped me to get it working again. (I had to remove some "inline"). It still leaves me curious, how does an inline change the interface? And does that mean it is considered a bug or not.

http://bugs.freepascal.org/view.php?id=19673

Jonas

Reply by email

Martin
to Jonas Maebe
Jonas Maebe wrote 18 lines
On 20 Oct 2013, at 18:52, Martin wrote: > On 20/10/2013 17:21, Jonas Maebe wrote: >> On 20 Oct 2013, at 17:30, Martin wrote: >> >>> Just checking, if there may be a simple fault on my side, or if I stumbled on a bug (fpc 2.6.2 and trunk (from a few weeks ago)) >>> >>> It happens with circular unit references via uses in implementation. (I know "not advisable design", but a valid language feature) >> http://lists.freepascal.org/lists/fpc-devel/2011-July/024974.html >> > Ok, thanks. > This at least helped me to get it working again. (I had to remove some "inline"). > > It still leaves me curious, how does an inline change the interface? > > And does that mean it is considered a bug or not. http://bugs.freepascal.org/view.php?id=19673

Thanks again.

I see there are still open related issues, so maybe some hope...

Show quoted text 5 lines
That is how the inlining is implemented by design currently. The availability of an inline function body changes the unit interface checksum, so that other units using that unit will be recompiled the next time and can use the inline body (since the first time the inline body was not yet available, it could not yet be inlined).

I have a very limited understanding of this, but I think I disagree (well I do disagree, I think tha I am correct to do so...)

AFAIX, ppu already have more than one checksum?

Then it would just be a question to make that yet another checksum. And if *only* this new checksum has changed, then recompile *if* the source is available.
If not, than keep things as they are.

After all what seems to happen:

- PackageUnit1 uses PackageUnit2 via implementation
- PackageUnit2 use PackageUnit1

So PackageUnit2 compiles with the "no inline body" interface of PackageUnit1. Then PackageUnit1 changes.

Now if project uses PackageUnit2 then fpc wants to recompile it (because PackageUnit1 changed).
But since compiling the project, there are only the ppu avail, and no source, it can not recompile.

Yet PackageUnit2 is actually valid, it only misses an optimization, but it can be used as it is.

Reply by email

Jonas Maebe
to Martin
Martin wrote 10 lines
I see there are still open related issues, so maybe some hope... > That is how the inlining is implemented by design currently. The availability of an inline function body changes the unit interface checksum, so that other units using that unit will be recompiled the next time and can use the inline body (since the first time the inline body was not yet available, it could not yet be inlined). I have a very limited understanding of this, but I think I disagree (well I do disagree, I think tha I am correct to do so...) AFAIX, ppu already have more than one checksum? Then it would just be a question to make that yet another checksum. And if *only* this new checksum has changed, then recompile *if* the source is available. If not, than keep things as they are.

Changing the behaviour of the compiler depending on whether or not the source code is available is not acceptable. The only reasonable alternative in my eyes would be to never inline anything in case of mutually dependent units (like Delphi does). Additionally, afaik compiling with -Ur already works around the problem today.

Jonas

Reply by email

Martin
to Jonas Maebe
Jonas Maebe wrote 13 lines
On 20 Oct 2013, at 19:33, Martin wrote: > I see there are still open related issues, so maybe some hope... > >> That is how the inlining is implemented by design currently. The availability of an inline function body changes the unit interface checksum, so that other units using that unit will be recompiled the next time and can use the inline body (since the first time the inline body was not yet available, it could not yet be inlined). > I have a very limited understanding of this, but I think I disagree (well I do disagree, I think tha I am correct to do so...) > > AFAIX, ppu already have more than one checksum? > > Then it would just be a question to make that yet another checksum. And if *only* this new checksum has changed, then recompile *if* the source is available. > If not, than keep things as they are. Changing the behaviour of the compiler depending on whether or not the source code is available is not acceptable. The only reasonable alternative in my eyes would be to never inline anything in case of mutually dependent units (like Delphi does). Additionally, afaik compiling with -Ur already works around the problem today.

Together with a note or hint, that would also be acceptable. Not havng an optimization, is still better than failing to compile valid code.

There also is http://bugs.freepascal.org/view.php?id=7370 (If I understand correct) About recompiling immediately, until all changes are resolved.

I can see from the comment (and I do agree) that this is not a favourite. But IMHO the following could be acceptable:
- do not recompile by default. (for optimization changes / this will leave those units without the optimization for good)
- Have a command line argument that tells the compiler how often to recompile, if needed. (may require a recompile count field in the ppu)
- only recompile, if the change was due to optimizations (possible if those changes are having their own checksum)

The optimization checksum also would be needed to make the count field work. If only the optimization checksum changed, then the count is increased.
If something else changed, it will follow current behaviour (and if that writes a new ppu, then it resets the count.

Reply by email