[Bug c++/79572] New: [6/7 Regression] Segfault with -O1 and higher on null reference
janus at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Feb 17 10:57:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572
Bug ID: 79572
Summary: [6/7 Regression] Segfault with -O1 and higher on null
reference
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janus at gcc dot gnu.org
Target Milestone: ---
Please consider this simple piece of code:
#include <iostream>
void f(const int &iref) {
if (&iref)
std::cout << iref << std::endl;
else
std::cout << "iref is NULL" << std::endl;
}
int main () {
f(*((int*) NULL));
return 0;
}
It is accepted by GCC 5 (and all earlier versions I tried), printing at all
optimization levels:
iref is NULL
That is also the result I get with GCC 6.2.0 using -O0. However, at -O1 and
higher it runs into a segfault, both with GCC 6.2.0 and a recent trunk build
(7.0.1 20170212).
When using -Wall, GCC 6 also prints these warnings:
null_ref.cpp:4:12: warning: the compiler can assume that the address of ‘iref’
will always evaluate to ‘true’ [-Waddress]
null_ref.cpp:4:3: warning: nonnull argument ‘iref’ compared to NULL
[-Wnonnull-compare]
if (&iref)
I agree that this way of using null references is not very nice & clean, but
it's used extensively in large code bases out there (e.g.
https://github.com/tpaviot/oce).
I can see two ways to fix this and I'm fine with either:
1) Disable the optimization that generates the segfault.
2) Reject the code with a hard error (in particular with -O1 and above).
For the second option, what should be rejected is probably the dereferencing of
a NULL pointer in
f(*((int*) NULL))
More information about the Gcc-bugs
mailing list