https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108781
Bug ID: 108781
Summary: Underlying variables of structured bindings should not
be treated as having external or module linkage
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: link-failure, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
For the following example with two translation units:
```C++
// main.cpp
using Arr = int[2];
auto [bx, by] = Arr{};
int main(){}
```
```C++
// a.cpp
using Arr = int[2];
auto [bx, by] = Arr{};
```
Currently a linker error is emitted (Godbolt link:
https://godbolt.org/z/e43s4ErKs):
> /opt/compiler-explorer/gcc-trunk-20230213/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
> CMakeFiles/test.dir/main.cpp.o:(.bss+0x0): multiple definition of
> `_ZDC2bx2byE'; CMakeFiles/test.dir/a.cpp.o:(.bss+0x0): first defined here
The linker succeeds if `[bx, by]` is changed to `[bx, bz]` in either TU (but
not both).
Presumably, _ZDC2bx2byE is the mangled name of the unnamed variable created in
the structured binding declaration. Per current standard wording ([basic.link],
see also discussion in https://github.com/cplusplus/CWG/issues/240), structured
bindings have no linkage, and so do the unname variables because they don't
even have names.
So linker should be successful for this example, and both TUs have its own
distinct unnamed variable.
