[Bug c++/65132] New: diagnostics: missing: bitfield member cannot have an in-class initializer

[Bug c++/65132] New: diagnostics: missing: bitfield member cannot have an in-class initializer

[jan.kratochvil at redhat dot com]

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

            Bug ID: 65132
           Summary: diagnostics: missing: bitfield member cannot have an
                    in-class initializer
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.kratochvil at redhat dot com

class C { bool x:1=false; };

g++ (GCC) 5.0.0 20150219 (experimental):
field.C:1:20: error: an assignment cannot appear in a constant-expression

clang-3.5.0-6.fc21.x86_64:
field.C:1:19: error: bitfield member cannot have an in-class initializer

I had no idea what GCC errors on until I asked clang.

[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-20
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Confirmed. 

Probably it is just a matter of calling cp_parser_constant_expression with the
right parameters to not emit errors, then checking after it returns that it
indeed parsed a constant-expression and give appropriate errors otherwise.
>From gcc-bugs-return-477933-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 12:25:19 2015
Return-Path: <gcc-bugs-return-477933-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28689 invoked by alias); 20 Feb 2015 12:25:19 -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 28315 invoked by uid 48); 20 Feb 2015 12:25:15 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65136] [5 Regression] VRP inserts unnecessary constant copy in the loop
Date: Fri, 20 Feb 2015 12:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_known_to_work target_milestone short_desc
Message-ID: <bug-65136-4-FhVWznLhJt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65136-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65136-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: 2015-02/txt/msg02263.txt.bz2
Content-length: 663

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide136

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.9.2
   Target Milestone|---                         |5.0
            Summary|VRP inserts unnecessary     |[5 Regression] VRP inserts
                   |constant copy in the loop   |unnecessary constant copy
                   |                            |in the loop

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is a regression from GCC 4.9.

[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #1)
> Probably it is just a matter of calling cp_parser_constant_expression with
> the right parameters to not emit errors, then checking after it returns that
> it indeed parsed a constant-expression and give appropriate errors otherwise.

Which is what the C++ parser needs to do in general to avoid the terribly
user-unfriendly "expected...before" diagnostics, particularly the infamous 
'expected primary-expression before...' PR39858.

We really need at lot more people working on the C++ parser...
>From gcc-bugs-return-477942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 13:07:10 2015
Return-Path: <gcc-bugs-return-477942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22338 invoked by alias); 20 Feb 2015 13:07:10 -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 22070 invoked by uid 48); 20 Feb 2015 13:07:06 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
Date: Fri, 20 Feb 2015 13:24: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: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: mliska at suse dot cz
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63892-4-zb6ruu9BzI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63892-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63892-4@http.gcc.gnu.org/bugzilla/>
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: 2015-02/txt/msg02274.txt.bz2
Content-length: 263

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
Thanks for cooperation, I'm going to bootstrap and run regression tests on
x86_64-linux-pc and I'm going to clone these tests too.

Martin
>From gcc-bugs-return-477944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 13:24:12 2015
Return-Path: <gcc-bugs-return-477944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2648 invoked by alias); 20 Feb 2015 13:24:11 -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 2628 invoked by uid 48); 20 Feb 2015 13:24:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65137] New: wrong line for missing semicolon after expression
Date: Fri, 20 Feb 2015 13:37: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: unknown
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: <bug-65137-4@http.gcc.gnu.org/bugzilla/>
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: 2015-02/txt/msg02276.txt.bz2
Content-length: 637

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

            Bug ID: 65137
           Summary: wrong line for missing semicolon after expression
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manu at gcc dot gnu.org

int foo(int a)
{
  a++
  return 0;    
}

gcc:

test.c:4:3: error: expected ‘;’ before ‘return’
   return 0;
   ^

clang:

test.c:3:6: error: expected ';' after expression
  a++
     ^
     ;
>From gcc-bugs-return-477943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 13:18:13 2015
Return-Path: <gcc-bugs-return-477943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13812 invoked by alias); 20 Feb 2015 13:18:12 -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 13739 invoked by uid 48); 20 Feb 2015 13:18:07 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65122] std::vector doesn't honor element alignment
Date: Fri, 20 Feb 2015 13:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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:
Message-ID: <bug-65122-4-ZDX8s6Ralx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65122-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65122-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: 2015-02/txt/msg02275.txt.bz2
Content-length: 2194

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide122

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Benoit Jacob from comment #11)
> (In reply to Richard Biener from comment #10)
> > But ::operator new(std::size_t) could always return memory aligned for the
> > most over-aligned type?  Thus our default new implementation could use
> > posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)?
>
> The problem is there are lots of use cases for really high alignment: AVX
> brings uses of 32-byte alignment, and cache lines are typically >= 64 byte
> aligned. So alignas has to support at least 64 or 128 byte alignment to
> support cache friendly code, and even without that, it would have to support
> at least 32 byte alignment for AVX vectorized code.
>
> Making all allocations that large would lead to substantial allocator slop.
> For example, jemalloc has a quantum of 8 or 16 byte depending on whether the
> arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big
> difference.

Though does it really matter in practice?  Tiny allocations would not suffer
because of the MIN (align, size), so the worst-case is max-align + 1
allocations.  Btw, you could as well try MIN (align, size & -size),
thus assume that the allocation size is N * alignof ().

> >
> > If the user provides its own ::new then he is on its own, of course
>
> I agree that's how I would like things to be. Unfortunately, the spec quote
> in comment 4, "the storage is obtained by calling ::operator
> new(std::size_t)", goes in the opposite direction, by requiring allocators
> to use the type-blind ::new , thereby losing useful type information such as
> the type's alignment. That's why I think that this is the spec's weak spot
> that might be questioned. but you're the expert, not me :)
>
> > (and
> > doing that and using posix_memalign in it would be a workaround for this
> > issue?!).
>
> That could be a good compromise for many applications, that either don't
> care about minimizing memory usage, or don't do many tiny allocations.
> Unfortunately, my context here is a library (Eigen), so we can't make this
> decision for all our users.

[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |8.0
         Resolution|---                         |FIXED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 8.0. C++20 added support for this feature and GCC enables it as an
extension for C++11+ with a warning:
<source>:1:19: warning: default member initializers for bit-fields only
available with -std=c++2a or -std=gnu++2a
 class C { bool x:1=false; };
                   ^
ASM generation compiler returned: 0
<source>:1:19: warning: default member initializers for bit-fields only
available with -std=c++2a or -std=gnu++2a
 class C { bool x:1=false; };
                   ^