https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119319
Bug ID: 119319
Summary: incorrect error: invalid use of incomplete type
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
Target: arm-linux-gnueabi
Created attachment 60787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60787&action=edit
Reduced testcase. Error at -O1 or above, only for the listed target, no error
at -O0
For the attached heavily reduced test-case, this error is emitted at -O1 and
above, but only for the listed target (arm-linux-gnueabi):
../../testcase.cc: In instantiation of 'struct std::pair<n0::Xyzzy,
std::__cxx11::basic_string<char> >':
../../testcase.cc:67:34: required from 'constexpr std::_Vector_base<_Tp,
_Alloc>::~_Vector_base() [with _Tp = std::pair<n0::Xyzzy,
std::__cxx11::basic_string<char> >; _Alloc =
std::allocator<std::pair<n0::Xyzzy, std::__cxx11::basic_string<char> > >]'
67 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
../../testcase.cc:75:11: required from here
75 | class vector : protected _Vector_base < _Tp, _Alloc > { };
| ^~~~~~
../../testcase.cc:24:9: error: 'std::pair<_T1, _T2>::first' has incomplete type
24 | _T1 first;
| ^~~~~
../../testcase.cc:83:9: note: forward declaration of 'class n0::Xyzzy'
83 | class Xyzzy;
| ^~~~~
../../testcase.cc: In constructor 'n0::CL0::CL0(int, const char*, const
n0::US0&)':
../../testcase.cc:106:28: note: synthesized method 'constexpr
std::vector<std::pair<n0::Xyzzy, std::__cxx11::basic_string<char> >,
std::allocator<std::pair<n0::Xyzzy, std::__cxx11::basic_string<char> > >
>::~vector()' first required here
106 | : Error (err, estr), us0 (vec) { }
| ^~~~~~~~~
The key line being has incomplete type and what seems to refer to Xyzzy, but
the error message quotes a forward declaration, though there's a complete
declaration (reduced empty).
I just can't find the incompleteness, and the optimization and target-specific
behavior tells me this is a gcc bug rather than program error.
Targets for which this error does *not* appear: cris-elf, aarch64-linux (also
with -mabi=ilp32). The -ftree-dump-original output shows an extra return
statement for the listed target, which looks correlated. (I have not traced
its target-specific origin.)
