From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16536 invoked by alias); 25 Sep 2014 22:16:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 16505 invoked by uid 48); 25 Sep 2014 22:16:19 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/63374] New: unhelpful diagnostics for missing initializer Date: Thu, 25 Sep 2014 22:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org 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_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02439.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63374 Bug ID: 63374 Summary: unhelpful diagnostics for missing initializer Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org class B { public: B(int x) : z(x) {} int z; }; class A { public: B b1; int a1; B b2; int a2; B b3; int b4; B a4; A(int x) : b1(x), b2(x), b3(x), b4(x) {} }; manuel@gcc10:~$ ~/test1/214251/build/gcc/cc1plus test.cc B::B(int) B::B(int) B::B(int) A::A(int) test.cc:16:39: error: no matching function for call to =E2=80=98B::B()=E2= =80=99 A(int x) : b1(x), b2(x), b3(x), b4(x) {} ^ test.cc:3:3: note: candidate: B::B(int) B(int x) : z(x) {} ^ test.cc:3:3: note: candidate expects 1 argument, 0 provided test.cc:1:7: note: candidate: B::B(const B&) class B { ^ test.cc:1:7: note: candidate expects 1 argument, 0 provided manuel@gcc10:~$ clang++ test.cc test.cc:16:3: error: constructor for 'A' must explicitly initialize the mem= ber 'a4' which does not have a default constructor A(int x) : b1(x), b2(x), b3(x), b4(x) {} ^ test.cc:14:5: note: member is declared here B a4; ^ test.cc:1:7: note: 'B' declared here class B { ^ 1 error generated. >>From gcc-bugs-return-462606-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 25 22:26:07 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 20809 invoked by alias); 25 Sep 2014 22:26:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 20746 invoked by uid 48); 25 Sep 2014 22:26:03 -0000 From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/63360] Does not retore f31 at -O0 across function calls Date: Thu, 25 Sep 2014 22:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: bergner at gcc dot gnu.org X-Bugzilla-Status: RESOLVED 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_status resolution Message-ID: In-Reply-To: References: 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: 2014-09/txt/msg02440.txt.bz2 Content-length: 1937 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 Peter Bergner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #16 from Peter Bergner --- Ok, this is an application problem. From the last gdb session, we see that the jmpbuf has an address non 16-byte aligned address, which the setjmp/longjmp code requires. (gdb) i reg r3 r3 0x2086db8 34106808 This leads to the code that saves the Altivec registers to clobber the jmpbuf field where f31 is stored, since the stvx store instruction implicitly truncates the bottom nibble of its address, giving it the same address as f31's field. Speaking with Camm offline, he doesn't use the jmpbuf type included from setjmp.h, but rather uses: struct frame { char frs_jmpbuf[SIZEOF_JMP_BUF]; object *frs_lex; bds_ptr frs_bds_top; object frs_val; ihs_ptr frs_ihs; char frs_class; char frs_in_signal_handler; char frs_pad[6]; /*Keep frs_jumpbuf 8 byte aligned*/ }; ...which will only enforce an 8 byte alignment. If you look at the jmpbuf declaration included from setjmp.h, you'll see it defined as: typedef long int __jmp_buf[64 + (12 * 4)] __attribute__ ((__aligned__ (16))); The save/restore code within setjmp/longjmp requires the 16-byte alignment. I'm guessing the working "optimized" code was only getting lucky with the address of your jmpbuf. I'll note that the same jmpbuf layout and setjmp/longjmp code is used for both ELFv1 and ELFv2, so you'll need to do this for both of them. The __powerpc64__ macro is defined for both ELFv1 and ELFv2, so you can use that to increase your jumpbuf's alignment when compiling for ELFv1 and ELFv2.