[Bug 211475] clang++ 3.8.0 false warning: wrong type/value involved in compiler's false message

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211475

            Bug ID: 211475
           Summary: clang++ 3.8.0 false warning: wrong type/value involved
                    in compiler's false message
           Product: Base System
           Version: 11.0-BETA3
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: markmi at dsl-only.net

The context here was a -r419343 /usr/ports based report, although later below I
show a 9-line, simple source that shows the issue . . .

devel/qmake5: . . ./corelib/tools/qmap.h:617:27: warning: returning address of
local temporary object

when compiled under a 11.0-BETA3 context: devel/qmake5 gets several reports of
returning the address of a local temporary object. For example:

--- metamakefile.o ---
In file included from
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/qmake/generators/metamakefile.cpp:37:
In file included from
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/include/QtCore/qdebug.h:1:
In file included from
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/include/QtCore/../../src/corelib/io/qdebug.h:40:
In file included from
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/include/QtCore/qmap.h:1:
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/include/QtCore/../../src/corelib/tools/qmap.h:617:27:
warning: returning address of local temporary object [-Wreturn-stack-address]
    return n ? n->value : adefaultValue;
                          ^~~~~~~~~~~~~
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/qmake/generators/win32/msvc_objectmodel.h:1064:32:
note: in instantiation of member function 'QMap<QString, TreeNode *>::value'
requested here
        TreeNode *n = children.value(newNodeName);
                               ^
/usr/obj/portswork/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.5.1/include/QtCore/../../src/corelib/tools/qmap.h:386:44:
note: binding reference variable 'adefaultValue' here
    const T value(const Key &key, const T &defaultValue = T()) const;
                                           ^              ~~~
I'll not go through the details of this complicated context.


A short source showing the problem is:

# more wrong_type.cc 
#include <cstddef>

template <typename T> const T value(const T &v = T()) { return v; }

int main ()
{
    int* n = value<int*>();
    return nullptr != n;
}

which when compiled reports:

# clang++ -std=c++14 wrong_type.cc
wrong_type.cc:3:64: warning: returning address of local temporary object
[-Wreturn-stack-address]
template <typename T> const T value(const T &v = T()) { return v; }
                                                               ^
wrong_type.cc:7:14: note: in instantiation of function template specialization
'value<int *>' requested here
    int* n = value<int*>();
             ^
wrong_type.cc:3:46: note: binding reference variable 'v' here
template <typename T> const T value(const T &v = T()) { return v; }
                                             ^   ~~~
1 warning generated.


Note that the "address of local temporary object" would have type int** in this
example and the value held would be a nullptr (translated to int*). T is int*
above.


The result of running the compiled result is:

# ./a.out && echo test
test

So n does end up matching nullptr, as it should. It does not end up with the
address of the local temporary object (which would not match nullptr).

# clang++ -std=c++11 -O0 wrong_type.cc

gets the same messages and the same result. Similarly for -std=c++98 or
-std=c++03.

So the warning does not match the execution behavior and the issue exists for
multiple c++ target-vintages.

It appears that for now the specific type of warning can not be relied on.


So this appears to be more than just a generic false-positive but an actual
reference to the wrong type and wrong value in the warning: the actual return
value in question is not a stack address at all.

Originally I was going to report this against devel/qmake5 but as I analyzed
the code and composed the submittal message I ended up with finding clang++ to
be referencing the wrong type and wrong value for the context in its message.
It appears to me that the C++ code generated is correct.

-- 
You are receiving this mail because:
You are the assignee for the bug.