[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Jason Merrill changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE
|while building firefox |while building firefox
|since r8-2720 |since r8-2720
--- Comment #13 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Jason Merrill from comment #10)
> > This doesn't look valid to me. In
> >
> > [x...] { x; }...
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358#c3 is what they actually
> have (not sure if it changes anything on the validness) and I have full
> preprocessed source, so can supply further details that would be needed.
That doesn't change anything; they should remove the ... from the capture to
make the testcase valid. Please check that the patch I just checked in
replaces the ICE with an error, thanks.
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
--- Comment #14 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #13)
> (In reply to Jakub Jelinek from comment #11)
> > (In reply to Jason Merrill from comment #10)
> > > This doesn't look valid to me. In
> > >
> > > [x...] { x; }...
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358#c3 is what they actually
> > have (not sure if it changes anything on the validness) and I have full
> > preprocessed source, so can supply further details that would be needed.
>
> That doesn't change anything; they should remove the ... from the capture to
> make the testcase valid. Please check that the patch I just checked in
> replaces the ICE with an error, thanks.
Ok, confirmed (with a backport to 10 because that in a cross to powerpc64le is
where I was testing it before), the unmodified original *.ii now errors out:
cchFugMG.ii: In lambda function:
cchFugMG.ii:73385:65: error: parameter packs not expanded with ‘...’:
73385 | return ErrorResult{aSpecialValueMappers(aSpecialValue)};
| ^
cchFugMG.ii:73385:65: note: ‘aSpecialValueMappers’
and compiles fine with the
ErrorResult ExtractErrorResult(SpecialValueMappers... aSpecialValueMappers)
{
return mVariant.match(
[](ErrorResult& aException) { return std::move(aException); },
-[aSpecialValueMappers...](const SpecialConstant& aSpecialValue) {
+[aSpecialValueMappers](const SpecialConstant& aSpecialValue) {
return ErrorResult{aSpecialValueMappers(aSpecialValue)};
}...);
}
change (in that case both with unmodified as well as modified gcc).
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358 --- Comment #15 from Dan Horák --- Petr, are you going to open a Firefox bug to fix their code or shall I do it?
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358 --- Comment #16 from Jakub Jelinek --- Perhaps also mention it in https://bugzilla.mozilla.org/show_bug.cgi?id=1665347
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
--- Comment #17 from Petr Sumbera ---
(In reply to Dan Horák from comment #15)
> Petr, are you going to open a Firefox bug to fix their code or shall I do it?
Please file it. I haven't had time to read whole thread and I don't know what
shall be the right fix. For now I used just:
--- a/dom/indexedDB/IDBResult.h Thu Oct 15 08:38:16 2020 +0200
+++ b/dom/indexedDB/IDBResult.h Thu Oct 15 08:38:38 2020 +0200
@@ -101,7 +101,7 @@
template
ErrorResult ExtractErrorResult(SpecialValueMappers... aSpecialValueMappers)
{
-#if (defined(__clang__) || (defined(__GNUC__) && __GNUC__ >= 8)) && \
+#if (defined(__clang__) || (defined(__GNUC__) && __GNUC__ >= 11)) && \
!defined(XGILL_PLUGIN)
return mVariant.match(
[](ErrorResult& aException) { return std::move(aException); },
But if you are busy I can do my best to report it.
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358 --- Comment #18 from Dan Horák --- So there is https://bugzilla.mozilla.org/show_bug.cgi?id=1671345 now, after I commented in the bug Jakub mentioned. I like such cooperation :-)
[Bug c++/97358] [8/9/10 Regression] ICE while building firefox since r8-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
||.co.uk
--- Comment #19 from Richard Smith
---
(In reply to Jason Merrill from comment #10)
> This doesn't look valid to me. In
>
> [x...] { x; }...
>
> we capture the entire pack, but then try to use only a single element. This
> should be rejected because the use of x in the lambda body is not expanded
The reference to 'x' is expanded within the scope of the parameter pack, though
(which is the entire function template, because 'x' here refers to the
parameter of the enclosing function template). So I think that case 2 is valid,
and expands to
foo(
[x...] { return x.[0]; },
[x...] { return x.[1]; },
...
[x...] { return x.[N]; },
);
(That is, each lambda captures the entire pack and then uses only part of it.)
More generally, I think cases such as
foo([x...] { return f(x..., x); } ...);
... are valid, resulting in expansions such as
foo(
[x...] { return f(x.[0], x.[1], ..., x.[N], x.[0]; },
[x...] { return f(x.[0], x.[1], ..., x.[N], x.[1]; },
...
[x...] { return f(x.[0], x.[1], ..., x.[N], x.[N]; },
);
I think Case 3 is not valid because the reference to the pack y is not expanded
*within the scope of that pack*, though it's not clear that the standard
actually clearly says that anywhere.
