HDTenEightyP/NetNews huggingface dataset:
From: scowen@wfpc3.la.asu.edu (Paul A. Scowen)
Subject: Problems - R5 build on DS 5000/25 using gcc-2.2.2 - gnu.gcc.help #2055
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 01:40:38 GMT

As requested by people on the net I'm forwarding my post to the buglist...

In article <1992Aug19.152652.11529@ennews.eas.asu.edu>, scowen@wfpc3.NoSubdomain.NoDomain (Paul A. Scowen) writes:
|> Hello,
|> 
|> I'm writing to request any words of wisdom from people who've attempted to
|> build the pl16 R5 distribution on Unix platforms using gcc-2.2.2.
|> 
|> I have attempted to do this using the compiler built on a DS 5000/25, and
|> on the whole it has been successful.  By the way, if the MIT people are reading
|> there a needed change to the ultrix.cf file - a line that undefines the 
|> PexCCOptions if Gcc is defined - otherwise a whole chunk of PEX stuff does
|> not get built.
|> 
|> Anyway, the build goes ok until the mfb part of the server/ddx tree is reached
|> when a whole series of errors like this happen:
|> 
|> as0: Error: mfbfillsp.c, line 771: undefined assembler operation: extzv
|> 	extzv $2,$8,0($9),$5
|> 
|> now while this may be a gcc error, it also has implications for the R5 
|> build as a whole since gcc is the recommended compiler, from the README's
|> I've read.  The result of these errors (not surprisingly) is a failure to
|> build the ./server/ddx/mfb part of the server code, which causes a premature
|> exit from the make as follows:
|> 
|> making all in ./server/.././fonts/lib/font...
|> making all in ./fonts/lib/font/bitmap...
|> making all in ./fonts/lib/font/fontfile...
|> making all in ./fonts/lib/font/fc...
|> making all in ./fonts/lib/font/Speedo...
|> making all in ./fonts/lib/font/util...
|> making all in ./server/.././extensions/server...
|> making all in ./extensions/server/PEX...
|> making all in ./extensions/server/PEX/dipex/dispatch...
|> making all in ./extensions/server/PEX/dipex/swap...
|> making all in ./extensions/server/PEX/dipex/objects...
|> making all in ./extensions/server/PEX/ddpex/mi/level1...
|> making all in ./extensions/server/PEX/ddpex/mi/level2...
|> making all in ./extensions/server/PEX/ddpex/mi/level3...
|> making all in ./extensions/server/PEX/ddpex/mi/level4...
|> making all in ./extensions/server/PEX/ddpex/mi/shared...
|> making all in ./extensions/server/PEX/ospex...
|> Make:  Don't know how to make ddx/mfb/libmfb.a.  Stop.
|> *** Error code 1
|> `all' not remade because of errors
|> 
|> Any words of sage advice out there?  Thanks.

-- 
-------------------------------------------------------------------------------
Paul A. Scowen				INTERNET: scowen@wfpc3.la.asu.edu
Department of Physics & Astronomy		  uk1@spacsun.rice.edu
Arizona State University		Tel:      (602) 965-0938
Tempe, AZ 85287-1504			FAX:      (602) 965-7954
-------------------------------------------------------------------------------

Newsgroups: gnu.gcc.bug
From: ret@dcs.ed.ac.UK (Rik)
Subject: Yet another one
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 20:09:32 GMT

>From Reference manual r.13.4.7  Increment & decrement :

class X {
   public: X operator++() { a=2 ; return *this ;} 
           X operator++(int) { a=5 ; return *this ;}
           int a ;
};

main () {
   X var ;
   ++var ;
   printf("%d\n",var.a) ;
   var++ ;
   printf("%d\n",var.a) ;
}

Prints 2 twice. Replace the postincrement call var++ with var.operator++(0)
and it works.

> Richard Eyre-Todd.  Department of Computer Science, University of Edinburgh.

> Email: ret@uk.ac.ed.dcs                     | Solid fuel is for camp-fires,
> or     ret%dcs.ed.ac.uk@nsfnet-relay.ac.uk  | not boosting Space Shuttles. :-)

Newsgroups: gnu.gcc.bug
From: mtn@cs.duke.edu (Michael T. Naseef)
Subject: g++ V2.2.2: conditional operator cannot handle const char * operand
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 10:48:21 GMT

SOFTWARE:  g++ (gcc) version 2.2.2

BUG REPORT:  conditional operator ?: cannot handle const char * operand.

I discovered the following bug while recompiling groff using g++
version 2.2.2.

PROBLEM: compiling the following code produces the error
	try.cc: In function `int  main ()':
	try.cc:5: assignment between incompatible pointer types

EXAMPLE CODE:
main()
{
    const char *p = "abcd";
    const char *c;
    c = ((p == 0) ? "1234" : p);
}


Note: changing the declaration of p to char * will allow g++ to compile the
code without error.  No casting of any members has any affect on the problem.

Mike Naseef
--
Mike Naseef
Department of Computer Science, Duke University, Durham, NC 27706
Internet:	mtn@cs.duke.edu	|  Phone:	919/660-6577
UUCP:		mcnc!duke!mtn	|

Newsgroups: gnu.gcc.bug
From: quanstro@stolaf.edu (goon)
Subject: more gcc cpp wierdness
Organization: St. Olaf College, Northfield, MN USA
Distribution: gnu
Date: Mon, 17 Aug 1992 00:42:29 GMT

Gcc 2.1 cpp reports "unterminated #if conditional" when are no
preproessor conditionals. The line number is bogus too.

gcc -pg -ggdb -Wall -Wshadow -Wwrite-strings -c y.tab.c
parse.y:724: unterminated `#if' conditional
parse.y:349: unterminated macro call
parse.y:864: macro `mknod' used with too many (4) args
*** Error code 1
make: Fatal error: Command failed for target `y.tab.o'
; wc -l parse.y
     490 parse.y
; gcc -v
Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4.1.1/2.1/specs
gcc version 2.1

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: gcc code dumpes core, other compilers do not
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 13:07:32 GMT

This is probably a GCC bug.  But the GCC maintainers don't have time
to figure out how your program is supposed to work; we can only take
action if you verify positively that a particular line does not
execute as it should.

In particular, we need to know WHICH line doesn't execute as it
should.  There is no reason to assume that the problem is in the line
where the crash happens.  We need you to figure out which line
the fault is in.

If you determine this information, you can send a bug report
that enables us to fix the problem.


Newsgroups: gnu.gcc.bug
From: samborn@lynchpin.mtkgc.COM (Kevin Samborn)
Subject: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 17:41:02 GMT

I am trying to use g++2.1 on SunOS 4.1.1 Rev B.  

Whenever I include standard include files, (in this case coming from
/usr/lang/SC1.0/CC/include), I get the errors similar to the following:

In file included from /usr/lang/SC1.0/include/CC/malloc.h:9,
                 from /usr/lang/SC1.0/include/CC/stdlib.h:21,
                 from Main.C:1:
/usr/lang/SC1.0/include/CC/alloca.h:10:
        declaration of `char * __builtin_alloca (int)'
<built-in>:0: conflicts with built-in
        declaration `void * __builtin_alloca (int)'
In file included from /usr/openwin3/include/X11/Xos.h:69,
                 from /usr/openwin3/include/X11/Intrinsic.h:37,
                 from Main.C:2:
/usr/lang/SC1.0/include/CC/strings.h:22:
        declaration of `unsigned int  strlen (const char *)'
<built-in>:0: conflicts with built-in
        declaration `int  strlen (const char *)'


This happens even when I pass the -fno-builtin option to g++.

Is there anyway to turn off type checking for builtin functions?

thanks,
kevin samborn
--
kevin samborn
Sakura Global Capital
samborn@mtkgc.com

Newsgroups: gnu.gcc.bug
From: munson@acacia.cs.berkeley.edu (Ethan V. Munson)
Subject: g++-2.2.2 profiling problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 16:56:50 GMT

Compiler: g++-2.2.2 (using LibG++ 2.1)
Machine: SparcStation 2 running SunOS 4.1.2

Problem: Can't link when profiling

Description:

When performing the final link step on our large program we get
complaints from /usr/bin/ld that it can't find a number of symbols.
These symbols all match the regular expression:

	LB[BE][1-9][0-9]

For example, LBB29 and LBE29.  These symbols always come in pairs like
this.

They look like compiler-generated symbols to me and do not appear in
any of our own code.

Our final link command is:

/usr/sww/bin/g++-2.2.2   -g -DTRACE -DDEBUG -pg -static  -Wimplicit -Wreturn-type -Wswitch    -o LDObj.sun4/ensemble main/LDObj.sun4/test5.o view/LDObj.sun4/libview.a exl/glue/LDObj.sun4/libglue.a exl/types/LDObj.sun4/libxtypes.a exl/misc/LDObj.sun4/libxmisc.a  doc/LDObj.sun4/libdoc.a  io/LDObj.sun4/libio.a  texted/LDObj.sun4/libtexted.a  supered/LDObj.sun4/libsupered.a  dispatch/LDObj.sun4/libdispatch.a  view/LDObj.sun4/libview.a  pres/LDObj.sun4/libpres.a  realize/LDObj.sun4/librealize.a  struct/LDObj.su
n4/libstruct.a  textbuf/LDObj.sun4/libtextbuf.a  textform/LDObj.sun4/libtextform.a  textrender/LDObj.sun4/libtextrender.a  location/LDObj.sun4/liblocation.a  repman/LDObj.sun4/librepman.a  ecp/LDObj.sun4/libecp.a  uspec/LDObj.sun4/libuspec.a  vtree/LDObj.sun4/libvtree.a  font/LDObj.sun4/libfont.a  common/LDObj.sun4/libcommon.a doc/LDObj.sun4/libdoc.a ecp/LDObj.sun4/libecp.a -lgsR4 -L.  -L/home/auspex/d/ensemble/lib -L/usr/sww/X11R4/lib -L/usr/sww/lib -lg++-2_1 -lm -lXm -lXt!
 -lX11


Ethan Munson
munson@cs.berkeley.edu

Newsgroups: gnu.gcc.bug
From: mike@skinner.cs.uoregon.edu (Michael John Haertel)
Subject: losing warning
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 14:15:39 GMT

The following warning loses totally and ought to be removed:

foo.c:10: warning: suggest parentheses around && within ||

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Nit: Fixincludes & SunOs 4.1 malloc.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 17:31:46 GMT

    ``USL has never sold long distance.  You're going after the wrong
    men in black hats.  (Or, in the case of Plan 9, black space
    suits)'' - Tom Limoncelli

USL is mostly owned by AT&T, which has ultimate control over and
responsibility for everything that USL does.

The powerful often try to evade responsibility for their actions.
Naming those acting for them as a separate entity is a common method.
If we are wise enough to see through it, it won't work.


Newsgroups: gnu.gcc.bug
From: dov@ds20.dmi.stevens-tech.edu (Dov Kruger)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 22 Aug 1992 08:35:28 GMT

Nested classes result in a syntax error when the enclosing class is a template.
DEC's cxx compiler successfully swallows this, and I can't find anything to
indicate that it should be illegal, so I assume it's a bug.  Thanks for a
generally wonderful product.  My only question is -- when will you have exceptions?

cheers,
dov


template <class T> class A {
public:
  T* _data;
  class Iter {
    T* _data;
  };
};


main()
{
  A<int> x;
  A<int>::Iter y;
}

Newsgroups: gnu.gcc.bug
From: chpetk@gdr.bath.ac.uk (Toby Kelsey)
Subject: compiling gcc-2.2.2 on a RS/6000 with AIX/3.2
Followup-To: gnu.gcc.bug
Summary: make fails with an assembler error
Keywords: gcc aix make
Organization: School of Chemistry, University of Bath, UK
Distribution: gnu
Date: Wed, 12 Aug 1992 00:00:11 GMT

I have tried to compile gcc-2.2.2 on a RS/6000 running AIX 3.2
The make fails as below:

[...]
#                 for name in _muldi3 _divdi3 _moddi3  { ...etc }
#                 do \
#                   echo ${name}; \
#                   ./gcc -O2    -g -B./ -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
# Assembler:
# /tmp/ccEEYDFW.s: line 25: Error In Syntax 
# The error code from the last failed command is 1.
# 
# Make Quitting.
# $ 

According to lslpp the release level is 03.02.0000.0000

Is the fix mentioned in README.RS6000 only required if you
need to debug code compiled with gcc (as it says), or is it
needed to get gcc to compile?

Toby

---
Toby Kelsey
School of Chemistry,  # JANET: chpetk@uk.ac.bath.gdr, otherwise
University of Bath.   # chpetk%gdr.bath.ac.uk@nsfnet-relay.ac.uk
-- 
Toby Kelsey
School of Chemistry,  # JANET: chpetk@uk.ac.bath.gdr, otherwise
University of Bath.   # chpetk%gdr.bath.ac.uk@nsfnet-relay.ac.uk

Newsgroups: gnu.gcc.bug
From: josh@viewlogic.COM (Josh Marantz)
Subject: Empty-else-body warning considered harmful
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 19:56:17 GMT

I frequently compile code that has if statements with empty else
clauses, as the result of macros.  I also like to compile with maximum
warning level in gcc.  Now (2.2.2) I get warnings for this practice
which used to (1.39) pass thru gcc without warning.  Can anything be
done to get rid of this warning without losing all the others?

The warning isn't mentioned in the man page, although it goes away
when I don't use -W (I usually use -Wall).  In addition, since it's a
2-line warning, it's hard to clean up the output with a "grep -v"
filter.  I wrote a filter in C that does the trick, but it's a real
pain to have to deal with this.

Does anyone else see a lot of value in this warning?

% cat gccwarn.c
int a(x)
    int x;
{
    if (x)
        x = 7;
    else;
    return (x);
} /* int a */
% gcc-2.2.2 -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
% gcc-2.2.2 -W -c gccwarn.c
gccwarn.c: In function `a':
gccwarn.c:7: warning: empty body in an else-statement
% gcc -v
gcc version 1.39
% gcc -W -c gccwarn.c
%

----------------
Joshua Marantz                          You make my life and times
Viewlogic Systems,                        a book of bluesy Saturdays
josh@viewlogic.com                      And I have to choose...

Newsgroups: gnu.gcc.bug
From: lindholm@ucs.ubc.CA (George Lindholm)
Subject: gcc 2.2.2 -p option broken with sgi irix 4.0.4
Organization: University Computing Services, UBC, Canada
Distribution: gnu
Date: Wed, 12 Aug 1992 22:36:58 GMT

One of our users just pointed out to me that the -p option doesn't work 
with sgi's irix 4.0.4 as shown below:

lindholm@numeric1$ gcc -v -p a.c
Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix4/2.2.2/specs
gcc version 2.2.2
...
 /usr/local/lib/gcc-lib/mips-sgi-irix4/2.2.2/ld /usr/lib/mcrt1.o -L/usr/local/lib/gcc-lib/mips-sgi-irix4/2.2.2 -L/usr/local/lib a.o -lgcc -lc_p /usr/lib/crtn.o-lgcc
ld:
Can't locate file for: -lc_p
collect: /usr/bin/ld returned 1 exit status


And here is what cc says:

lindholm@numeric1$ cc -v -p a.c
...
/usr/bin/ld -G 8 -g0 -nocount /usr/lib/mcrt1.o /usr/lib/libprof1.a -count a.o -nocount -lc /usr/lib/crtn.o

Does anyone have a fix for this? Also, shouldn't the -pg option be removed (or
aliased to -p) since sgi doesn't have gprof command? Thanks

   George
-- 
George Lindholm                                  phone:    (604) 822-4375
University Computing Services, UBC               fax:      (604) 822-5116
6356 Agricultural Road, Vancouver, B.C., Canada  internet: lindholm@ucs.ubc.ca
V6T 1Z2                                          bitnet:   USERGNL@UBCMTSG
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Newsgroups: gnu.gcc.bug
Subject: -print-libgcc-file-name
Date: 13 Aug 92 17:14:17 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The following two lines of gcc.c (2.2.2) in function process_command()
make command line parsing get confused:

      else if (! strcmp (argv[i], "-print-libgcc-file-name"))
	i++;

The line

    i++;

should be replaced with

    ;

Well, -print-libgcc-file-name seems not to be intended to be used, but
I got trapped when I added a new command line option by duplicating
the code used for -print-libgcc-file-name.

  Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)
Newsgroups: gnu.gcc.bug
From: byron@netapp.UUCP (Byron Rakitzis)
Subject: gcc-1.40: prototype declaring static & defining extern
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 06:41:34 GMT

Either ANSI C is too subtle for me, or this is a bug in gcc-1.40:

	static int foo(void);

	extern int main() {
		return foo();
	}

	extern int foo() {
		return 42;
	}

This code fails to draw any warnings from gcc (even with -Wall). I am
running under SunOS-4.1.1 on a sparc-2.

Newsgroups: gnu.gcc.bug
From: pn@telelogic.se (Piotr Nestorow - TeleLOGIC Malmoe AB)
Subject: gcc-2.2.2 cc1 problem on HP710 (HPUX-7.05)
Organization: TeleLOGIC Malmoe AB, SWEDEN
Distribution: gnu
Date: Thu, 13 Aug 1992 09:58:14 GMT

Hi!

Machine: HP710 (HP-UX 7.05)
Gcc: gcc-2.2.2

When compiling (sorry about the example - 
   the code is generated by a code generator):

/* ------------------------ */

typedef int SDL_Integer;
typedef unsigned int SDL_Natural;

typedef SDL_Integer  z1C_Digit_Type;

typedef SDL_Integer  z1D_A_AbNo_Type;

typedef SDL_Integer  z1E_B_AbNo_Type;

typedef SDL_Natural  z00L_Limit;

typedef struct {
    z1E_B_AbNo_Type  B_AbNo;
    SDL_Integer  NoOf_Periods;
}  z00J_Call_Info_Type;

typedef struct {
    z00J_Call_Info_Type  A[100 - 1+1];
}  z00K_Log_Array_Type;

typedef struct {
    SDL_Integer  NoOfCalls;
    z00K_Log_Array_Type  Log_Array;
}  z0055_Call_Record_Type;

typedef struct {
    z0055_Call_Record_Type  A[50 - 1+1];
}  z0056_Data_Base_Type;
extern z0056_Data_Base_Type  yMake_z0056_Data_Base_Type ( yExpr )
  z0055_Call_Record_Type  yExpr;
{
  int  yIndex;
  z0056_Data_Base_Type  yVar;
  memset((void *)(&yVar), 0, sizeof(z0056_Data_Base_Type));
  for (yIndex = 0; yIndex<=50 - 1; yIndex++)
    yVar.A[yIndex] = yExpr;
  return yVar;
}

/* ------------------------ */

Cc1 dumps core:

pn@cobra-11:42am-135 > /usr/local/lib/gcc-lib/hp710-hpux/2.2.2/cc1 TELEPHONE_EXCHANGE.i -quiet -dumpbase TELEPHONE_EXCHANGE.c -g -version -o TELEPHONE_EXCHANGE.s
GNU C version 2.2.2 (hp9000s800) compiled by GNU C version 2.2.2.
TELEPHONE_EXCHANGE.i: In function `yMake_z0056_Data_Base_Type':
TELEPHONE_EXCHANGE.i:38: internal error--unrecognizable insn:
(insn 76 75 77 (parallel[
           (set (mem:BLK (reg:SI 132))
               (mem:BLK (reg:SI 133)))
           (clobber (reg:SI 132))
           (clobber (reg:SI 133))
           (clobber (scratch:SI))
           (clobber (scratch:SI))
           (use (const_int 40200))
           (use (const_int 4))
       ] ) -1 (nil)
   (nil))
IOT trap (core dumped)

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2 doesn't warn about `if (x = 0)' etc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 00:22:47 GMT

GCC 2.2.2 doesn't warn about the common C coding error of using `=' when you
meant to use `=='.  For example, in the program

	int main(int argc, char **argv) {
		char **a = argv;
		for (;;) {
			printf("%s", *a);
			if (*++a = 0)
				break;
			printf(" ");
		}
		printf("\n");
		return 0;
	}

there's no option to make GCC warn that `if (*++a = 0) ...' does not do what
the programmer probably expected.

The following patch causes GCC to warn about using `=' in a truth value
context if the -Wparentheses option is specified.  If you really mean `='
instead of `==', you can prevent the warning by writing an extra set of
parentheses around the assignment, e.g. `if ((*++a = 0)) ...'.  The extra
parentheses help signal the reader of the unusual case where an assignment
appears where an equality test is normally expected.


Thu Aug 13 23:59:47 1992  Paul Eggert  (eggert@twinsun.com)

	* c-common.c (truthvalue_conversion): Optionally warn if an
	unparenthesized assignment is used as a truth value.
	* c-parse.y (expr_no_commas): Mark assignments for warning.

===================================================================
RCS file: c-common.c,v
retrieving revision 2.2
diff -c -r2.2 c-common.c
*** c-common.c	1992/05/26 19:22:26	2.2
--- c-common.c	1992/08/13 23:59:47
***************
*** 879,884 ****
--- 879,889 ----
  			      fold (build1 (NOP_EXPR,
  					    TREE_TYPE (TREE_OPERAND (expr, 0)),
  					    TREE_OPERAND (expr, 1))), 1);
+ 
+     case MODIFY_EXPR:
+       if (warn_parentheses && C_EXP_ORIGINAL_CODE (expr) == MODIFY_EXPR)
+ 	warning ("suggest parentheses around assignment used as truth value");
+       break;
      }
  
    return build_binary_op (NE_EXPR, expr, integer_zero_node, 1);
===================================================================
RCS file: c-parse.y,v
retrieving revision 2.2.2.2
diff -c -r2.2.2.2 c-parse.y
*** c-parse.y	1992/08/01 03:25:39	2.2.2.2
--- c-parse.y	1992/08/13 23:59:47
***************
*** 428,436 ****
  	| expr_no_commas '?' xexpr ':' expr_no_commas
  		{ $$ = build_conditional_expr ($1, $3, $5); }
  	| expr_no_commas '=' expr_no_commas
! 		{ $$ = build_modify_expr ($1, NOP_EXPR, $3); }
  	| expr_no_commas ASSIGN expr_no_commas
! 		{ $$ = build_modify_expr ($1, $2, $3); }
  	;
  
  primary:
--- 428,438 ----
  	| expr_no_commas '?' xexpr ':' expr_no_commas
  		{ $$ = build_conditional_expr ($1, $3, $5); }
  	| expr_no_commas '=' expr_no_commas
! 		{ $$ = build_modify_expr ($1, NOP_EXPR, $3);
! 		  C_SET_EXP_ORIGINAL_CODE ($$, MODIFY_EXPR); }
  	| expr_no_commas ASSIGN expr_no_commas
! 		{ $$ = build_modify_expr ($1, $2, $3);
! 		  C_SET_EXP_ORIGINAL_CODE ($$, MODIFY_EXPR); }
  	;
  
  primary:

Newsgroups: gnu.gcc.bug
From: ret@dcs.ed.ac.UK (Rik)
Subject: g++ 2.1 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 18:31:10 GMT

Hi again,
        I don't know whether or not you received my last bug
report, anyway here is another one.

>From the C++ reference manual r.14.7 (Friends) :

template<class T> class task {
   friend task<T>* preempt(task<T>*) ;
};

template<class T> task<T>* preempt(task<T>* t) { }

main () {
task<int> i ;
}

Compiler says " parse error before > " twice on line 2.
Take out the <T> bit, and it crashes, signal 11.
Am I missing something again ? Please tell me if this mail got through.
Thanks !

> Richard Eyre-Todd.  Department of Computer Science, University of Edinburgh.

> Email: ret@uk.ac.ed.dcs                     | Solid fuel is for camp-fires,
> or     ret%dcs.ed.ac.uk@nsfnet-relay.ac.uk  | not boosting Space Shuttles. :-)

Newsgroups: gnu.gcc.bug
From: sstorry@axion.bt.co.UK (Simon Storry)
Subject: Re: compiling gcc-2.2.2 on a RS/6000 with AIX/3.2
Keywords: gcc aix make
Organization: BT Laboratories
Distribution: gnu
Date: Wed, 19 Aug 1992 09:14:34 GMT

In article <9208120002.AA03644@life.ai.mit.edu>, chpetk@gdr.bath.ac.uk (Toby Kelsey) writes:
|> I have tried to compile gcc-2.2.2 on a RS/6000 running AIX 3.2
|> The make fails as below:
|> 
|> [...]
|> #                 for name in _muldi3 _divdi3 _moddi3  { ...etc }
|> #                 do \
|> #                   echo ${name}; \
|> #                   ./gcc -O2    -g -B./ -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
|> # Assembler:
|> # /tmp/ccEEYDFW.s: line 25: Error In Syntax 
|> # The error code from the last failed command is 1.
|> # 
|> # Make Quitting.
|> # $ 
|> 
|> According to lslpp the release level is 03.02.0000.0000
|> 
|> Is the fix mentioned in README.RS6000 only required if you
|> need to debug code compiled with gcc (as it says), or is it
|> needed to get gcc to compile?
|> 
|> Toby

The fix appears to be required in order to compile gcc - not just for 
debugging as stated. At least, the problem went away when we appled 
the assembler fix under AIX/3.2...

Simon


+:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::+
::                              ::                                     ::
::        Simon Storry          ::    email: sstorry@axion.bt.co.uk    ::
::                              ::    voice: +44 473 646642            ::
:: Mail:  Rm 306, SSTF          ::    fax  : +44 473 643019            ::
::        British Telecom       ::                                     ::
::           Laboratories       ::::::::::::::::::::::::::::::::::::::::+
::        Martlesham Heath      ::
::        IPSWICH               ::  `Nothing's really a problem...  
::        IP5 7RE               ::    if you've got a big enough hammer!'
::        UK                    ::   
+::::::::::::::::::::::::::::::::+