www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Compiler asserts on opCmp

reply "Uwe Salomon" <post uwesalomon.de> writes:
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
Apr 08 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Uwe Salomon wrote:
<snip>
 dmd: tocsym.c:285: virtual Symbol* FuncDeclaration::toSymbol(): 
 Assertion  `t->Tmangle == 0' failed.
 Abgebrochen

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.
Apr 08 2005
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----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-----
Apr 08 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 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
Apr 08 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----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-----
Apr 08 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 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
Apr 08 2005
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
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

Apr 08 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----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-----
Apr 08 2005
parent reply Nick <Nick_member pathlink.com> writes:
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 digitalmars.D.bugs/3538 Nick
Apr 08 2005
parent reply Nick <Nick_member pathlink.com> writes:
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
Apr 08 2005
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick schrieb am Fri, 8 Apr 2005 17:51:51 +0000 (UTC):
 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.

Added to DStress as http://dstress.kuehne.cn/run/bug_tocsym_217_01.d http://dstress.kuehne.cn/run/bug_tocsym_217_02.d http://dstress.kuehne.cn/run/bug_tocsym_217_03.d http://dstress.kuehne.cn/run/bug_tocsym_217_04.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCVtfB3w+/yD4P9tIRArofAKCB7EUqafzF99YleAY75y3Ibsr9cACeK3gt PIAhzTqsQaVnPmovpeJTylU= =EGZe -----END PGP SIGNATURE-----
Apr 08 2005