[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=6981

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  fd2f9486a11390046f6c6682323297239cf46cb0 (commit)
      from  3bfff2edbef578746211ba231f3942efffd38f86 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fd2f9486a11390046f6c6682323297239cf46cb0

commit fd2f9486a11390046f6c6682323297239cf46cb0
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Fri Feb 7 02:36:28 2014 +0000

    Bug 6981 was fixed by commit 1484e65736f4cab27e5051e0f06be8470e69af82.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog |    1 +
 NEWS      |   36 ++++++++++++++++++------------------
 2 files changed, 19 insertions(+), 18 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
__STDC_IEC_559__ is now conditional, reflecting the intent (not necessarily
completeness) regarding Annex F support, in glibc 2.19 given GCC 4.9 or later
(these sorts of corner cases are only expected to work for current GCC and
glibc working together).

Annex F permits FLT_EVAL_METHOD other than 0.  The relevant GCC macros are
defined conditional on such options as -ffast-math that indicate a user intent
contrary to Annex F.  GCC 4.9 disables contraction in strict conformance modes
(and if reenabled in those modes, __STDC_IEC_559__ will then not be defined).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[vincent-srcware at vinc17 dot net]

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.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[vincent-srcware at vinc17 dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #11 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #10)
> I don't see what problems you see with any example code in Annex F

After looking at them more closely, they seem to be OK (in particular, for the
round() one, I forgot that the rounding mode was set toward zero, so that
double rounding effect couldn't occur).

But if rounding is always done to extended precision, there's still a
contradiction with the IEEE 754-1985 standard, which says: "Normally, a result
is rounded to the precision of its destination. However, some systems deliver
results only to double or extended destinations. On such a system the user,
which may be a high-level language compiler, shall be able to specify that a
result be rounded instead to single precision, though it may be stored in the
double or extended format with its wider exponent range. [FOOTNOTE 4: Control
of rounding precision is intended to allow systems whose destinations are
always double or extended to mimic, in the absence of over/underflow, the
precisions of systems with single and double destinations. An implementation
should not provide operations that combine double or extended operands to
produce a single result, nor operations that combine double extended operands
to produce a double result, with only one rounding.] Similarly, a system that
delivers results only to double extended destinations shall permit the user to
specify rounding to single or double precision. Note that to meet the
specifications in 4.1, the result cannot suffer more than one rounding error."

Basically, this means that on such a system, a language should either always
round to the precision of the semantic type or specify a function to allow the
user to select the rounding precision (rounding accuracy); but C doesn't
specify such a function.

> > 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.

This is about the precision (of the format), not the accuracy. For instance,
with the x87 FPU control word, even though the precision of the destination is
always 64 bits, the rounding accuracy[*] can be set to 24, 53 or 64 bits, as
required by IEEE 754.

[*] That's a more proper term than precision in this context.

> 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).

But the IEEE 754 standard requires it to be supported (see citation above).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21362-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Feb 08 01:39:10 2014
Return-Path: <glibc-bugs-return-21362-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 23922 invoked by alias); 8 Feb 2014 01:39:10 -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 23891 invoked by uid 55); 8 Feb 2014 01:39:06 -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 01:39: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-jCknwkE97T@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/msg00339.txt.bz2
Content-length: 844

http://sourceware.org/bugzilla/show_bug.cgi?idi81

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 8 Feb 2014, vincent-srcware at vinc17 dot net wrote:

> But the IEEE 754 standard requires it to be supported (see citation above).

If so, then C99 and C11 do not provide complete bindings to IEEE 754-1985
for all implementation choices conforming to Annex F.  This is a
limitation in C99 and C11, not a bug in the implementations.  That
limitation is being addressed through the new TS (which might or might not
get integrated in a future C standard version - I think it might make
sense to integrate only those pieces that get significant implementation
experience) rather than through any changes to C11.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[vincent-srcware at vinc17 dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #13 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to joseph@codesourcery.com from comment #12)
> On Sat, 8 Feb 2014, vincent-srcware at vinc17 dot net wrote:
> 
> > But the IEEE 754 standard requires it to be supported (see citation above).
> 
> If so, then C99 and C11 do not provide complete bindings to IEEE 754-1985 
> for all implementation choices conforming to Annex F.

The bindings are complete when FLT_EVAL_METHOD is 0, because in such a case an
operation on float numbers is rounded to the float precision, and an operation
on double numbers is rounded to the double precision. That's why I suggested to
define __STDC_IEC_559__ only when FLT_EVAL_METHOD is 0, until the new TS is
implemented.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21370-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Feb 08 02:45:24 2014
Return-Path: <glibc-bugs-return-21370-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 8739 invoked by alias); 8 Feb 2014 02:45:23 -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 8687 invoked by uid 55); 8 Feb 2014 02:45:19 -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 02:45: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-dWxOCjDP2G@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/msg00347.txt.bz2
Content-length: 1186

http://sourceware.org/bugzilla/show_bug.cgi?idi81

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 8 Feb 2014, vincent-srcware at vinc17 dot net wrote:

> The bindings are complete when FLT_EVAL_METHOD is 0, because in such a case an
> operation on float numbers is rounded to the float precision, and an operation
> on double numbers is rounded to the double precision. That's why I suggested to
> define __STDC_IEC_559__ only when FLT_EVAL_METHOD is 0, until the new TS is
> implemented.

(a) __STDC_IEC_559__ is purely about support for Annex F, not about
whether Annex F provides complete support for another standard in the case
of the implementation choices made.

(b) As with __STDC__, __STDC_IEC_559__ is being defined in terms of intent
(that the compiler options used indicate an intent consistent with Annex
F, rather than specifying something incompatible like -ffinite-math-only)
rather than completeness.

(c) Implementation of the new standard would trigger defining
__STDC_IEC_60559_BFP__, rather than any change to __STDC_IEC_559__.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[vincent-srcware at vinc17 dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4096 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #15 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
F.7 of C99 says: "The floating-point environment defined in <fenv.h> includes
the IEC 60559 floating-point exception status flags and directed-rounding
control modes. It includes also IEC 60559 dynamic rounding precision and trap
enablement modes, if the implementation supports them.312)
312) This specification does not require dynamic rounding precision nor trap
enablement modes."

I suspect that F.7 has been added with x87 hardware in mind, and more generally
 hardware with dynamic rounding precision (where FLT_EVAL_METHOD is typically 1
or 2), and various modes are expected to be supported by the C implementation.
If the implementation (as an extension) or an external library provides a way
to set this dynamic rounding precision, then §4.3 of IEEE 754 can be fulfilled
without the alternate functions from the new TS. So, from this point of view,
having FLT_EVAL_METHOD set to 1 or 2 can be OK, as long as the implementation
supports the various rounding precisions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21377-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Feb 10 04:36:13 2014
Return-Path: <glibc-bugs-return-21377-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 25397 invoked by alias); 10 Feb 2014 04:36:13 -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 25352 invoked by uid 48); 10 Feb 2014 04:36:09 -0000
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/9712] Expose futex system call
Date: Mon, 10 Feb 2014 04:36: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: 2.8
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-9712-131-8RYpZIc7Ar@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-9712-131@http.sourceware.org/bugzilla/>
References: <bug-9712-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/msg00354.txt.bz2
Content-length: 951

https://sourceware.org/bugzilla/show_bug.cgi?id—12

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|WONTFIX                     |---

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
Can we please revisit the question of exposing a public futex function and
assocated macros? Using syscall.h from applications is a horrible hack. Now
that C11 has atomics, the demand for working directly with atomics is likely to
increase, but for lots of applications of atomics you also need futex().

If this is acceptable, my preferred header for the interface would be
sys/futex.h.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=6981

--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I read F.7 as guidance about the interpretation of "environment" - 
indicating what functions such as fesetenv should affect when processors 
have floating-point state beyond that specified in C99 - not about how 
arithmetic operations should bind to IEC 60559.  (I do consider it a bug - 
bug 16064, bug 16068 - that there are bits of floating-point state not 
handled by fesetenv etc., but also consider it undefined behavior to call 
any glibc function doing arithmetic if the floating-point state, such as 
non-extended rounding precision, could not be a result of proper use of 
library functions provided by glibc.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #17 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6981

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/6981] New: __STDC_IEC_559__ should not be defined unconditionally

[vincent+libc at vinc17 dot org]

__STDC_IEC_559__ is unconditionally defined as 1 in "/usr/include/features.h".
On some platforms, this is incorrect. In particular, if FLT_EVAL_METHOD is 1 or
2, it doesn't make sense to define __STDC_IEC_559__ as this contradicts the
bindings defined in Annex F of the ISO C standard.

I suggest to define __STDC_IEC_559__ only if FLT_EVAL_METHOD is 0 (probably test
__FLT_EVAL_METHOD__).

Even this test would not be sufficient with GCC, as it systematically contracts
expressions (in particular on PowerPC and IA-64, which have a FMA), which is
against the support of Annex F.

-- 
           Summary: __STDC_IEC_559__ should not be defined unconditionally
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: vincent+libc at vinc17 dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6981

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally

[vincent+libc at vinc17 dot org]

------- Additional Comments From vincent+libc at vinc17 dot org  2008-12-16 15:24 -------
See also: http://sources.redhat.com/ml/libc-alpha/2005-03/msg00196.html

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6981

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.