Bug 22207 - Spurious 'might be used uninitialized' warnings in STL headers with -O2
Summary: Spurious 'might be used uninitialized' warnings in STL headers with -O2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.4.4
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2005-06-27 23:08 UTC by brian
Modified: 2008-10-03 13:00 UTC (History)
5 users (show)

See Also:
Host:
Target: i686-pc-cygwin
Build:
Known to work: 4.1.0
Known to fail: 3.4.4
Last reconfirmed: 2005-09-06 18:59:23


Attachments
Preprocessed source for testcase (49.73 KB, text/plain)
2005-06-27 23:10 UTC, brian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description brian 2005-06-27 23:08:17 UTC
The following reduced test case causes spurious -Wuninitialized warnings, but
only with -O2:

-----

#include <vector>
#include <string>

class OptionSet
{
public:
  OptionSet ();
  std::vector<std::string> const &nonOptions() const;
private:
  std::vector<std::string> nonoptions;
};

OptionSet::OptionSet()
{
  nonoptions = std::vector<std::string> ();
}

std::vector<std::string> const &
OptionSet::nonOptions() const
{
  return nonoptions;
}

-----

$ g++ -Wuninitialized -O2 -c spurious_uninitialized_testcase.cc
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h: In member
function `std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const
std::vector<_Tp, _Alloc>&) [with _Tp = std::string, _Alloc =
std::allocator<std::string>]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_vector.h:715: warning:
'__result' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function

$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug : (reconfigured) 
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

-----

The warnings only occur at -O2 and seem to have something to do with inlining. 
This causes our build that uses "-Wall -Werror" to die whereas it had no problem
with this warning in gcc-3.3.

I'm sensitive to the fact that it's impossible for the compiler to get this
warning correct every time, and the reason for the use of "might be" in the
warning text.  It's acceptible to emit warnings about things that may not
actually be the case, and normally I would just modify the build environment to
disable that warning or lose -Werror.  But in this case, the code in question is
in the STL and is completely out of the hands of the user, and I don't think
it's unreasonable to expect to be able to compile STL-based code with -Werror -Wall.
Comment 1 brian 2005-06-27 23:10:41 UTC
Created attachment 9163 [details]
Preprocessed source for testcase
Comment 2 Ian Lance Taylor 2005-09-06 18:59:22 UTC
Confirmed that this happens with 3.4 for the i686-pc-cygwin target, though not
for the i686-pc-linux-gnu target.  It is fixed in current mainline for both targets.
Comment 3 Andrew Pinski 2006-03-08 16:06:13 UTC
Fixed in 4.0.0.
Comment 4 pdemarco 2008-10-01 12:10:40 UTC
any chance of getting this fixed on 3.4.4 ???
Comment 5 Dave Korn 2008-10-01 14:19:06 UTC
Sorry mate, all 3.x compilers are way past end-of-life now; there will never be another release.

Your best bet is to hand-edit the header files in your local install.  I don't remember the exact recipe, but of the two places where this bug crops up, one can be worked around by adding "__attribute__ ((__unused__))" to the relevant variable declaration, and the other one has to be fixed by adding "__attribute__ ((__noinline__))" to the function declaration.

I haven't tested these workaround for performance impact.  Shouldn't be too bad if you're not calling the functions from the middle of a loop that runs millions of times.
Comment 6 pdemarco 2008-10-01 18:04:31 UTC
(In reply to comment #5)
> Sorry mate, all 3.x compilers are way past end-of-life now; there will never be
> another release.
okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha.  If I could upgrade to a stable 4.x for the change... I would.
Comment 7 Paolo Carlini 2008-10-01 18:17:45 UTC
(In reply to comment #6)
> okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha.

Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x release series, and previously we had 4.2.x, and previously 4.1.x...

 

Comment 8 pdemarco 2008-10-01 18:19:31 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha.
> Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x
> release series, and previously we had 4.2.x, and previously 4.1.x...

My understanding was that 4.x was not available.  I'll have to re-check.  sorry for the noise.
Comment 9 brian 2008-10-01 20:25:58 UTC
Subject: Re:  Spurious 'might be used uninitialized' 
 warnings in STL headers with -O2

You are confusing the state of the Cygwin port of gcc with gcc in
general.
Comment 10 pdemarco 2008-10-03 12:53:56 UTC
(In reply to comment #9)
> Subject: Re:  Spurious 'might be used uninitialized' 
>  warnings in STL headers with -O2
> You are confusing the state of the Cygwin port of gcc with gcc in
> general.

Possibly, but I cannot find the download for 4.x.x.
Why does it have to be so confusing ?

http://sourceforge.net/project/showfiles.php?group_id=2435

This is the location that I got ALPHA from.
It appears that the best 4.x.x download is: Testing: gcc-4.3.0-20080502-mingw32-alpha

I see no other reasonable downloads.
Comment 11 Paolo Carlini 2008-10-03 13:00:12 UTC
Brian is right:

  http://gcc.gnu.org/mirrors.html