From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-53475-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 32095 invoked by alias); 9 Oct 2014 01:55:50 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 29808 invoked by uid 89); 9 Oct 2014 01:54:05 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mx1.redhat.com
Message-ID: <5435EAB8.5080401@redhat.com>
Date: Thu, 09 Oct 2014 01:55:00 -0000
From: "Carlos O'Donell" <carlos@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: "Joseph S. Myers" <joseph@codesourcery.com>
CC: libc-alpha@sourceware.org
Subject: Re: soft-fp: Add FP_DENORM_ZERO
References: <Pine.LNX.4.64.1409191817180.11496@digraph.polyomino.org.uk> <5435D91B.90603@redhat.com> <Pine.LNX.4.64.1410090054000.4884@digraph.polyomino.org.uk>
In-Reply-To: <Pine.LNX.4.64.1410090054000.4884@digraph.polyomino.org.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SW-Source: 2014-10/txt/msg00273.txt.bz2

On 10/08/2014 08:57 PM, Joseph S. Myers wrote:
> On Wed, 8 Oct 2014, Carlos O'Donell wrote:
> 
>>> diff --git a/soft-fp/soft-fp.h b/soft-fp/soft-fp.h
>>> index 86bc7fa..05fcca0 100644
>>> --- a/soft-fp/soft-fp.h
>>> +++ b/soft-fp/soft-fp.h
>>> @@ -161,6 +161,11 @@
>>>  # define FP_HANDLE_EXCEPTIONS do {} while (0)
>>>  #endif
>>>  
>>> +/* Whether to flush subnormal inputs to zero with the same sign.  */
>>> +#ifndef FP_DENORM_ZERO
>>> +# define FP_DENORM_ZERO 0
>>> +#endif
>>
>> OK, but...
>>
>> For the record this is an instance of the "centralized defaults" pattern
>> which we try to avoid in glibc. What if the target accidentally defines:
> 
> I am unconvinced this can readily be avoided in the soft-fp code without a 
> lot of duplication of common definitions in different sfp-machine.h files 
> (of which there are a lot, when you consider those in libgcc and the Linux 
> kernel as well as glibc).

I am not sufficiently familiar with the code to make that judgement, I was
only noting that we're trying to avoid that kind of pattern in glibc in
general. However, "in general" may not apply to this specific case for
soft-fp.

Cheers,
Carlos.