Bug 355496

Without anti-aliasing it still works fine, i.e. 

gs -dNOPLATFONTS -sDEVICE=x11
/usr/share/doc/packages/ghostscript-library/examples/alphabet.ps

works. But as soon as one tries to use anti-aliasing,
only blank pages are displayed.

The ghostscript of 10.3 is espgs 8.15.4, that on factory is gpl gs 8.60.
Please note that gpl gs 8.60 does show the page on a 10.2 with and without
anti-aliasing, therefore I guess a compiler problem.

Richard? What has changed between the old and new compiler?  Is there the
last working compiler available within factory?

There changed a lot, as always.  You can try murzim-rguenther-12 for what will
be submitted for the next rebuild.

This version of gcc results also in blank pages

Just copied the resulting binary RPMs of a factory build without
libgs support into a build system of 10.3 and installed this.
The same binary together with the same X11.so device file
does not work on factroy but on 10.3.

This leads me to the assumption that the problem is not located
within gs its self but one of the following libraries:

 d127:/ # ldd /tmp/gs /usr/lib64/ghostscript/8.60/X11.so
 /tmp/gs:
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00002aaaaacc8000)
        libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00002aaaaaf46000)
        libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002aaaab15c000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaab392000)
        libgimpprint.so.1 => /usr/lib64/libgimpprint.so.1 (0x00002aaaab5b8000)
        libz.so.1 => /lib64/libz.so.1 (0x00002aaaab8a2000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00002aaaabab8000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabcbc000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00002aaaabec0000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaac16f000)
        libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaac477000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaac6d1000)
        libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00002aaaac8f5000)
        libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00002aaaacb41000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaacec0000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaad0dc000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaad32f000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00002aaaad568000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaad79e000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
        libpcre.so.0 => /usr/lib64/libpcre.so.0 (0x00002aaaadae3000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaadd0c000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00002aaaadf1a000)
 /usr/lib64/ghostscript/8.60/X11.so:
        libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002aaaaaccc000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002aaaaaf2f000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002aaaab138000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002aaaab355000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002aaaab566000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab89c000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002aaaabbe2000)
        libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x00002aaaabde5000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002aaaabfe7000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaac204000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555555000)

It should be noted that not only the fonts are not displayed in
case of using -sDEVICE=x11alpha but also normal drawings are
missed or incomplete, e.g.

  gs -sDEVICE=x11alpha /usr/share/ghostscript/8.60/examples/tiger.eps

shows only a gray background in factory but in the 10.3 system the normal
tiger face in foreground.

Are there any miss-compilations within the X11 libraries?

We have now tried whether it works with the X11 library from 10.3.

We unpacked

/work/CDs/all/full-10.3-x86_64/suse/x86_64/xorg-x11-libX11.rpm

in a local directory and removed libX11-xcb.so.1.0.0 so that only
libX11 remained.

Then,

LD_LIBRARY_PATH=${PWD}/usr/lib64 gs -sDEVICE=x11alpha  /usr/share/ghostscript/8.60/examples/tiger.eps

worked.

So this might be a problem in libX11 or a maybe a mis-compilation of
libX11 in STABLE.

I don't see this issue on a 10.3 with current X.Org (including libX11) built for 10.3 and installed. But this is still ghostscript 8.15. 

(In reply to comment #7 from Stefan Dirsch)
> I don't see this issue on a 10.3 with current X.Org (including libX11) built
> for 10.3 and installed. But this is still ghostscript 8.15. 
Still working after updating ghostscript to release 8.60 from STABLE built for 10.3. Miscompilation of libX11 in STABLE?

I've now recompiled the libX11 and libxcb sources of 10.3 for STABLE. Still the same problem.

Building (STABLE) libX11 with
RPM_OPT_FLAGS="-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-aliasing", i.e. removing the "-O2" optimization, fixes the issue. We're testing on x86_64. I have no clue which file gets miscompiled.

"-O1" still works. 

So it's one of these:
+  -falign-jumps                        [enabled]
+  -falign-labels                       [enabled]
+  -fcaller-saves                       [enabled]
+  -fcrossjumping                       [enabled]
+  -fcse-follow-jumps                   [enabled]
+  -fdelete-null-pointer-checks         [enabled]
+  -fexpensive-optimizations            [enabled]
+  -fforward-propagate                  [enabled]
+  -fgcse                               [enabled]
+  -finline-small-functions             [enabled]
+  -foptimize-register-move             [enabled]
+  -foptimize-sibling-calls             [enabled]
+  -fpeephole2                          [enabled]
+  -fregmove                            [enabled]
+  -freorder-blocks                     [enabled]
+  -freorder-functions                  [enabled]
+  -fschedule-insns2                    [enabled]
+  -fstrict-aliasing                    [enabled]
+  -fthread-jumps                       [enabled]
+  -ftree-pre                           [enabled]
+  -ftree-store-ccp                     [enabled]
+  -ftree-vrp                           [enabled]

Richard, any favorites? Do I need to disable one by one? 
Werner, what is the difference between x11 and x11alpha DEVICE in X11 function calling? Can this give us a hint where to look for?

Try adding -fwrapv.  Also try the gcc from mbuild murzim-rguenther-54, that
contains some (random) fixes.

Fixed with adding "-fno-wrapv". :-)

There is no x86_64 in murzim-rguenther-54. Tried with urzim-rguenther-53. Without "-fno-wrapv" this didn't help. :-(

Err, -fno-wrapv is the default ... (I'm checking what that actually does now ;))

Oh, and it was murzim-rguenther-52, but I don't remember fixes in that area
(and if it is -fwrapv that fixes it, there's a bug in libX11).

I'm confused. I'll doublecheck my results.

My results before were bogus. Neither -fno-wrapv nor -fwrapv help. Sorry for the confusion. But at least using "-O1" still helps. :-)

Building with gcc from murzim-rguenther-52 didn't help. I think we're back to comment #12.

Ok. Using "-O2 -fno-tree-vrp" instead of "-O2" fixes the problem.

On comment #12: AFAIK ghostscript uses memory mapping into X11 pixmap
instead of drawing.  You may use also

gs -sDEVICE=x11 -dMaxBitmap=5000000 /usr/share/ghostscript/8.60/examples/waterfal.ps

to force this.

It's enough to compile libX11-1.1.3/src/ImUtil.c with -fno-tree-vrp. Most likely XinitImage(). Richard, let me know what you need to investigate this issue.

Please attach pre-processed source of this file (just pass an additional -save-temps to the build commandline), ImUtil.i.  Thanks.

Created attachment 194768 [details]
ImUtil.i

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35231

and I have a fix.

Great! A fix for gcc or libX11 code?

For gcc.

Fixed.  (package waits for checkin)

Excellent! I'll remove the option once gcc has been checked in.

(In reply to comment #28 from Stefan Dirsch)
> Excellent! I'll remove the option once gcc has been checked in.

done.