Bug in egcs?

Bug in egcs?

[Marius Kjeldahl]

While porting some code from Visual C++ 5.0 to egcs (I've tried both
1.0 and the 971207 release) I came across a problem compiling some of
the code. I have been able to narrow it down to the 30 lines attached
to this mail. The relevant error message I get while compiling if I
_remove_ the comment from the SomeClass_t constructor is:

test.cpp:13: sorry, not implemented: `try_catch_expr' not supported by
dump_expr

If the constructor is commented out, everything works fine and
dandy. On Microsoft Visual C++ a similar piece of code (which emits
the same error on the same construction under egcs on linux) compiles
and runs without any problems.

Regardless, the error message does not really give me much help in
figuring this one out. Is there anybody out there with a clue?

Thanks in advance..

Marius

-----8< Code snippet follows -----8<-----8<-----8<-----8<-----8<
#include <string.h>

class SomeClass_t {
public:
  //  SomeClass_t () : x (11) {}
protected:
  float x;
};

class DynamicOnly_t {
public:
  static DynamicOnly_t* create (const char* name = "UNDEF",
				const SomeClass_t& somec = *(new SomeClass_t ())) {
    return new DynamicOnly_t (name, somec);
  }
  DynamicOnly_t (const char* name, const SomeClass_t& somec) :
    m_somec (somec) {
    strncpy (m_Name, name, sizeof (m_Name));
  }
private:
  SomeClass_t m_somec;
  char m_Name[255];
};

int main (int argc, char* argv[]) {
  DynamicOnly_t* ptr = DynamicOnly_t::create ();
  return 0;
}

// compiled with 'gcc test.cpp' where gcc = egcs 1.0 and 971207

Re: Bug in egcs?

[H.J. Lu]

> 
> While porting some code from Visual C++ 5.0 to egcs (I've tried both
> 1.0 and the 971207 release) I came across a problem compiling some of
> the code. I have been able to narrow it down to the 30 lines attached
> to this mail. The relevant error message I get while compiling if I
> _remove_ the comment from the SomeClass_t constructor is:
> 
> test.cpp:13: sorry, not implemented: `try_catch_expr' not supported by
> dump_expr
> 
> If the constructor is commented out, everything works fine and
> dandy. On Microsoft Visual C++ a similar piece of code (which emits
> the same error on the same construction under egcs on linux) compiles
> and runs without any problems.
> 
> Regardless, the error message does not really give me much help in
> figuring this one out. Is there anybody out there with a clue?
> 
> Thanks in advance..
> 
> Marius
> 
> -----8< Code snippet follows -----8<-----8<-----8<-----8<-----8<
> #include <string.h>
> 
> class SomeClass_t {
> public:
>   //  SomeClass_t () : x (11) {}
> protected:
>   float x;
> };
> 
> class DynamicOnly_t {
> public:
>   static DynamicOnly_t* create (const char* name = "UNDEF",
> 				const SomeClass_t& somec = *(new SomeClass_t ())) {
>     return new DynamicOnly_t (name, somec);
>   }
>   DynamicOnly_t (const char* name, const SomeClass_t& somec) :
>     m_somec (somec) {
>     strncpy (m_Name, name, sizeof (m_Name));
>   }
> private:
>   SomeClass_t m_somec;
>   char m_Name[255];
> };
> 
> int main (int argc, char* argv[]) {
>   DynamicOnly_t* ptr = DynamicOnly_t::create ();
>   return 0;
> }
> 
> // compiled with 'gcc test.cpp' where gcc = egcs 1.0 and 971207
> 

I have no problem to compile it with egcs 1.0 on Linux/x86.

-- 
H.J. Lu (hjl@gnu.org)

Re: Bug in egcs?

[H.J. Lu]

> 
> I have no problem to compile it with egcs 1.0 on Linux/x86.
> 
> -- 
> H.J. Lu (hjl@gnu.org)
> 

Ooops. I got the same error.

-- 
H.J. Lu (hjl@gnu.org)

Re: Bug in egcs?

[Jani Hakala]

hjl@lucon.org (H.J. Lu) writes:

> > -----8< Code snippet follows -----8<-----8<-----8<-----8<-----8<
> > #include <string.h>
> > 
> > class SomeClass_t {
> > public:
> >   //  SomeClass_t () : x (11) {}
...
> 
> I have no problem to compile it with egcs 1.0 on Linux/x86.
> 
I had when I uncommented line containing '//  SomeClass_t () : x (11) {}'

pingviini:~> g++ -Wall test.cpp
test.cpp:13: sorry, not implemented: `try_catch_expr' not supported by dump_expr
test.cpp:26: sorry, not implemented: initializer contains unrecognized tree code

pingviini:~> gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.02/specs
gcc version egcs-2.91.02 971206 (gcc-2.8.0)

Re: Bug in egcs?

[Jason Merrill]

>>>>> Marius Kjeldahl <marius@ace.funcom.com> writes:

> test.cpp:13: sorry, not implemented: `try_catch_expr' not supported by
> dump_expr

Does this fix the problem?

Mon Dec 15 12:22:04 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* error.c (dump_expr): Handle TRY_CATCH_EXPR.

Index: error.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/cp/error.c,v
retrieving revision 1.15
diff -c -r1.15 error.c
*** error.c	1997/12/08 00:33:00	1.15
--- error.c	1997/12/15 23:04:56
***************
*** 1534,1539 ****
--- 1534,1544 ----
        OB_PUTS ("{unparsed}");
        break;
  
+     case TRY_CATCH_EXPR:
+     case WITH_CLEANUP_EXPR:
+       dump_expr (TREE_OPERAND (t, 0), nop);
+       break;
+ 
      case TREE_LIST:
        if (TREE_VALUE (t) && TREE_CODE (TREE_VALUE (t)) == FUNCTION_DECL)
  	{

Re: Bug in egcs?

[Marius Kjeldahl]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

>>>>> Marius Kjeldahl <marius@ace.funcom.com> writes:
    >> test.cpp:13: sorry, not implemented: `try_catch_expr' not
    >> supported by dump_expr

    Jason> Does this fix the problem?

[patch removed]

Nope, it yields another error:

test.cpp:13: sorry, not implemented: `cleanup_point_expr' not
supported by dump_expr

Any other suggestions?

Marius

Re: Bug in egcs?

[Jason Merrill]

>>>>> Marius Kjeldahl <marius@ace.funcom.com> writes:

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:
>>>>> Marius Kjeldahl <marius@ace.funcom.com> writes:

>>> test.cpp:13: sorry, not implemented: `try_catch_expr' not
>>> supported by dump_expr

Jason> Does this fix the problem?

> [patch removed]

> Nope, it yields another error:

> test.cpp:13: sorry, not implemented: `cleanup_point_expr' not
> supported by dump_expr

Ah.

Tue Dec 16 10:31:20 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* error.c (dump_expr): And CLEANUP_POINT_EXPR.

Mon Dec 15 12:22:04 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* error.c (dump_expr): Handle TRY_CATCH_EXPR.

Index: error.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/cp/error.c,v
retrieving revision 1.15
diff -c -r1.15 error.c
*** error.c	1997/12/08 00:33:00	1.15
--- error.c	1997/12/16 18:31:18
***************
*** 1534,1539 ****
--- 1534,1545 ----
        OB_PUTS ("{unparsed}");
        break;
  
+     case TRY_CATCH_EXPR:
+     case WITH_CLEANUP_EXPR:
+     case CLEANUP_POINT_EXPR:
+       dump_expr (TREE_OPERAND (t, 0), nop);
+       break;
+ 
      case TREE_LIST:
        if (TREE_VALUE (t) && TREE_CODE (TREE_VALUE (t)) == FUNCTION_DECL)
  	{

Re: Bug in egcs?

[Marius Kjeldahl]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

    >> Nope, it yields another error:

    >> test.cpp:13: sorry, not implemented: `cleanup_point_expr' not
    >> supported by dump_expr

    Jason> Ah.

[patch removed]

Your last patch almost fix it (I tested it with 971207 patched up to
971215). As before, by commenting out the line:

  SomeClass_t () : x (11) {}

it will compile fine. With your latest patch, the compiler does not
complain about that constructor, but it suddenly complains about the
following line instead:

  DynamicOnly_t* ptr = DynamicOnly_t::create ();

The message it gives is:

test.cpp:26: sorry, not implemented: initializer contains unrecognized
tree code

For completeness sake, I have included another copy of the test
program.

Anyway - thanks for helping out!

Marius

-- Test program test.cpp --

#include <string.h>

class SomeClass_t {
public:
  SomeClass_t () : x (11) {}
protected:
  float x;
};

class DynamicOnly_t {
public:
  static DynamicOnly_t* create (const char* name = "UNDEF",
				const SomeClass_t& somec = *(new SomeClass_t ())) {
    return new DynamicOnly_t (name, somec);
  }
  DynamicOnly_t (const char* name, const SomeClass_t& somec) :
    m_somec (somec) {
    strncpy (m_Name, name, sizeof (m_Name));
  }
private:
  SomeClass_t m_somec;
  char m_Name[255];
};

int main (int argc, char* argv[]) {
  DynamicOnly_t* ptr = DynamicOnly_t::create ();
  return 0;
}

Bug in egcs ?

[Laurent Deniau]

Hello,

egcs doesn't complain on the following code:

template <typename T>
class Object {
public:

  // ...

  Object&
  operator = (Object<T> const& e) {
    const_cast<T>(_e) = e;
    return *this;
  }

private:
  T _e;
};


According to the CD2, we should have write :

const_cast<T&>(_e) = e;

in order to get reference to _e.

with best regards,

[ Deniau Laurent -- Numerical Analysis and Signal Processing ]
[    CERN -- The European Laboratory for Particle Physics    ]
[ Laurent.Deniau@cern.ch -- http://wwwinfo.cern.ch/~ldeniau  ]

Re: Bug in egcs ?

[Nathan Myers]

Laurent Deniau wrote:
> egcs doesn't complain on the following code:
> 
> template <typename T>
> struct Object {
>   Object&
>   operator = (Object<T> const& e) {
>     const_cast<T>(_e) = e;
>     return *this;
>   }
>   T _e;
> };
> 
> According to the CD2, we should have write :
> 
> const_cast<T&>(_e) = e;
> 
> in order to get reference to _e.

This code is wrong in any case.  

No cast is needed, generally, to call T::operator= on a
const right-operand.  (auto_ptr<> is a special case.)

In this case, the expression _e already has type T&, because
_e is itself not const, so the const_cast has no effect anyway.  
I don't see how the compiler could be instrumented to detect 
errors like this.

It might be reasonable for the compiler to warn about calling operator= 
with an rvalue left-operand, and perhaps to warn about a cast that has 
no effect.

Nathan Myers
ncm@cantrip.org

Re: Bug in egcs ?

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

>>>>> «Nathan», Nathan Myers <ncm@cygnus.com> wrote:

Nathan> Laurent Deniau wrote:
>> egcs doesn't complain on the following code:
>> 
>> template <typename T>
>> struct Object {
>> Object&
>> operator = (Object<T> const& e) {
>> const_cast<T>(_e) = e;
>> return *this;
>> }
>> T _e;
>> };
>> 
>> According to the CD2, we should have write :
>> 
>> const_cast<T&>(_e) = e;
>> 
>> in order to get reference to _e.

Nathan> This code is wrong in any case.  

Nathan> No cast is needed, generally, to call T::operator= on a
Nathan> const right-operand.  (auto_ptr<> is a special case.)

Nathan> In this case, the expression _e already has type T&, because


In fact in Laurent's former code _e was of type const T (as he told
me). So const_cast<T> (_e) returned an rvalue... And EGCS didn't issue
any diagnostic. I think it should have complained.


-- Gaby