[Bug c++/63374] New: unhelpful diagnostics for missing initializer

[Bug c++/63374] New: unhelpful diagnostics for missing initializer

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63374

            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 ‘B::B()’
   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 member
'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: <gcc-bugs-return-462606-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-63360-4-v8ZOFAaXzT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63360-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63360-4@http.gcc.gnu.org/bugzilla/>
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?idc360

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> ---
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.