Gpc

gpc@gnu.de

5400 discussions

SERIOUS GPC BUG!!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

If you look at the time stamp of this message you'll see that it was written at 2:30am. :-( I have just (hopefully) isolated a VERY SERIOUS GPC bug. Every time I compiled my programs with "-g" (debugging) the compiler crashed with a SIGSEGV. With a bit of late-night detective-ing, I think I figured WHY this happens! I managed to get an assembly dump of my program without the compiler crashing. The "-g" option wrote ".def _(null) ... " to the assembly output. Somehow, some NULL strings have crept into GPC.... :-( Whats even scarier is that the number of _(null) defs varied between different compiles! When "--automake" is enabled, the compiler crashes with a SIGSEGV. I dont think "AS" was ever invoked because it usually complains about those _(NULLS). I am using GPC-970510 for DJGPP 2.01. Now, I desperately need some sleep!! Good night :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: `Word' data type
by Orlando Llanes 13 Jun '97

13 Jun '97

Why not just make it 16 bits on the Intel platform? On certain computers, like the Macintosh I believe, a Byte is the size of a PC Word. > behaviour. In this case I would appreciate suggestions how to rename > all GPC Integer types above (which I wouldn't like to do because I find > the above quite consistent). When I was playing with GPC doing the Port inline assembly stuff, I delcared the types as follows: ... TYPE ShortInt = __byte__ Integer; { 8 bits } Int = __short__ Integer; { 16 bits } LongInt = __long__ Integer; { 32 bits } Byte = __unsigned__ ShortInt; { 8 bits } Word = __unsigned__ Int; { 16 bits } DWord = __unsigned__ LongInt; { 32 bits } ... Or soemthing to that effect. Altho I'd prefer to re-declare the Integer as a PC Integer, I didn't because I don't like overriding the default type. I think that there should be a compiler directive to generate code, or maybe typecasting should be implemented, in case someone writes data from a 32-bit word to prevent it from being read into a 16-bit word. I like Borland Style Type-Casting because it's logical, for example: VAR MyDword : DWord; MyLInt : LongInt; BEGIN MyLint := -23; LongInt( MyDword ) := MyLint; END. Not much of a logical example, but hopefully it shows you what I mean :} See ya! Orlando Llanes

1 0

Re: `Word' data type
by Bernhard Tschirren 13 Jun '97

13 Jun '97

At 05:24 PM 13/06/97 +0200, you wrote: >AFAIK, a "word" is defined to be the "natural" unit of the computer, >but maybe this definition has changed since I have learned it. If the >definition of a word is indeed "16 bits" now, I should change GPC's > DONT CHANGE IT! The word size of a computer is indeed the size of the "natural" unit that the computer works with. GPC is a 32-bit compiler for 32-bit machines (except the 64-bit ALPHAS) so the type "WORD" should be 32-bits! ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

NOT A BUG Report :-)
by Bernhard Tschirren 13 Jun '97

13 Jun '97

Whew, this is not another bug report! :-0 Its a suggestion for a feature that I'd like in GPC. Sometimes I have to link in 'C' (ugh) code with GPC. Usually this 'C' code has been compiled into a ".a" library. Is there any way I can tell GPC to automatically link this ".a" file with my program using automake? At the moment I have to type: GPC program.pas -o program.exe library.a --automake Is there any way another compiler define could be added into the source of a unit to tell automake that "library.a" must be linked with the program. Something along the lines of {$LINK "library.a"} or the Borlandish {$O libary.a} I know that this is REALLY DIFFICULT to do because the unit must somehow tell the calling GPC that it must also link the ".a" library. But something like this is already done using units... Please tell me if Im setting my expectations of GPC a little too high :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Exported Type BUG!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

This is not really a serious bug because it only generates a warning and the code works OK. Its very complicating to explain, so just have a look at the (BIG) example below: {--TYPES.PAS-----------------------------------------------} Unit Types; Interface Type TRecord = Record Data : Word; End; Implementation End. {--PROC.PAS-----------------------------------------------} Unit Proc; Interface Uses Types; Procedure TheProc(Var Data:TRecord); Implementation Procedure TheProc(Var Data:TRecord); Begin End; End. {--BUG.PAS------------------------------------------------} Program Bug; Uses Types,Proc; Var Data : TRecord; Begin TheProc(Data); { Line 8 } End. {---------------------------------------------------------} The compiler spews out the following warning message when compiling: bug.pas: In function `program_Bug': bug.pas:8: warning: passing arg 1 of `Theproc' from incompatible pointer type {--------------------------------------------------------} The pointer is obviously NOT incompatible since its the SAME TYPE. As an aside: If "TheProc" is a method of an object, the compiler reports that the incompatible pointer type is passed in "arg 2" instead of "arg 1". :-) {--------------------------------------------------------} Now, this is what I call a bug report! Its HUGE, and the bug isnt even very serious! :-) Good Work ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Record Initialisers GONE WRONG!?!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

Hmm, this is very strange! {---------------------------------------------------} Type TRecord = Record First : Word; Second : Word; End; Var Single : TRecord Value (10; 1000); { This works OK } Many : Array[1..2] Of TRecord Value ((10; 1000), { Does NOT compile! } (10; 1000)); Begin End. {---------------------------------------------------} I am using GPC-970510 for DJGPP 2.01. This might be a known bug since I read somewhere that arrays are not fully implemented yet. Cya l8r, and happy debugging :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Enumerated types bug!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

WOW, Im on fire... I found another bug. I think this might a known bug. Enumerated types are not exported in the GPI file. For example: {---------------------------------------------------------------------} In TYPES.PAS: Unit Types; Type TDays = (Monday,Tuesday); ... In BUG.PAS: Uses Types; Var TheDay : TDays; { This is OK } Begin TheDay := Monday; { Monday is undefined! } End. {---------------------------------------------------------------------} Thanks ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Problems with OBJECTs
by Bernhard Tschirren 13 Jun '97

13 Jun '97

The program below causes a Segment Violation (SIGSEGV) during compilation using GPC-970510 for DJGPP 2.01. {-----------------------------------------------------------------------------} Type PEntry = ^TEntry; TEntry = Record Prev : PEntry; { Linked List } Data : Word; End; TObj = Object Index : PEntry; Procedure DisposeIndex; End; Procedure TObj.DisposeIndex; {$M START} Procedure DisposeEntry(Var Entry:PEntry); {$M STOP} Begin If (Entry <> Nil) Then Begin DisposeEntry(Entry^.Prev); Dispose(Entry); Entry := Nil; End; End; Begin DisposeEntry(Index); End; Begin End. {-----------------------------------------------------------------------------} The problem does not occur if the procedure "DisposeIndex" is NOT a method of an object. If "DisposeIndex" is declared as a normal procedure then the program compiles OK. WEIRD!?!? I narrowed the problem down to the definition of the nested procedure "DisposeEntry". The second {$M} is never displayed. Tschuess ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Inline Assembler Problems
by PredatorZeta 13 Jun '97

13 Jun '97

According to Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de>: > According to PredatorZeta: > > > > I receive the same invalid 386 instruction error message. > > Mmmh...I investigate on this. I have found this (probably) bug in the > > "as": > > > > movl $_TheArray(,%%esi,4), %%eax > > > > and > > > > movl %%eax, _TheArray(,%%esi,4) > > > > is accepted from the assembler without any problems. But sadly: > > > > movl %%eax, $_TheArray(,%%esi,4) > > > > is refused. If this isn't a bug, anyone know the reasons? > > I do not really know, but I guess that it's the following: > The `$' denotes a constant value, something without a `$' denotes > a memory reference. Not exatly, because $_TheArray is however an immediate value (displacement). The "AS" might accept this, because $_TheArray can be managed really as an immediate. Besides, logically if "movl $_TheArray(,%%esi,4), %%eax" is OK, movl %%eax, $_TheArray(,%%esi,4) MUST be OK. > But if it is so, I have problems to imagine > what "movl $_TheArray(,%%esi,4), %%eax" means ... except if the > `movl' is silently translated to a `leal'. > Could please somebody check it out? Here you are Peter! I have disassembled the object file outputted by "AS". "movl $_TheArray(,%%esi,4), %%eax" is showed in Intelly way as "mov eax, DWORD PTR [esi*4+_TheArray]" without any lea. More probably is an "AS" parsing problem. If it found an $ at the beginning of the DEST operand, it assume that you tried to move something in an immediate value, and emit the error message. But it isn't necessary an invalid opcode!!!! Cya. PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Speeding up GPC
by Peter Gerwinski 13 Jun '97

13 Jun '97

Hello, folks! I just compiled a Unit with a 5000-line interface part with GPC. 50 (fifty) seconds on a Pentium 166. :-( That's about a factor of 100 (!) slower than Borland Pascal 7.0 on the same host. :-( :-( Using (*$M Message *) directives, I found out that 90% of the time was spent in writing the GPI file (this is done when `Implementation' is read): Unit Foo; Interface (* ... Many constant definitions ... *) (*$M Writing GPI file ... *) Implementation (*$M GPI file written. *) (* ... other stuff *) end. I think I know already why this takes so long, so you can expect this bottleneck to vanish in the future. Now comes my request: Please help to find similar bottlenecks in GPC! To do so, you can compile your longer programs with the `-Q' option which makes GPC output the name of each function it compiles, and/or you can scatter (*$M message *) directives about your source like I did in the example above. As written in the DJGPP FAQ, GCC compiles 250 (-O2) to 430 (-O0) lines per second on an i486DX2-66. Since Pascal is stricter than C, GPC should not be slower! Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc