www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2582] New: Significantly Increased Compile Times For DWT

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2582

           Summary: Significantly Increased Compile Times For DWT
           Product: D
           Version: 1.039
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: business3 twistedpairgaming.com


Certain DWT programs (though not all) that compiled perfectly fine under DMD
1.037 experience suspiciously long compile times under DMD 1.039. For instance,
the sample "dwt-samples\snippets\treeeditor\Snippet111.d" goes from about 30
seconds in 1.037 to over 15 minutes (I killed it after that) in 1.039.

The bug seems to exhibit some sort of compounding effect, as the more I
stripped down the test case, the faster the compile time became. However, even
in the smallest test case I could come up with (which unfortunately still
relies on both Tango and DWT), there is still a significantly increased delay
at the point where compiler stalls:

--------------------
module test;

import tango.core.Traits;
import dwt.graphics.Path;

class Foo(Dg)
{
    alias ParameterTupleOf!(Dg) DgArgs;
}

void main ()
{
    pragma(msg, __LINE__.stringof);
    new Foo!( void delegate() )( );
    pragma(msg, __LINE__.stringof);
}
--------------------

I compiled this with DSSS 0.76, DWT 3.4-1, and Tango 0.99.7 (the version that
has DMD 1.035 packaged with it:
http://downloads.dsource.org/projects/tango/snapshots/tango-bin-win32-CURRENT-dmd.1.035.zip
).

I compiled with:
rebuild -C-v test

The relevant output for DMD 1.037 was:
--------------------
{...trimmed...}
semantic3 test
13L
{no noticeable pause}
15L
semantic3 Traits
{...trimmed...}
{no linker error}
--------------------

The relevant output for DMD 1.039 was:
--------------------
{...trimmed...}
semantic3 test
13L
{pauses here for about 1 minute}
15L
semantic3 Traits
{...trimmed...}
OPTLINK (R) for Win32 Release 8.00.1
Copyright (C) Digital Mars 1989-2004 All rights reserved.
.\dwt-dwthelper-File.obj(dwt-dwthelper-File) Offset 0575BH Record Type 0091
Error 1: Previous Definition Different : 
_D5tango4text4Text11__T4TextTaZ4Text4Span6__initZ
--- errorlevel 1
--------------------

The linker error seems to occur in 1.039 with every DWT sample I've tried, not
just the ones that also exhibit the long compile times (but never on 1.037). So
I assume that's a separate issue. I'll see if I can come up with a separate
test case and bug report for that.


-- 
Jan 12 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2582





------- Comment #1 from bugzilla digitalmars.com  2009-02-15 20:39 -------
Error 1: Previous Definition Different : 
_D5tango4text4Text11__T4TextTaZ4Text4Span6__initZ

Before saying this is a bug in the linker, it's worth finding why there are
multiple definitions of the same thing in the source code.

http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#previous_definition_different


-- 
Feb 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2582





------- Comment #2 from moritzwarning web.de  2009-02-21 19:47 -------
I tried to compile QTD today (http://code.google.com/p/qtd/)
and encountered a problem that a file didn't finished compiling.

After some testing with several dmd versions I found out
that all tested versions before dmd 1.038 work,
but later versions are caught in an infinite loop.
It's the same problem for ldc, but gdc works (old front end version).

The problem can be reproduced with
"dmd -c qt/gui/QPushButton.d -ofqt/gui/QPushButton.o"
and dmd version 1.038 or later (or ldc).

The back trace for ldc looks like this:
(gdb) bt
#0  0x0000000000545ed9 in Module::imports ()
#1  0x0000000000546478 in Module::imports ()
#2  0x0000000000546478 in Module::imports ()
#3  0x0000000000546478 in Module::imports ()
#4  0x00000000005bbf1e in TemplateInstance::semantic ()
#5  0x0000000000573d57 in TypeInstance::resolve ()
#6  0x0000000000571c30 in TypeInstance::semantic ()
#7  0x00000000005973ea in VarDeclaration::semantic ()
#8  0x00000000005c8f2c in ClassDeclaration::semantic ()
#9  0x0000000000549bde in StorageClassDeclaration::semantic ()
#10 0x0000000000549dc6 in ProtDeclaration::semantic ()
#11 0x00000000005448c8 in Module::semantic ()
#12 0x00000000005be2b4 in Import::semantic ()
#13 0x0000000000549dc6 in ProtDeclaration::semantic ()
#14 0x00000000005448c8 in Module::semantic ()
#15 0x00000000005be2b4 in Import::semantic ()
#16 0x0000000000549dc6 in ProtDeclaration::semantic ()
#17 0x00000000005448c8 in Module::semantic ()
#18 0x00000000005be2b4 in Import::semantic ()
#19 0x0000000000549dc6 in ProtDeclaration::semantic ()
#20 0x00000000005448c8 in Module::semantic ()
#21 0x00000000005be2b4 in Import::semantic ()
#22 0x0000000000549dc6 in ProtDeclaration::semantic ()
#23 0x00000000005448c8 in Module::semantic ()

Looks like Module::imports from module.c is involved.
It was added in dmd 1.038.

Hope that helps. :)


-- 
Feb 21 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2582


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #3 from bugzilla digitalmars.com  2009-03-11 14:53 -------
Fixed dmd 1.041


-- 
Mar 11 2009