https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-12
             Blocks|                            |24639
            Summary|Bogus maybe-uninitialized   |Bogus maybe-uninitialized
                   |warning due to              |(|| converted to nested-if)
                   |optimizations               |
     Ever confirmed|0                           |1

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andy Lutomirski from comment #1)
> This might be a duplicate of PR56574

I think not. In this case the problem is that

# value = PHI<value(D),intval()>
if (!valid || intval() < value)

is converted to

# value = PHI<value(D),intval() > 
if(!valid)
else if (intval() < value)

and I think the uninit pass is not smart enough to realize that the use is
guarded by valid != 0 but the default definition implies valid == 0.

Perhaps it is also a missed-optimization, since "if(cond())" could jump
directly to "if (intval() < value)".
>From gcc-bugs-return-461728-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 12 22:27:29 2014
Return-Path: <gcc-bugs-return-461728-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1171 invoked by alias); 12 Sep 2014 22:27:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1104 invoked by uid 48); 12 Sep 2014 22:27:21 -0000
From: "dvyukov at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/63251] New: tsan: corrupted shadow stack
Date: Fri, 12 Sep 2014 22:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dvyukov at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc attachments.created
Message-ID: <bug-63251-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg01562.txt.bz2
Content-length: 3053

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc251

            Bug ID: 63251
           Summary: tsan: corrupted shadow stack
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dvyukov at google dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 33486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3486&actioníit
reproducer

Reported in the ThreadSanitizer bug tracker, but it looks like gcc
instrumentation issue:
https://code.google.com/p/thread-sanitizer/issues/detail?idv

gcc version 5.0.0 20140830 (experimental) (GCC)

$ g++ -fsanitize=thread /tmp/stack.cc -pie -fPIE -g
$ ./a.out
=================WARNING: ThreadSanitizer: data race (pid'898)
...
  Thread T2 (tid'901, running) created by main thread at:
    #0 pthread_create ../../.././libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x000000026eb4)
    #1 main /tmp/stack.cc:28 (a.out+0x000000001017)
    #2 void std::__introsort_loop<__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, long,
__gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, long,
__gnu_cxx::__ops::_Iter_less_iter)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1952
(a.out+0x000000001d60)
    #3 void std::__sort<__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >,
__gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >, __gnu_cxx::__ops::_Iter_less_iter)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1967
(a.out+0x00000000182c)
    #4 void std::sort<__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > > >(__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:4676
(a.out+0x00000000130a)
    #5 main /tmp/stack.cc:24 (a.out+0x000000000fd9)


Frames #1-4 are bogus and must not be present in the thread creation stack.

Clang produces a correct stack, which is:
  Thread T2 (tid121, running) created by main thread at:
    #0 pthread_create
/ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:847
(a.out+0x000000048403)
    #1 main /tmp/stack.cc:28:3 (a.out+0x000000095bcf)


Looking at the symptoms I think that the sort-related functions do not call
__tsan_func_exit and so they are left on the shadow stack.

It's not only about report quality. If it happens enough times, then it will
overflow and blow up tsan shadow stack.