This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Apparent deeply-nested missing error bug with gcc 7.3
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Soul Studios <matt at soulstudios dot co dot nz>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 19 Jun 2018 11:04:30 +0100
- Subject: Re: Apparent deeply-nested missing error bug with gcc 7.3
- References: <5B270A8F.4090802@soulstudios.co.nz> <CAH6eHdSA+hYV=9Jzpk2TF=Gj042u_t7CciC=L_sQ9ZTCH2UoOg@mail.gmail.com> <CAH6eHdTUoujUeqDdykLatVcbRjf_ixEoZnVs=s864+Ha9hEchQ@mail.gmail.com> <d5dc5dfa-983e-ec12-9223-72f4949f4325@soulstudios.co.nz>
On Tue, 19 Jun 2018 at 01:30, Soul Studios wrote:
>
> >
> > It's never called.
> >
> > I added a call to abort() to that function, and the tests all pass. So
> > the function is never used, so GCC never compiles it and doesn't
> > notice that the return type is invalid. That's allowed by the
> > standard. The compiler is not required to diagnose ill-formed code in
> > uninstantiated templates.
> >
>
>
> UPDATE: My bad.
> The original compiler feature detection on the test suite was broken/not
> matching the correct libstdc++ versions.
> Hence the emplace_back/emplace_front tests were not running.
Told you so :-P
> However, it does surprise me that GCC doesn't check this code.
It's a dependent expression so can't be fully checked until
instantiated -- and as you've discovered, it wasn't being
instantiated. There's a trade-off between compilation speed and doing
additional work to check uninstantiated templates with arbitrarily
complex expressions in them.