* [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-12 15:29 ` ppalka at gcc dot gnu.org
2020-03-12 22:54 ` ppalka at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-03-12 15:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
Status|NEW |ASSIGNED
CC| |ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Looking into it.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 15:29 ` [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings ppalka at gcc dot gnu.org
@ 2020-03-12 22:54 ` ppalka at gcc dot gnu.org
2020-03-12 23:02 ` ppalka at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-03-12 22:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The ICE seems to be revealing a latent issue: In the following example (which
GCC accepts), according to the static_assert labelled (1), the type of t is
const int*, but according to the static_assert labelled (2), the type of t is
int *const.
template <typename T>
void foo(const T t)
{
static_assert(__is_same(decltype(t), const int*)); // (1)
}
static_assert(__is_same(decltype(foo<int[]>), void(int *))); // (2)
int
main()
{
foo<int[]>(nullptr);
}
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
2020-03-12 15:29 ` [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings ppalka at gcc dot gnu.org
2020-03-12 22:54 ` ppalka at gcc dot gnu.org
@ 2020-03-12 23:02 ` ppalka at gcc dot gnu.org
2020-03-17 18:34 ` ppalka at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-03-12 23:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #5)
> The ICE seems to be revealing a latent issue: In the following example
> (which GCC accepts), according to the static_assert labelled (1), the type
> of t is const int*, but according to the static_assert labelled (2), the
> type of t is int *const.
>
>
>
> template <typename T>
> void foo(const T t)
> {
> static_assert(__is_same(decltype(t), const int*)); // (1)
> }
>
> static_assert(__is_same(decltype(foo<int[]>), void(int *))); // (2)
>
> int
> main()
> {
> foo<int[]>(nullptr);
> }
So the question becomes, what should the type of t be here? According to
https://eel.is/c++draft/temp#deduct-3:
"A top-level qualifier in a function parameter declaration does not affect the
function type but still affects the type of the function parameter variable
within the function."
The above suggests that the type of foo<int[]> should be the same regardless of
where the parameter t is const-qualified. Going by this then, it appears that
the static_assert (2) is right and (1) is wrong. Can anyone confirm?
(On the other hand, Clang thinks (1) is right and (2) is wrong.)
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-03-12 23:02 ` ppalka at gcc dot gnu.org
@ 2020-03-17 18:34 ` ppalka at gcc dot gnu.org
2020-04-08 14:17 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-03-17 18:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #6)
> (In reply to Patrick Palka from comment #5)
> > The ICE seems to be revealing a latent issue: In the following example
> > (which GCC accepts), according to the static_assert labelled (1), the type
> > of t is const int*, but according to the static_assert labelled (2), the
> > type of t is int *const.
> >
> >
> >
> > template <typename T>
> > void foo(const T t)
> > {
> > static_assert(__is_same(decltype(t), const int*)); // (1)
> > }
> >
> > static_assert(__is_same(decltype(foo<int[]>), void(int *))); // (2)
> >
> > int
> > main()
> > {
> > foo<int[]>(nullptr);
> > }
>
> So the question becomes, what should the type of t be here? According to
> https://eel.is/c++draft/temp#deduct-3:
>
> "A top-level qualifier in a function parameter declaration does not affect
> the function type but still affects the type of the function parameter
> variable within the function."
>
> The above suggests that the type of foo<int[]> should be the same regardless
> of where the parameter t is const-qualified. Going by this then, it appears
> that the static_assert (2) is right and (1) is wrong. Can anyone confirm?
>
> (On the other hand, Clang thinks (1) is right and (2) is wrong.)
So I think the quoted wording from [temp.deduct]/3 applies to function
parameter types _after_ substitution. So this doesn't definitively tell us
anything about the type of t.
I think the answer lies in [basic.type.qualifier]/3, which says:
"Cv-qualifiers applied to an array type attach to the underlying element type,
so the notation “cv T”, where T is an array type, refers to an array whose
elements are so-qualified ([dcl.array]"
So the type const T after substituting T=int[] is precisely const int[], which
as a parameter type then decays to const int* according to [dcl.fct]/5. So it
seems that the static_assert (1) is right, and (2) is wrong.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-03-17 18:34 ` ppalka at gcc dot gnu.org
@ 2020-04-08 14:17 ` cvs-commit at gcc dot gnu.org
2020-04-08 14:33 ` [Bug c++/92010] [8/9 " ppalka at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-08 14:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:12f55e030ed068d5c7b14c65a74d102db925dab2
commit r10-7622-g12f55e030ed068d5c7b14c65a74d102db925dab2
Author: Patrick Palka <ppalka@redhat.com>
Date: Mon Mar 30 19:55:03 2020 -0400
c++: Function type and parameter type disagreements [PR92010]
This resolves parts of Core issues 1001/1322 by rebuilding the function
type
of an instantiated function template in terms of its formal parameter types
whenever the original function type and formal parameter types disagree
about
the type of a parameter after substitution.
gcc/cp/ChangeLog:
Core issues 1001 and 1322
PR c++/92010
* pt.c (rebuild_function_or_method_type): Split function out from
...
(tsubst_function_type): ... here.
(maybe_rebuild_function_decl_type): New function.
(tsubst_function_decl): Use it.
gcc/testsuite/ChangeLog:
Core issues 1001 and 1322
PR c++/92010
* g++.dg/cpp2a/lambda-uneval11.c: New test.
* g++.dg/template/array33.C: New test.
* g++.dg/template/array34.C: New test.
* g++.dg/template/defarg22.C: New test.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-04-08 14:17 ` cvs-commit at gcc dot gnu.org
@ 2020-04-08 14:33 ` ppalka at gcc dot gnu.org
2021-04-21 21:25 ` ppalka at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-04-08 14:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[8/9/10 Regression] gcc |[8/9 Regression] gcc
|internal error since 8x on |internal error since 8x on
|warning write-strings |warning write-strings
--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed on GCC 10 so far.
The thread https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542487.html
which continues at
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543094.html discusses this
PR and the ultimate fix.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-04-08 14:33 ` [Bug c++/92010] [8/9 " ppalka at gcc dot gnu.org
@ 2021-04-21 21:25 ` ppalka at gcc dot gnu.org
2021-10-05 9:55 ` nickhuang99 at hotmail dot com
` (5 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-04-21 21:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
This fix seems too risky to backport.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2021-04-21 21:25 ` ppalka at gcc dot gnu.org
@ 2021-10-05 9:55 ` nickhuang99 at hotmail dot com
2021-10-05 14:23 ` ppalka at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: nickhuang99 at hotmail dot com @ 2021-10-05 9:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
qingzhe huang <nickhuang99 at hotmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickhuang99 at hotmail dot com
--- Comment #11 from qingzhe huang <nickhuang99 at hotmail dot com> ---
The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
run by compiler cc1plus with latest code. And gdb shows that global var
"current_function_decl" is set to 0 when crashed. Should we reopen this bug?
./install/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/cc1plus -std=c++20
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C
<lambda()> void spam(decltype (<lambda>) (*)[sizeof (T)]) void foo()
<lambda()> static constexpr void<lambda()>::_FUN()
constexpr<lambda()>::operator void (*)()() const <lambda()> static constexpr
void<lambda()>::_FUN() constexpr<lambda()>::operator void (*)()() const
<lambda()> static constexpr void<lambda()>::_FUN()
constexpr<lambda()>::operator void (*)()() const <lambda()> static constexpr
void<lambda()>::_FUN() constexpr<lambda()>::operator void (*)()() const
constexpr<lambda()>::operator void (*)()() const <lambda()> static constexpr
void<lambda()>::_FUN() constexpr<lambda()>::operator void (*)()() const
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C: In instantiation of
‘constexpr<lambda()>::operator void (*)()() const’:
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:9:12: required from
here
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:4:25: internal compiler
error: Segmentation fault
4 | template <class T> void spam(decltype([]{}) (*s)[sizeof(T)] = nullptr)
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2021-10-05 9:55 ` nickhuang99 at hotmail dot com
@ 2021-10-05 14:23 ` ppalka at gcc dot gnu.org
2021-10-05 16:21 ` nickhuang99 at hotmail dot com
` (3 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-10-05 14:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #12 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to qingzhe huang from comment #11)
> The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> run by compiler cc1plus with latest code.
Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2021-10-05 14:23 ` ppalka at gcc dot gnu.org
@ 2021-10-05 16:21 ` nickhuang99 at hotmail dot com
2021-10-05 21:05 ` ppalka at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 13+ messages in thread
From: nickhuang99 at hotmail dot com @ 2021-10-05 16:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #13 from qingzhe huang <nickhuang99 at hotmail dot com> ---
(In reply to Patrick Palka from comment #12)
> (In reply to qingzhe huang from comment #11)
> > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> > run by compiler cc1plus with latest code.
>
> Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull. It
won't show anything when compiling with driver, i.e. g++, but if you run
"cc1plus", it will crash. For example,
${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus -std=c++20
./lambda-uneval11.C
Thank you
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2021-10-05 16:21 ` nickhuang99 at hotmail dot com
@ 2021-10-05 21:05 ` ppalka at gcc dot gnu.org
2021-10-05 21:56 ` nickhuang99 at hotmail dot com
2021-10-05 22:08 ` nickhuang99 at hotmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-10-05 21:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #14 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to qingzhe huang from comment #13)
> (In reply to Patrick Palka from comment #12)
> > (In reply to qingzhe huang from comment #11)
> > > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> > > run by compiler cc1plus with latest code.
> >
> > Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
>
> I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull.
> It won't show anything when compiling with driver, i.e. g++, but if you run
> "cc1plus", it will crash. For example,
> ${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus
> -std=c++20 ./lambda-uneval11.C
>
> Thank you
Ah yeah, I can reproduce the crash when invoking cc1plus directly and also when
passing -Q to the driver. Might be better to open a separate PR for this as it
seems to be a latent bug.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2021-10-05 21:05 ` ppalka at gcc dot gnu.org
@ 2021-10-05 21:56 ` nickhuang99 at hotmail dot com
2021-10-05 22:08 ` nickhuang99 at hotmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: nickhuang99 at hotmail dot com @ 2021-10-05 21:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #15 from qingzhe huang <nickhuang99 at hotmail dot com> ---
>>Might be better to open a separate PR for this as it
seems to be a latent bug.
thanks, I will file a new bug.
From: ppalka at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: October 5, 2021 5:05 PM
To: nickhuang99@hotmail.com <nickhuang99@hotmail.com>
Subject: [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on
warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #14 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to qingzhe huang from comment #13)
> (In reply to Patrick Palka from comment #12)
> > (In reply to qingzhe huang from comment #11)
> > > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> > > run by compiler cc1plus with latest code.
> >
> > Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
>
> I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull.
> It won't show anything when compiling with driver, i.e. g++, but if you run
> "cc1plus", it will crash. For example,
> ${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus
> -std=c++20 ./lambda-uneval11.C
>
> Thank you
Ah yeah, I can reproduce the crash when invoking cc1plus directly and also when
passing -Q to the driver. Might be better to open a separate PR for this as it
seems to be a latent bug.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
[not found] <bug-92010-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2021-10-05 21:56 ` nickhuang99 at hotmail dot com
@ 2021-10-05 22:08 ` nickhuang99 at hotmail dot com
12 siblings, 0 replies; 13+ messages in thread
From: nickhuang99 at hotmail dot com @ 2021-10-05 22:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #16 from qingzhe huang <nickhuang99 at hotmail dot com> ---
> Ah yeah, I can reproduce the crash when invoking cc1plus directly and also
> when
> passing -Q to the driver. Might be better to open a separate PR for this as
> it
> seems to be a latent bug.
just opened a new bug: pr102624
^ permalink raw reply [flat|nested] 13+ messages in thread