[Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[lukebenes at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

            Bug ID: 64812
           Summary: [4.9 regression] x86 LibreOffice Build failure:
                    undefined reference to acquire
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lukebenes at hotmail dot com

LibreOffice 4.2 or newer fails to build in a clean build environment on Linux
x86-32 with gcc 4.9.0, 4.9.1, and 4.9.2. However, the build succeeds on an
otherwise identical x86-64 system, and it also succeeds with gcc 4.8.2 (on
x86-32 and x86-64). The build also succeeds with clang 3.4 (on x86-32 and
x86-64).

The same errors appear in two places (svx and dbaccess), both times referring
to classes from toolkit/source/helper/listenermultiplexer.cxx, which compiled
fine without warnings.

Steps to reproduce on x86 NOT x86-64:
1. $ git clone git://anongit.freedesktop.org/libreoffice/core
2. $ git checkout libreoffice-4-4-0 (optional, master fails with same errors)
3. $ apt-get build-dep libreoffice ( also lo_usefull Shell Script if missing
dep)
4 ./autogen.sh && make

Build log:

/src/libreoffice-4.2.3.3/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: In
function
`FmXGridControl::createPeer(com::sun::star::uno::Reference<com::sun::star::awt::XToolkit>
const&, com::sun::star::uno::Reference<com::sun::star::awt::XWindowPeer>
const&)':
fmgridif.cxx:(.text+0x7f5a): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
fmgridif.cxx:(.text+0x7fb5): undefined reference to `non-virtual thunk to
FocusListenerMultiplexer::acquire()'
fmgridif.cxx:(.text+0x8010): undefined reference to `non-virtual thunk to
KeyListenerMultiplexer::acquire()'
fmgridif.cxx:(.text+0x806b): undefined reference to `non-virtual thunk to
MouseListenerMultiplexer::acquire()'
fmgridif.cxx:(.text+0x80c6): undefined reference to `non-virtual thunk to
MouseMotionListenerMultiplexer::acquire()'
fmgridif.cxx:(.text+0x8121): undefined reference to `non-virtual thunk to
PaintListenerMultiplexer::acquire()'
collect2: error: ld returned 1 exit status
/src/libreoffice-4.2.3.3/svx/Library_svxcore.mk:20: recipe for target
'/src/libreoffice-4.2.3.3/instdir/program/libsvxcorelo.so' failed
make[1]: *** [/src/libreoffice-4.2.3.3/instdir/program/libsvxcorelo.so] Error 1

/src/libreoffice-4.2.3.3/workdir/CxxObject/dbaccess/source/ui/uno/ColumnControl.o:
In function `.L362':
ColumnControl.cxx:(.text+0x1588): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
ColumnControl.cxx:(.text+0x15d6): undefined reference to `non-virtual thunk to
FocusListenerMultiplexer::acquire()'
ColumnControl.cxx:(.text+0x1624): undefined reference to `non-virtual thunk to
KeyListenerMultiplexer::acquire()'
ColumnControl.cxx:(.text+0x1672): undefined reference to `non-virtual thunk to
MouseListenerMultiplexer::acquire()'
ColumnControl.cxx:(.text+0x16c0): undefined reference to `non-virtual thunk to
MouseMotionListenerMultiplexer::acquire()'
ColumnControl.cxx:(.text+0x170e): undefined reference to `non-virtual thunk to
PaintListenerMultiplexer::acquire()'
collect2: error: ld returned 1 exit status
/src/libreoffice-4.2.3.3/dbaccess/Library_dbu.mk:10: recipe for target
'/src/libreoffice-4.2.3.3/instdir/program/libdbulo.so' failed
make[1]: *** [/src/libreoffice-4.2.3.3/instdir/program/libdbulo.so] Error 1

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-01-27
                 CC|                            |trippels at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Please try to narrow down the issue and attach prepossessed testcases
(of fmgridif.cxx and ColumnControl.cxx for a start).
Also find out where the `non-virtual thunk to
WindowListenerMultiplexer::acquire()' comes from in a successful build.
(add -Wl,--no-demangle to the link command, and search object files 
for the unmangled symbol.)

Nobody will git clone LibreOffice just to reproduce the problem.

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #1)
> Please try to narrow down the issue and attach prepossessed testcases
> (of fmgridif.cxx and ColumnControl.cxx for a start).
> Also find out where the `non-virtual thunk to
> WindowListenerMultiplexer::acquire()' comes from in a successful build.
> (add -Wl,--no-demangle to the link command, and search object files 
> for the unmangled symbol.)

Sorry, this should read:

Please try to narrow down the issue and attach preprocessed testcases
(of fmgridif.cxx and ColumnControl.cxx for a start).
Also find out where the `non-virtual thunk to
WindowListenerMultiplexer::acquire()' comes from in a successful build.
(add -Wl,--no-demangle to the link command, and search object files 
for the mangled symbol.)

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*
      Known to work|                            |4.8.2
   Target Milestone|---                         |4.9.3
      Known to fail|                            |4.9.0, 4.9.2

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[timo.teras at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Timo Teräs <timo.teras at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timo.teras at iki dot fi

--- Comment #3 from Timo Teräs <timo.teras at iki dot fi> ---
I can reproduce this, but unfortunately I don't have minimalistic test case
yet.

As a workaround removing -fvisibility-inlines-hidden from the build flags,
makes things work in the libreoffice.

What is involved / happening is:

The non-virtual thunks are in a DSO, but marked hidden. This is caused by
-fvisibility-inlines-hidden. The ::acquire members are virtual, but with inline
implementation (no inline marking / attribute though). The class itself is
marked __attribute__((visibility("default"))).

It appears that the places getting these unresolved symbols are trying to call
external symbol, even though it's inline implementation.

Apparently optimization flags, code context affects when this happens.

The symptoms sounds very much similar to what was in llvm:
http://llvm.org/bugs/show_bug.cgi?id=12255
>From gcc-bugs-return-475970-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 04 09:35:29 2015
Return-Path: <gcc-bugs-return-475970-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9548 invoked by alias); 4 Feb 2015 09:35:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9478 invoked by uid 48); 4 Feb 2015 09:35:23 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/64932] [4.9/5.0 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
Date: Wed, 04 Feb 2015 09:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone short_desc
Message-ID: <bug-64932-4-vvmgziFkPa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64932-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64932-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00303.txt.bz2
Content-length: 886

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd932

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.3
            Summary|[5.0] ICE on module end,    |[4.9/5.0 Regression] ICE in
                   |gfc_conv_descriptor_data_ge |gfc_conv_descriptor_data_ge
                   |t                           |t for generated finalizer

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The problem seems to occur in the finalizer, i.e. __final_coo_graphs_Coo_graph
for the component ref (ptr2 is of type coo_graph):

  ptr2->edges

which is an array_type - but with fixed bounds; it fails in
gfc_conv_descriptor_data_get for line

157       gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[basile at opensource dot dyc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Anthony G. Basile <basile at opensource dot dyc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |basile at opensource dot dyc.edu

--- Comment #4 from Anthony G. Basile <basile at opensource dot dyc.edu> ---
(In reply to Luke from comment #0)
> LibreOffice 4.2 or newer fails to build in a clean build environment on
> Linux x86-32 with gcc 4.9.0, 4.9.1, and 4.9.2. However, the build succeeds
> on an otherwise identical x86-64 system, and it also succeeds with gcc 4.8.2
> (on x86-32 and x86-64). The build also succeeds with clang 3.4 (on x86-32
> and x86-64).
> 

We are seeing this in gentoo on x86_64 with gcc-4.9.  See

https://bugs.gentoo.org/show_bug.cgi?id=538348

(In reply to Timo Teräs from comment #3)
> As a workaround removing -fvisibility-inlines-hidden from the build flags,
> makes things work in the libreoffice.

What's confusing me is that some of our users are seeing this bug and others
are not.  This leads me to think maybe its a c++ abi mismatch because we do
allow our users to build their systems using any recent version of gcc (and c++
abi emitted by 4.8 is not compatbile with that emitted by 4.9).  However, that
fact tat removing -fvisibility-inlines-hidden fixes this argues against my
suspicion.  So why would some of our users it this and others not?
>From gcc-bugs-return-477197-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 13 18:22:59 2015
Return-Path: <gcc-bugs-return-477197-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26529 invoked by alias); 13 Feb 2015 18:22:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26508 invoked by uid 48); 13 Feb 2015 18:22:54 -0000
From: "linux at horizon dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/65056] New: Missed optimization (x86): Redundant test/compare after arithmetic operations
Date: Fri, 13 Feb 2015 18:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linux at horizon dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_file_loc bug_status bug_severity priority component assigned_to reporter cf_gcchost cf_gcctarget
Message-ID: <bug-65056-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg01530.txt.bz2
Content-length: 5610

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide056

            Bug ID: 65056
           Summary: Missed optimization (x86): Redundant test/compare
                    after arithmetic operations
           Product: gcc
           Version: 5.0
               URL: http://marc.info/?l=linux-kernel&m\x142373514630907
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linux at horizon dot com
              Host: i586-linux-gnu
            Target: x86_64-*-*, i?86-*-*

The following code seems to miss some really obvious optimizations on
x86, both in -m32 and -m64.  Gcc is generating separate test & compare
instruction for conditions which are available in the condition codes set by
preceding arithmetic operations.

Bugs #30455 and #31799 are similar, but the problems there are caused by a
memory destination, which isn't the case here.

This happens with -O2, -O3 and -Os and with various models specified, so it
doesn't appear to be some obscure model-specific optimization.

Versions tested:
* gcc (Debian 4.9.2-10) 4.9.2
* gcc-5 (Debian 5-20150205-1) 5.0.0 20150205 (experimental) [trunk revision
220455]
* gcc (Debian 20150211-1) 5.0.0 20150211 (experimental) [trunk revision 220605]

#include <stddef.h>

#define BITS_PER_LONG (8 * sizeof(long))
#define DIV_ROUND_UP(x,n) (((x) + (n) - 1) / (n))
#define LAST_WORD_MASK(x) (~0ull >> (-(x) & BITS_PER_LONG - 1))

/*
 * __fls: find last set bit in word
 * @word: The word to search
 *
 * Undefined if no set bit exists, so code should check against 0 first.
 */
static inline unsigned long __fls(unsigned long word)
{
    asm("bsr %1,%0"
        : "=r" (word)
        : "rm" (word));
    return word;
}

size_t find_last_bit(const unsigned long *addr, size_t size)
{
    size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);
    unsigned long mask = LAST_WORD_MASK(size);

    while (idx--) {
        unsigned long val = addr[idx] & mask;
        if (val)
            return idx * BITS_PER_LONG + __fls(val);
        mask = ~0ul;
    }
    return size;
}

The code generated is (-m32 is equivalent):

    .file    "flb.c"
    .section    .text.unlikely,"ax",@progbits
.LCOLDB0:
    .text
.LHOTB0:
    .p2align 4,,15
    .globl    find_last_bit
    .type    find_last_bit, @function
find_last_bit:
.LFB1:
    .cfi_startproc
    movl    %esi, %ecx
    leaq    63(%rsi), %rdx
    movq    $-1, %r8
    negl    %ecx
    shrq    %cl, %r8
    shrq    $6, %rdx
    movq    %r8, %rcx
    jmp    .L2
    .p2align 4,,10
    .p2align 3
.L4:
    andq    (%rdi,%rdx,8), %rcx
    movq    %rcx, %r8
    movq    $-1, %rcx
    testq    %r8, %r8
    jne    .L8
.L2:
    subq    $1, %rdx
    cmpq    $-1, %rdx
    jne    .L4
    movq    %rsi, %rax
    ret
    .p2align 4,,10
    .p2align 3
.L8:
    salq    $6, %rdx
#APP
# 15 "flb.c" 1
    bsr %r8,%r8
# 0 "" 2
#NO_APP
    leaq    (%rdx,%r8), %rax
    ret
    .cfi_endproc
.LFE1:
    .size    find_last_bit, .-find_last_bit
    .section    .text.unlikely
.LCOLDE0:
    .text
.LHOTE0:
    .ident    "GCC: (Debian 20150211-1) 5.0.0 20150211 (experimental) [trunk
revision 220605]"
    .section    .note.GNU-stack,"",@progbits

In the loop at .L4, there's a completely unnecessary "movq %rcx, %r8;
testq %r8, %r8", when the jne could go right after the andq (and the
code at .L8 changed to expect the masked value in %rcx rather than %r8).

At .L2, it's even more ridiculous.  The subq generates a borrow if the value
wraps to -1.  Why is that not just "subq $1, %rdx; jnc .L4"?

A smarter compiler would notice that %rdx must have its top 6 bits clear
and thus "decq %rdx; jpl .L4" would also be legal.  (For non-x86 weenies,
the "dec" instructions do not modify the carry flag, originally so they
could be used for loop control in multi-word arithmetic.  This partial flags
update makes them slower than "subq $1" on many processors, so which is used
depends on the model flags.)

I tried reorganizing the source to encourage the first optimization:

size_t find_last_bit2(const unsigned long *addr, size_t size)
{
    unsigned long val = LAST_WORD_MASK(size);
    size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);

    while (idx--) {
        val &= addr[idx];
        if (val)
            return idx * BITS_PER_LONG + __fls(val);
        val = ~0ul;
    }
    return size;
}

... but the generated code is identical.


This version:

size_t find_last_bit3(const unsigned long *addr, size_t size)
{
    if (size) {
        unsigned long val = LAST_WORD_MASK(size);
        size_t idx = (size-1) / BITS_PER_LONG;

        do {
            val &= addr[idx];
            if (val)
                return idx * BITS_PER_LONG + __fls(val);
            val = ~0ul;
        } while (idx--);
    }
    return size;
}

Makes the first optimziation, and is at least clever with the second, but it's
still three instructions rather than two for an absolutely bog-standard
decrement loop:

find_last_bit3:
.LFB3:
    .cfi_startproc
    xorl    %eax, %eax
    testq    %rsi, %rsi
    je    .L17
    movl    %esi, %ecx
    leaq    -1(%rsi), %rax
    movq    $-1, %rdx
    negl    %ecx
    shrq    %cl, %rdx
    shrq    $6, %rax
    jmp    .L19
    .p2align 4,,10
    .p2align 3
.L18:
    subq    $1, %rax
    movq    $-1, %rdx
    cmpq    %rdx, %rax
    je    .L23
.L19:
    andq    (%rdi,%rax,8), %rdx
    je    .L18
    salq    $6, %rax
#APP
# 15 "flb.c" 1
    bsr %rdx,%rdx
# 0 "" 2
#NO_APP
    addq    %rdx, %rax
    ret
    .p2align 4,,10
    .p2align 3
.L23:
    movq    %rsi, %rax
.L17:
    rep ret

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Michael Stahl <mstahl at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |caolanm at redhat dot com,
                   |                            |mstahl at redhat dot com,
                   |                            |sbergman at redhat dot com

--- Comment #5 from Michael Stahl <mstahl at redhat dot com> ---
the problem is that with -Os, the inline method
 WindowListenerMultiplexer::acquire()
results in an undefined symbol, whereas with -O2
weak symbols are emitted into the object.

can reproduce this with:

gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)

the command line parameters for compilation in the build system were:

g++ -m32 -fvisibility=hidden -fmessage-length=0 -fno-common
-fvisibility-inlines-hidden -fstack-protector-strong -fPIC -std=gnu++11  -ggdb2
 -fexceptions -fno-enforce-eh-specs -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

the minimal command line parameters to trigger the bug:

> g++ -m32 -std=gnu++11 -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

> nm --demangle /tmp/fmgridif.o | grep WindowListenerMultiplexer
         U non-virtual thunk to WindowListenerMultiplexer::acquire()

the minimal command line parameters to avoid the bug:

> g++ -m32 -std=gnu++11 -O2 -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

> nm --demangle /tmp/fmgridif.o | grep WindowListenerMultiplexer
00000000 W WindowListenerMultiplexer::acquire()
00000020 W non-virtual thunk to WindowListenerMultiplexer::acquire()

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

--- Comment #6 from Michael Stahl <mstahl at redhat dot com> ---
Created attachment 34780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34780&action=edit
manually minimized reproducer

to reproduce, build with:
 g++ -m32 -std=gnu++11 -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

--- Comment #8 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Also happens with gcc-5 when linking two different LibreOffice libraries.
(libscfiltlo.so and libooxlo.so)

The undefined symbol is:
x4 ~ # c++filt _ZThn40_N3utl28OSeekableOutputStreamWrapper7acquireEv
non-virtual thunk to utl::OSeekableOutputStreamWrapper::acquire()

But the symbol is defined in
workdir/CxxObject/unotools/source/streaming/streamwrap.o
and adding this object file to the link object file list fixes the problem.

So it looks like a LibreOffice issue in this case.

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Michael Stahl <mstahl at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtardon at redhat dot com

--- Comment #9 from Michael Stahl <mstahl at redhat dot com> ---
(In reply to Markus Trippelsdorf from comment #8)
> Also happens with gcc-5 when linking two different LibreOffice libraries.
> (libscfiltlo.so and libooxlo.so)
> 
> The undefined symbol is:
> x4 ~ # c++filt _ZThn40_N3utl28OSeekableOutputStreamWrapper7acquireEv
> non-virtual thunk to utl::OSeekableOutputStreamWrapper::acquire()

interesting ... you are building LO 4.4.1.1 or older?

looking at the git log there is this apparent work-around:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bb0446974282b32d06cdbd35af83f91e033b4af

not sure if it's the same bug... in case this is triggered by some sort
of de-virtualization new in GCC5 then i guess it is LO's fault
because the acquire() / release() was not dll-exported.

i will push that to the libreoffice-4-3 release branch to get it into 4.3.7.

(i've only tried to build current master, which works fine now with
workaround for the bug from the description)

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

--- Comment #10 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Michael Stahl from comment #9)
> interesting ... you are building LO 4.4.1.1 or older? 

4.4.1.2

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4