__declspec(fld) to enable 80-bit long double (same as if -fld were given) but on a symbol by symbol basis

[joncampbell123]

Allow compiled C/C++ code to enable 80-bit long double on a symbol by symbol basis by adding declspec(fld) to the data type. Allow the declspec(fld) to function the same as if -fld were enabled at that very point.

This can help enable support for 80-bit long double gradually through the codebase without breaking anything.

Related to https://github.com/open-watcom/open-watcom-v2/issues/1200

[joncampbell123]

See also this DOSLIB test program which was updated to test it:

https://github.com/joncampbell123/doslib/blob/master/hw/dos/testprnb.c

First one without -fld, second one with -fld.

[joncampbell123]

If "fld" is not a good __declspec name, or there's a better way to do it, let me know. The idea is to allow the use of 80-bit long double even if -fld isn't specified by prefixing "long double" with something that overrides the default long double == double mapping. Internal parts of OW could use this to properly handle long double without needing the -fld flag.

The change given here was the best I could do in adding the feature with minimal changes to the code base.

[jmalak]

The purpose of the -fld option is to allow a long double to be used as an 80-bit FP including all math functions, etc. By default long double type is mapped to double type (by FE) all in-line FP math (80bit) is rounded to 64bit FP. With the -fld option, long double type is not double, but an 80-bit FP type, and all in-line FP math is not rounded to just 64-bit FP and stay with full 80-bit precission. CRTL gets information from the compiler about what size long double to use and switches all math functions between 64-bit or 80-bit for the long double type and any appropriate math functions. That something like __declspec(fld) cannot be implemented.

[joncampbell123]

The purpose of the -fld option is to allow a long double to be used as an 80-bit FP including all math functions, etc. By default long double type is mapped to double type (by FE) all in-line FP math (80bit) is rounded to 64bit FP. With the -fld option, long double type is not double, but an 80-bit FP type, and all in-line FP math is not rounded to just 64-bit FP and stay with full 80-bit precission. CRTL gets information from the compiler about what size long double to use and switches all math functions between 64-bit or 80-bit for the long double type and any appropriate math functions. That something like __declspec(fld) cannot be implemented.

The expectation here is only to be able to declare such a variable, even if at this time you can do little else with it due to total lack of support in the CG. I don't know how you expect to fix it without such a feature then.

If use of the declspec triggered a one time warning about lack of math runtime support, would you allow this?

[jmalak]

We are discus CRTL solution which doesn't depend on how good is CG long double support. It must be implemented way as other existing long double 80-bit support by using long_double structure and guarded by _LONG_DOUBLE_ macro.