Hello,

the new DMD 0.120 asserts on the following test program:


struct Iterator(T)
{
private:
  T* m_ptr;

public:
  int opEquals(Iterator iter)
  {
    return (m_ptr == iter.m_ptr);
  }

  int opCmp(Iterator iter)
  {
    return (m_ptr - iter.m_ptr);
  }
}

int main(char[][] args)
{
  Iterator!(int) iter;
}


This is what he says:

dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol(): Assertion `t->Tmangle == 0' failed.
Abgebrochen

It is important that there is an opEquals, otherwise the program passes (and comparison works fine). Version 0.119 works fine in both cases.

Another problem (already reported by Ben Hinkle, i think) occurs with opEquals/opCmp for structs larger than 8 bytes (or 4 bytes?). The compiler complains about wanting opEquals(StructName*) as declaration, but declaring this function isn't fine either because he then complains on the comparisons (struct1 == struct2).

Hope that helps.
uwe

Uwe Salomon wrote:
<snip>
> dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol(): Assertion  `t->Tmangle == 0' failed.
> Abgebrochen
<snip>

For me (Windows 98SE), it looks like this

Assertion failure: 't->Tmangle == 0' on line 285 in file 'tocsym.c'

Is the appearance of error messages platform dependent?  I wonder why.

It seems to happen only if both opEquals(Iterator) and opCmp(Iterator) are defined.  The bug also disappears if I remove or change the parameter type of either.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe Salomon schrieb am Fri, 08 Apr 2005 10:35:08 +0200:
> Hello,
>
> the new DMD 0.120 asserts on the following test program:
>
>
> struct Iterator(T)
> {
> private:
>    T* m_ptr;
>
> public:
>    int opEquals(Iterator iter)
>    {
>      return (m_ptr == iter.m_ptr);
>    }
>
>    int opCmp(Iterator iter)
>    {
>      return (m_ptr - iter.m_ptr);
>    }
> }
>
> int main(char[][] args)
> {
>    Iterator!(int) iter;
> }
>
>
> This is what he says:
>
> dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol(): Assertion
> `t->Tmangle == 0' failed.
> Abgebrochen
>
> It is important that there is an opEquals, otherwise the program passes (and comparison works fine). Version 0.119 works fine in both cases.

Added to DStess as http://dstress.kuehne.cn/run/bug_tocsym_285_01.d http://dstress.kuehne.cn/run/bug_tocsym_285_02.d http://dstress.kuehne.cn/run/bug_tocsym_285_03.d http://dstress.kuehne.cn/run/bug_tocsym_285_04.d

> Another problem (already reported by Ben Hinkle, i think) occurs with opEquals/opCmp for structs larger than 8 bytes (or 4 bytes?). The compiler complains about wanting opEquals(StructName*) as declaration, but declaring this function isn't fine either because he then complains on the comparisons (struct1 == struct2).

sample code?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCVlhf3w+/yD4P9tIRAkpEAJ4m5l00RQM4n1qHzlpINuNZdi4JFgCdEoSp
lACMCVeUBnx7wwasVkA5opY=
=xW7G
-----END PGP SIGNATURE-----

>> Another problem (already reported by Ben Hinkle, i think) occurs with
>> opEquals/opCmp for structs larger than 8 bytes (or 4 bytes?). The compiler
>> complains about wanting opEquals(StructName*) as declaration, but
>> declaring this function isn't fine either because he then complains on the
>> comparisons (struct1 == struct2).
>
> sample code?


struct TestStruct(T)
{
public:
  int opEquals(T[] len2)
  {
    return 0;
  }

  int opCmp(T[] len2)
  {
    return 0;
  }
}


int main(char [][] args)
{
  TypeInfo info = typeid(TestStruct!(int));
  return 0;
}


Well, this was a hard battle (reducing my nice 1500-lines-vector to this anonymous example). It also works with only one of the opXXX() functions, because the compiler complains on both of 'em:


main.d(122): function indigo.main.TestStruct!(int).TestStruct.opEquals must be declared as extern (D) int opEquals(TestStruct*)
main.d(127): function indigo.main.TestStruct!(int).TestStruct.opCmp must be declared as extern (D) int opCmp(TestStruct*)


The critical line is the one with the typeid() in the main function. Remove it and the error goes away. It also goes away if you insert this declaration (and remove the opEquals(), of course):


  int opCmp(TestStruct x)
  {
    return 0;
  }


So this may even be desired behaviour? Not sure if it is a bug. But if i also add the following function:


  int opEquals(TestStruct x)
  {
    return 0;
  }


then the compiler crashes with the error we discussed before (assertion in tocsym.c). I assume that he would otherwise pass the whole program and compile correctly.

Ciao
uwe

Little luck with 120. I have now experienced both compiler asserts (similar to the one you mention, but on completly different code) and incorrect code generation/code that does strange things. And that's just on the one small project I'm working on now (I have tried both 120 and 120.2.) Looks like 120 is borked. (Sorry I don't have code samples or anything helpful, but I've already reverted to 119.)

Perhaps it it time to begin with 'stable' and 'unstable' releases?

Nick

In article <opsowngukl6yjbe6@sandmann.maerchenwald.net>, Uwe Salomon says...
>
>Hello,
>
>the new DMD 0.120 asserts on the following test program:
>
>
>struct Iterator(T)
>{
>private:
>   T* m_ptr;
>
>public:
>   int opEquals(Iterator iter)
>   {
>     return (m_ptr == iter.m_ptr);
>   }
>
>   int opCmp(Iterator iter)
>   {
>     return (m_ptr - iter.m_ptr);
>   }
>}
>
>int main(char[][] args)
>{
>   Iterator!(int) iter;
>}
>
>
>This is what he says:
>
>dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol(): Assertion
>`t->Tmangle == 0' failed.
>Abgebrochen
>
>It is important that there is an opEquals, otherwise the program passes (and comparison works fine). Version 0.119 works fine in both cases.
>
>Another problem (already reported by Ben Hinkle, i think) occurs with opEquals/opCmp for structs larger than 8 bytes (or 4 bytes?). The compiler complains about wanting opEquals(StructName*) as declaration, but declaring this function isn't fine either because he then complains on the comparisons (struct1 == struct2).
>
>Hope that helps.
>uwe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick schrieb am Fri, 8 Apr 2005 14:05:54 +0000 (UTC):
> Little luck with 120. I have now experienced both compiler asserts (similar to the one you mention, but on completly different code) and incorrect code generation/code that does strange things. And that's just on the one small project I'm working on now (I have tried both 120 and 120.2.) Looks like 120 is borked. (Sorry I don't have code samples or anything helpful, but I've already reverted to 119.)

Any code - even if it's a 14k sample - would be very usefull if your assert message isn't listed below or in http://dstress.kuehne.cn/raw_results/linux-i686_dmd-0.120.log

>>dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol():Assertion
>>`t->Tmangle == 0' failed.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCVp2j3w+/yD4P9tIRAkV0AJsHhWaVkB85qFrdSvMfHmmp/bvN/gCfV039
b19xSAtehbUW93cbY6+doeU=
=gaUQ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe Salomon schrieb am Fri, 08 Apr 2005 15:21:12 +0200:
>>> Another problem (already reported by Ben Hinkle, i think) occurs with
>>> opEquals/opCmp for structs larger than 8 bytes (or 4 bytes?). The
>>> compiler
>>> complains about wanting opEquals(StructName*) as declaration, but
>>> declaring this function isn't fine either because he then complains on
>>> the
>>> comparisons (struct1 == struct2).
>>
>> sample code?
>
>
> struct TestStruct(T)
> {
> public:
>    int opEquals(T[] len2)
>    {
>      return 0;
>    }
>
>    int opCmp(T[] len2)
>    {
>      return 0;
>    }
> }
>
>
> int main(char [][] args)
> {
>    TypeInfo info = typeid(TestStruct!(int));
>    return 0;
> }
>
>
> Well, this was a hard battle (reducing my nice 1500-lines-vector to this anonymous example). It also works with only one of the opXXX() functions, because the compiler complains on both of 'em:
>
>
> main.d(122): function indigo.main.TestStruct!(int).TestStruct.opEquals
> must be declared as extern (D) int opEquals(TestStruct*)
> main.d(127): function indigo.main.TestStruct!(int).TestStruct.opCmp must
> be declared as extern (D) int opCmp(TestStruct*)
>
>
> The critical line is the one with the typeid() in the main function. Remove it and the error goes away.

Strange.

> It also goes away if you insert this declaration (and remove the opEquals(), of course):
>
>
>    int opCmp(TestStruct x)
>    {
>      return 0;
>    }
>
>
> So this may even be desired behaviour?

I think so.
Structs don't inherit. Thus defining custom opCmp/opEquals hide the
default opCmp/opEquals. Seems like DMD detected that there is no
correctly overloadeable version and barks a missleading message.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCVqKU3w+/yD4P9tIRAkKdAKCIORg2a05h9KEIrq7yGdzBEpoSmwCbBOv0
GPUp0xa2qPEVcT/Jx0zx9AY=
=UwxF
-----END PGP SIGNATURE-----

>> The critical line is the one with the typeid() in the main function.
>> Remove it and the error goes away.
>
> Strange.

I think the compiler only generates a typeinfo for the struct if it is needed somewhere. And the typeinfo includes the compare-operator (it takes 2 pointers to the struct, i think). Thus he needs the overloaded opCmp(Struct x) to work, but only if the typeinfo is requested.

> Structs don't inherit. Thus defining custom opCmp/opEquals hide the
> default opCmp/opEquals. Seems like DMD detected that there is no
> correctly overloadeable version and barks a missleading message.

Jep. But as soon as you defined the needed opCmp(), you can define others as well (i have opCmp(T[] x) and opCmp(T x) and opCmp(Struct!(T) x)), and thes work as expected. But you're right, the message should be a bit clearer (like "opCmp(Struct) is needed as well").

Ciao
uwe

In article <56jii2-126.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>
>Any code - even if it's a 14k sample - would be very usefull if your assert message isn't listed below or in http://dstress.kuehne.cn/raw_results/linux-i686_dmd-0.120.log
>
>>>dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol():Assertion
>>>`t->Tmangle == 0' failed.

It's neither this one or in the list. It was an assertion in tocsym.c in line 217 or so, I think, with VarDeclaration instead of FuncDeclaration. I can't seem to reproduce it right now, since I've changed my code a bit. I'll see what I can do.

The "strange behaviour" I managed to reproduce, though. I use std.stream but the bug probably doesn't depend on it:

#import std.stdio;
#import std.stream;
#
#class MyFile
#{
#  Stream file;
#
#  void open(char[] filename)
#    {
#      file = new File(filename);
#
#      // THIS FAILS
#      char[] a = getHeaderName();
#
#      /* THIS WORKS
#      char[5] buf;
#      file.readExact(buf.ptr, 5);
#      char[] a = buf;
#      */
#
#      writefln(a);
#
#      if(a != "HELLO")
#	writefln("ERROR");
#
#      file.close();
#    }
#
#  char[] getHeaderName()
#    {
#      char[5] buf;
#      file.readExact(buf.ptr, 5);
#      return buf;
#    }
#}
#
#void main()
#{
#  MyFile file = new MyFile;
#  file.open("hello.txt");
#}

hello.txt contains the word HELLO. Come to think of it, the bug is possably related or identical to the one David Medlock reported earlier http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3538

Nick

In article <d36e4v$2vc2$1@digitaldaemon.com>, Nick says...

>It's neither this one or in the list. It was an assertion in tocsym.c in line 217 or so, I think, with VarDeclaration instead of FuncDeclaration. I can't seem to reproduce it right now, since I've changed my code a bit. I'll see what I can do.

Ok, here we go:

# class A
# {
#   ~this() {}
# }
#
# void main()
# {
#   auto A a = new A();
#       try
#         {
#         }
#       catch(Exception e)
#         {
#           try {e.print();}
#           catch {}
#         }
# }

$ dmd bug.d
linkage = 0
dmd: tocsym.c:217: virtual Symbol* VarDeclaration::toSymbol(): Assertion `0'
failed.

Nick