public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance
@ 2015-06-25 13:10 antonio.poggiali at datalogic dot com
2015-06-25 17:49 ` [Bug c++/66666] " ramana at gcc dot gnu.org
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-25 13:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
Bug ID: 66666
Summary: ARM compiled code segmentation fault on multiple
inheritance
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antonio.poggiali at datalogic dot com
Target Milestone: ---
Created attachment 35854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35854&action=edit
Source files, compiled file, gcc output, etc.
Host system:
Linux MatrixPlatVb-lx-apoggiali 3.13.0-44-generic #73~precise1-Ubuntu SMP Wed
Dec 17 00:39:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Target system:
ARM cortex A5 (but same behavior on A9).
Linux sama5d4ek 3.18.0-linux4sam_5.0-alpha1 #1 Wed Jun 24 09:45:58 CEST 2015
armv7l GNU/Linux
Cross-compiler invocation and output:
Invoking: GCC C++ Compiler
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -O0 -g3 -Wall -Wextra -c
-fmessage-length=0 --sysroot=<...> -march=armv7-a -mfloat-abi=hard
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -MMD -MP
-MF"liste.d" -MT"liste.d" -o "liste.o" "liste.cpp"
Finished building:
liste.cpp
Invoking: GCC C++ Linker
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ --sysroot=<...>
-march=armv7-a -mfloat-abi=hard -o "liste" liste.o
Finished building target: liste
Input file (liste.cpp):
#include <list>
#include <iostream>
class SmartObject
{
public:
virtual ~SmartObject(){
}
void method(void) {}
};
class IMyInterface
{
public:
virtual ~IMyInterface(){
}
virtual std::list<int> getList() = 0;
};
class MyObject : public virtual IMyInterface, public SmartObject
{
public:
MyObject()
{
list.push_back(4);
list.push_back(5);
}
virtual std::list<int> getList() {
return list;
}
virtual ~MyObject(){
}
std::list<int> list;
};
int main()
{
IMyInterface * ip = new MyObject();
std::list<int> list_clone = ip->getList();
// On size() I get a segmentation fault
std::cout << list_clone.size() << std::endl;
delete ip;
return 0;
}
Stack at fault:
liste [C/C++ Remote Application]
list [1573] [cores: 0]
Thread [1] 1573 [core: 0] (Suspended : Signal :
SIGSEGV:Segmentation fault)
std::_List_const_iterator<int>::operator++() at
stl_list.h:244 0x9738
std::__distance<std::_List_const_iterator<int> >() at
stl_iterator_base_funcs.h:82 0x97d4
std::distance<std::_List_const_iterator<int> >() at
stl_iterator_base_funcs.h:118 0x9430
std::list<int, std::allocator<int> >::size() at
stl_list.h:887 0x9144
main() at liste.cpp:50 0x8a14
Comment:
The list obtained through ip->getList(); is incorrect: the tail pointer is
malformed. When size() is called the list is scanned to count the number of
elements. As the tail pointer is malformed the scan end condition is not met
and i get a segmentation fault (or an endless loop when optimization in on).
The same code works correctly on host system (x86_64-linux).
Notes:
Declaring "class MyObject : public virtual IMyInterface, public virtual
SmartObject" makes it work.
Also removing ~SmartObject() destructor makes it work.
In attachment source code and compiler outputs.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
@ 2015-06-25 17:49 ` ramana at gcc dot gnu.org
2015-06-26 7:04 ` antonio.poggiali at datalogic dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: ramana at gcc dot gnu.org @ 2015-06-25 17:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|Linux sama5d4ek |arm*-*-*
|3.18.0-linux4sam_5.0-alpha1 |
|#1 Wed Jun 24 09:45:58 CEST |
|2015 armv7l GNU/Linux |
CC| |ramana at gcc dot gnu.org
Host|Linux |x86_64-*-*
|MatrixPlatVb-lx-apoggiali |
|3.13.0-44-generic |
|#73~precise1-Ubuntu SMP Wed |
|Dec 17 00:39:15 UTC 2014 |
|x86_64 x86_64 x86_64 |
|GNU/Linux |
--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Obvious "dumb" question given this is a cross-environnment - I'm assuming that
you have the same libstdc++ in both places ?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
2015-06-25 17:49 ` [Bug c++/66666] " ramana at gcc dot gnu.org
@ 2015-06-26 7:04 ` antonio.poggiali at datalogic dot com
2015-06-26 11:23 ` antonio.poggiali at datalogic dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-26 7:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #2 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Ramana Radhakrishnan from comment #1)
> Obvious "dumb" question given this is a cross-environnment - I'm assuming
> that you have the same libstdc++ in both places ?
Yes, it is the same. I've just checked (again :-D).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
2015-06-25 17:49 ` [Bug c++/66666] " ramana at gcc dot gnu.org
2015-06-26 7:04 ` antonio.poggiali at datalogic dot com
@ 2015-06-26 11:23 ` antonio.poggiali at datalogic dot com
2015-06-26 11:24 ` antonio.poggiali at datalogic dot com
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-26 11:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #3 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
I've understand a little better the problem.
The compiler passes to std::list copy constructor a different address respect
to the destination variable.
This causes size() call to fail (endless loop or segmentation fault).
Here you can find a simpler test-bench:
#include <iostream>
using namespace std;
class TestReference
{
public:
// This is a pointer to me
const TestReference * _me;
TestReference() {
_me = this;
}
TestReference(const TestReference &obj)
{
_me = this;
}
};
class SmartObject
{
public:
SmartObject(){}
// removing this destructor makes it work
virtual ~SmartObject(){}
};
class IMyInterface
{
public:
IMyInterface(){}
// removing this destructor have no effect (fails anyway)
virtual ~IMyInterface(){}
virtual TestReference getTestReference() = 0;
};
// inheriting SmartObject virtually makes it work (but it is not feasible on
the overall application architecture)
class MyObject : public virtual IMyInterface, public SmartObject
{
public:
MyObject() : IMyInterface(), SmartObject() {}
virtual TestReference getTestReference() {
return testReference;
}
virtual ~MyObject(){
}
TestReference testReference;
};
int main()
{
IMyInterface *ip = new MyObject();
TestReference TestReference_local;
std::cout << "object address " << &TestReference_local << std::endl;
std::cout << "object address in constructor " <<
TestReference_local._me << std::endl;
if (&TestReference_local != TestReference_local._me)
std::cout << "warning! addresses are different!" << std::endl;
TestReference TestReference_clone = ip->getTestReference();
std::cout << "object address " << &TestReference_clone << std::endl;
std::cout << "object address in copy constructor " <<
TestReference_clone._me << std::endl;
if (&TestReference_clone != TestReference_clone._me)
std::cout << "warning! addresses are different!" << std::endl;
delete ip;
return 0;
}
Basically I expect the object address in the copy constructor (this) to be the
same of the object in the calling code, but when the program fails it is not
so!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (2 preceding siblings ...)
2015-06-26 11:23 ` antonio.poggiali at datalogic dot com
@ 2015-06-26 11:24 ` antonio.poggiali at datalogic dot com
2015-06-27 12:42 ` [Bug c++/66666] ARM wrong copy constructor address " mikpelinux at gmail dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-26 11:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #4 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
I've understand a little better the problem.
The compiler passes to std::list copy constructor a different address respect
to the destination variable.
This causes size() call to fail (endless loop or segmentation fault).
Here you can find a simpler test-bench:
#include <iostream>
using namespace std;
class TestReference
{
public:
// This is a pointer to me
const TestReference * _me;
TestReference() {
_me = this;
}
TestReference(const TestReference &obj)
{
_me = this;
}
};
class SmartObject
{
public:
SmartObject(){}
// removing this destructor makes it work
virtual ~SmartObject(){}
};
class IMyInterface
{
public:
IMyInterface(){}
// removing this destructor have no effect (fails anyway)
virtual ~IMyInterface(){}
virtual TestReference getTestReference() = 0;
};
// inheriting SmartObject virtually makes it work (but it is not feasible on
the overall application architecture)
class MyObject : public virtual IMyInterface, public SmartObject
{
public:
MyObject() : IMyInterface(), SmartObject() {}
virtual TestReference getTestReference() {
return testReference;
}
virtual ~MyObject(){
}
TestReference testReference;
};
int main()
{
IMyInterface *ip = new MyObject();
TestReference TestReference_local;
std::cout << "object address " << &TestReference_local << std::endl;
std::cout << "object address in constructor " <<
TestReference_local._me << std::endl;
if (&TestReference_local != TestReference_local._me)
std::cout << "warning! addresses are different!" << std::endl;
TestReference TestReference_clone = ip->getTestReference();
std::cout << "object address " << &TestReference_clone << std::endl;
std::cout << "object address in copy constructor " <<
TestReference_clone._me << std::endl;
if (&TestReference_clone != TestReference_clone._me)
std::cout << "warning! addresses are different!" << std::endl;
delete ip;
return 0;
}
Basically I expect the object address in the copy constructor (this) to be the
same of the object in the calling code, but when the program fails it is not
so!
on arm-linux:
object address 0xbeaf9be8
object address in constructor 0xbeaf9be8
object address 0xbeaf9bec
object address in copy constructor 0xbeaf9be4
warning! addresses are different!
on x64-linux:
object address 0x7ffff2be7410
object address in constructor 0x7ffff2be7410
object address 0x7ffff2be7420
object address in copy constructor 0x7ffff2be7420
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (3 preceding siblings ...)
2015-06-26 11:24 ` antonio.poggiali at datalogic dot com
@ 2015-06-27 12:42 ` mikpelinux at gmail dot com
2015-06-28 12:40 ` mikpelinux at gmail dot com
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mikpelinux at gmail dot com @ 2015-06-27 12:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
Mikael Pettersson <mikpelinux at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikpelinux at gmail dot com
--- Comment #6 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Using the test case in comment #0, I can reproduce wrong-code on armv7l with
gcc-4.9, 4.8, and 4.7 (everything native, nothing cross).
4.9: -O0: SEGV, -O1/2/3/s: infinite loop
4.8/4.7: -O0: SEGV, -O1/2/3/s: prints 2 and exits 0
With gcc-5 and trunk, it prints 2 and exits 0 at all -O levels.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (4 preceding siblings ...)
2015-06-27 12:42 ` [Bug c++/66666] ARM wrong copy constructor address " mikpelinux at gmail dot com
@ 2015-06-28 12:40 ` mikpelinux at gmail dot com
2015-06-29 15:56 ` antonio.poggiali at datalogic dot com
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mikpelinux at gmail dot com @ 2015-06-28 12:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #7 from Mikael Pettersson <mikpelinux at gmail dot com> ---
The test case in comment #0 stopped breaking on trunk with r221077, the fix for
PR65236 (a gcc-5 IPA regression). Backporting r221077 to 4.9.3 unbreaks this
test case there. However:
- I can't get this test case to fail anywhere except on ARM (x86_64, sparc,
m68k all work)
- The PR65236 test case doesn't fail with 4.9.3 on ARM
so I suspect a target-dependent issue here, and r221077 possibly just masks it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (5 preceding siblings ...)
2015-06-28 12:40 ` mikpelinux at gmail dot com
@ 2015-06-29 15:56 ` antonio.poggiali at datalogic dot com
2015-06-29 15:59 ` antonio.poggiali at datalogic dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-29 15:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #8 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
Hi all, I'm also trying the backport.
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?revision=221077&view=markup&pathrev=221077
Is only this part of code to be backported?
Regards
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (6 preceding siblings ...)
2015-06-29 15:56 ` antonio.poggiali at datalogic dot com
@ 2015-06-29 15:59 ` antonio.poggiali at datalogic dot com
2015-06-30 7:01 ` antonio.poggiali at datalogic dot com
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-29 15:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #9 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Antonio Poggiali from comment #8)
> Hi all, I'm also trying the backport.
>
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> c?revision=221077&view=markup&pathrev=221077
>
> Is only this part of code to be backported?
>
> Regards
Sorry, this code:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?r1=221077&r2=221076&pathrev=221077
I'm having cut and paste problems lately...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (7 preceding siblings ...)
2015-06-29 15:59 ` antonio.poggiali at datalogic dot com
@ 2015-06-30 7:01 ` antonio.poggiali at datalogic dot com
2015-06-30 13:24 ` antonio.poggiali at datalogic dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-30 7:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #11 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Mikael Pettersson from comment #10)
> (In reply to Antonio Poggiali from comment #9)
> > Sorry, this code:
> >
> > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> > c?r1=221077&r2=221076&pathrev=221077
>
> Yes, but I'm not convinced it's the real fix.
Unfortunately I can't use gcc 5 (I'm trying but it's not so easy) so, up to
now, this "patch" is the only way to get my system working.
Do you think this bug will be fixed in a new release (e.g. 4.9.4)?
Thank you!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (8 preceding siblings ...)
2015-06-30 7:01 ` antonio.poggiali at datalogic dot com
@ 2015-06-30 13:24 ` antonio.poggiali at datalogic dot com
2015-06-30 17:09 ` jgreenhalgh at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-06-30 13:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #12 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
Created attachment 35879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35879&action=edit
Temporary patch for gcc 4.9.3
A temporary patch masking the problem on gcc 4.9.3
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (9 preceding siblings ...)
2015-06-30 13:24 ` antonio.poggiali at datalogic dot com
@ 2015-06-30 17:09 ` jgreenhalgh at gcc dot gnu.org
2015-07-01 10:18 ` jgreenhalgh at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jgreenhalgh at gcc dot gnu.org @ 2015-06-30 17:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jgreenhalgh at gcc dot gnu.org
--- Comment #13 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
Starting with my own set of silly questions while I try to narrow down what
environments I need to set up...
Your toolchain is arm-none-linux-gnueabi , but you build with -mfloat-abi=hard
- do you have suitable hard-float libraries on the target?
How was the toolchain configured
(arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?
What userspace is running on the target?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (10 preceding siblings ...)
2015-06-30 17:09 ` jgreenhalgh at gcc dot gnu.org
@ 2015-07-01 10:18 ` jgreenhalgh at gcc dot gnu.org
2015-07-01 10:26 ` antonio.poggiali at datalogic dot com
2015-07-03 15:57 ` jgreenhalgh at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jgreenhalgh at gcc dot gnu.org @ 2015-07-01 10:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-07-01
Ever confirmed|0 |1
--- Comment #15 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
(In reply to Antonio Poggiali from comment #14)
> >
> > Your toolchain is arm-none-linux-gnueabi , but you build with
> > -mfloat-abi=hard - do you have suitable hard-float libraries on the target?
> >
>
> I have only hard-float libraries and related system header files.
>
> > How was the toolchain configured
> > (arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?
> >
>
> <Snip>
Thanks, I've reproduced the failure using the configuration above.
Looks like we can drop most of the command line arguments and still tickle the
segmentation fault
>
> > What userspace is running on the target?
>
> Sorry but I don't understand the question. Could you explain a little?
Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu 12.04.4
userspace. But I haven't yet understood the issue.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (11 preceding siblings ...)
2015-07-01 10:18 ` jgreenhalgh at gcc dot gnu.org
@ 2015-07-01 10:26 ` antonio.poggiali at datalogic dot com
2015-07-03 15:57 ` jgreenhalgh at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: antonio.poggiali at datalogic dot com @ 2015-07-01 10:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
--- Comment #16 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to James Greenhalgh from comment #15)
> >
> > > What userspace is running on the target?
> >
> > Sorry but I don't understand the question. Could you explain a little?
>
> Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu
> 12.04.4 userspace. But I haven't yet understood the issue.
I'm using Yocto-generated Linux systems. I had the defect on systems build with
angstrom and also with poky. I had the defect on systems based on different HW
vendors systems (atmel & altera).
Currently i'm working on: Linux sama5d4ek
3.18.0-linux4sam_5.0-alpha1-00061-gfeb4121 #1 Tue Jun 30 11:14:11 CEST 2015
armv7l GNU/Linux
Do I answered you question?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
` (12 preceding siblings ...)
2015-07-01 10:26 ` antonio.poggiali at datalogic dot com
@ 2015-07-03 15:57 ` jgreenhalgh at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jgreenhalgh at gcc dot gnu.org @ 2015-07-03 15:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666
James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #17 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
This feels very similar to pr65236. For your second testbench, we can look at
the output assembly for the fixup thunk for MyObject->getTestReference() for
arm:
---
_ZTv0_n16_N8MyObject16getTestReferenceEv:
.fnstart
.LFB1058:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {r4, fp, lr} @,
.save {r4, fp, lr}
.setfp fp, sp, #8
add fp, sp, #8 @,,
.pad #20
sub sp, sp, #20 @,,
str r0, [fp, #-16] @ .result_ptr, .result_ptr
str r1, [fp, #-20] @ this, this
ldr r3, [fp, #-20] @ vptr.4, this
ldr r3, [r3] @ vtableaddr.5, *vptr.4_4
sub r3, r3, #16 @ vtableaddr.5, vtableaddr.5,
ldr r3, [r3] @ vcalloffset.6, *vtableaddr.5_6
mov r2, r3 @ D.25213, vcalloffset.6
ldr r3, [fp, #-20] @ tmp116, this
add r3, r3, r2 @ D.25214, tmp116, D.25213
ldr r4, [fp, #-16] @ tmp117, .result_ptr
sub r2, fp, #28 @ tmp118,,
mov r0, r2 @, tmp118
mov r1, r3 @, D.25214
bl .LTHUNK0 @
ldr r3, [fp, #-28] @ tmp119,
str r3, [r4] @ tmp119, <retval>
ldr r0, [fp, #-16] @, .result_ptr
sub sp, fp, #8 @,,
@ sp needed @
ldmfd sp!, {r4, fp, pc} @
.fnend
---
We allocate some stack space for the result (tmp118) and hand it off to the
called function as the return value. The copy constructor is invoked as a copy
to this temporary rather than to the stack slot reserved for
TestReference_clone. When we do return to main, we just do a simple word-wise
copy of the object.
As to your original bug, the root cause is similar, the copy constructor for
list wants to set up pointers to the final list node (I think). But we've given
it an address on the stack which we will soon clobber when we start executing.
You can see the mismatch in expectations if you build an empty list, and check
it is empty with list->empty rather than size.
(gdb) print this->_M_impl._M_node
$3 = {_M_next = 0xbeffef08, _M_prev = 0xbeffef08}
(gdb) print &this->_M_impl._M_node
$4 = (std::__detail::_List_node_base *) 0xbeffef2c
As to why this is target specific... My untested hunch is you'll see it on the
following targets { vax, stormy16, pa, nds32, mmix, frv, cris, arm } - those
being the targets which #define TARGET_ASM_CAN_OUTPUT_MI_THUNK
default_can_output_mi_thunk_no_vcall and go through the generic, heavyweight,
(and apparently broken) thunk code. Enabling return slot optimization would
protect these targets against the current issue - that of the thunk code
constructing a temporary object in a soon-to-die location on the stack.
With all that said, I think backporting Honza's trunk patch for pr65236 looks
like a reasonable thing to do. Though, I'm CCing Honza for his input.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-07-03 15:57 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-25 13:10 [Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance antonio.poggiali at datalogic dot com
2015-06-25 17:49 ` [Bug c++/66666] " ramana at gcc dot gnu.org
2015-06-26 7:04 ` antonio.poggiali at datalogic dot com
2015-06-26 11:23 ` antonio.poggiali at datalogic dot com
2015-06-26 11:24 ` antonio.poggiali at datalogic dot com
2015-06-27 12:42 ` [Bug c++/66666] ARM wrong copy constructor address " mikpelinux at gmail dot com
2015-06-28 12:40 ` mikpelinux at gmail dot com
2015-06-29 15:56 ` antonio.poggiali at datalogic dot com
2015-06-29 15:59 ` antonio.poggiali at datalogic dot com
2015-06-30 7:01 ` antonio.poggiali at datalogic dot com
2015-06-30 13:24 ` antonio.poggiali at datalogic dot com
2015-06-30 17:09 ` jgreenhalgh at gcc dot gnu.org
2015-07-01 10:18 ` jgreenhalgh at gcc dot gnu.org
2015-07-01 10:26 ` antonio.poggiali at datalogic dot com
2015-07-03 15:57 ` jgreenhalgh 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).