public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally Date: Fri, 07 Feb 2014 23:56:00 -0000 [thread overview] Message-ID: <bug-6981-131-fgZit21MZX@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-6981-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=6981 --- Comment #9 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> --- (In reply to joseph@codesourcery.com from comment #8) > There would be no reason for F.6 and F.10.11 (in C11) if the intent wasn't > to support evaluation in wider types. The fact that both F.6 and F.10.11 are new in C11 shows that this is pointless in C99. And I disagree about F.6: you can have double foo (void) { return LDBL_EPSILON; } int main (void) { double x = 17.0L * foo (); } I don't think that C99 mandates that LDBL_EPSILON be converted to double if the eval method is implementation-defined (the arithmetic operations would be correctly rounded as required by IEEE 754, possibly with an extended exponent range, but the implementation could decide for C specific operations such as function calls). F.6 in C11 makes the behavior explicit. Concerning F.10.11, there's a contradiction with some codes given earlier in Annex F, which assume FLT_EVAL_METHOD to be 0 or a value with implementation-defined behavior. Now, it is not even clear that the following would be forbidden: FLT_EVAL_METHOD is 1 or 2, but rounding for the arithmetic operations is done in the semantic type. For instance, I suspect that FLT_EVAL_METHOD should be 2 with the x87 FPU, even when configured to round to double precision, because the intermediate values still have the extended exponent range (unless the compiler chooses to store the intermediate values to memory). In the C standard, FLT_EVAL_METHOD = 2 doesn't imply that the full extended precision is used, just that the intermediate values are representable in long double. > DTS 18661-1 clarifies things further [...] Well, it's more than clarification, it is based on IEEE 754-2008, whose requirements are different from the old IEEE 754-1985 standard: the old requirement I mentioned became obsoleted (replaced) by the use of formatOf operations. But C99 and C11's Annex F is based on the old IEEE 754-1985 standard. -- You are receiving this mail because: You are on the CC list for the bug. >From glibc-bugs-return-21356-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Feb 08 00:11:03 2014 Return-Path: <glibc-bugs-return-21356-listarch-glibc-bugs=sources.redhat.com@sourceware.org> Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 15604 invoked by alias); 8 Feb 2014 00:11:03 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <glibc-bugs.sourceware.org> List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org> List-Post: <mailto:glibc-bugs@sourceware.org> List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs> Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 15580 invoked by uid 55); 8 Feb 2014 00:10:59 -0000 From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally Date: Sat, 08 Feb 2014 00:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-6981-131-cvhmhwGwTD@http.sourceware.org/bugzilla/> In-Reply-To: <bug-6981-131@http.sourceware.org/bugzilla/> References: <bug-6981-131@http.sourceware.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00333.txt.bz2 Content-length: 1816 http://sourceware.org/bugzilla/show_bug.cgi?idi81 --- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 7 Feb 2014, vincent-srcware at vinc17 dot net wrote: > Concerning F.10.11, there's a contradiction with some codes given earlier in > Annex F, which assume FLT_EVAL_METHOD to be 0 or a value with > implementation-defined behavior. I don't see what problems you see with any example code in Annex F (but in any case, if there are contradictions - which you should raise as C11 DRs if so - it's natural to try to resolve them in accordance with the clear intent that FLT_EVAL_METHOD being 2 is consistent with Annex F. > Now, it is not even clear that the following would be forbidden: > FLT_EVAL_METHOD is 1 or 2, but rounding for the arithmetic operations is done > in the semantic type. For instance, I suspect that FLT_EVAL_METHOD should be 2 > with the x87 FPU, even when configured to round to double precision, because > the intermediate values still have the extended exponent range (unless the > compiler chooses to store the intermediate values to memory). In the C > standard, FLT_EVAL_METHOD = 2 doesn't imply that the full extended precision is > used, just that the intermediate values are representable in long double. "evaluate all operations and constants to the range and precision of the long double type" seems clear enough to me. If the x87 FPU is rounding to double precision, that's a different ABI, as used on 32-bit FreeBSD, where long double has the extended-precision in-memory encoding but only 53 mantissa bits are used; that ABI isn't supported by glibc (calling libm functions with the FPU rounding to double precision means undefined behavior). -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2014-02-07 23:56 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-6981-131@http.sourceware.org/bugzilla/> 2012-12-19 10:51 ` schwab@linux-m68k.org 2014-02-07 2:37 ` cvs-commit at gcc dot gnu.org 2014-02-07 2:41 ` jsm28 at gcc dot gnu.org 2014-02-07 23:56 ` vincent-srcware at vinc17 dot net [this message] 2014-02-08 1:22 ` vincent-srcware at vinc17 dot net 2014-02-08 2:00 ` vincent-srcware at vinc17 dot net 2014-02-09 18:25 ` vincent-srcware at vinc17 dot net 2014-02-10 15:08 ` joseph at codesourcery dot com 2014-02-16 19:42 ` jackie.rosen at hushmail dot com 2014-05-28 19:45 ` schwab at sourceware dot org 2014-06-13 11:16 ` fweimer at redhat dot com 2008-10-24 13:59 [Bug libc/6981] New: " vincent+libc at vinc17 dot org 2008-12-16 15:25 ` [Bug libc/6981] " vincent+libc at vinc17 dot org
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-6981-131-fgZit21MZX@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.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: linkBe 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).