FW: Parameter values wrong on indirect functions using gcc 2.95 on HP PA machines

["Dan Coby" <dan at artifex dot com>]

Hello,


I have tried to send this email but your email system will not
accept anything over 200k.  I have a 578k attachment.  Do you
have any suggestions?



My name is Dan Coby and I work for Artifex Software.  One of
Artifex's responsibilities is providing for supporting the
Ghostscript software package.  Ghostscript is an Adobe Postscript
and PDF interpreter.

We have what appears to be a GCC problem.  The problem only seems
to appear on HP Precision Architecture machines using GCC 2.95.

I got this email address from the web.  If I am sending this
information to the wrong people, please let me know and I thank
you for your efforts.

The problem is being reported by one of our customers.  As I said,
it only seems to exist on HP PA machines and GCC 2.95.  I do not
have this machine.  Thus I am working with indirect information
from our customer.  However the evidence seems very strong for
a GCC problem.

Note:  We have tested this same software on a Sun Solaris and GCC
2.95 and everything seems fine.  Ghostscript has thousands of users,
it is commonly the prime printer interface on Linux machines, and
we only have this one report of this specific problem.

The basic information:

OS:  HPUX 10.20 Model 712/80i With a cpu 9000
Compiler:  GCC 2.95 19990728 release

In our software there seems to be a parameter passing problem between
a routine called gs_ht_process_screen_memory() in the source module
gsht.c and a routine called spot_dummy() in the source module zht1.c.
Note:  *phsp->spot_function is pointing at spot_dummy().

To find the problem, I modified gs_ht_process_screen_memory from:

    while ((code = gs_screen_currentpoint(penum, &pt)) == 0)
	if ((code = gs_screen_next(penum, (*phsp->spot_function) (pt.x, pt.y))) <
0)
	    return code;

To:

    while ((code = gs_screen_currentpoint(penum, &pt)) == 0)
      {
	  floatp value;
        dprintf1("In gs_ht_process_screen_memory %d\n", 1);
	  value = (*phsp->spot_function) (pt.x, pt.y);
        if ( value < -1.0 ) {
 	   dprintf3("gsht:gx_ht_process_screen - value less than -1 %f at %f,
%f\n", value, pt.x, pt.y);
        }

        if ( value > 1.0 ) {
 	   dprintf3("gsht:gx_ht_process_screen - value greater than 1 %f at %f,
%f\n", value, pt.x, pt.y);
        }

	  if ((code = gs_screen_next(penum, value)) < 0)
	    return code;
      }

Spot_dummy was changed from:

private float
spot_dummy(floatp x, floatp y)
{
    return (x + y) / 2;
}

To:

private float
spot_dummy(floatp x, floatp y)
{
    floatp value = (x + y) / 2;
    dprintf3("zht1:spot_dummy %f, %f, value = %f\n", x, y, value);
    return value;
}


From some of the various include files, etc:

floatp is defined as double (in stdpre.h)

    src/stdpre.h:typedef double floatp;

The definition of spot_function is consistent with the definition of
spot_dummy.

   float (*spot_function) (P2(floatp, floatp));		(from gsht.h)

   private float
   spot_dummy(floatp x, floatp y)				(from zht1.c)


The types of pt.x and pt.y passed to

	  value = (*phsp->spot_function) (pt.x, pt.y);

are both double:

typedef struct gs_point_s {					(from gstypes.h)
    double x, y;
} gs_point;


Note:  My MSVC 6.0 compiler gives no warning messages about either zht1.c or
gsht.c.


With these changes the following section from the output was obtained:

In gs_ht_process_screen_memory 1
zht1:spot_dummy -2.334333, 0.333333, value = -1.000500
gsht:gx_ht_process_screen - value less than -1 -1.000500 at
0.666333, -0.334333


This shows:

1.  Entry into gs_ht_process_screen_memory (first line)
2.  The values of pt.x and pt.y are 0.666333, -0.334333 (from third line)
3.  spot_dummy thinks x and y are -2.334333, 0.333333 (from second line)
4.  The calculated value from spot_dummy is consistent with its incorrect
    parameter values.  Also this value is being returned properly to
    gs_ht_process_screen_memory().

We had the customer send us a copy of the assembly language produced by
the compiler.  Included as gsht.s and zht1.s.  Looking at it we see:

The spot_dummy procedure in zht1.o expects double-precision arguments in
%fr5 and %fr7, computes the double-precision result in %fr12, and converts
it to a single-precision return value in %fr4L.  This is as expected.

The call in gx_ht_process_screen_memory expects a single-precision return
value in %fr4L, so that is OK.  However, it is not obvious how it passes
the arguments.  Rather than calling the procedure directly, it uses a
runtime support procedure named $$dyncall, whose operation is unknown.
It is not loading %fr5 and %fr7 as we would expect.  For other calls (such
as the printf calls where we are printing the values) we do see the floating
point registers being loaded.

Everything points to a problem in the parameter passing mechanism with the
indirect call to the function spot_dummy.  We tried several variants but
anything that involved the indirect call failed.

The effective command line which is generated by our makefile is:

	  gcc `cat cc.tr` $(CFLAGS) gsht.o -c gsht.c

Where the contents of cc.tr is
	-Wcast-qual -Wwrite-strings

Where the following combinations for CFLAGS were tried
	-O2
	-g -O
	-g -O0

The actually commnd line is a little more complicated since files are
actually
in multiple directories.


I am sending:

gsht.c - the original (unmodified) version of this source file.
cc.tr - command file used on the compiler command line.
headers.zip - All of the headers in a Ghostscript build.  I do not know
    which ones are required for this file and I would forget one if I tried
    to pick them out.

Since I am doing things by proxy via our customer, I cannot generate the
preprocessor
output that you have requested.  Sorry.


If you are interested in a full copy of Ghostscript and its source files,
they can be obtained at
    http://sourceforge.net/projects/ghostscript
The current version is 6.01 (and that is the version being used by our
customer).
A description of the Ghostscript build process is described in doc/make.htm
in the download.  Our customer is using src/unix-gcc.mak as his makefile.

Thank you

Dan Coby

gsht.c

cc.tr

zht1.s

gsht.s