IA64 and SPARC64 64bit use 128bit long double. On x86+AMD64 long double is an 80bit floating point type. On some platforms long double is identical to double, because they do not support a wider floating point type.
Olga On Thu, Aug 22, 2013 at 7:32 PM, Glenn Fowler <[email protected]> wrote: > > On Thu, 22 Aug 2013 00:46:06 +0200 Irek Szczesniak wrote: >> On Thu, Aug 22, 2013 at 12:26 AM, Irek Szczesniak <[email protected]> >> wrote: >> > On Thu, Aug 22, 2013 at 12:03 AM, Glenn Fowler <[email protected]> >> > wrote: >> >> >> >> On Wed, 21 Aug 2013 22:24:52 +0200 Tina Harriott wrote: >> >>> On 21 August 2013 20:02, David Korn <[email protected]> wrote: >> >>> > cc: [email protected] >> >>> > Subject: Re: Re: Re: [ast-developers] "${_Bool.true}" not working... / >> >>> > was: Re: AT&T Software Technology ast alpha software download update >> >>> > -------- >> >>> > >> >>> >> > The reason why I want this to work are references, after which you >> >>> >> > can >> >>> >> > no longer differ between plain bool and array element book: >> >>> >> > ./arch/linux.i386-64/bin/ksh -o nounset -c 'bool -a b=( [4][5]=true >> >>> >> > ) >> >>> >> > ; nameref nb=b[4][5] ; print ${nb.true}' >> >>> >> > ./arch/linux.i386-64/bin/ksh: nb.true: parameter not set >> >>> >> > >> >>> >> > /arch/linux.i386-64/bin/ksh -o nounset -c 'bool b ; nameref nb=b ; >> >>> >> > print ${nb.true}' >> >>> >> > 1 >> >>> >> >> >>> >> Is the next alpha going to fix this? The bug is hurting my ability to >> >>> >> use the _Bool. >> >>> >> >> >>> >> Wendy >> >>> >> >> >>> > >> >>> > The next alpha (not counting the one gsf wants to test without my >> >>> > changes), allow bool array variables (and name references to them) >> >>> > to have .enumconstat appended. >> >> >> >>> Will num.MIN/.MAX/.EPSILON/.M_PI work in the next alpha, too? The code >> >>> appears to be almost identical for all those cases... >> >> >> >> the libast features/float iffe script will need to provide *_EPSILON >> >> on systems that don't provide it in <float.h>, and it has to be done >> >> without the benefit of libast, meaning possibly no hexfloat and most >> >> likely a printf that does a bad job rounding floating point numbers >> >> >> >> anybody have C code that does that sans <float.h> ? >> > >> > That's an easy request: http://en.wikipedia.org/wiki/Machine_epsilon > >> On a 2nd thought, there are only binary16, binary32, binary64, >> binary128 and the nonstandard x387 binary80 >> to deal with. libast doesn't support binary16 yet, leaving four >> formats which can be identified through sizeof and handled with >> constants embedded in the iffe probe. That might be safer than to >> trust an algorithm which may fall victim to bizarre compiler >> optimizations or bugs. > > thanks for the ref > tabulating may not be that easy > bear with me ... > > libast related regression tests are in > $PACKAGEROOT/src/cmd/tests > in there is the ast strtof test harness strtof.c which generates the exeutable > $INSTALLROOT/src/cmd/tests/strtof > > when strtof is run with no arguments it prints out a one line signature for > the > current floating point implementation (I just today added sizeof() to the > signature) > the signature is the first line of output from this program: > -- > #include <stdio.h> > #include <float.h> > > #define S(x) # x > #define X(x) S(x) > > int > main(int argc, char** argv) > { > printf("%u.%u.%u.%u-%u.%u.%u.%u-%u.%u.%u.%u\n", > 8 * sizeof(float), FLT_DIG, -(FLT_MIN_10_EXP), FLT_MAX_10_EXP, > 8 * sizeof(double), DBL_DIG, -(DBL_MIN_10_EXP), > DBL_MAX_10_EXP, > 8 * sizeof(long double), LDBL_DIG, -(LDBL_MIN_10_EXP), > LDBL_MAX_10_EXP); > printf("\n"); > printf(" FLT_MAX %s\n", X(FLT_MAX)); > printf(" DBL_MAX %s\n", X(DBL_MAX)); > printf("LDBL_MAX %s\n", X(LDBL_MAX)); > printf("\n"); > printf(" FLT_EPSILON %s\n", X(FLT_EPSILON)); > printf(" DBL_EPSILON %s\n", X(DBL_EPSILON)); > printf("LDBL_EPSILON %s\n", X(LDBL_EPSILON)); > return 0; > } > -- > > the signatures are used to select the approriate strtof test script which is > read by the strtof harness: > > strtof-<SIGNATURE>.tst > > this is what I've collected so far > > 32.6.37.38-64.15.307.308-128.31.291.308 # lost access to > machine > 32.6.37.38-64.15.307.308-128.31.307.308 # lost access to > machine > > -- > # i386-32 > > 32.6.37.38-64.15.307.308-96.18.4931.4932 > > FLT_MAX 3.40282347e+38F > DBL_MAX 1.7976931348623157e+308 > LDBL_MAX 1.18973149535723176502e+4932L > > FLT_EPSILON 1.19209290e-7F > DBL_EPSILON 2.2204460492503131e-16 > LDBL_EPSILON 1.08420217248550443401e-19L > > # i386-64 > > 32.6.37.38-64.15.307.308-128.18.4931.4932 > > FLT_MAX 3.40282347e+38F > DBL_MAX 1.7976931348623157e+308 > LDBL_MAX 1.18973149535723176502e+4932L > > FLT_EPSILON 1.19209290e-7F > DBL_EPSILON 2.2204460492503131e-16 > LDBL_EPSILON 1.08420217248550443401e-19L > > # ppc64 > > 32.6.37.38-64.15.307.308-64.15.307.308 > > FLT_MAX 3.40282347e+38F > DBL_MAX 1.7976931348623157e+308 > LDBL_MAX 1.7976931348623157e+308L > > FLT_EPSILON 1.19209290e-7F > DBL_EPSILON 2.2204460492503131e-16 > LDBL_EPSILON 2.2204460492503131e-16L > > # ia64 > > 4.6.37.38-8.15.307.308-16.33.4931.4932 > > FLT_MAX 3.40282346638528859812E+38F > DBL_MAX 1.79769313486231570815E+308 > LDBL_MAX 1.18973149535723176508575932662800702E+4932L > > FLT_EPSILON 1.19209289550781250000E-07F > DBL_EPSILON 2.22044604925031308085E-16 > LDBL_EPSILON 1.92592994438723585305597794258492732E-34L > > # sun4 > > 32.6.37.38-64.15.307.308-128.33.4931.4932 > > FLT_MAX 3.4028234663852885981170E+38F > DBL_MAX 1.7976931348623157081452E+308 > LDBL_MAX 1.189731495357231765085759326628007016E+4932L > > FLT_EPSILON 1.1920928955078125000000E-07F > DBL_EPSILON 2.2204460492503130808473E-16 > LDBL_EPSILON 1.925929944387235853055977942584927319E-34L > > # mvs.390 > > 32.6.78.75-64.15.78.75-128.32.78.75 > > FLT_MAX ((const float) ((float * const)(*_Gtab(26)))[1]) > DBL_MAX ((const double) ((double * const)(*_Gtab(27)))[1]) > LDBL_MAX ((const long double) ((long double * const)(*_Gtab(28)))[1]) > > FLT_EPSILON ((const float) ((float * const)(*_Gtab(26)))[2]) > DBL_EPSILON ((const double) ((double * const)(*_Gtab(27)))[2]) > LDBL_EPSILON ((const long double) ((long double * const)(*_Gtab(28)))[2]) > > # mvs.390 with %g for *_MAX and *_EPSILON > > FLT_MAX 7.2370051e+75 > DBL_MAX 7.237005577332262e+75 > LDBL_MAX 7.23700557733226221397318656304299e+75 > > FLT_EPSILON 9.5367432e-07 > DBL_EPSILON 2.220446049250313e-16 > LDBL_EPSILON 3.08148791101957736488956470813588e-33 > > -- > it would be good to know of any other signatures and the corresponding > *_EPSILON > and also which ones correspond to IEEE 754 > for example, ia64 and sun4 can't both be IEEE 754 considering the diffs, can > they? > > _______________________________________________ > ast-developers mailing list > [email protected] > http://lists.research.att.com/mailman/listinfo/ast-developers -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
