On Jan 4, 2019, Jason Merrill wrote:
> if (tree fn = cp_get_callee_fndecl_nofold (expr))
> if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))
> ? The other patch is OK with that change.
Thanks, I've regstrapped this on x86_64- and i686-linux-gnu, and I'm
checking it in momentarily.
[P
On 12/28/18 9:33 PM, Alexandre Oliva wrote:
On Dec 28, 2018, Alexandre Oliva wrote:
I guess I still need to
fill in other gaps to in my knowledge to try and make sense of it.
Done.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
Here's a patch based on your suggestion.
[PR88146] do
On Sat, Dec 29, 2018 at 12:33:18AM -0200, Alexandre Oliva wrote:
> --- a/gcc/cp/typeck2.c
> +++ b/gcc/cp/typeck2.c
> @@ -918,7 +918,11 @@ check_narrowing (tree type, tree init, tsubst_flags_t
> complain, bool const_only)
>return ok;
> }
>
> - init = maybe_constant_value (init);
> +
On Dec 28, 2018, Alexandre Oliva wrote:
> diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
And here's a cleaned-up patch based on my initial approach.
[PR88146] avoid diagnostics diffs if cdtor_returns_this
Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms. Specifically, on
On Dec 28, 2018, Alexandre Oliva wrote:
> I guess I still need to
> fill in other gaps to in my knowledge to try and make sense of it.
Done.
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
Here's a patch based on your suggestion.
[PR88146] do not instantiate constexpr if not manifestl
On Dec 20, 2018, Jason Merrill wrote:
> I think the bug is in calling instantiate_constexpr_fns in this case.
> I think that should only happen when ctx->manifestly_const_eval.
FTR, changing that breaks cpp2a/constexpr-init1.C (P0859),
unfortunately. I don't see why the operand of decltype or o
On 12/19/18 7:04 PM, Alexandre Oliva wrote:
Christophe,
Thanks again for the report. This was quite an adventure to figure
out ;-) See below.
[PR88146] avoid diagnostics diffs if cdtor_returns_this
Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms. Specifically, o
On Thu, 20 Dec 2018 at 01:04, Alexandre Oliva wrote:
>
> Christophe,
>
> Thanks again for the report. This was quite an adventure to figure
> out ;-) See below.
>
Glad I've helped. I wouldn't have been able to do the analysis :)
>
> [PR88146] avoid diagnostics diffs if cdtor_returns_this
>
>
Christophe,
Thanks again for the report. This was quite an adventure to figure
out ;-) See below.
[PR88146] avoid diagnostics diffs if cdtor_returns_this
Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms. Specifically, on ARM, the diagnostics within the subtest
deri
On Wed, Dec 19, 2018 at 04:47:51PM -0200, Alexandre Oliva wrote:
> On Dec 19, 2018, Christophe Lyon wrote:
>
> > The new test inh-ctor32.C fails on arm:
> > FAIL:g++.dg/cpp0x/inh-ctor32.C -std=c++14 (test for warnings, line
> > 208)
> > FAIL:g++.dg/cpp0x/inh-ctor32.C -std=c++17 (test
On Dec 19, 2018, Christophe Lyon wrote:
> The new test inh-ctor32.C fails on arm:
> FAIL:g++.dg/cpp0x/inh-ctor32.C -std=c++14 (test for warnings, line 208)
> FAIL:g++.dg/cpp0x/inh-ctor32.C -std=c++17 (test for warnings, line 208)
Thanks, sorry about the breakage, I'm looking into it.
On Sat, 15 Dec 2018 at 23:11, Jason Merrill wrote:
>
> On Fri, Dec 14, 2018 at 6:05 PM Alexandre Oliva wrote:
> >
> > On Dec 14, 2018, Jason Merrill wrote:
> >
> > > Let's move the initialization of "fields" inside the 'then' block here
> > > with the initialization of "cvquals", rather than cle
On Fri, Dec 14, 2018 at 6:05 PM Alexandre Oliva wrote:
>
> On Dec 14, 2018, Jason Merrill wrote:
>
> > Let's move the initialization of "fields" inside the 'then' block here
> > with the initialization of "cvquals", rather than clear it in the
> > 'else'.
>
> We'd still have to NULL-initialize it
On Dec 14, 2018, Jason Merrill wrote:
> Let's move the initialization of "fields" inside the 'then' block here
> with the initialization of "cvquals", rather than clear it in the
> 'else'.
We'd still have to NULL-initialize it somewhere, so I'd rather just move
the entire loop into the condition
On 12/14/18 5:33 PM, Alexandre Oliva wrote:
On Dec 14, 2018, Jason Merrill wrote:
If inh is false, we're a copy constructor, which always has a parm,
so this hunk seems unnecessary.
ack
- int cvquals = cp_type_quals (TREE_TYPE (parm));
+ int cvquals = parm ? cp_type_quals (TREE_T
On Dec 14, 2018, Jason Merrill wrote:
>> If inh is false, we're a copy constructor, which always has a parm,
>> so this hunk seems unnecessary.
ack
>>> - int cvquals = cp_type_quals (TREE_TYPE (parm));
>>> + int cvquals = parm ? cp_type_quals (TREE_TYPE (parm)) : 0;
>>
>> This could
On 12/14/18 3:42 PM, Jason Merrill wrote:
On 12/6/18 7:23 PM, Alexandre Oliva wrote:
This patch started out from the testcase in PR88146, that attempted to
synthesize an inherited ctor without any args before a varargs
ellipsis and crashed while at that, because of the unguarded
dereferencing of
On 12/6/18 7:23 PM, Alexandre Oliva wrote:
This patch started out from the testcase in PR88146, that attempted to
synthesize an inherited ctor without any args before a varargs
ellipsis and crashed while at that, because of the unguarded
dereferencing of the parm type list, that usually contains
On Dec 6, 2018, Alexandre Oliva wrote:
> Regstrapped on x86_64- and i686-linux-gnu, mistakenly along with a patch
> with a known regression, and got only that known regression. Retesting
> without it. Ok to install?
Ping? That round of retesting confirmed no regressions.
https://gcc.gnu.org/
19 matches
Mail list logo
