HDTenEightyP/NetNews huggingface dataset:
From: jbotz@mtholyoke.EDU (Jurgen Botz)
Subject: Bug in gcc-2.3.3 found while compiling Tk-3.0
Organization: Mount Holyoke College
Distribution: gnu
Date: Mon, 28 Dec 1992 19:15:41 GMT

I was just compiling the latest release of John Ousterhout's Tcl/Tk
with gcc-2.3.3 when I got the following error in tkTrig.c:

  tkTrig.c: In function 'TkBezierScreenPoint':
  tkTric.c:798: fp_offset (16) or end_offset (-4) is less than zero.

gcc-2.3.2 compiles the same file without complaining.  I don't have
the know-how or time to try to track this down right now, but I thought
I'd report it at least.  In case it might be helpful, here's the 
function...


void
TkBezierScreenPoints(canvasPtr, control, numSteps, xPointPtr)
    Tk_Canvas *canvasPtr;		/* Canvas in which curve is to be
					 * drawn. */
    double control[];			/* Array of coordinates for four
					 * control points:  x0, y0, x1, y1,
					 * ... x3 y3. */
    int numSteps;			/* Number of curve points to
					 * generate.  */
    register XPoint *xPointPtr;		/* Where to put new points. */
{
    int i;
    double u, u2, u3, t, t2, t3;

    for (i = 1; i <= numSteps; i++, xPointPtr++) {
	t = ((double) i)/((double) numSteps);
	t2 = t*t;
	t3 = t2*t;
	u = 1.0 - t;
	u2 = u*u;
	u3 = u2*u;
	xPointPtr->x = SCREEN_X(canvasPtr, (control[0]*u3
		+ 3.0 * (control[2]*t*u2 + control[4]*t2*u) + control[6]*t3));
	xPointPtr->y = SCREEN_Y(canvasPtr, (control[1]*u3
		+ 3.0 * (control[3]*t*u2 + control[5]*t2*u) + control[7]*t3));
    }
}


Newsgroups: gnu.gcc.bug
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Subject: Re: gcc-2.3.2 builds out of the box
Organization: Kansas State University
Distribution: gnu
Date: Sat, 26 Dec 1992 13:50:39 GMT

bray@wcuvax1.wcu.edu (Jim Bray) writes:

>  The problem I reported previously in making gcc-2.3.2 was caused by
>a missing character in the gcc/install.sh file. gcc-2.3.2 makes and
>seems to work well (compiles itself and the kernel) on my SLS (of
>12/03) system with a 0.99.1 kernel. Users may want to consider
>changing the linux-specific part of configure to install in
>/usr/instead of /usr/local (change prefix to /usr from /usr/local),
>and the system install program can be used instead of install.sh by
>removing the "broken_install=yes".

>--Jim Bray (bray@wcuvax1.wcu.edu)

I would caution against using 2.3.2, this version had some major bugs that
needed to be fixed. The current gnu snapshot seems to be stable, so I would
be 2.3.3 will be out soon.

Better to wait.

James

From: Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
Date: Sun, 3 Jan 93 17:56:04 +0100
To: bug-gcc@prep.ai.mit.edu
Cc: bug-gdb@prep.ai.mit.edu
Subject: More MKTEMP_EACH_FILE trouble
X-Created-Offline: 02-Jan-1993 14:00:10
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
Newsgroups: gnu.gcc.bug,gnu.gdb.bug
Followup-To: gnu.gcc.bug,gnu.gdb.bug

When using MKTEMP_EACH_FILE for GCC 2.3.3 with DBX debugging info, GDB
no longer works correctly as it explicitely checks for ".o" at the end
of symbols.  For instance, the backtrace command is affected.

Quotation from partial-stab.h of GDB 4.7:

	  if ((namestring[0] == '-' && namestring[1] == 'l')
	      || (namestring [(nsl = strlen (namestring)) - 1] == 'o'
		  && namestring [nsl - 2] == '.')

(BTW this is a bad idea if the length of namestring is less than 2.)

I solved the problem by letting ld append `.o' to the symbol
indicating the start of the text segment unless that symbol starts
with `-l' or already ends with `.o'.  (I'm still using the pre-BFD
version of GNU ld.)

Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug
From: johns@delilah.ccsf.caltech.edu (John Salmon)
Subject: varargs macros
Organization: Caltech Concurrent Supercomputing Facility.
Distribution: gnu
Date: Thu, 24 Dec 1992 15:30:27 GMT

I'm not sure if this is a bug or a misunderstanding.  I am trying to
write a varargs macro 'Error', which adds __FILE__ and __LINE__
information to a printf-like argument list.  It works fine, except
when the "rest" argument is empty, in which case the ##rest
consrtuction deletes too much of the preceding text.  I expected the
##args construction to delete only the preceding comma, but instead,
it deletes the __LINE__ as well as the comma.  

Is this the "correct" behavior?  Is there a reason why the ##rest
construction should delete more than the previous comma?  Is there a
workaround?

Thanks,
John Salmon		 Internet: johns@delilah.ccsf.caltech.edu
206-49 Caltech		 UUCP: johns%delilah.ccsf.caltech.edu@uunet.uu.net
Pasadena, CA 91125 USA	 Bitnet: johns@caltech.bitnet
(818)356-2907		 delilah.ccsf.caltech.edu=[131.215.145.137]

delilah->cat junk.c
void volatile _Error(const char *, ...) 
     __attribute__ ((format (printf, 1, 2)));
#define Error(format, args...) \
    _Error(__FILE__ "(%d):" format, __LINE__ , ##args)

main(){
    Error("hello world");
    Error("Hello %s", "world");
}
delilah->gcc -E junk.c
# 1 "junk.c"
void volatile _Error(const char *, ...) 
     __attribute__ ((format (printf, 1, 2)));



main(){
    _Error("junk.c" "(%d):" "hello world") ;
    _Error("junk.c" "(%d):" "Hello %s", 8 ,"world") ;
}
delilah->

--
John Salmon		 Internet: johns@delilah.ccsf.caltech.edu
206-49 Caltech		 UUCP: johns%delilah.ccsf.caltech.edu@uunet.uu.net
Pasadena, CA 91125 USA	 Bitnet: johns@caltech.bitnet
(818)356-2907		 delilah.ccsf.caltech.edu=[131.215.145.137]

Newsgroups: gnu.gcc.bug
From: win@in.rhein-main.DE (Winfried Koenig)
Subject: gcc and g++ warnings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 22:32:11 GMT

Hello,

when I compile the enclosed program with gcc (2.3.3) I get warning
messages. The essential message parts are enclosed in the comment.
I think, that messages marked with '!!' are ok but I don't understand
the reason for messages marked with '??'. Some messages are marked
with '!?', I think they should better read: '... discards `const' from ...'.

When I compile the same program with g++ I get no '??' message but
there is also no message for the lines marked with '???'.

Any comments?

Winfried

----------------------- cut ----------------
char ar[] = "foobar";
const char *st = "blub";
const char *const cpc = "wau";

int
main ()
{
  char *p;
  const char *pc;

  char **pp;
  const char **ppc;
  const char *const *pcpc;
  const char *const *const cpcpc = &cpc;

  void xpp (char **);
  void xppc (const char **);
  void xpcpc (const char *const *);

  p = ar;
  p = st;	/* !! assignment discards `const' from pointer target type */
  pc = ar;
  pc = st;

  pp = &p;
  pp = &pc;	/* !? assignment from incompatible pointer type */
		/* ??? no error if compiled with g++ !!!! */
  pp = &cpc;	/* !? assignment from incompatible pointer type */

  ppc = &p;	/* ?? assignment from incompatible pointer type */
  ppc = &pc;
  ppc = &cpc;	/* !! assignment discards `const' from pointer target type */

  pcpc = &p;	/* ?? assignment from incompatible pointer type */
  pcpc = &pc;
  pcpc = &cpc;

  cpcpc = &p;	/* !! assignment of read-only variable `cpcpc' */
  		/* !? assignment from incompatible pointer type */
  cpcpc = &pc;	/* !! assignment of read-only variable `cpcpc' */

  xpp (pp);
  xpp (ppc);	/* !? arg of `xpp' from incompatible pointer type */
		/* ??? no error if compiled with g++ !!!! */
  xpp (pcpc);	/* !? arg of `xpp' from incompatible pointer type */
  xpp (cpcpc);	/* !? arg of `xpp' from incompatible pointer type */

  xppc (pp);	/* ?? arg .. from incompatible pointer type */
  xppc (ppc);
  xppc (pcpc);	/* !! arg .. discards `const' from pointer target type */
  xppc (cpcpc);	/* !! arg .. discards `const' from pointer target type */

  xpcpc (pp);	/* ?? arg .. from incompatible pointer type */
  xpcpc (ppc);
  xpcpc (pcpc);
  xpcpc (cpcpc);

  return 0;
}
----------------------- cut ----------------

-- 
Winfried Koenig        win@in.rhein-main.de
Arendsstrasse 12       win@in.sub.org
6050 Offenbach         +49 69 868707
Germany

Newsgroups: gnu.gcc.bug
From: mybg@cs.huji.ac.il (Michael Ben-Gershon)
Subject: Re: Bug Report
Organization: The Hebrew U. of Jerusalem
Distribution: gnu
Date: Sat, 2 Jan 1993 21:50:40 GMT

In article <9212300819.AA22584@huey.cs.huji.ac.il> mybg@cs.huji.ac.il (Michael Ben-Gershon) writes:
>Date:       30 Dec 1992
>Version:    2.3.3
>Machine/OS: Acorn RISCiX
>
>When an error is generated (by %e) in specs included by %C, the
>compilation continues.  This is not the case when the error is generated
>in the specs themselves.....

As suggested by rms himself, I corrected gcc.c to fix this, so now errors
generated by specs included by %C (or the other things which include specs)
will terminate the compilation, just like errors generated by the specs
themselves.  I have mailed the bug-fix and it should be included in later
versions of gcc.  The other problems mentioned in the original post have
been worked-around without any bug-fixing necessary.

Michael
From: luik@isa.DE (Andreas Luik)
Subject: BITS_PER_UNIT == 8 assumed in float machine mode definition
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 19:47:57 GMT

Program:	gcc
Version:	2.3.2

Host:		sparc-sun-sunos4.1.3
Target:		own
Area:		cc1

Input file: 	all
gcc command:	n.a.

Synopsis:	BITS_PER_UNIT == 8 assumed in float machine mode definition

Description:

    machmode.def is used to define the machine modes. The float machine
    modes are defined using fixes sizes of 4, 8, 12 and 16 "bytes", but
    these "bytes" are units in the size defined by BITS_PER_UNIT. If this
    is defined as 16, then the smalles available float mode is 4 * 16 = 64
    bits wide. That's too much. At least the sizes of the float modes
    should depend on the BITS_PER_UNIT definition to simplify porting gcc
    to a target machine with word addressing.

Fix:

    Use a fix similar to the following:

*** machmode.def.ORIG	Fri May 31 22:43:32 1991
--- machmode.def	Mon Dec 21 01:36:57 1992
***************
*** 73,87 ****
  DEF_MACHMODE (DImode, "DI", MODE_INT, 8, 8, TImode)
  DEF_MACHMODE (TImode, "TI", MODE_INT, 16, 16, VOIDmode)
  
! DEF_MACHMODE (SFmode, "SF", MODE_FLOAT, 4, 4, DFmode)
! DEF_MACHMODE (DFmode, "DF", MODE_FLOAT, 8, 8, XFmode)
! DEF_MACHMODE (XFmode, "XF", MODE_FLOAT, 12, 12, TFmode)   /* IEEE extended */
! DEF_MACHMODE (TFmode, "TF", MODE_FLOAT, 16, 16, VOIDmode)
  
! DEF_MACHMODE (SCmode, "SC", MODE_COMPLEX_FLOAT, 8, 4, DCmode)
! DEF_MACHMODE (DCmode, "DC", MODE_COMPLEX_FLOAT, 16, 8, XCmode)
! DEF_MACHMODE (XCmode, "XC", MODE_COMPLEX_FLOAT, 24, 12, TCmode)
! DEF_MACHMODE (TCmode, "TC", MODE_COMPLEX_FLOAT, 32, 16, VOIDmode)
  
  /* BLKmode is used for structures, arrays, etc.
     that fit no more specific mode.  */
--- 73,91 ----
  DEF_MACHMODE (DImode, "DI", MODE_INT, 8, 8, TImode)
  DEF_MACHMODE (TImode, "TI", MODE_INT, 16, 16, VOIDmode)
  
! #define BYTES(B) ((B) * 8 / BITS_PER_UNIT)
  
! DEF_MACHMODE (SFmode, "SF", MODE_FLOAT, BYTES(4), BYTES(4), DFmode)
! DEF_MACHMODE (DFmode, "DF", MODE_FLOAT, BYTES(8), BYTES(8), XFmode)
! DEF_MACHMODE (XFmode, "XF", MODE_FLOAT, BYTES(12), BYTES(12), TFmode)   /* IEEE extended */
! DEF_MACHMODE (TFmode, "TF", MODE_FLOAT, BYTES(16), BYTES(16), VOIDmode)
! 
! DEF_MACHMODE (SCmode, "SC", MODE_COMPLEX_FLOAT, BYTES(8), BYTES(4), DCmode)
! DEF_MACHMODE (DCmode, "DC", MODE_COMPLEX_FLOAT, BYTES(16), BYTES(8), XCmode)
! DEF_MACHMODE (XCmode, "XC", MODE_COMPLEX_FLOAT, BYTES(24), BYTES(12), TCmode)
! DEF_MACHMODE (TCmode, "TC", MODE_COMPLEX_FLOAT, BYTES(32), BYTES(16), VOIDmode)
! 
! #undef BYTES
  
  /* BLKmode is used for structures, arrays, etc.
     that fit no more specific mode.  */


Comments:

    gcc is really great: I had only very little problems getting it
    running on this 16-bit processor with word addressing only. I know
    that gcc was not designed for such exotic processors but will
    nevertheless send you my bug reports and comments hoping they will
    help improving gcc.


-- 
Andreas Luik                E-Mail: luik@isa.de
(postmaster@isa.de)         UUCP:   ...!{uunet!unido,pyramid}!isaak!luik

Newsgroups: gnu.gcc.bug
From: traub@btcs.bt.co.UK (Michael Traub)
Subject: Re: Emacs with GCC 2.3.3
Organization: BT Customer Systems, Brighton, UK
Distribution: gnu
Date: Sat, 2 Jan 1993 16:50:11 GMT

In article <C04Exp.4u@fulcrum.co.uk> I.G.Batten@fulcrum.co.UK (Ian G Batten, Ian G Batten) writes:
>My previous message is in error.  The mistake was that I had not run the
>fixincludes script.  Interestingly, emacs compile correctly without
>fixincludes having been run but does not execute correctly.

Not that interesting. Many old compilers have macros for ioctls like so:

#define TIOCSETD        _IOW('t', 1, int)    /* set line discipline */

Which won't work with an Ansi compiler (you'll just get an ioctl with
the character 't' as the argument). Fixincludes changes them to:

#define TIOCSETD        _IOW(t, 1, int)      /* set line discipline */


It's not surprising that your un'fixinclude'd version didn't work.



-- 
Michael Traub
BT Customer Systems, Brighton Systems Centre. traub@btcs.bt.co.uk

Newsgroups: gnu.gcc.bug
From: pren@cs.umass.edu
Subject: gcc-2.3.2 & gawk-2.14
Followup-To: gnu.gcc.help
Organization: University of Massachusetts, Amherst
Distribution: gnu
Date: Wed, 23 Dec 1992 21:13:38 GMT

Hi,

We are using gcc-2.3.2 to build gawk-2.14 on a decstation running
Ultrix.4.2. The build was failed with the following error messages:


# make 1 (limits problem)
---------------------------------
gcc -DGAWK     -g -O  -c io.c
In file included from awk.h:28, from io.c:26:
/usr/local/lib/gcc-lib/decstation-ultrix.4.2/2.3.2/include/limits.h:11: syslimits.h: No such file or directory
*** Error code 1
---------------------------------
Stop.

Did anyone know where is the file "syslimits.h"? Is this a bug in
gcc-2.3.2 or gawk-2.14? Or I just miss something?

Please help!
Please send your reply to pren@cs.umass.edu

Thanks,
Pei

Newsgroups: gnu.gcc.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: misleading "limited range" warning
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 13:32:38 GMT

Compiling the following

=============================== warntest.c ==============================
int foo ()
{ if (0xFFFFFFFFULL & -1LL) return 4; else return 1; }
=========================================================================

using  "gcc -V 2.3.3 -c -W warntest.c"  produces the warning

warntest.c: In function `foo':
warntest.c:2: warning: comparison is always 1 due to limited range of data type

This is misleading: If the "comparison" ((0xFFFFFFFFULL & -1LL) != 0)
evaluates to 1 for a certain data type, then it evaluates to 1 for every
larger integer data type (in this case even for every integer data type).

I'm using gcc 2.3.3, configured i386-linux.
Btw, long long on i386 now work perfectly. Congratulations!


Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.gcc.bug
From: hall@waterfall.csee.usf.edu (Larry Hall)
Subject: g++ and dbx
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 21:27:26 GMT

Can't get dbx to run on the output of g++.  I have tried compiling
with option -g and -gdbx (which it does not know).  I have
tried dbx with no option.  The error is the same in all
cases.  I am running on a SUN sparc workstation with
O.S. 4.1.1 and dbx is the version that comes standard with 
a new Sparc.  The error looks like:
dbx: internal error: unexpected value 47 at line 2620 in file ../common/obj
ect.c

My Makefile looks as shown below.  Thanks.

--Larry Hall
hall@waterfall.csee.usf.edu

C++ = g++ 

C++FLAGS = 

DEPEND =

SRCS =	d.cc util.cc unify.cc learn.cc

SRCS1 =	d1.cc util.cc unify.cc learn1.cc

OBJS = $(SRCS:.cc=.o)

OBJS1 = $(SRCS1:.cc=.o)

omlet:	$(OBJS)
	g++ -o omlet $(OBJS) -lg++ -lm

newoml:	$(OBJS1)
	g++  -o omlet1 $(OBJS1) -lg++ -lm

%.o : %.cc 
	$(C++) -c  $(C++FLAGS) $< -o $@

depend:
	$(DEPEND) -I/usr/local/lib/g++-include -I/usr/local/lib/gcc-include \
	-I/usr/local/include $(SRCS)

# IF YOU PUT ANYTHING HERE IT WILL GO AWAY
# newoml makes Hall's test version.

Newsgroups: gnu.gcc.bug
From: luik@isa.DE (Andreas Luik)
Subject: truncation SImode -> HImode wrong if word_mode == QImode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 19:47:00 GMT

Program:	gcc
Version:	2.3.2

Host:		sparc-sun-sunos4.1.3
Target:		own
Area:		cc1

Input file: 	trunc.c

static void discardl (long l)	{}
void trunc ()
{
    long l;
    long long ll = (long long) 0x300040005;
    l = ll;     discardl (l);
}

gcc command:	gcc -S trunc.c

Synopsis:	truncation SImode -> HImode wrong if word_mode == QImode

Description:

    Assume a 16-bit word addressable target machine. Then the machine
    modes are:
    
	BITS_PER_UNIT			16
	BITS_PER_WORD			16
	UNITS_PER_WORD			1
    
	QImode = 16 Bits (C-Types char, short & int)
	HImode = 32 Bits (C-Type long)
	SImode = 64 Bits (C-Type long long)
	word_mode = QImode
    
    The assignment "(long) l = (long long) ll" must truncate the 64-Bit SImode
    value to the 32-Bit HImode value. This should be done by
    convert_move() [expr.c]. to_mode is HImode, from_mode is SImode. 
    
    convert_move() does nothing until it reaches the following statements: 
    
      if (GET_MODE_BITSIZE (from_mode) > BITS_PER_WORD)
	{
	  convert_move (to, gen_lowpart (word_mode, from), 0);
	  return;
	}
    
    As the condition is true, convert_mode() is recursively called with a
    source rtx with mode word_mode, i.e. QImode! This is wrong of course.

    (Usually this works because the conditions are as follows: from_mode
    must be DImode (> BITS_PER_WORD), to_mode must be != from_mode
    (otherwise convert_move will simply call emit_move_insn()), i.e.
    SImode. From (DImode) will be converted to lowpart(SImode, from) which
    will then work because to has a mode <= SImode. Note that this will
    fail in traditional architectures if integer arithmetic on TImode
    (16 byte ints) will be supported.)
    
    I don't understand the purpose of the above condition. The code that
    follows in convert_move() will handle all cases. Especially the code
    that handles from_mode DImode using CODE_FOR_truncdixx2 following the
    above condition will never get executed.
    
    Would you please check whether this condition (which should serve any
    optimization purpose I suppose) should not be eliminated.

Reproduce with:

    Difficult without appropriate target description. Please check the
    code. Maybe you may add a "truncdisi2" insn to a 32-bit target description
    (e.g. sparc.md) and see it ignored (if TRULY_NOOP_TRUNCATION is 0).

Fix:

*** expr.c.ORIG	Thu Dec  3 02:10:13 1992
--- expr.c	Thu Dec 17 18:55:10 1992
***************
*** 704,714 ****
--- 704,716 ----
        return;
      }
  
+ #if 0
    if (GET_MODE_BITSIZE (from_mode) > BITS_PER_WORD)
      {
        convert_move (to, gen_lowpart (word_mode, from), 0);
        return;
      }
+ #endif
  
    /* Handle pointer conversion */			/* SPEE 900220 */
    if (to_mode == PSImode)



-- 
Andreas Luik                E-Mail: luik@isa.de
(postmaster@isa.de)         UUCP:   ...!{uunet!unido,pyramid}!isaak!luik

Newsgroups: gnu.gcc.bug
From: fjtani@han.flab.fujitsu.co.JP (Hideaki Fujitani)
Subject: gcc-2.3.2 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 24 Dec 1992 11:09:06 GMT

A Merry Christmas.
  
 Following simple program shows Bus error at "a[0] = 5." only when
 dim is a multiple of 101.

     GCC: gcc-2.3.2,  OS: SunOS4.1.1,  Machine Sun Station 2;

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

main()
{
  void    *memory;
  int     *iv, dim;
  double  *a;

  dim = 101;
  memory = malloc(10000);
  iv = (int*)memory;
  memory += sizeof(int) * dim;
  a = (double*)memory;
  iv[3] = 15;
  a[0] = 5.;

  return  0;
}

# GNU is great !   fjtani@flab.fujitsu.co.jp


Newsgroups: gnu.gcc.bug
From: I.G.Batten@fulcrum.co.UK (Ian G Batten, Ian G Batten)
Subject: GCC 2.3.3 fails to compile Emacs 18.59?
Organization: Fulcrum Communications
Distribution: gnu
Date: Thu, 31 Dec 1992 10:05:45 GMT

[[ Sun 4/690-120, SunOS 4.1.2; Sun 4/470, SunOS 4.1.1 ]]

I have just attempted to compile Emacs 18.59 with gcc 2.3.3 using -O2.
This worked correctly with gcc 2.3.2.  Compiled with 2.3.3 it starts up
but immediately dies with SIGHUP.  Tracing it shows that the first SIGIO
after the window has appeared on my display causes an ioctl which fails.

I have recompiled from the same sources with gcc 2.3.2 and all is well.

I shall attempt to recompile with 2.3.3 and  the optimisation turned
off, but I'd like to know if anyone has seen similar troubles.

ian


Newsgroups: gnu.gcc.bug
From: robert@leda.e-technik.uni-dortmund.de (Robert Wei\ssenfels - The one who's watching YOU)
Subject: Problem with warning from gcc-2.3.[123]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 15:31:12 GMT

I have some trouble with the newest versions of GNU CC (2.3.[123]).

The problem didn't occur with 2.2.2 (and previous versions).

A source file reproducing the bug (?) can be generated by the following 
shell script:
#----------------------------bite,bite,bite-------------------------------
#!/bin/sh
#
# taken from the original source:
maxlines=4573
#
echo "struct Y_yywork { int verify,advance; } Y_yycrank[] = {" >test.c
lines=0
while [ $lines -ne $maxlines ]
do
  echo "0,0,0,0,0,0,0,0," >>test.c
  lines=`expr $lines + 1`
done
echo "0,0};" >>test.c
#----------------------------bite,bite,bite-------------------------------
The original source had been generated as a lex output.

The (minimum) trouble command was:	gcc -Wall -c test.c
Machine type:				SPARCstation IPX
OS:					SunOS 4.1.1
GCC was configured as follows:		./configure sparc --prefix=/tools/GNU

Error:
	A message

	test.c:4575: warning: aggregate has a partly bracketed initializer

	was repeated again and again until I interupted the output.


Good luck ;-)

Robert
              ________
             /////////   University of Dortmund
 # # #  # # ## / # //    Microelectronics Division
 # # ## # # # # # #/     c/o Dipl.-Ing. Robert Wei\ssenfels
 # # # ## # # # # #      P.O.BOX 500 500
  #  #  # # ## / #       D-4600 Dortmund 50
________/////////        
\_\X\_\_\///////         Phone: +45 231 755 3256
 \_\_\_\_\/////          
  \_\_\_\_\///           robert@leda.e-technik.uni-dortmund.de



Newsgroups: gnu.gcc.bug
From: karl@owl.HQ.ILeaf.COM
Subject: -exec-prefix vs. -exec_prefix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 17:14:02 GMT

gcc 2.3.3's configure script accepts an option `-exec-prefix' to set
exec_prefix in the Makefile; Autoconf-generated scripts accept
`-exec_prefix'.  It would be nice if everybody agreed.  Personally, I'd
vote for -exec-prefix, since we seem to use -'s in preference to _'s
wherever possible.

Newsgroups: gnu.gcc.bug
From: ori@marvin.technion.ac.il (Ori Degani)
Subject: IRIS4d gcc-2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Dec 1992 11:33:12 GMT

Hi,
  I tried to compile gcc on an iris4d running irix 4.0.5F
The problem is that it includes the file /usr/include/syms.h 
which tries to include: #include "cmplrs/stsupport.h"
with no luck.  It seems as though it's a problem with the system, 
but maybe it isn't.  Do you know anything about this?

Thanks,
Ori
   |  ----      Ori Degani
   |  |___      ori@eddie.technion.ac.il   (Ship Computer on the HOG)
   |  |         ori@marvin.technion.ac.il  (Who else) 
   |  ----      s2973229@techst02.technion.ac.il (Ech..)   


Newsgroups: gnu.gcc.bug
From: eurdang@advtech.USwest.COM (Erik Urdang)
Subject: RPC problem?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 16:45:02 GMT

I'm trying to compile (on a Sun Sparcstation IPC) FrameMaker's
"docclient.c",  an RPC application that runs maker as a client. When I
use Sun's "cc" it compiles and runs with no problems. When I use gcc,
it compiles (two minor warnings) and links. However, when I run it I
get the message:

	Bus error(coredump)

It seems to be happening during a call to: clnt_call ();

Any ideas?


Thank you!

Erik Urdang

(303) 541 6199 eurdang@uswest.com

Newsgroups: gnu.gcc.bug