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).