* [Bug c++/59775] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
@ 2014-01-12 17:01 ` nheghathivhistha at gmail dot com
2014-01-12 17:24 ` nheghathivhistha at gmail dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: nheghathivhistha at gmail dot com @ 2014-01-12 17:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #2 from David Kredba <nheghathivhistha at gmail dot com> ---
$O, $W and $S expanded command to compiler is
x86_64-pc-linux-gnu-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 -DOOX_DLLIMPLEMENTATION
-DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels
-Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -save-temps
-fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow
-Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON
-fexceptions -fno-enforce-eh-specs -fPIC -O2 -ggdb -march=native -mtune=native
-flto=4 -fuse-linker-plugin -mno-avx -mno-sse4.2 -mno-3dnow -fno-lto
-fno-use-linker-plugin -c
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/recordparser.cxx
-o ./recordparser.o
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/oox/source/core/
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/solver/unxlngx6.pro/inc/external
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/solver/unxlngx6.pro/inc
-I/usr/lib64/icedtea7/include -I/usr/lib64/icedtea7/include/linux
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/config_host
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CustomTarget/oox/generated
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc/UnoApiHeadersTarget/udkapi/normal
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/inc/UnoApiHeadersTarget/offapi/normal
-I/usr/include -I
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/UnoApiHeadersTarget/udkapi/normal
-I/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/UnoApiHeadersTarget/offapi/normal
Reducing it with x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -std=gnu++0x -c.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/59775] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
2014-01-12 17:01 ` [Bug c++/59775] " nheghathivhistha at gmail dot com
@ 2014-01-12 17:24 ` nheghathivhistha at gmail dot com
2014-01-12 17:25 ` nheghathivhistha at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: nheghathivhistha at gmail dot com @ 2014-01-12 17:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #3 from David Kredba <nheghathivhistha at gmail dot com> ---
typedef int sal_Int8;
typedef int sal_Int64;
namespace com
{
namespace sun
{
namespace star
{
namespace uno
{
template < class > class Sequence
{
};
}
}
} typedef com::sun::star::uno::Sequence < sal_Int8 > StreamDataSequence;
class BinaryStreamBase
{
public:
virtual void seek (sal_Int64);
void seekToStart ()
{
seek (0);
} int mbEof;
};
class BinaryInputStream:public virtual BinaryStreamBase
{
};
class SequenceInputStream:public BinaryInputStream
{
public:
SequenceInputStream (StreamDataSequence &);
};
namespace core
{
void RecordParserparseStream ()
{
StreamDataSequence aRecData;
SequenceInputStream aRecStrm (aRecData);
aRecStrm.seekToStart ();
}
}
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/59775] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
2014-01-12 17:01 ` [Bug c++/59775] " nheghathivhistha at gmail dot com
2014-01-12 17:24 ` nheghathivhistha at gmail dot com
@ 2014-01-12 17:25 ` nheghathivhistha at gmail dot com
2014-01-12 18:57 ` trippels at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: nheghathivhistha at gmail dot com @ 2014-01-12 17:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #4 from David Kredba <nheghathivhistha at gmail dot com> ---
Created attachment 31812
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31812&action=edit
(c-)Reduced testcase
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/59775] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (2 preceding siblings ...)
2014-01-12 17:25 ` nheghathivhistha at gmail dot com
@ 2014-01-12 18:57 ` trippels at gcc dot gnu.org
2014-01-12 19:44 ` [Bug ipa/59775] [4.9 Regression] " jakub at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-12 18:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-01-12
CC| |hubicka at gcc dot gnu.org,
| |trippels at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Confirmed.
A bit more reduced:
markus@x4 /tmp % cat test.ii
class A {
public:
virtual void m_fn1();
void m_fn2() { m_fn1(); }
int mbEof;
};
class B : public virtual A {};
class C : public B {
public:
C(int &);
};
int a;
void fn1() {
C b(a);
b.m_fn2();
}
Started with r206061.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (3 preceding siblings ...)
2014-01-12 18:57 ` trippels at gcc dot gnu.org
@ 2014-01-12 19:44 ` jakub at gcc dot gnu.org
2014-01-12 22:26 ` hubicka at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-12 19:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've reduced it to:
struct A
{
virtual void foo () = 0;
void bar () { foo (); }
bool a;
};
struct B : public virtual A
{
virtual void foo ();
};
struct C : public B
{
C ();
};
void
baz ()
{
C c;
c.bar ();
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (4 preceding siblings ...)
2014-01-12 19:44 ` [Bug ipa/59775] [4.9 Regression] " jakub at gcc dot gnu.org
@ 2014-01-12 22:26 ` hubicka at gcc dot gnu.org
2014-01-12 22:49 ` hubicka at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2014-01-12 22:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
mine.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (5 preceding siblings ...)
2014-01-12 22:26 ` hubicka at gcc dot gnu.org
@ 2014-01-12 22:49 ` hubicka at gcc dot gnu.org
2014-01-12 23:37 ` hubicka at ucw dot cz
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2014-01-12 22:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK,
this testcase shows the get_binfo_at_offset bug I mentioned in the first
virtual inheritance PR.
We call get_binfo_at_offset for binfo of C looking for A at offset 64. This is
correct query, but becase get_binfo_at_offsets walks fields and then it tries
to match binfos, it actually looks up field representing A already in C and
does not find A among direct bases of C.
I suppose we will need to dive into the bases in get_binfo_at_offset same way
as ipa-devirt does.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (6 preceding siblings ...)
2014-01-12 22:49 ` hubicka at gcc dot gnu.org
@ 2014-01-12 23:37 ` hubicka at ucw dot cz
2014-01-14 8:36 ` nheghathivhistha at gmail dot com
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at ucw dot cz @ 2014-01-12 23:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> ---
This is fix I am testing. It makes get_binfo_at_offset to walk down the
non-virtual
part of the hiearchy until it hits the proper base.
I hope to significantly simplify get_binfo_at_offset by making it to walk bases
only and use get_class_context to walk structure fields/array indexes. In that
case
it would make more sense to implement it same was as record_target_from_binfo
(i.e.
omit the fields walk completely and only care about bases), but for 4.9 I think
this
can be resonable fix.
Honza
Index: tree.c
===================================================================
--- tree.c (revision 206542)
+++ tree.c (working copy)
@@ -11995,16 +11995,35 @@ get_binfo_at_offset (tree binfo, HOST_WI
represented in the binfo for the derived class. */
else if (offset != 0)
{
- tree base_binfo, found_binfo = NULL_TREE;
- for (i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
- if (types_same_for_odr (TREE_TYPE (base_binfo), TREE_TYPE (fld)))
- {
- found_binfo = base_binfo;
- break;
- }
- if (!found_binfo)
- return NULL_TREE;
- binfo = found_binfo;
+ tree base_binfo, binfo2 = binfo;
+
+ /* Find BINFO corresponding to FLD. This is bit harder
+ by a fact that in virtual inheritance we may need to walk down
+ the non-virtual inheritance chain. */
+ while (true)
+ {
+ tree containing_binfo = NULL, found_binfo = NULL;
+ for (i = 0; BINFO_BASE_ITERATE (binfo2, i, base_binfo); i++)
+ if (types_same_for_odr (TREE_TYPE (base_binfo), TREE_TYPE (fld)))
+ {
+ found_binfo = base_binfo;
+ break;
+ }
+ else
+ if (BINFO_OFFSET (base_binfo) - BINFO_OFFSET (binfo) < pos
+ && (!containing_binfo
+ || (BINFO_OFFSET (containing_binfo)
+ < BINFO_OFFSET (base_binfo))))
+ containing_binfo = base_binfo;
+ if (found_binfo)
+ {
+ binfo = found_binfo;
+ break;
+ }
+ if (!containing_binfo)
+ return NULL_TREE;
+ binfo2 = containing_binfo;
+ }
}
type = TREE_TYPE (fld);
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (7 preceding siblings ...)
2014-01-12 23:37 ` hubicka at ucw dot cz
@ 2014-01-14 8:36 ` nheghathivhistha at gmail dot com
2014-01-14 9:06 ` trippels at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: nheghathivhistha at gmail dot com @ 2014-01-14 8:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #10 from David Kredba <nheghathivhistha at gmail dot com> ---
After your patch applied it not segfaults any more.
Unfortunately it not builds too, link of one module fails:
[build MOD] swext
S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 &&
O=$S/solver/unxlngx6.pro && W=$S/workdir/unxlngx6.pro && mkdir -p $W/Module/ &
touch $W/Module/swext
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o:
In function `~egmentProgressBar':
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110:
undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()'
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110:
undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()'
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110:
undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()'
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o:
In function `ox::SegmentProgressBar::~SegmentProgressBar()':
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110:
undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()'
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o:
In function `~egmentProgressBar':
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110:
undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()'
collect2: error: ld returned 1 exit status
Can this be anyhow related to your patch? Or GCC at all?
Why it names the function as `~egmentProgressBar'
when there is not such?
:
objdump -x
/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookheer.o
|grep egment
372 .text.unlikely._ZN3oox18SegmentProgressBarD2Ev 00000000 0000000000000000
0000000000000000 0000d3ca 2**1
373 .text._ZN3oox18SegmentProgressBarD2Ev 00000025 0000000000000000
0000000000000000 0000d3d0 2**4
374 .text.unlikely._ZN3oox18SegmentProgressBarD0Ev 00000000 0000000000000000
0000000000000000 0000d3f6 2**1
375 .text._ZN3oox18SegmentProgressBarD0Ev 0000002d 0000000000000000
0000000000000000 0000d400 2**4
0000000000000000 l d .text.unlikely._ZN3oox18SegmentProgressBarD2Ev
0000000000000000 .text.unlikely._ZN3oox18SegmentProgressBarD2Ev
0000000000000000 l d .text._ZN3oox18SegmentProgressBarD2Ev
0000000000000000 .text._ZN3oox18SegmentProgressBarD2Ev
0000000000000000 l d .text.unlikely._ZN3oox18SegmentProgressBarD0Ev
0000000000000000 .text.unlikely._ZN3oox18SegmentProgressBarD0Ev
0000000000000000 l d .text._ZN3oox18SegmentProgressBarD0Ev
0000000000000000 .text._ZN3oox18SegmentProgressBarD0Ev
0000000000000000 l .group 0000000000000000
_ZN3oox18SegmentProgressBarD5Ev
0000000000000000 w F .text._ZN3oox18SegmentProgressBarD2Ev
0000000000000025 _ZN3oox18SegmentProgressBarD2Ev
0000000000000000 *UND* 0000000000000000 _ZTVN3oox18SegmentProgressBarE
0000000000000000 *UND* 0000000000000000
_ZN3oox19ISegmentProgressBarD2Ev
0000000000000000 w F .text._ZN3oox18SegmentProgressBarD2Ev
0000000000000025 _ZN3oox18SegmentProgressBarD1Ev
0000000000000000 w F .text._ZN3oox18SegmentProgressBarD0Ev
000000000000002d _ZN3oox18SegmentProgressBarD0Ev
0000000000000000 *UND* 0000000000000000
_ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE
00000000000058c1 R_X86_64_GOTPCREL
_ZN3oox18SegmentProgressBarD0Ev-0x0000000000000004
00000000000058ce R_X86_64_GOTPCREL
_ZTVN3oox18SegmentProgressBarE-0x0000000000000004
00000000000058e6 R_X86_64_PLT32
_ZN3oox19ISegmentProgressBarD2Ev-0x0000000000000004
00000000000069af R_X86_64_PLT32
_ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE-0x0000000000000004
00000000000069cc R_X86_64_GOTPCREL
_ZN3oox18SegmentProgressBarD0Ev-0x0000000000000004
00000000000069d9 R_X86_64_GOTPCREL
_ZTVN3oox18SegmentProgressBarE-0x0000000000000004
00000000000069f2 R_X86_64_PLT32
_ZN3oox19ISegmentProgressBarD2Ev-0x0000000000000004
0000000000006ae7 R_X86_64_PLT32
_ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE-0x0000000000000004
0000000000006b04 R_X86_64_GOTPCREL
_ZN3oox18SegmentProgressBarD0Ev-0x0000000000000004
0000000000006b11 R_X86_64_GOTPCREL
_ZTVN3oox18SegmentProgressBarE-0x0000000000000004
0000000000006b2a R_X86_64_PLT32
_ZN3oox19ISegmentProgressBarD2Ev-0x0000000000000004
RELOCATION RECORDS FOR [.text._ZN3oox18SegmentProgressBarD2Ev]:
0000000000000003 R_X86_64_GOTPCREL
_ZTVN3oox18SegmentProgressBarE-0x0000000000000004
0000000000000021 R_X86_64_PLT32
_ZN3oox19ISegmentProgressBarD2Ev-0x0000000000000004
RELOCATION RECORDS FOR [.text._ZN3oox18SegmentProgressBarD0Ev]:
0000000000000003 R_X86_64_GOTPCREL
_ZTVN3oox18SegmentProgressBarE-0x0000000000000004
0000000000000020 R_X86_64_PLT32
_ZN3oox19ISegmentProgressBarD2Ev-0x0000000000000004
000000000017cc2d R_X86_64_64 .text._ZN3oox18SegmentProgressBarD2Ev
000000000017cc53 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x000000000000001c
000000000017cc69 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000025
000000000017cc85 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
000000000017ccaf R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
000000000017cccd R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000001c
000000000017cce3 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x0000000000000024
000000000017ccf6 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000002d
0000000000022de9 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD2Ev
0000000000022df1 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x000000000000000f
0000000000022dfc R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x000000000000000f
0000000000022e04 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000020
0000000000022e0f R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000020
0000000000022e17 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000024
0000000000022e22 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000024
0000000000022e2a R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000025
0000000000022e48 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
0000000000022e50 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000000f
0000000000022e5b R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000000f
0000000000022e63 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x0000000000000028
0000000000022e6e R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x0000000000000028
0000000000022e76 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000002c
0000000000022e81 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000002c
0000000000022e89 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000002d
00000000000005d0 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD2Ev
00000000000005e0 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
000000000000b170 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
000000000000b178 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x0000000000000007
000000000000b180 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000000b
000000000000b188 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x0000000000000024
000000000000e110 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD2Ev
000000000000e118 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD2Ev+0x0000000000000025
000000000000e120 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
000000000000e128 R_X86_64_64
.text._ZN3oox18SegmentProgressBarD0Ev+0x000000000000002d
000000000000c5e5 R_X86_64_64 .text._ZN3oox18SegmentProgressBarD2Ev
000000000000c5fc R_X86_64_64 .text._ZN3oox18SegmentProgressBarD0Ev
0000000000001b90 R_X86_64_PC32 .text._ZN3oox18SegmentProgressBarD2Ev
0000000000001bac R_X86_64_PC32 .text._ZN3oox18SegmentProgressBarD0Ev
Is this binutils bug please?
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (8 preceding siblings ...)
2014-01-14 8:36 ` nheghathivhistha at gmail dot com
@ 2014-01-14 9:06 ` trippels at gcc dot gnu.org
2014-01-15 21:32 ` hubicka at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-14 9:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #11 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to David Kredba from comment #10)
> After your patch applied it not segfaults any more.
> Unfortunately it not builds too, link of one module fails:
>
> [build MOD] swext
> S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2
> && O=$S/solver/unxlngx6.pro && W=$S/workdir/unxlngx6.pro && mkdir -p
> $W/Module/ & touch $W/Module/swext
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In
> function `~egmentProgressBar':
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> include/oox/helper/progressbar.hxx:110: undefined reference to
> `oox::ISegmentProgresBar::~ISegmentProgressBar()'
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> include/oox/helper/progressbar.hxx:110: undefined reference to
> `oox::ISegmentProgresBar::~ISegmentProgressBar()'
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> include/oox/helper/progressbar.hxx:110: undefined reference to
> `oox::ISegmentProgresBar::~ISegmentProgressBar()'
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In
> function `ox::SegmentProgressBar::~SegmentProgressBar()':
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> include/oox/helper/progressbar.hxx:110: undefined reference to
> `oox::ISegmentProgresBar::~ISegmentProgressBar()'
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In
> function `~egmentProgressBar':
> /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/
> include/oox/helper/progressbar.hxx:110: undefined reference to
> `oox::ISegmentProgresBar::~ISegmentProgressBar()'
> collect2: error: ld returned 1 exit status
>
> Can this be anyhow related to your patch? Or GCC at all?
No. I ran into exactly the same issue a while ago.
"$W/CxxObject/oox/source/helper/progressbar.o" is missing in the list
of object files when linking. This is a libreoffice bug.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (9 preceding siblings ...)
2014-01-14 9:06 ` trippels at gcc dot gnu.org
@ 2014-01-15 21:32 ` hubicka at gcc dot gnu.org
2014-01-16 8:49 ` nheghathivhistha at gmail dot com
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2014-01-15 21:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, thanks for testing. I posted the patch.
How far do we get with libreoffice and LTO now? (I need to move my compilation
setup to new machine, it is on my TODO to get some statistic about
devirtualization there - or any other app that does virtual inheritance)
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (10 preceding siblings ...)
2014-01-15 21:32 ` hubicka at gcc dot gnu.org
@ 2014-01-16 8:49 ` nheghathivhistha at gmail dot com
2014-01-17 1:05 ` hubicka at gcc dot gnu.org
2014-01-17 1:07 ` hubicka at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: nheghathivhistha at gmail dot com @ 2014-01-16 8:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #13 from David Kredba <nheghathivhistha at gmail dot com> ---
I have to keep LTO still off for Libreoffice. (And for many of simple programs
that do the test for endian type the way not counting with LTO and for some
that linker is not happy with relocation(s) and a few more different case. But
the main part is fine, icluding qtwebkit-4.8.5 (with only one fine tune in one
header file) which is great!)
I think there is standalone bug for Libreoffice LTO, am I wrong? I can append
the first error seen to it.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (11 preceding siblings ...)
2014-01-16 8:49 ` nheghathivhistha at gmail dot com
@ 2014-01-17 1:05 ` hubicka at gcc dot gnu.org
2014-01-17 1:07 ` hubicka at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2014-01-17 1:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Jan 17 01:04:59 2014
New Revision: 206694
URL: http://gcc.gnu.org/viewcvs?rev=206694&root=gcc&view=rev
Log:
PR ipa/59775
* tree.c (get_binfo_at_offset): Look harder for virtual bases.
Added:
trunk/gcc/testsuite/g++.dg/torture/pr59775.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
2014-01-12 16:53 [Bug c++/59775] New: internal compiler error: Segmentation fault nheghathivhistha at gmail dot com
` (12 preceding siblings ...)
2014-01-17 1:05 ` hubicka at gcc dot gnu.org
@ 2014-01-17 1:07 ` hubicka at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2014-01-17 1:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Thanks for testing the LTO. Yes, either attach the problems to libreoffice
tracking bug (I know there is firefox and kernel, but unsure about libreoffice)
or open new PRs for those.
If Markus is wright about missing file for linking in LO, then it should be
fixed in libreoffice instead. I am just moving my setup to new computer and
will see how far I get building it myself.
This particular problem should be solved now.
^ permalink raw reply [flat|nested] 15+ messages in thread