First, Happy New Year!

I've started investigating FPC support for GLScene (http://glscene.org), and have encountered a few issues:

1)are there any instruction on building FreePascal? I've got the CVS sources, tried several makefiles and .bat, browsed the READMEs, but couldn't get a compile to complete (this is under Win32, using the 1.9.0 release).

2)while compiling my units, I bumped on a compiler crash (now reported in the bugs with a sample unit), then managed to somehow work around it, but now the compilation fails with no errors. Ie. FPC's return value indicates a failed compile, and the .exe is not generated, but no error is listed. When compiling with '-va', nothing suspicious is listed and the ld.exe stage is reached. Any hints on extra verbose options that could shed more light?

3)while waiting for Lazarus, I've started work on an IDE expert for Delphi 7, which add FPC compile and options menu to the IDE. The compile side is now more or less operationnal (incl. error hyperlinks), and I've started investigating the debug side. Full debug support is quite certainly out of reach (and IMO better left to Lazarus), however ASM based debugging is possible (using the CPU view and Delphi's AttachTo command). What I'm after would be adding a few helper functions to convert pascal file/line number to EXE offset and vice-versa. This would allow basic breakpoint and trace support. Any suggestions on the most suitable debug format for this purpose that FPC 1.9.0 would already generates? Any links/docs on that format? (the expert is available from the Utilities directory of GLScene CVS at sourceforge, if an FPC guru wants to pick oversights and errors with how things are done/displayed...)

4)the '-B' option is listed for Build support, but doesn't seem to rebuild units if their code (file timestamp actually) hasn't changed. Is this a misunderstanding from my part or a bug?

5)do the snapshots include binaries, and if so, from which mirror should I download? (tried a few links from the website, but all failed)

Other than that things went quite smoothly, I haven't compiled/run anything really complex yet, but the extra hints/warnings of FPC allowed to catch a few bugs Delphi had missed, which is always nice :)

Eric

http://www.stack.nl/~marcov/buildfaq.pdf

That could mean that the error was in the linker. Don't forget that FPC calls the linker, so the linkers errorcode propagates to fpc's.

Linker errors are usually displayed though.

What I'm after would be adding a few helper functions to convert pascal file/line number to EXE offset and vice-versa. This would allow basic breakpoint and trace support. Any suggestions on the most suitable debug format for this purpose that FPC 1.9.0 would already generates?

I'm no expert on this, but afaik FPC generates stabs debug format, like gcc does. By simply compiling with -gl and -a you can see the debug info in the generated assembler (.s) file.

Any links/docs on that format? (the expert is available from the Utilities directory of GLScene CVS at sourceforge, if an FPC guru wants to pick oversights and errors with how things are done/displayed...)

gcc docs, I don't know if there is documentation on FPC extensions/mappings.

4)the '-B' option is listed for Build support, but doesn't seem to rebuild units if their code (file timestamp actually) hasn't changed. Is this a misunderstanding from my part or a bug?

No idea. I never use that :_)

Note that -Ur could be the reason for this. -Ur compiled units are not recompiled

5)do the snapshots include binaries, and if so, from which mirror should I download? (tried a few links from the website, but all failed)

Yes, but there will be a formal beta again soon. This beta will use more Delphi compatible register calling conventions, which might be important for what you are doing, specially the debugging.

I use ftp://freepascal.stack.nl

Other than that things went quite smoothly, I haven't compiled/run anything really complex yet, but the extra hints/warnings of FPC allowed to catch a few bugs Delphi had missed, which is always nice :)

:_)

My guess is that the compiler wants to recompile a certain unit (perhaps the system unit) and cannot find its source code. -B works perfectly for me, but I do have source code for all units installed.

Daniël

Eric,
It never fails every time I start looking at a project you are right their also :). So what arn't we working on that we can stick our noses into?

Jeremy

_________________________________________________________________ Worried about inbox overload? Get MSN Extra Storage now! http://join.msn.com/?PAGE=features/es

Thanks Marco & Daniel (grouped reply and new question).

I'm no expert on this, but afaik FPC generates stabs debug format, like gcc does. By simply compiling with -gl and -a you can see the debug info in the generated assembler (.s) file.

Ok, I've quickly , should be possible to make it
work both ways.

My guess is that the compiler wants to recompile a certain unit (perhaps the system unit) and cannot find its source code. -B works perfectly for me, but I do have source code for all units installed.

Issue is no longer present with 1.9.1 (14/12 binary).

New question: is -O2 supposed to perform uncertain optimizations as well? I've got a bit of code (OpenGL teapot) that behaves correctly when compiled with -O1,
and is somewhat visually garbled with -O2. I tried to simplify the case a bit, but that would
make the issue go away. The code in question is made of several imbricated loops massaging
values in 3 dimensionnal arrays.
Is it a known issue of the beta or would it be worth it trying harder to simplify for a test case?

Eric

Eric Grange wrote

New question: is -O2 supposed to perform uncertain optimizations as well?

No.

That's usually the case with optimizer bugs, as they highly depend on the context.

The code in question is made of several imbricated loops massaging values in 3 dimensionnal arrays. Is it a known issue of the beta or would it be worth it trying harder to simplify for a test case?

It would be very nice to have a test case, yes.

Thanks,

Jonas

It would be very nice to have a test case, yes.

Submitted. Could remove objects, OpenGL references and all unit dependencies, besides "offending" code, only fat const arrays remain (a soup of indices...). Test proggy checks only one of the values, though at least 3/4 of them are "visually" incorrect.

Eric