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


<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.
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
































#void main()





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
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:



















$ 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:



















 $ 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