ISO 7185 Failures [updated]

Waldek Hebisch hebisch at
Fri Nov 23 00:45:35 CET 2007

Scott Moore wrote:
> {******************************************************************************
> GPC standard ISO 7185 test failures
> The following failures were found:
> ===============================================================================
> C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas
> fails.pas:115: error: ISO 7185 Pascal allows only simple constants
> fails.pas: In main program:
> fails.pas:136: error: this use of packed array components is an extension of
> fails.pas:136: error:  Borland Pascal, traditional Macintosh Pascal
> fails.pas:137: error: this use of packed record fields is an extension 
> of Borland
> fails.pas:137: error:  Pascal, traditional Macintosh Pascal
> ===============================================================================
> None of these are valid failures, or indeed even have a reasonable 
> explaination
> in the standard. Also, all of these used to work fine in GPC:
> GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special)
> See the testing details for that compiler:

Yes, they are plain bugs (too eager error checks).  The first one
(string constants) should be fixed in versions starting from
gpc-20060215.  The patch below (to gpc-20070904) should fix the
two other.

> Now, with "--standard-pascal" off:
> ===============================================================================
> C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas
> C:\GPC\usr\test>fails
> 1
> 10
> 100
> 2147483647
> True
> False
> 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> '
> ===============================================================================
> Items:
> 1. Integer field default appears to be "1".
> This appears to indicate the default fields for integer is set to 1. This is
> technically valid, but clearly preverts the intent of the language. The
> "Pascal users manual and report" shows several examples of the field for
> integer being clearly set to the maximum size of integer. Ie., for a maximum
> integer of 11 digits including the sign (for +/-2147483647) the default 
> should
> be 11 digits for integer. The output of numbers in collumns under the
> assumption that they would correctly spaced for all integers would fail 
> under
> the current GPC (see again the several examples in the "report"). I have had
> the discussion with another implementor, and this treatment of defaults 
> falls
> under "techically valid (by the ISO 7185 standard), but would break examples
> of the original Pascal as formulated by Wirth", which I consider a quality
> issue.
> I tried this also with the "--standard-pascal" flag on (by commenting 
> out the
> error causing statements), and got the same result.
> Again, this used to pass.

Hmm, after commenting out the two offending statements in your program
and using "--standard-pascal" flag I get:

'too much<eoln> too soon<eoln> ' s/b 'too much<eoln> too soon<eoln> '

The same using the program as-is and patched gpc-20070904.  In
both cases gpc run on AMD64 machine under Mandrake 9.2 Linux.

> 2. Boolean outputs nonstandard.
> There is no explaination for the values of boolean. Since they are 
> treated as
> the strings "true" or "false", there is no possible default field that would
> deliver the results shown. If the default were 5 (size of 'false') the 
> result
> would be:
>   True
> False
> For 4 (size of 'true') it would be:
> True
> Fals
> I tried this also with the "--standard-pascal" flag on (by commenting 
> out the
> error causing statements), and got the same result.
> Again, this used to pass.
> 3. Last line in file without "eoln" not corrected as required by standard.
> In ISO 7185 " File types" lines without proper eoln are referred to
> as "partial lines", and are stated not to occur. In effect, the 
> implementation
> must either make sure that an eoln is always generated at the end of the 
> file,
> or that on read, an eoln is essentially inserted if missing at the end 
> of the
> file. In effect, a text file must be completely empty or be structured as a
> series of whole lines, including an eoln at the end of each line.
> I don't believe this ever passed in GPC, but I was told it would be fixed
> in later revisions.

IIRC the promise was that this will work with "--standard-pascal".
I belive that there was no intent to change default behaviour.

> Here is a -v dump on the GPC used:
> gpc version 20051116, based on gcc-3.4.4

I do not have binary gpc-20051116 at hand, but I belive that except for
the first error it should behave the same as gpc-20060215 or gpc-20070904
(there were a number of ISO compilance fixes in gpc-20060215, but none
should affect other problems).  

The patch follows:

--- p/predef.c	4 Sep 2007 06:02:58 -0000	1.20
+++ p/predef.c	22 Nov 2007 23:37:32 -0000
@@ -422,7 +422,10 @@
 actual_set_parameters (tree val, int reference)
   tree domain = TYPE_DOMAIN (TREE_TYPE (val)), addr;
-  int addressable = mark_addressable (val);
+  unsigned long save_pascal_dialect = co->pascal_dialect;
+  int addressable = mark_addressable2 (val, 1);
+  co->pascal_dialect = ANY_PASCAL;
   gcc_assert (addressable);
   /* Callers now handle the constant empty set. */
@@ -435,6 +438,7 @@
     addr = build_pascal_unary_op (ADDR_EXPR, val);
     addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (val)), val);
+  co->pascal_dialect = save_pascal_dialect;
   return tree_cons (NULL_TREE, addr,
     tree_cons (NULL_TREE, convert (pascal_integer_type_node, TYPE_MIN_VALUE (domain)),
       build_tree_list (NULL_TREE, convert (pascal_integer_type_node, TYPE_MAX_VALUE (domain)))));

                              Waldek Hebisch
hebisch at 

More information about the Gpc mailing list