public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10 Date: Mon, 03 Feb 2014 10:00:00 -0000 [thread overview] Message-ID: <bug-60038-4-YVcFXJtGul@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60038-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038 --- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Uroš Bizjak from comment #11) > (In reply to Jakub Jelinek from comment #9) > > Created attachment 32021 [details] > > gcc49-pr60038.patch > > > > This seems to work for me on glibc 2.17, Uros, can you please try it on your > > CentOS 5? > > Uh, that was quick, I didn't noticed your submission. ;) > > I'll test your patch in a moment. sanitizer re-build and regression test with RUNTESTFLAGS="--target_board=unix\{,-m32\} asan.exp" worked without problems on CentOS 5.10. >From gcc-bugs-return-442377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 10:24:31 2014 Return-Path: <gcc-bugs-return-442377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 30587 invoked by alias); 3 Feb 2014 10:24:31 -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 30506 invoked by uid 48); 3 Feb 2014 10:24:26 -0000 From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58742] pointer arithmetic simplification Date: Mon, 03 Feb 2014 10:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-58742-4-eqd6sfm5Ly@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-58742-4@http.gcc.gnu.org/bugzilla/> References: <bug-58742-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-02/txt/msg00134.txt.bz2 Content-length: 2655 http://gcc.gnu.org/bugzilla/show_bug.cgi?idX742 --- Comment #26 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Richard Biener from comment #25) > VERSION=0 and VERSION=1 are the same speed for me now, They aren't quite for me (2.5 vs 2.7) but > VERSION=2 is a lot slower still. that's the part I am concerned with here. > Yeah, the issue is that while FRE does some expression simplification it > doesn't wire into a common gimple pattern matcher (something I'd like to > fix for 4.10). That is, the simplification forwprop performs should be > done by FRE already. See tree-ssa-sccvn.c:simplify_binary_expression. Ah, ok, that makes sense. I assume it would also have basic CCP-like functionality (forwprop can create constants but doesn't always fold the resulting constant operations). Looking forward to that! > > VRP2 is too late if we hope to vectorize, and in > > any case it fails to remove the range checks, because it is confused by the > > new shape of the loops (possibly related to PR 25643, or not). The VRP2 > > failure looks funny with these consecutive lines: > > > > # ivtmp.80_92 = PHI <ivtmp.80_53(9), ivtmp.80_83(8)> > > # RANGE [10101, 989898] NONZERO 0x000000000000fffff > > _23 = ivtmp.80_92; > > if (ivtmp.80_92 > 999999) > > > > Really, we don't know that the comparison returns false? > > Well, _23 is simply dead at this point and VRP computed _92 to be > varying. Yes. I just meant that, as a hack, for 2 SSA_NAME defined in the same BB where one is a copy of the other, we could merge their range info (in both directions) and it might in this special case work around the fact that VRP2 is confused by the loop. But that would be too fragile and hackish. > From the no-undefined-overflow branch I'd take the idea of adding op > variants with known no overflow. That is, add MULTNV_EXPR, PLUSNV_EXPR, > MINUSNV_EXPR that can be used on unsigned types, too (you'd of course > have to define what overflow means there - if a - b does not overflow > then a + (-b) will - negate of x will always overflow if x is not zero). Ah, yes, I'd forgotten about those. I always wondered if it is better to have many different tree codes or a single one with "options". Like MULT_EXPR with a parameter saying what happens on overflow: undefined, saturate, wrap, other (seems hard to handle "jump to this location" in the same). Or COMPARISON_EXPR with several bools telling what the return value is if a<b, a==b, a>b, one is NaN, and if it can raise exceptions (we don't have the corresponding 32 tree codes). Or the 5 DIV_EXPR variants (counting only integers). I guess it doesn't really matter.
next prev parent reply other threads:[~2014-02-03 10:00 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-03 7:53 [Bug sanitizer/60038] New: " ubizjak at gmail dot com 2014-02-03 8:19 ` [Bug sanitizer/60038] " kcc at gcc dot gnu.org 2014-02-03 8:26 ` ubizjak at gmail dot com 2014-02-03 8:33 ` kcc at gcc dot gnu.org 2014-02-03 8:47 ` jakub at gcc dot gnu.org 2014-02-03 8:53 ` jakub at gcc dot gnu.org 2014-02-03 8:56 ` kcc at gcc dot gnu.org 2014-02-03 9:26 ` jakub at gcc dot gnu.org 2014-02-03 9:27 ` ubizjak at gmail dot com 2014-02-03 9:33 ` ubizjak at gmail dot com 2014-02-03 10:00 ` ubizjak at gmail dot com [this message] 2014-02-03 21:22 ` ubizjak at gmail dot com 2014-02-04 4:18 ` kcc at gcc dot gnu.org 2014-02-04 7:38 ` jakub at gcc dot gnu.org 2014-02-04 7:42 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-60038-4-YVcFXJtGul@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).