From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1517 invoked by alias); 23 Nov 2013 12:10:18 -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 1482 invoked by uid 48); 23 Nov 2013 12:10:15 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument Date: Sat, 23 Nov 2013 12:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg02395.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56788 --- Comment #10 from Marc Glisse --- (In reply to Uro=C5=A1 Bizjak from comment #9) > Patch that fixes _mm_frcz_{ss,sd} intrinsics Looks good (assuming the detailed description is more correct than the high-level one in AMD's doc), thank you. Arguably the LLVM intrinsic is more useful than the Microsoft one, but that= 's a different issue that doesn't matter that much. >>From gcc-bugs-return-435619-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 23 12:23:30 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7724 invoked by alias); 23 Nov 2013 12:23:30 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 7690 invoked by uid 48); 23 Nov 2013 12:23:27 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument Date: Sat, 23 Nov 2013 12:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg02396.txt.bz2 Content-length: 642 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56788 --- Comment #11 from Uro=C5=A1 Bizjak --- (In reply to Marc Glisse from comment #10) > (In reply to Uro=C5=A1 Bizjak from comment #9) >=20 > Arguably the LLVM intrinsic is more useful than the Microsoft one, but > that's a different issue that doesn't matter that much. I left the prototype the way it was. Marc, since it looks you have access to XOP target (I don't have one), can = you please write an XOP testcase for frcz insns? You can look at gcc.target/i386/xop-*.c. frcz tests are mysteriously missing there, with us= ual "untested code" consequences. >>From gcc-bugs-return-435620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 23 12:52:36 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 15918 invoked by alias); 23 Nov 2013 12:52:36 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 15845 invoked by uid 48); 23 Nov 2013 12:52:32 -0000 From: "earthdok at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/59061] Port leaksanitizer Date: Sat, 23 Nov 2013 12:52: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: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: earthdok 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: 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: 2013-11/txt/msg02397.txt.bz2 Content-length: 851 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #31 from Sergey Matveev --- (In reply to Kostya Serebryany from comment #30) > lsan's allocator clears all memory using internal_memset, which is damn > slow. (sets on byte at a time) > > asan's allocator doesn't do that (it sets first 4K bytes of allocated region > with garbage using the REAL fast memset) > > I think the right solution is to finally implement *fast* internal_memset. > We'll do that. > > Sergey, can this difference between asan and lsan allocators cause > false negatives/positives in lsan? It can cause a false negative if there's a stale pointer outside of those 4k. But in practice 4k ought to be enough for anybody. I think standalone LSan should support the max_alloc_fill_size flag. I'll also change it to use real memset.