https://llvm.org/bugs/show_bug.cgi?id=28788
Bug ID: 28788
Summary: Context FreeBSD's clang 3.8.0: false warning: wrong
type/value involved in compiler's false message
Product: clang
Version: 3.8
Hardware: All
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mar...@dsl-only.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
[This is from a submittal on FreeBSD's bugzilla against FreeBSD 11.0-BETA3 and
its system clang++ (3.8.0). My testing is limited to that context but I'd be
surprised if the below is FreeBSD specific, architecture specific, etc.]
The context here was a -r419343 /usr/ports based report, although later below I
show a 9-line, simple source that shows the issue . . .
The FreeeBSD devel/qmake5 port: . . ./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 9-line 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 in the stack's storage would be a nullptr
(translated to int*). T is int* above. The returned value should be the int*
value, not an int**.
The result of running the compiled code 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 message 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 (as it should be) not a stack address at all.
Originally I was going to report this against the FreeBSD port 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 messages. It appears to me that the C++ code generated is
correct.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
