HDTenEightyP/NetNews huggingface dataset:
From: neumann@dec4.wu-wien.ac.at (Gustaf Neumann)
Subject: core dump of gcc 2.2.2 on small example file
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 21:44:12 GMT

The following bug happend while compiling xdisp.c of lemacs19.3 with gcc 2.2.2
using -O -g. Below is a short extract, which suffices to show the misbehaviour.

Greetings,
-gustaf


<dec4:neumann:280> gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/mips-dec-ultrix4.2/2.2.2/specs
gcc version 2.2.2

------- input file: gccbug.c ------------------------------
typedef struct extent_fragment { int to; }*EXTENT_FRAGMENT;
EXTENT_FRAGMENT buffer_extfrag;
int to_pos;

void
update_cache (extfrag)
     EXTENT_FRAGMENT extfrag;
{ 
  to_pos = extfrag->to;
  buffer_extfrag = extfrag;
}
------- end of input file ----------------------------------- 

<dec4:neumann:279> gcc -g -O -c gccbug.c
pid 27960 (cc1) was killed on an unaligned access, at pc 0x46e40c 
gcc: Internal compiler error: program cc1 got fatal signal 10


DECstation 5000/200, Ultrix 4.2
# GCC was configured as follows:
./configure --target=mips-dec-ultrix4.2

--
Gustaf Neumann          neumann@dec4.wu-wien.ac.at, neumann@awiwuw11.bitnet
Vienna University of Economics and Business Administration 
Augasse 2-6,  A-1090 Vienna, Austria		
Tel: +43 (222) 31-336 x4533  	Fax: 347-555

Newsgroups: gnu.gcc.bug
From: graham@convex.com (Marv Graham)
Subject: long long <=> -traditional bug
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Distribution: gnu
Date: Wed, 9 Sep 1992 13:24:07 GMT

This source program

/*<<< If you have -traditional option on at command line and do any
long long shift operations, gcc aborts on the hp: >>*/

long long
xyzzy(long long a, long long b)
{
	return a << b;
}

produces these results when -traditional is used on an HP 710 under hpux:

gcc -v -traditional -c LS.c
Reading specs from /usr/local/lib/gcc-lib/hp700/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/hp700/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D_HPUX_SOURCE -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D___HPUX_SOURCE__ -D__hppa -D__hp9000s800 -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -D___HPUX_SOURCE -traditional LS.c /usr/tmp/cca19920.i
 GNU CPP version 2.2.2 (hp9000s800)
  /usr/local/lib/gcc-lib/hp700/2.2.2/cc1 /usr/tmp/cca19920.i -quiet -dumpbase LS.c -traditional -version -o LS.s
  GNU C version 2.2.2 (hp9000s800) compiled by CC.
  gcc: Internal compiler error: program cc1 got fatal signal 6

There are no problems when -traditional is omitted.

There are no problems with this program in any case with the convex and i386 versions of gcc-2.2.2

Marv Graham; Convex Computer Corp.  {uunet,sun,uiucdcs,allegra}!convex!graham
					graham@bach.convex.com

Newsgroups: gnu.gcc.bug
From: graham@convex.com (Marv Graham)
Subject: hppa1.1 switch problem
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Distribution: gnu
Date: Wed, 9 Sep 1992 13:56:33 GMT

/*<< hpux gcc 2.2.2 for hp710 (hppa1.1) gets wrong answers on the following code

The output should be:
4: a = 1028

but I get:

5: a = 1028
5: a = 1028

There is no problem unless -DOMIT is used on the command line
i.e: three cases work, more than three cases fails.

When it fails, it always uses the last case for all values of "a",
even when "a" is not one of the labels (e.g. 1 as below).
<<*/

sw(int a)
{
	switch (a) {
#ifdef OMIT
	case 0x402:
		printf("2: a = %d\n", a);
		break;
#endif  /* OMIT */
	case 0x403:
		printf("3: a = %d\n", a);
		break;
	case 0x404:
		printf("4: a = %d\n", a);
		break;
	case 0x405:
		printf("5: a = %d\n", a);
		break;
	}
}

main(void)
{
	sw(0x404);
	sw(1);
}

There are no problems with either the convex or the i386 versions of gcc-2.2.2
with this program - OMIT or not.


Marv Graham; Convex Computer Corp.  {uunet,sun,uiucdcs,allegra}!convex!graham
					graham@bach.convex.com

Newsgroups: gnu.gcc.bug
From: fjiao@cisco.com (Fan Jiao)
Subject: test, ignore
Organization: Cisco Systems, Inc.
Distribution: gnu
Date: Tue, 8 Sep 1992 05:52:21 GMT

This is a test.

Fan Jiao

Engineering

Newsgroups: gnu.gcc.bug
From: geoffr@sfu.CA (Geoff Routledge)
Subject: HPUX and -g: when?
Summary: GCC complains that -g is not supported
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: gnu
Date: Wed, 9 Sep 1992 16:19:19 GMT

I would like to use gcc, but I need to use a symbolic debugger too (I just
never got used to using printf's :).  But apparently (from responses I 
received to other postings) the -g option will not work with HPUX 8.0 - 
when will this be fixed?  

Just curious.

Geoff Routledge
DBA Communication Systems Inc.
North Vancouver, B.C., Canada

Newsgroups: gnu.gcc.bug
From: moore%cs@hellgate.utah.edu (Tim Moore)
Subject: Re: gcc 2.2.2 on hpux generate bad assembly code
Organization: University of Utah CS Dept
Distribution: gnu
Date: Sun, 13 Sep 1992 14:38:24 GMT

In article <1992Sep12.051459.21737@solucor.uucp> jack@solucor.UUCP (Jacques Gelinas) writes:

   I have built GCC 2.2.2 on HPUX 8.02 on a HP9000-827. I have
   managed to get a clean compile (stage1 stage2 stage3 and compare)
   by playing some game. I have found two bugs in the assembly
   code generated by the compiler.

   The following program crashes with an illegal instruction trap:

   int main()
   {
	   float a=0;
	   a = a + 1;
   }

   The module enquire.c which generate float.h crash this way.
   On the other hand, change float for double and all goes right.
   So I rebuild the compiler, adding on the command line
   "-Dfloat=double". Then I got a clean compile.

You may have configured gcc to generate code for a pa-risc 1.1
machine. Did you configure using "configure hppa1.0-hpux"?

   I start to compile a large CAD project, thinking that this
   bug could be solve later (converting every float to double).

   Doing so, after compiling a lot of code, I got another
   problem. This time, it was flag by the assembler. It is related
   to the number of parameter when generating the beginning of a function.
   It generates and .export assembly statement:

     Argument 1 or 3 in FARG upper
	   - lookahead = ARGW4=FR,RTNVAL=GR
 
Again, this is a symptom of configuration problem. Make sure you are
configured for hppa1.0.

--
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush

Newsgroups: gnu.gcc.bug
From: carson@cs.columbia.edu (Carson A. Gaspar)
Subject: Re: problems compiling X11R5 PL17 with gcc 2.2.2 [sun4, SunOS 4.1.2]
Organization: Columbia University Department of Computer Science
Distribution: gnu
Date: Tue, 15 Sep 1992 20:15:06 GMT

I noticed the same thing.  The problem, however, was in the generated
gram.c. If I used bison to generate it from gram.y, it compiled with
no problems.

from gram.c:

extern char *malloc(), *realloc();

# line 42 "gram.y"
#include <stdio.h>
..

-- 
			    Carson Gaspar
			carson@cs.columbia.edu

Newsgroups: gnu.gcc.bug
From: jet@nas.nasa.gov (J. Eric Townsend)
Subject: bug in Makefile for 2.2.2?
Organization: Numerical Aerodynamic Simulation, NASA Ames
Distribution: gnu
Date: Fri, 4 Sep 1992 15:29:09 GMT

I suspect this is a bug in the shell on the machine I'm porting gcc
to, but I thought I'd see if anyone else has had problems with it.
do1 is a shell script:
#!/bin/sh
pexec -on 3 make CC="stage1/gcc -Bstage1/" CFLAGS="-O"


$ ./do1
stage1/gcc -Bstage1/    -O   -o genrecog genrecog.o rtl.o ` case "obstack.o" in?*) echo obstack.o ;; esac ` ` case "stage1/gcc -Bstage1/"@"" in "cc"@?*) echo
;; esac ` ` case "" in ?*) echo  ;; esac `
ld: Error: undefined symbol '__obstack_begin'
ld: Error: undefined symbol '__obstack_newchunk'
ld: Fatal: no output file created

make: *** [genrecog] Error 1
spot:/u/sa/jet/gnu/gcc-2.2.2> stage1/gcc -Bstage1/    -O   -o genrecog genrecog.o rtl.o obstack.o


The problem seems to be that the case "loses" obstack.o.  If I
manually compile and simply state "obstack.o" things work just fine.

Anybody else seen something like this?
--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
                              '92 R100R, DoD# 0378
      "Heads.  Heads.  Heads.  Heads.  Heads.  Heads." -- R & G Are Dead

Newsgroups: gnu.gcc.bug
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: sun cc vs gcc structure
Organization: FWI, University of Amsterdam
Distribution: gnu
Date: Fri, 11 Sep 1992 08:32:50 GMT

zilla@nj.nec.com (John Lewis) writes:

>Hi, 
>In recompiling a file under gcc 2.2.2 (on sparc2), it seems like gcc
>is handling double alignment in a structure differently 
>than previous versions.  
>The file needs to be linked with some files compiled with the 
>normal sun cc; thus I specified -fpcc-struct-return, which did not help.

>The following self-contained program illustrates the problem.
>The program runs using the sun cc compilation line but fails with a
>buss error when run with either of the gcc lines.  
>================
>/*% cc % -o junk %*                             OK
> *% gcc % -o junk %*                            BUS ERROR
> *% gcc -fpcc-struct-return % -o junk %*        BUS ERROR
> */

>  p += 4;                                     /* make it aligned on 4*/

You mess with the structure alignment requirements. There is
no guarantee that your code will continue to work with Sun's
cc. (And it doesn't, if you use -dalign)
Gcc 2.x assumes that doubles are aligned on 8 byte boundaries.
That assumption holds, until people mess with the alignment.
Actually, I'm suprised that Sun's compiler doesn't do this by default.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

Newsgroups: gnu.gcc.bug
From: bwilson@shasta.stanford.edu (Bob Wilson)
Subject: Re: need test for negative constants in output_addr_const()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 19:30:14 GMT

> The case you are concerned with should never happen.  In GCC 2, the
> second argument of a MINUS should never be an integer constant.  If
> this ever happens, please send a bug report with a test case.
> 
> (The fix that you sent won't work.  It gets the sign wrong in the output.)
> 

OK, here's a simple test case.  This produces something like ".word buf--432"
in the MIPS .s file.


static char buf[512];

static struct io {
	int fd;
	char *bp;
	char *buffer;
	char *limit;
} iob[] = {
	0, 0, 0, 0,
	1, buf, buf, buf + sizeof buf - 80
};

main()
{
}

Newsgroups: gnu.gcc.bug
From: geoffr@sfu.CA (Geoff Routledge)
Subject: Re: HPUX and -g: when?
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: gnu
Date: Mon, 14 Sep 1992 21:03:17 GMT

zoo@cygnus.com (david d `zoo' zuhn) writes:

>Except that by saying HP9000, you haven't given us any useful information,
>other than that it's an HP unix box, as opposed to the HP3000, which runs
>the proprietary HP OS, whose name I can't recall.

>The 9000/300's and /400's are 68k based.

>The 9000/700's and /800's are HPPA based.

Oops!  I should have known.  We have HP9000 series 400 workstations (68k).
Is there any plans on GNU's part to fix this? or is it an HP problem?

Geoffrey Routledge
DBA Communication Systems, Inc.
North Vancouver, B.C., Canada

Newsgroups: gnu.gcc.bug
From: garyo@think.com (Gary Oberbrunner)
Subject: Any use of stdarg causes compiler warnings with -Wcast-align
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 20:41:39 GMT

When I use stdarg in a program and compile it with gcc 2.2.2 on my Sun4c
running 4.1.2, I get these warnings:

draw_func.c:107: warning: cast increases required alignment of target type
draw_func.c:107: warning: cast increases required alignment of target type

Two per line on which "va_arg" appears.

Test prog:

  #include <stdarg.h>
  int main(int a, ...) 
  {
  va_list va;
  int foo;
  va_start(va, a);
  foo = va_arg(va,int);
  return 0; 
  }

Compile like this:
  % gcc -c -Wcast-align foo.c
  foo.c:7: warning: cast increases required alignment of target type
  foo.c:7: warning: cast increases required alignment of target type
  %

I presume this is a problem with the implementation of the va_arg macro.

				- Gary Oberbrunner
				Thinking Machines Corporation
				245 First St
				Cambridge, MA 02142
				garyo@think.com

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 19:00:34 GMT

  And anyway, do you really want each of the thousands of people ...
  to send in a report...

You seem to be urging the public to disregard my advice as to how to
report bugs, on the grounds that you know better than I what they
should do to be helpful.

Please don't do this.  You may mean well, but it interferes with my
work.

If you think I may have made a mistake in writing my recommendations
for reporting bugs, please send your suggestion to me alone.  I do
make such mistakes, but when I do, a message to me is enough to let me
correct it.  Please don't take it upon yourself to correct what you
think is my mistake whether I like it or not.


To everyone who may find a bug: you don't have to obey my
recommendations; but if you'd like to help get bugs fixed, please do
follow them.  Please disregard any suggestions that you should do
otherwise.

Newsgroups: gnu.gcc.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: built-in strlen returns long unsigned int?
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Fri, 4 Sep 1992 20:44:57 GMT

Compiling libg++ 2.2 with gcc 2.2.2, I get the following result:

-----
gcc -g  -I.. -I../../../libg++/src -I../../../libg++/src/../iostream
-I../../../libg++/src/../g++-include  -c ../../../libg++/src/AllocRing.cc 

In file included from ../../../libg++/src/std.h:26, from
../../../libg++/src/AllocRing.cc:22:

../../../libg++/src/../g++-include/string.h:28: declaration of `int  strlen
(const char *)'

<built-in>:0: conflicts with built-in declaration `long unsigned int
strlen (const char *)'
-----

Why does gcc think that strlen should return long unsigned int, rather than
int?  How does it go about deciding the return type for these built-in
functions?  I haven't been able to find the place in the make process where
this happens.

I am working on a Sequent Symmetry running Dynix.  The string.h we are
using comes, I believe, from the AT&T C++ translator v1.2, and looks like
this:


/*	@(#)string.h	1.2	*/
extern char
	*strcpy(),
	*strncpy(),
	*strcat(),
	*strncat(),
	*strchr(),
	*strrchr(),
	*strpbrk(),
	*strtok();
extern int
	strcmp(),
	strncmp(),
	strlen(),
	strspn(),
	strcspn();

Would the absence of "int" in front of "strlen()" be confusing the make
process?  The strings.h on the machine is the Sequent version, and has the
ususal-style declaration.

--
Jason Merrill
jason@jarthur.claremont.edu
-- 
Fool on a Pedestal

Newsgroups: gnu.gcc.bug
From: hilfingr@tully.cs.berkeley.edu (Paul N. Hilfinger)
Subject: Possible stdarg.h bug on Mips Ultrix?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 07:46:58 GMT

In gcc 2.2.2, stdarg.h includes va-mips.h, which says

    #define va_arg(AP, mode)						\
      ((mode *)(AP = (char *) (__alignof(mode) > 4			\
				    ? ((int)AP + 2*8 - 1) & -8		\
				    : ((int)AP + 2*4 - 1) & -4)))[-1]


(if !lint).  However, under Ultrix V4.2A (Rev. 47) running on a
DecStation, I find the following:

    #ifdef __host_mips

     ...

	    /* va_arg aligns list and points past data */
    #define va_arg(list, mode) ((mode *)(list =\
     (va_list) ((((int)list + (__builtin_alignof(mode)<=4?3:7)) &\
     (__builtin_alignof(mode)<=4?-4:-8))+sizeof(mode))))[-1]

Notice that the va-mips.h code is insensitive to sizeof(mode).  As a
result, passing of sufficiently large structures does not work.  What
is going on?

P. Hilfinger

Newsgroups: gnu.gcc.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Bug in bitfield operations
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 13:24:39 GMT

Version: GCC 2.2.2 (m68k, sun3)

There is a bug in the optimizer for bitfield operations.


bug.c:
--------------------
struct term
{
  unsigned state: 1;
  unsigned info: 7;
  unsigned content: 24;
};

f (struct term t)
{
  struct term t1[1], t2[1]; /* force into memory */
  t1[0] = t;
  g ((char) t1->content);
  t2[0] = t;
  g ((short) t2->content);
}
--------------------

Compile with: gcc -O -S bug.c

bug.s:
--------------------
#NO_APP
gcc2_compiled.:
.text
	.even
.globl _f
_f:
	link a6,#-8
	movel a2,sp@-
	movel d2,sp@-
	movel a6@(8),d2
	movel d2,a6@(-4)
	moveb a6@(-2),d1	| <--- wrong
	extbl d1
	movel d1,sp@-
	lea _g,a2
	jbsr a2@
	addqw #4,sp
	movel d2,a6@(-8)
	bfexts a6@(-6){#0:#16},d1
	movel d1,sp@-
	jbsr a2@
	movel a6@(-16),d2
	movel a6@(-12),a2
	unlk a6
	rts
--------------------

The bug occurs in the combine pass, where these insns

-------------------- (bug.c.flow)
(insn 13 11 14 (set (reg:SI 31)
       (zero_extract:SI (mem/s:QI (plus:SI (reg:SI 14)
                   (const_int -3)))
           (const_int 24)
           (const_int 0))) 233 {extzv} (nil)
   (nil))

(insn 14 13 16 (set (reg:SI 32)
       (sign_extend:SI (subreg:QI (reg:SI 31) 0))) 49 {extendqisi2} (insn_list 13 (nil))
   (expr_list:REG_DEAD (reg:SI 31)
       (nil)))

(insn 16 14 18 (set (mem:SI (pre_dec:SI (reg:SI 15)))
       (reg:SI 32)) 29 {movsi+1} (insn_list 14 (nil))
   (expr_list:REG_DEAD (reg:SI 32)
       (nil)))
--------------------

are combined into ((const_int -2) is wrong)

-------------------- (bug.c.combine)
(insn 16 14 18 (set (mem:SI (pre_dec:SI (reg:SI 15)))
       (sign_extend:SI (mem/s:QI (plus:SI (reg:SI 14)
                   (const_int -2))))) 49 {extendqisi2} (nil)
   (nil))
--------------------
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.gcc.bug
From: zilla@nj.nec.com (John Lewis)
Subject: suncc vs gcc align
Organization: C&C Research Labs, NEC USA, Princeton, N.J.
Distribution: gnu
Date: Sat, 12 Sep 1992 03:40:01 GMT

Hi, 
In recompiling a file under gcc 2.2.2 (on sparc2), it seems like gcc
is handling double alignment in a structure differently 
than previous versions.  
The file needs to be linked with some files compiled with the 
normal sun cc; thus I specified -fpcc-struct-return, which did not help.

The following self-contained program illustrates the problem.
The program runs using the sun cc compilation line but fails with a
buss error when run with either of the gcc lines.  
================
/*% cc % -o junk %*                             OK
 *% gcc % -o junk %*                            BUS ERROR
 *% gcc -fpcc-struct-return % -o junk %*        BUS ERROR
 */

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

struct S_Flonum {			/* structure containing double */
    int tag;
    double val;
};

typedef unsigned Object;
#define FLONUM(x)   ((struct S_Flonum *)(x))

main() {
  char *p;
  Object num;
  unsigned long a;

  p = malloc(sizeof(struct S_Flonum) + 100);  /* result is 8-aligned */
  p += 4;                                     /* make it aligned on 4*/

  num = (int)p;
  FLONUM(num)->val = 3.1415927;		/* BUSS ERROR here if 4-aligned */
  a = (unsigned long)&(FLONUM(num)->val);
  printf("val @ %d, 4=%d,8=%d\n",a,4*(a/4),8*(a/8)); fflush(stdout);
  printf("val=%f\n",FLONUM(num)->val);
}

Newsgroups: gnu.gcc.bug
From: gnulists@ai.mit.edu (GNU Mailing List Maintenance)
Subject: Re: HPUX and -g: when?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 17:31:11 GMT

> 
>   I would like to use gcc, but I need to use a symbolic debugger too (I just
>   never got used to using printf's :).  But apparently (from responses I 
>   received to other postings) the -g option will not work with HPUX 8.0 - 
>   when will this be fixed?  
> 
> Already in GCC 2.2.2 -g is supported.  You need to get GAS from Utah
> to use it, and supply the `--gas' flag to configure when you set up
> the compiler.
> 

Sorry, I forgot to mention that we have HP9000s, not PA machines - the 
Utah stuff is for PA.  Jeff Law (from Utah) told me that he thinks that
some stuff exists for HP 68000 machines, but he can't remember where; Any
ideas?

Thanks

Geoffrey Routledge
DBA Communication Systems, Inc.
North Vancouver, B.C., Canada



Newsgroups: gnu.gcc.bug
From: rhr@clio.rice.edu (Rush Record 713-864-1574)
Subject: gcc on solaris
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 01:59:55 GMT

You people may already know all about this. Forgive me if
so. A friend was talking to a Sun rep about solaris. I'm
sure you know they are no longer bundling the C compiler
with it. The rep claimed, however, that Sun's cheap ($700)
C compiler won't successfully compile gcc. They must be
trying to make things difficult for you.

Newsgroups: gnu.gcc.bug
From: jsr@dexter.mi.ORG (Jay S. Rouman)
Subject: gcc 1.41 -O2 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 18:13:50 GMT

>Sat Jun  6 15:00:22 1992  Richard Stallman  (rms@mole.gnu.ai.mit.edu)
>
>	* toplev.c (main): Accept -O1 and -O2.

I think you need to make this change to gcc.c for these to work.
----------------------cut-----------------cut-------------------
*** gcc.c.orig	Mon Sep  7 22:03:36 1992
--- gcc.c	Mon Sep  7 22:03:55 1992
***************
*** 262,268 ****
          %i %{!M*:%{!E:%{!pipe:%g.cpp}}}%{E:%W{o*}}%{M*:%W{o*}} |\n\
      %{!M*:%{!E:cc1 %{!pipe:%g.cpp} %1 \
  		   %{!Q:-quiet} -dumpbase %i %{Y*} %{d*} %{m*} %{f*} %{a}\
! 		   %{g} %{O} %{W*} %{w} %{pedantic} %{ansi} %{traditional}\
  		   %{v:-version} %{gg:-symout %g.sym} %{pg:-p} %{p}\
  		   %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
  		   %{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %{|!pipe:%g.s}} |\n\
--- 262,268 ----
          %i %{!M*:%{!E:%{!pipe:%g.cpp}}}%{E:%W{o*}}%{M*:%W{o*}} |\n\
      %{!M*:%{!E:cc1 %{!pipe:%g.cpp} %1 \
  		   %{!Q:-quiet} -dumpbase %i %{Y*} %{d*} %{m*} %{f*} %{a}\
! 		   %{g} %{O*} %{W*} %{w} %{pedantic} %{ansi} %{traditional}\
  		   %{v:-version} %{gg:-symout %g.sym} %{pg:-p} %{p}\
  		   %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
  		   %{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %{|!pipe:%g.s}} |\n\
----------------------cut-----------------cut-------------------
-- 
Jay Rouman  (jsr@dexter.mi.org  jsr@ais.org)
From: sean@flamingo.stanford.edu (Sean Quinlan)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 16:28:36 GMT

I think I have found a bug with the mips stdarg header.
The following program was run on a DEC 500 running
ULTRIX V4.2A (Rev. 47) and compiled with gcc version 2.2.2


The sample program is supposed to cycle through three structures
printing them out.  The correct output is 

1 2
13 12
123 456

when compiled with gcc I get

3 3
3 1
1 2

After playing with it a while, it looks like the macro va_arg
does not take a big enough step for each structure.  In fact the macro
in va-mips.h does not even take the size of the object that is to be
returned and thus it is not possible to step the correct amount.

I hope you can fix the problem!

thanks
sean quinlan

---------

#include <stdarg.h>

typedef struct Obj {
	int p0;
	int p1;
} Obj;

Obj
convert(int n, ...)
{
	va_list ap;
	Obj o;
	int i;

	va_start(ap, n);
	for (i = 0; i < n; i++) {
		o = va_arg(ap, Obj);
		printf("%d %d\n", o.p0, o.p1);
	}
	va_end(ap);

	return o;
}

main()
{
	Obj a, b, c, d;

	a.p0 = 1;
	a.p1 = 2;

	b.p0 = 13;
	b.p1 = 12;

	c.p0 = 123;
	c.p1 = 456;

	
	d = convert(3, a, b, c);
}


Newsgroups: gnu.gcc.bug