This is fantastic news :-)
On 11/02/2011, at 6:58 PM, [email protected] wrote:
> Send Mingw-w64-public mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mingw-w64-public digest..."
> Today's Topics:
>
> 1. PostgreSQL builds with MinGW-w64 (Andrew Dunstan)
> 2. Re: Looking for unsigned __int128 (Sisyphus)
> 3. Re: Looking for unsigned __int128 (Kai Tietz)
> 4. Re: Cross-compile with autoconf (Paul Leder)
> 5. Debugger limitations? (Paul Leder)
> 6. should MINIDUMP_EXCEPTION_INFORMATION be packed? (Joel Dice)
> 7. Re: Looking for unsigned __int128 (Jim Michaels)
>
> From: Andrew Dunstan <[email protected]>
> Date: 11 February 2011 12:27:27 AM AEST
> To: [email protected]
> Subject: [Mingw-w64-public] PostgreSQL builds with MinGW-w64
>
>
> The PostgreSQL project <http://www.postgresql.org/> recently added support
> for building with MinGW-w64.
>
> cheers
>
> andrew
>
>
>
>
>
> From: "Sisyphus" <[email protected]>
> Date: 11 February 2011 3:52:34 AM AEST
> To: "Jim Michaels" <[email protected]>, "mingw64"
> <[email protected]>
> Subject: Re: [Mingw-w64-public] Looking for unsigned __int128
>
>
>
> ----- Original Message ----- From: "Jim Michaels"
>
>> cool! I've been wanting to work with a 128-bit data type for a while now...
>> now I can work with GUIDs easier.
>> is this available under stdint.h as uint128_t and int128_t?
>
> Not in my version (4.6.0 20100414) of the compiler - I can't speak for more
> recent editions.
>
> All I have is the (signed) __int128, and now the (unsigned) __uint128.
> However, I guess I could typedef them to int128_t and uint128_t if I wanted
> to use those symbols instead.
>
> Cheers,
> Rob
>
>
>
>
>
> From: Kai Tietz <[email protected]>
> Date: 11 February 2011 4:21:46 AM AEST
> To: Sisyphus <[email protected]>
> Cc: mingw64 <[email protected]>
> Subject: Re: [Mingw-w64-public] Looking for unsigned __int128
>
>
> 2011/2/10 Sisyphus <[email protected]>:
>>
>> ----- Original Message -----
>> From: "Jim Michaels"
>>
>>> cool! I've been wanting to work with a 128-bit data type for a while
>>> now...
>>> now I can work with GUIDs easier.
>>> is this available under stdint.h as uint128_t and int128_t?
>>
>> Not in my version (4.6.0 20100414) of the compiler - I can't speak for more
>> recent editions.
>>
>> All I have is the (signed) __int128, and now the (unsigned) __uint128.
>> However, I guess I could typedef them to int128_t and uint128_t if I wanted
>> to use those symbols instead.
>>
>> Cheers,
>> Rob
>
> Well, the builtin __int128 type is just available for targets
> supporting wide-enough TImode. For x86 (means 32-bit) this isn't the
> case, and therefore this feature is at the moment just available for
> x64.
> As those aren't standard integers, you won't find them in stdint.h.
> But of couse you can typedef them easily (for 4.6 via builtin, for
> earlier gcc versions via attribute).
>
> For for 4.6 64-bit typedefs are looking that way:
>
> typedef unsigned __int128 uint128_t;
> typedef signed __int128 int128_t;
>
> Regards,
> Kai
>
>
>
>
>
> From: Paul Leder <[email protected]>
> Date: 11 February 2011 9:10:37 AM AEST
> Cc: mingw-w64-public <[email protected]>
> Subject: Re: [Mingw-w64-public] Cross-compile with autoconf
>
>
> Thanks Vincent/Jon - I got it working with just --host.
>
> -Paul
>
>
>
>
>
> From: Paul Leder <[email protected]>
> Date: 11 February 2011 9:24:30 AM AEST
> To: mingw-w64-public <[email protected]>
> Subject: [Mingw-w64-public] Debugger limitations?
>
>
> Should I expect any problems when running gdb/insight on Cygwin, debugging
> cross-compiled binaries?
>
> I'm cross-compiling on Linux (-g -O0), and copying the binaries to Cygwin,
> together with the same source tree that I used on Linux. When I run insight
> on Cygwin, the initial window displays only assembler output. More info:
>
> 1 - Insight can find and display the source files, but can't set a breakpoint
> in the source file (and nor can plain gdb)
>
> 2 - if I change to the same directory as the file that contains main, and run
> 'gdb myprog.exe', it makes no difference. If I enter 'break foo.cc:100' gdb
> replies "No line 100 in file 'foo.cc'".
>
> 3 - The source directory tree on Cygwin is identical to the source directory
> tree on Linux, except that one is rooted at 'C:'. However, if I run 'pwd'
> from the gdb console then the path reported is the Cygwin path, which is
> identical to the Linux path.
>
> 4 - the code definitely has debug info in it - it's much larger than the
> optimised version.
>
> Thanks -
>
> Paul
>
>
>
>
>
> From: Joel Dice <[email protected]>
> Date: 11 February 2011 10:33:28 AM AEST
> To: [email protected]
> Subject: [Mingw-w64-public] should MINIDUMP_EXCEPTION_INFORMATION be packed?
>
>
> Hi all,
>
> My application uses AddVectoredExceptionHandler to register an exception
> handler which, if it can't handle the exception, tries to create a mini dump
> file for later analysis. This involves using MiniDumpWriteDump from
> dbghelp.dll, which accepts a pointer to a MINIDUMP_EXCEPTION_INFORMATION
> instance which wraps the LPEXCEPTION_POINTERS instance provided to the
> exception handler by the OS.
>
> All this works great on 32-bit systems, but crashes on 64-bit ones. To find
> out why, I ran my app in WinDbg and found that code in MiniDumpWriteDump was
> triggering an EXCEPTION_ACCESS_VIOLATION. Tracing through the disassembled
> code revealed that MiniDumpWriteDump is looking for the ExceptionPointers
> field at a four byte offset from the beginning of the
> MINIDUMP_EXCEPTION_INFORMATION instance I passed as a parameter. However, the
> natural alignment of that field is 8 bytes, so GCC added padding after the
> first field (ThreadId) to achieve that alignment.
>
> Once I realized what was happening, I defined my own version of
> MINIDUMP_EXCEPTION_INFORMATION with __attribute__ ((__packed__)) to eliminate
> the padding, and this fixed the crash.
>
> Should MINIDUMP_EXCEPTION_INFORMATION be declared with __attribute__
> ((__packed__)) in dbghelp.h? Are there other structures in that header that
> should be similarly declared?
>
> Thanks.
>
>
>
>
>
> From: Jim Michaels <[email protected]>
> Date: 11 February 2011 6:58:40 PM AEST
> To: mingw64 <[email protected]>
> Subject: Re: [Mingw-w64-public] Looking for unsigned __int128
> Reply-To: Jim Michaels <[email protected]>
>
>
> I see it's in _mingw.h
>
> #ifndef _INT128_DEFINED
> #define _INT128_DEFINED
> #ifdef __GNUC__
> #define __int8 char
> #define __int16 short
> #define __int32 int
> #define __int64 long long
> #ifdef _WIN64
> #ifndef __SIZEOF_INT128__
> typedef int __int128 __attribute__ ((__mode__ (TI)));
> #endif
> #endif
> #endif /* __GNUC__ */
> #endif /* _INT128_DEFINED */
>
> it's not defined for 32 bit target, I wish it were.
>
>
> but it appears that __attribute__ I guess is defined as a comment.
>
> and __mode__ doesn't seem to be defined anywhere.
>
>
>
>
> #include <stdio.h>
> #include <_mingw.h>
> int main(void) {
> __int128 i=170141183460469231731687303715884105727LLLL;
> unsigned __int128 u=340282366920938463463374607431768211455ULLLL;
> printf("i=%I128d\n", i);
> printf(" 170141183460469231731687303715884105727\n"); //for comparison
> printf("u=%I128u\n", u);
> printf(" 340282366920938463463374607431768211455\n"); //for comparison
> return 0;
> }
>
> __int128.cpp:4:16: error: invalid suffix "LLLL" on integer constant
> __int128.cpp:5:25: error: invalid suffix "ULLLL" on integer constant
>
> so I tried one less L...
>
> __int128.cpp:4:16: error: invalid suffix "LLL" on integer constant
> __int128.cpp:5:25: error: invalid suffix "ULLL" on integer constant
>
> 128-bit constants are not allowed in mingw-w64 apparently. they must be
> designed into the language.
>
> I don't know why there isn't a 128-bit data type - there are UUID's on UNIX,
> the MAC, and the equivalent GUID on windows (a 128-bit number).
> seems to me that a 128-bit number would be an ideal storage place for this.
> All you would need is some conversion stuff maybe - I guess that's up the
> programmer.
>
> I am using 4.5.2 sezero.
>
> From: Kai Tietz <[email protected]>
> To: Sisyphus <[email protected]>
> Cc: Jim Michaels <[email protected]>; mingw64
> <[email protected]>
> Sent: Thu, February 10, 2011 10:21:46 AM
> Subject: Re: [Mingw-w64-public] Looking for unsigned __int128
>
> 2011/2/10 Sisyphus <[email protected]>:
> >
> > ----- Original Message -----
> > From: "Jim Michaels"
> >
> >> cool! I've been wanting to work with a 128-bit data type for a while
> >> now...
> >> now I can work with GUIDs easier.
> >> is this available under stdint.h as uint128_t and int128_t?
> >
> > Not in my version (4.6.0 20100414) of the compiler - I can't speak for more
> > recent editions.
> >
> > All I have is the (signed) __int128, and now the (unsigned) __uint128.
> > However, I guess I could typedef them to int128_t and uint128_t if I wanted
> > to use those symbols instead.
> >
> > Cheers,
> > Rob
>
> Well, the builtin __int128 type is just available for targets
> supporting wide-enough TImode. For x86 (means 32-bit) this isn't the
> case, and therefore this feature is at the moment just available for
> x64.
> As those aren't standard integers, you won't find them in stdint.h.
> But of couse you can typedef them easily (for 4.6 via builtin, for
> earlier gcc versions via attribute).
>
> For for 4.6 64-bit typedefs are looking that way:
>
> typedef unsigned __int128 uint128_t;
> typedef signed __int128 int128_t;
>
> Regards,
> Kai
>
> Need Mail bonding?
> Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
