Bug 34470 - [4.3 regression] spurious "is used uninitialized" from auto_ptr
Summary: [4.3 regression] spurious "is used uninitialized" from auto_ptr
Status: RESOLVED DUPLICATE of bug 34196
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.3.0
: P2 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, wrong-code
Depends on: 34196
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-14 21:18 UTC by Zack Weinberg
Modified: 2008-01-16 22:29 UTC (History)
10 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2008-01-02 12:53:18


Attachments
-fdump-tree-optimized output (700 bytes, text/plain)
2007-12-14 21:26 UTC, Zack Weinberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zack Weinberg 2007-12-14 21:18:08 UTC
This test case provokes spurious "is used uninitialized" warnings from trunk GCC.

  #include <string>
  #include <memory>
  class HashFunction {};
  HashFunction *get_hash (std::string const &);
  void generate_dsa_primes (void)
  { std::auto_ptr <HashFunction> hash(get_hash("SHA-160")); }

->

backward/auto_ptr.h: In function 'void generate_dsa_primes()':
backward/auto_ptr.h:177: warning: 'hash.std::auto_ptr<HashFunction>::_M_ptr'
  is used uninitialized in this function
dsa_gen.cc:6: note: 'hash.std::auto_ptr<HashFunction>::_M_ptr' 
  was declared here

This does not happen with 4.2.3.  Note that the warnings go away if you change get_hash to take a const char * instead of a std::string const &, which seems like it shouldn't matter.
Comment 1 Zack Weinberg 2007-12-14 21:26:17 UTC
Created attachment 14756 [details]
-fdump-tree-optimized output

I looked at the -fdump-tree-optimized output (attached) and it makes somewhat more sense that the presence of std::string would matter -- the code generated to convert the string constant to a std::string object introduces seriously nontrivial control flow.  However, that's not an excuse.
Comment 2 Zack Weinberg 2007-12-14 21:33:02 UTC
Ooh, it gets worse.  The spurious diagnostic is a symptom of an incorrect optimization.  In normal control flow, the result of get_hash is assigned to a synthetic variable, D.13336, and that variable is used to call operator delete in basic block 14.  However, an exception might transfer control to label L1 (not a basic block?!) which calls operator delete on hash$_M_ptr, which has never been initialized.
Comment 3 Richard Biener 2007-12-14 22:23:36 UTC
I think this is a dup of PR34196.  You might want to add something about the wrong-code bits there.
Comment 4 Zack Weinberg 2007-12-14 22:31:20 UTC
How do you know whether an EH region is dead?  That information does not seem to be in the dumps.
Comment 5 Andrew Pinski 2007-12-14 22:36:02 UTC
(In reply to comment #4)
> How do you know whether an EH region is dead?  That information does not seem
> to be in the dumps.

the summary of that other bug is incorrect.  I already added information about the wrong code in the other bug.  See my comment #1.
Comment 6 Zack Weinberg 2007-12-14 22:45:12 UTC
"How do you know whether an EH region is dead" is still a live question for this bug.  Not turning hash$_M_ptr into D.13336 is only a wrong-code bug if the block can be executed.
Comment 7 Mark Mitchell 2007-12-31 06:51:45 UTC
Leaving as P3 until we know whether this is actually wrong code or not.
Comment 8 Richard Biener 2008-01-02 12:53:18 UTC
At least confirmed.  Jason, would you have a look here?
Comment 9 Mark Mitchell 2008-01-02 22:59:35 UTC
P2, until we know if this is actually wrong code.
Comment 10 Richard Biener 2008-01-16 22:29:04 UTC
dup.  don't count this twice.

*** This bug has been marked as a duplicate of 34196 ***
Comment 11 Zack Weinberg 2008-01-17 00:13:56 UTC
Subject: Re:  [4.3 regression] spurious "is used uninitialized" from auto_ptr

I'm not convinced it is a duplicate; no one has determined whether or
not the EH region in my case is actually dead.