Fixed thus. For a user-provided default constructor we don't need to
play with zeroing the object first, so we can use the normal logic that
works properly for protected access.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 0ebf6baa1f5f27bd96db44514425075cad2cbd97
Author:
On 12/24/2012 03:29 AM, Paolo Carlini wrote:
Are you sure your patch handles the access control issue too?? (isn't
obvious to me that it does, looking at the patch itself and your comments)
Nope, you're right. I put the testcase in one file and then compiled a
different one. /facepalm
On 12/24/2012 05:56 AM, Jason Merrill wrote:
On 12/22/2012 06:02 PM, Paolo Carlini wrote:
Well, we still reject it after the patch
My 4.7 and trunk compilers both accept it (with -std=c++11, of course).
I just updated and rebuilt my 4.7 for you (which definitely I didn't
hack over the next
... to explain more concretely what I mean, if I *brutally* hack
mainline per the below, then the testcase is accepted.
Paolo.
//
Index: call.c
===
--- call.c (revision 194659)
+++ call.c (working copy)
On 12/22/2012 06:02 PM, Paolo Carlini wrote:
Well, we still reject it after the patch
My 4.7 and trunk compilers both accept it (with -std=c++11, of course).
Jason
On 12/21/2012 06:38 AM, Paolo Carlini wrote:
I was looking a bit more into this Bug, and something seems still weird about
the testcase in Comment #1 of the audit trail, which we also didn't reject with
4.6.x:
What's weird about it?
Jason
Hi,
Jason Merrill ja...@redhat.com ha scritto:
On 12/21/2012 06:38 AM, Paolo Carlini wrote:
I was looking a bit more into this Bug, and something seems still
weird about the testcase in Comment #1 of the audit trail, which we
also didn't reject with 4.6.x:
What's weird about it?
Well, we
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic initialization code out into a function that's definitely
creating a new
On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic
Am 07.12.2012 10:17, schrieb Jakub Jelinek:
On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves
Hi,
On 12/07/2012 10:24 AM, Matthias Klose wrote:
committed.
Matthias
2012-12-07 Matthias Klose d...@ubuntu.com
* tree.c (build_aggr_init_expr): Add parameter name, mark as unused.
Thanks.
I was wondering if in mainline we could just do the below. It seems
straightforward
On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose d...@ubuntu.com wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic
On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose d...@ubuntu.com wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of
On Fri, Dec 7, 2012 at 7:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose d...@ubuntu.com wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base
OK.
Jason
It's perfectly OK to initialize a base class of abstract type; it's only
an error to create a full object of such a type. So this patch moves
the check from more generic initialization code out into a function
that's definitely creating a new object.
Tested x86_64-pc-linux-gnu, applying to
16 matches
Mail list logo
