From: <dan...@ya...> - 2001-12-01 06:18:30
|
An interesting patch submission to binutils from the ReactOS team: [PATCH] PE image checksum http://sources.redhat.com/ml/binutils/2001-11/msg00763.html Danny http://shopping.yahoo.com.au - Yahoo! Shopping - Get organised for Christmas early this year! |
From: <dan...@ya...> - 2002-07-20 22:59:21
|
Given the new GCC development plan, viz: GCC 3.1 Stage 3 (ends Feb 15 2002) GCC 3.0.4 release (Feb 20 2001) | +-- GCC 3.1 branch created ------+ | \ | v v GCC 3.1 release (May 15 2002) GCC 3.2 Stage 1 (ends Jun 15 2002) \ | v | GCC 3.1.1 release (Jul 21 2002) | \ v v New development plan announced Branch renamed to GCC 3.2 to | (Jul 14 2002) accomodate for C++ ABI fixes | (C++ binary incompatible with | GCC 3.1, see release info) | \ | v | GCC 3.2 release (Jul 23 2002) I do not think a release of 3.1.1 for mingw is warranted, particuarly because of binary incompatability beteen 3.1.1 and and 3.2+. Thus, I plan to upload next mingw release candidate when 3.2 hits the rubber highway. Of course, if anyone else wants to do something different, go for it. Danny http://www.sold.com.au - SOLD.com.au - Find yourself a bargain! |
From: Christopher F. <cg...@re...> - 2002-07-20 23:18:42
|
On Sun, Jul 21, 2002 at 08:59:21AM +1000, Danny Smith wrote: >Given the new GCC development plan, viz: > > >GCC 3.1 Stage 3 (ends Feb 15 2002) GCC 3.0.4 release (Feb 20 2001) > | > +-- GCC 3.1 branch created ------+ > | \ > | v > v GCC 3.1 release (May 15 2002) > GCC 3.2 Stage 1 (ends Jun 15 2002) \ > | v > | GCC 3.1.1 release (Jul 21 2002) > | \ > v v > New development plan announced Branch renamed to GCC 3.2 to > | (Jul 14 2002) accomodate for C++ ABI fixes > | (C++ binary incompatible with > | GCC 3.1, see release info) > | \ > | v > | GCC 3.2 release (Jul 23 2002) > > > >I do not think a release of 3.1.1 for mingw is warranted, particuarly because >of binary incompatability beteen 3.1.1 and and 3.2+. > >Thus, I plan to upload next mingw release candidate when 3.2 hits the rubber >highway. I've recently announced similar intentions for cygwin, FWIW. cgf |
From: Ranjit M. <rm...@ho...> - 2003-02-11 19:31:04
|
Hi, How does one run the GCC testsuites on Windows? It essentially boils down to getting dejagnu/expect for Windows, I think. Danny, what do you use? Do you use the Cygwin tools? Does anyone know of *native* dejagnu for Windows? I couldn't find such a beast anywhere. Thanks for your help in advance. Ranjit. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Danny S. <dan...@cl...> - 2003-02-11 19:52:14
|
----- Original Message ----- From: "Ranjit Mathew" <rm...@ho...> To: <min...@li...> Sent: Tuesday, 11 February 2003 19:30 Subject: [MinGW-dvlpr] (no subject) > Hi, > > How does one run the GCC testsuites on Windows? It essentially boils > down to getting dejagnu/expect for Windows, I think. Danny, what do you > use? Do you use the Cygwin tools? Yes. That is one of the many reasons I've stuck with cygwin environment for building mingw tools. Does anyone know of *native* dejagnu > for Windows? I couldn't find such a beast anywhere. > Not I. Danny > Thanks for your help in advance. > > Ranjit. > > > > > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Kai T. <Kai...@on...> - 2006-09-21 15:09:48
|
Hallo all, I want to start the discussion for the new target mingw64. As I begun to make an private gcc port to mingw64 (for AMD64) and a non external prototype of necessary include files, I noticed, that in my opinion the following issues can be a good starting point for further discussions Which targets for mingw64 we will support ? - AMD64 (x86_64) target (now supported by binutils) - IA64 target (currently unsupport by binutils) Differences between the MSVCI and the gcc 1) Types and their sizes MS declares "long int" as 4 byte integer, but gcc uses 8 bytes. (which - as I think - is the proper size for this type). MS introduced the "long long" as 8 byte integer, but may it is better declare it as 16 byte integer for gcc (larger than a unsigned long) for an equivalent of __int128. MS declared the "long double" equivalent to a "double", which the gcc does not. The other MS specific types "__int???" are more defines and therefore of less interrest. 2) The fastcall register operations for AMD64 The fastcall issues is quite equivalent to the old behaviour, except that additionally the rd8 & rd9 registers are used for argument passing too. 3) Fastcalled wildcard argument treating for AMD64 in msvcrt The exported methods of the msvcrt are using registers for passing wildcard arguments as I noticed by reading MSVC produced assembly. 4) The exception handling May it would be worth to introduce the SIB exception handling supported by the native OS itself. There are new pragma-commands introduced by MS, which have no equivalent to gcc-world. How to treat them ? E.g. MS introduced the "#pragma push_macro() " and "#pragma pop_macro()" preprocessor statement, which may is worth to be introduced into gcc, too. The manifest support for MS owned and new generated DLL's and executables Application using the MS-Runtime DLL have to bring a manifest-file on disc or as linked resource to work proper. What's about managed code in mixed mode ? I think, this part should be ignored. Regards, i.A. Kai Tietz |
From: Luke D. <cod...@ho...> - 2006-09-22 16:47:22
|
----- Original Message ----- From: "Kai Tietz" <Kai...@on...> To: <min...@li...> Sent: Thursday, September 21, 2006 11:08 PM Subject: [MinGW-dvlpr] (no subject) > Hallo all, > > I want to start the discussion for the new target mingw64. As I begun to > make an private gcc port to mingw64 (for AMD64) and a non external > prototype of necessary include files, I noticed, that in my opinion the > following issues can be a good starting point for further discussions > > Which targets for mingw64 we will support ? > - AMD64 (x86_64) target (now supported by binutils) > - IA64 target (currently unsupport by binutils) > > Differences between the MSVCI and the gcc > 1) Types and their sizes > MS declares "long int" as 4 byte integer, but gcc uses 8 > bytes. (which - as I think - is the proper size for this type). If mingw64 used different integer sizes to the MS 64-bit compiler then surely that would make it binary-incompatible, so how could you successfully link a program compiled with mingw64 with the Windows 64-bit system DLLs? Luke > MS introduced the "long long" as 8 byte integer, but may > it is better declare it as 16 byte integer for gcc (larger than a unsigned > long) for an equivalent of __int128. > MS declared the "long double" equivalent to a "double", > which the gcc does not. > The other MS specific types "__int???" are more defines > and therefore of less interrest. > 2) The fastcall register operations for AMD64 > The fastcall issues is quite equivalent to the old > behaviour, except that additionally the rd8 & rd9 registers are used for > argument passing too. > 3) Fastcalled wildcard argument treating for AMD64 in msvcrt > The exported methods of the msvcrt are using registers for > passing wildcard arguments as I noticed by reading MSVC produced assembly. > 4) The exception handling > May it would be worth to introduce the SIB exception > handling supported by the native OS itself. > > There are new pragma-commands introduced by MS, which have no equivalent > to gcc-world. How to treat them ? > E.g. MS introduced the "#pragma push_macro() " and "#pragma > pop_macro()" preprocessor statement, which may is worth to be introduced > into gcc, too. > > The manifest support for MS owned and new generated DLL's and executables > Application using the MS-Runtime DLL have to bring a manifest-file > on disc or as linked resource to work proper. > > What's about managed code in mixed mode ? > I think, this part should be ignored. > > Regards, > i.A. Kai Tietz |
From: Kai T. <Kai...@on...> - 2006-09-25 08:30:45
|
The ABI compabitility is done by type changes of the MS-ABI for the gcc-ABI. Reasoned by the fact, that x86_64 stack-layout is 8 byte oriented, each parameter is passed within a 8 byte word on both ABI's. This ease things a little bit. The following translation rules for types I've used: MS-type GCC-type Remarks void void void * void * Pointers have equal size of 8 bytes for both ABI's char char short short int int long int Both type sizes are 4 bytes long, may an define or typedef will help to make clear, that this is in MS world an long. long long long Both types have sizes of 4 bytes long. __int8 char __int16 short __int32 int __int64 long The type "__int64" is used by MS-ABI as pointer difference integer [e.G. (((char *)p-(char*)0)==(__int64)p) ] __int128 long long Both types The other possibility would be to set-up gcc fully type compliant to MS. But that mean we have to introduce a new type as __int128 for gcc, because than a "long long" of gcc has to be just 8 bytes long. Cheers, i.A. Kai Tietz |
From: Luke D. <cod...@ho...> - 2006-09-25 15:46:49
|
----- Original Message ----- From: "Kai Tietz" <Kai...@on...> To: "MinGW Devlopers Discussion List" <min...@li...> Cc: "MinGW Devlopers Discussion List" <min...@li...> Sent: Monday, September 25, 2006 4:29 PM Subject: Re: [MinGW-dvlpr] (no subject) > The ABI compabitility is done by type changes of the MS-ABI for the > gcc-ABI. Reasoned by the fact, that x86_64 stack-layout is 8 byte > oriented, each parameter is passed within a 8 byte word on both ABI's. > This ease things a little bit. Correct me if I'm wrong but I think there will still be major incompatibilities. If one developer creates a Win64 DLL using MSVC and then another developer tries to link it with an .exe built using mingw64 then it may or may not fail at runtime depending on what types they use. Consider such a DLL with the following header file: int foo(long long x); void bar(long *p); When the .exe calls foo() it will pass 16 bytes but the DLL will be expecting 8 bytes. When the .exe calls bar() the DLL will only access the lower 32-bits of the 64-bit long. Some people won't need to call third party DLLs (or static libraries) that use ISO C types but I think *many* will, and it is unreasonable to expect them to hack the header files. For these reasons I think that mingw64 needs to keep compatibility with MSVC (including providing a 128-bit integer type). Luke > > The following translation rules for types I've used: > MS-type GCC-type Remarks > void void > void * void * Pointers have equal size > of 8 bytes for both ABI's > char char > short short > int int > long int Both type sizes are 4 > bytes long, may an define or typedef will help to make clear, that this is > in MS world an long. > long long long Both types have sizes of 4 > bytes long. > __int8 char > __int16 short > __int32 int > __int64 long The type "__int64" is used > by MS-ABI as pointer difference integer [e.G. (((char > *)p-(char*)0)==(__int64)p) ] > __int128 long long Both types > > The other possibility would be to set-up gcc fully type compliant to MS. > But that mean we have to introduce a new type as __int128 for gcc, because > than a "long long" of gcc has to be just 8 bytes long. > > Cheers, > i.A. Kai Tietz |
From: Kai T. <Kai...@on...> - 2006-09-26 07:37:14
|
Luke wrote: > Correct me if I'm wrong but I think there will still be major > incompatibilities. If one developer creates a Win64 DLL using MSVC and then > another developer tries to link it with an .exe built using mingw64 then it > may or may not fail at runtime depending on what types they use. Consider > such a DLL with the following header file: > > int foo(long long x); > void bar(long *p); > > When the .exe calls foo() it will pass 16 bytes but the DLL will be > expecting 8 bytes. When the .exe calls bar() the DLL will only access the > lower 32-bits of the 64-bit long. Yes, that true, but the major problem is the ISO definition of the pointer difference, which lead to a long type. What implicit means, that a long needs to have the same size as a pointer itself. Even MS reflect this by defining intptr_t to an __int64 type. The example would be still proper if we recomment, that users are using the windows type definitions as LONG, or LONGLONG instead of using ISO-C types. Because these types can be handled by header definitions. Eg. The header would than look like: int foo(LONGLONG x); void bar(LONG *p); If we change the ISO-C type "long", it means that programmer needs to learn that pointer differences are "__int64" not "long", which for my opinion looks more worse. The "long long" type now introduced also by MS, has the definition to be bigger than the largest architecture interger. Of course, we can define it as a 8 byte word, but again it looks for me as an ISO violation. > Some people won't need to call third party DLLs (or static libraries) that > use ISO C types but I think *many* will, and it is unreasonable to expect > them to hack the header files. For these reasons I think that mingw64 needs > to keep compatibility with MSVC (including providing a 128-bit integer > type). Even MS mentioned for there type size definitions the reason, that it is more a period issue to avoid problems on porting to the new architecture and a lot of standard methods will move in future versions to 64-bit typed arguments and return values. This will inflict to many coders the need to rewrite and rethink there usage of types, too. If we make a "long" 4 bytes, a "long long" 8 bytes, we have to define a new type for the 16 byte type "__int128" ("long long long" ?:) ) and do the integer arithmetics and optimizations in gcc for it. Also I assume that it is getting hardly introduced into the mainline of gcc, but may I am wrong. Regards, i.A. Kai Tietz WWW: http://www.OneVision.com |
From: Greg C. <chi...@co...> - 2006-09-26 12:40:36
|
On 2006-9-26 7:36 UTC, Kai Tietz wrote: > > [...] the major problem is the ISO definition of the pointer > difference, which lead to a long type. What implicit means, that a long > needs to have the same size as a pointer itself. Even MS reflect this by > defining intptr_t to an __int64 type. The C standard, ISO/IEC 9899, says at 6.5.6/9 When two pointers are subtracted, [...] the size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t 6.2.5/4 defines signed integer types to include implementation- defined extended types. Thus, ptrdiff_t does not need to be the same as long int. > If we change the ISO-C type "long", it means that programmer needs to > learn that pointer differences are "__int64" not "long", which for my > opinion looks more worse. Programmers should use ptrdiff_t directly, and not assume that it's the same as any particular type. |
From: <ja...@so...> - 2007-05-25 04:56:38
|
On Wednesday 23 May 2007 14:04, Earnie Boyd wrote: > Currently the static page input filter is set to filtered HTML. I am > thinking that maybe we should change the format to DocuWiki filtering > for consistency. So we write [[http://sample.org/do.php?my_sample|my > sample]] instead of <a href="http://sample.org/do.php?my_sample>my > sample</a>. Comments? I personally hate Wiki formats, but then again I never properly put any effort into learning them. --Jason Craig |
From: Keith M. <kei...@us...> - 2007-05-25 18:00:38
|
On Friday 25 May 2007 05:56, ja...@so... wrote: > On Wednesday 23 May 2007 14:04, Earnie Boyd wrote: > > Currently the static page input filter is set to filtered HTML. I > > am thinking that maybe we should change the format to DocuWiki > > filtering for consistency. So we write > > [[http://sample.org/do.php?my_sample|my sample]] instead of <a > > href="http://sample.org/do.php?my_sample>my sample</a>. Comments? > > I personally hate Wiki formats, So do I. > but then again I never properly put any effort into learning them. Each is different from the next, without even the slightest attempt to implement a standard. Porting phpwiki to docuwiki is a pain; link syntax is incompatible, with link-name and address fields in reverse order; (a bit of sed scripting helps). Worse still, I'm even finding that the dokuwiki syntax doesn't behave as it "says on the tin". At least with HTML, we have a standard to aim for, (not that I am in any way expert in coding for it, and I wish it could do better typographic control). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-05-25 21:34:50
|
Quoting Keith Marshall <kei...@us...>: > On Friday 25 May 2007 05:56, ja...@so... wrote: >> On Wednesday 23 May 2007 14:04, Earnie Boyd wrote: >> > Currently the static page input filter is set to filtered HTML. I >> > am thinking that maybe we should change the format to DocuWiki >> > filtering for consistency. So we write >> > [[http://sample.org/do.php?my_sample|my sample]] instead of <a >> > href="http://sample.org/do.php?my_sample>my sample</a>. Comments? >> >> I personally hate Wiki formats, > > So do I. > >> but then again I never properly put any effort into learning them. > > Each is different from the next, without even the slightest attempt to > implement a standard. Porting phpwiki to docuwiki is a pain; link > syntax is incompatible, with link-name and address fields in reverse > order; (a bit of sed scripting helps). Worse still, I'm even finding > that the dokuwiki syntax doesn't behave as it "says on the tin". > > At least with HTML, we have a standard to aim for, (not that I am in any > way expert in coding for it, and I wish it could do better typographic > control). > I am going to play with some of the filters that allow me to ignore some tags within the current input type next week. I'm thinking that maybe we could have the best of both worlds. I'll let you know what I find out. Earnie |
From: Alexey P. <ale...@gm...> - 2013-01-16 15:03:56
|
al...@gm... |
From: Earnie B. <ea...@us...> - 2013-01-16 17:38:20
|
On Wed, Jan 16, 2013 at 10:03 AM, Alexey Pavlov wrote: > alexpux@g... I assume you mean you wish to be subscribed via this address or do you want both? -- Earnie -- https://sites.google.com/site/earnieboyd |