www.digitalmars.com         C & C++   DMDScript  

D.gnu - Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4

reply Daniel Green <venix1 gmail.com> writes:
Please post all issues in D.gnu or on GDC's site 
https://bitbucket.org/goshawk/gdc

Due to the use of a newer runtime than TDM64-GCC it is **recommended** 
to install a copy specifically for GDC.

Features
  * binutils with TLS patches
  * mingw-w64-runtime with TLS and stdio fixes.
  * GCC 4.6.1 with TLS patches
  * Both D1 and D2 compilers.  D2 invoked by default.
    * -v1 Compiles with D1.  Must be used in linking stage as well.
    * -v2 Compiles with D2.  Must be used in linking stage as well.

MinGW64 installer
http://tdm-gcc.tdragon.net/

GDC binary
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232cd89d90b4-20120128.7z

Known issues:
  * May break TDM64 C++.
  * Field-less structs will throw a null this exception.  When formatted 
by std.format.  runnable/test23.d

---

For the time, MinGW32 binaries will not be provided.  MinGW64 is built 
as a 32-bit binary that allows use on 32-bit Windows.  GDC requires 
patches to binutils and the MinGW runtime to function properly.  Until 
those patches make it into their official repositories only MinGW64 will 
be released.
Jan 28 2012
next sibling parent reply Sönke Ludwig <sludwig_sp niksoftware.com> writes:
== Auszug aus Daniel Green (venix1 gmail.com)'s Artikel
 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc
 Due to the use of a newer runtime than TDM64-GCC it is **recommended**
 to install a copy specifically for GDC.
 Features
   * binutils with TLS patches
   * mingw-w64-runtime with TLS and stdio fixes.
   * GCC 4.6.1 with TLS patches
   * Both D1 and D2 compilers.  D2 invoked by default.
     * -v1 Compiles with D1.  Must be used in linking stage as well.
     * -v2 Compiles with D2.  Must be used in linking stage as well.
 MinGW64 installer
 http://tdm-gcc.tdragon.net/
 GDC binary

 Known issues:
   * May break TDM64 C++.
   * Field-less structs will throw a null this exception.  When formatted
 by std.format.  runnable/test23.d
 ---
 For the time, MinGW32 binaries will not be provided.  MinGW64 is built
 as a 32-bit binary that allows use on 32-bit Windows.  GDC requires
 patches to binutils and the MinGW runtime to function properly.  Until
 those patches make it into their official repositories only MinGW64 will
 be released.

== Auszug aus Daniel Green (venix1 gmail.com)'s Artikel
 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc
 Due to the use of a newer runtime than TDM64-GCC it is **recommended**
 to install a copy specifically for GDC.
 Features
   * binutils with TLS patches
   * mingw-w64-runtime with TLS and stdio fixes.
   * GCC 4.6.1 with TLS patches
   * Both D1 and D2 compilers.  D2 invoked by default.
     * -v1 Compiles with D1.  Must be used in linking stage as well.
     * -v2 Compiles with D2.  Must be used in linking stage as well.
 MinGW64 installer
 http://tdm-gcc.tdragon.net/
 GDC binary

 Known issues:
   * May break TDM64 C++.
   * Field-less structs will throw a null this exception.  When formatted
 by std.format.  runnable/test23.d
 ---
 For the time, MinGW32 binaries will not be provided.  MinGW64 is built
 as a 32-bit binary that allows use on 32-bit Windows.  GDC requires
 patches to binutils and the MinGW runtime to function properly.  Until
 those patches make it into their official repositories only MinGW64 will
 be released.

Most cases work for me now. Only the LoadLibrary+DllMain tests still produce a status 988 (access violation in dll_process_attach...dll_fixTLS or rt.lifetime.__getBlkInfo if Runtime.initialize is used instead). It also links now without the manual _tls_callbacks_a definition (_tlsstart and _tlsend in plaindll.d is still needed or it will crash during initialization). Btw. many thanks for your commitment to the Windows gdc version. It currently the only working 64-bit/Windows solution and I'm working on a D project for my company that absolutely needs to support 64-bit - it would not be possible otherwise.
Jan 30 2012
parent Daniel Green <venix1 gmail.com> writes:
On 1/30/2012 5:34 AM, Sönke Ludwig wrote:
 Most cases work for me now. Only the LoadLibrary+DllMain tests still produce a
 status 988 (access violation in dll_process_attach...dll_fixTLS or
 rt.lifetime.__getBlkInfo if Runtime.initialize is used instead). It also links
now
 without the manual _tls_callbacks_a definition (_tlsstart and _tlsend in
 plaindll.d is still needed or it will crash during initialization).

failing? Try using MinGW64 to compile the 32-bit tests. Going forward it's the only release I'll be doing. It can generate 32 and 64-bit code and is usable on 32-bit Windows. echo "== Testing 32 bit ==" GCC="x86_64-w64-mingw32-gcc.exe -m32" GDC="x86_64-w64-mingw32-gdc.exe -m32" perform_test echo echo "== Testing 64 bit ==" GCC="x86_64-w64-mingw32-gcc.exe -m64" GDC="x86_64-w64-mingw32-gdc.exe -m64" perform_test
Jan 30 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
You guys rock!

This should be on dlang.org someplace.
Jan 30 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, Jan 28, 2012 at 8:46 AM, Daniel Green <venix1 gmail.com> wrote:
 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc

 Due to the use of a newer runtime than TDM64-GCC it is **recommended** to
 install a copy specifically for GDC.

 Features
 =A0* binutils with TLS patches
 =A0* mingw-w64-runtime with TLS and stdio fixes.
 =A0* GCC 4.6.1 with TLS patches
 =A0* Both D1 and D2 compilers. =A0D2 invoked by default.
 =A0 * -v1 Compiles with D1. =A0Must be used in linking stage as well.
 =A0 * -v2 Compiles with D2. =A0Must be used in linking stage as well.

 MinGW64 installer
 http://tdm-gcc.tdragon.net/

 GDC binary
 https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232cd89=

 Known issues:
 =A0* May break TDM64 C++.
 =A0* Field-less structs will throw a null this exception. =A0When formatt=

 std.format. =A0runnable/test23.d

 ---

 For the time, MinGW32 binaries will not be provided. =A0MinGW64 is built =

 32-bit binary that allows use on 32-bit Windows. =A0GDC requires patches =

 binutils and the MinGW runtime to function properly. =A0Until those patch=

 make it into their official repositories only MinGW64 will be released.

I'm seeing a consistent hang on a multithreaded application that runs under GDC on Linux. It seems to be hanging on startup shortly after it starts a thread (which is odd because this is the second thread it starts, not the first). GDB shows that the original thread and the first thread started are in ntdll!ZwWriteVirtualMemory and the new thread is in KERNEL32!CtrlRoutine, but it doesn't show any functions from my program in the backtrace, which makes me suspicious. (the main thread shows unidentifiable functions in the backtrace and causes GDB to emit internal error warnings when trying to print said backtrace) I initially thought it might be GC related, but runniing GC.disable() on startup doesn't seem to have any effect. Is this known, or should I copy/paste a bunch of GDB output and file a bug?
Feb 09 2012
prev sibling next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Thu, Feb 9, 2012 at 10:25 AM, Andrew Wiley <wiley.andrew.j gmail.com> wr=
ote:
 On Sat, Jan 28, 2012 at 8:46 AM, Daniel Green <venix1 gmail.com> wrote:
 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc

 Due to the use of a newer runtime than TDM64-GCC it is **recommended** t=


 install a copy specifically for GDC.

 Features
 =A0* binutils with TLS patches
 =A0* mingw-w64-runtime with TLS and stdio fixes.
 =A0* GCC 4.6.1 with TLS patches
 =A0* Both D1 and D2 compilers. =A0D2 invoked by default.
 =A0 * -v1 Compiles with D1. =A0Must be used in linking stage as well.
 =A0 * -v2 Compiles with D2. =A0Must be used in linking stage as well.

 MinGW64 installer
 http://tdm-gcc.tdragon.net/

 GDC binary
 https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232cd8=


 Known issues:
 =A0* May break TDM64 C++.
 =A0* Field-less structs will throw a null this exception. =A0When format=


 std.format. =A0runnable/test23.d

 ---

 For the time, MinGW32 binaries will not be provided. =A0MinGW64 is built=


 32-bit binary that allows use on 32-bit Windows. =A0GDC requires patches=


 binutils and the MinGW runtime to function properly. =A0Until those patc=


 make it into their official repositories only MinGW64 will be released.

I'm seeing a consistent hang on a multithreaded application that runs under GDC on Linux. It seems to be hanging on startup shortly after it starts a thread (which is odd because this is the second thread it starts, not the first). GDB shows that the original thread and the first thread started are in ntdll!ZwWriteVirtualMemory and the new thread is in KERNEL32!CtrlRoutine, but it doesn't show any functions from my program in the backtrace, which makes me suspicious. (the main thread shows unidentifiable functions in the backtrace and causes GDB to emit internal error warnings when trying to print said backtrace) I initially thought it might be GC related, but runniing GC.disable() on startup doesn't seem to have any effect. Is this known, or should I copy/paste a bunch of GDB output and file a bu=

Probably more interestingly, I don't know where that third thread is coming from. I only ever start two in my program at the moment. I can also just stuff the program source onto Github. It's not closed sourc= e.
Feb 09 2012
parent reply Daniel Green <venix1 gmail.com> writes:
If you could post the source and a link to it I'd be happy to take a 
look.  Also bug reports are always welcomed especially when accompanied 
by reduced testcases ;)


On 2/9/2012 11:34 AM, Andrew Wiley wrote:
 On Thu, Feb 9, 2012 at 10:25 AM, Andrew Wiley<wiley.andrew.j gmail.com>  wrote:
 On Sat, Jan 28, 2012 at 8:46 AM, Daniel Green<venix1 gmail.com>  wrote:
 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc

 Due to the use of a newer runtime than TDM64-GCC it is **recommended** to
 install a copy specifically for GDC.

 Features
   * binutils with TLS patches
   * mingw-w64-runtime with TLS and stdio fixes.
   * GCC 4.6.1 with TLS patches
   * Both D1 and D2 compilers.  D2 invoked by default.
    * -v1 Compiles with D1.  Must be used in linking stage as well.
    * -v2 Compiles with D2.  Must be used in linking stage as well.

 MinGW64 installer
 http://tdm-gcc.tdragon.net/

 GDC binary
 https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232cd89d90b4-20120128.7z

 Known issues:
   * May break TDM64 C++.
   * Field-less structs will throw a null this exception.  When formatted by
 std.format.  runnable/test23.d

 ---

 For the time, MinGW32 binaries will not be provided.  MinGW64 is built as a
 32-bit binary that allows use on 32-bit Windows.  GDC requires patches to
 binutils and the MinGW runtime to function properly.  Until those patches
 make it into their official repositories only MinGW64 will be released.

I'm seeing a consistent hang on a multithreaded application that runs under GDC on Linux. It seems to be hanging on startup shortly after it starts a thread (which is odd because this is the second thread it starts, not the first). GDB shows that the original thread and the first thread started are in ntdll!ZwWriteVirtualMemory and the new thread is in KERNEL32!CtrlRoutine, but it doesn't show any functions from my program in the backtrace, which makes me suspicious. (the main thread shows unidentifiable functions in the backtrace and causes GDB to emit internal error warnings when trying to print said backtrace) I initially thought it might be GC related, but runniing GC.disable() on startup doesn't seem to have any effect. Is this known, or should I copy/paste a bunch of GDB output and file a bug?

Probably more interestingly, I don't know where that third thread is coming from. I only ever start two in my program at the moment. I can also just stuff the program source onto Github. It's not closed source.

Feb 15 2012
parent Daniel Green <venix1 gmail.com> writes:
On 2/16/2012 3:25 PM, Andrew Wiley wrote:
 Trouble is that this a few thousand line codebase. I'll see what I can
 do about getting a reduced sample.

reduced case helps tremendously but isn't necessary.
 I was mostly wondering whether you've seen anything like this before,
 but it sounds like you haven't.

history disappears it can be mean that the stack is being corrupted. Another common symptom of stack corruption is returning to weird functions. Are you using -m32 to compile the code? If not can it be compiled with -m32? The latest MinGW compiler is 64-bit by default and it's possible some function calls have not been updated resulting in passing 32-bit value when a 64-bit value is needed or passing 64-bit values to functions that only want 32-bit values. As for the extra thread the runtime starts a thread for the GC inside the initialization routine. It may still exist with GC.disable().
 I initially thought it might be related to my use of Fibers, but
 removing them seems to have had no effect (although my program is
 faster now, so I suppose that's an effect).

Feb 16 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
Trouble is that this a few thousand line codebase. I'll see what I can
do about getting a reduced sample.
I was mostly wondering whether you've seen anything like this before,
but it sounds like you haven't.

I initially thought it might be related to my use of Fibers, but
removing them seems to have had no effect (although my program is
faster now, so I suppose that's an effect).

On Wed, Feb 15, 2012 at 2:28 PM, Daniel Green <venix1 gmail.com> wrote:
 If you could post the source and a link to it I'd be happy to take a look=

 =A0Also bug reports are always welcomed especially when accompanied by re=

 testcases ;)



 On 2/9/2012 11:34 AM, Andrew Wiley wrote:
 On Thu, Feb 9, 2012 at 10:25 AM, Andrew Wiley<wiley.andrew.j gmail.com>
 =A0wrote:
 On Sat, Jan 28, 2012 at 8:46 AM, Daniel Green<venix1 gmail.com> =A0wrot=



 Please post all issues in D.gnu or on GDC's site
 https://bitbucket.org/goshawk/gdc

 Due to the use of a newer runtime than TDM64-GCC it is **recommended**
 to
 install a copy specifically for GDC.

 Features
 =A0* binutils with TLS patches
 =A0* mingw-w64-runtime with TLS and stdio fixes.
 =A0* GCC 4.6.1 with TLS patches
 =A0* Both D1 and D2 compilers. =A0D2 invoked by default.
 =A0 * -v1 Compiles with D1. =A0Must be used in linking stage as well.
 =A0 * -v2 Compiles with D2. =A0Must be used in linking stage as well.

 MinGW64 installer
 http://tdm-gcc.tdragon.net/

 GDC binary

 https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-232c=




 Known issues:
 =A0* May break TDM64 C++.
 =A0* Field-less structs will throw a null this exception. =A0When form=




 by
 std.format. =A0runnable/test23.d

 ---

 For the time, MinGW32 binaries will not be provided. =A0MinGW64 is bui=




 as a
 32-bit binary that allows use on 32-bit Windows. =A0GDC requires patch=




 to
 binutils and the MinGW runtime to function properly. =A0Until those
 patches
 make it into their official repositories only MinGW64 will be released=




 I'm seeing a consistent hang on a multithreaded application that runs
 under GDC on Linux. It seems to be hanging on startup shortly after it
 starts a thread (which is odd because this is the second thread it
 starts, not the first).
 GDB shows that the original thread and the first thread started are in
 ntdll!ZwWriteVirtualMemory and the new thread is in
 KERNEL32!CtrlRoutine, but it doesn't show any functions from my
 program in the backtrace, which makes me suspicious.
 (the main thread shows unidentifiable functions in the backtrace and
 causes GDB to emit internal error warnings when trying to print said
 backtrace)
 I initially thought it might be GC related, but runniing GC.disable()
 on startup doesn't seem to have any effect.

 Is this known, or should I copy/paste a bunch of GDB output and file a
 bug?

Probably more interestingly, I don't know where that third thread is coming from. I only ever start two in my program at the moment. I can also just stuff the program source onto Github. It's not closed source.


Feb 16 2012
prev sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Thu, Feb 16, 2012 at 9:12 PM, Daniel Green <venix1 gmail.com> wrote:
 On 2/16/2012 3:25 PM, Andrew Wiley wrote:
 Trouble is that this a few thousand line codebase. I'll see what I can
 do about getting a reduced sample.

If I can get a copy I'll look at it when I have some free time. A reduced case helps tremendously but isn't necessary.
 I was mostly wondering whether you've seen anything like this before,
 but it sounds like you haven't.

I have a few thoughts about what could be causing it. When the call histo=

 disappears it can be mean that the stack is being corrupted. Another comm=

 symptom of stack corruption is returning to weird functions.

 Are you using -m32 to compile the code? =A0If not can it be compiled with
 -m32? =A0The latest MinGW compiler is 64-bit by default and it's possible=

 function calls have not been updated resulting in passing 32-bit value wh=

 a 64-bit value is needed or passing 64-bit values to functions that only
 want 32-bit values.

-m32 vs -m64 doesn't seem to change the behavior at all.
 As for the extra thread the runtime starts a thread for the GC inside the
 initialization routine. =A0It may still exist with GC.disable().

Ah, that makes sense.
Feb 16 2012