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: Jason
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
Jaso
... 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/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 da
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
Hi,
Jason Merrill 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 still reject i
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,
On 12/07/2012 06:05 AM, Jason Merrill wrote:
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 o
OK.
Jason
On Fri, Dec 7, 2012 at 7:39 AM, Jakub Jelinek 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 wrote:
>> > Am 07.12.2012 06:05, schrieb Jason Merrill:
>> >> It's perfectly OK to initialize a base class of abstract type; i
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 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 ty
On Fri, Dec 7, 2012 at 3:13 AM, 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 initialization cod
Hi,
On 12/07/2012 10:24 AM, Matthias Klose wrote:
committed.
Matthias
2012-12-07 Matthias Klose
* 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 enough...
Thanks
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 pat
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 initia
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 obj
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 tr
17 matches
Mail list logo
