HDTenEightyP/NetNews huggingface dataset:
From: amorton@cc.uow.EDU.AU (andrew morton)
Subject: CSE optimization opportunities missed (68k)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 17:03:01 GMT

A few things I have noticed in gcc2.2.2 (m68k):

The code

foo()
{
	bar(0x12345);
	bar(0x12345);
	bar(0x12345);
	bar(0x12345);
	bar(0x12345);
}

Doesn't put the constant into a register: it seems that
constant function arguments are being missed as CSE
candidates.

Also, in the code

foo(int a, int b, int c, int d)
{
	a += 0x12345;
	b += 0x12345;
	c += 0x12345;
	d += 0x12345;
	bar(a, b, c, d);
	zot(0x12345);
}

The constants used in the additions are held in a register
but that register is not used for the call to zot(): a constant
is pushed instead.

Thirdly, there seems to be a problem with -funroll-all-loops
and -frerun-cse-after-loops.  In the code

foo()
{
	int i;

	for (i = 0; i < 10; i++)
		bar();
}

The address of bar() is not held in a register after
unrolling.


Newsgroups: gnu.gcc.bug
From: urabe@ttc.rdc.ricoh.co.JP
Subject: Re: ioctl does not work in gcc.2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 09:12:34 GMT

	Some peoples point me that my ioctl problem occured when
	I forgot to run fixincludes.

	Unfortunatly, I already run "gmake install-fixincludes".
	I run "gmake fixincludes" again, and compile the program.
	But the same problem happened.

	Thank you for your kindness.

				701 Development Group
				NA Development Department
				Advanced Technology Development Center	
				Research and Development Group
				RICOH Co. Ltd.

					Akio Urabe

				urabe@ttc.rdc.ricoh.co.jp
				tel +81-45-593-3411 ext 3040    
				    +81-45-590-1203 
				FAX 81-45-593-3487 (G3)   81-45-590-1201 (G4)

Newsgroups: gnu.gcc.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: GCC-2.3.1 doesn't compile under NeXTstep 3.0
Organization: U. C. Berkeley
Distribution: gnu
Date: Tue, 17 Nov 1992 01:23:31 GMT

In article <9211160513.AA00346@_grettir.quorum.com_> brown@quorum.COM (Robert E. Brown) writes:
>In an earlier bug report, which I saw in gnu.gcc.bug, Magnus Nordborg
>(magnus@fisher.stanford.edu) reports that GCC version 2.3.1 does not compile
>on Next computers running release 3.0 of the operating system.
>
>The problem seems to be the use of Objective C (or C++) style comments in
>Next's /usr/include/ansi/m68k/stdarg.h include file, which is included
>indirectly when the GCC source code contains #include <stdarg.h>.  I don't
>think the use of the // comment syntax belongs in an ANSI include file.

Perhaps the best way to fix this is to extend fixincludes, which is
intended to install legal ANSI replacements for defective vendor headers.
In this case, it would turn // comments into /* comments.

If stdarg.h is the only file with this wierdness, it would be enough to
put a fixed copy of it into the /usr/local/lib/gcc-lib/next-whatever/include
directory by hand (check the path on your system; it's where the
gcc-generated header files live).


--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.gcc.bug
From: rwk@quark.sbi.com (Richard W. Kreutzer Consultant)
Subject: PIC option broken?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 20:58:45 GMT

Did the -fpic option get broken from gcc-2.2.2 to gcc-2.3.1?  Or have I
installed gcc improperly?  I have compiled gcc-2.3.1 on a SPARCstation 1+
running SunOS 4.1.1 in the usual fashion.  However the following now fails (it
worked under 2.2.2):

	void printf(...);
	void a() {
	  printf("Hi\n");
	  }

	$ gcc -fpic -c a.c
	gcc: Internal compiler error: program cc1 got fatal signal 6

G++ fails in the same way:

	$ g++ -fpic -c a.c
	Internal compiler error: program cc1plus got fatal signal 6

Is there a patch I can install?  I have removed all traces of 2.2.2 because I
lack disk space and everything seemed to work in 2.3.1 (until this) so I
deleted all traces of 2.2.2.  Thanks,

Dick
____
        Richard W. (Dick) Kreutzer
Net:    rwk@quark.sbi.com				CIS:	70702,2174
Voice:  +1(801)571-2446					FAX:	+1(801)571-2448
Mail:   Integra Software Corp.; 1378 Jasmine Avenue; Sandy, UT 84092 (USA)

Newsgroups: gnu.gcc.bug
From: bray@wcuvax1.wcu.edu (Jim Bray)
Subject: Info Documentation of -mno-486 switch is wrong
Followup-To: bray@wcuvax1.wcu.edu (Jim Bray)
Organization: North Carolina State University
Distribution: gnu
Date: Sat, 21 Nov 1992 01:59:27 GMT

  The info documentation describes a switch -mno486 to turn off the 486-
specific optimisation. This didn't work for me, and digging thru the code
showed the switch is coded as "-mno-486".

--Jim Bray


Newsgroups: gnu.gcc.bug
From: urabe@ttc.rdc.ricoh.co.JP
Subject: ioctl does not work in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 02:32:33 GMT

	I encountered the problem using gcc 2.3.1 on SS2 SUNOS 4.1.2.
	I compiled the folowing program using gcc2.3.1 and cc and run
	under the Openwindow2.0's comannd tool. I expected
	the result is the same, but not.

% cat ttt.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sgtty.h>


#define EXIT_OK 0
#define EXIT_FAILURE 1


main()
{
    struct sgttyb arg;

    if (!isatty(fileno(stdin))) {
        fprintf(stderr, "stdin is not tty\n") ;
        exit(EXIT_FAILURE);
    }
    fprintf(stderr, "tty name is %s\n", ttyname(fileno(stdin))) ;
    if (ioctl(fileno(stdin), TIOCGETP, (char *)&arg) < 0) {
        perror("ioctl - TIOCGETP");
        exit(EXIT_FAILURE);
    }
    fprintf(stderr, "We can do ioctl\n") ;
    exit(EXIT_OK);
}

	The config.status of gcc is the following.

% cat config.status
#!/bin/sh
# GCC was configured as follows:
./configure --target=sparc-sun-sunos4.1 --prefix=/usr/gnu
echo host=sparc-sun-sunos4.1 target=sparc-sun-sunos4.1 build=sparc-sun-sunos4.1

	And the script of the result is the following.

% gcc -v -o ttt.gcc ttt.c
Reading specs from /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
gcc version 2.3.1
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix ttt.c /tmp/cca11931.i
GNU CPP version 2.3.1 (sparc)
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/cc1 /tmp/cca11931.i -quiet -dumpbase ttt.c -version -o /tmp/cca11931.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 as -o /tmp/cca119311.o /tmp/cca11931.s
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/ld -e start -dc -dp -o ttt.gcc /lib/crt0.o -L/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1 -L/usr/gnu/lib /tmp/cca119311.o -lgcc -lc -lgcc

% ttt.gcc
tty name is /dev/ttyp4
ioctl - TIOCGETP: Inappropriate ioctl for device

	And the result of the default SUN cc is the following.

% cc -v -o ttt.cc ttt.c
/lib/cpp -undef -Dunix -Dsun -Dsparc ttt.c >/tmp/cpp.11939.0.i
/lib/ccom - </tmp/cpp.11939.0.i >/tmp/ccom.11939.1.s
rm /tmp/cpp.11939.0.i
/bin/as -o ttt.o -Q /tmp/ccom.11939.1.s
rm /tmp/ccom.11939.1.s
/bin/ld -dc -dp -e start -X -o ttt.cc /usr/lib/crt0.o ttt.o -lc
rm ttt.o

% ttt.cc
tty name is /dev/ttyp4
We can do ioctl


	I hope this information is useful to you.


				701 Development Group
				NA Development Department
				Advanced Technology Development Center	
				Research and Development Group
				RICOH Co. Ltd.

					Akio Urabe

				urabe@ttc.rdc.ricoh.co.jp
				tel +81-45-593-3411 ext 3021    
				FAX 81-45-593-3487 (G3)

Newsgroups: gnu.gcc.bug
From: dbt@adm.csc.ncsu.edu (David B. Teague)
Subject: Apparent Optimization bug causes multiply-defined labels
Followup-To: bray@wcuvax1.wcu.edu
Organization: wcuvax1.wcu.edu (CS Dept., Western Carolina University)
Distribution: gnu
Date: Sat, 21 Nov 1992 00:27:15 GMT

[Please respond to bray@wcuvax1.wcu.edu]

While making libg++2.2, I came upon the following multiply-defined
label problem. Note that this does not occur without optimization, and
does occur with both -O and -O2. An examination of the .s files generated
with optimization shows labels, such as .L_b20 and .L_b26, to occur twice.
This does not occur in the .s files generated without optimization.

--Jim

gcc 2.3.1: i486-sysv4
libg++ 2.2

pwd
/usr/local/libg++

elentari$make
/bin/sh ./config.status
Created "Makefile" in / using "config/mh-sysv4"
[ stuff deleted ]
gcc -g -O2 -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c
Obstack.cc
Assembler: Obstack.cc
        aline 1878      : multiply defined label
        aline 2556      : multiply defined label
        aline 2859      : multiply defined label
        aline 3227      : multiply defined label
        aline 3614      : multiply defined label
        aline 3951      :  : multiply defined label
make[2]: *** [Obstack.o] Error 1
make[1]:*** [in-src] Error 1
make: *** [all-libg++] Error 1

gcc -g -O2 -S -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include
-c Obstack.cc


>From Obstack.s:
        .file   "Obstack.cc"
        .version        "01.01"
gcc2_compiled.:

[Stuff deleted]

        pushl %ebx
        movl 8(%ebp),%ebx
        movl 12(%ebp),%esi
.L_b20:
.L_LC36:

[Stuff deleted]

        .2byte  0xffff
        .4byte  .L_LC37-.L_text_b
        .previous
.L_b20: [[[Line 1878]]]
        xorb %al,%al
        movl %esi,%edi

[Stuff deleted]

        movl 8(%ebp),%ebx
        movb 12(%ebp),%dl
        movb %dl,-4(%ebp)
.L_b26:
.L_LC57:

.section        .line
        .4byte  158     / /Obstack.h:158

[stuff deleted]

        .2byte  0xffff
        .4byte  .L_LC58-.L_text_b
        .previous
.L_b26: [[[Line 2556]]]
.L_LC59:

.section        .line

Newsgroups: gnu.gcc.bug
From: randy@kcin.alphacdc.COM (Randy S. Welch)
Subject: Patch to config/plexus.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 06:45:00 GMT

A couple of fixes for plexus.h for gcc 2.3.1.

Fixes SIZE_TYPE  definition as needed by gcc-2.3.1
Defines size_t, since the plexus doesn't have size_t defined by default
Defines rindex/index to str* functions for sysV environments

-randy

*** config/plexus.h.org	Mon Nov  2 22:41:20 1992
--- config/plexus.h	Tue Nov 10 20:58:54 1992
***************
*** 87,90 ****
  #define NO_SYS_SIGLIST
  #define NO_DUP2
  
! #define SIZE_TYPE int
--- 87,97 ----
  #define NO_SYS_SIGLIST
  #define NO_DUP2
  
! #define SIZE_TYPE "int"
! /************************************************************************/
! /*               define items the plexus doesn't have...                */
! /************************************************************************/
! 
! #define size_t int
! #define rindex strrchr
! #define index strchr


Newsgroups: gnu.gcc.bug
From: stolcke@icsi.berkeley.edu (Andreas Stolcke)
Subject: -D/-U interaction bug ?
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Distribution: gnu
Date: Mon, 16 Nov 1992 23:32:52 GMT

I find that gcc 2.3.1 doesn't handle -DFOO -UFOO as it used to.
The -U option seems to be ignored in this case, whereas up to gcc 2.2.2
it would override the -D option.  This is the behavior that is 
documented and that other C compilers seem to prefer as well.
gcc -Upredefined_symbol seems to have stopped working as well.

Incidentally, this breaks the compile of the MIT R5 XsunMono server.

here is a clue from ChangeLog:

Fri Oct  2 20:03:53 1992  Richard Stallman  (rms@mole.gnu.ai.mit.edu)

        * cccp.c (main): Handle -U before -D (and -A).

What's the story?

-- 
Andreas Stolcke					stolcke@icsi.berkeley.edu
International Computer Science Institute	stolcke@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704	(510) 642-4274 ext. 126

Newsgroups: gnu.gcc.bug
From: enelson@apnext1.slac.stanford.edu (Eric M. Nelson)
Subject: Fatal signal 10 with ObjC.
Reply-To: enelson@apnext1.slac.stanford.edu (Eric M. Nelson)
Organization: Stanford Linear Accelerator Center
Distribution: gnu
Date: Fri, 20 Nov 1992 20:14:07 GMT

  The following simple program fails to compile with gcc 2.3.1 on a NeXT  
running NeXTstep 3.0. Note that <stdarg.h> is required by <objc/Object.h>,  
but <objc/Object.h> forgets to include it.

#include <stdarg.h>
#include <objc/Object.h>

int main(){
  id anObject;
  anObject=[Object new];
  }

The compilation yields,
rees> gcc -v -c -I ~/Sources/gnu/gcc-2.3.1 test.m
Reading specs from /usr/local/lib/gcc-lib/next/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/next/2.3.1/cpp -lang-objc -v -I  
/Net/apnext1/Users/enelson/Sources/gnu/gcc-2.3.1 -undef -D__OBJC__  
-D__GNUC__=2 -Dmc68000 -Dm68k -DNeXT -Dunix -D__MACH__  
-D__ARCHITECTURE__="m68k" -D__mc68000__ -D__m68k__ -D__NeXT__ -D__unix__  
-D__MACH__ -D__ARCHITECTURE__="m68k" -D__mc68000 -D__m68k -D__NeXT  
-D__unix -D__MACH__ -D__ARCHITECTURE__="m68k" test.m /usr/tmp/cc026776.i
GNU CPP version 2.3.1 (68k, MIT syntax)
 /usr/local/lib/gcc-lib/next/2.3.1/cc1obj /usr/tmp/cc026776.i -quiet  
-dumpbase test.m -version -lang-objc -o /usr/tmp/cc026776.s
GNU C version 2.3.1 (68k, MIT syntax) compiled by GNU C version 2.3.1.
gcc: Internal compiler error: program cc1obj got fatal signal 10

Has anyone had better luck with ObjC than this? If so, please let
me know. Thanks.
-Eric

Newsgroups: gnu.gcc.bug
From: Peter.Schauer@regent.e-technik.tu-muenchen.dbp.DE (Peter Schauer)
Subject: gcc-2.3.1 i386gas.h NO_UNDERSCORES problem + fix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 22 Nov 1992 12:08:03 GMT

(An apology if you receive this twice but I sent it to bug-gcc and never
saw it on the gnu.bug.gcc newsgroup)

There are two small bugs in i386gas.h that manifest themselves on systems
that have NO_UNDERSCORES. LPREFIX is not redefined to .L as necessary
and the * was dropped from ASM_GENERATE_INTERNAL_LABEL which causes problems
with the Ltext label output in dbxread.c.

Here are the diffs:

*** ./config/i386gas.h.orig	Fri Oct 30 02:15:41 1992
--- ./config/i386gas.h	Wed Nov 11 09:57:45 1992
***************
*** 139,144 ****
--- 139,148 ----
  			 then it must take more than `L' to identify
  			 a label that should be ignored.  */
  
+ /* Local labels are prefixed with ".L" */
+ #undef LPREFIX
+ #define LPREFIX ".L"
+ 
  /* This is how to store into the string BUF
     the symbol_ref name of an internal numbered label where
     PREFIX is the class of label and NUM is the number within the class.
***************
*** 146,152 ****
  
  #undef ASM_GENERATE_INTERNAL_LABEL
  #define ASM_GENERATE_INTERNAL_LABEL(BUF,PREFIX,NUMBER)	\
!     sprintf ((BUF), ".%s%d", (PREFIX), (NUMBER))
  
  /* This is how to output an internal numbered label where
     PREFIX is the class of label and NUM is the number within the class.  */
--- 150,156 ----
  
  #undef ASM_GENERATE_INTERNAL_LABEL
  #define ASM_GENERATE_INTERNAL_LABEL(BUF,PREFIX,NUMBER)	\
!     sprintf ((BUF), "*.%s%d", (PREFIX), (NUMBER))
  
  /* This is how to output an internal numbered label where
     PREFIX is the class of label and NUM is the number within the class.  */

--
Peter Schauer			pes@regent.e-technik.tu-muenchen.de


Newsgroups: gnu.gcc.bug
From: morgan@dl5000.bc.edu (Morgan Stair)
Subject: Bug with varargs.h and stdio.h
Organization: Institute for Space Research, Boston College
Distribution: gnu
Date: Mon, 16 Nov 1992 20:33:53 GMT

/*-
 * tester.c
 *
 * This program shows the following error when compiled by gcc-2.3.1 on
 * my Sun Sparc 1+ with SunOS 4.1.1
 *
 *

In file included from /software/gcc-2.3.1/lib/gcc-lib/sparc-sun-sunos4.1.1/2.3.1/include/stdarg.h:32, from /software/gcc-2.3.1/lib/gcc-lib/sparc-sun-sunos4.1.1/2.3.1/include/stdio.h:2, from tester.c:16:
/software/gcc-2.3.1/lib/gcc-lib/sparc-sun-sunos4.1.1/2.3.1/include/va-sparc.h:45: warning: useless keyword or type name in empty declaration

 *
 *
 * The error does not occurr when <stdio.h> is put before <varargs.h>
 *
 */

#include <varargs.h>
#include <stdio.h>

main()
{
}
--
***************************************
* Morgan Stair <Morgan@DL5000.BC.EDU> *
* BC / Institute for Space Research   *
* (617)552-8783                       *
***************************************

Newsgroups: gnu.gcc.bug
From: leisner@eso.mc.xerox.COM ( Marty Leisner)
Subject: gcc 2.2.2 on sparcs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 22:22:53 GMT

This is very strange.

I reported problems with the gcc -a option (I got it to link, but it can't open a profiling file...)

I took out  the -a option, recompiled and got:

napurna$ make
gcc -g  -v     -o 8086engine 8086engine.o  
Reading specs from /usr/gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/ld -e start -dc -dp -o 8086engine /lib/crt0.o -L/usr/lib/X11 -L/usr/openwin/lib -L/usr/marty/lib -L/usr/lib/X11 -L/usr/openwin/lib -L/usr/marty/lib -L/usr/gnu/lib/gcc-lib/sun4/2.2.2 -L/usr/gnu/lib 8086engine.o -lgcc -lc -lg -lgcc
ld: 8086engine.o: odd word displacement at text+0x44d8
collect: /usr/bin/ld returned 2 exit status
make: *** [8086engine] Error 1
leisner@annapurna$ xterm &

I've never seen this before.

nm says:
000043e0 t _mov_to_bytereg
00004478 t _mov_seg_to_ea
00004640 t _mov_ea_to_seg

I tried playing with options...with the optomizer turned on:
ld: 8086engine.o: odd word displacement at text+0x20ec
ld: 8086engine.o: odd word displacement at text+0x2098
(nm reports different functions)...

I'll give whoever wants the project...

marty




Newsgroups: gnu.gcc.bug
From: roberts@nsrl31.nsrl.rochester.edu (Roland B Roberts)
Subject: gcc 2.2, VMS stdio.h missing fpos_t typedef
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 22:17:50 GMT

The following is a patch for the VMS <stdio.h> which is missing the
typedef for fpos_t.

Ideally, shouldn't the header have ANSI prototypes as well?  If this is
desireable, I can work on it.

roland

% diff -c stdio.h;-1 stdio.h
*** stdio.h;-1
--- stdio.h
**************
*** 39,44
   *	passes around pointers to pointers.
   */
  typedef struct _iobuf *FILE;
  
  /*
   *	Also, stdin/stdout/stderr need to be defined
--- 39,45 -----
   *	passes around pointers to pointers.
   */
  typedef struct _iobuf *FILE;
+ typedef struct {unsigned : 32; unsigned : 32;} fpos_t;
  
  /*
   *	Also, stdin/stdout/stderr need to be defined

Newsgroups: gnu.gcc.bug
From: n3889@tamarack.cray.com (Benoit Dupont de Dinechin)
Subject: Internal compiler error (cc1plus got fatal signal 11)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 24 Nov 1992 01:04:29 GMT

willow41:~/workcray/development/c++:142 cat gcc_bug2.cc
#include <iostream.h>

template<class T>
class gen_ddcell {
    signed next_ : 32 ;
    signed prev_ : 32 ;
public:
    T item ;

    gen_ddcell(void) { ; }
    gen_ddcell(const T &item) {
        this->item = item ; }
} ;

template<class T>
ostream &operator<<(ostream &s, gen_ddcell<T> &c) {
    return s << c.item ; }

main() {
    gen_ddcell<char> cell = 'a' ;
    cerr << cell ;
}

willow41:~/workcray/development/c++:143 g++ -v -o bug2 gcc_bug2.cc
Reading specs from /usr/contrib/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/contrib/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/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 gcc_bug2.cc /usr/tmp/cca15093.i
GNU CPP version 2.2.2 (sparc)
 /usr/contrib/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca15093.i -quiet -dumpbase gcc_bug2.cc -version -o /usr/tmp/cca15093.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/usr/contrib/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

This example works if I replace:

template<class T>
ostream &operator<<(ostream &s, gen_ddcell<T> &c) {
    return s << c.item ; }

by:

ostream &operator<<(ostream &s, gen_ddcell<char> &c) {
    return s << c.item ; }

in the code listed above.

Benoit

Newsgroups: gnu.gcc.help
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Looking for a switch to turn off builtin decl warnings.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 22 Nov 1992 18:02:36 GMT

If you get frequent warnings about built-in functions in GCC 2.3,
chances are some bug is responsible.  The only way anyone can find out
is if you send a precise bug report.  So please do that.  Papering
over the problem with an option will avoid getting to the bottom of
things.

Newsgroups: gnu.gcc.help
From: efv@vilspa.dnet.nasa.GOV (DU)
Subject: Ansi C specifications
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 06:42:45 GMT

Hi...
Where could I find ANSI C specifications ??
Does exist a plubic site where I could find it ??
Sorry me if this is not the correct place to put this questions.

Please send answers to efv@vilspa.dnet.nasa.gov

Thanks in advance...

   Eduardo F. Vieira.
   ESA ( European Space Agency - VillaFranca Del Castillo
         Madrid - Spain )
From: edc@ENG.Vitalink.COM (Eric D. Christensen)
Newsgroups: gnu.gcc.help
Subject: Problems with 2.3.1 on Sun4 4.1.1
Keywords: .stabs & cross compilers
Date: 17 Nov 92 22:38:46 GMT
Organization: Vitalink Communications, Fremont, California

Two guestions for you Gnurus (ugh! sorry, I couldn't resist):

1) When attempting to build stage 1 for sparc in a subdirectory fo the
source directory I get the following error:

  warhol{edc}100: cd gcc-2.3.1
  warhol{edc}101: mkdir sparc
  warhol{edc}102: cd sparc
  warhol{edc}103: ls
  warhol{edc}104: ../configure --srcdir=.. sun4
  Linked `config.h' to `../config/xm-sparc.h'
  Linked `tm.h' to `../config/sparc.h'
  Linked `md' to `../config/sparc.md'
  Linked `aux-output.c' to `../config/sparc.c'
  Linked `tconfig.h' to `../config/xm-sparc.h'
  Linked `hconfig.h' to `../config/xm-sparc.h'
  Created `Makefile'.
  Links are now set up for target sparc-sun-sunos4.1.1.
  warhol{edc}105: make LANGUAGES=c
  
  [ lots of stuff deleted ]
  
  rm -f tmplibgcc2.a
  set -e; \
  for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _lshldi3 _ashldi3 _ashrdi3 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi __gcc_bcmp _varargs _eprintf _builtin_new _caps_New _builtin_del _bb _shtab _clear_cache _trampoline __main _exit _ctors; \
  do \
    echo ${name}; \
    ./xgcc -B./ -O2  -DIN_GCC   -g  -g1 -I. -I.. -I../config -c -DL${name} \
        ../libgcc2.c -o ${name}.o; \
    if [ $? -eq 0 ] ; then true; else exit 1; fi; \
    ar rc tmplibgcc2.a ${name}.o; \
    rm -f ${name}.o; \
  done
  _muldi3
  /usr/tmp/cca05063.s:2: Unknown pseudo-op:  `.stabs'
  make: *** [libgcc2.a] Error 1

Whoops! Anyone have any idea where I may be going wrong here? I can't
seem to figure it out.


2) Once I get the sparc version built and tested, I will be using it
to build cross compilers for a29k and mc68K. The problem is that I
need to call versions of gas for 29k and 68k respectively. My
intention is to call the cross compilers gcc29k and gcc68k, and the
assemblers gas29k and gas68k. Is this the "right" way to do it? And
wher should I make the configuration changes to get them to call the
appropriate assembler? Or is there a better way of setting this up?

Thanks in advance!!!!

Cheers-

-- 
+---------------------------------------------------------------------------+
|   Eric D. Christensen - System Administrator - Vitalink Communications    |
|        Email: edc@ENG.Vitalink.COM           Phone: (510)440-2209         |
|                 SCCA San Francisco Region - Formula 440 #8                |
+---------------------------------------------------------------------------+
|     Racing is like sex: You spend far too much time and money on the      |
|    preliminaries, when you finally get to do it it doesn't last long      |
| enough, and once it's over you want to do it again, but you have to wait. |
+---------------------------------------------------------------------------+
Newsgroups: gnu.gcc.help