A bad gcc 2.95 bug

A bad gcc 2.95 bug

[H.J. Lu]

Hi,

With egcs 1.1.2, I got

# gcc foo.cc
foo.cc:4: warning: declaration of `exit(int)' throws different exceptions
foo.cc:3: warning: previous declaration here

But with gcc 2.95 19990711, now I got
# gcc foo.cc
foo.cc:4: declaration of `exit(int)' throws different exceptions
foo.cc:3: previous declaration here

That is a bug fixed for egcs 1.1.2. Why does it return in gcc 2.95?
It will screw up glibc. It has to be fixed in gcc 2.95.

-- 
H.J. Lu (hjl@gnu.org)
---foo.cc-
extern "C" {
void exit (int);
void exit (int) __attribute__ ((__noreturn__));
void exit (int) throw () __attribute__ ((__noreturn__));
};
>From egdorf@zaphod.lanl.gov Wed Jul 14 17:03:00 1999
From: egdorf@zaphod.lanl.gov (Skip Egdorf)
To: egcs-bugs@egcs.cygnus.com
Cc: d.love@dl.ac.uk, hwe@lanl.gov
Subject: Another scratch-file bug
Date: Wed, 14 Jul 1999 17:03:00 -0000
Message-id: <199907141906.NAA03434@zaphod.lanl.gov>
X-SW-Source: 1999-07/msg00535.html
Content-length: 4472

> >Your patch mentioned above seems to be suspiciously similar to what I am
> >seeing. Could you send me some more details on what the problem was with
> >rewind and scratch files? Any other hints on where I should look??
> 
> I'm not sure, but I *think* this problem might have already been found
> and fixed for gcc 2.95, aka egcs 1.2, which should be released very
> soon (maybe around this weekend).  If you want to try a prerelease
> (snapshot or CVS-readonly checkout), or need other info on EGCS, see:
> 
>   < http://egcs.cygnus.com/ >
> 
> Also, I have a little g77 web page at < http://world.std.com/~burley/g77.html >.
> 
>         tq vm, (burley)
> 

Well, I have it boiled out of my 100K-line legacy Fortran code, and the bug
is still in the current (june 28) egcs release.

I have fetched the egcs-19990629 version. It and glibc-2.1.1 are fresh-built
from sources on my RedHat-6.0 Linux box for debugging. I have removed the
RedHat compilers and libraries from the system, and this egcs and glibc are
now the sytstem defaults. By the way, this egcs seems to work fine for building
the kernel (2.2.10) and the glibc stuff.

The following program dumps core on both Linux and Solaris with g77 later than
0.5.21 or so. I will include info from the Linux box as it was my debugging
platform. The unit=39 and the extra backpace and rewind are there only because
this is the sequence in the old large legacy code. The "endfile" is the culprit.

This is the "test1.F" file compiled below.
---
      program main
      character*5 buf
 10   format (1x,a5)
c
      open (unit=39,status='scratch')
      write (39,10) 'line1'
      write (39,10) 'line2'
c
      backspace 39
      endfile 39
      rewind 39
c
      do 100 i = 1, 2
         read (39,10) buf
         write (*,*) buf
 100     continue
      stop
      end
---
System information and build is (although it also happens on Solaris...)
---
dilbert% uname -a
Linux dilbert.lanl.gov 2.2.10 #1 Wed Jul 7 13:30:18 MDT 1999 i586 unknown
dilbert% g77 -g -o test1 test1.F
dilbert% ./test1
fmt: end of file
apparent state: unit 39 named /tmp/fort.AopL42
last format: (1X,A5)
lately reading sequential formatted external IO
Abort (core dumped)
dilbert%
dilbert% g77 --version
GNU Fortran 0.5.25 19990628 (prerelease)
Copyright (C) 1997 Free Software Foundation, Inc.
For more version information on components of the GNU Fortran
compilation system, especially useful when reporting bugs,
type the command `g77 --verbose'.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
or type the command `info -f g77 Copying'.
dilbert%
---

The iot() happens at the first "read". There is plenty of stuff in the
FILE *'s buffer, but the _IO_NO_READS flag has been turned on in the
struct FILE._flags word for unit 39. (check bit 0x4 of
f__units[39]->ufd->_flags)

Following through with gdb, the culpret seems to be the "endfile" statement.

The open works correctly with the fopen on line 251 of libI77/open.c
using mode "r+w" as it should. A "scratch" file can be both written and read.
f__units[39]->ufd->_flags has bits 0x06 zeroed...

In endfile.c, down at line 101 in t_runc(), the file is freopened() with
a mode of "w" only. <-- this is the error. The "read"ability of the file gets
lost. f__units[39]->ufd->_flags has bit 0x04 turned on.

Thus, when the read happens, the getc returns -1 with errno set to EBADF, because
the _flags word of the FILE structure has bit 0x04 turned on (_IO_NO_READS)
which is translated into EOF in fmt.c line 474. (The place in glibc-2.1.1 is
in _IO_new_file_underflow() line 349 in libio/fileops.c  called from getc
if anyone cares to dig that deep, but all that is proper, I think, given that
the file is opened for writting only...)

The problem is clearly that the system should remember that the scratch file
is open for "r+w" when it re-opens it in the endfile. I think I see the path
through the code, and I understand why the tempfile/copy stuff is going on
(endfile may have been done on a rewound - half-way-through file and so a
truncate must be done if we are on a seekable file... right?)

However, I don't really have enough of a grasp on how all the other pieces
fit together to suggest a proper fix. Suggestions on what else I should do are
welcome...

					Skip Egdorf
					hwe@lanl.gov
>From hjl@varesearch.com Wed Jul 14 17:03:00 1999
From: hjl@varesearch.com (H.J. Lu)
To: jason@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), egcs@egcs.cygnus.com
Subject: Your g++ breaks glibc.
Date: Wed, 14 Jul 1999 17:03:00 -0000
Message-id: <19990714195521.1BA043FC1@varesearch.com>
X-SW-Source: 1999-07/msg00534.html
Content-length: 1214

Hi,

Your change:

1998-12-07  Jason Merrill  <jason@yorick.cygnus.com>

        * decl.c (init_decl_processing): If neither -fpermissive or -pedantic
	were specified, set flag_pedantic_errors.

breaks glibc. That is a code fragment generated by autoconf. With gcc
2.95, I got

# gcc -S bar.cc
In file included from bar.cc:5:
/usr/include/stdlib.h:520: declaration of `exit(int)' throws different exceptions
bar.cc:2: previous declaration here

egcs 1.1.2 only gives a warning. It should be fixed in gcc 2.95.

How does this patch sound?

--- ../../import/gcc-2.95/egcs/gcc/cp/decl.c	Fri Jul  9 08:32:50 1999
+++ gcc/cp/decl.c	Wed Jul 14 12:51:56 1999
@@ -3516,7 +3516,8 @@ duplicate_decls (newdecl, olddecl)
 	  TREE_TYPE (olddecl) = build_exception_variant (newtype,
 							 TYPE_RAISES_EXCEPTIONS (oldtype));
 
-	  if ((pedantic || ! DECL_IN_SYSTEM_HEADER (olddecl))
+	  if ((pedantic || (! DECL_IN_SYSTEM_HEADER (olddecl)
+	  		    && ! DECL_IN_SYSTEM_HEADER (newdecl)))
 	      && DECL_SOURCE_LINE (olddecl) != 0
 	      && flag_exceptions
 	      && ! compexcepttypes (TREE_TYPE (newdecl), TREE_TYPE (olddecl)))

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
extern "C" {
void exit (int);
};

#include <stdlib.h>
>From ian@tharas.com Wed Jul 14 17:04:00 1999
From: Ian Nixon <ian@tharas.com>
To: egcs-bugs@egcs.cygnus.com
Subject: Internal compiler error: name confusion in template?
Date: Wed, 14 Jul 1999 17:04:00 -0000
Message-id: <378CFF56.F474B844@tharas.com>
X-SW-Source: 1999-07/msg00539.html
Content-length: 985

  Using:

Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

  The following code:

template <class Key> struct hash {
  void operator()(Key c) const {}
};

template <class Key, class Functor>
class Hash {
 public:

  void Add (Key k) {
	Functor f;
	f.hash (k);
  }

};

struct functor
{
  void hash (const char *k) const {
	::hash<const char *> hf;
	hf (k);
  }
};

main ()
{

  Hash<const char *,functor> Table;

  Table.Add ("Wibble");

}

  produces this:

g++ code.cc -o code
code.cc: In method `void Hash<const char *,functor>::Add<const char *,
functor>(const char *)':
code.cc:30:   instantiated from here
code.cc:12: Internal compiler error.
code.cc:12: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'.
code.cc:12: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for
details.

  changing the name of one of the hash functions so there is no clash
removes
the problem.
>From tom@ait-tech.com Wed Jul 14 17:04:00 1999
From: Tomislav Goles <tom@ait-tech.com>
To: egcs-bugs@egcs.cygnus.com
Subject: another egcs-g77 + LAPACK inconsistency?
Date: Wed, 14 Jul 1999 17:04:00 -0000
Message-id: <u9673nt1w3.fsf@ait-tech.com>
X-SW-Source: 1999-07/msg00536.html
Content-length: 1082

I'm using egcs-1.1.2 on linux and have just noticed
that LAPACK function dlamch_('P') which is supposed
to return machine precision returns different values
depending on whether it's compiled with -O0 or 
-O[123] flag(s).

When dlamch.f is g77 compiled with -O0 it returns: 2.220446E-16

With -O3 it returns: 4.440892E-16 

These numbers are actually output by my g++ driver
program which links to dlamch.o.

This (problem?) seems to only happen on linux - I tried this
on HPUX 10.01 and 10.20 and in that case 2.220446E-16
is always returned. I also compiled this on solaris 2.5.1
with Sun's fortran compiler and I again got 2.220446E-16
(optimized or not). I don't know whether this has
anything to do with the other g77 vs LAPACK issues that have
been discussed recently, but figured others may be
interested to know (since this function is called by
many other higher level functions).

BTW, this happens with both LAPACK 2.0 and LAPACK 3.0.

Finally, my linux info:
% uname -a
Linux tgmontreal 2.2.5-15 #1 Mon May 3 15:39:19 EDT 1999 i686 unknown

Best regards,
Tomislav Goles
>From toon@moene.indiv.nluug.nl Wed Jul 14 17:04:00 1999
From: Toon Moene <toon@moene.indiv.nluug.nl>
To: martin.kahlert@mchp.siemens.de
Cc: craig@jcb-sc.com, egcs-bugs@egcs.cygnus.com
Subject: Re: Bug with g77 and -mieee on Alpha Linux
Date: Wed, 14 Jul 1999 17:04:00 -0000
Message-id: <378CE789.9F3F773C@moene.indiv.nluug.nl>
References: <3783B4B1.89DC2124@moene.indiv.nluug.nl> <19990708135500.12573.qmail@deer> <3784BE26.D14F95CD@blueskystudios.com> <19990708155845.13652.qmail@deer> <19990708111645.A6051@cygnus.com> <37850FE1.94D5B63D@moene.indiv.nluug.nl> <19990709021223.16356.qmail@deer> <3785E797.F6809570@moene.indiv.nluug.nl> <19990709152312.18370.qmail@deer> <37863D4F.287AF653@moene.indiv.nluug.nl> <19990714101440.C17684@keksy.mchp.siemens.de>
X-SW-Source: 1999-07/msg00538.html
Content-length: 3572

First of all, I want to - belatedly - apologize to Martin and his
colleagues for the following insinuation:

> If people are
> forced to deal with badly written software in such large IT firms like
> Siemens, they'd better be prepared to pay up, or shut up.

It was uncalled for and wrong.  This will not happen again.

Martin Kahlert wrote:

> Please correct my if i am wrong, but meteorological simulation
> usually deals with elliptic partial differential equations in each time
> step (i don't think you have shocks). Since there is the maximum principle,
> i assume, you can theoretically prove that all of your floating point values
> are within good boundaries.

Possibly (numerically, the partitioning of PDEs in hyperbolic, parabolic
and elliptic is not very useful), but I am not sure these properties
still hold after discretization.  We tend to approach the issue from the
other direction: 

Given that the atmospheric quantities stay within certain limits, our
differential equations after discretization should also stay within
those limits.

Because weather forecasting is an initial/boundary-value problem, and
all forecast times are useful (up to a certain limit), we want this to
hold for the entire evolution from initial state to final state.

Hence, if our discretization gives rise to unboundedly growing errors,
we have to control them - we dissipate these waves by filters.

> Electrical circuit simulation is by a big amount more nasty thing than this!
> Each transistor has about 3 operation modes: One, where it doesn't do a lot,
> since the voltages are a bit too low, one rather linear part in the voltage-
> current graph (where amplification happens) and a saturation part.
> This graph has rather sharp edges and you don't know anything about, where
> the designer wants the transistor to work - and this has not neccessarily
> anything to do with where they actually work ;-).
> This might be rather simple to solve in the case of toy problems with less then 100
> transistors, but our simulation tool is inteded more in the range between
> 10000 and 100000 of them. Unfortunatly transient time simulation is the simpler
> part. A great deal of effort (and computation time)
> is put into finding an initial consistent solution.

And for this you use the Newton-Raphson root finder, if I understand
correctly.

> While in meteorological simulations the linear sets of equations are so well
> behaved, that usually iterative solvers converge, i don't know of any successful
> use of an iterative linear solver in analog circuit simulation.

The PDEs of atmospheric motion are non-linear, although not
spectacularly so - we also do not use iterative solvers (why do you
think so ? - we're not trying to calculate an equilibrium solution, but
a time evolution).

> I think, you didn't read Num. Rec. exactly: Can you tell me any globally convergent
> method for nonlinear methods, which can be coded to not produce FPEs?
> The rather trivial improvements of newton's method in NR, all suggest to calculate
> F(x_new) first (to ensure quadratical convergence near the solution).
> But this is not possible, if x_new has bad values inside it. Even something
> like if(x_new(i) .GT. 1D10) can throw an exception! The only thing you can
> savely do with these values is to not use them.

Yes, obviously, I didn't read it far enough.  Sorry for my rant.

-- 
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 jason@cygnus.com Wed Jul 14 17:04:00 1999
From: Jason Merrill <jason@cygnus.com>
To: hjl@varesearch.com (H.J. Lu)
Cc: egcs-bugs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), egcs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: Your g++ breaks glibc.
Date: Wed, 14 Jul 1999 17:04:00 -0000
Message-id: <u9lncjuhkt.fsf@yorick.cygnus.com>
References: <19990714195521.1BA043FC1@varesearch.com>
X-SW-Source: 1999-07/msg00537.html
Content-length: 19

This is OK.

Jason
>From martin@mira.isdn.cs.tu-berlin.de Wed Jul 14 17:05:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: sosedada@usa.net
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Default template parameters in 2.95
Date: Wed, 14 Jul 1999 17:05:00 -0000
Message-id: <199907142234.AAA00721@mira.isdn.cs.tu-berlin.de>
References: <19990714170858.11055.qmail@www0t.netaddress.usa.net>
X-SW-Source: 1999-07/msg00541.html
Content-length: 385

> Is it now a problem to define this friend function within the
> template class?

The problem is that function templates must not have default template
parameters. Member functions of template classes are normally
templates themselves, having the template parameters of the class
template implicitly. However, I'm not certain whether this applies to
friends as well.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Wed Jul 14 17:05:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: Klaus.Bergdolt@de.bosch.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: implicit conversion from "pointer to function" to "void*"
Date: Wed, 14 Jul 1999 17:05:00 -0000
Message-id: <199907142254.AAA00786@mira.isdn.cs.tu-berlin.de>
References: <378C7E2E.A5523C92@de.bosch.com>
X-SW-Source: 1999-07/msg00543.html
Content-length: 290

> in C++ it's possible to implicitly convert a pointer to a function
> to void*.

Really? Looking at the C++ standard, I cannot find the place where
this is allowed. I would have expected that in 4.10, [conv.ptr]/2; but
that is explicitly restricted to pointers-to-object.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Wed Jul 14 17:05:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: wolfgang.sepp@gmx.net
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: ICE on nested class template member operator specialization
Date: Wed, 14 Jul 1999 17:05:00 -0000
Message-id: <199907142235.AAA00728@mira.isdn.cs.tu-berlin.de>
References: <24105.931941386@www8.gmx.net>
X-SW-Source: 1999-07/msg00542.html
Content-length: 691

> Egcs 1.1.2 produces an internal compiler error by compiling the
> following little program.

Thanks for your bug report. gcc-2.95 19990701 reports

a.cc:6: explicit specialization in non-namespace scope `A<T1>'
a.cc:6: enclosing class templates are not explicitly specialized
a.cc:6: syntax error before `{'
a.cc:6: missing ';' before right brace
a.cc:7: parse error at null character
a.cc:14: explicit specialization in non-namespace scope `B<T1>'
a.cc:14: enclosing class templates are not explicitly specialized
a.cc:14: syntax error before `{'
a.cc:14: missing ';' before right brace
a.cc:15: parse error at null character

so it appears that the bug has been fixed.

Regards,
Martin

Re: A bad gcc 2.95 bug

[H.J. Lu]

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

It is a real bug. I posted a patch:

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00534.html
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00537.html


H.J.
>From khaley@bigfoot.com Wed Jul 14 23:13:00 1999
From: "K. Haley" <khaley@bigfoot.com>
To: Mumit Khan <khan@xraylith.wisc.edu>, egcs-bugs@egcs.cygnus.com
Subject: Wrong delete being called.
Date: Wed, 14 Jul 1999 23:13:00 -0000
Message-id: <4.1.19990714001252.009455a0@pop.mail.yahoo.com>
X-SW-Source: 1999-07/msg00551.html
Content-length: 1142

I have a base class with operator delete declared private.  The destructor
of a derived class tries to delete a pointer held by the base class but it
can't.  The compiler reports that operator delete is private which is true,
however it is not the delete that should be called. Here is a test case:

#include <new.h>

template<class T> class TPointerBase {
  public:

  protected:
    TPointerBase(T* pointer) : P(pointer) {}
    TPointerBase() : P(0) {}

    T* P;

  private:
    void* operator new(size_t) {return 0;}  // prohibit use of new
    void operator delete(void* p) {((TPointerBase<T>*)p)->P=0;}
};

template<class T> class TPointer : public TPointerBase<T> {
  public:
    TPointer() : TPointerBase<T>() {}
    TPointer(T* pointer) : TPointerBase<T>(pointer) {}
   ~TPointer() {delete P;}
    TPointer<T>& operator =(T* src) {delete P; P = src; return *this;}
    T* operator->() {return P;}  // Could throw exception if P==0
};

int main()
{
	TPointer<int> pi;

	return 0;
}
---
Just another brain dead computer user.

Kenneth Haley < mailto:khaley@bigfoot.com >
My website if your interested http://www.bigfoot.com/~khaley

Re: A bad gcc 2.95 bug

[Alexandre Oliva]

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

Re: A bad gcc 2.95 bug

[Mike Stump]

> To: egcs-bugs@egcs.cygnus.com
> Date: Wed, 14 Jul 1999 12:32:06 -0700 (PDT)
> Cc: libc-hacker@sourceware.cygnus.com (GNU C Library)
> From: hjl@varesearch.com (H.J. Lu)

> That is a bug fixed for egcs 1.1.2. Why does it return in gcc 2.95?
> It will screw up glibc. It has to be fixed in gcc 2.95.

I don't understand the bug.  I do understand the error in the code,
though.