public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-56788-4-2MKAae3sKC@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-56788-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Uroš 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: <gcc-bugs-return-435619-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 7690 invoked by uid 48); 23 Nov 2013 12:23:27 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.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: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: <bug-56788-4-wFvlP3kfLq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56788-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56788-4@http.gcc.gnu.org/bugzilla/>
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=56788

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Marc Glisse from comment #10)
> (In reply to Uroš Bizjak from comment #9)
> 
> 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 usual
"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: <gcc-bugs-return-435620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 15845 invoked by uid 48); 23 Nov 2013 12:52:32 -0000
From: "earthdok at google dot com" <gcc-bugzilla@gcc.gnu.org>
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: <bug-59061-4-2yWiBZ8sCp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59061-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59061-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: 2013-11/txt/msg02397.txt.bz2
Content-length: 851

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY061

--- Comment #31 from Sergey Matveev <earthdok at google dot com> ---
(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.


  parent reply	other threads:[~2013-11-23 12:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-30 20:20 [Bug target/56788] New: " glisse at gcc dot gnu.org
2013-03-30 20:42 ` [Bug target/56788] " glisse at gcc dot gnu.org
2013-06-27 13:05 ` glisse at gcc dot gnu.org
2013-11-23  9:09 ` ubizjak at gmail dot com
2013-11-23  9:19 ` ubizjak at gmail dot com
2013-11-23  9:22 ` ubizjak at gmail dot com
2013-11-23  9:34 ` glisse at gcc dot gnu.org
2013-11-23  9:45 ` ubizjak at gmail dot com
2013-11-23 11:39 ` ubizjak at gmail dot com
2013-11-23 12:10 ` glisse at gcc dot gnu.org [this message]
2013-11-23 13:00 ` glisse at gcc dot gnu.org
2013-11-27 18:07 ` uros at gcc dot gnu.org
2013-11-28 16:48 ` uros at gcc dot gnu.org
2013-11-28 18:14 ` uros at gcc dot gnu.org
2013-11-28 18:15 ` ubizjak at gmail dot com

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-56788-4-2MKAae3sKC@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: link
Be 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).