This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 65580 - gcc 3.1-3 miscompiles OpenOffice; -O0 worse than higher levels
gcc 3.1-3 miscompiles OpenOffice; -O0 worse than higher levels
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2002-05-27 18:00 EDT by Bernhard Rosenkraenzer
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-30 08:40:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Bernhard Rosenkraenzer 2002-05-27 18:00:38 EDT
Description of Problem:    
gcc 3.1-3 fails to build OpenOffice 1.0 with gcc 3.1 (Working spec file with    
patches in, module openoffice, blank    
password ;) Unfortunately it currently requires jdk.)  
The breakages vary with optimization levels:  
It doesn't build. The "idlc" program (IDL compiler,  used during the build) 
crashes on startup, therefore the rest can't be built. 
-O1 and higher: 
It builds, but the resulting binaries fail. Widgets aren't drawn, but show up 
when redraw events occur (e.g. dropdown menu items aren't drawn until they're 
Version-Release number of selected component (if applicable):    
2.96-x is ok. 
How Reproducible:    
Comment 1 Jakub Jelinek 2002-05-28 14:30:15 EDT
I'll try the idcl crash first. Could any of you try to debug the other problem?
Does it show up with gcc 3.0.4? As I'm familiar with neither current X toolkit,
the latter would be pretty hard for me unless you find which source misbehaves.
BTW: What are the mozilla binaries for when Mozilla address book is not built
(*nomozab* patches)?
Comment 2 Jakub Jelinek 2002-05-30 08:39:59 EDT
Ok, idlc crash is because Sun doesn't know what inline assembly is about.
Here is a fix (untested yet):
begin 644 P.bz2
--- oo_1.0_src/sal/osl/unx/interlck.c.jj        Wed May  2 17:03:13 2001
+++ oo_1.0_src/sal/osl/unx/interlck.c   Thu May 30 10:45:19 2002
@@ -83,9 +83,11 @@ oslInterlockedCount SAL_CALL osl_increme
                "xadd %0, %2\n\t"
                "incl %0"
-       :       "=a" (nCount), "=m" (*pCount)
+       :       "=&r" (nCount), "=m" (*pCount)
        :       "m" (*pCount)
        :       "memory");
+       return nCount;

 oslInterlockedCount SAL_CALL osl_decrementInterlockedCount(oslInterlockedCount* pCount)
@@ -97,9 +99,11 @@ oslInterlockedCount SAL_CALL osl_decreme
                "xadd %0, %2\n\t"
                "decl %0"
-       :       "=a" (nCount), "=m" (*pCount)
+       :       "=&r" (nCount), "=m" (*pCount)
        :       "m" (*pCount)
        :       "memory");
+       return nCount;

 #elif defined ( GCC ) && defined ( POWERPC )
@@ -117,7 +121,7 @@ oslInterlockedCount SAL_CALL osl_increme
                "   addi    %0,%0,1\n\t"
                "   stwcx.  %0,0,%2\n\t"
                "   bne-    1b"
-               : "=r" (nCount), "=m" (*pCount)
+               : "=&r" (nCount), "=m" (*pCount)
                : "r" (pCount)
                : "r4", "memory");

@@ -134,7 +138,7 @@ oslInterlockedCount SAL_CALL osl_decreme
                "   subi        %0,%0,1\n\t"
                "   stwcx.  %0,0,%2\n\t"
                "   bne-    1b"
-               : "=r" (nCount), "=m" (*pCount)
+               : "=&r" (nCount), "=m" (*pCount)
                : "r" (pCount)
                : "r4", "memory");

--- oo_1.0_src/bridges/source/c_uno/intelx86.cxx.jj     Wed Apr 18 13:05:48 2001
+++ oo_1.0_src/bridges/source/c_uno/intelx86.cxx        Thu May 30 11:37:26 2002
@@ -95,24 +95,21 @@ Lcopy:      sub             eax, 4
                add             esp, eax
 #elif GCC
+       int ecx, edx;
-               "mov %2, %%eax\n\t"
-               "mov %%eax, %%ecx\n\t"
-               "shl $2, %%eax\n\t"
-               "add %1, %%eax\n"
-               "Lcopy:\n\t"
-               "sub $4, %%eax\n\t"
-               "pushl (%%eax)\n\t"
-               "dec %%ecx\n\t"
-               "jne Lcopy\n\t"
-               "mov %0, %%eax\n\t"
-               "call *%%eax\n\t"
-               "mov %%eax, %3\n"
-               "mov %2, %%eax\n\t"
-               "shl $2, %%eax\n\t"
-               "add %%eax, %%esp\n\t"
-               : : "m"(fptr), "m"(pParams), "m"(nParams), "m"(retVal)
+               "1:\n\t"
+               "subl $4, %0\n\t"
+               "pushl (%0)\n\t"
+               "decl %1\n\t"
+               "jne 1b\n\t"
+               "call *%2\n\t"
+               "leal 0(%%esp,%3,4), %%esp\n\t"
+               : "=a"(retVal), "=c"(ecx), "=d"(edx)
+               : "S"(nParams),
+                 "0" (((int *) pParams) + nParams), "1" (nParams), "2"(fptr)
+               : "memory", "cc"
 #error "### unsupported x86 compiler!"

(actually only the first file is what matters in this case).
Inline assembly in bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx
looks extremely suspicios too, I think best would be to write cpp_vtable_call
in pure assembly plus put some assertions into cpp2uno.cxx so that the assembly
can use hardcoded typelib_TypeClass_* values it wants.

As far as redrawing at -O1, what I could see is that basically no drawing occured
at all, just windows poped up. The only window content I saw was in ./setup program
the unpacking progress bar and in ooffice background in the main window (ie.
logo and the like). I couldn't get it to redraw by either minimizing/maximizing
or by moving other windows on top of it.
I was building with gcc3-c++-3.1-2 (that's what I have installed at home) on
vanilla 7.3 (plus jdk :( ).
I remember my brother seeing this with the OO1.0 provided binaries when running
the setup program during installation on 7.1, but it worked in 7.3.
David Sainty wrote to me 2 weeks ago:
> I do however have an unfortunate problem.  It seems all of my builds so
> far (on RHL 7.3) have had a problem whereby activity seemingly related to
> StarBASIC (a mix of XML an javascripty type stuff) causes the instance to
> abort (SIGSEGV).  I think I will actually consider changing my Java and
> my XML libraries, in case there is some issue here.
Was this built with gcc 3.1 or 3.0 or 2.96-RH?
Comment 3 Jakub Jelinek 2002-07-11 11:27:40 EDT
Guess I can close this now, OpenOffice redraws just fine (ATM miscompiles (but I have added workaround) and file open/save dialog
doesn't work). Grr.

Note You need to log in before you can comment on or make changes to this bug.