[Bug c++/83990] New: Spurious "potential null pointer dereference" warning regression from 7.1 onwards
TonyELewis at hotmail dot com
gcc-bugzilla@gcc.gnu.org
Tue Jan 23 10:54:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Bug ID: 83990
Summary: Spurious "potential null pointer dereference" warning
regression from 7.1 onwards
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 43217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43217&action=edit
Pre-processed (-save-temps) on GCC 7.2.0 [Ubuntu 17.10]
Compiling this code:
#include <iostream>
#include <string>
#include <vector>
void a() {
std::vector<std::string> s;
s.reserve( 5 );
for (const std::string &x : s) {
std::cout << x;
}
}
template <typename... Ts> void ignore_unused(Ts &&...) {}
void b() {
for (const int &i : { 0, 0, 0, 0 } ) {
ignore_unused( i );
std::vector<std::string> s;
s.reserve( 5 );
for (const std::string &x : s) {
std::cout << x;
}
}
}
...with...
g++ -std=c++17 -O3 -Werror -Wnull-dereference a.cpp -s -o /tmp/a.o
Gives the following error (upgraded from a warning):
In function ‘void std::vector<_Tp, _Alloc>::reserve(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = std::__cxx11::basic_string<char>; _Alloc =
std::allocator<std::__cxx11::basic_string<char> >]’:
cc1plus: error: potential null pointer dereference
[-Werror=null-dereference]
cc1plus: all warnings being treated as errors
I don't think the user code is doing anything to warrant this warning and it's
unhelpful that there is no stack/line information to track the issue.
I'm guessing that the problem here is that, as is hypothesised for bug 83591,
the source location info has been lost so the warning isn't being squelched as
it should for being in a system header.
>From what I can see on GodBolt, this issue was introduced between 6.3 and 7.1
and is still present in trunk (8.0.1 20180122).
In 7.1, the problem goes away if compiling with -std=c++14 or -std=c++11
(rather than -std=c++17) but in trunk (8.0.1 20180122) the problem persists in
all three modes.
More information about the Gcc-bugs
mailing list