[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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);
}

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.)

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[cvs-commit at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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?

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com]

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

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[ppalka at gcc dot gnu.org]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com]

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.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com]

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