On 29 Aug, Don Lewis wrote:
> On 14 Aug, Andrea Pescetti wrote:
>> On 09/08/2015 Don Lewis wrote:
>>> Looks like you are compiling with gcc 4.9. I ran into this same problem
>>> on FreeBSD and worked around it by changing the "-Os" optimization flag
>>> ... This is a gcc bug, see:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009
>>
>> This looks like very valuable information (I never saw this, but I build
>> with gcc 4.8.x most of the times). Could you expand on it a bit?
>
> It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc
> 5 and was not present in 4.8. It is sometimes triggered by inline
> virtual class methods. I believe it only happens with -Os optimization.
> The workaround is to either disable optimization by using
> "-O0", or disabling the problematic optimization step by using
> "-fno-devirtualize -fno-devirtualize-speculatively", which I figured out
> based on comment #2 in the gcc bug report. I didn't attempt to figure
> out if only one of the flags would be sufficient.
>
>> Do I understand correctly from the above issue than anybody building
>> OpenOffice (I'm obviously particularly interested in the coming 4.1.2)
>> with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the
>> issue is not fixed yet in 4.9.x) will have to manually edit their makefiles?
>
> Yes.
>
>> If this is true, would you recommend that we either detect it at
>> configuration time, or modify the makefiles, or anything else?
>
> It would be nice to detect it at configuration time, but configure
> doesn't really look at the compiler version. One half of the build
> framework does decipher the compiler version and that could be leveraged
> to change the optimization flags for gcc 4.9, but the other half of the
> build framework does not. Unfortunately there are two instances where
> this is broken, and the fix needs to be done in both places.
>
> I maintain the FreeBSD port and the approach that I took for package
> building is to detect the use of gcc 4.9 in the port Makefile, and then
> patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is
> detected. I didn't need to patch unxfbdx.mk because it uses -O2
> optimization on x86_64.
>
>> Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475
>> (where a patch by Ariel is available, but operates at a C++ code level
>> and not at a Makefile level)?
>
> Yes. Early on I saw the LibreOffice folks do something similar, but I
> was not able to get that to work reliably and switched to -O0
> optmization for a long time. My workaround above is fairly recent.
As I recall, when I tried something similar to the patch in the bug
report, it fixed the problem on x86_64, but not intel. The problem
potentially affects two files, fmgridif.cxx and ColumnControl.cxx. The
out of the box build on FreeBSD builds one of those with -Os and the
other with -O2 on x86_64. Since the gcc bug is only triggered when
using -Os, only one of the resulting .o files has the problem, and it is
fixed by the patch. On intel, both files are built with -Os, so both
.o files have the problem. The patch fixed one of them and the
undefined symbols were exported, but they were exported as weak symbols
and were not visible outside of the shared library that the .o file was
linked into. The .o file that remained broken was linked into another
shared library and wasn't able to see the symbols from the "fixed" .o
file.
Patching the source to attempt to export these symbols is the wrong
thing to do in any case. These are for class methods that are defined
in the class declaration, so the expectation is that the compiler will
inline them wherever they are used.
There are some hooks in the build specific files with optimization
disabled, so adding the above two files to that list is one possible
fix, though I don't know if that hook is present in both parts of the
build framework, but it looks like it is.
Another possibility is to globally change "-Os" to "-Os
-fno-devirtualize -fno-devirtualize-speculatively" when building with
gcc. On the solenv/inc side, this would involve patching these files:
os2.mk
unxfbsdi.mk
unxfbsdppc.mk
unxlngi.mk
unxlngm68k.mk
unxlngmips.mk
unxlngppc.mk
unxlngr.mk
unxlngs.mk
Since CCUMVER is available, this could be made conditional on the
gcc version.
On the gbuild/platform side, the files to change are:
freebsd.mk
linux.mk
os2.mk
winmingw.mk
Since CCNUMBER is not available here, the optmiization change would
affect all gcc versions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
