This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/79572] New: [6/7 Regression] Segfault with -O1 and higher on null reference
- From: "janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 17 Feb 2017 10:57:39 +0000
- Subject: [Bug c++/79572] New: [6/7 Regression] Segfault with -O1 and higher on null reference
- Auto-submitted: auto-generated
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))