This is Info file ./gpc.info, produced by Makeinfo version 1.67 from
the input file ./gpc.texi.

   This file documents the use and the internals of the GNU Pascal
compiler.

   Copyright (C) 1988, 1996 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.


File: gpc.info,  Node: How to Contribute,  Next: GPC notes,  Prev: GPC Bugs,  Up: Top

How *you* can contribute to GNU Pascal
**************************************

   Below you can find a list of jobs which should be done for GNU
Pascal.  In cases where somebody is already working on it, the name of
that person is written behind the job's description together with the
status of the project; e-mail addresses are given below.

   If there is already a name behind a job, this does *not* mean that
you shouldn't do that but just that you should get in contact with that
person if you would like to contribute to that field.

   Don't forget to join the GPC mailing list, `gpc@hut.fi'.  To
subscribe, write to
       gpc-request@hut.fi

   Welcome to the GNU Pascal development team!

List of jobs
============

     Overall coordination                    Juki, Peter         works ;-)
     Coordination with GCC developers         ?                   ?
     Merge into GCC main distribution        JanJaap             planned
     
     ISO 7185 Standard Pascal                Juki                Level 0 works
     ISO 10206 Extended Pascal               Juki                90%
     Object Pascal                            ?
     Borland Pascal 7.0                      Peter               80%
     Delphi                                   ?
     Pascal-SC                               Peter               please help!
     Compiler options to force one standard  Peter               planned
     
     Win32 version                           JanJaap             works
     
     Documentation                           JanJaap, Peter      existing ;-)
     
     Type checking                           Juki                 ?
     Automatic make                          Peter               works
     Objects: C++ code compatibility         Peter               planned
     Objects: multiple inheritance           Peter               planned
     PXSC module syntax                      Peter               planned
     Procedure overloading                   Peter               planned
     Precompiled module interfaces           Peter               works
     
     Run time system                         Juki                works
     I/O error handling                       ?
     Turbo compatible DOS, CRT, ...           ?                  ask Peter
     Turbo compatible Graph                  Sven                70%
     Turbo Vision compatible library          ?
     POSIX library (replacement for DOS)     Berend              to be ported
     Replacement for (parts of) CRT          Peter               beta (BO5)
     Replacement for Graph                   Peter               planned (BO5)
     Replacement for Turbo Vision            Peter               planned (BO5)
     
     Adaption of the RHIDE IDE (for DOS)     Robert              beta
     Adaption of the XWPE IDE (for UNIX)      ?
     Pascal mode for GDB, the GNU Debugger   JanJaap             planned

List of done jobs :-)
=====================

     EMX version (DOS and OS/2)              Peter               works
     DJ version (DOS)                        JanJaap             works
     Cross compilers Linux -> others         JanJaap             works
     
     Installation instructions               JanJaap, Peter      done

List of contributors (in alphabetical order)
============================================

     Berend              Berend de Boer, Nederlands
                         <berend@pobox.com>
     
     JanJaap             Jan-Jaap van der Heijden, Nederlands
                         <j.j.vanderheijden@student.utwente.nl>
     
     Juki                Jukka Virtanen, Finland
                         <jtv@hut.fi>
     
     Peter               Peter Gerwinski, Germany
                         <peter.gerwinski@uni-essen.de>
     
     Robert              Robert Hoehne, Germany
                         <robert.hoehne@mathematik.tu-chemnitz.de>
     
     Sven                Sven Hilscher, Germany
                         <sven@rufus.central.de>


File: gpc.info,  Node: FPK Pascal,  Next: GPC Bugs,  Prev: Borland Pascal,  Up: Top

FPK Pascal and GNU Pascal--a comparision
****************************************

   by Florian Klaempfl <fnklaem@cip.ft.uni-erlangen.de>
and Peter Gerwinski <peter.gerwinski@uni-essen.de>
22 September 1996

                  FPK Pascal                        GNU Pascal
                  ----------                        ----------
     
     aim:         free Borland compatible           free portable
                  32-bit Pascal compiler            32-bit Pascal compiler
     
     version:     0.6.4                             2.0 (corresp. to GCC 2.7.2.1)
     
     operating    DOS (DJGPP), OS/2, Linux          DOS (DJGPP), DOS (EMX),
     systems:                                       OS/2 (EMX), Win95/NT (CygWin),
                                                    arbitrary UNIX systems
     
     written in:  Pascal, TP Syntax                 C
                  (compiles itself)
     
     source:      900 kB                            6.4 MB plus source of GCC (27 MB)
                                                    (including documentation etc.)
     
     language     Borland Pascal 7.0,               ISO 7185, ISO 10206,
     standard:    (parts of) Delphi II              (most of) Borland Pascal 7.0
     
     extensions:  function overloading              user-definable operators
     
     home server: http://home.pages.de/~FPK-Pascal/ http://home.pages.de/~GNU-Pascal/
                                                    ftp://kampi.hut.fi/jtv/gnu-pascal/
     
     license:     FreeWare (GPL)                    FreeWare (GPL)
     
     author:      Florian Klaempfl, Germany         Jukka Virtanen, Finland
                  fnklaem@cip.ft.uni-erlangen.de    jtv@hut.fi


File: gpc.info,  Node: GPC notes,  Next: PVS,  Prev: How to Contribute,  Up: Top

GPC--Gnu Pascal Random Notes
****************************

   * a bison parser for GPC

     (the parser is a ISO 7185 standard pascal parser with extensions
     (like casts, type of, address of vars, inline, return, break,
     continue, otherwise and so on...)

   * code (glue) that can be used to convert the Pascal way of defining
     things to use routines in a modified `c-decl.c'.  This mainly does
     re-ordering of the data structures. The glue lives in
     `gpc-parser.y' or in `gpc-util.c'.

   * VAR parameters for Pascal routines

     Now done with REFERENCE_TYPE. Until the REFERENCE_TYPE is
     implemented as in C++, I just get rid of this type as soon as
     possible by converting it to POINTER_TYPE in as few places as
     possible. Currently affects `gpc-parse.y', `actualparameterlist()'
     and `default_conversion()'.

   * redeclaration of standard identifiers (NOT reserved words) This
     requires a change in `tree.def' sometime in the future; currently
     I am mis-using Tiemann's FRIEND_DECL TREECODE which looks exactly
     like my KNOWNID_DECL would look like.  So maybe there is no need
     to add it at all for Pascal.

   * run time system & routines that generate calls to the rts.  The
     old one Antti Louko & I originally wrote back in -85 when I ported
     another Pascal compiler (Pax) to BSD Vax.  Pax compiler is written
     in Pascal, and it runs on Twenex and Unix. (Very good error
     reporting capabilities.) More info on request.

   * WITH statement should work properly. No information of WITH is
     currently given to the debugger.

   * variant records

     These should work. Added routine find_field() that returns a chain
     of TREE_LIST nodes and modified build_component_ref() to work as
     follows: When `gpc-parse.y' builds a variant record, it constructs
     an unnamed RECORD_TYPE containing the possible variant selector
     field and an unnamed UNION_TYPE node. `When find_field()' sees
     unnamed RECORD_TYPE or UNION_TYPE nodes implicitely propagates to
     the inner layer of the definition. It then returns the TREE_LIST
     chain of this propagation and this is modified to a series of
     build(COMPONENT_REF,...) for all propagated RECORD_TYPE nodes,
     which the rest of gcc will handle. This does NOT YET check variant
     access errors...  When thinking about it, it does not check very
     many other things either, so maybe no one will notice this :-)

   * Arrays with non-zero lower bound

     Required some changes to `expr.c.'


File: gpc.info,  Node: PVS,  Next: Set types,  Prev: GPC notes,  Up: Top

A list of failed Pascal Validation Suite Conformance tests by
*************************************************************

   		GPC-1.2 (GCC-2.7.2)

   Last modified: Sun Dec 10 00:58:14 1995 Run by: Juki <jtv@hut.fi>

   Number of validation suite tests run: 199 Only LEVEL-0 tests run (no
conformant arrays).

   All programs have been named as `pDDD.pas' (DDD = three digits)
Otherwise my naming convention does not mean anything.

   All tests run with and without `-g' and with/without `-O' and
with/without `-O6' Only the tests that fail are mentioned, otherwise
they all pass.

     	TEST	WHAT HAPPENS
     	----    ------------
     i486	Mach 3 (CMU UX): 	All conformance tests pass.
     
     rs-6000 Aix 3.2.5: 		All conformance tests pass.
     
     mips	Ultrix 4.3:		All conformance tests pass.
     				*** Tested with gpc 2.5.7 only
     
     alpha:	OSF 1/V3.2c:		All conformace tests pass.
     
     	Important: DO NOT USE -O switch with the alpha GPC
     		   until the problems are fixed!!!
     
     	*** With -O the following FAIL
     	*** This is ridiculous!!! They worked before...
     	p004	FAIL
     	p029	FAIL
     	p069	FAIL
     	p072	FAIL
     	p075	FAIL
     	p076	FAIL
     	p098	FAIL
     	p108	FAIL
     	p110	FAIL
     	p111	FAIL
     	p113	FAIL
     	p128	FAIL
     	p136	FAIL
     	p142	runtime error
     	p157	FAIL
     	p164	FAIL
     	p167	FAIL
     	p171	FAIL
     
     	*** But with -O6 the following are compiled incorrectly.
     	*** (i.e. they compile but produce incorrect results).
     	*** Don't use -O6 on alpha until the bugs are fixed.
     	*** These have never worked.
     	*** I have not checked the reason for these:
     	p029	FAIL
     	p095	FAIL
     	p110	FAIL
     	p111	FAIL
     	p117	Loops
     	p157	FAIL
     
     sparc	Solaris 2.3:		*** Tested with gpc 2.6.3 only
     	003	Signal 11 received by the compiler when -O (optimized)
     
     HP-PA:	HP-UX 9.03 / --with-gnu-as
     	All other tests pass, except 003:
     
     	003	Compiler: Unrecognized insn. Compiler abort().
     		(PASS with -O6)
     
     		p003.pas:262: internal error--unrecognizable insn:
     		(jump_insn 730 728 732 (set (pc)
     		        (if_then_else (gt (const_int 0)
     		                (reg:SI 259))
     		            (label_ref 766)
     		            (pc))) -1 (nil)
     		    (nil))
     		p003.pas:262: internal gcc abort
     		p003.pas did not compile
     
     		This looks more like a generic GNU compiler bug than
     		a bug in GPC code...
     
     		003 is the PVS test 6.1.1-3.


File: gpc.info,  Node: Set types,  Next: GPI files,  Prev: PVS,  Up: Top

Information of the SET_TYPE implementation in GPC.
**************************************************

   Juki <jtv@hut.fi>
Last modified: Wed Sep 22 11:47:27 1993

   * Memory format

     `Set of T' type nodes are represented as bit vectors, one bit for
     each element. The SET_TYPE objects contain only the bits necessary
     to represent the set type PLUS the padding to align the objects to
     the nearest word boundary. Thus, there may be unused bits in front
     and after the end of otherwise contiquous bit vector that
     represents all the elements of the set.

   * Sparse sets are not implemented

     there is no concept of "sparse sets", which I thought might be
     nice for things like `[ -maxint, maxint ]' to work. Maybe someone
     implements this later, e.g. with a list of set fragments or a list
     of set elements.

   * Negative bounds for sets do not work

     Perhaps this could be done by subtracting the low bound from all
     set elements before storing them to bitvectors. (This might cause
     complications with set constructors in expressions?)

   * Set of integer

     This is a problem currently. It should be dynamic, but currently
     the bounds are always set to 0..255 for an unlimited integer set.

     First aid: implement a switch that specifies the bounds of such
     sets. The value should be passed to `setop.c' in some language
     independend way. (Global variables :-)

   * Set operations:

     With a massive hack attack I converted all set operations to
     inline code. It is not perfect yet, but now it passes all set
     tests I have. Yet, the code contains unimplemented parts (see
     `setop.c').

   * List of set operations:

     CARD_EXPR:      returns the number of set elements currently in the set
                     Extended Pascal.
     
     UNION           SETC := SETA + SETB; union of the sets
     BIT_OR_EXPR
     
     DIFF            SETC := SETA - SETB; If in A, but not in B.
     BIT_ANDTC_EXPR  (and `tc_optab' has vanished from gcc-2, so this
                     will be done ``SETA and (not (SETB))'')
     
     INTERSECTION    SETC := SETA * SETB; If in A and in B
     BIT_AND_EXPR
     
     SYMDIFF         SETC := SETA >< SETB; set symmetric difference
     BIT_XOR_EXPR    (C if only in A or only in B (Boolean `XOR')
                     Extended Pascal.
     
     SEARCH_EXPR:    in a set iteration, yields each member of the set
                     in some implementation dependend order.
                     Extended Pascal (this is not yet implemented in gpc).
     
     Rest of the operands result in boolean values.
     
     =, <>           Equality comparisons
     
     <=              `LE_EXPR'
                     SETA <= SETB denotes the inclusion of SETA in SETB
     
     >=              Implemented with `LE_EXPR', like above
                     SETA >= SETB denotes the inclusion of SETB in SETA


File: gpc.info,  Node: GPI files,  Next: AutoMake,  Prev: Set types,  Up: Top

GPI files - GNU Pascal Interfaces
*********************************

   This file documents the mechanism how information is transferred
from the exporting Modules and Units to the Program, Module or Unit
which imports (uses) the information.

   The GPI mechanism is not (yet :-) as stable as it should be.  If you
encounter problems with your Modules or Units, please do the following:

   * To work around, include the module interface (or the whole Unit)
     via a preprocessor directive #include "myfile.pas" or (*$i MyFile
     *) into the source of the main program, *prior* to the "Program
     foo" headline.  Do not use #include or $i in a Module using
     another Module; use them in the main program, instead - and in the
     correct order.

   * To help the problem being solved, please report the bug in the
     following way:

        * Construct the *smallest possible* combination of Modules
          (Units) and Programs which still produces the error.

        * Send the bug report and your (small!) example programs via
          e-mail to Peter Gerwinski <peter.gerwinski@uni-esen.de>.

   * To solve the problem by yourself (requires experience with `C'),
     get the source of the GNU Pascal Compiler (GPC) from
     ftp://kampi.hut.fi/jtv/gnu-pascal, make sure that you can compile
     it on your system and go on reading.

The GPI mechanism
=================

   A GPI file contains a precompiled GNU Pascal Interface.
"Precompiled" means in this context that the Interface already has been
parsed (i.e the front-end has done its work), but that no assembler
output has been produced yet.

   The GPI file format is an implementation-dependent (but not *too*
implementation-dependent ;-) file format for storing GNU Pascal
Interfaces to be exported--Extended Pascal and PXSC module interfaces
as well as interface parts of Borland Pascal Units compiled with GNU
Pascal.

   To see what information is stored in or loaded from a GPI file, run
GPC with an additional command-line option `--debug-gpi'.  Then, GPC
will write a human-readable version of what is being stored/loaded to
stderr.

   While parsing an Interface, GPC stores the names of exported objects
in tree lists--in gpc-parse.y, the bison (yacc) source of GPC's parser,
search for `handle_autoexport'.  At the end of the Interface, everything
is stored in one or more GPI files.  This is called in
gpc-parse.y--search for `create_gpi_files ()'.

   Everything else is done in gpc-module.c.  Here you can find the
source of create_gpi_files () which documents the file format:  First,
a header of 33 bytes containing the string `GNU Pascal Module/Unit
Interface\n' is stored, then the name of the primary source file of the
module as a string, then the name of the exported interface as a tree
node (see below), after that all exported names in the order as they
were stored while parsing.

   The names and the objects (i.e. constants, data types, variables and
functions) they refer to are internally represented as so-called *tree
nodes* as defined in the files tree.h and tree.def from the GCC source
(i.e. the source of the GNU C compiler).  The names are stored as
`IDENTIFIER_NODE's, their meanings as `IDENTIFIER_GLOBAL_VALUE's of
these nodes.  The main problem when storing tree nodes is that they
form a complicated tree in memory with a lot of circular references
making it hard to decide which information must be stored and which
mustn't.

   The functions load_tree and store_tree are intended to load/store a
tree node in a GPI file.

   Each tree node has a `TREE_CODE' indicating what kind of information
it contains.  Each different tree node must be stored in a different
way.  See the source of `load_tree' and `store_tree' for details.

   Most tree nodes contain pointers to other tree nodes; therefore
`load_tree' and `store_tree' are recursive functions.  The
`--debug-gpi' debugging informations contains the recursion level in
parantheses, e.g. `loaded (2):' means that the loaded information was
requested by a pointer contained in a tree node requested by a pointer
contained in a tree node representing an exported symbol.

   Since this recursion can be circular (think of a record containing a
pointer to a record of the same type), we must resolve references to
tree nodes which already have been loaded.  For this reason, and for
saving disk space, I have introduced a `gpi_contents' list containing
pointers to all nodes so far loaded from / stored in the GPI file under
consideration.  When storing a node which already is in the
gpi_contents list, a (normally invalid) `TREE_CODE' of 255 `(0xFF)'
followed by the (int) index of the node in the `gpi_contents' list is
stored instead.  Like this, the reference uses 1 byte plus the size of
an int (normally 4) in the GPI file.  In the debugging information,
this method of storing/loading is indicated as `via gpi_contents'.

   There are some special tree_nodes (e.g. `integer_type_node' or
`NULL_TREE') which are used very often.  I have assigned (normally
invalid) unique `TREE_CODES' for them, so they can be stored in a
single byte.

   That's it.  Now you should be able to "read" GPI files using GPC's
`--debug-gpi' option.  If you encounter a case where the loaded
information differs too much from the stored information, you have
found a bug--congratulations!  What "too much" means, depends on the
object being stored in / loaded from the GPI file.  Remind that the
order things are loaded from a GPI file is the *reversed* order things
are stored when considering *different* recursion levels, but the
*same* order when considering ths *same* recursion level.


File: gpc.info,  Node: AutoMake,  Next: Trouble,  Prev: GPI files,  Up: Top

GNU Pascal's AutoMake facility
******************************

   This file documents a feature of GPC which makes it superfluos to
use `make' (and to write a Makefile) in most cases.

   (For those who know Borland Pascal:  `bpc -m foo'  ("make") is now
`gpc --automake foo.pas.')

   When you invoke GPC with the command line option `--automake', it
checks whether the Modules/Units your program uses must be recompiled.
If so, it recursively calls `GPC -c' to compile them.  Furthermore, the
names of user-written object files are automatically passed to the
linker.  This means that you can compile (and link) your program with a
line like

       gpc --automake foo.pas

   even if `foo' is a large project with a lot of Modules/Units and
include files.  (Yes, when you have modified an include file, GPC
recognizes which Modules/Units must be recompiled!)

   If you want to pass command line options to such second-level
compiles, specify them with the -automake option:

       gpc --automake="-g -O6 -D TERMCAP" foo.pas

   Don't forget the quotes if the string contains blanks.  When you omit
this specification, top level command line options are *not*
automatically passed through.

The AutoMake mechanism--how it works
====================================

   When a Program/Module/Unit imports (uses) an Interface, GPC searches
for the GPI file (see GPI.DOC) derived from the name of the Interface.

   Case 1:  A GPI file was found.

   Each GPI file contains the name of the primary source file (normally
a `.pas' or `.p' file) of the Module/Unit, and the names of all
interfaces imported.  GPC reads this information and invokes itself
with a command like

       gpc foo.pas -M -o foo.d

   This means: preprocess the file, and write down the name of the
object file and those of all its source files in `foo.d'.  GPC reads
`foo.d' and looks if the object file exists and if the source was
modified since the creation of the object file and the gpi file.  If
so, GPC calls itself again to compile the primary source file.  When
everything is done, the .d file is removed.  If there was no need to
recompile, all interfaces imported by the Module/Unit are processed in
the same way as this one.

   Case 2:  No GPI file was found.

   In this case, GPC derives the name of the source file from that of
the Interface by trying first `interface.p', then `interface.pas'.
This will almost always work with Borland Pascal Units, almost never
with Extended Pascal Modules.  With Extended Pascal, compile the Module
once manually in order to produce a GPI file.

   All this is done by the function `gpi_open ()' which uses some
auxiliary functions such as `module_must_be_recompiled ()' and
`compile_module ()'.

   Each time an object file is compiled or recognized as being
up-to-date, its name is stored in a temporary file with the same base
name as all the other temporary files used by GPC but the extension
.gpc.  When the top-level gpc is invoked (which calls gpc1 later on),
it passes the name of this temporary file as an additional command line
parameter to gpc1.  After compilation has been completed, the top-level
gpc reads the temporary file and adds the new object files to the
arguments passed to the linker.

   The additional command (`--amtmpfile'; not to be specified by the
user!) is passed to child GPC processes, so all compiles use the same
temporary file.

   The source for this is merely in `gpc-module.c', but there are also
some hacks in `gcc.c', additional command line options in
`gpc-options.h' and `gpc-decl.c', and `gpc-defs.h' is adapted to
support new functions and global variables.


File: gpc.info,  Node: Trouble,  Next: Bugs,  Prev: AutoMake,  Up: Top

Known Causes of Trouble with GNU CC
***********************************

   This section describes known problems that affect users of GNU CC.
Most of these are not GNU CC bugs per se--if they were, we would fix
them.  But the result for a user may be like the result of a bug.

   Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.

* Menu:

* Actual Bugs::		      Bugs we will fix later.
* Installation Problems::     Problems that manifest when you install GNU CC.
* Cross-Compiler Problems::   Common problems of cross compiling with GNU CC.
* Interoperation::      Problems using GNU CC with other compilers,
			   and with certain linkers, assemblers and debuggers.
* External Bugs::	Problems compiling certain programs.
* Incompatibilities::   GNU CC is incompatible with traditional C.
* Fixed Headers::       GNU C uses corrected versions of system header files.
                           This is necessary, but doesn't always work smoothly.
* Standard Libraries::  GNU C uses the system C library, which might not be
                           compliant with the ISO/ANSI C standard.
* Disappointments::     Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings::     Common misunderstandings with GNU C++.
* Protoize Caveats::    Things to watch out for when using `protoize'.
* Non-bugs::		Things we think are right, but some others disagree.
* Warnings and Errors:: Which problems in your code get warnings,
                         and which get errors.


File: gpc.info,  Node: Actual Bugs,  Next: Installation Problems,  Up: Trouble

Actual Bugs We Haven't Fixed Yet
================================

   * The `fixincludes' script interacts badly with automounters; if the
     directory of system header files is automounted, it tends to be
     unmounted while `fixincludes' is running.  This would seem to be a
     bug in the automounter.  We don't know any good way to work around
     it.

   * The `fixproto' script will sometimes add prototypes for the
     `sigsetjmp' and `siglongjmp' functions that reference the
     `jmp_buf' type before that type is defined.  To work around this,
     edit the offending file and place the typedef in front of the
     prototypes.

   * There are several obscure case of mis-using struct, union, and
     enum tags that are not detected as errors by the compiler.

   * When `-pedantic-errors' is specified, GNU C will incorrectly give
     an error message when a function name is specified in an expression
     involving the comma operator.

   * Loop unrolling doesn't work properly for certain C++ programs.
     This is a bug in the C++ front end.  It sometimes emits incorrect
     debug info, and the loop unrolling code is unable to recover from
     this error.


File: gpc.info,  Node: Installation Problems,  Next: Cross-Compiler Problems,  Prev: Actual Bugs,  Up: Trouble

Installation Problems
=====================

   This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up during installation of GNU
CC.

   * On certain systems, defining certain environment variables such as
     `CC' can interfere with the functioning of `make'.

   * If you encounter seemingly strange errors when trying to build the
     compiler in a directory other than the source directory, it could
     be because you have previously configured the compiler in the
     source directory.  Make sure you have done all the necessary
     preparations.

   * If you build GNU CC on a BSD system using a directory stored in a
     System V file system, problems may occur in running `fixincludes'
     if the System V file system doesn't support symbolic links.  These
     problems result in a failure to fix the declaration of `size_t' in
     `sys/types.h'.  If you find that `size_t' is a signed type and
     that type mismatches occur, this could be the cause.

     The solution is not to use such a directory for building GNU CC.

   * In previous versions of GNU CC, the `gpc' driver program looked for
     `as' and `ld' in various places; for example, in files beginning
     with `/usr/local/lib/gpc-'.  GNU CC version 2 looks for them in
     the directory `/usr/local/lib/gpc-lib/TARGET/VERSION'.

     Thus, to use a version of `as' or `ld' that is not the system
     default, for example `gas' or GNU `ld', you must put them in that
     directory (or make links to them from that directory).

   * Some commands executed when making the compiler may fail (return a
     non-zero status) and be ignored by `make'.  These failures, which
     are often due to files that were not found, are expected, and can
     safely be ignored.

   * It is normal to have warnings in compiling certain files about
     unreachable code and about enumeration type clashes.  These files'
     names begin with `insn-'.  Also, `real.c' may get some warnings
     that you can ignore.

   * Sometimes `make' recompiles parts of the compiler when installing
     the compiler.  In one case, this was traced down to a bug in
     `make'.  Either ignore the problem or switch to GNU Make.

   * If you have installed a program known as purify, you may find that
     it causes errors while linking `enquire', which is part of building
     GNU CC.  The fix is to get rid of the file `real-ld' which purify
     installs--so that GNU CC won't try to use it.

   * On Linux SLS 1.01, there is a problem with `libc.a': it does not
     contain the obstack functions.  However, GNU CC assumes that the
     obstack functions are in `libc.a' when it is the GNU C library.
     To work around this problem, change the `__GNU_LIBRARY__'
     conditional around line 31 to `#if 1'.

   * On some 386 systems, building the compiler never finishes because
     `enquire' hangs due to a hardware problem in the motherboard--it
     reports floating point exceptions to the kernel incorrectly.  You
     can install GNU CC except for `float.h' by patching out the
     command to run `enquire'.  You may also be able to fix the problem
     for real by getting a replacement motherboard.  This problem was
     observed in Revision E of the Micronics motherboard, and is fixed
     in Revision F.  It has also been observed in the MYLEX MXA-33
     motherboard.

     If you encounter this problem, you may also want to consider
     removing the FPU from the socket during the compilation.
     Alternatively, if you are running SCO Unix, you can reboot and
     force the FPU to be ignored.  To do this, type `hd(40)unix auto
     ignorefpu'.

   * On some 386 systems, GNU CC crashes trying to compile `enquire.c'.
     This happens on machines that don't have a 387 FPU chip.  On 386
     machines, the system kernel is supposed to emulate the 387 when you
     don't have one.  The crash is due to a bug in the emulator.

     One of these systems is the Unix from Interactive Systems: 386/ix.
     On this system, an alternate emulator is provided, and it does
     work.  To use it, execute this command as super-user:

          ln /etc/emulator.rel1 /etc/emulator

     and then reboot the system.  (The default emulator file remains
     present under the name `emulator.dflt'.)

     Try using `/etc/emulator.att', if you have such a problem on the
     SCO system.

     Another system which has this problem is Esix.  We don't know
     whether it has an alternate emulator that works.

     On NetBSD 0.8, a similar problem manifests itself as these error
     messages:

          enquire.c: In function `fprop':
          enquire.c:2328: floating overflow

   * On SCO systems, when compiling GNU CC with the system's compiler,
     do not use `-O'.  Some versions of the system's compiler miscompile
     GNU CC with `-O'.

   * Sometimes on a Sun 4 you may observe a crash in the program
     `genflags' or `genoutput' while building GNU CC.  This is said to
     be due to a bug in `sh'.  You can probably get around it by running
     `genflags' or `genoutput' manually and then retrying the `make'.

   * On Solaris 2, executables of GNU CC version 2.0.2 are commonly
     available, but they have a bug that shows up when compiling current
     versions of GNU CC: undefined symbol errors occur during assembly
     if you use `-g'.

     The solution is to compile the current version of GNU CC without
     `-g'.  That makes a working compiler which you can use to recompile
     with `-g'.

   * Solaris 2 comes with a number of optional OS packages.  Some of
     these packages are needed to use GNU CC fully.  If you did not
     install all optional packages when installing Solaris, you will
     need to verify that the packages that GNU CC needs are installed.

     To check whether an optional package is installed, use the
     `pkginfo' command.  To add an optional package, use the `pkgadd'
     command.  For further details, see the Solaris documentation.

     For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc',
     `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.

     For Solaris 2.2, GNU CC needs an additional seventh package:
     `SUNWsprot'.

   * On Solaris 2, trying to use the linker and other tools in
     `/usr/ucb' to install GNU CC has been observed to cause trouble.
     For example, the linker may hang indefinitely.  The fix is to
     remove `/usr/ucb' from your `PATH'.

   * If you use the 1.31 version of the MIPS assembler (such as was
     shipped with Ultrix 3.1), you will need to use the
     -fno-delayed-branch switch when optimizing floating point code.
     Otherwise, the assembler will complain when the GCC compiler fills
     a branch delay slot with a floating point instruction, such as
     `add.d'.

   * If on a MIPS system you get an error message saying "does not have
     gp sections for all it's [sic] sectons [sic]", don't worry about
     it.  This happens whenever you use GAS with the MIPS linker, but
     there is not really anything wrong, and it is okay to use the
     output file.  You can stop such warnings by installing the GNU
     linker.

     It would be nice to extend GAS to produce the gp tables, but they
     are optional, and there should not be a warning about their
     absence.

   * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU
     CC at all unless it has been fixed with `fixincludes'.  This causes
     problems in building GNU CC.  Once GNU CC is installed, the
     problems go away.

     To work around this problem, when making the stage 1 compiler,
     specify this option to Make:

          GCC_FOR_TARGET="./xgpc -B./ -I./include"

     When making stage 2 and stage 3, specify this option:

          CFLAGS="-g -I./include"

   * Users have reported some problems with version 2.0 of the MIPS
     compiler tools that were shipped with Ultrix 4.1.  Version 2.10
     which came with Ultrix 4.2 seems to work fine.

     Users have also reported some problems with version 2.20 of the
     MIPS compiler tools that were shipped with RISC/os 4.x.  The
     earlier version 2.11 seems to work fine.

   * Some versions of the MIPS linker will issue an assertion failure
     when linking code that uses `alloca' against shared libraries on
     RISC-OS 5.0, and DEC's OSF/1 systems.  This is a bug in the
     linker, that is supposed to be fixed in future revisions.  To
     protect against this, GNU CC passes `-non_shared' to the linker
     unless you pass an explicit `-shared' or `-call_shared' switch.

   * On System V release 3, you may get this error message while
     linking:

          ld fatal: failed to write symbol name SOMETHING
           in strings table for file WHATEVER

     This probably indicates that the disk is full or your ULIMIT won't
     allow the file to be as large as it needs to be.

     This problem can also result because the kernel parameter `MAXUMEM'
     is too small.  If so, you must regenerate the kernel and make the
     value much larger.  The default value is reported to be 1024; a
     value of 32768 is said to work.  Smaller values may also work.

   * On System V, if you get an error like this,

          /usr/local/lib/bison.simple: In function `yyparse':
          /usr/local/lib/bison.simple:625: virtual memory exhausted

     that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'.

   * Current GNU CC versions probably do not work on version 2 of the
     NeXT operating system.

   * On NeXTStep 3.0, the Objective C compiler does not work, due,
     apparently, to a kernel bug that it happens to trigger.  This
     problem does not happen on 3.1.

   * On the Tower models 4N0 and 6N0, by default a process is not
     allowed to have more than one megabyte of memory.  GNU CC cannot
     compile itself (or many other programs) with `-O' in that much
     memory.

     To solve this problem, reconfigure the kernel adding the following
     line to the configuration file:

          MAXUMEM = 4096

   * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a
     bug in the assembler that must be fixed before GNU CC can be
     built.  This bug manifests itself during the first stage of
     compilation, while building `libgpc.a':

          _floatdisf
          cc1: warning: `-g' option not supported on this version of GCC
          cc1: warning: `-g1' option not supported on this version of GCC
          ./xgpc: Internal compiler error: program as got fatal signal 11

     A patched version of the assembler is available by anonymous ftp
     from `altdorf.ai.mit.edu' as the file
     `archive/cph/hpux-8.0-assembler'.  If you have HP software support,
     the patch can also be obtained directly from HP, as described in
     the following note:

          This is the patched assembler, to patch SR#1653-010439, where
          the assembler aborts on floating point constants.

          The bug is not really in the assembler, but in the shared
          library version of the function "cvtnum(3c)".  The bug on
          "cvtnum(3c)" is SR#4701-078451.  Anyway, the attached
          assembler uses the archive library version of "cvtnum(3c)"
          and thus does not exhibit the bug.

     This patch is also known as PHCO_4484.

   * On HP-UX version 8.05, but not on 8.07 or more recent versions,
     the `fixproto' shell script triggers a bug in the system shell.
     If you encounter this problem, upgrade your operating system or
     use BASH (the GNU shell) to run `fixproto'.

   * Some versions of the Pyramid C compiler are reported to be unable
     to compile GNU CC.  You must use an older version of GNU CC for
     bootstrapping.  One indication of this problem is if you get a
     crash when GNU CC compiles the function `muldi3' in file
     `libgpc2.c'.

     You may be able to succeed by getting GNU CC version 1, installing
     it, and using it to compile GNU CC version 2.  The bug in the
     Pyramid C compiler does not seem to affect GNU CC version 1.

   * There may be similar problems on System V Release 3.1 on 386
     systems.

   * On the Intel Paragon (an i860 machine), if you are using operating
     system version 1.0, you will get warnings or errors about
     redefinition of `va_arg' when you build GNU CC.

     If this happens, then you need to link most programs with the
     library `iclib.a'.  You must also modify `stdio.h' as follows:
     before the lines

          #if     defined(__i860__) && !defined(_VA_LIST)
          #include <va_list.h>

     insert the line

          #if __PGC__

     and after the lines

          extern int  vprintf(const char *, va_list );
          extern int  vsprintf(char *, const char *, va_list );
          #endif

     insert the line

          #endif /* __PGC__ */

     These problems don't exist in operating system version 1.1.

   * On the Altos 3068, programs compiled with GNU CC won't work unless
     you fix a kernel bug.  This happens using system versions V.2.2
     1.0gT1 and V.2.2 1.0e and perhaps later versions as well.  See the
     file `README.ALTOS'.

   * You will get several sorts of compilation and linking errors on the
     we32k if you don't follow the special instructions.

   * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
     program to report an error of the form:

          ./fixproto: sh internal 1K buffer overflow

     To fix this, change the first line of the fixproto script to look
     like:

          #!/bin/ksh


File: gpc.info,  Node: Cross-Compiler Problems,  Next: Interoperation,  Prev: Installation Problems,  Up: Trouble

Cross-Compiler Problems
=======================

   You may run into problems with cross compilation on certain machines,
for several reasons.

   * Cross compilation can run into trouble for certain machines because
     some target machines' assemblers require floating point numbers to
     be written as *integer* constants in certain contexts.

     The compiler writes these integer constants by examining the
     floating point value as an integer and printing that integer,
     because this is simple to write and independent of the details of
     the floating point representation.  But this does not work if the
     compiler is running on a different machine with an incompatible
     floating point format, or even a different byte-ordering.

     In addition, correct constant folding of floating point values
     requires representing them in the target machine's format.  (The C
     standard does not quite require this, but in practice it is the
     only way to win.)

     It is now possible to overcome these problems by defining macros
     such as `REAL_VALUE_TYPE'.  But doing so is a substantial amount of
     work for each target machine.  *Note Cross-compilation::.

   * At present, the program `mips-tfile' which adds debug support to
     object files on MIPS systems does not work in a cross compile
     environment.

