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.

Reply via email to