From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30674 invoked by alias); 12 Dec 2014 17:22:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30610 invoked by uid 48); 12 Dec 2014 17:22:43 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/64265] [5 Regression] r217669 broke tsan Date: Fri, 12 Dec 2014 17:22:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed 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: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-12/txt/msg01456.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #7 from Jakub Jelinek --- Note, I don't see any kind of memory leak on any of the testcases. Sure, calling __tsan_func_entry many times is of course wrong. As for #c5, clang doesn't call __tsan_func_exit in that case either. Dmitry? If we were to call it even for exceptions, I'm afraid expanding this in tsan pass is too late, we'd need to add the __tsan_func_exit call say during gimplification as a cleanup of the whole body and then EH code would take care of adding the needed landing pads etc. But libtsan e.g. wraps longjmp and pops frames in there, not sure if it doesn't do something similar for exceptions already.