From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-353774-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30149 invoked by alias); 8 Nov 2013 09:44:30 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 30138 invoked by uid 89); 8 Nov 2013 09:44:30 -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,RCVD_IN_DNSWL_NONE,RDNS_NONE,SPAM_SUBJECT,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO: mail-pd0-f172.google.com
Received: from Unknown (HELO mail-pd0-f172.google.com) (209.85.192.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 08 Nov 2013 09:44:29 +0000
Received: by mail-pd0-f172.google.com with SMTP id w10so1912853pde.3        for <gcc-patches@gcc.gnu.org>; Fri, 08 Nov 2013 01:44:21 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.133.198 with SMTP id pe6mr14101808pbb.10.1383903861046; Fri, 08 Nov 2013 01:44:21 -0800 (PST)
Received: by 10.70.129.145 with HTTP; Fri, 8 Nov 2013 01:44:20 -0800 (PST)
In-Reply-To: <Pine.LNX.4.64.1311071824560.20971@digraph.polyomino.org.uk>
References: <Pine.LNX.4.64.1311052316480.30260@digraph.polyomino.org.uk>	<20131107164555.GI27813@tucnak.zalov.cz>	<CAFULd4bpn+rO=_i+CHAgjGF4i=hpf-6E-MHCTNFG-OQ09XHFAQ@mail.gmail.com>	<Pine.LNX.4.64.1311071824560.20971@digraph.polyomino.org.uk>
Date: Fri, 08 Nov 2013 10:09:00 -0000
Message-ID: <CAFULd4ZbQ+XOQDvPuXS7j5zsKGvbow6i0rXG4zHVD-KGkV4YHw@mail.gmail.com>
Subject: Re: Implement C11 _Atomic
From: Uros Bizjak <ubizjak@gmail.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Jakub Jelinek <jakub@redhat.com>, "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>, 	Andrew MacLeod <amacleod@redhat.com>, Mike Stump <mikestump@comcast.net>, stanshebs@earthlink.net, 	Jason Merrill <jason@redhat.com>, Richard Henderson <rth@redhat.com>, "jh@suse.cz" <jh@suse.cz>
Content-Type: text/plain; charset=ISO-8859-1
X-SW-Source: 2013-11/txt/msg00873.txt.bz2

On Thu, Nov 7, 2013 at 7:26 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:

>> Please note that following code form fenv.c won't generate overflow
>> exception on x87:
>>
>>   if (excepts & FP_EX_OVERFLOW)
>>     {
>>       volatile float max = __FLT_MAX__;
>>       r = max * max;
>>     }
>
> r being volatile is intended to ensure that the result does get stored
> back to memory, and so in particular that a result computed with excess
> precision gets converted back to float and the exception is raised.

Can we introduce a target-dependant source here, in the same way as
gfortran has different config/fpu-*.c files? I would like to propose
the code from (recently improved) libgcc/config/i386/sfp-exceptions.c
to generate exceptions on x86 targets. The main benefits of this code
are:
- precision: it generates exactly the exception it is supposed to
generate at the exact spot (x87 and SSE)
- the code doesn't do arithemtics with denormal results
- can also generate non-standard denormal exception

Your proposed code can be considered a generic fallback code then. I'm
sure other targets have their own, perhaps better ways to generate FP
exceptions.

Uros.