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.

== 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
>
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.

== 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
>
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.

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.

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).
All tests pass successfully over here.  Are only the 32-bit tests 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

You guys rock!

This should be on dlang.org someplace.

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?

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.

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.

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.  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.
>
>

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 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).

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 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.

-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.  It may still exist with GC.disable().

Ah, that makes sense.