View mode: basic / threaded / horizontal-split · Log in · Help
January 28, 2012
Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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.
January 30, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
== 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.
January 30, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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
January 30, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
You guys rock!

This should be on dlang.org someplace.
February 09, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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?
February 09, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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.
February 15, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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.
February 16, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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.
>
>
February 17, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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).
February 17, 2012
Re: Release: MinGW64 GCC 4.6.1 GDC 232cd89d90b4
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.
Top | Discussion index | About this forum | D home