Re: [C++ PATCH] lang_decl selector & decomposition

[Jakub Jelinek <jakub@redhat.com>]

On Wed, May 31, 2017 at 01:16:36PM -0400, Nathan Sidwell wrote:
> On 05/31/2017 01:05 PM, Jakub Jelinek wrote:
> 
> > That is weird, that sounds like a bug somewhere?  Which testcase is it on?
> 
> I think decomp25 & decomp7 & 8 (sorry, can't recall full name).
> I discovered them because my first attempt had an assert that the incoming
> base was the same as the stored one, for the already-converted case.

That doesn't look like a bug to me.
When instantiating structured binding inside of a template, the VAR_DECL is
created using copy_decl from the template VAR_DECL:
#0  0x00007ffff69a6521 in memcpy () from /lib64/libc.so.6
#1  0x00000000008ca690 in cxx_dup_lang_specific_decl (node=<var_decl 0x7fffefc23b40 d>) at ../../gcc/cp/lex.c:657
#2  0x00000000008ca6ee in copy_decl (decl=<var_decl 0x7fffefc01900 d>) at ../../gcc/cp/lex.c:675
#3  0x00000000009b174b in tsubst_decl (t=<var_decl 0x7fffefc01900 d>, args=<tree_vec 0x7fffefc2ef00>, complain=3) at ../../gcc/cp/pt.c:12860
#4  0x00000000009b3796 in tsubst (t=<var_decl 0x7fffefc01900 d>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>) at ../../gcc/cp/pt.c:13376
#5  0x00000000009bf6e8 in tsubst_decomp_names (decl=<var_decl 0x7fffefc23a20>, pattern_decl=<var_decl 0x7fffefc017e0>, 
    args=<tree_vec 0x7fffefc2ef00>, complain=3, in_decl=<template_decl 0x7fffefc1ad80 foo>, first=0x7fffffffd648, cnt=0x7fffffffd654)
    at ../../gcc/cp/pt.c:15719
#6  0x00000000009c0a5a in tsubst_expr (t=<decl_expr 0x7fffefc14ce0>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15890
#7  0x00000000009bfc0d in tsubst_expr (t=<statement_list 0x7fffefc14c00>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15771
#8  0x00000000009c1832 in tsubst_expr (t=<bind_expr 0x7fffefabea80>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15998
#9  0x00000000009e2d6d in instantiate_decl (d=<function_decl 0x7fffefc1c900 foo>, defer_ok=false, expl_inst_class_mem_p=false)
    at ../../gcc/cp/pt.c:22965
and then finalized later:
#0  fit_decomposition_lang_decl (t=<var_decl 0x7fffefc23b40 d>, base=<var_decl 0x7fffefc23a20>) at ../../gcc/cp/lex.c:588
#1  0x000000000084a584 in cp_finish_decomp (decl=<var_decl 0x7fffefc23a20>, first=<var_decl 0x7fffefc23b40 d>, count=2)
    at ../../gcc/cp/decl.c:7387
#2  0x00000000009c0a9b in tsubst_expr (t=<decl_expr 0x7fffefc14ce0>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15894
#3  0x00000000009bfc0d in tsubst_expr (t=<statement_list 0x7fffefc14c00>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15771
#4  0x00000000009c1832 in tsubst_expr (t=<bind_expr 0x7fffefabea80>, args=<tree_vec 0x7fffefc2ef00>, complain=3, 
    in_decl=<template_decl 0x7fffefc1ad80 foo>, integral_constant_expression_p=false) at ../../gcc/cp/pt.c:15998
#5  0x00000000009e2d6d in instantiate_decl (d=<function_decl 0x7fffefc1c900 foo>, defer_ok=false, expl_inst_class_mem_p=false)
    at ../../gcc/cp/pt.c:22965

So unless cxx_dup_lang_specific_decl or copy_decl or tsubst_decl
clears the DECL_DECOMP_BASE for the short time before cp_finish_decomp
is called, DECL_DECOMP_BASE will be "wrong" for a short time, but it
shouldn't matter, nothing should be querying it in between.  Setting
it to NULL wouldn't be correct either anyway.

	Jakub