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.
(In reply to Mark Millard from comment #0) I have submitted 28788 to llvm's bugzilla against 3.8 --a minor variation of the same basic text as here.
I tried the 9-line test source under head -r358510 and it (system clang++ 9) had no troubles.