headers
Greg Chicares | 1 Jan 2011 02:00
Picon
Favicon

Re: Support for __float128 or quadruple precision?

On 2010-12-31 23:16Z, mbn wrote:
> 
> I have been using the 80-bit precision long double with Mingw under cygwin.
> I can use printf with long doubles when I add the -D__USE_MINGW_ANSI_STDIO
> option:
> 
> x86_64-w64-mingw32-g++.exe -D__USE_MINGW_ANSI_STDIO myfile.cpp
> 
> And it works great. However I now need more precision and don't want to use
> libraries like gmp, because I think that with quadruple precision should be
> enough. My question is: Is there support for __float128 in the current MinGW
> implementation

Yes.

80x87 registers are eighty bits wide, so 'long double' fits the hardware;
__float128 doesn't, so expect it to run an order of magnitude slower.

> (or with other data type for quadruple precision floating
> point numbers)? If so, then:
> 
> - What's the suffix for __float128 literals? For long double it's L (e.g.,
> 1.0L)

'q' or 'Q'. See:
  http://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html

> - Is printf implemented for __float128 variables? If so, what specifier
> should be used?
> - Is the power (pow) and natural logarithm (log) functions implemented? If
(Continue reading)

Permalink | Reply | 2 comments |
headers
mbn | 1 Jan 2011 04:39
Picon

printf with -D__USE_MINGW_ANSI_STDIO, and fstream


Hi,

I am able to display long double values with printf if I use the compilation
flag 
-D__USE_MINGW_ANSI_STDIO. 

However, if I also include <fstream> in my program, then printf does not
display long double values correctly anymore. I even tried using ::printf,
but still the same result. It's enough that <fstream> be included for this
issue to happen. 

For instance, the program below outputs 3.645200e-4951, but if I include
fstream then the result is 1.133047e-317

How can I avoid this? I want to use the version of printf that outputs the
correct result

Thanks in advance

P.S. including the flags -ansi or -posix does not make any difference. As
long as I include fstream I can't output long double values correctly

////////////////////////////////////////////////////////////////////////////////////
/* Compile under cygwin with this command line

x86_64-w64-mingw32-g++.exe -D__USE_MINGW_ANSI_STDIO  test_fstream.cpp -o
test_fstream && ./test_fstream.exe

*/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Zellhofer | 1 Jan 2011 09:47
Picon

Re: Support for __float128 or quadruple precision?

Greg Chicares wrote:
> On 2010-12-31 23:16Z, mbn wrote:
>> I have been using the 80-bit precision long double with Mingw under cygwin.
>> I can use printf with long doubles when I add the -D__USE_MINGW_ANSI_STDIO
>> option:
>>
>> x86_64-w64-mingw32-g++.exe -D__USE_MINGW_ANSI_STDIO myfile.cpp
>>
>> And it works great. However I now need more precision and don't want to use
>> libraries like gmp, because I think that with quadruple precision should be
>> enough. My question is: Is there support for __float128 in the current MinGW
>> implementation
> 
> Yes.
> 
> 80x87 registers are eighty bits wide, so 'long double' fits the hardware;
> __float128 doesn't, so expect it to run an order of magnitude slower.

Would the use of SSE fit his needs?
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
read -mfpmath description
http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

> 
>> (or with other data type for quadruple precision floating
>> point numbers)? If so, then:
>>
>> - What's the suffix for __float128 literals? For long double it's L (e.g.,
>> 1.0L)
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Brown | 1 Jan 2011 19:30
Picon
Favicon

Re: --enable-auto-import

Chris Sutcliffe <ir0nh34d <at> ...> writes:

> 
> On 4 December 2010 23:39, Simson Garfinkel wrote:
> > I've tried searching for this in the archives of the mailing list but
> > couldn't find it.
> > I finally got my program to compile and link. Unfortunately I'm getting
> > these weird errors about auto-import.  I've tried adding the
> > "--enable-auto-import" to my link flags and it doesn't make the errors go
> > away. When I add --enable-auto-import to my CXXFLAGS or CPPFLAGS, the
> > configure script fails.
> > Any ideas?
> 
> Try: -Wl,--enable-auto-import
> 
> Chris
> 

-Wl,--enable-auto-import makes the warning go away, but the underlying
issue is that the .o file contains names like __ZSt4cout and is being
linked to an import library that contains names like __imp___ZSt4cout.

Surely it is a bug if my simple C++ program

#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
  cout << "Hello, world!" << endl;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helfer Thomas | 2 Jan 2011 15:08
Picon
Favicon

cross-compiling a dll on linux : fail to use --kill-at or --add-stdcall-alias options correctly

I feel sorry to annoy you with a question that seems to have been
largely documented by I did not get it working.

I am trying to cross-compile a dll on linux. I am using mingw on ubuntu
lucid lynx :

586-mingw32msvc-g++ --version
i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2)
Copyright © 2007 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de copie.
Il n'y a PAS
GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.

The basic test is to create a dll and load it through
LoadLibrary/GetProcAddress using a simple program ran through wine.

The dll contains the following function, declared with __stdcall calling
convention for VB compatibility :

#include<iostream>

extern "C" {

  __declspec(dllexport) void __stdcall test(void)
  {
    using namespace std;
    cout << "Hello from c++" << endl;
  }

}
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kai Tietz | 2 Jan 2011 15:34

Re: cross-compiling a dll on linux : fail to use --kill-at or --add-stdcall-alias options correctly

Hello Thomas,

2011/1/2 Helfer Thomas <helferthomas@...>:
> I feel sorry to annoy you with a question that seems to have been
> largely documented by I did not get it working.
>
> As you may have understood, I want to get rid of the  <at> 0 decoration. I
> tried the following command without success:
>
>  i586-mingw32msvc-g++ --shared -Wl,-no-undefined -Wl,--add-stdcall-alias
> -Wl,--kill-all test.cxx -o libtest.dll

is this kill-all here a typo? AFAIK it should be the option -Wl,-kill-at

Regards,
Kai

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tor Lillqvist | 2 Jan 2011 17:08
Picon
Picon
Favicon

Re: cross-compiling a dll on linux : fail to use --kill-at or --add-stdcall-alias options correctly

> i586-mingw32msvc-nm libtest.dll | grep test

nm doesn't show the symbols *exported* from a DLL (which is what VB,
or another importer of the DLL, would be looking at). Use pexports or
objdump to see the exported symbols. (The --kill-at option will affect
those symbols, AFAICR.)

What nm shows for a DLL is the optional informational symbol table.

--tml

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
(Continue reading)

Permalink | Reply | 1 comment |
headers
Helfer Thomas | 2 Jan 2011 20:41
Picon
Favicon

Re: cross-compiling a dll on linux : fail to use --kill-at or --add-stdcall-alias options correctly

Thanks for the advice, it showed me that a was searching the wrong way. 

The example I gave was a simplification of my true problem which implied
libtool. All now works (although I don't know what was wrong).

Helfer Thomas

Le dimanche 02 janvier 2011 à 18:08 +0200, Tor Lillqvist a écrit :
> > i586-mingw32msvc-nm libtest.dll | grep test
> 
> nm doesn't show the symbols *exported* from a DLL (which is what VB,
> or another importer of the DLL, would be looking at). Use pexports or
> objdump to see the exported symbols. (The --kill-at option will affect
> those symbols, AFAICR.)
> 
> What nm shows for a DLL is the optional informational symbol table.
> 
> --tml
> 
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and, 
> should the need arise, upgrade to a full multi-node Oracle RAC database 
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> MinGW-users mailing list
> MinGW-users <at> lists.sourceforge.net
> 
> This list observes the Etiquette found at
(Continue reading)

Permalink | Reply | 0 comments |
headers
zwz | 3 Jan 2011 15:59
Picon

mintty does not get the right $HOME changed in profile

Hi,

I modified the /etc/profile so that HOME is set to /home.

I start "msys.bat -mintty", but mintty still tries to read/write
/home/≤user>/.minttyrc.

I think this is a bug.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe
Permalink | Reply | 2 comments |
headers
mbn | 3 Jan 2011 19:20
Picon

Re: printf with -D__USE_MINGW_ANSI_STDIO, and fstream


Can anybody please shed light on this issue?

Thanks,

Mark

mbn wrote:
> 
> Hi,
> 
> I am able to display long double values with printf if I use the
> compilation flag 
> -D__USE_MINGW_ANSI_STDIO. 
> 
> However, if I also include <fstream> in my program, then printf does not
> display long double values correctly anymore. I even tried using ::printf,
> but still the same result. It's enough that <fstream> be included for this
> issue to happen. 
> 
> For instance, the program below outputs 3.645200e-4951, but if I include
> fstream then the result is 1.133047e-317
> 
> How can I avoid this? I want to use the version of printf that outputs the
> correct result
> 
> Thanks in advance
> 
> P.S. including the flags -ansi or -posix does not make any difference. As
> long as I include fstream I can't output long double values correctly
(Continue reading)

Permalink | Reply | 1 comment |

Gmane