public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire @ 2015-01-27 2:48 lukebenes at hotmail dot com 2015-01-27 6:48 ` [Bug regression/64812] " trippels at gcc dot gnu.org ` (11 more replies) 0 siblings, 12 replies; 13+ messages in thread From: lukebenes at hotmail dot com @ 2015-01-27 2:48 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com @ 2015-01-27 6:48 ` trippels at gcc dot gnu.org 2015-01-27 6:56 ` trippels at gcc dot gnu.org ` (10 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: trippels at gcc dot gnu.org @ 2015-01-27 6:48 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com 2015-01-27 6:48 ` [Bug regression/64812] " trippels at gcc dot gnu.org @ 2015-01-27 6:56 ` trippels at gcc dot gnu.org 2015-01-27 11:11 ` rguenth at gcc dot gnu.org ` (9 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: trippels at gcc dot gnu.org @ 2015-01-27 6:56 UTC (permalink / raw) To: gcc-bugs 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.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com 2015-01-27 6:48 ` [Bug regression/64812] " trippels at gcc dot gnu.org 2015-01-27 6:56 ` trippels at gcc dot gnu.org @ 2015-01-27 11:11 ` rguenth at gcc dot gnu.org 2015-02-04 9:33 ` timo.teras at iki dot fi ` (8 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: rguenth at gcc dot gnu.org @ 2015-01-27 11:11 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (2 preceding siblings ...) 2015-01-27 11:11 ` rguenth at gcc dot gnu.org @ 2015-02-04 9:33 ` timo.teras at iki dot fi 2015-02-13 18:04 ` basile at opensource dot dyc.edu ` (7 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: timo.teras at iki dot fi @ 2015-02-04 9:33 UTC (permalink / raw) To: gcc-bugs 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)); ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (3 preceding siblings ...) 2015-02-04 9:33 ` timo.teras at iki dot fi @ 2015-02-13 18:04 ` basile at opensource dot dyc.edu 2015-02-16 14:10 ` mstahl at redhat dot com ` (6 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: basile at opensource dot dyc.edu @ 2015-02-13 18:04 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (4 preceding siblings ...) 2015-02-13 18:04 ` basile at opensource dot dyc.edu @ 2015-02-16 14:10 ` mstahl at redhat dot com 2015-02-16 14:14 ` mstahl at redhat dot com ` (5 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: mstahl at redhat dot com @ 2015-02-16 14:10 UTC (permalink / raw) To: gcc-bugs 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() ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (5 preceding siblings ...) 2015-02-16 14:10 ` mstahl at redhat dot com @ 2015-02-16 14:14 ` mstahl at redhat dot com 2015-02-27 8:39 ` [Bug ipa/64812] " trippels at gcc dot gnu.org ` (4 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: mstahl at redhat dot com @ 2015-02-16 14:14 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (6 preceding siblings ...) 2015-02-16 14:14 ` mstahl at redhat dot com @ 2015-02-27 8:39 ` trippels at gcc dot gnu.org 2015-02-27 14:23 ` mstahl at redhat dot com ` (3 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: trippels at gcc dot gnu.org @ 2015-02-27 8:39 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (7 preceding siblings ...) 2015-02-27 8:39 ` [Bug ipa/64812] " trippels at gcc dot gnu.org @ 2015-02-27 14:23 ` mstahl at redhat dot com 2015-02-27 14:48 ` trippels at gcc dot gnu.org ` (2 subsequent siblings) 11 siblings, 0 replies; 13+ messages in thread From: mstahl at redhat dot com @ 2015-02-27 14:23 UTC (permalink / raw) To: gcc-bugs 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (8 preceding siblings ...) 2015-02-27 14:23 ` mstahl at redhat dot com @ 2015-02-27 14:48 ` trippels at gcc dot gnu.org 2015-06-26 20:18 ` jakub at gcc dot gnu.org 2015-06-26 20:39 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: trippels at gcc dot gnu.org @ 2015-02-27 14:48 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (9 preceding siblings ...) 2015-02-27 14:48 ` trippels at gcc dot gnu.org @ 2015-06-26 20:18 ` jakub at gcc dot gnu.org 2015-06-26 20:39 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2015-06-26 20:18 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com ` (10 preceding siblings ...) 2015-06-26 20:18 ` jakub at gcc dot gnu.org @ 2015-06-26 20:39 ` jakub at gcc dot gnu.org 11 siblings, 0 replies; 13+ messages in thread From: jakub at gcc dot gnu.org @ 2015-06-26 20:39 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-06-26 20:38 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-27 2:48 [Bug regression/64812] New: [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire lukebenes at hotmail dot com 2015-01-27 6:48 ` [Bug regression/64812] " trippels at gcc dot gnu.org 2015-01-27 6:56 ` trippels at gcc dot gnu.org 2015-01-27 11:11 ` rguenth at gcc dot gnu.org 2015-02-04 9:33 ` timo.teras at iki dot fi 2015-02-13 18:04 ` basile at opensource dot dyc.edu 2015-02-16 14:10 ` mstahl at redhat dot com 2015-02-16 14:14 ` mstahl at redhat dot com 2015-02-27 8:39 ` [Bug ipa/64812] " trippels at gcc dot gnu.org 2015-02-27 14:23 ` mstahl at redhat dot com 2015-02-27 14:48 ` trippels at gcc dot gnu.org 2015-06-26 20:18 ` jakub at gcc dot gnu.org 2015-06-26 20:39 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).