HDTenEightyP/NetNews huggingface dataset:
From: bitbug@netcom.com (James Buster)
Subject: Bug in config/bsd386.h from gcc 2.3.3.
Organization: Lynx Real-Time Systems, Inc.
Distribution: gnu
Date: Tue, 5 Jan 1993 02:01:13 GMT

When NO_UNDERSCORES is in effect, compiler generated symbols must be prefixed
with `.', just like LPREFIX is. Unfortunately, this is not completely done in
bsd386.h. Here are fixes in context diff format:

*** config/bsd386.h	Mon Jan  4 17:19:27 1993
--- config/bsd386.h.orig	Mon Jan  4 17:19:30 1993
***************
*** 103,116 ****
--- 103,126 ----
     PREFIX is the class of label and NUM is the number within the class.
     This is suitable for output with `assemble_name'.  */
  
+ #ifdef NO_UNDERSCORES
+ #define ASM_GENERATE_INTERNAL_LABEL(BUF,PREFIX,NUMBER)	\
+     sprintf ((BUF), "*.%s%d", (PREFIX), (NUMBER))
+ #else
  #define ASM_GENERATE_INTERNAL_LABEL(BUF,PREFIX,NUMBER)	\
      sprintf ((BUF), "*%s%d", (PREFIX), (NUMBER))
+ #endif
  
  /* This is how to output an internal numbered label where
     PREFIX is the class of label and NUM is the number within the class.  */
  
+ #ifdef NO_UNDERSCORES
+ #define ASM_OUTPUT_INTERNAL_LABEL(FILE,PREFIX,NUM)	\
+   fprintf (FILE, ".%s%d:\n", PREFIX, NUM)
+ #else
  #define ASM_OUTPUT_INTERNAL_LABEL(FILE,PREFIX,NUM)	\
    fprintf (FILE, "%s%d:\n", PREFIX, NUM)
+ #endif
  
  /* This is how to output a reference to a user-level label named NAME.  */

-- 
				James Buster
			     bitbug@netcom.com

Newsgroups: gnu.gcc.bug
From: marc@mit.edu (Marc Horowitz)
Subject: ["Mark W. Eichin": gcc diff]
Reply-To: Marc Horowitz <marc@mit.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 00:02:52 GMT

Here is a patch to make "gcc -E -e" work.  It's off of a version of
gcc.c provided to me by eichin@cygnus.com.  I think he said it was
from the 930101 snapshot.  Anyway, it's pretty straightforward.

Thanks.

		Marc


*** gcc.c.fsf	Sat Jan  2 20:26:13 1993
- --- gcc.c	Sat Jan  2 20:47:03 1993
***************
*** 3632,3643 ****
    /* Look for a suffix.  */
    for (cp = compilers + n_compilers - 1; cp >= compilers; cp--)
      {
!       if (strlen (cp->suffix) < length
  	       /* See if the suffix matches the end of NAME.  */
  	       && !strcmp (cp->suffix,
! 			   name + length - strlen (cp->suffix))
! 	       /* The suffix `-' matches only the file name `-'.  */
! 	       && !(!strcmp (cp->suffix, "-") && length != 1))
  	{
  	  if (cp->spec[0][0] == '@')
  	    {
- --- 3632,3643 ----
    /* Look for a suffix.  */
    for (cp = compilers + n_compilers - 1; cp >= compilers; cp--)
      {
!       if ((strlen (cp->suffix) < length
  	       /* See if the suffix matches the end of NAME.  */
  	       && !strcmp (cp->suffix,
! 			   name + length - strlen (cp->suffix)))
! 	  /* The suffix `-' matches only the file name `-'.  */
! 	  || (!strcmp (cp->suffix, "-") && !strcmp (name, "-")))
  	{
  	  if (cp->spec[0][0] == '@')
  	    {


------- End of Forwarded Message


Newsgroups: gnu.gcc.bug
From: przemek@viewlogic.COM (Przemek Skoskiewicz)
Subject: Spurious warnings...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 21:52:21 GMT

Compiling the following code with -Wall option produces these warnings:

>gcc -Wall bar.c
bar.c:5: warning: return-type defaults to `int'
bar.c: In function `main':
bar.c:10: warning: implicit declaration of function `_filbuf'   <----
bar.c:11: warning: implicit declaration of function `fclose'    <----
bar.c:12: warning: control reaches end of non-void function


Why do I get the warnings for _filbuf and fclose given the fact that I've
included the stdio.h header file (especially in view of the lack of a warning
for fopen)?  I'm especially interested in _filbuf since it's cluttering the
more important warnings generated by the -Wall option.


#include    "stdio.h"

main()
{
    int     ch;
    FILE   *fp;

    fp = fopen ("bar.c", "r");
    ch = getc (fp);
    fclose (fp);
}


System: SPARCstation IPX
OS:     SunOS 4.1.3
GCC:    2.2.2 and 2.3.2 and 2.3.3


Viewlogic Systems, Inc.                         Przemek Skoskiewicz
293 Boston Post Road West
Marlborough, MA 01752-4615, USA
email: przemek@viewlogic.com

Newsgroups: gnu.gcc.bug
From: kessler@romulus.CRay.COM (Richard Kessler  {66651 CF/DEV})
Subject: gcc bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 22:28:29 GMT

/*

GCC BUG: bad code with nested switches and double-length
   integers.

This is example code to exercise a gcc bug.

On a "sparc-sun-sunos4.1" with gcc version 2.2.2, the
following code core dumps. I used "gcc -ggdb file.c" to
compile.

 I can fix it by: (a) the "#define switch(a) switch((int)(a))"
below, or (b) "typedef int longint" instead of
"typedef long long longint". The nested switch also seems
important; I don't think it will core dump with just one
switch level.

It coredumps on the outermost "switch".

*/

#include <stdio.h>
/*
#define switch(a) switch((int)(a))
*/

typedef long long longint;
void main(void);
void wwrite(longint);

void main(void)
{
	wwrite((longint) 0);
}

void wwrite(longint i)
{
	longint j = 0;

	switch(i)
	{
	case 1:
	case 2:
	case 3:
	case 4:
	case 5:
	case 6:
	case 7:
	case 0xa:
	case 0x1c:
		j = 1;
	case 23:
		switch(j)
		{
		case 0:
			printf("hello\n");
			break;
		case 1:
			printf("bye\n");
			break;
		}
		break;
	case 47:
		printf("hi\n");
		break;
	default:
		printf("ho\n");
		break;
	}
}

Newsgroups: gnu.gcc.bug
From: was%oberon@garwein.hai.siemens.co.AT (Wolfgang Anton Sommerer)
Subject: bugs in gcc-2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 12:04:20 GMT

I have to report two bugs which occured while installing InterViews3.1
and libg++-2.3. Hardware configuration is a SUN4/60 running SunOS4.1.1.


1.) Bug in handling of multpile inheritance

This bug actually occured when running the doc Apllication of InterViews3.1.
It resulted in a segmentation violation with the following phenomenon.

	The line 
	
		x->request(y);
		
	resulted in a call to
	
		x->event(y);
	
I was able to isolate the problem and reproduce it in a samll example program.

**** file : a.h ******

class Z {
public:
	virtual void z();
};

class A : public Z {
public:
	virtual void a1();
	virtual void a2();
};

class B : public Z {
public:
	virtual void b1();
	virtual void b2();
	virtual void b3();
};

class C : public A, public B {
	virtual void a1();
	virtual void a2();
	virtual void b1();
	virtual void b2();
};

**** file : a.C ******

#include "a.h"
#include "iostream.h"

void Z::z()  { }

void A::a1() { cout << " A::a1() called" << endl; }
void A::a2() { cout << " A::a2() called" << endl; }

void B::b1() { cout << " B::b1() called" << endl; }
void B::b2() { cout << " B::b2() called" << endl; }
void B::b3() { cout << " B::b3() called" << endl; }

void C::a1() { cout << " C::a1() called" << endl; }
void C::a2() { cout << " C::a2() called" << endl; }
void C::b1() { cout << " C::b1() called" << endl; }
void C::b2() { cout << " C::b2() called" << endl; }


**** file : main.C *****

main()
{
C c;

A& c1 = c;
B& c2 = c;

	c1.a2();
	c1.a1();
	c2.b1();
	c2.b2();
	c2.b3();
}


**** result of running the program ****

C::b2() called			<--- should be C::a2()
C::b1() called			<--- should be C::a1()
C::b1() called
C::b2() called
B::b3() called

The reason for this behaviour is a wrong vtable generated in file 
main.C (or a.C if #pragma interface and #pragma implementation is used).

_vt$C entries do not point to class A methods. They rather point to the
class B mehtods which reside at the same slot index. Changing the vtable 
in the assembler code manually did at least result in the expected behaviour 
of the program.

This workaround also fixed the problem at hand in the InterViews applicaiton.
But there the bug occurs many times, so manually changing the assembeler code
is impossible.



2.) Bug when compiling libg++-2.3

Compiling iostream.cc will generate a symbol named __vt$istream$3ios.
Compiling another file which includes iostream.h will generate 
a symbol __vt$7istream$3ios. So when linking the two files you'll get an
undefined symbol (__vt$7istream$3ios).

I solved the problem by putting a forward declaration of class istream into
streambuf.h.

I changed line 39 from :
	class ostream; class streambuf; class backupbuf;
to:
	class istream; class ostream; class streambuf; class backupbuf;

This works fine !



If there exists a patch for the first problem please let me know.

Regards,

Wolfgang Sommerer




Newsgroups: gnu.gcc.bug
From: pmontgom@math.orst.edu (Peter Montgomery)
Subject: Uninitialized address for temporary (SPARC, gcc 2.3.3)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 23:06:40 GMT

/*
	Subject: Uninitialized address for temporary (SPARC, gcc 2.3.3)


		Variables f1, f2, f3 contain successive results of
	a floating point function.  Since SPARC floating point 
	registers are not preserved by function calls, 
	gcc -O (version 2.3.3) moves f1 to %l4 and f2 to %l2.
	Later, when f1, f2, and f3 are used in a computation,
	address [%o3] is used to move f1 back to a floating
	point register, but %o3 has not been initialized.
	
		The problem occurs only if the program
	has lots of local data, and a displacement over
	12-bits might be required on the temporary.

		Peter Montgomery
		Department of Mathematics
		Oregon State University
		Corvallis, OR 97331-4605
		pmontgom@math.orst.edu

	Specifically, the generated code (SPARC, SunOS 4.1.1) contains

L6:
        call _printf,0
        mov %l2,%o1			itest (for printf)
        call _drand48,0
        add %l2,1,%l2			itest++
        std %f0,[%fp-8]
        ldd [%fp-8],%l4			%l4 = f1
        call _drand48,0
        nop
        std %f0,[%fp-8]
        ldd [%fp-8],%l0			%l0 = f2
        call _drand48,0
        nop
        std %l4,[%o3]			***** %o3 undefined *****
        ldd [%o3],%f4			Attempting to move f1 to %f4
        sethi %hi(-5024),%o3
        or %o3,%lo(-5024),%o3
        add %o3,%fp,%o3
        std %l0,[%o3]
        ldd [%o3],%f6			%f6 = f2
        faddd %f4,%f6,%f2		%f2 = f1 + f2
        faddd %f2,%f0,%f0		%f0 = f1 + f2 + f3
        std %f0,[%fp-8]
        ld [%fp-4],%o2
        ld [%fp-8],%o1
        call _printf,0			Print f1 + f2 + f3
        or %l3,%lo(LC1),%o0

*/
double drand48();		/* SUN random number generator */
/* #include <stdio.h> */

int main(int argc, char* argv[])
{
#if 1			/* Works if this is removed */
    char unused[5000];
#endif
    double f1, f2, f3;
    int itest; 
    for (itest = 1; itest <= 10 ; itest++) {
	printf("Iteration %d\n", itest);
        f1 = drand48(); 
        f2 = drand48(); 
        f3 = drand48();
	printf("Random sum: %6f\n", f1 + f2 + f3);
    }					 
    exit(0);
}

Newsgroups: gnu.gcc.bug
From: shap@halifax.syncomas.com
Subject: Bug in cross builds
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 07:03:00 GMT

I can't remember if I sent this in or not.

The LIBGCC2_CFLAGS variable should probably include -Isys-include.
That way, if I have a directory that is already set up for
cross-building the compiler, I have a chance of building libgcc2.a

Also, in the make rule for collect, STANDARD_STARTFILE_PREFIX should
be $(libsubdir), not $(libdir).  Making it $(libdir) is an anachronism
from the pre-libsubdir days.  By changing it to $(libsubdir)
cross-making collect works again.

Newsgroups: gnu.gcc.bug
From: alex.ZAtsman@analog.COM (Alex Zatsman)
Subject: Re:  Unending Warnings about '-Wid-clash-..'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 21:16:06 GMT

Earlier I wrote:

	Calling "gcc -Wid-clash-LEN <file name>" sends cc1 into infinite loop
	in which it prints 

		cc1: error: Invalid option `-Wid-clash-LEN'

	on each iteration. The bad code is in toplev.c (line 2848):

			  while (*endp)
			    {
....


The fix in that message was not good enough -- cc1 still issued id
clash warnings for length 0. A better fix is:


		  warn_id_clash = 1;
		  while (*endp)
		    {
		      if (*endp >= '0' && *endp <= '9')
			endp++;
		      else
		      {
			  error ("Invalid option `%s'", argv[i]);
			  warn_id_clash = 0;
			  break;
		      }
		    }
		  id_clash_len = atoi (str + 10);


Sorry for bad fix.

Alex Zatsman.
Analog Devices, Inc.

Newsgroups: gnu.gcc.bug
From: adda@acri.FR (Serge Adda)
Subject: porting problem
Organization: Advanced Computer Research Institute
Distribution: gnu
Date: Mon, 11 Jan 1993 09:56:23 GMT

Hello,

I am porting gcc to a new system where I have to
define ASM_OUTPUT_EXTERNAL. The macro prints out 
a ".global 'func'" in the assembly file.

The problem is that if a function is called n times,
assemble_external prints out n times the ".global"
assembly directive.

When the option "-traditional" is used, the directive
is only printed once.

Could someone have an explanation?

Thanx.

Serge Adda - A.C.R.I. Compiler Team
email: adda@acri.fr

Newsgroups: gnu.gcc.bug
From: dennis@ans.net (Dennis Ferguson)
Subject: ffs() with gcc 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 06:14:32 GMT

There is at least one bug report in here, and perhaps a second unless I
am missing something.  I am using gcc 2.3.3 configured for i386-bsd and
sparc-sun-sunos4.1 (I am running both versions on a Sun, if this matters).
My understanding is that gcc should recognize ffs() as a builtin under
certain conditions, and that if the machine has an instruction to do this
gcc will generate code which uses it.  In addition gcc should almost always
recognize references to __builtin_ffs() as referring to the built in
version of the routine.

The 386 CPU has an ffs() instruction, and a template using this is included
in config/i386.md.  Using __builtin_ffs() to reference this seems to work 
fine:

  azilda.ans.net> cat myffs_builtin.c
  int
  myffs(int i)
  {
	return __builtin_ffs(i);
  }
  azilda.ans.net> gcc386 -O -S -Wall myffs_builtin.c
  azilda.ans.net> cat myffs_builtin.s
	.file   "myffs_builtin.c"
  gcc2_compiled.:
  .text
	.align 2
  .globl _myffs
  _myffs:
	pushl %ebp
	movl %esp,%ebp
	movl $-1,%eax
	bsfl 8(%ebp),%eax
	incl %eax
	leave
	ret
  azilda.ans.net> 

Unfortunately I have yet to be able to find a set of options which will
compile a reference to ffs() the same way as __builtin_ffs().  Neither
the Sun nor the i386 compiler seems to recognize ffs() as a built-in,
so both always generate external calls:

  azilda.ans.net> cat myffs.c
  int
  myffs(int i)
  {
	return ffs(i);
  }
  azilda.ans.net> gcc386 -O -S -Wall myffs.c
  myffs.c: In function `myffs':
  myffs.c:4: warning: implicit declaration of function `ffs'
  azilda.ans.net> cat myffs.s
	.file   "myffs.c"
  gcc2_compiled.:
  .text
	.align 2
  .globl _myffs
  _myffs:
	pushl %ebp
	movl %esp,%ebp
	pushl 8(%ebp)
	call _ffs
	leave
	ret
  azilda.ans.net> 

It hence appears that the only way to get ffs() to compile to an instruction
on machines which have one is to include a -Dffs=__builtin_ffs somewhere.
The problem with this is that with the sparc compiler, whose machine
description does not define an ffs() instruction, __builtin_ffs()
compiles as a call to __ffssi2().  The latter routine, which looks
like it should be part of libgcc?.c, does not exist.

  azilda.ans.net> gcc -O -S -Wall myffs_builtin.c
  azilda.ans.net> cat myffs_builtin.s
  gcc2_compiled.:
  .text
	.align 4
	.global _myffs
	.proc   04
  _myffs:
	!#PROLOGUE# 0
	save %sp,-136,%sp
	!#PROLOGUE# 1
	call ___ffssi2,0
	mov %i0,%o0
	ret
	restore %g0,%o0,%o0
  azilda.ans.net> gcc -O -o mymain mymain.c myffs_builtin.c
  ld: Undefined symbol 
     ___ffssi2 
  collect: /usr/bin/ld returned 2 exit status
  azilda.ans.net> 

Ideally I would like gcc to recognize ffs() as a builtin function the
way it does other builtin's, certainly on machines where there is some
benefit to this.  Failing this I would at least like __builtin_ffs()
to compile and load correctly on all target machines.

Thanks,
Dennis Ferguson

Newsgroups: gnu.gcc.bug
From: mycroft@gnu.ai.mit.edu
Subject: [i386-unknown-bsd] internal error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 08:28:10 GMT

This seems to go away if I omit the `-traditional'.

bash# gcc -v -traditional -O util.c
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-bsd/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/i386-unknown-bsd/2.3.3/cpp -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386 -D____386BSD____ -D__386BSD__ -DBSD_NET2 -D__unix__ -D__i386__ -D____386BSD____ -D__386BSD__ -D__BSD_NET2__ -D__unix -D__i386 -D____386BSD____ -D__386BSD__ -D__BSD_NET2 -D__OPTIMIZE__ -traditional util.c /var/tmp/cc003872.i
GNU CPP version 2.3.3 (80386, BSD syntax)
 /usr/local/lib/gcc-lib/i386-unknown-bsd/2.3.3/cc1 /var/tmp/cc003872.i -quiet -dumpbase util.c -O -traditional -version -o /var/tmp/cc003872.s
GNU C version 2.3.3 (80386, BSD syntax) compiled by GNU C version 2.3.3.
util.c: In function `mypopen':
util.c:15: internal error--unrecognizable insn:
(insn 16 15 75 (parallel[ 
            (set (reg:CC 30)
                (compare:CC (mem:BLK (reg:SI 25))
                    (mem:BLK (reg:SI 26))))
            (use (reg:SI 27))
            (use (const_int 1))
            (clobber (reg:SI 25))
            (clobber (reg:SI 26))
            (clobber (reg:SI 27))
        ] ) -1 (insn_list 11 (insn_list 13 (insn_list 15 (nil))))
    (expr_list:REG_UNUSED (reg:SI 25)
        (expr_list:REG_UNUSED (reg:SI 26)
            (expr_list:REG_UNUSED (reg:SI 27)
                (nil)))))
gcc: Internal compiler error: program cc1 got fatal signal 6
bash# cat util.c
int
mypopen(cmd)
char *cmd;
{
    int p[2];
    register int pid;
    int doexec = strcmp(cmd,"-");

    if (pipe(p) < 0)
        return -1;
    while ((pid = (doexec?vfork():fork())) < 0) {
    }
    close(p[1]);
    return p[0];
}
bash# 


Newsgroups: gnu.gcc.bug
From: tw@sics.se (Tommy Wallo)
Subject: Bug in gcc-2.3.3 fixinclude for AIX-3.1.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 12 Jan 1993 08:04:49 GMT

subotnick:tw> uname -a
AIX subotnick 1 3 000005423000
subotnick:tw> lslpp -h bos.obj
                     ACTIVE     COMMIT     07/23/91  03.01.0005.0012 root
subotnick:tw> gcc -v
Reading specs from /usr/gnu/lib/gcc-lib/rs6000/2.3.3/specs
gcc version 2.3.3


Fixinclude genereates an erroneous file device.h.

subotnick:tw> pwd
/usr/gnu/lib/gcc-lib/rs6000/2.3.3/include
subotnick:tw> diff device.h.corrupt /usr/include/device.h
156,162c156,162
< /* #define BUT103     104     */**              Light Pen Button      */*/
< /* #define BUT104     105     */**              Bitpad Button 0       */*/
< /* #define BUT105     106     */**              Bitpad Button 1       */*/
< /* #define BUT106     107     */**              Bitpad Button 2       */*/
< /* #define BUT107     108     */**              Bitpad Button 3       */*/
< /* #define BUT108     109     */**              Light Pen Valid       */*/
< /* #define BUT109     110     */**              UNUSED                */*/
---
> /* #define BUT103     104     *//*              Light Pen Button      */
> /* #define BUT104     105     *//*              Bitpad Button 0       */
> /* #define BUT105     106     *//*              Bitpad Button 1       */
> /* #define BUT106     107     *//*              Bitpad Button 2       */
> /* #define BUT107     108     *//*              Bitpad Button 3       */
> /* #define BUT108     109     *//*              Light Pen Valid       */
> /* #define BUT109     110     *//*              UNUSED                */


---
Tommy Wallo                                     Internet: tw@sics.se
Swedish Institute of Computer Science (SICS)    Tel:      +46 8 752 15 53
PO Box 1263, S-164 28 KISTA, SWEDEN             Fax:      +46 8 751 72 30

Newsgroups: gnu.gcc.bug
From: simon@lia.di.epfl.CH (Simon Leinen)
Subject: Re: gcc-2.3.3 - bug on SUN for (char *) within a struct
Organization: Ecole Polytechnique Federale de Lausanne
Distribution: gnu
Date: Fri, 8 Jan 1993 12:23:48 GMT

In article <9301071447.AA12676@uk0x06.ggr.co.uk> gml4410@ggr.co.UK
(Lack Mr G M) writes:

        I wish to report a bug in gcc-2.3.3 on a SUN.

        I  have  built  gcc-2.3.3 on a Sun Sparcstation at SunOS4.1.1.  The
   configure option was "sparc-sun-sunos4.1" and I  used  CFLAGS=-O  during
   the makeing, which completed with no errors.

        The  following  simple  program dies with a segmentation fault.  It
   runs correctly with gcc-2.3.3 on an SG Indigo, with Suns own cc compiler
   (and with other c compilers on other platforms).

If there's a bug, then it's that the GCC-compiled binary on the SGI
doesn't get the segmentation fault.  Your strcpy()'s are overwriting
string constants, which are usually allocated in read-only space by
GCC (as you can see by the ".text" directives preceding the ".ascii"
directives for your string constants).  This is a deliberate design
decision which improves VM performance.  If you want to turn this
behaviour off, you can pass the "-fwritable-strings" option to GCC.
--
Simon.

Newsgroups: gnu.gcc.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: since when is @ a symbol for a C identifier?
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 8 Jan 1993 15:40:05 GMT

I'm running gcc 2.3.2 on sparcs...

What does the @ symbol mean to a C compiler? (I don't recall)

This program got an assembler error:
main()
{
        foo@();
}

This produced:

gcc2_compiled.:
text
        .align 4
        .global _main
        .proc   04
_main:
        !#PROLOGUE# 0
        save %sp,-136,%sp
        !#PROLOGUE# 1
        call ___main,0
        nop
        call _foo@,0
        nop
L1:
        ret
        restore

Here's a copy of the run:

gcc version 2.3.2
 /usr/gnu/lib/gcc-lib/sparc/2.3.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix identifier.c /usr/tmp/cca02981.i
GNU CPP version 2.3.2 (sparc)
 /usr/gnu/lib/gcc-lib/sparc/2.3.2/cc1 /usr/tmp/cca02981.i -quiet -dumpbase identifier.c -version -o /usr/tmp/cca02981.s
GNU C version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
 as -o /usr/tmp/cca029811.o /usr/tmp/cca02981.s
/usr/tmp/cca02981.s:12:Illegal operands
 /usr/gnu/lib/gcc-lib/sparc/2.3.2/ld -e start -dc -dp /lib/crt0.o -L/usr/gnu/lib/gcc-lib/sparc/2.3.2 -L/usr/gnu/lib /usr/tmp/cca029811.o -lgcc -lc -lgcc
ld: Undefined symbol 
   _foo 
collect: /usr/bin/ld returned 2 exit status

In a large project, the make stopped after the assembler error...in this example, after the assembler error,
the link was attempted...


--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.gcc.bug
From: marc@mit.edu (Marc Horowitz)
Subject: ["Mark W. Eichin": gcc diff]
Reply-To: Marc Horowitz <marc@mit.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 00:03:33 GMT

(if this looks like a duplicate, it's not.  Ignore the previous one.)

Here is a patch to make "gcc -E -" work.  It's relative to a version
of gcc.c provided to me by eichin@cygnus.com.  I think he said it was
from the 930101 snapshot.  Anyway, it's pretty straightforward.

Thanks.

		Marc


*** gcc.c.fsf	Sat Jan  2 20:26:13 1993
- --- gcc.c	Sat Jan  2 20:47:03 1993
***************
*** 3632,3643 ****
    /* Look for a suffix.  */
    for (cp = compilers + n_compilers - 1; cp >= compilers; cp--)
      {
!       if (strlen (cp->suffix) < length
  	       /* See if the suffix matches the end of NAME.  */
  	       && !strcmp (cp->suffix,
! 			   name + length - strlen (cp->suffix))
! 	       /* The suffix `-' matches only the file name `-'.  */
! 	       && !(!strcmp (cp->suffix, "-") && length != 1))
  	{
  	  if (cp->spec[0][0] == '@')
  	    {
- --- 3632,3643 ----
    /* Look for a suffix.  */
    for (cp = compilers + n_compilers - 1; cp >= compilers; cp--)
      {
!       if ((strlen (cp->suffix) < length
  	       /* See if the suffix matches the end of NAME.  */
  	       && !strcmp (cp->suffix,
! 			   name + length - strlen (cp->suffix)))
! 	  /* The suffix `-' matches only the file name `-'.  */
! 	  || (!strcmp (cp->suffix, "-") && !strcmp (name, "-")))
  	{
  	  if (cp->spec[0][0] == '@')
  	    {


------- End of Forwarded Message


Newsgroups: gnu.gcc.bug