Bug 689598 - grashopp.pcl incorrect with release build
Summary: grashopp.pcl incorrect with release build
Status: RESOLVED WORKSFORME
Alias: None
Product: GhostPCL
Classification: Unclassified
Component: PCL raster (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Marcos H. Woehrmann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-06 11:34 UTC by Ralph Giles
Modified: 2011-08-15 19:47 UTC (History)
4 users (show)

See Also:
Customer:
Word Size: ---


Attachments
example incorrect rendering (109.88 KB, image/png)
2007-12-06 11:39 UTC, Ralph Giles
Details
grasshopper.pdf (474.45 KB, application/pdf)
2010-06-25 05:56 UTC, Henry Stiles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Giles 2007-12-06 11:34:06 UTC
For me, the release builds of ghostpcl render the example file
tools/grashopp.pcl incorrectly. The problem occurs on x86_64 Ubuntu Linux 7.10
(upgraded from previous versions). The debug builds work correctly, so we
suspect it's related to optimization. It seems to be hard to reproduce, even on
other 64 bit linux systems.

There problem occurs with both 32 bit and 64 bit gx_color_index.
Comment 1 Ralph Giles 2007-12-06 11:39:54 UTC
Created attachment 3615 [details]
example incorrect rendering

Uploading and output sample to show the problem.
Comment 2 Henry Stiles 2007-12-06 13:09:00 UTC
Just for kicks, maybe Marcos can try this on his 64 bit big endian rig.
Comment 3 Marcos H. Woehrmann 2007-12-06 15:49:24 UTC
Will do.
Comment 4 Henry Stiles 2007-12-17 16:07:16 UTC
The source of the problem is the code in gxfarith.h which does not work on 64
bit ubuntu (attached below).  I don't think this is worth detailed investigation
and the code should simply be removed.  I'll wait to hear objections, I don't
think this code really has an owner.  Alex owns zarith.c.  I suspect it is only
reproducible in pcl because USE_FPU <= 0.  The problem should be reproducible in
gs with a similar configuration.

/*
 * The following macros replace the ones in gxarith.h on machines
 * that are likely to have very slow floating point.
 *
 * None of these macros would be necessary if compilers had a clue
 * about generating good floating point comparisons on machines with
 * slow (or no) floating point hardware.
 */

# if USE_FPU <= 0 && ARCH_FLOATS_ARE_IEEE && (arch_sizeof_float ==
arch_sizeof_int || arch_sizeof_float == arch_sizeof_long)

#  if arch_sizeof_float == arch_sizeof_int
typedef int _f_int_t;
typedef uint _f_uint_t;

#  else				/* arch_sizeof_float == arch_sizeof_long */
typedef long _f_int_t;
typedef ulong _f_uint_t;

#  endif
#  define _f_as_int(f) *(const _f_int_t *)(&(f))
#  define _f_as_uint(f) *(const _f_uint_t *)(&(f))

#  if arch_sizeof_double == arch_sizeof_int
#    define _d_int_t int
#  else
#   if arch_sizeof_double == arch_sizeof_long
#    define _d_int_t long
#   endif
#  endif
#  define _d_uint_t unsigned _d_int_t
#  define _d_as_int(f) *(const _d_int_t *)(&(f))
#  define _d_as_uint(f) *(const _d_uint_t *)(&(f))

#  define _ftest(v,f,n)\
     (sizeof(v)==sizeof(float)?(f):(n))
#  ifdef _d_int_t
#    define _fdtest(v,f,d,n)\
	(sizeof(v)==sizeof(float)?(f):sizeof(v)==sizeof(double)?(d):(n))
#  else
#    define _fdtest(v,f,d,n)\
	_ftest(v,f,n)
#  endif

#  undef is_fzero
#  define is_fzero(f)	/* must handle both +0 and -0 */\
     _fdtest(f, (_f_as_int(f) << 1) == 0, (_d_as_int(f) << 1) == 0,\
       (f) == 0.0)

#  undef is_fzero2
#  define is_fzero2(f1,f2)\
     (sizeof(f1) == sizeof(float) && sizeof(f2) == sizeof(float) ?\
      ((_f_as_int(f1) | _f_as_int(f2)) << 1) == 0 :\
      (f1) == 0.0 && (f2) == 0.0)

#  undef is_fneg
#  if arch_is_big_endian
#    define _is_fnegb(f) (*(const byte *)&(f) >= 0x80)
#  else
#    define _is_fnegb(f) (((const byte *)&(f))[sizeof(f) - 1] >= 0x80)
#  endif
#  if arch_sizeof_float == arch_sizeof_int
#    define is_fneg(f)\
       (sizeof(f) == sizeof(float) ? _f_as_int(f) < 0 :\
	_is_fnegb(f))
#  else
#    define is_fneg(f) _is_fnegb(f)
#  endif

#  define IEEE_expt 0x7f800000	/* IEEE exponent mask */
#  define IEEE_f1 0x3f800000	/* IEEE 1.0 */

#  undef is_fge1
#  if arch_sizeof_float == arch_sizeof_int
#    define is_fge1(f)\
       (sizeof(f) == sizeof(float) ?\
	(_f_as_int(f)) >= IEEE_f1 :\
	(f) >= 1.0)
#  else				/* arch_sizeof_float == arch_sizeof_long */
#    define is_fge1(f)\
       (sizeof(f) == sizeof(float) ?\
	(int)(_f_as_int(f) >> 16) >= (IEEE_f1 >> 16) :\
	(f) >= 1.0)
#  endif

#  undef f_fits_in_ubits
#  undef f_fits_in_bits
#  define _f_bits(n) (4.0 * (1L << ((n) - 2)))
#  define f_fits_in_ubits(f, n)\
	_ftest(f, _f_as_uint(f) < (_f_uint_t)IEEE_f1 + ((_f_uint_t)(n) << 23),\
	  (f) >= 0 && (f) < _f_bits(n))
#  define f_fits_in_bits(f, n)\
	_ftest(f, (_f_as_uint(f) & IEEE_expt) < IEEE_f1 + ((_f_uint_t)((n)-1) << 23),\
	  (f) >= -_f_bits((n)-1) && (f) < _f_bits((n)-1))

# endif				/* USE_FPU <= 0 & ... */
Comment 5 Henry Stiles 2007-12-17 20:05:54 UTC
There is probably more to this problem than #4.  I cannot reproduce the problem
in ghostscript with a similar FPU configuration.
Comment 6 Henry Stiles 2007-12-18 12:06:42 UTC
A related issue is USE_FPU and USE_FPU_FIXED can have different definitions in
different source files depending weather gconfigv.h is pre included before
gxfixed.h.  This can be observed in the code by inspection.  Once this is fixed,
the problem can be reassigned back to me, if there is still an issue.  I still
recommend removing the code in comment #4 regardless of how this winds down.
Comment 7 Henry Stiles 2010-05-12 16:58:45 UTC
Marcos if you can still reproduce this assign it back to me.
Comment 8 Henry Stiles 2010-06-25 05:56:41 UTC
Created attachment 6402 [details]
grasshopper.pdf

I can't reproduce this bug.  I am attaching the scanned HP result.
Comment 9 Marcos H. Woehrmann 2011-08-15 19:47:49 UTC
Can't reproduce either.  Closing as WORKSFORME.