Bug 314011 - Very strange problem with gcc-c++-4.1.2-27.fc7
Very strange problem with gcc-c++-4.1.2-27.fc7
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
7
x86_64 Linux
urgent Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-01 11:19 EDT by Neal Becker
Modified: 2008-08-02 19:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-25 00:41:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This one produces a strange warning, and incorrect results (222.01 KB, application/x-bzip2)
2007-10-01 11:19 EDT, Neal Becker
no flags Details
This one produces no warning and correct results. Only difference is to add printout (221.98 KB, application/x-bzip2)
2007-10-01 11:21 EDT, Neal Becker
no flags Details
test case (222.16 KB, application/x-bzip2)
2007-10-02 08:24 EDT, Neal Becker
no flags Details

  None (edit)
Description Neal Becker 2007-10-01 11:19:58 EDT
Description of problem:

In the first version of this code, a very strange message is output, and the 
code produces garbage results.

If I add a line to print out the results, the message is gone, and now the 
result is correct!

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Neal Becker 2007-10-01 11:19:58 EDT
Created attachment 212381 [details]
This one produces a strange warning, and incorrect results
Comment 2 Neal Becker 2007-10-01 11:21:56 EDT
Created attachment 212401 [details]
This one produces no warning and correct results.  Only difference is to add printout
Comment 3 Neal Becker 2007-10-01 11:29:36 EDT
Also, result is correct (and no warning) if compiled with -O1, but not 
with -O3.

Also, here is compile options:
g++ -o 
mod/cic.os -c -g -DBOOST_DISABLE_THREADS  -O1 -ffast-math -DNDEBUG -Wall -fPIC -Isrc -I/usr/local/src/boost.hg -I/usr/include/python2.5 
mod/cic.cc -save-temps
Comment 4 Jakub Jelinek 2007-10-01 16:04:48 EDT
The warning is correct.
for CICDecim (0, 0)
x is certainly uninitialized.
The testcase isn't self-contained, so guessing what you mean by incorrect results
is impossible.  But likely it is completely unrelated to this warning.
Comment 5 Neal Becker 2007-10-01 16:44:07 EDT
Sorry, I did not mean the x uninitialized message.  The strange message is 
this:
src/fixed.hpp:36: warning: '__imag__ x.std::complex<double>::_M_value' is used 
uninitialized in this function
src/fixed.hpp:36: warning: '__real__ x.std::complex<double>::_M_value' is used 
uninitialized in this function

This appears with -O3, but not with -O2.  Also, the code works as expected 
with -O3 but not with -O2.  I'm sorry I have been trying to get a smaller 
testcase, but so far it's been difficult.  But, what do you mean by not 
self-contained?  Isn't it sufficient to include the .ii?
Comment 6 Jakub Jelinek 2007-10-02 08:05:35 EDT
I'm certainly not seeing any warnings but:
src/cic.hpp: In function `out_t do_decim(cic_t&, const in_t&) [with cic_t =
CICDecim<int>, out_t = boost::numeric::ublas::vector<int,
boost::numeric::ublas::unbounded_array<int, std::allocator<int> > >, in_t =
boost::numeric::ublas::vector<int, boost::numeric::ublas::unbounded_array<int,
std::allocator<int> > >]':
src/cic.hpp:66: warning: `x' may be used uninitialized in this function

Tried all of -O{1,2,3} with additional -Wall -g.
Self-contained testcase for suspected miscompilation certainly isn't any .ii
file, you need something that can be also linked (ideally without the need
for anything beyond glibc libs, libgcc or perhaps libstdc++) and run and where
it is clear what a success and failure means (ideally write the testcase in a way
where if it fails, it aborts, otherwise exits with 0 exit status).
Comment 7 Neal Becker 2007-10-02 08:24:10 EDT
Created attachment 213331 [details]
test case
Comment 8 Jakub Jelinek 2007-10-02 10:26:24 EDT
You only changed one !1 to !0  and added one blank line.  Certainly it is not
self-contained and I can't reproduce any warning but the above mentioned either.
Comment 9 Neal Becker 2007-10-02 10:49:14 EDT
I just tried on another machine which is also x86_64 
rpm -q gcc-c++
gcc-c++-4.1.2-27.fc7

and got the same result.  I can't understand how it could be that you get a 
different result.  Are you using x86_64 version?  That's the only possible 
difference.
Comment 10 Jakub Jelinek 2007-10-02 11:23:30 EDT
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' gcc-c++; g++ -S -O2
314011-3.ii -Wall
gcc-c++-4.1.2-27.fc7.x86_64
src/cic.hpp: In function `out_t do_decim(cic_t&, const in_t&) [with cic_t =
CICDecim<int>, out_t = boost::numeric::ublas::vector<int,
boost::numeric::ublas::unbounded_array<int, std::allocator<int> > >, in_t =
boost::numeric::ublas::vector<int, boost::numeric::ublas::unbounded_array<int,
std::allocator<int> > >]':
src/cic.hpp:66: warning: `x' may be used uninitialized in this function
Comment 11 Neal Becker 2007-10-02 11:32:03 EDT
Problem only occurs with -O3, not with -O2.  Looks like you used -O2.
Comment 12 Jakub Jelinek 2007-10-02 11:40:59 EDT
That's exactly the same diagnostic:
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' gcc-c++; g++ -S -O3 -Wall
314011-3.ii
gcc-c++-4.1.2-27.fc7.x86_64
src/cic.hpp: In function `out_t do_decim(cic_t&, const in_t&) [with cic_t =
CICDecim<int>, out_t = boost::numeric::ublas::vector<int,
boost::numeric::ublas::unbounded_array<int, std::allocator<int> > >, in_t =
boost::numeric::ublas::vector<int, boost::numeric::ublas::unbounded_array<int,
std::allocator<int> > >]':
src/cic.hpp:66: warning: `x' may be used uninitialized in this function
Comment 13 Neal Becker 2007-10-02 11:58:48 EDT
After some more trial and error, I see it requires -fPIC also:

 g++ -c -g -O3 -Wall -fPIC cic.ii 
src/cic.hpp: In member function ‘void CICDecim<inputtype>::Compute(const 
in_t&, out_t&) [with in_t = boost::numeric::ublas::vector<int, 
boost::numeric::ublas::unbounded_array<int, std::allocator<int> > >, out_t = 
boost::numeric::ublas::vector<int, boost::numeric::ublas::unbounded_array<int, 
std::allocator<int> > >, inputtype = int]’:
src/cic.hpp:66: warning: ‘x’ may be used uninitialized in this function
src/fixed.hpp: In member function ‘void CICDecim<inputtype>::Compute(const 
in_t&, out_t&) [with in_t = boost::numeric::ublas::vector<std::complex<int>, 
boost::numeric::ublas::unbounded_array<std::complex<int>, 
std::allocator<std::complex<int> > > >, out_t = 
boost::numeric::ublas::vector<std::complex<int>, 
boost::numeric::ublas::unbounded_array<std::complex<int>, 
std::allocator<std::complex<int> > > >, inputtype = std::complex<int>]’:
src/fixed.hpp:36: warning: ‘__imag__ x.std::complex<double>::_M_value’ is used 
uninitialized in this function
src/fixed.hpp:36: warning: ‘__real__ x.std::complex<double>::_M_value’ is used 
uninitialized in this function
Comment 14 Brian Powell 2008-04-25 00:41:55 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.

Note You need to log in before you can comment on or make changes to this bug.