HDTenEightyP/NetNews huggingface dataset:
From: eggert@twinsun.COM (Paul Eggert)
Subject: more problems with signed char index array violations in GCC 2.3.3 cpp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 02:49:13 GMT

I looked for more array bound violations in cpp (GCC 2.3.3) and found four
places in cccp.c where (on a machine where char is signed) a negative value
might be used as a subscript, leading to possibly wrong answers and/or core
dumps.  Here is a patch.


Wed Jan  6 02:35:23 1993  Paul Eggert  (eggert@twinsun.com)

	* cccp.c (check_preconditions, do_error, do_warning, do_xifdef):
	Don't use signed chars to index into arrays; they might be negative.

===================================================================
RCS file: RCS/cccp.c,v
retrieving revision 2.3
diff -c -r2.3 cccp.c
*** cccp.c	1992/12/16 04:25:36	2.3
--- cccp.c	1993/01/06 02:35:23
***************
*** 4383,4392 ****
        int len;
        
        prec += 5;
!       while (is_hor_space[*prec])
  	prec++;
        name = prec;
!       while (is_idchar[*prec])
  	prec++;
        len = prec - name;
        
--- 4383,4392 ----
        int len;
        
        prec += 5;
!       while (is_hor_space[(U_CHAR) *prec])
  	prec++;
        name = prec;
!       while (is_idchar[(U_CHAR) *prec])
  	prec++;
        len = prec - name;
        
***************
*** 5827,5833 ****
       struct directive *keyword;
  {
    int length = limit - buf;
!   char *copy = (char *) xmalloc (length + 1);
    bcopy (buf, copy, length);
    copy[length] = 0;
    SKIP_WHITE_SPACE (copy);
--- 5827,5833 ----
       struct directive *keyword;
  {
    int length = limit - buf;
!   U_CHAR *copy = (U_CHAR *) xmalloc (length + 1);
    bcopy (buf, copy, length);
    copy[length] = 0;
    SKIP_WHITE_SPACE (copy);
***************
*** 5850,5856 ****
       struct directive *keyword;
  {
    int length = limit - buf;
!   char *copy = (char *) xmalloc (length + 1);
    bcopy (buf, copy, length);
    copy[length] = 0;
    SKIP_WHITE_SPACE (copy);
--- 5850,5856 ----
       struct directive *keyword;
  {
    int length = limit - buf;
!   U_CHAR *copy = (U_CHAR *) xmalloc (length + 1);
    bcopy (buf, copy, length);
    copy[length] = 0;
    SKIP_WHITE_SPACE (copy);
***************
*** 6094,6100 ****
    if (ip->fname != 0 && keyword->type == T_IFNDEF) {
      U_CHAR *p = ip->buf;
      while (p != directive_start) {
!       char c = *p++;
        if (is_space[c])
  	;
        else if (c == '/' && p != ip->bufp && *p == '*') {
--- 6094,6100 ----
    if (ip->fname != 0 && keyword->type == T_IFNDEF) {
      U_CHAR *p = ip->buf;
      while (p != directive_start) {
!       U_CHAR c = *p++;
        if (is_space[c])
  	;
        else if (c == '/' && p != ip->bufp && *p == '*') {

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.3.3 cpp violates array bounds when given chars with top bit on
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 02:25:47 GMT

When given the program

	#if \377
	#endif

where the `\377' stands for a single character with all bits on,
the preprocessor for GCC 2.3.3 (sparc, SunOS 4.1.2) addresses
outside the bounds of an array due to signed character extension.
Here is a patch.

Wed Jan  6 02:16:48 1993  Paul Eggert  (eggert@twinsun.com)

	* cexp.y (yylex): Don't use signed chars to index into arrays;
	they might be negative.

===================================================================
RCS file: cexp.y,v
retrieving revision 2.3
diff -c -r2.3 cexp.y
*** cexp.y	1992/10/21 06:53:52	2.3
--- cexp.y	1993/01/06 02:10:19
***************
*** 467,473 ****
   retry:
  
    tokstart = lexptr;
!   c = *tokstart;
    /* See if it is a special token of length 2.  */
    if (! keyword_parsing)
      for (toktab = tokentab2; toktab->operator != NULL; toktab++)
--- 467,473 ----
   retry:
  
    tokstart = lexptr;
!   c = (unsigned char) *tokstart;
    /* See if it is a special token of length 2.  */
    if (! keyword_parsing)
      for (toktab = tokentab2; toktab->operator != NULL; toktab++)
***************
*** 688,694 ****
    if (c >= '0' && c <= '9' && !keyword_parsing) {
      /* It's a number */
      for (namelen = 0;
! 	 c = tokstart[namelen], is_idchar[c] || c == '.'; 
  	 namelen++)
        ;
      return parse_number (namelen);
--- 688,694 ----
    if (c >= '0' && c <= '9' && !keyword_parsing) {
      /* It's a number */
      for (namelen = 0;
! 	 c = (unsigned char) tokstart[namelen], is_idchar[c] || c == '.'; 
  	 namelen++)
        ;
      return parse_number (namelen);
***************
*** 698,704 ****
  
    if (keyword_parsing) {
      for (namelen = 0;; namelen++) {
!       if (is_hor_space[tokstart[namelen]])
  	break;
        if (tokstart[namelen] == '(' || tokstart[namelen] == ')')
  	break;
--- 698,704 ----
  
    if (keyword_parsing) {
      for (namelen = 0;; namelen++) {
!       if (is_hor_space[(unsigned char) tokstart[namelen]])
  	break;
        if (tokstart[namelen] == '(' || tokstart[namelen] == ')')
  	break;
***************
*** 711,717 ****
        return ERROR;
      }
  
!     for (namelen = 0; is_idchar[tokstart[namelen]]; namelen++)
        ;
    }
    
--- 711,717 ----
        return ERROR;
      }
  
!     for (namelen = 0; is_idchar[(unsigned char) tokstart[namelen]]; namelen++)
        ;
    }
    

Newsgroups: gnu.gcc.bug
From: FLEINERC%CFRUNI51.BITNET@mitvma.mit.edu
Subject: Signal 6 while compiling libgcc2.c _floatdidf
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 12:09:00 GMT

Error when installing gcc -2.3.3

gcc-2.3.3 compiled without problems (using gcc-2.3.2), but when
installing, it tried to compile _floatdidf in libgcc2.c and
stopped with

        xgcc: internal compiler error: program cc1 got fatal signal 6

I have an ISC Version 3.2, Systempro 386.
I used "configure isc", wich worked great on gcc-2.2.2 and gcc-2.3.2.

If commenting out the 2 lines
        d *= HIGH_HALFWORD_COEFF;
        d *= HIGH_HALFWORD_COEFF;
it works.

Thanks for any help.

Claudio Fleiner (fleinerc@cfruni51.bitnet)



Newsgroups: gnu.gcc.bug
From: bitbug@netcom.com (James Buster)
Subject: Bug in config/sparc.h from gcc 2.3.3
Organization: Lynx Real-Time Systems, Inc.
Distribution: gnu
Date: Tue, 5 Jan 1993 01:53:15 GMT

A format string passed to fprintf() is wrong in PRINT_OPERAND_ADDRESS.

*** sparc.h	Mon Jan  4 17:14:42 1993
--- sparc.h.new	Mon Jan  4 17:14:52 1993
***************
*** 1716,1722 ****
  	base = XEXP (addr, 0), index = XEXP (addr, 1);		\
        fputs (reg_names[REGNO (base)], FILE);			\
        if (index == 0)						\
! 	fprintf (FILE, "%+d", offset);				\
        else if (GET_CODE (index) == REG)				\
  	fprintf (FILE, "+%s", reg_names[REGNO (index)]);	\
        else if (GET_CODE (index) == SYMBOL_REF)			\
--- 1727,1733 ----
  	base = XEXP (addr, 0), index = XEXP (addr, 1);		\
        fputs (reg_names[REGNO (base)], FILE);			\
        if (index == 0)						\
! 	fprintf (FILE, "+%d", offset);				\
        else if (GET_CODE (index) == REG)				\
  	fprintf (FILE, "+%s", reg_names[REGNO (index)]);	\
        else if (GET_CODE (index) == SYMBOL_REF)			\

-- 
				James Buster
			     bitbug@netcom.com

Newsgroups: gnu.gcc.bug
From: Todd.CLayton@eng.SUn.COM (Todd Clayton)
Subject: GCC preprocessor bug ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 02:10:44 GMT

I'm not sure this is a bug, but Sun cc behaves differently than gcc on this
simple testcase. I thought it would be best to report it and let the
pros figure it out. In the simple testcase below I thought "-x" should 
should be treated as separte preprocessing tokens in the macro "Blk".
That is "-" and "x" are seperate tokens and should not be merged as
gcc does.

-Todd

oconee:tmp% gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos5.1/2.3.3/specs
gcc version 2.3.3
oconee:tmp% cat foo.c
#define Blk(x)          (-x)


foo()
{
	Blk(-1);
}
oconee:tmp% gcc -E foo.c
# 1 "foo.c"

foo()
{
	         (--1) ;
}
oconee:tmp% cc -E foo.c
# 1 "foo.c"
# 6


foo()
{
	 ( - - 1 ) ;
}
#ident "acomp: (CDS) SPARCompilers 2.0.1 03 Sep 1992"
oconee:tmp% 


Newsgroups: gnu.gcc.bug
From: jivano@samser.gold.SUb.ORG (Swami Sangit Jivano)
Subject: gcc 2.3.1 will not run with SCO 3.2v4.0 assembler & decimal-comma
Organization: SAM - Software Artists Munich
Distribution: gnu
Date: Sat, 9 Jan 1993 04:29:33 GMT

After compiling the gcc 2.3.1 (plus some patches from E.J.Vens) on an
SCO ODT 3.2v4.0 with international supplement, I detected a bug in the
'as' assembler which came with the SCO development system:

	'as' does not compile 'double'- statements correctly,
	if the locale-environment specifies a "decimal-comma"
	instead of the "decimal-point" used in English speaking
	countries.

To reproduce the error, do:

	set LANG=german_germany.8859

	assemble a program e.g. with 'double 1.000e+1'

	and look at the generated constant thru a debugger
	(should be 10.000, but is generated as 1.000).

Thus the gcc on these systems either needs another assembler as a back-end
(like the gas) or an locale-setting like "export LANG=english_us.8859"
- at least until SCO has that bug fixed. Failure to do so will hang
the generation (a loop in the execution of ./enquire), because of the
incorrectly generated floating point constants (e.g 1.0 instead of 10.0).

NB: The ATT compiler, which comes with the system - 'rcc' - has similiar
    problems. Only the MS-C compiler 'cc' works independant of the
    LANG-setting.

The reason for this faults obviously is the usage of 'strtod()' within
the assembler which was itself not build with the '-nointl' flag
( as 'intl' became the default of the SCO ODT cc now ).

As the gcc itself also needs the 'strtod()', it's bootstrap should
probably be done with 'CC=cc -nointl'.

Greetings, Jivano.
-- 
Jivano@samser.gold.sub.org              Dorfstrasse 5, 8031  Woerthsee, Germany
Swami Sangit Jivano                     Call: +49 8153 89138     Fax: ... 89238


Newsgroups: gnu.gcc.bug
From: rontay@netxwest.COM (Ron Taylor)
Subject: ___main
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 00:43:44 GMT

I found ___main in ccrt0.o and included this in my compile command.

This worked, but I'd still like to know how this is supposed to 
be set up.


Thanks,

Ron Taylor
rontay@netxwest.com

Newsgroups: gnu.gcc.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: installing info files.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 19:36:33 GMT

Program: gcc
Version: 2.3.3
Hardware: SPARCstation IPX
OS: SunOS4.1.1
Description:
  Can the makefile be modified to automatically install the info files
  as part of the installation process. Other GNU programs that I have
  installed place their info files at '$(prefix)/info'.

Newsgroups: gnu.gcc.bug
From: simon@lia.di.epfl.CH
Subject: GCC 2.3.3 (MIPS): inline bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 21:20:00 GMT

liasg1[gcc-2.3.3]% gcc -v
Reading specs from /logiciels/public/gnu/lib/gcc-lib/iris4d/2.3.3/specs
gcc version 2.3.3

Somebody complained that the C++ side of GCC 2.3.3 didn't work on the
Silicon Graphics, and I found out that cc1plus dumped core during
initialization.  The gcc installation has been bootstrapped properly;
a cc1plus that has just been compiled with SGI's standard CC seems to
work fine.

Here's what GDB says:

----------------------------------------------------------------------
liasg1[gcc-2.3.3]% gdb cc1plus
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.7, Copyright 1992 Free Software Foundation, Inc...
Breakpoint 1 at 0x55ce48: file abort.c, line 36.
(gdb) r
Starting program: /usr/tmp/gcc-2.3.3/cc1plus

Program received signal 11, Segmentation fault
0x43b170 in init_lex () at cp-lex.c:756
756           UNSET_RESERVED_WORD ("exception");
(gdb) bt
#0  0x43b170 in init_lex () at cp-lex.c:756
During symbol reading, guessed tag type of struct sigaction incorrectly.
#1  0x46caec in compile_file (name=0x1003944c "stdin") at toplev.c:1535
#2  0x46fcf0 in main (argc=1, argv=0x7fffc754, envp=0x65) at toplev.c:3285
(gdb)
----------------------------------------------------------------------

The problem seems to be related to inlining - UNSET_RESERVED_WORD
calls is_reserved_word which is declared inline.

Here's a smaller example that demonstrates the bug.  It runs fine when
compiled without -O, but dumps core in the same statement as above
when compiled with -O ("gcc -I. -I. -I./config -O foo.c" in the top
gcc source directory):

------------------------------ foo.c ------------------------------
#include <sys/types.h>
#include <stdio.h>
#include <errno.h>
#include <setjmp.h>
#include "config.h"
#include "input.h"
#include "tree.h"
#include "cp-lex.h"
#include "cp-parse.h"
#include "cp-tree.h"
#include "flags.h"
#include "obstack.h"

#ifdef MULTIBYTE_CHARS
#include <stdlib.h>
#include <locale.h>
#endif

#include "cp-hash.h"

#ifndef errno
extern int errno;		/* needed for VAX.  */
#endif
extern jmp_buf toplevel;

#define obstack_chunk_alloc xmalloc
#define obstack_chunk_free free

extern struct obstack *expression_obstack, permanent_obstack;
extern struct obstack *current_obstack, *saveable_obstack;

extern double atof ();

extern char *get_directive_line ();	/* In c-common.c */

extern int
main ()
#define UNSET_RESERVED_WORD(STRING) \
  do { is_reserved_word (STRING, sizeof (STRING) - 1)->name = ""; } while (0)

{
  UNSET_RESERVED_WORD ("all");
  UNSET_RESERVED_WORD ("except");
  UNSET_RESERVED_WORD ("exception");
  return 0;
}
------------------------------ foo.c ------------------------------


Newsgroups: gnu.gcc.bug
From: mgarrett@metz.une.edu.au (Mark Garrett)
Subject: Ultrix 4.2 gcc2.3.[23]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 16:37:56 GMT

	While compiling elm2.4pl17 with gcc2.3.2 or gcc2.3.3 on ultrix
4.2 I get the following errors (note this does not happend with ultrix4.3)

	Can anyone help me with this rather cryptic message?

	Thanks in advance,

		Mark :)
gcc -fpcc-struct-return  -O2 -I../hdrs    -c showmsg.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c showmsg_c.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c signals.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c softkeys.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c sort.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c string2.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c strings.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c syscall.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c utils.c
gcc -fpcc-struct-return  -O2 -I../hdrs    -c wildcards.c
wildcards.c: In function `has_wildcards':
wildcards.c:103: warning: assignment makes pointer from integer without a cast
gcc -fpcc-struct-return  -O2 -I../hdrs    -c wordwrap.c
gcc  -o ../bin/elm addr_util.o   alias.o                 aliaslib.o      args.o          a_edit.o        a_screen.o      a_sort.o        a_quit.o        bouncebk.o      builtin.o       calendar.o      curses.o        date.o          delete.o        edit.o          editmsg.o       elm.o           encode.o        exitprog.o      expires.o       file.o          file_util.o     fileio.o        find_alias.o    forms.o                 hdrconfg.o      help.o          in_utils.o      init.o          leavembox.o   


  lock.o          limit.o                 mailmsg1.o      mailmsg2.o      mime.o          mkhdrs.o        newmbox.o       options.o       out_utils.o     pattern.o       pmalloc.o       quit.o          read_rc.o       remail.o        reply.o                 returnadd.o     save_opts.o     savecopy.o      screen.o        showmsg.o       showmsg_c.o     signals.o       softkeys.o      sort.o          string2.o       strings.o       syscall.o       utils.o                 wildcards.o     wordwrap.o ../lib/lib


util.a -ltermlib  
ld:
../lib/libutil.a(getarpdate.o): gp relocation out-of-range in .text section for relocation entry 2 for symbol: timezone
../lib/libutil.a(getarpdate.o): above gp relocation entry for non .sdata or .sbss symbol
gp relocation out-of-range for small data or bss by,
              0 in the positive direction,
      264080944 in the negative direction.
Best -G num value to compile all -count'ed objects creating ../bin/elm with is 1012
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).
collect: /usr/bin/ld returned 1 exit status
*** Error code 1

Stop.
*** Error code 1

Stop.


Newsgroups: gnu.gcc.bug
From: shap@halifax.syncomas.com
Subject: Bug in config/i386bsd.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 04:46:00 GMT

   I just looked in config/i386/bsd.h (new name for config/i386bsd.h)
   and I don't see any macros with parameters that might be stringified.
   Which macros might have this happen?  Can you send me the preprocessed
   output from a compiler that stringized something unexpectedly?

I included a command in my original mail that should give warnings on
stringification:

   > 	gcc -Wtraditional -I. -I.. -E i386bsd.h > /dev/null

The reason I included the command is because it's the sort of problem
that is hard to spot by eye, and if it exists in this header file it
probably exists in others. By turning on traditional warnings, the gcc
-E command above will give you line numbers and warnings for (among
other things) potential stringification problems.

The offending macros in my copy of i386bsd.h are:

	perform_udivsi3
	perform_divsi3
	perform_umodsi3
	perform_modsi3

In each case, the macro arguments 'a' and 'b' appear within the asm
strings within the macros. Specifically, the strings "=a" and "a"
cause substitution of the macro argument name 'a'.  The problem won't
show up when compiling native under BSD, but it will bite you in some
cross-compiles.

I suppose it's possible that someone has already applied an earlier
bug fix I sent in on this, and has changed the macro arguments to 'aa'
and 'bb'.  Or maybe the macros were moved to another file in your
reorganization?

Anyway, if you look at the indicated macros below, the problem should
be obvious.

Hope that helps.  I can generate bad cpp output for you if you really
want it, or send you a copy of my config/i386bsd.h if it will help.


Jonathan S. Shapiro

Newsgroups: gnu.gcc.bug
From: dic5340@hertz.njit.edu (David Charlap)
Subject: Bug in gcc's rand() function.
Organization: New Jersey Institute of Technology, Newark, N.J.
Distribution: gnu
Date: Mon, 4 Jan 1993 21:07:29 GMT

When the stdlib.h rand() function is called, the sequence is
repeatable, mod 8.

For example, the following code:

	#include <stdio.h>
	#include <stdlib.h>

	main() {
	  int x;

	  for (x=0; x<100; x++)
	    printf ("%d   ", rand() % 8);
	}

always produces the following repeating sequence:

	6   7   4   5   2   3   0   1

I have tested it on the OS/2 2.0 port of gcc and the Dec-Ultrix
version, and I get the same result in both cases.
-- 
  |)  David Charlap          | .signature confiscated by FBI due to
 /|_  dic5340@hertz.njit.edu | an ongoing investigation into the
((|,)                        | source of these .signature virusses
 ~|~

Newsgroups: gnu.gcc.bug
From: joe@modcomp.COM (Joe Korty)
Subject: gcc-2.3.3: ++E vs E+=1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 20:13:01 GMT

Gcc generates less efficient code for the `++E' construct than it does
for the equivalent `E+=1', a suprising result given that the pre- and
post-increment forms are intended to make it easier for compilers to
find the most efficient code.  Below are some sample 88k assembly
fragments illustrating the effect.  The inefficiency (I hesitate to
call it a problem) seems to originate in the way expand_increment()
converts a preincrement tree to rtl (done in a funny way in order to
get around a nasty protect_from_queue() side effect in expand_binop()),
and hence is likely to affect more than just the 88k.

Compiler options: -O.  Compilers tested: 2.2.2, 2.3.1, 2.3.3.  System:
m88k-realix (a svr3 motorola delta box derivative; for C, equivalent to
m88k-motorola).

We noticed this only because it came up in some critical sections of
our code; for now, we have converted the most affected statements to the
equivalent assignment form.

; f(sp)
; register short *sp;
; {
;  return ++(*sp);
; }
_f:
	ld.hu	 r9,r0,r2
	addu	 r9,r9,1
	st.h	 r9,r0,r2
	ld.h	 r2,r0,r2  ; why the extra load?  should be an ext r2,r9,16<0>
	jmp	 r1


; g(sp)
; register short *sp;
; {
;   return (*sp)+=1;
; }
_g:
	or	 r9,r0,r2
	ld.hu	 r2,r0,r9
	addu	 r2,r2,1
	st.h	 r2,r0,r9
	jmp.n	 r1
	ext	 r2,r2,16<0>

Any changes to gcc will also have to pass the following stress test.
This causes emit_queue() to be called at the appropriately nasty point,
and will result in subtly defective assembly code if the fix is invalid
(naturally, I have not been able to find an efficient, valid fix to
expand_increment() that passes this test).

f(sp)
short *sp;
{
  return (++(*sp)) >= 0 ? g(sp) : 0;
}

-- 
Joe Korty,  REAL/IX Operating Systems

MODCOMP, an AEG Company			Telephone: (305) 977-1820
1650 West McNab Road			Fax:	   (305) 977-1638
P.O. Box 6099				E-mail:	   uunet!modcomp!joe
Ft. Lauderdale, FL 33309-1088

Newsgroups: gnu.gcc.bug
From: rontay@netxwest.COM (Ron Taylor)
Subject: what is ___main?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 23:42:17 GMT

I think we're missing a gcc library or something...


napali /home/beauty/rontay/test 548 cat main.c
main()
{
}
napali /home/beauty/rontay/test 549 gcc -c main.c
napali /home/beauty/rontay/test 550 gcc -o main main.o
main.o: undefined reference to `___main'
napali /home/beauty/rontay/test 551 
napali /home/beauty/rontay/test 551 
napali /home/beauty/rontay/test 551 
napali /home/beauty/rontay/test 551 gcc main.c
main.o: undefined reference to `___main'
napali /home/beauty/rontay/test 552 
napali /home/beauty/rontay/test 552 
napali /home/beauty/rontay/test 552 nm main.o

nm: can't open 'main.o'.
napali /home/beauty/rontay/test 553 gcc -c main.c
napali /home/beauty/rontay/test 554 nm main.o
         U ___main
00000000 T _main
00000000 t gcc2_compiled.
napali /home/beauty/rontay/test 555 


If I move main.c to main.cc and try "gcc main.cc" the
compilation completes with no errors.


Any ideas on what I'm doing wrong?

Thanks!

Ron Taylor
rontay@netxwest.com

Newsgroups: gnu.gcc.bug
From: obz@sisd.kodak.COM (Orest Zborowski COMP)
Subject: gcc-2.3.3: gcc -E foo.s runs gas
Organization: Printer Products Eastman Kodak
Distribution: gnu
Date: Tue, 5 Jan 1993 01:31:39 GMT

Trying to run makedepend for X11R5 I discovered that gcc -E foo.s will run
the assember, rather than stopping after performing any preprocessing:

---foo.s---
#define florp blorp
        florp
---
% gcc -v -E foo.s
Reading specs from /usr/local/lib/gcc-2.3.3/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 as -o /usr/tmp/cca233591.o foo.s
as: "foo.s", line 1: error: unknown opcode "FLORP"
as: "foo.s", line 1: error: statement syntax
gcc: /usr/tmp/cca233591.o: No such file or directory

Sun cc produces:
% cc -E foo.s
# 1 "foo.s" 

        blorp

I inferred from the manpage that
	-c stops after producing .o
	-S stops after producing .s
	-E stops after producing cpp file

It wasn't clear what was supposed to happen with a .s file, but Sun's behavior
seems consistent. Am I misunderstanding something?

zorst
-- 
zorst (orest zborowski)
[obz@raster.Kodak.COM]

Newsgroups: gnu.gcc.bug