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

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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.