Apparent deeply-nested missing error bug with gcc 7.3

Apparent deeply-nested missing error bug with gcc 7.3

[Soul Studios]

In the following case GCC correctly throws an error since 
simple_return_value is returning a pointer, not a reference:

"#include <iostream>

int & simple_return_value(int &temp)
{
	return &temp;
}


int main()
{
	int temp = 42;
	return simple_return_value(temp);
}"



However in deeply-nested code GCC appears to miss the error, and in fact 
still returns a reference despite the return value of a pointer.

Take the following code in plf_list 
(https://github.com/mattreecebentley/plf_list):

"template<typename... arguments>
inline PLF_LIST_FORCE_INLINE reference emplace_back(arguments &&... 
parameters)
{
	return (emplace(end_iterator, 
std::forward<arguments>(parameters)...)).node_pointer->element;
}
"


emplace returns an iterator which contains a pointer to a node, which is 
then used to return the element at that node. However if you change the 
line to:
	"return &((emplace(end_iterator, 
std::forward<arguments>(parameters)...)).node_pointer->element);"


GCC 7.3 doesn't blink. Worse, it appears to return a reference anyway. 
The test suite cpp explicitly tests the return value of emplace_back, so 
changing the line should result in a test fail as well as a compile 
error. Neither occur.
You can test this yourself by downloading the code + test suite at 
http://www.plflib.org/plf_list_18-06-2018.zip
and editing the line yourself (line 1981).

Clang 3.7.1 detects the error immediately.


I'm not sure at which stage this bug appears. Templating the code at the 
top of this mail doesn't recreate the bug, so it must be something to do 
with templated classes (I'm guessing here).

Hopefully someone can shed some light on this.

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Jonathan Wakely]

This is not the right place for bug reports. Please use the gcc-help
list or Bugzilla.

The most likely scenario is that GCC is performing an implicit
conversion from pointer to some class type (like an iterator) and then
converting that to a reference. Or the function template is not being
called.


On Mon, 18 Jun 2018 at 02:28, Soul Studios wrote:
>
> In the following case GCC correctly throws an error since
> simple_return_value is returning a pointer, not a reference:
>
> "#include <iostream>
>
> int & simple_return_value(int &temp)
> {
>         return &temp;
> }
>
>
> int main()
> {
>         int temp = 42;
>         return simple_return_value(temp);
> }"
>
>
>
> However in deeply-nested code GCC appears to miss the error, and in fact
> still returns a reference despite the return value of a pointer.
>
> Take the following code in plf_list
> (https://github.com/mattreecebentley/plf_list):
>
> "template<typename... arguments>
> inline PLF_LIST_FORCE_INLINE reference emplace_back(arguments &&...
> parameters)
> {
>         return (emplace(end_iterator,
> std::forward<arguments>(parameters)...)).node_pointer->element;
> }
> "
>
>
> emplace returns an iterator which contains a pointer to a node, which is
> then used to return the element at that node. However if you change the
> line to:
>         "return &((emplace(end_iterator,
> std::forward<arguments>(parameters)...)).node_pointer->element);"
>
>
> GCC 7.3 doesn't blink. Worse, it appears to return a reference anyway.
> The test suite cpp explicitly tests the return value of emplace_back, so
> changing the line should result in a test fail as well as a compile
> error. Neither occur.
> You can test this yourself by downloading the code + test suite at
> http://www.plflib.org/plf_list_18-06-2018.zip
> and editing the line yourself (line 1981).
>
> Clang 3.7.1 detects the error immediately.
>
>
> I'm not sure at which stage this bug appears. Templating the code at the
> top of this mail doesn't recreate the bug, so it must be something to do
> with templated classes (I'm guessing here).
>
> Hopefully someone can shed some light on this.

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Jonathan Wakely]

On Mon, 18 Jun 2018 at 12:09, Jonathan Wakely wrote:
>
> This is not the right place for bug reports. Please use the gcc-help
> list or Bugzilla.
>
> The most likely scenario is that GCC is performing an implicit
> conversion from pointer to some class type (like an iterator) and then
> converting that to a reference. Or the function template is not being
> called.

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.

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Soul Studios]

> 
> 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.
> 

As I mentioned in the original message, it is called several times.
Both MSVC and Clang pick up the error, but GCC does not. It's a bug.

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Soul Studios]

> 
> 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.
However, it does surprise me that GCC doesn't check this code.
Cheers-

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Jonathan Wakely]

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.

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Jason Merrill]

On Tue, Jun 19, 2018 at 6:04 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 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.

And specifically, &<type-dependent expression> might use an overloaded
operator& that returns a reference, so it might be possible to have a
valid instantiation, so the compiler must not reject the template.

Jason

Re: Apparent deeply-nested missing error bug with gcc 7.3

[Soul Studios]

>> 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.
> 

Yeah, I get it - saves a lot of time with heavily-templated setups and 
large projects.