* Re: egcs-1.1.1 stuff
1998-11-01 23:15 egcs-1.1.1 stuff Jeffrey A Law
@ 1998-11-02 7:12 ` Hans-Peter Nilsson
1998-11-02 11:33 ` Jason Merrill
1998-11-02 7:39 ` Robert L Krawitz
` (4 subsequent siblings)
5 siblings, 1 reply; 12+ messages in thread
From: Hans-Peter Nilsson @ 1998-11-02 7:12 UTC (permalink / raw)
To: law; +Cc: egcs, jason
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-01 23:15 egcs-1.1.1 stuff Jeffrey A Law
1998-11-02 7:12 ` Hans-Peter Nilsson
@ 1998-11-02 7:39 ` Robert L Krawitz
1998-11-04 20:47 ` Martin von Loewis
1998-11-02 10:40 ` H.J. Lu
` (3 subsequent siblings)
5 siblings, 1 reply; 12+ messages in thread
From: Robert L Krawitz @ 1998-11-02 7:39 UTC (permalink / raw)
To: law; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-02 7:39 ` Robert L Krawitz
@ 1998-11-04 20:47 ` Martin von Loewis
1998-11-05 5:01 ` Robert L Krawitz
1998-11-05 5:01 ` Robert L Krawitz
0 siblings, 2 replies; 12+ messages in thread
From: Martin von Loewis @ 1998-11-04 20:47 UTC (permalink / raw)
To: rlk; +Cc: law, egcs
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-04 20:47 ` Martin von Loewis
@ 1998-11-05 5:01 ` Robert L Krawitz
1998-11-06 8:00 ` Joe Buck
1998-11-05 5:01 ` Robert L Krawitz
1 sibling, 1 reply; 12+ messages in thread
From: Robert L Krawitz @ 1998-11-05 5:01 UTC (permalink / raw)
To: martin; +Cc: law, egcs, smr
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-05 5:01 ` Robert L Krawitz
@ 1998-11-06 8:00 ` Joe Buck
0 siblings, 0 replies; 12+ messages in thread
From: Joe Buck @ 1998-11-06 8:00 UTC (permalink / raw)
To: Robert L Krawitz; +Cc: martin, law, egcs, smr
> > 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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-04 20:47 ` Martin von Loewis
1998-11-05 5:01 ` Robert L Krawitz
@ 1998-11-05 5:01 ` Robert L Krawitz
1 sibling, 0 replies; 12+ messages in thread
From: Robert L Krawitz @ 1998-11-05 5:01 UTC (permalink / raw)
To: martin; +Cc: law, egcs, smr
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-01 23:15 egcs-1.1.1 stuff Jeffrey A Law
1998-11-02 7:12 ` Hans-Peter Nilsson
1998-11-02 7:39 ` Robert L Krawitz
@ 1998-11-02 10:40 ` H.J. Lu
[not found] ` <199811021542.KAA06874.cygnus.egcs@rlk-ppp-1.torrent.com>
` (2 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: H.J. Lu @ 1998-11-02 10:40 UTC (permalink / raw)
To: law; +Cc: egcs
>
>
>
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <199811021542.KAA06874.cygnus.egcs@rlk-ppp-1.torrent.com>]
* Re: egcs-1.1.1 stuff
1998-11-01 23:15 egcs-1.1.1 stuff Jeffrey A Law
` (3 preceding siblings ...)
[not found] ` <199811021542.KAA06874.cygnus.egcs@rlk-ppp-1.torrent.com>
@ 1998-11-04 6:42 ` Franz Sirl
1998-11-06 18:09 ` Richard Henderson
5 siblings, 0 replies; 12+ messages in thread
From: Franz Sirl @ 1998-11-04 6:42 UTC (permalink / raw)
To: law; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs-1.1.1 stuff
1998-11-01 23:15 egcs-1.1.1 stuff Jeffrey A Law
` (4 preceding siblings ...)
1998-11-04 6:42 ` Franz Sirl
@ 1998-11-06 18:09 ` Richard Henderson
5 siblings, 0 replies; 12+ messages in thread
From: Richard Henderson @ 1998-11-06 18:09 UTC (permalink / raw)
To: law, egcs
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~
^ permalink raw reply [flat|nested] 12+ messages in thread