[Bug c++/109083] New: Incorrect static_assert shown in diagnostics

[Bug c++/109083] New: Incorrect static_assert shown in diagnostics

[markus-t314 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

            Bug ID: 109083
           Summary: Incorrect static_assert shown in diagnostics
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: markus-t314 at gmx dot de
  Target Milestone: ---

Code:

#include <type_traits>

template<typename T>
void unused_function()
{
    static_assert(std::is_member_function_pointer<decltype(&T::foo)>::value,
"Line 6");
}

template<typename T>
void fail_here()
{
    static_assert(std::is_member_function_pointer<decltype(&T::foo)>::value,
"Line 12");
}

int main()
{
    fail_here<int>();
}



This fails correctly, but the wrong static assertion is given in diagnostics:

main.cpp: In instantiation of ‘void fail_here() [with T = int]’:
main.cpp:17:19:   required from here
main.cpp:6:60: error: ‘foo’ is not a member of ‘int’
    6 |    
static_assert(std::is_member_function_pointer<decltype(&T::foo)>::value, "Line
6");
      |


https://godbolt.org/z/6Yrc9x6Ws


Might be related to bug 66968

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|Incorrect static_assert     |[10/11/12/13 Regression]
                   |shown in diagnostics        |Incorrect static_assert
                   |                            |shown in diagnostics
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |needs-bisection
      Known to work|                            |4.5.3, 4.6.4, 4.7.1, 4.7.4
   Last reconfirmed|                            |2023-03-09

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What happens is that finish_template_type is called once from unused_function
with
is_member_function_pointer TEMPLATE_DECL as name and args
 <tree_vec 0x7fffea2fd2e0 length:1
    elt:0 <decltype_type 0x7fffea2fc930 VOID
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
        expr <addr_expr 0x7fffea2fd2c0 type <dependent_operator_type
0x7fffea2fc888>

            arg:0 <scope_ref 0x7fffea2fbd20 tree_0 arg:0 <template_type_parm
0x7fffea2fc738 T>
                arg:1 <identifier_node 0x7fffea2e9cc0 foo
                    normal local bindings <(nil)>>
                pr109083.ii:86:64 start: pr109083.ii:86:64 finish:
pr109083.ii:86:66>
            pr109083.ii:86:60 start: pr109083.ii:86:60 finish:
pr109083.ii:86:66>>>
(in my case of reduced preprocessed source), calls lookup_template_class, finds
nothing in
9943          entry = type_specializations->find_with_hash (&elt, hash);
and so creates
10082             t = make_class_type (TREE_CODE (template_type));
etc.
Next time finish_template_type is called from fail_here with the same
TEMPLATE_DECL as name and args
 <tree_vec 0x7fffea2fd400 length:1
    elt:0 <decltype_type 0x7fffea2fcf18 VOID
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
        expr <addr_expr 0x7fffea2fd3e0 type <dependent_operator_type
0x7fffea2fce70>

            arg:0 <scope_ref 0x7fffea302000 tree_0 arg:0 <template_type_parm
0x7fffea2fcd20 T>
                arg:1 <identifier_node 0x7fffea2e9cc0 foo
                    normal local bindings <(nil)>>
                pr109083.ii:92:64 start: pr109083.ii:92:64 finish:
pr109083.ii:92:66>
            pr109083.ii:92:60 start: pr109083.ii:92:60 finish:
pr109083.ii:92:66>>>
but this type the previously created specialization from unused_function is
returned.

So, shall template_args_equal or whatever it calls be changed so that it
doesn't consider these to be equal?  If so, what compilation memory effects
will it have?

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think this started with r0-116872-gf330f5991ef0182d59ab.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder why we instantiate from unused_function (but don't diagnose) at all?

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We don't instantiate in that case, just look up a specialization which might be
or might not be later instantiated (which is when it is diagnosed).
One way to fix this would be to drop locations from the expressions in the
template arguments if we use them from multiple spots.  But that could result
in less accurate diagnostics.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 54673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54673&action=edit
first try

Another approach would be to treat the expressions as different for the
*_specializations hash tables, as per this patch, which fixes the testcase. 
But as is this patch breaks the standard library, so more work would need to be
done to make type canonicalization continue to work.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/109083] [10/11/12/13/14 Regression] Incorrect static_assert shown in diagnostics

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug c++/109083] [11/12/13/14 Regression] Incorrect static_assert shown in diagnostics

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109083

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.