gmane.comp.lang.d.gnu

MinGW thread.Fiber

Manu — 2012-05-24T09:42:12

I don't know if anyone saw my bug on core.thread.Fiber under MinGW64. I'm
curious to know if anyone else can reproduce it?

- Manu

Re: MinGW Release. D2.058 x86-64 20120513

Manu — 2012-05-14T07:34:17

Awesome. Is this version much different than the prior release other than
the details you list? Does it include more recent DMD changes?


On 14 May 2012 07:20, Daniel Green <venix1< at >gmail.com> wrote:

MinGW Release. D2.058 x86-64 20120513

Daniel Green — 2012-05-14T04:20:09

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
  **ALPHA** As in, D2.058 support is still new.
  * D2.058
  * Debug information available using gnu-debuglink.
  * Removed D1(Did anyone use this feature?).
    * Due to current system breaking with repository changes and D1
      being discontinued at the end of the year.
  * binutils with TLS patches
  * mingw-w64-runtime with TLS and stdio fixes.
  * GCC 4.6.1 with TLS patches

Installation instructions:

1. Download and install TDM MinGW64
2. Extract the downloaded archive into the base of the newly installed 
TDM install.

If you've done this before, you can just do step 2.

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

GDC binary
https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-dd401b9-20120513-D2.058.7z

Changes:
  * Fixes __t.0 undefined references with interfaces.
  * Fixes 32-bit _Dmodule_ref issues.
  * sqlite3 is now part of libgphobos2.a.  (32/64-bit)

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

Re: Problem with passing ref parameters to properties

Manu — 2012-05-10T20:22:02


Hmmm, with this in mind, and the information that it works if you remove
'ref', I wonder if this may be related to the problem that caused me to
have to remove 'ref' from all the operators on tuesday (where we couldn't
chain operators that received their argument by ref, complaining about
lvalues). Perhaps the result of the ternary operator is causing a similar
problem with temporary variable lifetime?

I am suspecting ref its self might be kinda broken. Is it a fairly new
keyword? We've had a few weird problems with it.

Re: Problem with passing ref parameters to properties

SebastianA — 2012-05-10T15:10:08

I had not tested the code with DMD. We need x64 support, so we 
need GDC for that at the moment. However, I tried compiling with 
DMD and it seems that the line

t.vPosition = (Clock.currStdTime % 2 == 0) ? Vec(2, 2) : Vec(3, 
3);

does not compile with the latest DMD compiler. I get the error:

test.d(23): Error: not a property t.vPosition

when trying that. If I remove the ternary operator and just 
assign Vec(2, 2) to the property, it works as expected. Am I 
missing something here? Why cannot I write the code as listed 
above?

Re: Problem with passing ref parameters to properties

Iain Buclaw — 2012-05-10T14:46:37


Hello Sebastian,


Thanks for your report.  I will check this out and get back to you
this afternoon.

You should be able to produce a debug tree of the code generated in
GCC AST using the command line switch -fdump-tree-original.  This will
output the code sent to the backend in a C-like syntax, and should
help you decode where it may be going wrong.

Have you also checked this test case against the DMD compiler to see
if you get the same or different behaviour that GDC produces?


Regards

Problem with passing ref parameters to properties

SebastianA — 2012-05-10T14:18:59

We are seeing a problem with passing ref parameters to 
properties. This bug only occurs in certain situations. Consider 
the following code:

====
void runTest()
{
Thing t;
t.vPosition = (Clock.currStdTime % 2 == 0) ? Vec(2, 2) : Vec(3, 
3);
Vec v = t.vPosition;

outputDebug("%d %d\n", v.x, v.y);
}

struct Vec
{
int x;
int y;
}

struct Thing
{
< at >property Vec vPosition() { return mPosition; }
< at >property Vec vPosition( const ref Vec value ) { return 
mPosition = value; }

private:
Vec mPosition;
}
===

Now, this code should output either "2 2" or "3 3" depending on 
the time. However, on release builds this code will output "0 0" 
every time it is run. This seems to happen regardless of the 
optimization level (we have tried with -O1 and -O3). Some things 
to note is that the bug will NOT occur if any of the following is 
true:

- We compile the code in debug mode. - We specify a constant 
known at compile time (eg. "true") instead of the 
non-deterministic time value. - We save the vector into a 
temporary local variable before passing it to the property. - We 
remove the "const ref" from the property setter and pass the 
vector by value.

Debugging the code reveals that the value passed to the getter is 
indeed 0,0, which rules out the getter as the error source.

We are building this on x64 Windows using gdc version 4.6.1 
20110627 (gdc hg r826:396ce79e6402(default), using dmd ) 
(tdm64-1).

Any idea what's going on?

[Issue 1] asm enter and leave bug

2012-05-05T11:54:02

http://d.puremagic.com/issues/show_bug.cgi?id=1


klickverbot <code< at >klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code< at >klickverbot.at


--- Comment #10 from klickverbot <code< at >klickverbot.at> 2012-05-05 04:55:15 PDT ---
(In reply to comment #9)

The GitHub Bugzilla hook script must have misparsed that message – can anyone
see how?

[Issue 1] asm enter and leave bug

2012-05-04T17:40:05

http://d.puremagic.com/issues/show_bug.cgi?id=1



--- Comment #9 from github-bugzilla< at >puremagic.com 2012-05-04 10:41:20 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/5a062e8d544a5c66ecfe0df456096ad12f6963eb
Merge pull request #924 from donc/D1uninitialized

Heisenbug: D1-only uninitialized variable

Re: MinGW Release. D2.058 x86-64 20120428

Manu — 2012-05-01T14:51:27


No problem, I only depend on x64 for the time being, so it's no problem to
use that :)

Re: MinGW Release. D2.058 x86-64 20120428

Daniel Green — 2012-05-01T14:31:16

In D2.058, the _Dmodule_ref code was moved to minfo.d.  I didn't 
properly move the GNU specific stuff on the first build, problem didn't 
surface until I compiled it with MinGW.

They reduced it to OSX, Posix for including _Dmodule_ref.  Which is why 
linux didn't exhibit the same problems.

I added it back but there's a chance the 32-bit library wasn't updated 
properly.

Re: MinGW Release. D2.058 x86-64 20120428

Iain Buclaw — 2012-05-01T06:53:52

no _Dmodule_ref would probably mean no object_.d was compiled in.

Re: MinGW Release. D2.058 x86-64 20120428

Daniel Green — 2012-05-01T04:37:57

Build order?  binutils isn't smart(purposefully so?) when it comes to 
symbol resolution.  The symbol must be declared after it is used.  I 
would check the -v output and see where your library is in relation to 
the object file.


This would save you the need to add -lsqlite and ensure that phobos 
symbols are properly resolved as well.  As Iain suggested, this may be 
what GDC will start doing.

ar q libgphobos2.a sqlite3.o

Here's the size with -O2, -O3 for 32 and 64 bit.
-rw-r--r-- 1 venix Administrators 742K Apr 30 23:23 sqlite3-m32-03.
-rw-r--r-- 1 venix Administrators 565K Apr 30 23:21 sqlite3-m32.o
-rw-r--r-- 1 venix Administrators 755K Apr 30 23:30 sqlite3-m64-03.
-rw-r--r-- 1 venix Administrators 579K Apr 30 23:32 sqlite3-m64.o

DMD/Windows uses minit for module initialization.  GDC uses 
_Dmodule_ref.  In the last release, they reorganized some module 
initialization code causing GDC/MinGW to not use define/use _Dmodule_ref 
initialization.

Currently, there is an issue with multilib building on MinGW.  I had to 
manually compile and extract libphobos for the release.  It's possible I 
missed something.

Re: MinGW Release. D2.058 x86-64 20120428

Manu — 2012-04-30T19:49:58

Actually, I just tried -m64 and the _Dmodule_ref errors were all gone...
switched back to -m32 and they were back again...
User error? What are they about?

Re: MinGW Release. D2.058 x86-64 20120428

Manu — 2012-04-30T18:38:05


libsqlite is quite big, perhaps it would be better to have the script
create a lib beside phobos instead of in it?
DMD supplies this as a separate lib, although theirs is about 1/3rd the
size of the one I built for some reason :/


Curl is the only tricky one.  It actually has configuration options and


I suspect the doc may reveal which features are available:
http://dlang.org/phobos/etc_c_curl.html (looks like it covers basically
everything)
Is there a standard set of features for some 'standard' binary
distribution? Most linux '-dev' packages seem to include binary libs for
easy access, there must be a standard used there...

I had trouble building curl, but I will be using all 3 currently existing
etc.c libs in my app.

Re: MinGW Release. D2.058 x86-64 20120428

Manu — 2012-04-30T18:24:06


I seem to be getting a lot of these with the latest build trying to build a
windows project (Daniel: the same repo I referred to in that bug report)

c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(ti_Aint.o):
In function `rt.typeinfo.ti_Aint._D2rt8typeinfo7ti_Aint9__modinitFZv':
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
undefined reference to `_Dmodule_ref'
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos\libdruntime/../../../../../gcc-4.6.1/libphobos/libdruntime/rt/typeinfo/ti_Aint.d:1:
undefined reference to `_Dmodule_ref'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib32/libgphobos2.a(conv.o):
In function `std.conv._D3std4conv9__modinitFZv':
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
undefined reference to `_Dmodule_ref'
C:\crossdev\gdc64\v2\build\x86_64-w64-mingw32\32\libphobos/../../../../gcc-4.6.1/libphobos/std/conv.d:1:
undefined reference to `_Dmodule_ref'
etc...


I also built sqlite, but it's complaining with lots of:

C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB6AttachMFAxaAxaZE4demu5tools5error9ErrorCode':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:57: undefined reference to
`sqlite3_exec'
C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB5CloseMFZv':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:46: undefined reference to
`sqlite3_close'
C:\Users\MANUEV~1\AppData\Local\Temp\cclkNCic.o: In function
`D4demu5tools8sqlitedb8SQLiteDB4OpenMFAxaZE4demu5tools5error9ErrorCode':
D:\Projects\SuperEmu/Source/Tools/SQLiteDB.d:34: undefined reference to
`sqlite3_open'
etc...


Any ideas?

Here's how I built sqlite, in case I did something wrong:
gcc -c sqlite3.c -m64 -O3  -> sqlite3.o
ar rs libsqlite.a sqlite3.o    -> sqlite.a

Re: MinGW Release. D2.058 x86-64 20120428

Iain Buclaw — 2012-04-30T15:40:46

SQLite comes as a single source file if I recall correctly, and could
be added to the libphobos build folder under libphobos/sqlite.

In future when (or if) shared libraries are supported, can remove the
source file and have these as dependencies for building libphobos,
which are linked in during compilation of libgphobos.so

Re: MinGW Release. D2.058 x86-64 20120428

Daniel Green — 2012-04-30T15:33:19

It was sort of an intermittent release, to get it out and tested.

To update the lib status, zlib is already part of libgphobos2.a.  If you 
inspect the library you'll see it's object files.  If you're having 
specific zlib errors, you should share them.

sqlite.o is easy enough to build and can be put into libgphobos.a. 
Being public domain helps, I'll add it to the build process.

Curl is the only tricky one.  It actually has configuration options and 
probably dependencies.  Is there a list of what features D requires curl 
to support?

Re: MinGW Release. D2.058 x86-64 20120428

Manu — 2012-04-30T11:18:08

I guess the etc.c... libs didn't make the cut :(

On 28 April 2012 22:35, Dmitry Olshansky <dmitry.olsh< at >gmail.com> wrote:

Re: MinGW Release. D2.058 x86-64 20120428

Dmitry Olshansky — 2012-04-28T19:35:12

Nice, it works so far :)

And where as previous version promptly segfaulted on my regex benchmark 
this one goes through. And the compiled binary performance is not bad 
either:

Small test - searching for all \S+< at >\S+ (rough "email") in 40Mb of 
man-like text.

dmd: 5.48sec
gdc: 3.30sec

Cool, surely gone use it side by side with dmd.

P.S. Command line options:
dmd -O -release -noboundscheck
gdc -Ofast -frelease

Re: MinGW Release. D2.058 x86-64

Daniel Green — 2012-04-28T17:09:06

Removed the download.  Broken binaries aren't useful.

Try

https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm64-1-gdc-7e1a98da2769-20120428-D2.058.7z