- Gpc - gnu.de

Integer Of
by Contestcen＠aol.com 05 Apr '06

05 Apr '06

<< I feel we should use consistent terminology. The SizeOf function returns a number of bytes, the BitSizeOf function returns a number of bits. Using just "size" when the requested parameter is a number of bits, introduces sloppy terminology, which - in general - is a source of programming errors. With IntegerOf(n), one can (implicitely) read IntegerOf(bits), so I think that is OK. Regards, Adriaan van Os >> If you want to be grammatical and consistent, then consider IntegerOfBitSize(n). For my taste, however, this is just too long. Frank Rubin

1 0

(no subject)
by Contestcen＠aol.com 04 Apr '06

04 Apr '06

In a message dated 4/2/2006 10:51:12 AM Eastern Standard Time, ih8mj(a)fjf.gnu.de writes: << BTW, native speakers, with formulation is better, "integer with/of N bits"? >> The description "Integer of N bits" is better. For the declaration, both IntegerOfBits(n) and IntegerWithBits(n) seem awkward. I would prefer the shorter IntegerOf (n) or possibly IntegerOfSize (n). Frank Rubin

3 2

gdb 6.4 patch
by Pascal Viandier 03 Apr '06

03 Apr '06

I installed gdb 6.4 on my Debian x86 box and made the patch for gpc in it. To who may be interested, here it is :-) --- gdb-6.4/gdb/dwarf2read.c 2005-11-03 21:58:31.000000000 -0500 +++ gdb-6.4.new/gdb/dwarf2read.c 2006-03-31 14:15:52.000000000 -0500 @@ -911,6 +911,8 @@ static void read_enumeration_type (struct die_info *, struct dwarf2_cu *); +static void read_set_type (struct die_info *, struct dwarf2_cu *); + static void process_enumeration_scope (struct die_info *, struct dwarf2_cu *); static struct type *dwarf_base_type (int, int, struct dwarf2_cu *); @@ -2648,6 +2650,9 @@ read_enumeration_type (die, cu); process_enumeration_scope (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; /* FIXME drow/2004-03-14: These initialize die->type, but do not create a symbol or process any children. Therefore it doesn't do anything @@ -4031,6 +4036,24 @@ return new_prefix; } +static void +read_set_type (struct die_info * die, struct dwarf2_cu *cu) +{ + struct type *domain_type; + + /* Return if we've already decoded this type. */ + if (die->type) + { + return; + } + + domain_type = die_type (die, cu); + + die->type = create_set_type (NULL, domain_type); + +} + + /* Given a pointer to a die which begins an enumeration, process all the dies that define the members of the enumeration, and create the symbol for the enumeration type. @@ -6113,9 +6136,11 @@ case DW_LANG_Ada95: cu->language = language_ada; break; + case DW_LANG_Pascal83: + cu->language = language_pascal; + break; case DW_LANG_Cobol74: case DW_LANG_Cobol85: - case DW_LANG_Pascal83: case DW_LANG_Modula2: default: cu->language = language_minimal; @@ -6904,6 +6929,7 @@ case DW_TAG_structure_type: case DW_TAG_union_type: case DW_TAG_enumeration_type: + case DW_TAG_set_type: SYMBOL_CLASS (sym) = LOC_TYPEDEF; SYMBOL_DOMAIN (sym) = STRUCT_DOMAIN; @@ -7225,6 +7251,9 @@ case DW_TAG_enumeration_type: read_enumeration_type (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; case DW_TAG_subprogram: case DW_TAG_subroutine_type: read_subroutine_type (die, cu); @@ -7282,7 +7311,8 @@ struct die_info *parent; if (cu->language != language_cplus - && cu->language != language_java) + && cu->language != language_java + && cu->language != language_pascal) return NULL; parent = die->parent;

1 0

Re: Redeclarations of predefined ordinal
by willett 03 Apr '06

03 Apr '06

On 2 Apr 2006, at 10:46, Frank Heckenbach wrote: >> 1. Predefine 2 pseudo-schema types to define signed and unsigned >> integral types: >> >> IntegerWithBits (n) >> CardinalWIthBits (n) >> >> where n is a compile-time constant expression. >> > > BTW, native speakers, with formulation is better, "integer with/of N > bits"? > By my intuition (native speakers vary), clearest would be "Integer of N Bits". Given that the parameter cannot appear in the middle of the predefined identifier, perhaps "IntegerOfBitsize(n)". Others, including (my second choice) "IntegerOfBits(n)" are to me less clear--it suggests that other integers are not made up of bits. Ålso, "of" is more consistent with Pascal use in declarations, "with" has different Pascal semantics. IMHO Willett Kempton

1 0

Re: New (gpc-20060325)
by Adriaan van Os 03 Apr '06

03 Apr '06

>> Waldek Hebisch wrote: >> >>> Adriaan van Os wrote: >>>> Waldek Hebisch wrote: >>>>> BTW: if the same happens with standalone program (without >>>>> modules) >>>>> I should be able to reproduce it. >>>> >>>> Sorry, not clear to me what you mean. >>> >>> I have build a cross-compiler targetting Mac OSX. However, I do not >>> have the complete toolchain (only bare compiler). Without full >>> toolchain I can not compile RTS (the problem really is >>> configure) and >>> also I can not compile anything using GPC module. >>> >>> If you have a testcase which does not use GPC module (directy or >>> indirectly) I should be able to compile it. In fact, if a >>> program uses >>> no extra modules (units) at all debugging becomes easier. >>> >>> I have tried the cross-compiler on various test programs and ATM it >>> happily produced stabs debug info. >> >> OK, I understand, I will look for a testcase (or try to isolate the >> problem). > > Some observations: > > 1. the problem does not occur when running gpc directly rather than > with make, even when passing the same compiler switches (this > sounds like random behaviour and makes me think there is an > uninitialized variable somewhere in the compiler source code) > > 2. the problems disappears when I remove Turbo3 from the USES > clause in aturbo3test.pas > > 3. the problem persists when I reduce the Turbo3 unit to nothing but > > import > > System (MemAvail => System_MemAvail, > MaxAvail => System_MaxAvail); > > Will try to further narrow this down in units/System.pas. The problem disappears when I change type PMemList = ^PMemList; to type PMemList = ^Pointer; in the function MemAvail in units/system.pas. I think that explains it. Apparently the stabs symbol generator doesn't like the type PMemList = ^PMemList declaration. Regards, Adriaan van Os

3 3

Redeclarations of predefined ordinal data types
by Adriaan van Os 02 Apr '06

02 Apr '06

The following two programs are rejected by gpc program redeclare1; type Int16 = Integer attribute( size = 16); Integer = Int16; {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. program redeclare2; type Integer = Integer attribute( size = 16); {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. The following program is accepted: program redeclare3; type Integer = ShortInt; begin writeln( 'SizeOf( Integer) = ', SizeOf( Integer)) end. GPC has been accepting the above first two programs. Gale Paper reminded me that this was (probably) changed in gpc-20050325 with bug fix 20050325: check identifier scopes stricter (az25.pas, fjf1059*.pas). However, I would argue that a type definition like int_nn = Integer attribute( size = nn); does not "use" the Integer type as such in a strict sense. Thus, it can be treated as a special case, accepting the above two programs again. Same for the other predefined ordinal types that accept attribute( size = nn), like Word, Cardinal and Boolean. Regards, Adriaan van Os

4 10

Preprocessor conditional expression support bug
by Gale Paeper 02 Apr '06

02 Apr '06

While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan): program dollars; {$definec dollars $1} {$ifc dollars = 1} {$endc} begin end. Compiling yields the error: dollars.pas:3: conditional expression: parse error If one changes {$definec dollars $1} to {$definec dollars 1}, it compiles with no problem. After some futher testing and digging into the gpcpp.c source code, it looks like the preprocessor doesn't support $ hex constants in conditional expressions for conditional compilation directives. Since $ hex constant usage in preprocessor expressions (including conditional compilation directives) has been supported in MacPascal dialect compilers for well over two decades and it has been a long standing "standard" to use hex nibble formatting convensions for things such as conditional compilation version testing, the lack of GPC preprocessor support for $ hex constants in preprocessor conditional expressions creates MacPascal to GPC code porting problems. (Note: I'm not sure how much further back $ hex constant usage in preprocessor expression has been supported in Apple's USCD Pascal derived compilers. The support was in the first MPW Pascal compiler and may have been supported in the predecessor Lisa Pascal and Apple II compilers but I don't have anything (e.g., documentation) to verify it in the predecessors.) If for no other reason than to facilitate porting of MacPascal dialect codee to GPC, the preprocessor conditional expression support needs to be fixed to allow usage of $ hex constants. Compiler used was Adriaan's pre-built GPC Mac OS X version with specs: Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

3 3

Re: New (gpc-20060325)
by Adriaan van Os 01 Apr '06

01 Apr '06

> Waldek Hebisch wrote: > >> Adriaan van Os wrote: >>> Waldek Hebisch wrote: >>>> BTW: if the same happens with standalone program (without modules) >>>> I should be able to reproduce it. >>> >>> Sorry, not clear to me what you mean. >> >> I have build a cross-compiler targetting Mac OSX. However, I do not >> have the complete toolchain (only bare compiler). Without full >> toolchain I can not compile RTS (the problem really is configure) >> and >> also I can not compile anything using GPC module. >> >> If you have a testcase which does not use GPC module (directy or >> indirectly) I should be able to compile it. In fact, if a program >> uses >> no extra modules (units) at all debugging becomes easier. >> >> I have tried the cross-compiler on various test programs and ATM it >> happily produced stabs debug info. > > OK, I understand, I will look for a testcase (or try to isolate the > problem). Some observations: 1. the problem does not occur when running gpc directly rather than with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code) 2. the problems disappears when I remove Turbo3 from the USES clause in aturbo3test.pas 3. the problem persists when I reduce the Turbo3 unit to nothing but import System (MemAvail => System_MemAvail, MaxAvail => System_MaxAvail); Will try to further narrow this down in units/System.pas. Regards, Adriaan van Os

3 5

gcc-3.4.6
by Russell Whitaker 27 Mar '06

27 Mar '06

Hi Built gpc using just released gcc-3.4.6 and gpc-20060215: passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas both failures got an ICE at the line "with v do" Russ

5 11

Re: the loss of SET_TYPE
by Adriaan van Os 26 Mar '06

26 Mar '06

Forwarding from the gcc-patches mailing list > Gaius Mulley wrote: >> I'm trying to port bring the GNU Modula-2 front end up to gcc-4.1.0 >> and have found out that SET_TYPE has been removed :-) >> >> I see the patch from Dec 2004: >> >> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00670.html >> >> and understand the reason (no front ends in gcc tree use SET_TYPE >> etc). I suppose I'd just like to flag that Modula-2 utilises this type >> during the generation of BITSET types and also large sets (built >> internally from multiple int length SET_TYPEs). But I totally >> understand it might be difficult to justify code which is never run >> (and difficult to test) in the main gcc tree.. >> >> Pragmatically I guess it is best for me to maintain a reversed patch >> which can be applied to a gcc-4.1.0 tar ball which reintroduces this >> TYPE. Any thoughts? > > Many of the front-ends use langauge-specific tree codes to manipulate > types and/or operators specific to their needs. I suspect that > treating the SET_TYPE as a front-end tree is your best bet, and > lowering > it to the appropriate C-like representation (array, struct or integer) > during gimplification is the best way to go. > > Even if SET_TYPE is resurected, I suspect that the lack of constant > folding transformations on these expressions/trees, makes it > unnecessary > to expose their semantics to the early middle-end (and thereby all > other > front-ends), but perhaps there are dwarf2 or similar issues that don't > yet have the necessary hooks, that require this be a "common" tree > code? > > > [As a one-time Modula-2 programmer myself, I'd support Eric's > suggestion. > Wasn't James Morrison investigating issues of GNU pascal integration?] > > Roger Regards, Adriaan van Os

1 0