http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #30 from Jan Hubicka ---
BTW the first parameter is this pointer ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #29 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
>
> --- Comment #28 from Martin Liška ---
> Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
> is marked with '>', address: 0x2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #28 from Martin Liška ---
Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
is marked with '>', address: 0x2aaab390c19d
+
B+ ¦0x2aaab390c180 <_ZN10ScDocument7CalcAllEv> push %r15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #27 from Jan Hubicka ---
It is difficult to say why the unit test fails. Would be possible to run it in
GDB and figure out why it segfaults?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #26 from Martin Liška ---
Unit tests error:
Program received signal SIGSEGV, Segmentation fault.
0x2aaab39189ed in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
(gdb) bt
#0 0x2aaab39189ed i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #24 from Jan Hubicka ---
S=/home/marxin/libreoffice && O=$S/solver/unxlngx6.pro &&
W=$S/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto
-fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin
'-Wl,-rpath,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #23 from Martin Liška ---
The patch fixed weakrefs problems.
Compilation goes further and some undefined stuff in libreoffice is met:
https://bugs.freedesktop.org/show_bug.cgi?id=61627
I think this gcc bug could be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #20 from Martin Liška ---
Looks like the compilation goes further, but another gcc_assert is reached:
0x51f015 add_symbol_to_partition_1
../../gcc/lto/lto-partition.c:187
0x51f5ba lto_balanced_map()
../../gcc/lto/lto-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #19 from Jan Hubicka ---
Ok, I got a self contained testcase for this and indeed, it is safe to remove
that assert. In fact it is yet another problem with weakrefs: we have weakrefs
that are referring locally defined studd and we have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #18 from Jan Hubicka ---
> Callstack:
> [build CXX] store/source/stortree.cxx
> lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:566
> 0x52004f lto_balanced_map()
> ../../gcc/lto/lto-partition.c:566
M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #17 from Martin Liška ---
I tried to apply suggested patch, but following gcc_assert was thrown:
https://github.com/marxin/gcc/blob/master/gcc/lto/lto-partition.c#L564
Callstack:
[build CXX] store/source/stortree.cxx
lto1: internal c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #16 from Jan Hubicka ---
OK, I think I found the bug. Weakrefs are considered to be external but they
need to be duplicated. Does the following fix the problem?
Index: lto-partition.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #15 from Jan Hubicka ---
Hmm, this still does not seem helpful.
mkdir -p
/home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/Dep/CxxObject/comphelper/source/property/
&& echo
"/home/marxin/Programming/libreoffice/workdir/unxlngx6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #14 from Martin Liška 2013-05-03
17:00:19 UTC ---
Created attachment 30027
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30027
Build log1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #13 from Martin Liška 2013-05-03
16:59:42 UTC ---
I attached build log where compilation is aborted after calling
add_symbol_to_partition_1 of FieldCacheImpl.o.
If it is not useful, please tell me how to provide more verbose details
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #12 from Jan Hubicka 2013-05-03 16:48:41
UTC ---
> Hi,
>you are right, the symbol is also missing in FieldCacheImpl.o.
>
> Unlike FieldCacheImpl.o, propagg.o really contains symbol:
> _ZNSt11_Tuple_implILm0EJRKiEEC1Ev
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #11 from Martin Liška 2013-05-03
15:22:15 UTC ---
Created attachment 30025
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30025
Preprocessed propag.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #10 from Martin Liška 2013-05-03
15:19:08 UTC ---
Hi,
you are right, the symbol is also missing in FieldCacheImpl.o.
Unlike FieldCacheImpl.o, propagg.o really contains symbol:
_ZNSt11_Tuple_implILm0EJRKiEEC1Ev
I'm going to attac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #9 from Jan Hubicka 2013-05-03 14:19:22 UTC
---
Hi,
I can not find any symbol
ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev in the
preprocessed file you added. Can you check if the symbol appears in LTO symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #8 from Martin Liška 2013-05-03
13:07:56 UTC ---
Flags:
g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE
-DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS
-D_REENTRANT -DRTL_USING -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #7 from Jan Hubicka 2013-05-03 13:03:32 UTC
---
Hmm, not weakref but really weak alias of external function. This seems even
more weird.
What are the flags used to compile the .o file?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #6 from Martin Liška 2013-05-03
12:44:44 UTC ---
Created attachment 30020
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30020
FieldCacheImpl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #5 from Martin Liška 2013-05-03
12:43:56 UTC ---
Looks like the problem has many occurrences in CLucene:
_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876
(_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #4 from Jan Hubicka 2013-05-03 12:15:48 UTC
---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
>
> --- Comment #3 from Martin Liška 2013-05-03
> 11:20:00 UTC ---
> lto-partition.c:265 (add_symbol_to_partition)
>
> c++filt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #3 from Martin Liška 2013-05-03
11:20:00 UTC ---
lto-partition.c:265 (add_symbol_to_partition)
c++filt:
std::_Tuple_impl<0ul, int const&>::_Tuple_impl()
dump_symtab_node:
_ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (_ZNSt11_Tuple_impl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #2 from Martin Liška 2013-04-26
09:23:58 UTC ---
So the symbol is really external :
c++filt:
std::_Tuple_impl<0ul, int const&>::_Tuple_impl()
dump_symbol_node:
_ZNSt11_Tuple_implILm0EIRKiEEC1Ev/279814 (__comp_ctor ) @0x7fd6b26766f0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #1 from Jan Hubicka 2013-04-24
13:35:36 UTC ---
Hmm, the failing test is:
/* Be sure that we never try to duplicate partitioned symbol
or add external symbol. */
gcc_assert (c != SYMBOL_EXTERNAL
&& (
30 matches
Mail list logo
