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.
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]
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
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
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,
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
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
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
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
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
CATION (fndecl)
= DECL_SOURCE_LOCATION (TYPE_NAME (DECL_CONTEXT (fndecl)));
Is this OK too? (pending regstrapping)
[PR c++/88146] do not crash synthesizing inherited ctor(...)
This patch started out from the testcase in PR88146, that attempted to
synthesize an inherited ctor without any arg
the patch that added an if (inh) to
print an error on zero-args had an 'else fields = NULL;'. That
improvement went away along with my course change. But look!, it's back
in the version below ;-)
Testing... Ok to install if it passes?
[PR c++/88146] do not crash synthesizing inherited ctor(...)
earlier version of the patch that added an if (inh) to
print an error on zero-args had an 'else fields = NULL;'. That
improvement went away along with my course change. But look!, it's back
in the version below ;-)
Testing... Ok to install if it passes?
[PR c++/88146] do not crash
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
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.
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 a
terminator. The terminator is not there
20 matches
Mail list logo
