[Bug c++/101150] New: null pointer dereference false positive disappears when compiling an additional function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101150
Bug ID: 101150
Summary: null pointer dereference false positive disappears
when compiling an additional function
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
Created attachment 51042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51042&action=edit
source code, plus the three preprocessed versions
I'm observing the following behavior with gcc-snapshot on Debian
unstable as well as when using "x86-64 gcc (trunk)" and "x86-64 gcc
(11.1)" on Godbolt. This false positive is not reported by gcc 10.
% g++ --version | sed 1q
g++ (Debian 20210527-1) 12.0.0 20210527 (experimental) [master revision
262e75d22c3:7bb6b9b2f47:9d3a953ec4d2695e9a6bfa5f22655e2aea47a973]
% cat foo.cc
#include
#ifdef FOO
void foo(const std::vector& other)
{
std::vector v;
std::size_t sz = other.size();
v.resize(sz);
int i = 0;
for (int o: other)
v[i++] = o;
}
#endif
#ifdef BAR
void bar(const std::vector& other)
{
std::vector v;
unsigned sz = other.size();
v.resize(sz);
int i = 0;
for (int o: other)
v[i++] = o;
}
#endif
% g++ -O3 -Wnull-dereference -c foo.cc -DBAR
% g++ -O3 -Wnull-dereference -c foo.cc -DFOO -DBAR
% g++ -O3 -Wnull-dereference -c foo.cc -DFOO
In function 'void foo(const std::vector&)':
cc1plus: warning: potential null pointer dereference [-Wnull-dereference]
The two functions differ only by the type of sz, and the warning
occurs only if foo() is compiled but bar() is not.
I *believe* the warning comes from the fact that if sz is 0, the data
pointer of v will still be nullptr after resize(), and that would
render v[i++]=o invalid. However if sz is 0, the loop will not do
any iteration, so that's a false positive.
However I can't explain
- why changing size_t into unsigned makes the warning go away,
- why compiling the two functions makes the warning go away.
I was expecting the diagnostics about foo() to be independent of the presence
of bar(), and I was expecting to get the same diagnostics for both functions
(preferably none, but I understand it's only a "potential" issue)
[Bug preprocessor/103488] New: cpp --help lists some options that are silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103488
Bug ID: 103488
Summary: cpp --help lists some options that are silently
ignored
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
Hi!
Sorry for this trivialish issue, but that puzzled me for 10 minutes this
morning while I was looking whether cpp had some option I needed.
The help text of cpp suggests that `cpp --help=common' will work, but that
option seems to be silently ignored.
% cpp --version | sed 1q
cpp (Debian 11.2.0-12) 11.2.0
% cpp --help | sed 7q
Usage: cpp [options] file...
Options:
-pass-exit-codes Exit with highest error code from a phase.
--help Display this information.
--target-helpDisplay target specific command line options.
--help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...].
Display specific types of command line options.
% cpp --help=common "
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 ""
% cpp --help=foobarbaz "
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 ""
Given this help text, I would have expected any use of --help=... to prevent
the normal behavior of cpp, and I would have expected a diagnostic for
--help=foobarbaz.
[Bug c++/106159] New: Have -Woverloaded-virtual not warn about virtual destructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106159 Bug ID: 106159 Summary: Have -Woverloaded-virtual not warn about virtual destructors? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adl at gnu dot org Target Milestone: --- The new version of -Woverloaded-virtual recently introduced seems to warn about virtual destructors in case of multiple inheritance. Is this really intended? Could destructors be ignored from this warning? Also note that the diagnostic is output three times. $ cat > vee.cc
[Bug tree-optimization/108860] [12/13/14/15 regression] New (since gcc 12) false positive null-dereference in vector.resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108860
Alexandre Duret-Lutz changed:
What|Removed |Added
CC||adl at gnu dot org
--- Comment #3 from Alexandre Duret-Lutz ---
Arrived here because I have the same issue, but with an even simpler input.
% cat foo.c
#include
void test(std::vector& v)
{
v.insert(v.begin(), 12);
}
% g++ -O -std=c++20 -Werror=null-dereference -c foo.cc
In file included from /usr/include/c++/13/bits/stl_iterator.h:85,
from /usr/include/c++/13/bits/stl_algobase.h:67,
from /usr/include/c++/13/vector:62,
from foo.cc:1:
In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*,
_Args&& ...) [with _Tp = int; _Args = {int}]’,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = int; _Args = {int}; _Tp = int]’ at
/usr/include/c++/13/bits/alloc_traits.h:540:21,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_realloc_insert(iterator, _Args&& ...) [with _Args = {int}; _Tp =
int; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/vector.tcc:468:28,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::_M_insert_rval(const_iterator, value_type&&) [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/13/bits/vector.tcc:372:19,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, value_type&&) [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/13/bits/stl_vector.h:1394:30,
inlined from ‘void test(std::vector&)’ at foo.cc:5:11:
/usr/include/c++/13/bits/stl_construct.h:97:14: error: potential null pointer
dereference [-Werror=null-dereference]
97 | { return ::new((void*)__location)
_Tp(std::forward<_Args>(__args)...); }
|
^~~~
cc1plus: some warnings being treated as errors
Reproduced with
- g++-13 (Debian 13.2.0-25) 13.2.0
- g++-12 (Debian 12.3.0-17) 12.3.0
[Bug c++/120288] New: spurious null pointer dereference in std::__detail::_Hashtable_base::_M_key_equals since gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120288
Bug ID: 120288
Summary: spurious null pointer dereference in
std::__detail::_Hashtable_base::_M_key_equals since
gcc-15
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
Created attachment 61428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61428&action=edit
preprocessed sources
The following code produces spurious "potential null pointer dereference" with
GCC 15.1 and Debian's gcc-snapshot (20250502).
Those false positives where not produced with GCC 14.2 and earlier.
I found it quite hard to reduce the problem, because the diagnostics were only
pointing to the C++ headers, without any indication of what part of my code
called that method.
https://godbolt.org/z/s7W46dqnj
% cat foo.cc
#include
class key
{
};
bool less_than(const key* left, const key* right) noexcept;
struct hash
{
size_t
operator()(const key*) const noexcept
{
return 0;
}
};
struct equal
{
bool
operator()(const key* left, const key* right) const noexcept
{
return less_than(left, right);
}
};
class foo
{
public:
foo();
private:
std::unordered_map map;
};
foo::foo()
{
key b;
map.find(&b);
}
% g++ -O -Wnull-dereference -Werror -c foo.cc
In file included from /usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:37,
from
/usr/lib/gcc-snapshot/include/c++/16/bits/unordered_map.h:33,
from /usr/lib/gcc-snapshot/include/c++/16/unordered_map:43,
from foo.cc:1:
In member function 'bool std::__detail::_Hashtable_base<_Key, _Value,
_ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _Traits>::_M_key_equals(const
_Key&, const std::__detail::_Hash_node_value<_Value, typename
_Traits::__hash_cached::value>&) const [with _Key = const key*; _Value =
std::pair; _ExtractKey = std::__detail::_Select1st;
_Equal = equal; _Hash = hash; _RangeHash = std::__detail::_Mod_range_hashing;
_Unused = std::__detail::_Default_ranged_hash; _Traits =
std::__detail::_Hashtable_traits]',
inlined from 'std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::__location_type
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::_M_locate(const key_type&) const [with _Key =
const key*; _Value = std::pair; _Alloc =
std::allocator >; _ExtractKey =
std::__detail::_Select1st; _Equal = equal; _Hash = hash; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]' at
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:2272:31,
inlined from 'std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::iterator
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::find(const key_type&) [with _Key = const
key*; _Value = std::pair; _Alloc =
std::allocator >; _ExtractKey =
std::__detail::_Select1st; _Equal = equal; _Hash = hash; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits]' at
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable.h:1918:32:
/usr/lib/gcc-snapshot/include/c++/16/bits/hashtable_policy.h:1409:23: error:
potential null pointer dereference [-Werror=null-dereference]
1409 | return _M_eq()(__k, _ExtractKey{}(__n._M_v()));
|~~~^~~~
cc1plus: all warnings being treated as errors
