From: Wu Y. <ad...@ne...> - 2002-06-12 02:46:13
|
I read this from MSDN: In Win32 programming, however, the long double data type maps to the double, 64-bit precision data type. The Microsoft run-time library provides long double versions of the math functions only for backward compatibility. The long double function prototypes are identical to the prototypes for their double counterparts, except that the long double data type replaces the double data type. The long double versions of these functions should not be used in new code. And I tested using the following code: #include <stdio.h> int main() { long double d; d = 0.1; printf("%d\n", sizeof d); printf("%Lg\n", d); return 0; } MSVC 6 output: 8 0.1 MinGW GCC output (both 2.95.3-7 and CRTDLL version 2.95.2 19991024): 12 -9.25596e+061 So MinGW was never consistent with MSVC on this point (luckily we still could use cout << (long double) d in MinGW). And we can either use only double (consistent with MSVC) or write our own printf/fprintf/sprintf/snprintf/.... Or never printf a long double. For the current moment, I prefer not to printf a long double. Seldom are chances to do that. Best regards, Wu Yongwei |
From: Wu Y. <ad...@ne...> - 2002-06-12 02:54:31
|
Test program: #include <cstdio> #include <iostream> using namespace std; int main() { long double d; d = 0.1; printf("%d %Lg\n", sizeof d, d); cout << sizeof d << ' ' << d << endl; return 0; } MSVC 6: 8 0.1 8 0.1 BCC32 5.5.1: 10 0.1 10 0.1 MinGW GCC: 12 -9.25596e+061 12 0.1 Cygwin GCC: 12 0.1 12 0.1 For me, the BCC32 result seems more reasonable. Does GCC pad long double to 12 bytes for alignment? Best regards, Wu Yongwei |
From: Ioannis V. <no...@ho...> - 2002-06-12 03:29:38
|
For the code: #include <iostream> int main() { using namespace std; long double ld=0.7; cout<<ld<<" "<<sizeof(ld)<<" "<<sizeof(double)<<endl; } > Executing: C:\Program Files\ConTEXT\ConExec.exe "g++" "temp.cpp" -o temp -ansi -pedantic-errors -Wall -fexpensive-optimizations -O3 -ffloat-store -mcpu=pentiumpro C:\c>temp -4.66726e-062 12 8 ==> Definately broken. > Executing: C:\Program Files\ConTEXT\ConExec.exe "bcc32" -O2 -6 -q "temp.cpp" C:\c>temp 0.7 10 8 > Executing: C:\Program Files\ConTEXT\ConExec.exe "icl" /EHa /G6 /nologo /O3 /Qansi /Qc99 /Za /Qipo "temp.cpp" C:\c>temp 0.7 8 8 At the last we see double occupying the same space as long double. In BCC long double is larger, in GCC too, but in GCC the implementation is broken. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Luke D. <cod...@ho...> - 2002-06-12 05:38:22
|
----- Original Message ----- From: "Ioannis Vranos" <no...@ho...> To: "'MinGW-Users'" <min...@li...> Sent: Wednesday, June 12, 2002 11:29 AM Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect > For the code: > > > #include <iostream> > > int main() > { > using namespace std; > > long double ld=0.7; > > cout<<ld<<" "<<sizeof(ld)<<" "<<sizeof(double)<<endl; > } > > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "g++" "temp.cpp" -o > temp -ansi -pedantic-errors -Wall -fexpensive-optimizations -O3 > -ffloat-store -mcpu=pentiumpro > > C:\c>temp > -4.66726e-062 12 8 > > ==> Definately broken. > It apparently uses sprintf() to format the output so this the same as the last problem. > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "bcc32" -O2 -6 -q > "temp.cpp" > > C:\c>temp > 0.7 10 8 > > > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "icl" /EHa /G6 /nologo > /O3 /Qansi /Qc99 /Za /Qipo "temp.cpp" > > C:\c>temp > 0.7 8 8 > > > At the last we see double occupying the same space as long double. > > In BCC long double is larger, in GCC too, but in GCC the implementation > is broken. > Yes, so this will need to be fixed by using a different implementation of *printf functions. I think Danny is working on this at the moment. Luke Dunstan |
From: Ioannis V. <no...@ho...> - 2002-06-12 05:58:02
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Luke Dunstan > Sent: Wednesday, June 12, 2002 8:38 AM > To: Ioannis Vranos > Cc: mingw-users > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect > > > Yes, so this will need to be fixed by using a different > implementation of > *printf functions. I think Danny is working on this at the moment. This is great. I downloaded the sources from sourceforge myself, but i cannot find the implementation of fprintf() etc! Are these functions precompiled and included as object files or something? Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Luke D. <cod...@ho...> - 2002-06-12 06:37:33
|
Once again, the C runtime library is not written by the Mingw or GCC developers, it is provided by Microsoft in MSVCRT.DLL (which is included with Windows). This is unlike some other Windows compilers such as Borland C++ which have their own C runtime library. That is why bugs like this are not trivial to fix, and would require an entirely different implementation of printf. Most likely an open source library will be used, but I think many people will want it to be compatible with the MS printf, in the sense of its extra features (not its bugs and missing features). There is a separate project at http://sourceforge.net/projects/mingwacr/ to develop a complete C runtime for Mingw from scratch, so perhaps you could contribute to this project if it interests you. Luke Dunstan ----- Original Message ----- From: "Ioannis Vranos" <no...@ho...> To: "MinGW Users Mailing List" <min...@li...> Sent: Wednesday, June 12, 2002 1:57 PM Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect > > -----Original Message----- > > From: min...@li... > > [mailto:min...@li...] On Behalf Of > > Luke Dunstan > > Sent: Wednesday, June 12, 2002 8:38 AM > > To: Ioannis Vranos > > Cc: mingw-users > > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect > > > > > > Yes, so this will need to be fixed by using a different > > implementation of > > *printf functions. I think Danny is working on this at the moment. > > > This is great. I downloaded the sources from sourceforge myself, but i > cannot find the implementation of fprintf() etc! Are these functions > precompiled and included as object files or something? > > > Ioannis > > * Ioannis Vranos > * Programming pages: http://www.noicys.cjb.net > * Alternative URL: http://run.to/noicys > |
From: Karl B. <kb...@pa...> - 2002-06-12 07:45:26
|
> Once again, the C runtime library is not written by the Mingw or GCC > developers, it is provided by Microsoft in MSVCRT.DLL (which is included > with Windows). This is unlike some other Windows compilers such as Borland > C++ which have their own C runtime library. That is why bugs like this are > not trivial to fix, and would require an entirely different implementation > of printf. Most likely an open source library will be used, but I think many > people will want it to be compatible with the MS printf, in the sense of its > extra features (not its bugs and missing features). Does anybody know if using STLport would fix this? > There is a separate project at http://sourceforge.net/projects/mingwacr/ to > develop a complete C runtime for Mingw from scratch, so perhaps you could > contribute to this project if it interests you. |
From: Tomasz P. <coc...@po...> - 2002-06-12 22:23:31
|
I was watching this subject curiously and there is other thing that is unsure for me: code: // init float f = 0.1; double d = 0.1; printf("%u, %u\n", sizeof(f), sizeof(d)); // just info printf("%f, %u\n", d, 1); // ??? printf("%lf, %u\n", f, 2); // ??? output: 4, 8 0.100000, 1 0.100000, 2 The question is: why is it working at all ??? In the 2nd printf the compiler should push 8 bytes to the stack and printf should expect only 4 so the 2nd param should contain 2 bytes of double! In the 3rd printf the compiler should push 4 bytes to the stack and printf should expect 8, so the 1st param should consist of float and 2nd param! Koczis. |
From: Ioannis V. <no...@ho...> - 2002-06-13 00:41:30
|
> -----Original Message----- > From: Tomasz Pona [mailto:coc...@po...] > Sent: Thursday, June 13, 2002 1:15 AM > To: Luke Dunstan; Ioannis Vranos > Cc: mingw-users > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect > > > I was watching this subject curiously and there is other thing that is > unsure for me: > > code: > > // init > float f = 0.1; > double d = 0.1; > > printf("%u, %u\n", sizeof(f), sizeof(d)); // just info > > printf("%f, %u\n", d, 1); // ??? > printf("%lf, %u\n", f, 2); // ??? %lf is C99 stuff. And basically %l in front of f has no effect. So it is as if you wrote %f. The standard says: "l (ell) Specifies that a following d, i, o, u, x, or X conversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g, or G conversion specifier." > > output: > > 4, 8 > 0.100000, 1 > 0.100000, 2 > > The question is: why is it working at all ??? > > In the 2nd printf the compiler should push 8 bytes to the > stack and printf > should expect only 4 so the 2nd param should contain 2 bytes > of double! > In the 3rd printf the compiler should push 4 bytes to the > stack and printf > should expect 8, so the 1st param should consist of float and > 2nd param! ... Confused. If the above explanation isn't sufficient, say so and i 'll think on all those numbers you provided. :) Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Luke D. <cod...@ho...> - 2002-06-13 01:11:31
|
I believe the reason is because all float values are promoted to double when passed as variable arguments, therefore %f implies a double type. Luke Dunstan ----- Original Message ----- From: "Tomasz Pona" <coc...@po...> To: "Luke Dunstan" <cod...@ho...>; "Ioannis Vranos" <no...@ho...> Cc: "mingw-users" <min...@li...> Sent: Thursday, June 13, 2002 6:15 AM Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect > I was watching this subject curiously and there is other thing that is > unsure for me: > > code: > > // init > float f = 0.1; > double d = 0.1; > > printf("%u, %u\n", sizeof(f), sizeof(d)); // just info > > printf("%f, %u\n", d, 1); // ??? > printf("%lf, %u\n", f, 2); // ??? > > output: > > 4, 8 > 0.100000, 1 > 0.100000, 2 > > The question is: why is it working at all ??? > > In the 2nd printf the compiler should push 8 bytes to the stack and printf > should expect only 4 so the 2nd param should contain 2 bytes of double! > In the 3rd printf the compiler should push 4 bytes to the stack and printf > should expect 8, so the 1st param should consist of float and 2nd param! > > Koczis. > |
From: Ioannis V. <no...@ho...> - 2002-06-12 03:10:51
|
Whatever the reason, it is surely a defect. Also long double being a double is somewhat lame. :) And this because we use long double in special occassions when we want extreme accuracy. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys > -----Original Message----- > From: Luke Dunstan [mailto:cod...@ho...] > Sent: Wednesday, June 12, 2002 4:45 AM > To: mingw-users; Ioannis Vranos > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > Message > I can't say for sure but I believe the problem is that Mingw > uses the MS C > runtime, which does not support long doubles with printf(). I > tried this > with MSVC 6 and it seems to use doubles everywhere instead of > long doubles, > so it produces the correct result. I assume that the other > two compilers > either use doubles only, or have their own runtime libraries > that print long > doubles properly. > > The assembly produced by: > > long double x = 0.1; > printf("%Lf\n", x); > > Is this for GCC 3.1: > > movl $0xccccd000,0xffffffe8(%ebp) > movl $0xcccccccc,0xffffffec(%ebp) > movl $0x3ffb,0xfffffff0(%ebp) > pushl 0xfffffff0(%ebp) > pushl 0xffffffec(%ebp) > pushl 0xffffffe8(%ebp) > push $0x142 > call 18e <_printf> > > And this for MSVC 6: > > movl $0x9999999a,0xfffffff8(%ebp) > movl $0x3fb99999,0xfffffffc(%ebp) > mov 0xfffffffc(%ebp),%eax > push %eax > mov 0xfffffff8(%ebp),%ecx > push %ecx > push $0x0 > call 38 <_printf> > > I think the old Mingw GCC used "long double" == "double" like > MSVC, so it > would have worked before. > > Luke Dunstan > > ----- Original Message ----- > From: Ioannis Vranos > To: MinGW Users Mailing List > Sent: Tuesday, June 11, 2002 2:34 PM > Subject: [Mingw-users] GMINGW GCC 3.1 another defect? > > > I do some rounding experiments today, but GCC 3.1 produces > strange results > for the following code: > > #include <stdio.h> > #include <stdlib.h> > > #include <math.h> > #include <float.h> > > /* depth is: 0.12345 . That is if we want to round the number > 1.23 to the > integral part we give mround(1.23, 0) > */ > > long double mround(long double number, const unsigned long depth) > { > if(depth>=DBL_DIG) > return number; > > if(number>=0) > return floor(number * pow(10, depth) + 0.5) / pow(10, depth); > > else > return floor(number * pow(10, depth) - 0.5) / pow(10, depth); > } > > > int main(void) > { > > system("cls"); > > printf("%Lf\n", mround(0.1, 3)); > > > return 0; > } > > > Compiled: > > Executing: C:\Program Files\ConTEXT\ConExec.exe "gcc" "mround.c" -o > mround -ansi -pedantic-errors -Wall -fexpensive-optimizations > -O3 -ffloat-st > ore -mcpu=pentiumpro > > > produces: > > -92559631349317808000000000000000000000000000000000000000000000.000000 > > > However: > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "bcc32" -O2 -6 -q -A > "mround.c" > > 0.100000 > > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "icl" /EHa > /G6 /nologo /O3 > /Qansi /Qc99 /Za /Qipo "mround.c" > > 0.100000 > > > > Casting doesn't help. > > > Things work reasonably when double is used. > > > Ioannis > > * Ioannis Vranos > * Programming pages: http://www.noicys.cjb.net > * Alternative URL: http://run.to/noicys > |
From: Mikael A. <mik...@te...> - 2002-06-12 06:35:05
|
Hi ! You might wanna call it a defect, but there is not much that can be done about it, the MS runtime does not support long doubles, it's as simple as that. What you could do, would be to force gcc to make all "long double" normal "double" instead, and as far as I know that is fine with the ansi standard also, but then you can't use long doubles at all. Mikael ----- Original Message ----- From: "Ioannis Vranos" <no...@ho...> To: "'mingw-users'" <min...@li...> Sent: Wednesday, June 12, 2002 4:10 AM Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect? > Whatever the reason, it is surely a defect. Also long double being a > double is somewhat lame. :) And this because we use long double in > special occassions when we want extreme accuracy. > > > > Ioannis > > * Ioannis Vranos > * Programming pages: http://www.noicys.cjb.net > * Alternative URL: http://run.to/noicys > > > > -----Original Message----- > > From: Luke Dunstan [mailto:cod...@ho...] > > Sent: Wednesday, June 12, 2002 4:45 AM > > To: mingw-users; Ioannis Vranos > > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > > > > Message > > I can't say for sure but I believe the problem is that Mingw > > uses the MS C > > runtime, which does not support long doubles with printf(). I > > tried this > > with MSVC 6 and it seems to use doubles everywhere instead of > > long doubles, > > so it produces the correct result. I assume that the other > > two compilers > > either use doubles only, or have their own runtime libraries > > that print long > > doubles properly. > > > > The assembly produced by: > > > > long double x = 0.1; > > printf("%Lf\n", x); > > > > Is this for GCC 3.1: > > > > movl $0xccccd000,0xffffffe8(%ebp) > > movl $0xcccccccc,0xffffffec(%ebp) > > movl $0x3ffb,0xfffffff0(%ebp) > > pushl 0xfffffff0(%ebp) > > pushl 0xffffffec(%ebp) > > pushl 0xffffffe8(%ebp) > > push $0x142 > > call 18e <_printf> > > > > And this for MSVC 6: > > > > movl $0x9999999a,0xfffffff8(%ebp) > > movl $0x3fb99999,0xfffffffc(%ebp) > > mov 0xfffffffc(%ebp),%eax > > push %eax > > mov 0xfffffff8(%ebp),%ecx > > push %ecx > > push $0x0 > > call 38 <_printf> > > > > I think the old Mingw GCC used "long double" == "double" like > > MSVC, so it > > would have worked before. > > > > Luke Dunstan > > > > ----- Original Message ----- > > From: Ioannis Vranos > > To: MinGW Users Mailing List > > Sent: Tuesday, June 11, 2002 2:34 PM > > Subject: [Mingw-users] GMINGW GCC 3.1 another defect? > > > > > > I do some rounding experiments today, but GCC 3.1 produces > > strange results > > for the following code: > > > > #include <stdio.h> > > #include <stdlib.h> > > > > #include <math.h> > > #include <float.h> > > > > /* depth is: 0.12345 . That is if we want to round the number > > 1.23 to the > > integral part we give mround(1.23, 0) > > */ > > > > long double mround(long double number, const unsigned long depth) > > { > > if(depth>=DBL_DIG) > > return number; > > > > if(number>=0) > > return floor(number * pow(10, depth) + 0.5) / pow(10, depth); > > > > else > > return floor(number * pow(10, depth) - 0.5) / pow(10, depth); > > } > > > > > > int main(void) > > { > > > > system("cls"); > > > > printf("%Lf\n", mround(0.1, 3)); > > > > > > return 0; > > } > > > > > > Compiled: > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "gcc" "mround.c" -o > > mround -ansi -pedantic-errors -Wall -fexpensive-optimizations > > -O3 -ffloat-st > > ore -mcpu=pentiumpro > > > > > > produces: > > > > -92559631349317808000000000000000000000000000000000000000000000.000000 > > > > > > However: > > > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "bcc32" -O2 -6 -q -A > > "mround.c" > > > > 0.100000 > > > > > > > Executing: C:\Program Files\ConTEXT\ConExec.exe "icl" /EHa > > /G6 /nologo /O3 > > /Qansi /Qc99 /Za /Qipo "mround.c" > > > > 0.100000 > > > > > > > > Casting doesn't help. > > > > > > Things work reasonably when double is used. > > > > > > Ioannis > > > > * Ioannis Vranos > > * Programming pages: http://www.noicys.cjb.net > > * Alternative URL: http://run.to/noicys > > > > _______________________________________________________________ > > Multimillion Dollar Computer Inventory > Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar > > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Wu Y. <ad...@ne...> - 2002-06-12 04:07:06
|
The way of MSVC is acceptable behaviour. It is not broken, whether you like it or not. The C++ 98 standard reads: The type double provides at least as much precision as float, and the type long double provides at least as much precision as double. And the C99 standard has similar wording. The problem of MinGW is that it wants compatibility with MSVC while it really supports a more precise long double as other GCC does. A question for Danny (or other gurus): Why padding 80 bits to 96 bits? Best regards, Wu Yongwei |
From: Ioannis V. <no...@ho...> - 2002-06-12 04:49:09
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Wu Yongwei > Sent: Wednesday, June 12, 2002 7:07 AM > To: MinGW-Users > Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect? > > > The way of MSVC is acceptable behaviour. It is not broken, > whether you like > it or not. I think VC++ 6 works fine with long double, since it is 100% ANSI C89 compliant. > The C++ 98 standard reads: > > The type double provides at least as much precision as float, > and the type long double provides at least as much precision > as double. > > And the C99 standard has similar wording. > > The problem of MinGW is that it wants compatibility with MSVC while it > really supports a more precise long double as other GCC does. No, the problem is that printf(), cout() do not work correctly with long double. For example the code: #include <stdio.h> int main(void) { long double ld=0.7; double d=ld; printf("%f %f\n", (double)ld, d); return 0; } works as it should: C:\c>temp 0.700000 0.700000 Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Joerg B. <jo...@sq...> - 2002-06-12 10:14:27
|
Hi! Wu Yongwei wrote: > > [...] > > The problem of MinGW is that it wants compatibility with MSVC while it > really supports a more precise long double as other GCC does. From following these messages, my impression is that the only problem is formatting the output in the "printf" family (and possibly also analyzing input in the "scanf" family). In that case, the "simple" solution seems to be - cast any "long double" to "double" in the "printf" calls, - replace any "%Lf" by "%f" in these calls. I am aware that this would require source code modifications, but it would at least keep up the precision in computation (while losing it in the printed representation); and the modified source would still be portable as well as work with any C runtime (including the original MSVCRT). > > A question for Danny (or other gurus): Why padding 80 bits to 96 bits? Just a guess: To get 32 bit alignment without "external" padding? Regards, Joerg Bruehe -- Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany (speaking only for himself) mailto: jo...@sq... |
From: Ioannis V. <no...@ho...> - 2002-06-12 10:40:30
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Joerg Bruehe > Sent: Wednesday, June 12, 2002 1:14 PM > To: MinGW-Users > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > Hi! > > Wu Yongwei wrote: > > > > [...] > > > > The problem of MinGW is that it wants compatibility with > MSVC while it > > really supports a more precise long double as other GCC does. > > From following these messages, my impression is that the only > problem is formatting the output in the "printf" family > (and possibly also analyzing input in the "scanf" family). > In that case, the "simple" solution seems to be > - cast any "long double" to "double" in the "printf" calls, > - replace any "%Lf" by "%f" in these calls. > I am aware that this would require source code modifications, > but it would at least keep up the precision in computation > (while losing it in the printed representation); > and the modified source would still be portable > as well as work with any C runtime (including the original MSVCRT). No it is not only this. LDBL_DIG in float.h must be changed to reflect the range of double, LDBL_MAX, LDBL_MIN, ... C++'s <limits> (or how it is called). Isn't it possible during compilation, where it is read as long double in the source code, a double to be created? And then all the above to be implemented too. Anyone having VC++ 6, can test the following code and provide us with the results? It would give a useful insight. #include <stdio.h> #include <float.h> int main(void) { printf("\nsizeof(long double)= %lu, sizeof(double)= %lu\n", (unsigned long)sizeof(long double), (unsigned long)sizeof(double)); printf("DBL_DIG= %d, LDBL_DIG= %d\n", DBL_DIG, LDBL_DIG); printf("\nDBL_MAX= %f,\n\nLDBL_MAX=%Lf\n", DBL_MAX, LDBL_MAX); return 0; } Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Esa V. <esa...@bo...> - 2002-06-12 12:24:06
|
Ioannis Vranos wrote : Anyone having VC++ 6, can test the following code and provide us with the results? It would give a useful insight. #include <stdio.h> #include <float.h> int main(void) { printf("\nsizeof(long double)= %lu, sizeof(double)= %lu\n", (unsigned long)sizeof(long double), (unsigned long)sizeof(double)); printf("DBL_DIG= %d, LDBL_DIG= %d\n", DBL_DIG, LDBL_DIG); printf("\nDBL_MAX= %f,\n\nLDBL_MAX=%Lf\n", DBL_MAX, LDBL_MAX); return 0; } MSVC++6sp5 on nt4sp6 produced this: " sizeof(long double)= 8, sizeof(double)= 8 DBL_DIG= 15, LDBL_DIG= 15 DBL_MAX= 17976931348623157000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 00.0 00000, LDBL_MAX=1797693134862315700000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 00.0 00000 " ---------------------------------------------------------- Esa Ilari Vuokko +358-50-544 8847 esa...@bo... Bonum IT Oy www.bonumit.com ---------------------------------------------------------- |
From: Ioannis V. <no...@ho...> - 2002-06-12 12:43:03
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Esa Vuokko > Sent: Wednesday, June 12, 2002 3:24 PM > To: Ioannis Vranos; MinGW Users Mailing List > Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect? > > > Ioannis Vranos wrote : > > Anyone having VC++ 6, can test the following code and > provide us with > the results? It would give a useful insight. > > #include <stdio.h> > #include <float.h> > > int main(void) > { > printf("\nsizeof(long double)= %lu, sizeof(double)= %lu\n", > (unsigned long)sizeof(long double), (unsigned > long)sizeof(double)); > > printf("DBL_DIG= %d, LDBL_DIG= %d\n", DBL_DIG, LDBL_DIG); > > printf("\nDBL_MAX= %f,\n\nLDBL_MAX=%Lf\n", DBL_MAX, LDBL_MAX); > > > > return 0; > } > > > MSVC++6sp5 on nt4sp6 produced this: > > " > sizeof(long double)= 8, sizeof(double)= 8 > DBL_DIG= 15, LDBL_DIG= 15 > > DBL_MAX= > 17976931348623157000000000000000000000000000000000000000000000 > 000000000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 0000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 0000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 00.0 > 00000, > > LDBL_MAX=17976931348623157000000000000000000000000000000000000 > 00000000000000 > 0000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 0000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 0000 > 00000000000000000000000000000000000000000000000000000000000000 > 00000000000000 > 00.0 > 00000 > " Useful info. It is apparent that VC++ 6's long double is equivallent with double. I hope it shows a direction. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Luke D. <cod...@ho...> - 2002-06-12 12:53:15
|
----- Original Message ----- From: "Ioannis Vranos" <no...@ho...> To: "MinGW Users Mailing List" <min...@li...> Sent: Wednesday, June 12, 2002 6:40 PM Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect? > > > > From following these messages, my impression is that the only > > problem is formatting the output in the "printf" family > > (and possibly also analyzing input in the "scanf" family). > > In that case, the "simple" solution seems to be > > - cast any "long double" to "double" in the "printf" calls, > > - replace any "%Lf" by "%f" in these calls. > > I am aware that this would require source code modifications, > > but it would at least keep up the precision in computation > > (while losing it in the printed representation); > > and the modified source would still be portable > > as well as work with any C runtime (including the original MSVCRT). > > > No it is not only this. LDBL_DIG in float.h must be changed to reflect > the range of double, LDBL_MAX, LDBL_MIN, ... C++'s <limits> (or how it > is called). What is wrong with LDBL_DIG, etc? DBL_DIG = 15 and LDBL_DIG = 18, which is correct. Wu Yongwei is simply saying what we originally suggested: just don't use %Lf at all with Mingw. He is not suggesting that we convert long double to be equivalent to double in representation, and he is not suggesting ways to make Mingw ANSI compliant. > > Isn't it possible during compilation, where it is read as long double in > the source code, a double to be created? And then all the above to be > implemented too. Yes, you can configure GCC to make double and long double exactly equivalent, but if most users want 80 bit long doubles despite the C runtime, then that is probably how it will stay. Perhaps you believe that removing functionality (higher precision) is better than not having 100% ANSI compliance, but others believe that is is better to wait, and add functionality (a new printf) to achieve compliance. > > > Anyone having VC++ 6, can test the following code and provide us with > the results? It would give a useful insight. > [snip] > > > Ioannis I don't see why you would need to run this to know what it will produce. On MSVC we have already established that sizeof(double) == sizeof(long double), so of course DBL_DIG *must* be equal to LDBL_DIG, etc. From everything you have said, it sounds like you want to make Mingw behave exactly like MSVC with respect to long doubles, and if this is true then why not just say that from the beginning :) Luke Dunstan |
From: Wu Y. <ad...@ne...> - 2002-06-12 09:55:35
|
I will not even say that the MS runtime does not support long doubles. It's that the MS long double is not equivalent to that of MinGW (GCC), and is only 64 bits instead of 80 bits. It seems we need to deviate from MS compatibility if we want a "better" long double. Since MS does not recomment people to use long double, it does not seems a serious issue. Maybe we could place the new printf statically in libmingwex so we automatically link it when we use the extended math functions. Or place it in a new separate library? I am really glad that MinGW GCC 2.95 works with cout << (long double).... So we can at least use long double with G++ for now. For Karl, STLport can do cout << (long double)... too, if this is what you want; though this will not help C programmers. Best regards, Wu Yongwei --- Original Message from --- Hi ! You might wanna call it a defect, but there is not much that can be done about it, the MS runtime does not support long doubles, it's as simple as that. What you could do, would be to force gcc to make all "long double" normal "double" instead, and as far as I know that is fine with the ansi standard also, but then you can't use long doubles at all. Mikael |
From: Ioannis V. <no...@ho...> - 2002-06-12 13:02:10
|
> -----Original Message----- > From: Luke Dunstan [mailto:cod...@ho...] > Sent: Wednesday, June 12, 2002 3:57 PM > To: Ioannis Vranos > Cc: mingw-users > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > What is wrong with LDBL_DIG, etc? DBL_DIG = 15 and LDBL_DIG = > 18, which is > correct. Wu Yongwei is simply saying what we originally > suggested: just > don't use %Lf at all with Mingw. He is not suggesting that we > convert long > double to be equivalent to double in representation, and he is not > suggesting ways to make Mingw ANSI compliant. Ok, i thought he did. > Yes, you can configure GCC to make double and long double exactly > equivalent, but if most users want 80 bit long doubles despite the C > runtime, then that is probably how it will stay. Perhaps you > believe that > removing functionality (higher precision) is better than not > having 100% > ANSI compliance, but others believe that is is better to wait, and add > functionality (a new printf) to achieve compliance. It is ANSI compliant, but it is broken. Where is the functionality. i want the functionality to be corrected. > I don't see why you would need to run this to know what it > will produce. On > MSVC we have already established that sizeof(double) == > sizeof(long double), > so of course DBL_DIG *must* be equal to LDBL_DIG, etc. From > everything you > have said, it sounds like you want to make Mingw behave > exactly like MSVC > with respect to long doubles, and if this is true then why > not just say that > from the beginning :) No i want printf(), scanf() etc to work correctly. I do not want a VC++ emulator. :) Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: Ioannis V. <no...@ho...> - 2002-06-12 03:23:17
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Wu Yongwei > Sent: Wednesday, June 12, 2002 5:46 AM > To: MinGW-Users > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > I read this from MSDN: > > In Win32 programming, however, the long double data type maps > to the double, > 64-bit precision data type. The Microsoft run-time library > provides long > double versions of the math functions only for backward > compatibility. The > long double function prototypes are identical to the > prototypes for their > double counterparts, except that the long double data type > replaces the > double data type. The long double versions of these functions > should not be > used in new code. Interesting. > > And I tested using the following code: > > #include <stdio.h> > > int main() > { > long double d; > d = 0.1; > printf("%d\n", sizeof d); > printf("%Lg\n", d); > return 0; > } > > MSVC 6 output: > > 8 > 0.1 > > MinGW GCC output (both 2.95.3-7 and CRTDLL version 2.95.2 19991024): > > 12 > -9.25596e+061 What is the output of sizeof(double) on the same compilers? > > So MinGW was never consistent with MSVC on this point > (luckily we still > could use cout << (long double) d in MinGW). The casting is not needed. > And we can either use only double (consistent with MSVC) or > write our own > printf/fprintf/sprintf/snprintf/.... Or never printf a long > double. This is non-sense. The above mean that the compiler doesn't work correctly with ANSI C/C++ code and thus is broken till it gets fixed even with the conversion of long double to get equivallent with double. I do not know Win32 API but i guess that it refers to not use long double Win32 API functions. It can't refer to ANSI C/C++ code. From the moment that something compiles it should work properly, or to not compile at all (and in the case of ANSI C 89 code to be considered extremelly lame/broken). > For the > current moment, I prefer not to printf a long double. Seldom > are chances to > do that. Well it is your code. I do not use long double usually myself too, but we can't be serious by recommending to not use a built in type at all. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |
From: <dan...@ya...> - 2002-06-12 03:43:04
|
--- Ioannis Vranos <no...@ho...> wrote: > > -----Original Message----- > > From: min...@li... > > [mailto:min...@li...] On Behalf Of > > Wu Yongwei > > Sent: Wednesday, June 12, 2002 5:46 AM > > To: MinGW-Users > > Subject: Re: [Mingw-users] GMINGW GCC 3.1 another defect? > > > > > This is non-sense. The above mean that the compiler doesn't work > correctly with ANSI C/C++ code and thus is broken till it gets fixed > even with the conversion of long double to get equivallent with double. > The GCC compiler works fine with long double (80 bit IEEE padded to 96 bits). The runtime has deficiencies in C99 support. > I do not know Win32 API but i guess that it refers to not use long > double Win32 API functions. It can't refer to ANSI C/C++ code. MSVC does not support long doubles in its runtime nor in w32api. Not at all. Mingw has some runtime support and it is growing. Contributions are welcome. From the > moment that something compiles it should work properly, or to not > compile at all (and in the case of ANSI C 89 code to be considered > extremelly lame/broken). Long double is not in ANSI C89. It is in C99. How many windows compilers support all of C99? > > > > For the > > current moment, I prefer not to printf a long double. Seldom > > are chances to > > do that. > > > Well it is your code. I do not use long double usually myself too, but > we can't be serious by recommending to not use a built in type at all. > I would recommend that someone fix the bug. I hope that doesn't offend anyone. One alternative is that you can pay someone to fix it. I am open to offers. Another alternative is to wait till someone fixes it for you for free. Danny > > Ioannis > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://www.sold.com.au - SOLD.com.au - Find yourself a bargain! |
From: Ioannis V. <no...@ho...> - 2002-06-12 03:50:35
|
> -----Original Message----- > From: Danny Smith [mailto:dan...@ya...] > Sent: Wednesday, June 12, 2002 6:42 AM > To: Ioannis Vranos; 'MinGW-Users' > Subject: RE: [Mingw-users] GMINGW GCC 3.1 another defect? > > > The GCC compiler works fine with long double (80 bit IEEE > padded to 96 bits). > The runtime has deficiencies in C99 support. I am refering both to C89 and C++98 code. No C99 at all. long double x=0.7l /* ... */ printf("%Lf\n", x); is C89 code. > MSVC does not support long doubles in its runtime nor in > w32api. Not at all. I guess you refer to VC++ 6. Welll if it doesn't support printf("%Lf\n", x); is broken concerning C89. > Long double is not in ANSI C89. It is in C99. How many > windows compilers > support all of C99? Of course it is C89. Look your K&R 2. at the back library pages where fprintf() etc are mentioned. Check above the table 7-2 where it mentions the specifier L. I have a Greek K&R so i can not quote exactly in English. :) > I would recommend that someone fix the bug. I hope that > doesn't offend anyone. > One alternative is that you can pay someone to fix it. I am > open to offers. > Another alternative is to wait till someone fixes it for you for free. :)) I think that you are aggressive because you think i am talking about C99 extensions, while it is C89 stuff. Also, personally i do not like C99. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |