www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2962] New: Assertion in glue.c fails

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

           Summary: Assertion in glue.c fails
           Product: D
           Version: 2.029
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: bugzilla kyllingen.net


Created an attachment (id=358)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=358)
Compile and run this file

While porting a library from D1 to D2 I encountered the following DMD error:

dmd: glue.c:652: virtual void FuncDeclaration::toObjFile(int): Assertion
`!v->csym' failed.
Aborted

It's hard to say what causes the error, but I've been able to narrow it down to
a point where almost any change I make makes the error disappear. The source
files are attached. (There's four of them, but they are very short.)

To reproduce the error, compile and run the program with rdmd:
    rdmd moduleA.d
Strangely enough, running DMD directly does not reproduce the error:
    dmd moduleA.d moduleB.d moduleC.d moduleD.d
    ./moduleA

For some changes a runtime bug is introduced instead; see the commented section
in moduleC.d.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #1 from Lars T. Kyllingstad <bugzilla kyllingen.net>  2009-05-11
01:57:57 PDT ---
Created an attachment (id=359)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=359)
Imported by moduleA

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #2 from Lars T. Kyllingstad <bugzilla kyllingen.net>  2009-05-11
01:58:36 PDT ---
Created an attachment (id=360)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=360)
moduleC: imported by moduleB

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #3 from Lars T. Kyllingstad <bugzilla kyllingen.net>  2009-05-11
01:59:11 PDT ---
Created an attachment (id=361)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=361)
moduleD: imported by moduleC

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Lars T. Kyllingstad <bugzilla kyllingen.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #359|Imported by moduleA         |moduleB: Imported by
        description|                            |moduleA




-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Sergey Gromov <snake.scaly gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
                 CC|                            |snake.scaly gmail.com
            Version|2.029                       |1.030
         OS/Version|Linux                       |All




--- Comment #4 from Sergey Gromov <snake.scaly gmail.com>  2009-08-13 18:52:22
PDT ---
Here is a simpler test case for what I think is the same issue:

-----8<----testa.d-----
import testb;

int foo()
{
  return bar(0);
}
-----8<----testa.d-----

-----8<----testb.d-----
T bar(T)(T x)
{
  return baz!(T, x)();
}

T baz(T, T x)()
{
  return x;
}
-----8<----testb.d-----

Compile order matters:

 dmd -c testb.d testa.d

abnormal program termination
 dmd -c testa.d testb.d

Tested this with DMD 1.030, 1.033, 1.041, 1.042, 1.046, 2.026, 2.027 and 2.031, with exactly the same results. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Sergey Gromov <snake.scaly gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |ice-on-invalid-code




--- Comment #5 from Sergey Gromov <snake.scaly gmail.com>  2009-08-13 19:00:24
PDT ---
Sorry, this ICE is definitely on *invalid* code since the baz template is being
parametrized on the bar's run-time argument.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, wrong-code
                 CC|                            |clugdbug yahoo.com.au
            Summary|Assertion in glue.c fails   |ICE(glue.c) or bad codegen
                   |                            |passing variable as
                   |                            |template value parameter
           Severity|normal                      |major




--- Comment #6 from Don <clugdbug yahoo.com.au>  2009-08-14 00:43:43 PDT ---
Fundamentally this is an accepts-invalid bug, it shouldn't reach the code
generation stage where the ICE occurs. Here's a test case which shouldn't
compile.
There's a chance this could be a regression.

---
T bar(T)(T y) {
  return baz!(T, y)();
}

T baz(T, T z)() {
  return z*z;
}

void main() {
  assert(bar(4)!=0);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #7 from Don <clugdbug yahoo.com.au>  2009-08-14 06:04:11 PDT ---
It's definitely not a recent regression, D1.020 behaved the same way.

Probably the same as 2733, (but please DO NOT mark this as a duplicate, this is
a much better bug report).

Even smaller test case:

void baz(int z)() {}

void main() {
  int x;
  baz!(x)();
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #8 from Don <clugdbug yahoo.com.au>  2009-08-14 07:30:04 PDT ---
Actually I'm not sure if this a bug or an easter egg. The current behaviour of
template value parameters is: if it is a compile-time constant, instantiate the
template as a value. If it is a variable, instantiate it as an alias parameter.

That's actually quite cool.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #9 from Sergey Gromov <snake.scaly gmail.com>  2009-08-14 08:03:44
PDT ---
By the way, the example Lars posted is not as obviously invalid, at least to
me.  He passes a local variable as a template alias parameter.  Docs say that
"local names" can be used as template alias parameters.  This actually works
correctly:

import std.stdio;
void main() {
  foo(1);
}
void foo(int a) {
  bar!(a)();
  writefln(a);
}
void bar(alias var)() {
  var = 2;
}

Prints 2.  This works even if bar is defined in a different module.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley gmail.c
                   |                            |om




--- Comment #10 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-08-14 08:05:06 PDT ---
(In reply to comment #8)
 Actually I'm not sure if this a bug or an easter egg. The current behaviour of
 template value parameters is: if it is a compile-time constant, instantiate the
 template as a value. If it is a variable, instantiate it as an alias parameter.
 
 That's actually quite cool.

Local variables have been passable as alias parameters for quite some time now. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #11 from Don <clugdbug yahoo.com.au>  2009-08-14 08:12:03 PDT ---
(In reply to comment #10)
 (In reply to comment #8)
 Actually I'm not sure if this a bug or an easter egg. The current behaviour of
 template value parameters is: if it is a compile-time constant, instantiate the
 template as a value. If it is a variable, instantiate it as an alias parameter.
 
 That's actually quite cool.

Local variables have been passable as alias parameters for quite some time now. :)

Yes, but if you declare a template parameter as 'alias', it can't accept literals. You can actually achieve the same effect with a tuple parameter, so this behaviour should probably disappear. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #12 from Lars T. Kyllingstad <bugzilla kyllingen.net>  2009-08-14
12:55:04 PDT ---
What I find very strange here is that when I compile my test case with DMD
2.031 specifying just the four attached files, it works. And it should -- I
think the code is valid according to the spec of both D1 and D2.

lars neutrino:~/tmp/bug2962$ dmd moduleA.d moduleB.d moduleC.d moduleD.d 
lars neutrino:~/tmp/bug2962$ ./moduleA
1

However, when I compile it like rdmd does, specifying every module in Phobos on
the command line, it fails:

lars neutrino:~/tmp/bug2962$ dmd 'moduleA.d' 'moduleC.d'
'/usr/local/include/d/druntime/core/sys/posix/config.d'
'/usr/local/include/d/druntime/core/stdc/stdio.d'
'/usr/local/include/d/druntime/core/sys/posix/fcntl.d' [...]
dmd: glue.c:658: virtual void FuncDeclaration::toObjFile(int): Assertion
`!v->csym' failed.

(Run rdmd with --dry-run to see the full list of files it passes to DMD.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #13 from Sergey Gromov <snake.scaly gmail.com>  2009-08-14 13:00:32
PDT ---
(In reply to comment #12)
 What I find very strange here is that when I compile my test case with DMD
 2.031 specifying just the four attached files, it works. And it should -- I
 think the code is valid according to the spec of both D1 and D2.
 
 lars neutrino:~/tmp/bug2962$ dmd moduleA.d moduleB.d moduleC.d moduleD.d 

Try dmd moduleA.d moduleC.d moduleB.d moduleD.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #14 from Lars T. Kyllingstad <bugzilla kyllingen.net>  2009-08-14
13:05:26 PDT ---
Oh, my. :) Didn't even cross my mind that the order of the files matter.

But my example IS valid code, right?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #15 from Sergey Gromov <snake.scaly gmail.com>  2009-08-14 13:34:17
PDT ---
I do think it's valid, see my comment #9.  According to the obj2asm, when you
pass a local var as an alias parameter to a template:

void foo() {
  int i;
  bar!(i)();
}
void bar(alias var)() {
  var = 1;
}

compiler rewrites it as

void foo() {
  int i;
  void bar() {
    i = 1;
  }
  bar();
}

Probably this rewrite is not always possible, hence the assertion failure.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #16 from Sergey Gromov <snake.scaly gmail.com>  2009-08-14 14:05:39
PDT ---
Seems like this bug is an ice-on-VALID after all.  All our examples boil down
to passing local variables as alias template arguments.  Also it seems like a
nice candidate for the issue 340 list.  Don, what do you think?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962





--- Comment #17 from Don <clugdbug yahoo.com.au>  2009-08-15 11:41:14 PDT ---
(In reply to comment #16)
 Seems like this bug is an ice-on-VALID after all.  All our examples boil down
 to passing local variables as alias template arguments.  Also it seems like a
 nice candidate for the issue 340 list.  Don, what do you think?

Could be. I'm busy on other stuff right now, so haven't had a good look at it. Are you able to simplify the valid code example? It's worth all bug reporters knowing that the first step to fixing a bug is to minimize the test case that's in Bugzilla. It helps a _lot_. I found that 90% of the bugs in bugzilla can be minimized further. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #18 from Don <clugdbug yahoo.com.au> 2009-09-10 01:29:07 PDT ---
I don't have a patch, but it's easy to at least get the line number into the
ICE message.

glue.c line 658:

    if (v->csym)
    error("Bugzilla 2962 - Internal Compiler Error");

Doing this would greatly reduce frustration, and probably allow us to close bug
#3283. I'm sure it's a duplicate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 10 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alvcastro yahoo.es


--- Comment #19 from Don <clugdbug yahoo.com.au> 2009-09-13 03:39:51 PDT ---
*** Issue 3283 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid,            |ice-on-valid-code
                   |ice-on-invalid-code         |


--- Comment #20 from Don <clugdbug yahoo.com.au> 2009-09-21 12:14:39 PDT ---
Here's a reduced test case for the ice-on-valid case. dmd moduleC.d moduleA.d
The instantiation of funcD inside funcC is failing, if funcC is only
instantiated from another module. Some kind of instantiation order problem
(semantic not run, perhaps). This is definitely valid code.
Quite probably related to the other template alias ICE and bad codegen
bugs.(eg, bug 3293, bug 2325, bug 2845, ...)

moduleA.d
==========
import moduleC;

void main() {
    funcC!(bool)(1.0);
}
=====
moduleC.d
=======
void funcD(alias x)() {
   assert(x==1.0);
}

void funcC(T)(double a){
    // Case 1: ICE(glue.c)
    funcD!(a)();

    // Case 2: wrong code
    double b = 1.0; funcD!(b)();
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #21 from Don <clugdbug yahoo.com.au> 2009-10-13 02:54:53 PDT ---
This is really tough, it's an order-of-evaluation issue.
When generating the code for a template, which has a local variable as an alias
parameter, the alias parameter MUST be created before the code for template is.

But I have no idea how the order of code generation is supposed to be enforced.
It seems to always get it right if everything is in the same file.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax gmail.com


--- Comment #22 from Leandro Lucarella <llucax gmail.com> 2009-11-05 06:26:17
PST ---
Related SVN commit: http://www.dsource.org/projects/dmd/changeset/240

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


David Simcha <dsimcha yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha yahoo.com


--- Comment #23 from David Simcha <dsimcha yahoo.com> 2009-12-01 11:07:54 PST
---
I can confirm that this bug is dependent on the order of code generation.  I
just ran into this on a project I'm working on and it seems that whether this
bug is exposed or not depends on the order in which I pass the files to DMD. 
Some permutations result in my project compiling and linking w/o errors. 
Others result in this bug being exposed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |critical


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Haruki Shigemori <rayerd.wiz gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rayerd.wiz gmail.com


--- Comment #24 from Haruki Shigemori <rayerd.wiz gmail.com> 2010-12-28
19:59:09 PST ---
Phobos unittest is broken.
I tried to build dmd, druntime, and phobos of trunk.
You should notice -unittest below.

c:\d\svnproj\phobos_trunk\phobos\std>dmd -c -of_ -unittest algorithm.d stdio.d
...
std.algorithm.canFindSorted is scheduled for deprecation.  Use
std.range.SortedR
ange.canFind instead.
std.algorithm.lowerBound is scheduled for deprecation.  Use
std.range.SortedRang
e.lowerBound instead.
std.algorithm.upperBound is scheduled for deprecation.  Use
std.range.SortedRang
e.upperBound instead.
std.algorithm.equalRange is scheduled for deprecation.  Use
std.range.SortedRang
e.equalRange instead.
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1263): Error: function
std.con
v.parse!(float,LockingTextReader).parse compiler error, parameter 'p', bugzilla
2962?
Assertion failure: '0' on line 729 in file 'glue.c'

abnormal program termination

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #25 from Haruki Shigemori <rayerd.wiz gmail.com> 2010-12-28
23:08:59 PST ---
Sorry, you will encounter this issue when dmd and phobos are debug build.
For dmd, you will build dmd with "make -f win32.mak" and "DEBUG=-g -D
-DUNITTEST -L/detailedmap".
For phobos, "you will build phobos with "make -f win32.mak" and
"DFLAGS=-unittest -g -d -debug -L/detailedmap".
If you do so, you will get the following result.

C:\d\svnproj\phobos_trunk\phobos\std>dmd -c -of_ -unittest algorithm.d stdio.d
2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2:
 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2
: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2:
 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2
: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2:
 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2
: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2:
 2: std.algorithm.canFindSorted is scheduled for deprecation.  Use
std.range.Sor
tedRange.canFind instead.
std.algorithm.lowerBound is scheduled for deprecation.  Use
std.range.SortedRang
e.lowerBound instead.
std.algorithm.upperBound is scheduled for deprecation.  Use
std.range.SortedRang
e.upperBound instead.
std.algorithm.equalRange is scheduled for deprecation.  Use
std.range.SortedRang
e.equalRange instead.
2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2:
 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2:
2
: 2: 2: C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1263): Error:
function
 std.conv.parse!(float,LockingTextReader).parse compiler error, parameter 'p',
b
ugzilla 2962?
assert glue.c(729) 0      <---- AND HALT!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #26 from Don <clugdbug yahoo.com.au> 2010-12-29 00:03:44 PST ---
(In reply to comment #25)
 Sorry, you will encounter this issue when dmd and phobos are debug build.
 For dmd, you will build dmd with "make -f win32.mak" and "DEBUG=-g -D
 -DUNITTEST -L/detailedmap".

No problem, I was able to reproduce it from your first comment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #27 from Don <clugdbug yahoo.com.au> 2010-12-29 00:19:59 PST ---
A simpler command line is this:
/dmd/src/phobos/std> dmd -c -unittest conv.d stdio.d
The unittest which it's failing in, is in stdio.d, line 1630:

unittest
{
    float f;
    if (false) readf("%s", &f);
}
Which just shows how nasty this bug is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #28 from Haruki Shigemori <rayerd.wiz gmail.com> 2010-12-29
08:39:15 PST ---
(In reply to comment #27)
 A simpler command line is this:
 /dmd/src/phobos/std> dmd -c -unittest conv.d stdio.d
 The unittest which it's failing in, is in stdio.d, line 1630:
 
 unittest
 {
     float f;
     if (false) readf("%s", &f);
 }
 Which just shows how nasty this bug is.

This is a progress report. failed: /dmd/src/phobos/std dmd -c -unittest conv.d stdio.d succeeded: /dmd/src/phobos/std dmd -c -unittest stdio.d conv.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #29 from Haruki Shigemori <rayerd.wiz gmail.com> 2010-12-29
10:14:31 PST ---
A simpler sample is this:

// module a
import b;

void main()
{
    foo!int(0);
}

// module b
void foo(T)(T p)
{
    void inner(U)() {
        auto p2 = p;
    }
    inner!int();
}

C:\Users\haru\Desktop\c>dmd b a
b.d(1): Error: function b.foo!(int).foo compiler error, parameter 'p', bugzilla
2962?
assert glue.c(729) 0
<--------------------------------- HALT


However, the following result is success.

C:\Users\haru\Desktop\c>dmd a b
Max # of fixups = 8

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario gmx.de


--- Comment #30 from Rainer Schuetze <r.sagitario gmx.de> 2011-01-30 08:07:38
PST ---
I've also hit this issue today after updating to the latest dmd and runtime
from github.

As there is no hint where the problem is in my project, I took a look at the
last test case, and figured out a few things:

- the template instantiation for foo is added to module a, but the
instantiation of inner is added to module b.
- the error is triggered because the code for the inner function is generated
before the code for the outer function. Hence the reliance on the order of
modules on the command line.
- that made me think, that it might be ok to just skip the test, but the
following code shows, that it does not work because the inner function needs
the stack offset which is only calculated when the outer function is generated:

// module b
T foo(T)(T p, int q)
{
    T inner(U)() {
    return p;
    }
    return inner!int();
}

// module a
import b;

void main()
{
    assert(foo!int(5, 2) == 5);
}

fails for "dmd b.a b.d", but not for "dmd a.d b.d".

Is there a good reason why the inner function is generated into a different
module than the outer function?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 30 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #31 from Rainer Schuetze <r.sagitario gmx.de> 2011-02-06 12:22:16
PST ---
Investigating this a little further, I noticed that when compiling "dmd b a"
the problem seems to be that inner!int is *parsed* before the invocation of the
outer foo, which causes a TemplateInstance to be created. This later causes the
code generation of inner to come first, making the compiler bail out, because
the reference to the parameter of the outer function is not known yet.

As a workaround it seems to work if you put a reference to foo!int where the
parser sees it before inner!int, for example into another file c.d:

module c;
static if(__traits(compiles,foo!int))){}

and the compile it with "dmd c b a".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Bernard Helyer <blood.of.life gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |blood.of.life gmail.com


--- Comment #32 from Bernard Helyer <blood.of.life gmail.com> 2011-02-18
03:45:08 PST ---
Ouch. Hit this when compiling SDC ( https://github.com/bhelyer/SDC ) with
2.052. I'm stuck on 2.051 for the time being.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962


Andriy <andrden gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrden gmail.com


--- Comment #33 from Andriy <andrden gmail.com> 2011-05-23 02:35:44 PDT ---
dmd v2.052, Ubuntu, quite short example of this bug:

$ cat main.d 
import std.stdio;

void main(){}

$ cat utils.d
import std.json;

auto val = &parseJSON!string;

$ dmd main.d utils.d 
/usr/include/d/dmd/phobos/std/conv.d(1301): Error: function
std.conv.parse!(real,string).parse compiler error, parameter 'p', bugzilla
2962?
dmd: glue.c:734: virtual void FuncDeclaration::toObjFile(int): Assertion `0'
failed.
Aborted (core dumped)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2962



--- Comment #34 from Don <clugdbug yahoo.com.au> 2011-05-23 04:20:16 PDT ---
(In reply to comment #33)
 dmd v2.052, Ubuntu, quite short example of this bug:

<snip> No, that's a long example -- it imports from Phobos. Test cases for compiler bugs which import from Phobos are not completely reduced. The examples in comments 20 and 29 are minimal test cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2011