Bug 2062 - ./ns3/epc-x2-sap.h:311:10: error: ‘params.ns3::EpcX2Sap::ResourceStatusUpdateParams::targetCellId’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
./ns3/epc-x2-sap.h:311:10: error: ‘params.ns3::EpcX2Sap::ResourceStatusUpdate...
Status: RESOLVED WONTFIX
Product: ns-3
Classification: Unclassified
Component: lte
pre-release
PC Linux
: P5 enhancement
Assigned To: Nicola Baldo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-11 15:20 UTC by Manuel Rüger
Modified: 2015-02-16 05:03 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Rüger 2015-02-11 15:20:09 UTC
Steps to reproduce:
- Use Ns3 Master
- Activate c++11 support*
- Configure with -d optimized
- Build

*I've added 
def configure(conf):
    conf.env.append_value('CXXFLAGS','-std=c++11');                                                                                                                                                    to my own module.

If I don't use "-d optimized" to configure ns3, build is successful.

Result:


In file included from ./ns3/epc-x2-header.h:24:0,
                 from ../src/lte/model/epc-x2.cc:27:
./ns3/epc-x2-sap.h: In member function ‘void ns3::EpcX2::RecvFromX2cSocket(ns3::Ptr<ns3::Socket>)’:
./ns3/epc-x2-sap.h:311:10: error: ‘params.ns3::EpcX2Sap::ResourceStatusUpdateParams::targetCellId’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   struct ResourceStatusUpdateParams
          ^
../src/lte/model/epc-x2.cc:349:52: note: ‘params.ns3::EpcX2Sap::ResourceStatusUpdateParams::targetCellId’ was declared here
           EpcX2SapUser::ResourceStatusUpdateParams params;
                                                    ^
cc1plus: all warnings being treated as errors
Waf: Leaving directory `/home/mrueg/ns3/build'
Build failed
 -> task in 'ns3-lte' failed (exit status 1): 
        {task 140439618012304: cxx epc-x2.cc -> epc-x2.cc.1.o}
['/usr/bin/g++', '-O3', '-g', '-Wall', '-Werror', '-march=native', '-fstrict-overflow', '-std=c++11', '-Wno-error=deprecated-declarations', '-fstrict-aliasing', '-Wstrict-aliasing', '-fPIC', '-pthread', '-I.', '-I..', '-I/usr/include/libxml2', '-DHAVE_SYS_IOCTL_H=1', '-DHAVE_IF_NETS_H=1', '-DHAVE_NET_ETHERNET_H=1', '-DHAVE_PACKET_H=1', '-DHAVE_SQLITE3=1', '-DHAVE_IF_TUN_H=1', '-DHAVE_GSL=1', '../src/lte/model/epc-x2.cc', '-c', '-o', 'src/lte/model/epc-x2.cc.1.o']
Comment 1 Manuel Rüger 2015-02-11 15:20:58 UTC
As requested on IRC:
gcc --version
gcc (Gentoo 4.9.2 p1.0, pie-0.6.1) 4.9.2
Comment 2 Nicola Baldo 2015-02-13 04:22:33 UTC
I tried to reproduce using changeset94c2675383e6 with
CC=gcc-4.9 CXX=g++-4.9 CXXFLAGS="-std=c++11" ./waf configure --enable-examples --enable-tests --disable-gtk -d optimized
and build succeeds on the system I am using (gcc 4.9.2, x86_64).

Is any further setting needed to reproduce the bug? If finally it can't be reproduced, I'd close it as invalid.
Comment 3 Tom Henderson 2015-02-14 17:26:51 UTC
(In reply to Nicola Baldo from comment #2)
> I tried to reproduce using changeset94c2675383e6 with
> CC=gcc-4.9 CXX=g++-4.9 CXXFLAGS="-std=c++11" ./waf configure
> --enable-examples --enable-tests --disable-gtk -d optimized
> and build succeeds on the system I am using (gcc 4.9.2, x86_64).
> 

I also could not reproduce on Fedora Core 21 server with gcc-4.9.2, passing CXXFLAGS as above.

Manuel, can you try on your platform to checkout a clean ns-3-dev and run the above configure (then './waf build') that Nicola tried?
Comment 4 Manuel Rüger 2015-02-14 20:00:23 UTC
I can't reproduce it with CXXFLAGS="-std=c++11" set.

Without CXXFLAGS="-std=c++11" it is reproducable, if a single module has set c++11 in its wscript.
Comment 5 Nicola Baldo 2015-02-16 05:03:07 UTC
This seems to be a rather infrequent use case, so considered that the build of a clean ns-3-dev is ok, I'd take no further action. Hence I am marking this as resolved->won't fix.

Manuel, if you think that this is really important for you, feel free to reopen the bug and propose a patch, and we'll consider applying it.