This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gfortran,ping] support for large kinds in front-end and library


On Sep 12, 2005, at 10:45 AM, Steve Kargl wrote:

On Mon, Sep 12, 2005 at 07:19:20PM +0200, Fran?ois-Xavier Coudert wrote:

So, we need to have configure check if these exists in libm,
and if not, we need to provide implementations.

Well, I don't think it's our job to provide implementations.

If we provide REAL(10) (or REAL(16)) data type, then we must provide "working" Fortran intrinsic procedures (for some definition of "working"). IIRC, this is a requirement of the Standard.

That's my understanding also. I've seen at least one case where a vendor tried to weasel out of this by arguing that they supported an additional real kind as an "extension." This was their attempt at justifying why they could get by without supporting a complex of that kind. But I don't think that the argument actually held water because some aspects turned into violations instead of extensions.


For a very pointed and specific example, I think it a violation for selected_real_kind to return a positive value that isn't the kind of a fully supported real; a user is supposed to be able to count on anything returned by selected_real_kind as either being negative or completely implemented. Please don't break that bit; it is fundamental and important. If you have an incompletely implemented kind, then make sure it doesn't get returned by things like selected_real_kind.

--
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                            |        -- Mark Twain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]