egcs-1.1.1 stuff

egcs-1.1.1 stuff

[Jeffrey A Law]

I've put a pre-release of egcs-1.1.1 on the ftp server
(pub/egcs/snapshots/1.1.1-prerelease).

No components for the pre-release, but diffs from egcs-1.1b are available.

There's still a few things to take care of (doc stuff mostly I think), but
that pre-release should be pretty close to the real thing.

--

Here's the current change list for egcs-1.1.1.  Some of these things may need
to be expanded (arm fixes, cygwin fixes, c++ fixes, etc).  Your feedback would
be greatly appreciated.



	* Fix identification of Unixware 7 machines.

	* Do not assume x86-svr4 or x86-unixware machines can handle stabs.

	* Fix cpp predefines for various linux targets.

	* Fix out of range displacement problem for m68k targets and
	byte sized operand problems for the coldfire.

	* Fixes for 64bit ppc/rs6000 targets.  Fix varargs bug with long long
	typess in the overflow area.

	* Various cygwin/mingw fixes.

	* Fix generic code generation bug in loop invariant code motion
	optimization.

	* Fix generic code generation bug in gcse optimization.

	* fixincludes fixes for rpc header files on SunOs.

	* Simplify/fix installation of assert.h for cross targets.

	* arm fixes

	* Fix compiler abort in reg-stack on the x86.

	* Fix alpha code generation bug (richard, more details?)

	* Fix compiler segfault/abort compiling linux 2.1.11x kernels.

	* Fix return type for RAND in Fortran front end.

	* Various documentation updates for the Fortran front end.

	* Fix Makefiles in Fortran front end and runtime to work better
	BSD shells/make	programs.

	* Fix implicit endfile on rewind in Fortran runtime libraries.

	* Avoid spurious recursive i/o error from formatted direct i/o in
	Fortran runtime libraries.

	* Various C++ fixes.


jeff

Re: egcs-1.1.1 stuff

[Hans-Peter Nilsson]

> Your feedback would be greatly appreciated.

Since you asked:
 Please include Jason's one-line change to refer to the FAQ in
the ICE message in my_friendly_abort() in cp/typeck2.c
(Sorry, no better reference).

brgds, H-P

Re: egcs-1.1.1 stuff

[Jason Merrill]

>>>>> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

 >  Please include Jason's one-line change to refer to the FAQ in
 > the ICE message in my_friendly_abort() in cp/typeck2.c

Done.

Jason

Re: egcs-1.1.1 stuff

[Robert L Krawitz]

> Date: Sun, 01 Nov 1998 18:53:44 -0700
> From: Jeffrey A Law <law@cygnus.com>
> 
> I've put a pre-release of egcs-1.1.1 on the ftp server
> (pub/egcs/snapshots/1.1.1-prerelease).

This doesn't fix the problem with undeclared functions not signalling an
error:

$ cat > implicit.C
a()
{
  foo();
}
$ /home/user1/egcs-1.1.1/bin/g++ -c -pedantic implicit.C 
implicit.C: In function `int a()':
implicit.C:3: warning: implicit declaration of function `int foo(...)'
implicit.C:4: warning: control reaches end of non-void function `a()'
$ echo $?     
0

This is actually quite important -- the C++ spec emphasizes that functions
must be explicitly declared, and this failure to flag an error causes us some
trouble with generated code that really does need to be flagged.

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: egcs-1.1.1 stuff

[Martin von Loewis]

> implicit.C:3: warning: implicit declaration of function `int foo(...)'
[...]
> This is actually quite important -- the C++ spec emphasizes that functions
> must be explicitly declared, and this failure to flag an error causes us some
> trouble with generated code that really does need to be flagged.

The C++ spec does not talk about errors and warnings. Instead, it
requires that an implementation should produce *diagnostic
message*. It is implementation-defined what constitutes these
diagnostics. For g++, diagnostics include error and warning message.

As Jason points out, -pedantic-errors turns warnings into errors.

Regards,
Martin

Re: egcs-1.1.1 stuff

[Robert L Krawitz]

> Date: Wed, 4 Nov 1998 22:20:22 +0100
> From: Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>
> Cc: law@cygnus.com, egcs@cygnus.com
> 
> > implicit.C:3: warning: implicit declaration of function `int foo(...)'
> [...]
> > This is actually quite important -- the C++ spec emphasizes that functions
> > must be explicitly declared, and this failure to flag an error causes us some
> > trouble with generated code that really does need to be flagged.
> 
> The C++ spec does not talk about errors and warnings. Instead, it
> requires that an implementation should produce *diagnostic
> message*. It is implementation-defined what constitutes these
> diagnostics. For g++, diagnostics include error and warning message.
> 
> As Jason points out, -pedantic-errors turns warnings into errors.

At the very least, please provide a specific option to reject undeclared
functions.
-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: egcs-1.1.1 stuff

[Joe Buck]

> > The C++ spec does not talk about errors and warnings. Instead, it
> > requires that an implementation should produce *diagnostic
> > message*. It is implementation-defined what constitutes these
> > diagnostics. For g++, diagnostics include error and warning message.
> > 
> > As Jason points out, -pedantic-errors turns warnings into errors.
> 
> At the very least, please provide a specific option to reject undeclared
> functions.

The main problem isn't what we call the problem (error or warning).  The
problem is that the parser inserts a definition of an undeclared function
as

	extern "C" int funcName(...);

The problem is that this is 99.9% certain to be incorrect, unless
the program is being written by a K&R C programmer who is just learning
C++.

It has implications for error recovery.  If funcName is a typo, then
a large cascade of bogus error reports will occur in many cases; these
bogus errors would not occur if this definition is not inserted and
an error node is inserted instead.  This especially happens with

	overloadedFunction(funcName());

where overloadedFunction does not accept an int argument.

Changing the status from warning to error, but still inserting the
extern "C" int definition, would be just as bad.  The problem is that
this K&R C notion (that you can use any name as a function and the
compiler will create a function returning int) is just wrong for C++
and should be killed dead (or at minimum there should be a flag that
does it).

Re: egcs-1.1.1 stuff

[Robert L Krawitz]

> Date: Wed, 4 Nov 1998 22:20:22 +0100
> From: Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>
> Cc: law@cygnus.com, egcs@cygnus.com
> 
> > implicit.C:3: warning: implicit declaration of function `int foo(...)'
> [...]
> > This is actually quite important -- the C++ spec emphasizes that functions
> > must be explicitly declared, and this failure to flag an error causes us some
> > trouble with generated code that really does need to be flagged.
> 
> The C++ spec does not talk about errors and warnings. Instead, it
> requires that an implementation should produce *diagnostic
> message*. It is implementation-defined what constitutes these
> diagnostics. For g++, diagnostics include error and warning message.
> 
> As Jason points out, -pedantic-errors turns warnings into errors.

Unfortunately, this really isn't very useful to us.  -pedantic-errors also
rejects 'long long', a common C++ extension.  There are certain C++ extensions
that we're aware are extensions (such as long long) that we use carefully.

This, on the other hand, causes us real grief.  It makes it hard for us to use
egcs/g++ to verify that a program compiles correctly.

Can you please consider making this consistent with common C++ practice
elsewhere?  What possible advantage is it (other than compiling legacy C code,
which doesn't apply to C++) to accept undeclared functions?

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: egcs-1.1.1 stuff

[H.J. Lu]

> 
> 
> 
> I've put a pre-release of egcs-1.1.1 on the ftp server
> (pub/egcs/snapshots/1.1.1-prerelease).
> 
> No components for the pre-release, but diffs from egcs-1.1b are available.
> 
> There's still a few things to take care of (doc stuff mostly I think), but
> that pre-release should be pretty close to the real thing.
> 

Have we fixed the EH regression against 1.0.3?


H.J.

Re: egcs-1.1.1 stuff

[Jason Merrill]

>>>>> Robert L Krawitz <rlk@tiac.net> writes:

 > This doesn't fix the problem with undeclared functions not signalling an
 > error:

You can use -pedantic-errors.

Jason

Re: egcs-1.1.1 stuff

[Franz Sirl]

Hi Jeff,

do you have any reports of a working qt-1.41 (compiled with -O2) and
kde-1.0 (compiled with -O2 against qt-1.41) configuration?
I still have the problem here that any selection of text (in eg. kvt or
kedit) with the mouse, crashes the app as soon as the mouse button is
lifted. AFAIK this problem affected x86 too with egcs-1.1, and qt-1.41 had
to be compiled with -O0 there.

Any hints appreciated.

Franz.



At 02:53 02.11.98 , Jeffrey A Law wrote:
>
>
>I've put a pre-release of egcs-1.1.1 on the ftp server
>(pub/egcs/snapshots/1.1.1-prerelease).
>
>No components for the pre-release, but diffs from egcs-1.1b are available.
>
>There's still a few things to take care of (doc stuff mostly I think), but
>that pre-release should be pretty close to the real thing.
>
>--
>
>Here's the current change list for egcs-1.1.1.  Some of these things may need
>to be expanded (arm fixes, cygwin fixes, c++ fixes, etc).  Your feedback would
>be greatly appreciated.
>
>
>
>	* Fix identification of Unixware 7 machines.
>
>	* Do not assume x86-svr4 or x86-unixware machines can handle stabs.
>
>	* Fix cpp predefines for various linux targets.
>
>	* Fix out of range displacement problem for m68k targets and
>	byte sized operand problems for the coldfire.
>
>	* Fixes for 64bit ppc/rs6000 targets.  Fix varargs bug with long long
>	typess in the overflow area.
>
>	* Various cygwin/mingw fixes.
>
>	* Fix generic code generation bug in loop invariant code motion
>	optimization.
>
>	* Fix generic code generation bug in gcse optimization.
>
>	* fixincludes fixes for rpc header files on SunOs.
>
>	* Simplify/fix installation of assert.h for cross targets.
>
>	* arm fixes
>
>	* Fix compiler abort in reg-stack on the x86.
>
>	* Fix alpha code generation bug (richard, more details?)
>
>	* Fix compiler segfault/abort compiling linux 2.1.11x kernels.
>
>	* Fix return type for RAND in Fortran front end.
>
>	* Various documentation updates for the Fortran front end.
>
>	* Fix Makefiles in Fortran front end and runtime to work better
>	BSD shells/make	programs.
>
>	* Fix implicit endfile on rewind in Fortran runtime libraries.
>
>	* Avoid spurious recursive i/o error from formatted direct i/o in
>	Fortran runtime libraries.
>
>	* Various C++ fixes.
>
>
>jeff

Re: egcs-1.1.1 stuff

[Richard Henderson]

On Sun, Nov 01, 1998 at 06:53:44PM -0700, Jeffrey A Law wrote:
> 	* Fix alpha code generation bug (richard, more details?)

The bug was in the handling of __builtin_return_address.  It 
showed up as an infinite loop during boot of SMP Linux kernels.


r~