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

Daniel Green (25/25) Jan 28 2012 Please post all issues in D.gnu or on GDC's site

S�nke Ludwig (12/60) Jan 30 2012 == Auszug aus Daniel Green (venix1@gmail.com)'s Artikel

Daniel Green (14/19) Jan 30 2012 All tests pass successfully over here. Are only the 32-bit tests

F i L (2/2) Jan 30 2012 You guys rock!
Andrew Wiley (20/44) Feb 09 2012 ed by
Andrew Wiley (13/59) Feb 09 2012 o

Daniel Green (4/56) Feb 15 2012 If you could post the source and a link to it I'd be happy to take a

Andrew Wiley (16/87) Feb 16 2012 Trouble is that this a few thousand line codebase. I'll see what I can

Daniel Green (14/21) Feb 16 2012 If I can get a copy I'll look at it when I have some free time. A

Andrew Wiley (7/25) Feb 16 2012 on

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

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

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.

Jan 30 2012

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

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

Jan 30 2012

"F i L" <witte2008 gmail.com> writes:

You guys rock!

This should be on dlang.org someplace.

Jan 30 2012

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=

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

ed by
 std.format. =A0runnable/test23.d

 ---

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

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

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

es
 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

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=


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


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


ted by
 std.format. =A0runnable/test23.d

 ---

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


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


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


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

g?

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

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

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=

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



e:
 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=




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




atted
 by
 std.format. =A0runnable/test23.d

 ---

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




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




es
 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

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.

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

Feb 16 2012

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=

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

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

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

en
 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

D Programming

C/C++ Programming

Other

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