Re: Bug in gcc-2.95 prerelease

Re: Bug in gcc-2.95 prerelease

[Mike Stump]

Lie to the compiler at your own risk.  These are not bugs...

You are free to use nothrow new calls, if you want.  Also you are free to
raise a signal or call exit or abort to indicate error as well.
If you insist on doing what you want, you will need -fcheck-new, but at some
point, this flag will go away.  It is a backwards compatibility hack
for people that are doing what you do.
>From tudor.hulubei@ecora.com Thu Jul 15 11:14:00 1999
From: Tudor Hulubei <tudor.hulubei@ecora.com>
To: egcs-bugs@egcs.cygnus.com
Subject: Internal compiler error 754867
Date: Thu, 15 Jul 1999 11:14:00 -0000
Message-id: <14222.9308.807935.755033@data.ecora.com>
X-SW-Source: 1999-07/msg00575.html
Content-length: 762

Hello,

I've reported this on July 6th, but it looks like it didn't get
through (at least I haven't got it back through the list).  Here it is 
again:

The following C++ code triggers an internal compiler error under
RedHat 6.0 with the stock egcs (1.1.2):

#include <iostream>

int
main()
{
    (((void) (cout)) ? 1 : 0);
    return 0;
}

[tudor@data]:~ $ c++ t.cc
t.cc: In function `int main()':
t.cc:7: Internal compiler error 754867.
t.cc:7: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
t.cc:7: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

[tudor@data]:~ $ c++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Regards,
Tudor

Re: Bug in gcc-2.95 prerelease

[Carlos O'Ryan]

Hi,

Martin v. Loewis writes:
 > > // IMHO (1) is clearly a bug, if exceptions are disabled then the only
 > > // way to report errors from "operator new" is to return 0
 > > // This is non-conforming with the C++ spec, but also is
 > > // disabling exceptions ;-)
 > 
 > I agree this is surprising behaviour. However, it is out-of-scope of
 > the C++ standard

	Yes.

 > (since there is no -fno-exceptions in standard c++),

	That's what i was trying to say....

 > so you are on your own.

	Hmmm, i would expect that if the compiler supports
-fno-exceptions then it should behave "correctly" for it. Requiring
the user to throw exceptions when exceptions are disabled doesn't fit
my definition of correct behavior.

 > You can use -fpermissive to have g++ accept
 > that code.

	and lose other (really good, btw) error messages? I'd rather
do the hack with the temporary variable....

Mike Stump writes:
 > Lie to the compiler at your own risk.

	I'm not lying to the compiler: i disabled exceptions and the
compiler is asking me to raise one, if i try to raise it the compiler
says i can't.  Admiteddly i'm using a non-standard, maybe not even
popular set of options, but nevertheless a supported one.

 >  These are not bugs...

	See my point above: issuing a diagnostic for a situation that
cannot be fixed is (IMHO) a bug; the test for "new must throw" should
be disabled if exceptions are disabled.

 > You are free to use nothrow new calls, if you want.

	Sure, i only have to change 1,000,000 lines of code to do that 
;-) ;-)  actually it is not that bad, i have a workaround, i can use
and i thought people may want to know about the problem. The error is
actually helping me find the problems, but i will probably have to
maintain code for platforms with and without exceptions for a
while, minimizing the number of hacks for all those platforms would be 
nice.

 >  Also you are free to
 > raise a signal or call exit or abort to indicate error as well.

	somehow i feel like my users will not like that ;-) ;-)

 > If you insist on doing what you want, you will need -fcheck-new,

	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; though i should probably think twice before using
that overloaded operator new on with standard containers (assuming
again that i also disable exceptions).

 > but at some
 > point, this flag will go away.  It is a backwards compatibility hack
 > for people that are doing what you do.

	Fine.

	My only complaint is that *if* exceptions are disabled (have
no problems with it if exceptions are enabled), this particular
diagnostic is at least misleading and i would even say that it is
plain wrong.  In fact the problem is fairly easy to fix, and here is
the patch:

---------------- cut here ----------------
--- typeck.c.orig       Thu Jul 15 13:50:39 1999
+++ typeck.c    Thu Jul 15 13:51:42 1999
@@ -7352,7 +7352,8 @@
   if ((DECL_NAME (current_function_decl) == ansi_opname[(int) NEW_EXPR]
        || DECL_NAME (current_function_decl) == ansi_opname[(int) VEC_NEW_EXPR])
       && !TYPE_NOTHROW_P (TREE_TYPE (current_function_decl))
-      && null_ptr_cst_p (retval))
+      && null_ptr_cst_p (retval)
+      && doing_eh (0))
     cp_pedwarn ("operator new should throw an exception, not return NULL");
   
   if (retval == NULL_TREE)
---------------- cut here ----------------


			I hope that helps.
-- 
Carlos O'Ryan (coryan@cs.wustl.edu)
#include <std.disclaimer>
#include <cute.quote> // "Speak softly and carry a megawatt laser"
>From toon@moene.indiv.nluug.nl Thu Jul 15 12:52:00 1999
From: Toon Moene <toon@moene.indiv.nluug.nl>
To: craig@jcb-sc.com
Cc: dmg@bell-labs.com, "John W. Eaton" <jwe@bevo.che.wisc.edu>, bug-octave@bevo.che.wisc.edu, egcs-bugs@egcs.cygnus.com, Thomas Hoffmann <hoffmann@ehmgs2.et.tu-dresden.de>
Subject: Re: [jwe@bevo.che.wisc.edu: Crashing after complex division by zero]
Date: Thu, 15 Jul 1999 12:52:00 -0000
Message-id: <378E3B3C.AD755950@moene.indiv.nluug.nl>
References: <19990714171536.16205.qmail@deer>
X-SW-Source: 1999-07/msg00578.html
Content-length: 2394

craig@jcb-sc.com wrote:

> Enclosed is a bug report against libF77.  I'm not sure how valid the
> complaint is, or what all the implications of making the recommended
> change are.  I'm pretty sure we won't be making any g77-specific patches
> to libf2c (in what we call libg2c) anymore, except in specific instances,
> such as when we're pretty sure you're going to make the same bug-fix
> shortly anyway -- definitely not the case here!

Well, you will be surprised to hear this from me, but it is a correct
move in the direction of making libF77 IEEE-conformant (so it is a long
term bug-fix).

In fact, because I anticipated the interest in IEEE-conformant
programming, I already designed my open-coded complex division in
optabs.c likewise.

[ducks]

My line of reasoning at that time was:

1. I don't know how to code
	sig_die("complex division by zero", 1);
   in optabs.c

2. However, I won't have to, when I adhere to the following principle:
   The division that's part of complex division will abort itself,
   iff the CPU is placed in a mode that enforces 
   trap-on-divide-by-zero and the trap leads to an abort.

3. This means that complex-divide-by-zero won't abort on IEEE conformant
   hardware by default, but we should change that silly default
   anyway.

[ducks 2]

[ sprinkle the above with smiley's liberately ]

> Also, I'll note that, as of gcc 2.95 aka g77 0.5.25, libg2c's c_div and
> z_div routines aren't used by default anymore.  But they're still used
> if the user compiles with the `-Os' (optimize for space) option, so we're
> still interested in keeping them current vis-a-vis netlib libf2c.

Of course, that means that programs compiled with -Os do not perform the
same computation as those compiled with other options.  I'm sorry I
forgot to point that out.

John Eaton's Octave example points out why this do-not-abort-on-complex-
divide-by-zero can be useful (especially when coupled to "passing the
buck up"):  Octave could deliver a meaningful message to the user,
instead of dumping core itself; or it could enable a user program to
receive the trap [I do not really know if that can be done in Octave's
language - perhaps John can point that out].

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html
>From arras@intertv.com Thu Jul 15 13:05:00 1999
From: Michael Arras <arras@intertv.com>
To: egcs-bugs@egcs.cygnus.com
Subject: egcs-19990714 C++ -O Creates Wrong Code on SPARC
Date: Thu, 15 Jul 1999 13:05:00 -0000
Message-id: <378E3F17.77A12491@intertv.com>
X-SW-Source: 1999-07/msg00579.html
Content-length: 1287

// The following C++ program demonstrates a bug in egcs-1990714
// and egcs-1.1.2 on Solaris 2.5, 2.6 and 7 SPARC.
//
// To see bug compile with `g++ -O optbug.cxx'.  The output
// should be "Catch 0" 4 times.  "Catch 1" should never be
// printed.
//
// The bug does not occur with egcs compiled on IRIX 6.5 MIPS or
// Linux 2.2 x86.
//
// When compiled with -O(1-3), value is set to true, even though
// f2() always throws an exception.
//
// When compiled with -O3 -fno-delayed-branch (or no optimization
// at all) the program works as it should.
//
// The loop and "++odd %2" are there so egcs does not optimize the
// bug out.  The bug was discovered in production code.

#include <iostream>
#include <exception>

int odd = 0;

void f1(void) throw(exception)
{
    if (++odd % 2)
        throw exception();
}

void f2(void) throw(exception)
{
    throw exception();     // Always
}

main(int c, char **v)
{
    for (int i = 0; i < 4; i++)
    {
        bool value = false;

        try
        {
            f1();
            f2();
            // Should never get here
            value = true;
            cout << "Try ";
        }
        catch (...)
        {
            cout << "Catch ";
        }

        // value should never be true
        cout << value << endl;
    }
}
>From sylv@tiem.utk.edu Thu Jul 15 13:20:00 1999
From: Scott Sylvester <sylv@tiem.utk.edu>
To: egcs-bugs@egcs.cygnus.com
Cc: sylv@tiem.utk.edu
Subject: EGCS bug
Date: Thu, 15 Jul 1999 13:20:00 -0000
Message-id: <19990715202041.15677.qmail@bufo.tiem.utk.edu>
X-SW-Source: 1999-07/msg00580.html
Content-length: 1585

To Whom it may concern, 
	I've found what I believe to be a bug in EGCS which is not listed among the 
"Known Bugs".

I'm running EGCS on a Sun Ultra Sparc 1 running Solaris 2.5

EGCS version:
bufo>g++ -v
Reading specs from /diamond/homes/sylv/usr/local/lib/gcc-lib/sparc-sun-solaris2
.5/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

The .ii file created from the code which causes the error is:


# 1 "main.cc"
namespace NS {
	const int DefaultValue = -1;
};

template<class T>
class A
{
	public:
		A( int ai_value = NS::DefaultValue ) {}  
};

main()
{
}



compilation is carried out with:
bufo>g++ main.cc -o main
the results of this command are:
main.cc:9: sorry, not implemented: `namespace_decl' not supported by dump_type

Since the code on line nine appears to be completely valid, and other 
compilers handle this just fine, and similar code in non-templated classes is 
just fine, I assume the error message is incorrect.

Thank you for your time,
Scott Sylvester.

************************************************************************
Scott M. Sylvester               |E-mail: sylv@tiem.utk.edu
UTK Dept. of EEB                 |Web: http::/www.tiem.utk.edu/~sylv
569 Dabney Hall                  |Phone: (423) 974-0223 or(423) 974-3065
Knoxville TN 37996-1610          |Fax: (423) 974-3067
------------------------------------------------------------------------
Working in: 
	104 Hoskins Library... you will never find a more 
	wretched hive of scum and villiany.
************************************************************************

Re: Bug in gcc-2.95 prerelease

[Martin v. Loewis]

> 	Hmmm, i would expect that if the compiler supports
> -fno-exceptions then it should behave "correctly" for it. Requiring
> the user to throw exceptions when exceptions are disabled doesn't fit
> my definition of correct behavior.
[-fpermissive]
> 	and lose other (really good, btw) error messages? I'd rather
> do the hack with the temporary variable....

Ok. So what do you want to hear? You've found a work-around; go ahead
an use it.

While I think the compiler behaviour could be improved here, it is not
a very high priority on my list (given the long list of real
bugs). Feel free to submit a patch to egcs-patches@egcs.cygnus.com if
you think this absolutely must be fixed.

Regards,
Martin

Re: Bug in gcc-2.95 prerelease

[Martin v. Loewis]

> // IMHO (1) is clearly a bug, if exceptions are disabled then the only
> // way to report errors from "operator new" is to return 0
> // This is non-conforming with the C++ spec, but also is
> // disabling exceptions ;-)

I agree this is surprising behaviour. However, it is out-of-scope of
the C++ standard (since there is no -fno-exceptions in standard c++),
so you are on your own. You can use -fpermissive to have g++ accept
that code.

Regards,
Martin

Re: Bug in gcc-2.95 prerelease

[Mike Stump]

> From: "Carlos O'Ryan" <coryan@cs.wustl.edu>
> Date: Thu, 15 Jul 1999 16:55:11 -0500 (CDT)

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

The compiler doesn't _want_ that.  Ignore it.  What the compiler
wants, is for you to not return NULL.  Don't do that, it is wrong, the
compiler knows it and doing it is guaranteed 100% to screw your code.
There is no question about it.

You can claim otherwise, but this can only be through ignorance or
shortsightedness.

Sure, I agreed that the wording is bogus.  That can be fixed.  Sure,
it should omit this if -fcheck-new is given, that can be fixed.

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

You have failed to understand.  It is not your code I worry about not
checking, I can trivially assume that you will check, that isn't the
problem.  The problem comes when the code faults due to magic code the
compiler generates behind your back that you have no control over
(other than -fcheck-new) because of the NULL.

You can ignore me and not give -fcheck-new and then in 20 months when
in an obscure case your code crashes and you submit a but report for
it, I can then tell you to use this option and _then_ you can know why
I suggested it...

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

Like I said, that is a bug that can be fixed.

Re: Bug in gcc-2.95 prerelease

[Mike Stump]

> From: "Carlos O'Ryan" <coryan@cs.wustl.edu>
> Date: Thu, 15 Jul 1999 14:13:50 -0500 (CDT)

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

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

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

>  > If you insist on doing what you want, you will need -fcheck-new,

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

> 	My only complaint is that *if* exceptions are disabled (have
> no problems with it if exceptions are enabled), this particular
> diagnostic is at least misleading and i would even say that it is
> plain wrong.  In fact the problem is fairly easy to fix, and here is
> the patch:

> ---------------- cut here ----------------
> --- typeck.c.orig       Thu Jul 15 13:50:39 1999
> +++ typeck.c    Thu Jul 15 13:51:42 1999
> @@ -7352,7 +7352,8 @@
>    if ((DECL_NAME (current_function_decl) == ansi_opname[(int) NEW_EXPR]
>         || DECL_NAME (current_function_decl) == ansi_opname[(int) VEC_NEW_EXPR])
>        && !TYPE_NOTHROW_P (TREE_TYPE (current_function_decl))
> -      && null_ptr_cst_p (retval))
> +      && null_ptr_cst_p (retval)
> +      && doing_eh (0))
>      cp_pedwarn ("operator new should throw an exception, not return NULL");
>    
>    if (retval == NULL_TREE)

Re: Bug in gcc-2.95 prerelease

[Carlos O'Ryan]

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"
>From Franz.Sirl-kernel@lauterbach.com Thu Jul 15 15:02:00 1999
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: egcs-bugs@egcs.cygnus.com
Cc: "T.Ueda" <ueda@power.elec.kitami-it.ac.jp>
Subject: Re: Fwd: Help! Fortran call from C on LinuxPPC-R5
Date: Thu, 15 Jul 1999 15:02:00 -0000
Message-id: <99071600025900.06989@ns1102.munich.netsurf.de>
References: <4.2.0.58.19990715163648.05778290@mail.lauterbach.com>
X-SW-Source: 1999-07/msg00585.html
Content-length: 2382

I looked at the generated code for f22.f a bit closer and I think it's totally
broken (the compiler even notices that, with -O2 all is optimized away :-) ).

Could one of the Fortran guys please look at this? I don't know where to start
here or if the the source is valid at all. I could even offer an account on a
Linux/PPC machine if necessary.

Franz.


Am Don, 15 Jul 1999 schrieb Franz Sirl:
>Hi,
>
>this was just reported on the linuxppc-dev list. R5 means that he is using 
>egcs-1.1.2, but I just verified that this is still present in gcc-2.95.
>
>Franz.
>
>
>>X-Mailer: Macintosh Eudora Pro Version 4.0.1Jr1
>>Date: Thu, 15 Jul 1999 17:57:42 +0900
>>To: linuxppc-dev@lists.linuxppc.org
>>From: "T.Ueda" <ueda@power.elec.kitami-it.ac.jp>
>>Subject: Help! Fortran call from C on LinuxPPC-R5
>>Sender: owner-linuxppc-dev@lists.linuxppc.org
>>X-Mailing-List: <linuxppc-dev@lists.linuxppc.org>
>>X-Loop: linuxppc-dev@lists.linuxppc.org
>>
>>Hi,
>>
>>I am checking a simple program that Fortran calls C  using LinuxPPC-R5 on 
>>PowerBookG3.
>>
>>It seems that real fuction call of fortran may wrong.
>>Why 2147482368.000000 in the case of calling real function?? ( real and 
>>float are not same bytes?)
>>
>>Anyone know the reason?
>>
>>
>>Tac@Japan
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>[complile& run]
>>f77 -c f2.f
>>f77 -c f22.f
>>f77 -c f3.f
>>f77 -c f33.f
>>gcc main.c f2.o f22.o f3.o f33.o
>>a.out
>>Result: 5  --> 25  2147482368.000000  125   125.000000
>>
>>Why 2147482368.000000?? ( real and float are not same size?)
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>/*   (1)main.c  */
>>#include <stdio.h>
>>
>>int main() {
>>   float y22, y33;
>>   int x=5;
>>   int y2, y3;
>>
>>   y2=f2_(&x);
>>   y22=f22_(&x);
>>   f3_(&x, &y3);
>>   f33_(&x, &y33);
>>   printf("%d  --> %d  %f  %d   %f \n", x, y2, y22, y3, y33);
>>    return 0;
>>}
>>~~~~~~~~~~~~~~~~~~
>>C    (2)f2.f
>>     integer  function f2(x)
>>       integer x
>>       f2=x*x
>>       end
>>~~~~~~~~~~~~~~~~~~
>>C   (3) f22.f
>>       real function f22(x)
>>       integer x
>>       f22=x*x
>>       end
>>~~~~~~~~~~~~~~~~~~
>>C   (4) f3.f
>>       subroutine f3(x,y)
>>       integer x, y
>>       y=x*x*x
>>       end
>>~~~~~~~~~~~~~~~~~~
>>C   (5) f33.f
>>       subroutine f33(x,y)
>>       integer x
>>       real y
>>       y=x*x*x
>>       end
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>From mrs@wrs.com Thu Jul 15 15:16:00 1999
From: mrs@wrs.com (Mike Stump)
To: coryan@cs.wustl.edu
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Bug in gcc-2.95 prerelease
Date: Thu, 15 Jul 1999 15:16:00 -0000
Message-id: <199907152216.PAA08595@kankakee.wrs.com>
X-SW-Source: 1999-07/msg00586.html
Content-length: 2652

> From: "Carlos O'Ryan" <coryan@cs.wustl.edu>
> Date: Thu, 15 Jul 1999 16:55:11 -0500 (CDT)

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

The compiler doesn't _want_ that.  Ignore it.  What the compiler
wants, is for you to not return NULL.  Don't do that, it is wrong, the
compiler knows it and doing it is guaranteed 100% to screw your code.
There is no question about it.

You can claim otherwise, but this can only be through ignorance or
shortsightedness.

Sure, I agreed that the wording is bogus.  That can be fixed.  Sure,
it should omit this if -fcheck-new is given, that can be fixed.

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

You have failed to understand.  It is not your code I worry about not
checking, I can trivially assume that you will check, that isn't the
problem.  The problem comes when the code faults due to magic code the
compiler generates behind your back that you have no control over
(other than -fcheck-new) because of the NULL.

You can ignore me and not give -fcheck-new and then in 20 months when
in an obscure case your code crashes and you submit a but report for
it, I can then tell you to use this option and _then_ you can know why
I suggested it...

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

Like I said, that is a bug that can be fixed.
>From drow@false.org Thu Jul 15 15:40:00 1999
From: Daniel Jacobowitz <drow@false.org>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: egcs-bugs@egcs.cygnus.com, "T.Ueda" <ueda@power.elec.kitami-it.ac.jp>
Subject: Re: Fwd: Help! Fortran call from C on LinuxPPC-R5
Date: Thu, 15 Jul 1999 15:40:00 -0000
Message-id: <19990715184120.A7216@drow.res.cmu.edu>
References: <4.2.0.58.19990715163648.05778290@mail.lauterbach.com> <99071600025900.06989@ns1102.munich.netsurf.de>
X-SW-Source: 1999-07/msg00587.html
Content-length: 1429

On Thu, Jul 15, 1999 at 11:57:13PM +0200, Franz Sirl wrote:
> I looked at the generated code for f22.f a bit closer and I think it's totally
> broken (the compiler even notices that, with -O2 all is optimized away :-) ).

I didn't see that behavior here...

> >>It seems that real fuction call of fortran may wrong.
> >>Why 2147482368.000000 in the case of calling real function?? ( real and 
> >>float are not same bytes?
> >>
> >>Anyone know the reason?

You need prototypes in main.c.  This made the problem go away:

int f2_(int *x);
float f22_(int *x);
void f3_(int *x, int *y);
void f33_(int *x, float *y);

Perhaps, it should be float rather than double, I don't know.  Without
a prototype, though, even though you assign the return value of f22_ to
a float, it is assumed to be an int.

gcc -Wall gives the ever-useful:
main.c:14: warning: implicit declaration of function `f2_'
main.c:15: warning: implicit declaration of function `f22_'
main.c:16: warning: implicit declaration of function `f3_'
main.c:17: warning: implicit declaration of function `f33_'



Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/
>From oliva@dcc.unicamp.br Thu Jul 15 16:16:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Tudor Hulubei <tudor.hulubei@ecora.com>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error 754867
Date: Thu, 15 Jul 1999 16:16:00 -0000
Message-id: <orlnchqzbn.fsf@cupuacu.lsd.dcc.unicamp.br>
References: <14222.9308.807935.755033@data.ecora.com>
X-SW-Source: 1999-07/msg00588.html
Content-length: 568

On Jul 15, 1999, Tudor Hulubei <tudor.hulubei@ecora.com> wrote:

> I've reported this on July 6th, but it looks like it didn't get
> through (at least I haven't got it back through the list).

AFAIR, it did, and I even replied telling you the bug had already been 
fixed for gcc 2.95

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Bug in gcc-2.95 prerelease

[Carlos O'Ryan]

The file included below is (i believe) self explanatory:

---------------- cut here ----------------
#include <new>

// $ g++ -v
// Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/specs
// gcc version 2.95 19990714 (prerelease)
// Linux bambuca 2.2.10 #1 SMP Fri Jun 25 13:33:38 CDT 1999 i686 unknown
//
// 1) Using the following options we get an error:
//
// $ g++ -W -Wall -fno-exceptions 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
//
// 2) Trying to throw an exception obviously does not work:
//
// $ g++ -W -Wall -fno-exceptions -DTRY_THROWING file.cc
// file.cc: In function `static void * Foo::operator new(unsigned int)':
// file.cc:48: exception handling disabled, use -fexceptions to enable
// file.cc:60: warning: control reaches end of non-void function `Foo::operator new(unsigned int)'
//
// 3) There is a work around:
// g++ -fno-exceptions -W -Wall -DTHIS_WILL_FOOL_EGCS -c file.cc
//
// IMHO (1) is clearly a bug, if exceptions are disabled then the only
// way to report errors from "operator new" is to return 0
// This is non-conforming with the C++ spec, but also is
// disabling exceptions ;-)
//
// (2) looks OK, and is included just for the sake of completeness...
// (3) could be added to your FAQ or database as a work around. Some
//     people would argue that the workaround itself is a bug 8-)
//
//      I hope that helps, please feel free to contact me at:
//
//      coryan@cs.wustl.edu
//
//      for more details.

class Foo
{
public:
  Foo () {}
  
  void* operator new (size_t /* n */) {

#if defined(TRY_THROWING)

    throw std::bad_alloc ();

#elif defined(THIS_WILL_FOOL_EGCS)

    static void* silly_egcs_does_not_want_a_null = 0;
    return silly_egcs_does_not_want_a_null;

#else

    return 0;

#endif
  }

};
---------------- cut here ----------------

-- 
Carlos O'Ryan (coryan@cs.wustl.edu)
#include <std.disclaimer>
#include <cute.quote> // "Speak softly and carry a megawatt laser"
>From oliva@dcc.unicamp.br Wed Jul 14 21:36:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: hjl@varesearch.com (H.J. Lu)
Cc: egcs-bugs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library)
Subject: Re: A bad gcc 2.95 bug
Date: Wed, 14 Jul 1999 21:36:00 -0000
Message-id: <or673mmsw3.fsf@cupuacu.lsd.dcc.unicamp.br>
References: <19990714193206.B31013FC1@varesearch.com>
X-SW-Source: 1999-07/msg00549.html
Content-length: 470

On Jul 14, 1999, hjl@varesearch.com (H.J. Lu) wrote:

> Why does it return in gcc 2.95?

gcc 2.95 has become much stricter about C++ rules.  You need
-fpermissive to get it less strict.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them