Re: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

2006-03-11 Thread Michalis Kamburelis

Den Jean wrote:

Hi,

I have a strange problem. My Qt4 demo program worked 
fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2.

Debugging shows that indeed a div by zero is done within
the Qt4 lib. However with FPC 2.0.0 or using C++ code the library
isn't bothered with the div by zero. When I use FPC 2.0.2 however
it is.



Maybe it was FPC 2.0.0 bug (that was fixed in the meantime) that caused 
this SIGFPE inside qt to be ignored ? AFAIK it was always the intention 
of FPC that if used library causes a signal like SIGFPE, this signal 
*will not be ignored* and will cause our program to fail with some 
exception.


Maybe you can workaround this with Set8087CW, just like it has to be 
workarounded for OpenGL under Windows (see 
[http://www.freepascal.org/bugs/showrec.php3?ID=3955]). Just add 
Set8087CW($133F); at the beginning of your program (or even right 
inside qt unit initialization) and see if it helps.


(Note that I'm writing this without any knowledge of qt or your testcase 
--- I just thought that it may be helpful, sorry if it's not relevant :) ).


Michalis
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Dump_Stack broken in fpc 2.1.1

2006-03-11 Thread Vincent Snijders

Vincent Snijders wrote:

Hi,

Line info is broken in fpc 2.1.1 on win32. I have created the attached 
test program.


Running the program gives:
C:\lazarus\bugs\fpc\lineinfoproject1.exe
In test

opening the program in gdb gives.
(no debugging symbols found)...

Running the program compiled with fpc 2.0.3 gives:
C:\lazarus\bugs\fpc\lineinfoproject1.exe
In test
  $0040109D  main,  line 17 of project1.pas



Peter made some fixes yesterday, but that was not enough. I still don't 
get the backtrace.


If I compile with -XS, gdb doesn't give errors.
If I use the default linking settings, I get the following warnings:

During symbol reading...function `_FPC_MAINCRTSTARTUP' appears to be 
defined out
side of all compilation units...function `fpc_get_output' appears to be 
defined
outside of all compilation units...function 
`fpc_write_text_pchar_as_array' appe
ars to be defined outside of all compilation units...function 
`fpc_iocheck' appe
ars to be defined outside of all compilation units...function 
`fpc_writeln_end'
appears to be defined outside of all compilation units...function 
`GET_FRAME' ap
pears to be defined outside of all compilation units...function 
`DUMP_STACK' app
ears to be defined outside of all compilation units...function 
`fpc_initializeun
its' appears to be defined outside of all compilation units...function 
`DO_EXIT'
 appears to be defined outside of all compilation units...function 
`SYSTEM_init'

 appears to be defined outside of all compilation units...

Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Problems with fixes_2_0 rev. 2824

2006-03-11 Thread Martin Schreiber
On Friday 10 March 2006 13.06, Peter Vreman wrote:
  Hi,
  Are there any known problems with FPC fixes_2_0 rev. 2824?
  I get many AV's, error 204's and other strange things.

 There are no regressions in the building and in the testsuite.

The problem is probably in rtl/i386/i386.inc:

Procedure fpc_AnsiStr_Decr_Ref (Var S : Pointer); 
[Public,Alias:'FPC_ANSISTR_DECR_REF']; compilerproc; nostackframe; assembler;
[]
.Lj3610:
movl%edx,%eax
callcpudeclocked
movb%al,%al
je  .Lj3605
.Lj3620:
movl(%esp),%eax
movl(%eax),%eax
subl$8,%eax
callFPC_FREEMEM_X
movl(%esp),%eax
movl$0,(%eax)
.Lj3618:
.Lj3605:
.Lj3596:

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] add external links to fpdoc generated documents

2006-03-11 Thread Tomas Hajny
On 10 Mar 06, at 15:48, Marco van de Voort wrote:
  On Fri, 10 Mar 2006, Vincent Snijders wrote:
  
   Hi,
  
   I would like to add a link to external documentation in a fpdoc generated 
   document file. Is this possible.
  
   For example:
   On 
   http://lazarus-ccr.sourceforge.net/docs/lcl/xmlpropstorage/txmlpropstorage.html

   I would like a See also link to 
   http://wiki.lazarus.freepascal.org/index.php/TXMLPropStorage. This is a 
   wiki 
   document that contain more explanation, images and has a place for user 
   comments.
  
  It is currently not possible. The reason is that fpdoc can also
  be used to generate PDF or Latex or plain text or RTF docs, and these
  don't support links.
 
 Actually, PDF (and latex package hyperref) support links. Both to other PDF
 and HTTP iirc.

... and RTF probably supports links too, I guess. 
So what is left is plain text, and that just 
needs some sensible way how to mark references.

Tomas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] add external links to fpdoc generated documents

2006-03-11 Thread Marco van de Voort
document that contain more explanation, images and has a place for user 
comments.
   
   It is currently not possible. The reason is that fpdoc can also
   be used to generate PDF or Latex or plain text or RTF docs, and these
   don't support links.
  
  Actually, PDF (and latex package hyperref) support links. Both to other PDF
  and HTTP iirc.
 
 ... and RTF probably supports links too, I guess. 
 So what is left is plain text, and that just 
 needs some sensible way how to mark references.

(note that I meant links that cross file bounderies)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] OS aware RTL proposal

2006-03-11 Thread Daniël Mantione


Op Fri, 10 Mar 2006, schreef Ales Katona:

 http://www.freepascal.org/wiki/index.php/OS_aware_RTL
 
 Tell me what you think

I don't like to do the abstraction at the syscall level, but one level 
higher, i.e. the Tstream implementation. The reason is that the operating 
system abstraction happens at this level:
- OS abstraction wis present here.
- Emulating missing system calls is often much more inefficient than 
  a higher level workaround.

Adding an extra layer of abstraction without a good technical reason greatly 
increases the danger of overdesign and code bloat.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel