Problems relating to Windows Binaries.

Daniel Green avatarDaniel Green created an issue

The simpleness of this issue system leaves something to be desired.

Any issues relating to the current TDM-GDC binaries post here.

Comments (15)

  1. Andrej08
    • changed status to open

    Is pragma(lib) going to be supported? I'm not in a rush or anything. :)

    The other issue is that I've tried passing the library file name on command line, like so:

    gdmd driver.d libwinmm.a

    However gdmd won't link with libwinmm.a unless I copy the file directly to my project directory. libwinmm.a is an import library and its located by default in the /lib subdirectory of MinGW/GDC. Shouldn't GDMD automatically try to look in the /lib directory for missing library files specified on the command line?

  2. Daniel Green

    I guess that shows how much gdmd has been tested. GDC requires -lwinmm -L<path> for library usage. Briefly looking over the source for GDMD it doesn't take that into consideration.

  3. Andrej08
    • changed status to new

    Windows users will need to create a batch to easily use GDMD, gdmd.bat:

    @echo off
    perl gdmd %*
    @echo on

    I keep that file in GDC /bin. Maybe add it to the binaries on the next release?

  4. Anonymous
    import std.stdio, std.conv;
    int main()
    	wstring wmsg="hello world"w;
    	string cmsg=text(wmsg);
    	assert(cmsg=="hello world");
    	writeln("hangs on writeln(wmsg);");
    	return 0;


    gdc -v2 test.d -o test.exe

    and run

    works with dmd 2.050, windows

  5. jordirovira

    This small program gives me an ICE with the latest binary distribution. I think the linux version works, however i will try again later.

    module  bug;
    class foo
    void func()
            foo a = null;
            foo[] b = [ null, a, a ];

    used like this:

    D:\projectes\bug>gdc -v2 bug.d
    bug.d:1:0: internal compiler error: in expand_expr_real_1, at expr.c:8481
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <> for instructions.
  6. Daniel Green

    Got debugging symbols put back into GDC. Briefly looking at the code, the assert is triggered because context is null. I'll look into it more later, unless Iain has any ideas on why it's happening.

    /* from expr.c */
    8474          /* Variables inherited from containing functions should have
    8475             been lowered by this point.  */
    8476          context = decl_function_context (exp);
    8477          gcc_assert (!context
    8478                      || context == current_function_decl
    8479                      || TREE_STATIC (exp)
    8480                      /* ??? C++ creates functions that are not TREE_STATIC. */
    8481                      || TREE_CODE (exp) == FUNCTION_DECL);
  7. Daniel Green

    Only my changes to d-spec.c and lang-specs.h have not been merged. They modify the command line to allow GDC to invoke D1 or D2. changes.diff contains the modifications that aren't merged.

    A couple of interesting things.

    foo a = null;
    foo[] b = [ a, null, null ]; // Will not trigger the assert.  No matter what position as long as a is used only once.

    decl_function_context(exp) returns DECL_CONTEXT (exp).

    In [ a, null, a] I would have thought both "a" refer to the same tree. That seems to be false or DECL_CONTEXT is lost after the first use. The symbol name that triggers the assert appears to be an internal symbol DI.XXX.

    This issue is not related to reference types only.

        int a = 12;
        int[] b = [a, 0, a]; // Produces the same error.
  8. Daniel Green

    Looking at the issue again, the variable 'a' does have a context. It fails the second test in the assert context == current_function_decl, current_function_decl is null.

    This was tested on a fresh compiler with only the trunk.

    When I look at the gimple output with -fdump-tree-gimple Linux and Windows produce different code for the same source.

    // Linux gimple
    func ()
      void * D.1731[3];
      void * * D.1732;
      struct  b;
      void * a;
      a = 0B;
      D.1731[0] = 0B;
      D.1731[1] = a;
      D.1731[2] = a;
      D.1732 = _d_arrayliteralTp (&_D12TypeInfo_APv6__initZ, 3);
      __builtin_memcpy (D.1732, &D.1731, 24);
      b.length = 3;
      b.ptr = D.1732;
    // Windows gimple
    func ()
      void * D.1718[3];
      static void * C.0[3] = {0B, a, a};
      void * * D.1720;
      struct  b;
      void * a;
      a = 0B;
      D.1718 = C.0;
      D.1720 = _d_arrayliteralTp (&_D12TypeInfo_APv6__initZ, 3);
      __builtin_memcpy (D.1720, &D.1718, 12);
      b.length = 3;
      b.ptr = D.1720;

    I find it reasonable to infer that current_function_decl is null because 'a' is used to initialize a static variable.

    I build GDC/MinGW with cloog and ppl. I'll rebuild tomorrow without those libraries and see if things change.

  9. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.