HDTenEightyP/NetNews huggingface dataset:
From: leif@ifm.liu.se (Leif Hedstrom)
Subject: Problems compiling Xaw3d with gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 13:54:07 GMT

Hi,

gcc2.3.1 dumps core when trying to compile the latest version (0.4) of
the Xaw3d library. I don't read the gcc-bug news group, so I don't know if
this is a known bug. Below is a trace from gdb, if that is any help.

-- Leif

ifm 101% gdb -c core /usr/gnu/debug/gcc-lib/sparc-sun-sunos4.1/2.3.1/cc1
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...
Core was generated by `cc1'.
Program terminated with signal 6, Abort.
#0  0xf775c120 in kill ()
(gdb) bt
#0  0xf775c120 in kill ()
#1  0xf777449c in abort ()
#2  0x9bbf8 in decode_rtx_const (mode=SImode, x=0x1cbe28, value=0xf7ffecc8)
    at varasm.c:2193
#3  0x9bcc0 in simplify_subtraction (x=0x1cd358) at varasm.c:2218
#4  0x16c31c in output_addr_const (file=0x1bcc98, x=0x1cd358) at final.c:2312
#5  0x16bd98 in output_address (x=0x1cd380) at final.c:2202
#6  0x16b158 in output_asm_insn (template=0x180b30 "sethi %%hi(%a1),%0", 
    operands=0x1be7f0) at final.c:2076
#7  0x16a838 in final_scan_insn (insn=0x1cd3a0, file=0x1bcc98, optimize=4, 
    prescan=0, nopeepholes=0) at final.c:1697
#8  0x169488 in final (first=0x1cea50, file=0x1bcc98, optimize=4, prescan=0)
    at final.c:922
#9  0x3bed0 in rest_of_compilation (decl=0x31ae10) at toplev.c:2671
#10 0x20ea0 in finish_function (nested=0) at c-decl.c:6073
#11 0x8968 in yyparse () at c-parse.y:269
#12 0x39684 in compile_file (name=0xf7fffa1c "/usr/tmp/cca25117.i")
    at toplev.c:1804
#13 0x3d978 in main (argc=9, argv=0xf7fff944, envp=0xf7fff96c) at toplev.c:3283
(gdb) 

Newsgroups: gnu.gcc.bug
From: christos@deshaw.com (Christos Zoulas)
Subject: Argument passing bug in gcc-2.3.1 (sparc)
Keywords: sparc, arguments, double
Organization: D. E. Shaw & Co.
Distribution: gnu
Date: Tue, 24 Nov 1992 01:25:54 GMT

Hello,

The following program works correctly with sun's cc, but produces incorrect
results with gcc.

% cc bug.c
% a.out
 0 0 1.2 1.2 1 0

% gcc -v bug.c
Reading specs from /usr/local/lib/gcc-lib/sparc/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc/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 bug.c /usr/tmp/cca03859.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc/2.3.1/cc1 /usr/tmp/cca03859.i -quiet -dumpbase bug.c -version -o /usr/tmp/cca03859.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 as -o /usr/tmp/cca038591.o /usr/tmp/cca03859.s
 /usr/local/lib/gcc-lib/sparc/2.3.1/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc/2.3.1 -L/usr/local/lib /usr/tmp/cca038591.o -lgcc -lc -lgcc
% a.out
 0 0 4.24399e-315 1.2 1 0

% cat bug.c
#include <stdio.h>


struct x {
   struct {
	double b;
	double a;
   } q;
   struct {
	double m;
   } p;
   double nl;
   double lo;
   double in;
};


double f1(ip, d1, d2, d3)
   struct x *ip;
   double d1, d2, d3;
{
   return (d1 + 1.0) * d2 + d3 + 1.2;
}


double f2(d1, d2)
   double d1, d2;
{
   return d1 * d2 + 1.0;
}

struct x g;

main()
{
  struct x *ip = &g;

  (void)fprintf(stderr, " %g %g %g %g %g %.10g\n",
                ip->q.b, ip->q.a,
                f1(ip, 0.0, ip->p.m, 0.0),
                f1(ip, ip->p.m, 0.0, 0.0),
                f2(ip->nl, ip->lo),
                ip->in);
  exit(0);
}


Newsgroups: gnu.gcc.bug
From: steve%eowyn@gte.com (Steve Preston)
Subject: dtor call without ctor call on temp instance.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 09:31:18 GMT

I tried mailing to bug-g++@prep.ai.mit.edu, but it bounced.

For gcc (g++) versions 2.2.2 and 2.3.1, on hppa1.1-hp-hpux and on
decstation-ultrix.  

When a class has (1) an operator= method, (2) a constructor and 
(3) destructor, calling the operator= method causes a destructor call
on a temporary instance without a corresponding constructor call.

For example:

/* #include "String.h" */

/* String.h */
const int max_string_length = 128; 
 
class String { 
 public: 
  String();
  ~String();
  
  String operator=(const String &);
  int length() const; 
  int read (); 
  void print() const; 
  
 private: 
  char text[max_string_length+1]; 
}; 

main(int, char *[])
{
  String s1, s2;
  
  s2 = s1;
  
  s1.print();
  s2.print();
  
  return 0;
}

After the assignment, the destructor is called on a temporary instance
of String, without a corresponding constructor call.

I believe this is a bug.
--
Steve Preston (spreston@gte.com)

Newsgroups: gnu.gcc.bug
From: rpb@psy.ox.ac.UK (Ray Bellis)
Subject: Bug in 2.3.1 objc/Makefile
Organization: Dept. of Experimental Psychology, Oxford, England.
Distribution: gnu
Date: Fri, 20 Nov 1992 18:47:16 GMT

There is a bug in the file objc/Makefile when using a separate
object/executable directory.  There are dependencies which point
back to ../assert.h and ../gstdarg.h.  These should be written
$(srcdir)/assert.h and $(srcdir)/gstdarg.h since the relative
path isn't correct in this case.

Ray.
--
------------------------------------------------------------------------------
R. P. Bellis				E-Mail:	<rpb@psy.ox.ac.uk>
Dept. of Experimental Psychology	Whois:	(RB83)
University of Oxford			Tel:	+44 865 271419
South Parks Road			Fax:	+44 865 310447
Oxford OX1 3UD
------------------------------------------------------------------------------
From: michael@mercury.cs.mun.ca (Mike Rendell)
Newsgroups: gnu.gcc.bug
Subject: More config file fixes for Mips Risc/os 5.0
Date: 16 Nov 92 12:21:11 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Environment: Mips M/120 running Risc/os 5.0, gcc 2.3.1

The mips-5{bsd43,sysv,svr4}.h config files define SYSTEM_INCLUDE_DIR
when they should be defining STANDARD_INCLUDE_DIR.  The difference
is that in the former case, the default STANDARD_INCLUDE_DIR,
"/usr/include",  will also be searched.  This causes problems in the
bsd environment, where files like termio.h should not be found but
are.

The following diffs change config/mips-5bsd.h, config/mips-5sysv.h
and config/mips-5svr4.h.  Similar changes should probably be made
to config/mips-{bsd,sysv,svr4}.h, but I don't have access to systems
running Risc/os 4.x, so I don't know for sure.


--- config/mips-5bsd.h.orig	Thu Nov 12 12:04:04 1992
+++ config/mips-5bsd.h	Thu Nov 12 12:04:24 1992
@@ -21,7 +21,7 @@
 
 #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_BSD43"
 
-#define SYSTEM_INCLUDE_DIR "/bsd43/usr/include"
+#define STANDARD_INCLUDE_DIR "/bsd43/usr/include"
 
 #define CPP_SPEC "\
 %{.cc:	-D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS} \
--- config/mips-5svr4.h.orig	Thu Nov 12 12:04:04 1992
+++ config/mips-5svr4.h	Thu Nov 12 12:04:27 1992
@@ -21,7 +21,7 @@
 
 #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SVR4"
 
-#define SYSTEM_INCLUDE_DIR "/svr4/usr/include"
+#define STANDARD_INCLUDE_DIR "/svr4/usr/include"
 
 #define CPP_SPEC "\
 %{.cc:	-D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS} \
--- config/mips-5sysv.h.orig	Thu Nov 12 12:04:04 1992
+++ config/mips-5sysv.h	Thu Nov 12 12:04:30 1992
@@ -21,7 +21,7 @@
 
 #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SYSV"
 
-#define SYSTEM_INCLUDE_DIR "/sysv/usr/include"
+#define STANDARD_INCLUDE_DIR "/sysv/usr/include"
 
 #define CPP_SPEC "\
 %{.cc:	-D__LANGUAGE_C_PLUS_PLUS -D_LANGUAGE_C_PLUS_PLUS} \

--
Michael Rendell - Dept. of Comp. Sci., Memorial University of Newfoundland
Newsgroups: gnu.gcc.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: GCC 2.3.1: bug in combine pass
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 11:54:11 GMT

GCC 2.3.1 (m68k, Atari TT) generates wrong code for this file:

---------- test.c
typedef struct
{
  unsigned short b0, b1, b2, b3;
} four_quarters;

four_quarters x;
int a, b;

void f (four_quarters j)
{
  b = j.b2;
  a = j.b3;
}
----------

Compiled with: gcc -O -S test.c

---------- test.s
#NO_APP
gcc2_compiled.:
.text
	.even
.globl _f
_f:
	link a6,#0
	movel d2,sp@-
	movel a6@(8),d1
	movel a6@(12),d2
	movel d2,d0
	clrw d0
	swap d0
	movel d0,_b
	clrw _a
	movew d1,_a+2		| <--- should be d2
	movel a6@(-4),d2
	unlk a6
	rts
.comm _x,8
.comm _a,4
.comm _b,4
----------

I suppose that the bug is in combine.c (make_extraction), near line 4630:

----------
      else if (GET_CODE (inner) == REG)
	/* We can't call gen_lowpart_for_combine here since we always want
	   a SUBREG and it would sometimes return a new hard register.  */
	new = gen_rtx (SUBREG, tmode, inner,
		       (WORDS_BIG_ENDIAN
			&& GET_MODE_SIZE (is_mode) > UNITS_PER_WORD
			? ((GET_MODE_SIZE (is_mode) - GET_MODE_SIZE (tmode))
			   / UNITS_PER_WORD)
			: 0));
----------

If `is_mode' is changed to `inner_mode' (in both places), the bug disappears.
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.gcc.bug
From: sethg@cs.berkeley.edu (Seth C. Goldstein)
Subject: gcc 2.3.1 bug with function templates (multiple definitions)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 08:21:08 GMT

Machine:	sparc
Version:	gcc version 2.3.1
OS:		SunOS Release 4.1.2
problem:	If more than one  use of a function, which is defined
		with a template, occurs in a file, the assembler claims
		that the function is defined more than once.

sample code:
/////////////////////////////////////////////////////////// start
int *packAddress(void);
void packDone(int);
#define intsIn(T)	((sizeof(T)+(sizeof(T)-1))/sizeof(int))

int i;
double d;
int j;

template<class T>
void
pack(T& data)
{
	T *p = (T *)packAddress();

	*p = data;
	packDone(intsIn(T));
}

foo()
{
	pack(i);
	pack(d);
	pack(j);
}
/////////////////////////////////////////////////////////// end
sample compilation:
/////////////////////////////////////////////////////////// start
gcc-2.3.1 -v -o foo foo.C
Reading specs from /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
gcc version 2.3.1
 /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.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 foo.C /usr/tmp/cca21700.i
GNU CPP version 2.3.1 (sparc)
 /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/cc1plus /usr/tmp/cca21700.i -quiet -dumpbase foo.cc -version -o /usr/tmp/cca21700.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
foo.C: In function `int  foo ()':
foo.C:24: warning: control reaches end of non-void function
 as -o /usr/tmp/cca217001.o /usr/tmp/cca21700.s
as: "/usr/tmp/cca21700.s", line 57: error: redefinition of symbol "_pack"
gcc-2.3.1: /usr/tmp/cca217001.o: No such file or directory
/////////////////////////////////////////////////////////// end

-seth

p.s. Am I sending these reports to the correct place?


Newsgroups: gnu.gcc.bug
From: singhal@cs.utexas.edu (Vivek Singhal)
Subject: GCC 2.3.1 on Sparc -- conflicting types
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 04:04:04 GMT

Here's a bug I ran across when compiling glibc-1.05 on a Sparc running
SunOS 4.1.2 (using GCC 2.3.1).  GCC reports an extraneous error
(conflicting types for `puts'); note that this error disappears when
the declaration for `strlen' is removed.

This error does not occur on other architectures that I've tried
(DecStation 5000/20 running Ultrix 4.2a, HP 9000/300 running HP/UX
7.0, Sun 3/50 running SunOS 4.1.2).

Vivek

----------------------------------------------------------------
Vivek Singhal      singhal@cs.utexas.edu  Office: (512) 471-9711
Univ of TX @ Austin, CS Dept, TAY 3.104C    Home: (512) 385-1855

% cat puts-bug.c 
typedef unsigned long int size_t;
typedef struct stdio_file FILE;
extern FILE *stdout;
extern int putchar (int c);
extern int fputs (const char *s, FILE * stream);
extern int puts (const char *s);
extern size_t strlen (const char *s);

int
puts (const char *s)
{
  return (fputs (s, stdout) || putchar ('\n') == (-1) ? (-1) : 0);
}
% gcc -v -c puts-bug.c
Reading specs from /p/lib/gcc-lib/sun4/2.3.1/specs
gcc version 2.3.1
 /p/lib/gcc-lib/sun4/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 puts-bug.c /usr/tmp/cca23212.i
GNU CPP version 2.3.1 (sparc)
 /p/lib/gcc-lib/sun4/2.3.1/cc1 /usr/tmp/cca23212.i -quiet -dumpbase puts-bug.c -version -o /usr/tmp/cca23212.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
puts-bug.c:11: conflicting types for `puts'
puts-bug.c:6: previous declaration of `puts'

Newsgroups: gnu.gcc.bug
From: dpotlur@hubcap.clemson.edu (Potluri Dora)
Subject: Assembly code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 05:01:46 GMT

Hi!
	We have a question regarding generation of assembly code.
Our problem is we are writing a compiler as part of our class work( a
very miniature version). We are at Code generation phase and we decided
to target the vax  machines. In  this regard we were looking at 
the assembly code generated for a simple c-program. We were wondering if
we can in anyway generate assembly code with the corresponding c-code
interspersed between them. For example:
# a = a + b
	.
	.
	assembly code for the statement a = a+b
	.
	.
	
	I hope my question is clear. We went through the man page
looking if we needed to set/unset any flags in order to do so..
Unfortunately, we were not successful...
	We would really appreciate your help. By the way, the assembly
code is generated in this manner on DEC workstation (MIPS architecture)
when we compile using cc (ansi option).
	Thanks for your help,
	Dora Potluri


		



Newsgroups: gnu.gcc.bug
From: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Subject: GCC 2.3.1 config/ns32k.h strangeness
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 15:40:12 GMT

The following definitions of TARGET_32332 and TARGET_32532 in the file
config/ns32k.h seem to be confused:

    /* Options to select type of CPU, for better optimization.
       The output is correct for any kind of 32000 regardless of these options.  */
    #define TARGET_32532 (target_flags & 8)
    #define TARGET_32332 (target_flags & 16)

	...

    #define TARGET_SWITCHES  \
	    ...
	{ "32532", 24},				\
	{ "32332", -16},			\
	{ "32332", 8},				\
	{ "32032", -24},			\
	    ...

The code makes me believe that the define TARGET_32332 is intended to
be true for 32332 and 32532 machines, and TARGET_32532 only for 32532
machines.  This would mean that the macro TARGET_32332 ought to have
the current definition of TARGET_32532, and vice versa.

Unless I have misunderstood this code completely...

Newsgroups: gnu.gcc.bug
From: stan@rti.COM (Stan Schneider)
Subject: -I option differences
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 23:50:49 GMT

Hi Gnu Gurus,


There appears to have been a suble change in gcc's include file behavior.  The
compile options:

	-Idira -Idirb

    with file structure:

	dira:
	   foo.h
	dirb:
	   foo.h fooinclude.h

Yields different results under 2.x that differ from 1.37x.  In particular, if
fooinclude.h contains `#include "foo.h"', and your source includes
"fooinclude.h", then under 1.37x, you would get dira/foo.h (in the order of the
options), under 2.x you get dirb/foo.h (the "current" directory has
precedence).

Was this intended?  Adding the options "-I- -I." doesn't really fix the
"problem"; that fails when you compile source from a subdirectory.

Thanks for your time,

        -- Stan


===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================


Newsgroups: gnu.gcc.bug
From: rrh@tera.com (Robert R. Henry)
Subject: sparc va_arg botches some structure passing
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 20:06:47 GMT

The following program contains a varargs routine,
which is given a 32 bit structure by value in one
of the varargs slots.

It is compiled by BOTH gcc2.3.1 and gcc2.2.2, host=sparc, target=sparc.

When the resulting code is executed it bus errors at the line marked ``HERE''.
Examining the faulting instruction shows that it is executing
	ld [%o1], %o0
with o1 containing 113.  The value 113 is what the va_arg
should ultimately deliver; there's one too many indirections going on.

This situation happens even if the structure actual parameter
is the first actual parameter after the 'op' parameter (so
its unlikely to be a register window alignment problem, altho
one never knows).

#include <stdio.h>
#include <stdarg.h>

typedef int TERA_Boolean;

typedef enum _FullEmptyControl{
	FE_NORMAL = 0	 
	,FE_FUTURE = 2	 
	,FE_SYNC = 3	 
} FullEmptyControl;

typedef struct _OperationAccessControl{
	int    :27  ;	 
	TERA_Boolean fwd_disable   :1  ;	 
	FullEmptyControl fe_control   :2  ;	 
	TERA_Boolean trap1_disable   :1  ;	 
	TERA_Boolean trap0_disable   :1  ;	 
} OperationAccessControl;  

typedef long long int int64;

void encode(int64 *r_result, int op, ...)
{
  static int v[] = {
    0,
    1, 1, 2,
    3, 2, -1
  };
  int64 result;
  int shift_amt = 64;
  int iarg;
  int shift = 0;
  int pass_op;
  unsigned int uarg;
  int type;
  int optype;
  int save_low_offset;
  va_list ap;
  va_start(ap,  op);

  for (iarg = 0; v[iarg] >= 0; iarg++){
    switch(v[iarg]){
    case 0:	/* begin */
      printf("begin\n");
      break;
    case 1:	/* reg */
      uarg = va_arg(ap, unsigned int);
      printf("reg %d\n", uarg);
      break;
    case 2:	/* lit */
      printf("lit\n");
      break;
    case 3:	/* UnsOpAC */
      {
	union {
	  OperationAccessControl ac;
	  int prt;
	} ac_ctrl;
	OperationAccessControl acl;
/* BUS ERROR HERE */
	acl = va_arg(ap, OperationAccessControl);
	printf("oac %d\n", ac_ctrl.prt);
	break;
      }
    default:
      break;
    }
  }
}

main()
{
  int64 x;
  encode(&x, 0, 17, 18, 113, 117);
}

Newsgroups: gnu.gcc.bug
From: p92084sm@post.isci.kyutech.ac.jp (Murata Schuuitschirou)
Subject: gcc 2.3.1 ... cc1obj got fatal signal 11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 22 Nov 1992 03:31:32 GMT

  On a Sparc Station 2 running SunOS 4.1.1, the followling program 
fails to complile with gcc 2.3.1.

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

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

$ gcc -I ~/include -v -c test.m
Reading specs from /edu/lib/gcc-2.3.1/lib/gcc-lib/sun4-sunos4.1/2.3.1/specs
gcc version 2.3.1
 /edu/lib/gcc-2.3.1/lib/gcc-lib/sun4-sunos4.1/2.3.1/cpp 
-lang-objc -v -I /home/p92084sm/include 
-undef -D__OBJC__ -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__
-D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.m /usr/tmp/cca11705.i
GNU CPP version 2.3.1 (sparc)
 /edu/lib/gcc-2.3.1/lib/gcc-lib/sun4-sunos4.1/2.3.1/cc1obj 
/usr/tmp/cca11705.i -quiet -dumpbase test.m -version -lang-objc 
-o /usr/tmp/cca11705.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
gcc: Internal compiler error: program cc1obj got fatal signal 11


Murata Schuuitchirou (but the former is family name)
E-Mail: p92084sm@post.isci.kyutech.ac.jp

Newsgroups: gnu.gcc.bug
From: kilitzir@ics.forth.GR (Xristos Kilitzirakis)
Subject: gcc warnings/errors
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10
	      tel: +30(81)221171, 229368,02 fax: +30(81)229342,3 tlx: 262389 CCI
Distribution: gnu
Date: Fri, 20 Nov 1992 18:37:31 GMT

Sirs,
where can I get the long description of the compiler's 
errors/warnings.<Info gcc > is istalled in our system.
We are currently using v2.3.1


XXXristos K.

Newsgroups: gnu.gcc.bug
From: matt@stdavids.picker.COM (Matthew Donham)
Subject: Product Plan Question
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 21:25:45 GMT

HI,

	We are considering using a DEC Alpha workstation in a product plan, and
are investigating the availability of tools. Could you please tell me about 
your plans for support of Alpha, for gcc, gdb, etc?

Thanks,

Matthew Donham, Picker Intl.

matt@stdavids.picker.com

Newsgroups: gnu.gcc.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: GCC-2.3.1 doesn't compile under NeXTstep 3.0
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sun, 15 Nov 1992 19:13:57 GMT

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.


Newsgroups: gnu.gcc.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: bug in config/t-next
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 14:43:46 GMT

I'm using GCC version 2.3.1 on a Next computer.

The file config/t-next sets OTHER_FIXINCLUDES_DIRS like this:

	OTHER_FIXINCLUDES_DIRS= /NextDeveloper/Headers \
	  /NextDeveloper/Headers/ansi /NextDeveloper/Headers/bsd \
	  /LocalDeveloper/Headers /LocalDeveloper/Headers/ansi \
	  /LocalDeveloper/Headers/bsd

This variable is used in the GCC Makefile like this:

	for dir in /usr/include $(OTHER_FIXINCLUDES_DIRS); do ...

Since /usr/include is a symbolic link to /NextDeveloper/Headers on Next
computers running release 3.0 of NextStep, the "for" loop in the Makefile
processes the same directories several times.  Since the makefile processes
any directory listed and all of its subdirectories with fixincludes, there's
no reason to set OTHER_FIXINCLUDES_DIRS to contain both directories and their
children.  In addition, the standard 3.0 distribution from Next does not even
contain /LocalDeveloper/Headers/ansi and /LocalDeveloper/Headers/bsd, so I
have no idea why they're in the list of files above.

The config/t-next file should instead contain this line:

	OTHER_FIXINCLUDES_DIRS= /LocalDeveloper/Headers


Newsgroups: gnu.gcc.bug
From: schulze@asgard.lpl.arizona.edu (Dean Schulze)
Subject: header files for g++ v2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 21:37:13 GMT

Hello FSF,

    Our systems programmer recently installed g++ v2.2.2, but when I tried to
use it there was a problem with the header files.  g++ looks in the directory

    /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/include/

for the .h files, but these files all have the arguments commented out in
the function prototypes (K&R prototypes), and g++ complains about an incorrect
number of arguments for these function calls.

    Did we err when building up the libraries or installing v2.2.2 somehow, or
are the proper header files to be found in some other directory?  The directory

    /usr/local/lib/g++-include

is empty.

    Dean Schulze



Newsgroups: gnu.gcc.bug