HDTenEightyP/NetNews huggingface dataset:
From: uddeborg@sisu.SE (G|ran Uddeborg)
Subject: Re: Odd behavior when '~' in include path
Keywords: include path, -I, ~
Organization: Swedish Institute of Systems Development
Distribution: gnu
Date: Wed, 8 Apr 1992 07:45:36 GMT

In article <22536@dog.ee.lbl.gov> maze@bea.lbl.gov (Don R. Maszle) writes:
>        gcc -I~/include  ...      includes "*.h" files from /usr/include
>
>        gcc -Ifull-pathname ...   includes "*.h" files from ~/include

"~" is only expanded by the shell if it is the first character of a
word.  It has nothing to do with gcc.  Replace "gcc" with "echo" in
the commands above for an illustration.

Newsgroups: gnu.gcc.bug
From: Marc_Van-Woerkom@ac.maus.DE (Marc Van-Woerkom)
Subject: gcc-2.1 internal compiler err
Organization: Mausnet
Distribution: gnu
Date: Thu, 9 Apr 1992 07:58:00 GMT

The System:
-----------

gcc-2.1, sgi iris4d under Irix 3.3.x


The Program:
------------

Host sbsvax.cs.uni-sb.de   (134.96.252.31)
Last updated 07:23 30 Mar 1992

    Location: /pub/utils
      FILE      rw-r--r--     42234  Mar 10 19:37   freeze-2.3.3.tar.Z


The Error:
----------

165 PXCL1 /usr/local/freeze >make sysv
        make prog CFLAGS="-O -DBITS=16 -DFAST -DSIGTYPE=void"\
                LIBS="-lc_s"
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
bitio.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
debug.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
decode.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
default.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
encode.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
freeze.c
freeze.c: In function `main':
freeze.c:187: warning: assignment from incompatible pointer type
freeze.c:187: warning: comparison of distinct pointer types lacks a cast
freeze.c:190: warning: passing arg 2 of `signal' from incompatible pointer type
freeze.c:199: warning: passing arg 2 of `signal' from incompatible pointer type
freeze.c: In function `foreground':
freeze.c:827: warning: comparison of distinct pointer types lacks a cast
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
huf.c
        gcc -fstrength-reduce  -c -O -DBITS=16 -DFAST -DSIGTYPE=void -DCOMPAT
lz.c
        gcc -fstrength-reduce  -O -DBITS=16 -DFAST -DSIGTYPE=void  bitio.o
debug.o decode.o default.o encode.o freeze.o huf.o lz.o -lc_s -o freeze
ld:
Warning: exit: multiply defined
        previous (used) definition from '/usr/lib/libc_s.a';
        new (ignored) definition from
'/usr/local/lib/gcc-lib/iris4d/2.1//libgcc.a'
gcc: Internal compiler error: program ld got fatal signal 10
*** Error code 1

Stop.
*** Error code 1

Stop.


A similar fatal error yields "make generic" -- signal 11 if I got it right.
The native C compiler has no problems.


Bye, Marc

Newsgroups: gnu.gcc.bug
From: laf4@uhura.cc.rochester.edu (Lawrence Fried)
Subject: GCC 2.0 - 2.1 Debug on Irix 4.0.1
Organization: University of Rochester Computing Center
Distribution: gnu
Date: Tue, 7 Apr 1992 06:14:48 GMT

Subject: GCC 2.0 - 2.1 Debug on Irix 4.0.1
Summary: GCC Debug broke when moving from Irix 3.3 to Irix 4.0.1
Expires: 
Followup-To: 
Distribution: gnu
Organization: University of Rochester (Rochester, NY)
Keywords: 

When we moved up from Irix 3.3 to Irix 4.0.1 on our system (an SGI 4d-320), 
GCC 2.0 stopped producing debugging information that could be used by
dbx.  The current status is that only external variables can be
examined.  Also, the frame stack is not correctly displayed.  dbx
still works with the cc supplied by SGI.  gdb 4.4 doesn't work either.

I tried rebuilding GCC 2.0 and GCC 2.1 with the configure options 
mips-sgi-irix4, but the debug problem wouldn't go away.  
I also tried, with no success,
to use the patches for mips-tfile supplied with GCC 2.1.

Does anybody know if GCC is supposed to produce debug information
under Irix 4.0.1 ??

Does anybody have a version of GCC 2.0 or GCC 2.1 that produces
correct debug info for the SGI ??

	Larry Fried (larry@liouville.chem.rochester.edu)

Newsgroups: gnu.gcc.bug
From: dbgwab@edp130.edp.ARco.COM (Bill Bailey)
Subject: lib++-2.0 BUG
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 05:45:17 GMT

I seem to have encountered a problem building lib++-2.0 on SUN3s. It builds successfully
on a DECstation 5000 running Ultrix 4.2 and 4.2a. However on my SUN 3/60 and SUN 3/260
running SUNos 4.1.1 it fails duing the initial make. What follows is the last 20 lines
from the make log.

        true ; \
fi
(rootme=`pwd` ; export rootme ; cd src ; \
        make "CC=gcc" "XTRAFLAGS=" \
        "AR=ar" "RANLIB=ranlib")
gcc -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
gcc -I. -I./../iostream -I./../g++-include  -c Obstack.cc
gcc -I. -I./../iostream -I./../g++-include  -c builtin.cc
gcc -I. -I./../iostream -I./../g++-include  -c regex.cc
gcc -I. -I./../iostream -I./../g++-include  -c Regex.cc
as: error (/usr/tmp/cca09100.s:452): Invalid operand
as: error (/usr/tmp/cca09100.s:528): Invalid operand
*** Error code 1
make: Fatal error: Command failed for target `Regex.o'
Current working directory /home1/source/GCC/libg++-2.0/libg++/src
*** Error code 1
make: Fatal error: Command failed for target `.stmp-src'
Current working directory /home1/source/GCC/libg++-2.0/libg++
*** Error code 1
make: Fatal error: Command failed for target `stmp-libg++'


Any thoughts or recommendations?

Bill Bailey

Newsgroups: gnu.gcc.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: ANSI C spec and GNU C preprocessing
Organization: Harvey Mudd College
Distribution: gnu
Date: Mon, 13 Apr 1992 05:33:30 GMT

gnu@toad.com writes:

>Applications that depend on the output of an arbitrary C preprocessor
>are typically broken.  X11 expands makefiles that way -- that's a bug.

But then, so does Emacs...

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  __main
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:37:40 GMT

The call to it support the proper execution of mixed (C and C++) programs
that have a C main.  The support is on purpose and unless you can come up
with a good reason, will always be in FSF released gcc.

Why can you not have libgcc.a available to link against?  I cannot think
of any good reasons.

The _start idea does not work, because the _start used is vendor
supplied, and we have no control over it.  There is also little
desire to provide one, just look at GNU emacs for reasons as I
understand them.

You are using gcc in non-standard ways, therefore you have to expect to
go to a little extra work.  If you had not defeated the inclusion of
libgcc.a on a link line, the problem would not exist, right?

For you, the solution may be to just comment out the call to
expand_main_function.  Seems really easy, simple to maintain, and will
always work.  Why can't you just bite the bullit on this one?

> Message-Id: <9204150101.AA18863@life.ai.mit.edu>
> From: Christopher Maeda <cmaeda@mc8.mach.cs.cmu.edu>
> Date: Tue, 14 Apr 92 20:59:55 EDT
> To: bug-gcc@prep.ai.mit.edu
> Cc: cmaeda@cs.cmu.edu
> Subject: __main
> Reply-To: cmaeda@cs.cmu.edu

> Why do all C programs call __main?  The change logs seem to say __main
> is for C++ programs and shared libraries.

> The reason I care or even know about this is that I'm using gcc2 to
> build mach kernels which are not linked against gcc's libraries.
> Thus, I either have to stick a null definition of __main in mach's
> libraries or convince you that two wrongs don't make a right.  I
> clearly don't need whatever __main provides and it's a bug that I
> should even have to think about it.

> A less intrusive approach to this might be to fold __main into
> __start.  Then if you don't link with the gnu __start (or whatever
> function is in crt0), you don't have to worry about __main.

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.1 and ANSI-like exception handling g++ 2.1 and ANSI-like exception handling
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:24:22 GMT

Reports concerning C++ should go to the bug-g++ list, not this one.

Yes, that is right, exception handling does not work, it is ``not supported''
yet.  Consider it pre alpha.

> From: S_SCHLICHT@irav1.ira.uka.de (|S| Christian Schlicht)
> Newsgroups: gnu.gcc.bug
> Subject: g++ 2.1 and ANSI-like exception handling
> Date: 13 Apr 1992 18:26:44 GMT
> Organization: University of Karlsruhe, FRG - Informatik Rechnerabteilung
> Message-Id: <kujkj4INNon@iraul1.ira.uka.de>
> To: bug-gcc@prep.ai.mit.edu

> Hello,

> Sorry if this was reported before, but I can't use ANSI-like exception
> handling.
> I'm using gcc 2.1 on an ESIX System 5.3.2 Rev.D. My configuration is 
> i386-coff-sysv32.
> Everytime I try to use a simple "throw;" with the following command line
> g++ -fansi-exceptions -c foo.c
> the compiler dumps core.

> The pain is that I really want this exception handling to run.  I
> heard that GNU C++ comes with it's own exception handling syntax and
> semantic, but I can't find any documentation of this.  Could anybody
> help me? Either to get -fansi-exception run or get documentation of
> the GNU C++ exception handling (first preferred)?

Newsgroups: gnu.gcc.bug
From: ian@case.co.UK (Ian Macpherson)
Subject: G++ V2.1 PROBLEMS?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 09:15:28 GMT

	Hello,

	We've just got gcc-2.1. I've installed it on a number of sun4
	machines and used it to successfully build programs such as libg++
	and groff.

	However, on a sun3 (a SUN 3/50) the C++ compiler has problems
	building groff and libg++. The SUN assembler objects to the .stabs
	directive generated by the compiler. The details of the system
	are:

	Host:			SUN 3/50
	OS:			SUNOS 4.1
	Host compiler:		GCC 1.40
	Host assembler:		Sun as
	Configuration:		sun3-sunos4.1 --nfp
				Linked `config.h' to `./config/xm-m68k.h'
				Linked `tm.h' to `./config/sun3n.h'
				Linked `md' to `./config/m68k.md'
				Linked `aux-output.c' to `./config/m68k.c'
				Linked `tconfig.h' to `./config/xm-m68k.h'

	As an example, here is the assembler output and errors from
	compiling the groff 1.05 c++test.c program:

====================== C++ source =============================
#include <stdio.h>

struct A {
  A() { fputs("A\n", stdout); }
  ~A() { fputs("~A\n", stdout); }
};

A a;

main()
{
  return 0;
}
====================== assembler code & errors ================
	#NO_APP
	gcc2_compiled.:
	.text
	LC0:
		.ascii "A\12\0"
	LC1:
		.ascii "~A\12\0"
	.globl _a
	.data
		.even
	_a:
		.skip 1
	.text
		.even
	.globl _main
	_main:
		link a6,#0
		jbsr ___main
		clrl d0
		unlk a6
		rts
		.even
	.globl __GLOBAL_$D$a
	__GLOBAL_$D$a:
		link a6,#0
		pea __iob+20
		pea LC1
		jbsr _fputs
		unlk a6
		rts
	.stabs "___DTOR_LIST__",22,0,0,__GLOBAL_$D$a
as: error (c++test.s:31): Invalid operand
		.even
	.globl __GLOBAL_$I$a
	__GLOBAL_$I$a:
		link a6,#0
		pea __iob+20
		pea LC0
		jbsr _fputs
		unlk a6
		rts
	.stabs "___CTOR_LIST__",22,0,0,__GLOBAL_$I$a
as: error (c++test.s:41): Invalid operand


-- 
Ian Macpherson
Phone:	+44 (923) 258229
Email:	uknet!case!ian  or  ian@case.co.uk
--

Newsgroups: gnu.gcc.bug
From: bhunt@critical.nswc.navy.mil (Brian Hunt)
Subject: small program crashes GCC-2.1 on HP9000/720 (HP-UX 8.07)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 21:37:52 GMT

I have (successfully so far, except for the problem I'm reporting)
built GCC-2.1 on an HP9000/720 running HP-UX 8.07 (I don't have
any other system I can build GCC-2.1 on, so I'm not sure how
machine-specific the problem is.)  I am getting the following error
message when trying to compile some programs.

gcc: Internal compiler error: program cc1 got fatal signal 6

I tried to isolate the type of statement which causes this; here is
the simplest program I could come up with that produces the above
error.

main()
{
  int n;
  double x;
  n = 0;
  x = 0;
  n = (x < 1 ? n : n + 1);
}

The program compiles fine if I declare "x" to be "int" instead of
"double", or if I replace either "n" or "n + 1" by a constant.

Here are the details of how I built GCC and so forth.  In the source
directory, I typed the following.

configure hp700
make LANGUAGES=c
make stage1
make CC=stage1/gcc CFLAGS="-g -O stage1/"

I named the above program bug.c (in the directory where I'd just made
GCC) and all of the following commands give the above error.

./gcc bug.c
./gcc -O bug.c
stage1/gcc -Bstage1/ bug.c

Hope this report is of some help.  By the way, when I get the above
error message I silently get a core dump.  I could reproduce the core
file (it's around 180K, but only 32K compressed and uuencoded) and
send it to anyone who's interested.

Brian Hunt
bhunt@critical.nswc.navy.mil

Newsgroups: gnu.gcc.bug
From: maw@netcom.com (Martin Walker)
Subject: Re: GCC 2.1 on SCO Unix 3.2.4
Keywords: gcc sco bug
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Thu, 9 Apr 1992 10:50:15 GMT

jpr@jpradley.JPr.COM (Jean-Pierre Radley) writes:

>The SCO 3.2v4 Development System is available? My sources don't have it.

Yes, we here in South Africa have had it for about 3 weeks already. It has
several bugs (cc -Ox -CSON causes the compiler to coredump, there are
several bugs in the header files, codeview has many bugs, etc).
All in all, GCC 2.1 is a far superior compiler. However, what
SCO has that is very neat, it support for several different C standards.
ANSI, XPG3, SVID, POSIX are all supported. Just change the command line
and you have a different compiler (sort of). I have made a i386sco324.h
file for GCC 2.1 which emulates this. If anyone has SCO DevSys 3.2v4
and would like to make use of these different standards, let me know and
I'll post that file.

The way I have done it is not very clean, but it does work. Needless to
say, the pre-processor and linker specs are awefully long!

Now, all we need to throw SCO's DevSys out th window is a GDB that will
read SCO generasted core files. Anyone got THAT working yet?

Regards,
Kean Johnston
maw@netcom.netcom.com


Newsgroups: gnu.gcc.bug
From: flur@eecom.gatech.edu (Peter W. Flur)
Subject: Re: gcc compiler bug ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 14:02:21 GMT

|->  From osborn@eecom.gatech.edu Tue Apr 14 09:00:15 1992
|->  Return-Path: <osborn@eecom.gatech.edu>
|->  Date: Tue, 14 Apr 1992 09:00:13 -0500
|->  To: help@eecom
|->  From: osborn@eecom.gatech.edu
|->  Subject: gcc compiler bug ?
|->  
|->  
|->  There appears to be a bug in the gcc compiler on the hp's.  (I have not
|->  tried the suns yet.)
|->  
|->  The following program shows that the absolute value function (fabs) does
|->  not except double precision variables, as the man pages indicate.
|->  
|->  #include <math.h>
|->  
|->  main(ac,av)
|->  int ac;
|->  char *av[];
|->  {
|->  
|->  double a,b;
|->  
|->  a = 1.7;
|->  b = 0.5;
|->  printf("x = %g\n",fabs(a-b));
|->  printf("x = %g\n",fabs((a-b)));
|->  printf("x = %g\n",fabs((double)(a-b)));
|->  printf("x = %g\n",fabs((float)(a-b)));
|->  printf("x = %g\n",fabs(a*b));
|->  }
|->  
|->  Who should this bug be reported to ??  
|->  
|->  Allan Osborn
|->  
|->  

Yup, looks like you may have a bug.  I'll forward this on to the people
at FSF.

Peter
-----------------------------------------------------------------------
     Peter Flur, Research Engineer - School of EE, Georgia Tech
       E-MAIL: Peter.Flur@ee.gatech.edu PHONE: (404) 853-9355
     DUKE UNIVERSITY -- 1991 & 1992 NCAA BASKETBALL CHAMPIONS!!!
            The Duke Dynasty Rolls  --- ThreePeat '93

Newsgroups: gnu.gcc.bug
From: maze@bea.lbl.gov (Don R. Maszle)
Subject: Odd behavior when '~' in include path
Followup-To: gnu.gcc.bug
Keywords: include path, -I, ~
Organization: Lawrence Berkeley Laboratory, Berkeley
Distribution: gnu
Date: Mon, 6 Apr 1992 23:22:17 GMT

>> Reading specs from /usr/local/lib/gcc/sun4-sunos4.1/2.0/specs
>> gcc version 2.0

Our system headers are not set up properly, so I have several local
versions of headers in an include directory $HOME/include.  Depending
on how I specify the include path, gcc will use either my locally
defined headers or the system headers in /usr/include.

        gcc -I~/include  ...      includes "*.h" files from /usr/include

        gcc -Ifull-pathname ...   includes "*.h" files from ~/include

Don Maszle


Newsgroups: gnu.gcc.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: -nostdlib variant that includes libgcc?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 15:35:12 GMT

It would be nice to have an option like -nostdlib, but that includes
libgcc.a in the link (though nothing else the user doesn't specify).  When
linking with nonstandard libraries or startup files, you still need
libgcc.a, and its location is hard to determine in the version 2 scheme of
things.

Newsgroups: gnu.gcc.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: getting gcc-include
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 07:57:22 GMT

I want to use -nostdinc, but I still want to get the gcc-include
directory.  With GCC 1 this is easy; just add -I..../gcc-include to
CFLAGS.  With GCC 2, however, the gcc-include directory is
version-dependent, so this is liable to errors.  Is there a simple way
to tell CPP "Use the current gcc-include directory, but nothing
else."?

	-mib

Newsgroups: gnu.gcc.bug
From: c_brown@csd.BRispoly.ac.UK (C Brown)
Subject: dbx fails with gcc 2.0
Reply-To: c_brown@csd.brispoly.ac.uk
Organization: Bristol Polytechnic (The Magic Roundabout)
Distribution: gnu
Date: Tue, 7 Apr 1992 12:16:32 GMT

I am running gcc 2.0 on a Solbourne 5/601 under OS/MP 4.1.A (c.f. 4.1.1).
gcc compiles okay but if I try to run dbx on the binary it fails.

When run gcc on the following:

	#include <stdio.h>

	main()
	{
	  printf("hello, world\n");
	}

then dbx a.out I get the following error message:

dbx: internal error: bad input on type id "long_long" at "t18=u8s:17,0,64;ll:7,0,64;;" @

The message actually has 3 graphics characters (rectangles) before ampersand.

Can anyone tell me what's going on and how I fix the problem.

Chris

Newsgroups: gnu.gcc.bug
From: jjc@jclark.COM (James Clark)
Subject: optimization bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 11:23:55 GMT

gcc 2.1 misoptimizes the following program:

$ cat bug.c

main()
{
  signed char c = -1;
  printf("%d\n", c < 0);
  exit(0);
}
$ gcc -v -O bug.c
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ bug.c /usr/tmp/cca28545.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/cc1 /usr/tmp/cca28545.i -quiet -dumpbase bug.c -O -version -o /usr/tmp/cca28545.s
GNU C version 2.1 (sparc) compiled by GNU C version 2.0.
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/as -o bug.o /usr/tmp/cca28545.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/ -L/usr/local/lib/ bug.o -lgcc -lc -lgcc
$ ./a.out
0
$ gcc bug.c
$ ./a.out
1
$ 

James Clark
jjc@jclark.com

Newsgroups: gnu.gcc.bug
From: cmaeda@mc8.mach.cs.cmu.edu (Christopher Maeda)
Subject: __main
Reply-To: cmaeda@cs.cmu.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 00:59:55 GMT

Hi,

Why do all C programs call __main?  The change logs seem to say __main
is for C++ programs and shared libraries.

The reason I care or even know about this is that I'm using gcc2 to
build mach kernels which are not linked against gcc's libraries.
Thus, I either have to stick a null definition of __main in mach's
libraries or convince you that two wrongs don't make a right.  I
clearly don't need whatever __main provides and it's a bug that I
should even have to think about it.

A less intrusive approach to this might be to fold __main into
__start.  Then if you don't link with the gnu __start (or whatever
function is in crt0), you don't have to worry about __main.

Chris

Newsgroups: gnu.gcc.bug
From: nicwi@isy.liu.se (Niclas Wiberg)
Subject: Bug in gcc 2.1: volatile function produces warning in C++ code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 15:44:52 GMT

Hi, and thank you for a good compiler.

I think I have found a bug in gcc 2.1 which only shows up for C++ programs.
We have sun4 with SunOS 4.1.1B and gcc 2.1.

The following file produces a warning when compiled as a C++ program,
with filename "bad.cc", but not when compiled as a C program, with
filename "good.c":

------------------- bad.cc  &  good.c -----------------------
void volatile abort();

void volatile quit() {
  abort();
}
-------------------------------------------------------------

gcc -c good.c       # does not complain

gcc -c bad.cc       # complains:
bad.cc: In function `void  quit ()':
bad.cc:5: warning: `volatile' function does return



----------------- Compilation with -v -----------------------


gcc -v -c good.c

Reading specs from /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/specs
gcc version 2.1
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/cpp -lang-c -v -undef -D__GNUC__=2   \\
-Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun      \\
-D__unix good.c /usr/tmp/cca00679.i
GNU CPP version 2.1 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/cc1 /usr/tmp/cca00679.i -quiet       \\
-dumpbase good.c -version -o /usr/tmp/cca00679.s
GNU C version 2.1 (sparc) compiled by GNU C version 2.1.
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/as -o good.o /usr/tmp/cca00679.s



gcc -v -c bad.cc

Reading specs from /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/specs
gcc version 2.1
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 \\
-D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__        \\
-D__unix__ -D__sparc -D__sun -D__unix bad.cc /usr/tmp/cca00683.i
GNU CPP version 2.1 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/cc1plus /usr/tmp/cca00683.i -quiet   \\
-dumpbase bad.cc -version -o /usr/tmp/cca00683.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
bad.cc: In function `void  quit ()':
bad.cc:5: warning: `volatile' function does return
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.1/as -o bad.o /usr/tmp/cca00683.s



Hope you can use this,

----------------------------------------------------------------------
Niclas Wiberg                         nicwi@isy.liu.se
Dept. of EE    Linkoping University   Sweden

Hope you can use this

Newsgroups: gnu.gcc.bug