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
