The "3" flag on the line marker marks the following lines as originating from a system header where warnings are suppressed.  Use -Wsystem-headers to enable them.

I don't want to enable them. The problem is not with too little but too many warnings.

A snippet from one of the problematic files:

	{ NULL, NULL, false, false }

is preprocessed to 

 { 
# 62 "AdsPlugin.cpp" 3 4
  __null
# 62 "AdsPlugin.cpp"
      , 
# 62 "AdsPlugin.cpp" 3 4
        __null
# 62 "AdsPlugin.cpp"
            , false, false }
};

Here I see the same flags, yet for these two NULLs gcc warns.

(In reply to petschy from comment #0)
> For c++11 and later code, why is NULL defined as __null, rather than nullptr?

Because defining NULL as nullptr would violate the requirements of the standard, which very intentionally says that NULL is an integral constant expression, not nullptr.

(In reply to petschy from comment #2)
> Here I see the same flags, yet for these two NULLs gcc warns.

prog.cc:6:28: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]
             , false, false };
                            ^

because the location given is wrong, so the location in this case is not within the system-header flags. If the location was right (under __null), it would not warn. That is the bug.

Some more details, hope this helps. Preprocessed one of the oddly behaving files with 5.4.1, 6.2.1 and 7.0.0, then tried to compile each preprocessed file with each compiler version. 5.4.1 warned for all preprocessed files, 6.2.1 and 7.0.0 didn't warn for any of them. This doesn't mean that 6.2.1 and 7.0.0 is not affected, just for this particular file they didn't warn. 

Diffing the files revealed that there is no difference in the user code, only in the system headers included, eg <string> comes from /usr/local/include/c++/5.4.1/string for 5.4.1, etc.

All of the problematic lines are assignments of the form
  var = NULL;
or
  var1 = var2 = NULL;

ALL of the NULL assignments in the file are reported.
NONE of the == or != tests are reported.

Eg: this code warns:

AbstractImage::AbstractImage()
{
 pixels=
# 124 "common/src/AbstractImage.cpp" 3 4
       __null
# 124 "common/src/AbstractImage.cpp"
           ;
 channels_n=0;
 mode=255;
 width=-1;
 height=-1;
}

But if I replace 'pixels =' with 'bool b = pixels ==' above, the warning disappears, which is strange, I think.

The flags are the same for the != and == tests, ie 
# <n> "common/src/AbstractImage.cpp" 3 4
is everywhere.

(In reply to Jonathan Wakely from comment #3)
> (In reply to petschy from comment #0)
> > For c++11 and later code, why is NULL defined as __null, rather than nullptr?
> 
> Because defining NULL as nullptr would violate the requirements of the
> standard, which very intentionally says that NULL is an integral constant
> expression, not nullptr.

I don't know how autoritative is it, but cppreference.com says that since C++11,  NULL is

    an integer literal with value zero, or a prvalue of type std::nullptr_t

See: http://en.cppreference.com/w/cpp/types/NULL

"The macro NULL is an implementation-defined null pointer constant.", says the C++ standard draft.

See r260973

(In reply to Ville Voutilainen from comment #7)
> "The macro NULL is an implementation-defined null pointer constant.", says
> the C++ standard draft.

So it does, maybe I was misremembering something from an older C++0x draft.

Either way, 0 is still a valid definition of NULL, and I suspect that defining NULL as nullptr would break a lot of code (albeit bad code that is misusing NULL).

*** Bug 77299 has been marked as a duplicate of this bug. ***

Confirmed.

*** Bug 103347 has been marked as a duplicate of this bug. ***

An intereting case from PR 103347 where the pedwarn about the NSDMI is suppressed because GCC thinks the initializer is in a system header:

#include <cstddef>
struct test {
    void *x = NULL; //invalid in C++03 mode
};
int main() {}

This should be rejected with -pedantic-errors, but g++ is silent unless you also add -Wsystem-headers.

(In reply to Jonathan Wakely from comment #13)
> An intereting case from PR 103347 where the pedwarn about the NSDMI is
> suppressed because GCC thinks the initializer is in a system header:
> 
> #include <cstddef>
> struct test {
>     void *x = NULL; //invalid in C++03 mode
> };
> int main() {}
> 
> This should be rejected with -pedantic-errors, but g++ is silent unless you
> also add -Wsystem-headers.

And this is a regression, because 4.8 silently accepts this code in C++98 mode, whereas 4.7 warns about it as expected:

null.C:3:15: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default]

Note the original issue with -Wzero-as-null-pointer-constant is fixed in GCC 9 by r9-873. The system header issue is now listed as PR 77299.