[Cfp-interest 2365] Re: Updated (V4) N2823

Wed Feb 2 16:11:15 PST 2022

I probably should have added the latest draft that does NOT do the 3 part
approach Jim suggested (this one was based on the original feedback from
this group).

(See attached file: N2823UpdateV8.html)

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM

From:	"Rajan Bhakta" <rbhakta at us.ibm.com>
To:	"Jim Thomas" <jaswthomas at sbcglobal.net>
Cc:	"CFP" <cfp-interest at ucbtest.org>
Date:	02/02/2022 06:10 PM
Subject:	[EXTERNAL] [Cfp-interest 2364] Re: Updated (V4) N2823
Sent by:	"Cfp-interest" <cfp-interest-bounces at oakapple.net>

From my understanding, the problem is that freestanding implementations may
want to support 60559 (either or both BFP and DFP). As such, the concern
was that supporting that also brings in state issues that are not normally
appropriate for ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

From my understanding, the problem is that freestanding implementations may
want to support 60559 (either or both BFP and DFP). As such, the concern
was that supporting that also brings in state issues that are not normally
appropriate for freestanding implementations.
From discussion with the reflector message author, it does seem that the
issue really is the global storage and state that is brought into the
freestanding world which previously was not there for good reason.

The concerns in the reflector message did explicitly mention errno and
Joseph's follow on also discussed it. I do believe though the inclusive
path we have discussed (no way to access errno without errno.h) does
address that concern.

The FENV_ACCESS approach could work and fits in with practice in that
anecdotal evidence suggests no one really implements this fully anyways.

I am good with rewriting this paper based on the 3 part approach. Anyone
else have any preferences either way?

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM

Inactive hide details for "Jim Thomas" ---01/22/2022 12:54:47 AM---First,
what’s really the problem? Do the freestanding imple"Jim Thomas"
---01/22/2022 12:54:47 AM---First, what’s really the problem? Do the
freestanding implementations in question want to define __S

From: "Jim Thomas" <jaswthomas at sbcglobal.net>
To: "Rajan Bhakta" <rbhakta at us.ibm.com>
Cc: "CFP" <cfp-interest at ucbtest.org>
Date: 01/22/2022 12:54 AM
Subject: [EXTERNAL] Re: [Cfp-interest 2346] Updated (V4) N2823

First, what’s really the problem? Do the freestanding implementations in
question want to define __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__?
That is, do they want to declare support for Annex F? If not, there’s not a
problem. If they do, ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
First, what’s really the problem?

Do the freestanding implementations in question want to define
__STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__? That is, do they want to
declare support for Annex F? If not, there’s not a problem. If they do, …

Do freestanding implementations that want to declare support for Annex F
want to provide all the features of Annex F except for the parts that
require “global” storage? For example, do they want to provide all the math
functions? If not, just addressing the “global” storage part isn’t a
solution for them still wouldn’t allow them to declare support for Annex F.

So, we can focus on freestanding implementations that want to declare
support for Annex F but be exempt just from supporting the parts that
require global or thread storage. The potentially relevant such parts refer
to the floating-point environment (flags and modes) and the variable errno
(which have thread storage) and the floating-point numeric conversion
functions in stdlib.h (which use locales whose maintenance requires
“global” storage).

Freestanding implementations are not required to accept strictly conforming
programs that use features of <errno.h> or <locale.h>. I understand this to
imply such programs cannot access the variable errno or the locale, and
hence freestanding implementations need not maintain “global” storage for
errno or locales (even if they provide functions whose specification
references errno or locales).

This leaves the floating-point environment. Maintaining storage for the
environment is necessary only if the program can read (or test) flags or
change modes. A simple. direct way of addressing this would be to not
require freestanding implementations to accept strictly conforming programs
that set the state of the FENV_ACCESS pragma to ON (7.6.1). This could be
part 1 of a 3-part proposal (described further below).

As noted in previous email, we should also allow freestanding
implementations to define math_errhandling to be 0 (7.12). This will allow
the feature tests for errno and floating-point exceptions to work for
freestanding implementations. Alternative 3 in V6 addresses this, but the 0
option should be allowed only for freestanding implementations -- and it’s
not really an alternative because it’s only for part of the problem with
fenv.h. It could be part 2 of the aforementioned 3-part proposal.

A separate issue is whether the floating-point numeric conversion functions
should have the same option as math functions to report errors via errno or
floating-point exceptions. Alternative 2 in V6 specifies the changes, but
calling it an “alternative” seems confusing. It could be part 3 of the
3-part proposal.

Part 1 of the 3-part proposal addresses the main issue. Part 2 is a
programming aid for freestanding implementations. Part 3 is for consistent
error reporting.

- Jim Thomas
On Jan 20, 2022, at 6:39 AM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

Hi Jim,

This paper did not make it into the schedule for the next C meeting so it
is not a tight schedule at all. I do hope to get something in within the
next couple of weeks to make it in time for the subsequent (post February)
WG14 meeting though.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM

<graycol.gif>"Jim Thomas" ---01/20/2022 12:24:39 AM---Rajan, the comments
below are for V4. I believe most of them still apply to V6, but they are
incompl

From: "Jim Thomas" <jaswthomas at sbcglobal.net>
To: "Rajan Bhakta" <rbhakta at us.ibm.com>
Cc: "CFP" <cfp-interest at ucbtest.org>
Date: 01/20/2022 12:24 AM
Subject: [EXTERNAL] Re: [Cfp-interest 2346] Updated (V4) N2823

Rajan, the comments below are for V4. I believe most of them still apply to
V6, but they are incomplete. It will probably be Friday before I can
respond to V6 properly. How tight is your schedule on this? On Jan 19,
2022, at 3:25 PM, Rajan Bhakta ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Rajan, the comments below are for V4. I believe most of them still apply to
V6, but they are incomplete. It will probably be Friday before I can
respond to V6 properly.  How tight is your schedule on this?
On Jan 19, 2022, at 3:25 PM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

Once more into the breech! Responses inline in blue below.

(See attached file: N2823UpdateV6.html)

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM

<graycol.gif>"Jim Thomas" ---01/19/2022 04:26:12 PM---There’s no need to
mention <math.h> in “… when <stdlib.h>, <fenv.h> and <math.h> are included
…”. Th

From:  "Jim Thomas" <jaswthomas at sbcglobal.net>
To:  "Rajan Bhakta" <rbhakta at us.ibm.com>
Cc:  "CFP" <cfp-interest at ucbtest.org>
Date:  01/19/2022 04:26 PM
Subject:  [EXTERNAL] Re: [Cfp-interest 2346] Updated (V4) N2823

There’s no need to mention <math.h> in “… when <stdlib.h>, <fenv.h> and
<math.h> are included …”. The “inclusive version” of Alternative 1 is
missing ", without the requirements to set errno (see 7.5) or modify the
floating-point ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
There’s no need to mention <math.h> in “… when <stdlib.h>, <fenv.h> and
<math.h> are included …”.

Agreed.

The “inclusive version” of Alternative 1 is missing ", without the
requirements to set errno (see 7.5) or modify the floating-point
environment (see 7.6),”.
I thought that was the discussion we had today. Without requiring errno.h
to be included, there is no way to access errno from a user program,
meaning we do not need to say anything about setting it as the behaviour is
not observable by a program.
That was what I had thought you meant by "not excluding". i.e. no need to
say no setting errno or modifying the floating point environment in the
normative text. I did add in a line to mention the floating-point
environment to the footnote as you suggested below.

Ah. I didn’t understand the whole intention for the “inclusive version”.

Similar to [?] regarding errno, if the <fenv.h> functions to query flags or
modify modes are not required, the implementation does not have to maintain
thread local storage for the floating-point environment.

Regarding the [?] footnote, I don’t see that C mentions the as if rule.
Also, the C term seems to be “thread storage”. Here’s a different shot at
the footnote:
[?] Since a conforming freestanding implementation is not required to
accept program that use features in the contents of <errno.h>, the
implementation need not provide thread storage for errno. Similarly, since
a conforming freestanding implementation is not required to accept programs
that use features in the contents of <fenv.h> for accessing floating-point
exceptions or for changing the floating-point rounding mode, the
implementation need not provide thread storage for the floating-point
environment.

In 7.20 #20 we could allow freestanding implementations to define
math_errhanding to 0, to indicate that neither errno nor floating-point
exceptions are supported.

The draft footnote above doesn’t mention locales. I’m not sure what to say.

The following would be more parallel, and uses the same wording as for math
overflow and underflow in 7.12.1:
;  if the integer expression math_errhandling & MATH_ERRNO is nonzero,
whether errno acquires the value ERANGE is implementation defined; if the
integer expression math_errhandling & MATH_ERREXCEPT is nonzero, whether
the "underflow" floating-point exception is raised is
implementation-defined.
Where do you see this being added? I can't see using it in alternative 1 as
that is intended to have no error handling. Was this a proposal for
alternative 2?

Yes. It’s for the underflow paragraph for alternative 2, for 7.22.1.5 and
7.29.4.1.1.

Matching the overflow paragraph to 7.12.1 gives
...; if the integer expression math_errhandling & MATH_ERRNO is nonzero,
the integer expression errno acquires the value ERANGE; if the integer
expression math_errhandling & MATH_ERREXCEPT is nonzero, the “overflow"
floating-point exception is raised.

The overflow paragraph for 7.29.4.1.1 should match 7.22.1.5.
If so, I like it as it allows implementations to avoid the exception case
as well. This however would be a change to the existing definition which
requires ERANGE for overflow. I did want to avoid changing the existing
specification too much beyond allowing exceptions (as it seems we do for
other functions).

Hmm. Isn’t it substantively the same as what you have? It makes the
floating-point numeric conversion functions like the math functions with
respect to errno and floating-point exceptions. Yes, it is a change from
the current C draft. The change is like when we added floating-point
exceptions as an alternative to errno for math.h functions.

-  Jim Thomas

The (unchanged) last sentence in the last change does not match what is in
the draft.
Updated. This is probably also what Fred meant. Sorry Fred, I misunderstood
what you were referring to.

- Jim Thomas
On Jan 19, 2022, at 11:30 AM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

(See attached file: N2823UpdateV4.html)

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM

<N2823UpdateV4.html>_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest

<N2823UpdateV6.html>

_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220202/612c2882/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220202/612c2882/attachment-0001.gif>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220202/612c2882/attachment-0001.html>