* [Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer
2015-02-20 9:14 [Bug c++/65132] New: diagnostics: missing: bitfield member cannot have an in-class initializer jan.kratochvil at redhat dot com
2015-02-20 12:43 ` [Bug c++/65132] " manu at gcc dot gnu.org
@ 2015-02-20 13:18 ` manu at gcc dot gnu.org
2021-07-23 21:24 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: manu at gcc dot gnu.org @ 2015-02-20 13:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread