From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22637 invoked by alias); 7 Nov 2013 21:26:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22620 invoked by uid 89); 7 Nov 2013 21:26:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPAM_SUBJECT,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f176.google.com Received: from Unknown (HELO mail-ob0-f176.google.com) (209.85.214.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 07 Nov 2013 21:26:30 +0000 Received: by mail-ob0-f176.google.com with SMTP id uy5so684976obc.35 for ; Thu, 07 Nov 2013 13:26:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.149.169 with SMTP id ub9mr1637343oeb.39.1383859582305; Thu, 07 Nov 2013 13:26:22 -0800 (PST) Received: by 10.182.137.136 with HTTP; Thu, 7 Nov 2013 13:26:22 -0800 (PST) In-Reply-To: References: <20131107164555.GI27813@tucnak.zalov.cz> Date: Thu, 07 Nov 2013 22:25:00 -0000 Message-ID: Subject: Re: Implement C11 _Atomic From: Uros Bizjak To: "Joseph S. Myers" Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-11/txt/msg00842.txt.bz2 On Thu, Nov 7, 2013 at 9:55 PM, Uros Bizjak wrote: >>> > I see code of the form (testing compilation rather than execution): >>> > >>> > flds 4(%esp) >>> > flds 8(%esp) >>> > fmulp %st, %st(1) >>> > fstps 12(%esp) >>> > >>> > where the fstps should result in the exception, and glibc uses volatile in >>> > several places, conditional on __FLT_EVAL_METHOD__ != 0, to force a >>> > conversion to the semantic type (whether for correct results, or to ensure >>> > exceptions). >>> >>> Yes, this is the exact sequence my example compiles to: >>> >>> 8048405: d9 44 24 14 flds 0x14(%esp) >>> 8048409: d9 44 24 18 flds 0x18(%esp) >>> 804840d: de c9 fmulp %st,%st(1) >>> 804840f: d9 5c 24 1c fstps 0x1c(%esp) >>> >>> unfortunately, it won't generate exception. >> >> Are you sure? It's documented as generating an exception. That may mean, >> as usual on x87, setting the exception bit (as can be tested by >> fetestexcept) and only calling a trap handler on the *next* x87 >> instruction. So if fstps is the last floating-point instruction executed >> by the program, a trap handler may not be called - but that's no different >> from an ordinary floating-point compound assignment having the >> exception-raising operation as the last floating-point instruction. > > Aha, here is the problem. > > The exception is not generated by fmulp, but by the fstps that follows > fmulp. The fstps will close exception window from fmulp, but fstps > needs another fwait to generate exception. I have added fwait after > fstps manually: > > 0x080483fd <+29>: fstps 0x18(%esp) > 0x08048401 <+33>: flds 0x18(%esp) > 0x08048405 <+37>: flds 0x18(%esp) > 0x08048409 <+41>: fmulp %st,%st(1) > 0x0804840b <+43>: fstps 0x1c(%esp) > => 0x0804840f <+47>: fwait > 0x08048410 <+48>: leave > > And in this case, exception was generated, as marked by "=>" in gdb. However, this insn also raised FE_INEXACT flag (also on x86_64), probably not what you wanted. Your code that generates FE_UNDERFLOW will also raise FE_INEXACT. (and FE_DENORMAL). Uros.