Re: ECGS bug report

Re: ECGS bug report

[Meenaradchagan Vishnu]

> > I got the following error message when compiling the attached file.
> 
> Thanks for your bug report. Unfortunately, it is incomplete. Please
> see http://egcs.cygnus.com/faq.html#bugreport
> 
> Regards,
> Martin

Hi Martin,

Here is a complete bug report.  I am including a small program (6 lines)
which gives
the error message.  I realize that the program has a bug:  The third template
parameter to the priority_queue<> must be a class whereas I am passing a 
function. Nevertheless, I am reporting because I got an Internal Compiler
Error 290.

Best Regards
Meenan

egcs version: 1.1.2
system type: Sun Sparc Solaris
options passed to g++: none
error message:

[columbia:~] g++ junk10.cc
junk10.cc:11: Internal compiler error 290.
junk10.cc:11: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
junk10.cc:11: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

program listing:


#include <queue>

struct Event
  {
    int type;
    double time;
  };

//template specialization for Event*
template<> bool less( Event* e1, Event* e2 )
  {
    return( e1->time < e2->time );
  }

int main()
  {
    priority_queue<Event*, vector<Event*>, less<Event> > pq

    return( 0 );
  }

Re: ECGS bug report

[Martin v. Loewis]

> I got the following error message when compiling the attached file.

Thanks for your bug report. Unfortunately, it is incomplete. Please
see http://egcs.cygnus.com/faq.html#bugreport

Regards,
Martin

ECGS bug report

[Meenaradchagan Vishnu]

I got the following error message when compiling the attached file.

[columbia:~/BFS] g++ -c event_manager.cc
In file included from event_manager.cc:2:
event_manager.hh:11: Internal compiler error 290.
event_manager.hh:11: Please submit a full bug report to 
`egcs-bugs@egcs.cygnus.com'.
event_manager.hh:11: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for 
details.

[columbia:~/BFS] which g++
g++:     aliased to 
/us/swswbld/Compilers/egcs/release/1.1.2/sparc-sun-solaris2.6/bin/g++
>From coryan@cs.wustl.edu Sat Jul 31 23:33:00 1999
From: "Carlos O'Ryan" <coryan@cs.wustl.edu>
To: mrs@wrs.com (Mike Stump)
Cc: coryan@cs.wustl.edu, egcs-bugs@egcs.cygnus.com
Subject: Re: Bug in gcc-2.95 prerelease
Date: Sat, 31 Jul 1999 23:33:00 -0000
Message-id: <14222.22190.75394.275347@macarena.cs.wustl.edu>
References: <199907152134.OAA08254@kankakee.wrs.com>
X-SW-Source: 1999-07n/msg00584.html
Content-length: 2237

Hi,

Mike Stump writes:
 > > 	See my point above: issuing a diagnostic for a situation that
 > > cannot be fixed is (IMHO) a bug;
 > 
 > -fcheck-new should cause the warning/error to go away.  If it doesn't
 > than that _is_ a bug.

$ g++ -W -Wall -fno-exceptions -fcheck-new file.cc
file.cc: In function `static void * Foo::operator new(unsigned int)':
file.cc:57: operator new should throw an exception, not return NULL


  > > the test for "new must throw" should be disabled if exceptions are
 > > disabled.
 > 
 > No, what should be changed is the wording of the message.  This is a
 > minor nit.  If -fcheck-new is in effect, we can remove it.

	Hmmm, changing the wording will not fix it: the compiler wants 
you to throw an exception from operator new when exceptions are
disabled, 

 > > 	Sure, i only have to change 1,000,000 lines of code to do that
 > 
 > If you lucky, you can
 > 
 > #define new new(nothrow)
 > 
 > in your .h file, this is a small change.

	I was trying to make a small joke, we have been dealing with
different ways to report problems in new for quite sometime now (over
2 years i would say); including platforms that throw std::bad_alloc,
throw xalloc or return 0.  BTW, i new about the pre-processor trick,
you probably also read the discussion in USENET about the problems
with that approach.


 > > 	Hmmm, from the flag documentation it would seem like this will 
 > > fix the run-time behavior; i'm not complaining about the resulting
 > > run-time behavior;
 > 
 > That's unfortunate.  It means you haven't tested the code any (when
 > you return 0).  It should be near useless without it.

	Uh? It seems i'm unable to express my points today, we *do*
check for failures, whatever way operator new chooses to report them.
	I was pointing out that the documentation for -fcheck-new
talks about the run-time behavior of the generated code, not about the
diagnostics it will generate, in fact as pointed out above it does
*not* change the diagnostics.
	You are right though that -fcheck-new seems like a good idea
when exceptions are disabled, thanks for the tidbit.

-- 
Carlos O'Ryan (coryan@cs.wustl.edu)
#include <std.disclaimer>
#include <cute.quote> // "Speak softly and carry a megawatt laser"