Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

On 8/7/2012 3:06 AM, Kai Tietz wrote: > 2012/8/7 Kyle Schwarz : >> On 8/6/2012 4:58 PM, Kai Tietz wrote: >>> I have attached a modified version of winpthread (uncomress it and >>> rename it back to .dll). It would be great if you could test this >>> variant on your box, too. >> >> Thanks a lot for

Re: [Mingw-w64-public] SEH

2012/8/4 Kai Tietz: > After crt was built and installed, use 'make > all-target-libgcc' and then use 'make install-target-libgcc'. The same error. -- Regards, niXman ___ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://s

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

2012/8/8 Earnie Boyd > On Wed, Aug 8, 2012 at 3:49 PM, Ruben Van Boxem wrote: > > > > Further reduction to (removed unistd.h): > > #define __STDC_FORMAT_MACROS > > #include > > #include > > #include > > #include > > #include > > int main(int argc,char **argv) > > { > >uint64_t val=123456

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

On Wed, Aug 8, 2012 at 3:49 PM, Ruben Van Boxem wrote: > > Further reduction to (removed unistd.h): > #define __STDC_FORMAT_MACROS > #include > #include > #include > #include > #include > int main(int argc,char **argv) > { >uint64_t val=1234567890; >printf("%"PRId64"\n",val); >exit

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

2012/8/8 Kai Tietz > This issue is caused by default of POSIX-printf/scanf for g++. The > reason is that g++ applies to printf/scanf functions two times > formatting rules. One time automagical as system-default, and > secondly as specified by headers. So those warnings are occuring. > This

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

On Wed, Aug 8, 2012 at 3:29 PM, Earnie Boyd wrote: > On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote: >> Found the cause for this. This was caused by dg_qnan.h header ... I >> really should get rid of this gdtoa ... >> >> Revision 5361 fixes this problem. >> >> Thanks for reporting, > > The thanks

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote: > Found the cause for this. This was caused by dg_qnan.h header ... I > really should get rid of this gdtoa ... > > Revision 5361 fixes this problem. > > Thanks for reporting, The thanks belongs to you for fixing it. -- Earnie -- https://sites.go

Re: [Mingw-w64-public] SEH

2012/8/8 niXman > 2012/8/8 Ruben Van Boxem: > > That's not what was implemented. What was implemented is the > > native (MSVC compatible?) Win64 native exception handling. > Why Win64? SEH that, only for Win64 is implemented/works? > > P.S. > Probably my questions seem silly, but I never worked fo

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

2012/8/8 dashesy : > On Wed, Aug 8, 2012 at 11:37 AM, Earnie Boyd > wrote: >> On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote: >>> BTW, this is the line in Wikipedia "64-bit Windows has switched to >>> using position-independent code for DLLs as well and has abandoned >>> relocation" >>> And it refe

Re: [Mingw-w64-public] SEH

2012/8/8 Ruben Van Boxem: > That's not what was implemented. What was implemented is the > native (MSVC compatible?) Win64 native exception handling. Why Win64? SEH that, only for Win64 is implemented/works? P.S. Probably my questions seem silly, but I never worked for windows. Some years I work a

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

On Wed, Aug 8, 2012 at 11:37 AM, Earnie Boyd wrote: > On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote: >> BTW, this is the line in Wikipedia "64-bit Windows has switched to >> using position-independent code for DLLs as well and has abandoned >> relocation" >> And it references here: >> http://msdn

Re: [Mingw-w64-public] SEH

2012/8/8 niXman > I got to build only for x86_64 target. For the i686 - I did not. > I have tested this example: > try { >int* i = 0; >cout << *i << endl; > } catch ( ... ) { >cout << "exception" << endl; > } > > the exception is not caught. > That's not what was implemented. What wa

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

This issue is caused by default of POSIX-printf/scanf for g++. The reason is that g++ applies to printf/scanf functions two times formatting rules. One time automagical as system-default, and secondly as specified by headers. So those warnings are occuring. This might be worth a bug report on g

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

Found the cause for this. This was caused by dg_qnan.h header ... I really should get rid of this gdtoa ... Revision 5361 fixes this problem. Thanks for reporting, Kai -- Live Security Virtual Conference Exclusive live

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

2012/7/11 Simson Garfinkel > When I #include with mingw64-g++ the PRId64 value is no longer > interpreted correctly. > > Here is the test program: > > #define __STDC_FORMAT_MACROS > #include > #include > #include > #include > #include > #include > int main(int argc,char **argv) > { >ui

Re: [Mingw-w64-public] SEH

I got to build only for x86_64 target. For the i686 - I did not. I have tested this example: try { int* i = 0; cout << *i << endl; } catch ( ... ) { cout << "exception" << endl; } the exception is not caught. I have two questions: 1) What kind of SEH was added for WIN platform? How does

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote: > BTW, this is the line in Wikipedia "64-bit Windows has switched to > using position-independent code for DLLs as well and has abandoned > relocation" > And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx For 64 bit binarie

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

On Wed, Aug 8, 2012 at 10:18 AM, Kai Tietz wrote: > 2012/8/8 dashesy : >> Reading the Wikipedia page >> (http://en.wikipedia.org/wiki/Position-independent_code) , it seems >> Windows supports PIC on x64, >> Please correct me if I am wrong. >> I was wondering if I can build PIC dlls on x64. >> This

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

2012/8/8 Earnie Boyd : > On Wed, Aug 8, 2012 at 11:01 AM, Kai Tietz wrote: >> 2012/8/4 Earnie Boyd : >>> I need some math whiz help. So it seems to me that strtod("NAN", >>> NULL) should return the same as __builtin_nan(""). And G++ should >>> return the same result as GCC. For the GCC instance

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

On Wed, Aug 8, 2012 at 11:01 AM, Kai Tietz wrote: > 2012/8/4 Earnie Boyd : >> I need some math whiz help. So it seems to me that strtod("NAN", >> NULL) should return the same as __builtin_nan(""). And G++ should >> return the same result as GCC. For the GCC instance I believe that >> the crt/gd

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

2012/8/8 dashesy : > Reading the Wikipedia page > (http://en.wikipedia.org/wiki/Position-independent_code) , it seems > Windows supports PIC on x64, > Please correct me if I am wrong. > I was wondering if I can build PIC dlls on x64. > This would be specially useful with "--enable-cygwin" to elimin

[Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

Reading the Wikipedia page (http://en.wikipedia.org/wiki/Position-independent_code) , it seems Windows supports PIC on x64, Please correct me if I am wrong. I was wondering if I can build PIC dlls on x64. This would be specially useful with "--enable-cygwin" to eliminate the need to do rebaseall at

Re: [Mingw-w64-public] Packing bug with "unsigned int" bitfields

Hi Simson, the issue isn't the bitfields here and isn't related to the type in first place. The issue is that the __attribute__((pack)) works now only on the outer structure alignment, but doesn't affect the padding between different fields. Please file a bug report to gcc's bugzilla about this.

Re: [Mingw-w64-public] can a statically linked regex be added to fedora mingw32 and mingw64?

On Sun, Jul 29, 2012 at 9:41 PM, Simson Garfinkel wrote: > Greetings. I develop computer forensic tools using mingw64. > > It's very important that these tools be statically linked. > > Would it be possible for the mingw32-libgnurx.noarch and the > mingw64-libgnurx.noarch be expanded to include st

Re: [Mingw-w64-public] Packing bug with "unsigned int" bitfields

On Wed, Aug 8, 2012 at 11:05 AM, Simson Garfinkel wrote: > I've reported a number of bugs on this mailing list. I don't know if that is > the correct way to report them. My bugs aren't getting fixed, so I'm coding > around them, but it would be nice for at least someone to acknowledge > them... T

[Mingw-w64-public] Packing bug with "unsigned int" bitfields

compiler version: i686-w64-mingw32-g++ (GCC) 4.7.0 20120322 (Fedora MinGW 4.7.0-2.fc17) Structures with Bitfields defined as "unsigned int" are not being packed properly. They are being packed properly if the bitfields are defined with "uint8_t". Test program: #include #include struct v1 {

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

2012/8/4 Earnie Boyd : > I need some math whiz help. So it seems to me that strtod("NAN", > NULL) should return the same as __builtin_nan(""). And G++ should > return the same result as GCC. For the GCC instance I believe that > the crt/gdtoa/strtodnrp.c code is wrong. For the G++ instance I >

Re: [Mingw-w64-public] GCC 4.6.3-1-release and Clang 3.1 release by rubenvb

On Wed, Aug 8, 2012 at 5:56 PM, Ruben Van Boxem wrote: > 2012/8/8 Jean-Claude Beaudoin > >> >> >> On Wed, Aug 8, 2012 at 1:39 AM, Dongsheng Song >> wrote: >> >>> I recommend you use '-march=x86-64' instead of '-march=nocona'. >>> >> > I don't see that option listed > here

Re: [Mingw-w64-public] GCC 4.6.3-1-release and Clang 3.1 release by rubenvb

On Wed, Aug 8, 2012 at 5:56 AM, Ruben Van Boxem wrote: > PS: I investigated the implications of the -march=nocona option and it seems > this is unfortunately also passed to runtime libraries. It is not a general > cause for concern; only libgfortran contained 3 calls to an SSE3 > instruction, all t

Re: [Mingw-w64-public] GCC 4.6.3-1-release and Clang 3.1 release by rubenvb

2012/8/8 Jean-Claude Beaudoin > > > On Wed, Aug 8, 2012 at 1:39 AM, Dongsheng Song > wrote: > >> I recommend you use '-march=x86-64' instead of '-march=nocona'. >> > I don't see that option listed here, although my 32-bit GCC 4

Re: [Mingw-w64-public] error: unknown type name 'char_t' in secapi/wmemcpy_s.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.08.2012 07:21, schrieb Kai Tietz: > Sorry, > > I made a typo. Of course it should be wchar_t and not char_t. Issue fixed > at rev.5357. > > Regards, Kai > Thanks! Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment

Re: [Mingw-w64-public] [patch] Add --enable-cygwin to the build system

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.08.2012 09:32, schrieb Corinna Vinschen: > On Aug 7 23:44, Rainer Emrich wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> I think we have the wrong default now. I have to use --disable-w32api to >> get the crt built. Please verify.

Re: [Mingw-w64-public] GCC 4.6.3-1-release and Clang 3.1 release by rubenvb

On Wed, Aug 8, 2012 at 1:39 AM, Dongsheng Song wrote: > I recommend you use '-march=x86-64' instead of '-march=nocona'. > > On Tue, Aug 7, 2012 at 3:24 AM, Ruben Van Boxem > wrote: > > Hi everyone, > > > > I have finished messing up my scripts and fixing them afterwards. I > > bring you another

Re: [Mingw-w64-public] [patch] Add --enable-cygwin to the build system

On Aug 7 23:44, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I think we have the wrong default now. I have to use --disable-w32api to get > the crt built. Please verify. Yes, wrong default. Sorry about that. I fixed that. Corinna ---