PROBLEM:  (QAR 56987)	(Patch ID: OSF410-124)
********
When the -fast switch is specified on the command line, the cc command (driver)
instructs the c compiler to create a single object file for all of the .c files
specified.  If the -c switch is also included, this one large object file 
remains after the compilation completes.  When these two switches are specified,
and the -compress switch is also specified asking for a compressed object, the
driver fails to supply its call to objZ (to do the compression) with the object
file name that is being used for the final object file output.

Without this patch, when these switches are used in combination, the call to 
objZ to compress the object file fails with a "usage" error since no object 
file is specified for the compression.

PROBLEM:  (58430)    (Patch ID: OSF410-173)
********
The current preferred mechanism for passing command line switches to a
given phase of compilation via cc is with the -W switch.  The cc driver uses 
the character following the "W" to direct the switch following it to the 
appropriate phase.  This patch addresses a problem that occurs when trying 
to pass a '-input filename' switch to ld (the linker) through cc.  The file 
that 'filename' refers to contains lines that are interpreted by ld as if they 
were included on the actual command line.  For example:

        cc test.o -Wl,-input,ldinput

        where: cat ldinput
               sub.o

This cc command invokes ld, passing test.o and "-input ldinput".  ld opens
the file "ldinput" and adds sub.o to its own command line.

The problem occurs when the contents of a file passed in this manner are 
position dependent when presented to ld.  Specifically, cc puts arguments 
passed via Wl on the command line first, followed by any switches or object 
files entered by the user on the cc command line that are meant for ld.  This 
includes the specification of /usr/lib/cmplrs/cc/crt0.o, which is the transfer 
point for all executables (the place where control is transferred when a 
program is loaded).  cc always adds this to the ld command line when an 
executable is being created.  The ld command line created by cc in the above 
example looks like this:

        cc -v test.o -Wl,-input,ldinput
        ld -input ldinput -g0 -O1 -call_shared /usr/lib/cmplrs/cc/crt0.o test.o
-lc

Notice the placement of "-input ldinput" on the ld command line.  When linking
an executable, the linker lays out the code in the order in which it sees
the input .o files.  The very first address in the text section will be
the transfer address, or entry point, for the program.  This MUST BE crt0.o.
The executable created by the command line above produces a transfer address 
point in sub.o, and ultimately a segmentation fault when run.
 
The solution for this problem is to provide cc with a way to recognize a
position-dependent argument meant for the ld command line.  This has been
accomplished with a new cc switch:

        -input_to_ld filename

The cc driver interprets this switch as a -input switch destined for ld, and
places it on the ld command line in the same relative position that it had
on the cc command line.  We can now write the above example like this:

        cc test.o -input_to_ld ldinput
        ld -g0 -O1 -call_shared /usr/lib/cmplrs/cc/crt0.o test.o -input ldinput
-lc

Notice that the -input switch has retained its cc command line position.

PROBLEM:  (QAR 57515)    (Patch ID: OSF410-188)
********
There is a problem in cc that causes it to set the incorrect optimization 
level when the user specifies the "-O -migrate" options.

If you compile with the options "-O -migrate -v", you will see that gemc_cc 
is invoked with -O2 instead of -O4.