HDTenEightyP/NetNews huggingface dataset:
Path: kithrup!hoptoad!pacbell!pacbell.com!mips!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!engtwomac.synoptics.com!Andrew_Smith.ENGINONE
   From: Andrew_Smith.ENGINONE@engtwomac.synoptics.com (Andrew Smith)
   Sender: gnulists@ai.mit.edu
   Organization: GNUs Not Usenet
   Distribution: gnu
   Date: Fri, 3 Apr 1992 18:26:22 GMT
   Approved: bug-gnu-utils@prep.ai.mit.edu
   Lines: 92

   Version:     gas-1.92.3 ftp'ed from wombat.gnu.ai.mit.edu on 27-mar-92
   Configure:  configure sun4os4 -target=a29k 
				 (this chooses native Sun a.out)

   1.    .align directive does not work as described in the manual (January
	   1992 edition).    .align 8 performs alignment to an 8 byte boundary,
	    not to a 256 (2^^8) boundary as described.
	    .align 0x8000 performs alignment to a 32k boundary
	    .align 0x10000 is a syntax error! (Any reason for this?)

As I recall, it matches the behaviour of .align from mataware's
assembler, but I could be mistaken.

   2.     Is there a way to align symbols declared by .comm and .lcomm
	   directives in the (non-existant!) .bss section?
	   Why can't the .bss be treated like any other section and support .bss
	   directives and the allocation of "variables" and labels in this space?
	   [I guess that COMMON storage is inherited from older high-level
	   languages].

It will be soon.

   3.      There is a strange feature with the subtraction of two labels
	    which are in the same section, same file:

I'll have to look into this and get back to you.

   4.      Could a newer gas support a "repetition" operator? This would be 
	    compatible with some other assemblers:
			      e.g.    wombat:     .word   [0x100]0

	   as well as the current syntax of

			      wombat:     .fill    0x100,4       ;  (for 32-bit
   .words)

I suppose it could.  What's the advantage?

   5.      Has anyone got a gas that uses BFD for output yet?

Not to my knowledge.

Newsgroups: gnu.utils.bug
From: uddeborg@sisu.SE (G|ran Uddeborg)
Subject: Re: Conversion from SCCS to RCS
Organization: Swedish Institute of Systems Development
Distribution: gnu
Date: Tue, 14 Apr 1992 07:43:32 GMT

In article <20608.9204100900@chough.eurotherm.co.uk> mt00@etherm.co.UK (Martin Tomes) writes:
>Does anyone know where I can get the sources for sccstorcs?

There is a script called sccs2rcs in volume 15 of comp.sources.misc,
available from many archive sites.  (In the UK, for example
clover.csv.warwick.ac.uk in
/pub/archive/comp.sources.misc/volume15/sccs2rcs_kc.)


Newsgroups: gnu.utils.bug
From: rrh@tera.com (Robert R. Henry)
Subject: cross development of binutils
Organization: Tera Computer Corporation, Seattle, WA
Distribution: gnu
Date: Thu, 9 Apr 1992 03:55:15 GMT

I'm trying to build a minimal set of gnu cc compiler tools (gcc-2.1,
gas, binutils-1.9/{ar,ranlib,ld,nm}) that will run on a sparc but
manipulate sun3 binaries.

gcc-2.1 is designed for doing this.

binutils-1.9 is not.

For example, ld includes <a.out.h>, which on a sun4, trapses through
/usr/include/machine/a.out, which through symbolic links eventually
comes back to /usr/include/sun4/a.out, which is not what I'd like to
build a ld that knows about sun3 binaries.

Has anybody built these binutils tools for such a cross develoment
environment?


Newsgroups: gnu.utils.bug
From: gerard@tscs.tscs.COM (Stephen M. Gerard)
Subject: Problem with configure script
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 04:52:41 GMT

Hello:

There is a major problem with the configure script when gcc is found.  You
set the "-O" flag which would be nice for general purpose compilations;
however, in the case of the configure script, GCC's optimization is too
effective eliminating the call to the function being checked for which
occurs after the exit(0).

It might also be nice to print out the status of each check so the user
can see if things are as they should be.

------------------------------------------------------------------------------
Stephen Gerard  -  Total Support Computer Systems  -  Tampa  -  (813) 876-5990
E-Mail: gerard@tscs.tscs.com				   FAX: (813) 871-2783
US-MAIL: Post Office Box 15395 - Tampa, Florida  33684-5395

Newsgroups: gnu.gcc.bug
From: pete@othello.dartmouth.edu (Pete Schmitt)
Subject: Problem compiling cp-lex.c on AIX 3.2 (RS6000)
Organization: Dartmouth College, Hanover, NH
Distribution: gnu
Date: Mon, 6 Apr 1992 14:44:53 GMT

It compiled fine under 3.1.  After upgrading to 3.2 over the weekend
I tried a recompile of gcc2.1.  I get the following error:

        cc -c    -g     -I. -I. -I./config cp-lex.c
"cp-lex.c", line 67.0: 1506-041 (S) Parameter list cannot contain fewer paramet.
The error code from the last failed command is 1.


Has someone fixed this one?  And are there others that need to be fixed as
well for 3.2?

-pete
--
Peter Schmitt, UNIX Systems Specialist, Computing Services, Dartmouth College
Email: peter.schmitt@dartmouth.edu                        Phone: 603-646-2085
******* Let us not give up meeting together, as some are in the habit *******
******* of doing, but let us encourage one another.    -Hebrews 10:25 *******

Newsgroups: gnu.gcc.bug
From: brendan@cs.widener.edu (Brendan Kehoe)
Subject: gcc 2.1 bug with frame ptr handling
Reply-To: brendan@cs.widener.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 20:59:28 GMT

The code below on a sparc produces bad code when no opimization is
turned on---note that it uses %fp *after* it's been zero'd out.  A
similar program for the DecStation exhibits the same problem.  I'm not
sure if this falls under the "gcc bug" section, or under the "really
nasty user trick".  Should gcc recognize that you've altered fp and
compensate [if it can]?

This bug came out of the sun4 start.c in the GNU C library failing to
build properly without optimization.

--
/* For mips, change %sp to `sp', and %fp to `$fp'.  */
register long int sp asm("%sp"), fp asm("%fp");

foo ()
{
  int a;

  /* mov 0, %fp */
  fp = 0;

  /* ld [%sp+16], %o0
     st %o0, [%fp-20] */
  a = ((int *)sp)[4];

  /* ld [%fp-20], %i0 */
  return a;

  /* When optimized, all of the above becomes the single instruction
       ld [%sp+16], %i0
     which avoids the problem.  */
}


--
Brendan Kehoe, Sun Network Manager                      brendan@cs.widener.edu
Widener University                                                 Chester, PA

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  G++ V2.1 PROBLEMS?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 21:52:48 GMT

You need to use gas.

> From: Ian Macpherson <ian@case.co.uk>
> Message-Id: <9204140915.AA01055@trillian.case.uucp>
> Subject: G++ V2.1 PROBLEMS?
> To: bug-gcc@prep.ai.mit.edu
> Date: Tue, 14 Apr 92 10:15:28 BST
> Cc: nc@uknet.ac.uk (Nigel Canning)

> 	Hello,

> 	We've just got gcc-2.1. I've installed it on a number of sun4
> 	machines and used it to successfully build programs such as libg++
> 	and groff.

> 	However, on a sun3 (a SUN 3/50) the C++ compiler has problems
> 	building groff and libg++. The SUN assembler objects to the .stabs
> 	directive generated by the compiler. The details of the system
> 	are:

> 	Host:			SUN 3/50
> 	OS:			SUNOS 4.1
> 	Host compiler:		GCC 1.40
> 	Host assembler:		Sun as
> 	Configuration:		sun3-sunos4.1 --nfp
> 				Linked `config.h' to `./config/xm-m68k.h'
> 				Linked `tm.h' to `./config/sun3n.h'
> 				Linked `md' to `./config/m68k.md'
> 				Linked `aux-output.c' to `./config/m68k.c'
> 				Linked `tconfig.h' to `./config/xm-m68k.h'

> 	As an example, here is the assembler output and errors from
> 	compiling the groff 1.05 c++test.c program:

> ====================== C++ source =============================
> #include <stdio.h>

> struct A {
>   A() { fputs("A\n", stdout); }
>   ~A() { fputs("~A\n", stdout); }
> };

> A a;

> main()
> {
>   return 0;
> }
> ====================== assembler code & errors ================
> 	#NO_APP
> 	gcc2_compiled.:
> 	.text
> 	LC0:
> 		.ascii "A\12\0"
> 	LC1:
> 		.ascii "~A\12\0"
> 	.globl _a
> 	.data
> 		.even
> 	_a:
> 		.skip 1
> 	.text
> 		.even
> 	.globl _main
> 	_main:
> 		link a6,#0
> 		jbsr ___main
> 		clrl d0
> 		unlk a6
> 		rts
> 		.even
> 	.globl __GLOBAL_$D$a
> 	__GLOBAL_$D$a:
> 		link a6,#0
> 		pea __iob+20
> 		pea LC1
> 		jbsr _fputs
> 		unlk a6
> 		rts
> 	.stabs "___DTOR_LIST__",22,0,0,__GLOBAL_$D$a
> as: error (c++test.s:31): Invalid operand
> 		.even
> 	.globl __GLOBAL_$I$a
> 	__GLOBAL_$I$a:
> 		link a6,#0
> 		pea __iob+20
> 		pea LC0
> 		jbsr _fputs
> 		unlk a6
> 		rts
> 	.stabs "___CTOR_LIST__",22,0,0,__GLOBAL_$I$a
> as: error (c++test.s:41): Invalid operand

Newsgroups: gnu.gcc.bug
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Subject: __GNUC__ should be defined in specs, not hardcoded in gcc.
Reply-To: friedman@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 14:11:05 GMT

__GNUC__ shouldn't be hardcoded in the gcc binary as a definition passed to
cpp.  It should be defined in specs, so that specs files written for older
versions of gcc (e.g. 1.40) won't create warnings that some users could
potentially misunderstand.  

The specs file is a really nice idea.  Advatange should be taken of it
wherever possible. 

Newsgroups: gnu.gcc.bug
From: peb@bsu-cs.bsu.edu
Subject: g++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 14:59:05 GMT

I just installed gcc-2.1 and libg++-2.0 obtained from prep.ai.mit.edu
on our DecSystem 5100 running Ultrix 4.1.  Collect2 has been installed,
but I am having problems with constructors: the program foo from
test-install on the libg++ distribution gets the following diffs:

1a2,3
> Initializing Foo(2) "static_foo1" with Foo(1)
> Destructing Foo(1) "static_foo1" (remaining foos: 1)
2a5,6
> Initializing Foo(3) "static_foo2" with Foo(2)
> Destructing Foo(2) "static_foo2" (remaining foos: 2)
14,15c18,19
< Destructing Foo(2) "static_foo2" (remaining foos: 1)
< Destructing Foo(1) "static_foo1" (remaining foos: 0)
---
> Destructing Foo(3) "static_foo2" (remaining foos: 1)
> Destructing Foo(2) "static_foo1" (remaining foos: 0)

It appears the very first Initialization should not have occurred.
What went wrong?  How serious is it?  How do I fix it?

Newsgroups: gnu.gcc.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: Re: FIX FOR: gcc 2.1 post increment bug
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Thu, 9 Apr 1992 21:21:00 GMT

A bug report from brennan@baker.ds.boeing.COM shows that, under
optimization, "switch (*p++)" may branch to the wrong case in the
switch.  Here is a patch.

----------------------------------------------------------------------------
Thu Apr  9 09:50:26 1992  Chip Salzenberg  (chip at tct.com)

	* stmt.c (expand_end_case): Before using index expression,
	  take care to call copy_to_reg() and protect_from_queue().

Index: stmt.c
*************** expand_end_case (orig_index)
*** 3582,3591 ****
  	    }
  
  	  emit_queue ();
  	  do_pending_stack_adjust ();
  
- 	  index = protect_from_queue (index, 0);
- 	  if (GET_CODE (index) == MEM)
- 	    index = copy_to_reg (index);
  	  if (GET_CODE (index) == CONST_INT
  	      || TREE_CODE (index_expr) == INTEGER_CST)
--- 3582,3591 ----
  	    }
  
+ 	  if (GET_CODE (index) == MEM)
+ 	    index = copy_to_reg (index);
+ 	  index = protect_from_queue (index, 0);
  	  emit_queue ();
  	  do_pending_stack_adjust ();
  
  	  if (GET_CODE (index) == CONST_INT
  	      || TREE_CODE (index_expr) == INTEGER_CST)
*************** expand_end_case (orig_index)
*** 3662,3667 ****
  				      index_expr);
  	      index = expand_expr (index_expr, 0, VOIDmode, 0);
! 	      emit_queue ();
  	      index = protect_from_queue (index, 0);
  	      do_pending_stack_adjust ();
  
--- 3662,3671 ----
  				      index_expr);
  	      index = expand_expr (index_expr, 0, VOIDmode, 0);
! 
! 
! 	      if (GET_CODE (index) == MEM)
! 		index = copy_to_reg (index);
  	      index = protect_from_queue (index, 0);
+ 	      emit_queue ();
  	      do_pending_stack_adjust ();
  
*************** expand_end_case (orig_index)
*** 3681,3686 ****
  	      index = expand_expr (index_expr, 0, VOIDmode, 0);
  	      index = convert_to_mode (Pmode, index, 1);
! 	      emit_queue ();
  	      index = protect_from_queue (index, 0);
  	      do_pending_stack_adjust ();
  
--- 3685,3693 ----
  	      index = expand_expr (index_expr, 0, VOIDmode, 0);
  	      index = convert_to_mode (Pmode, index, 1);
! 
! 	      if (GET_CODE (index) == MEM)
! 		index = copy_to_reg (index);
  	      index = protect_from_queue (index, 0);
+ 	      emit_queue ();
  	      do_pending_stack_adjust ();
  
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
      "Informix 4GL is not a 4G, and it's barely an L."  -- John Tombs

Newsgroups: gnu.gcc.bug
From: dan@uiucmath.math.uiuc.edu (Daniel R. Grayson)
Subject: gcc - too many arguments
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 00:53:12 GMT

Please ignore my previous message about gcc giving a message about too many
arguments - the problem went away when I replace "make" by a more modern
version.

Thank you.

Newsgroups: gnu.gcc.bug
From: Bruce_Martin@next.com
Subject: GCC 2.1 codegen bug when function is declared volatile
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 01:01:38 GMT

Gcc Version: 2.1
Configuration: i386-mach
Reported by: Bruce Martin (Bruce_Martin@NeXT.COM)

Description: if a function is declared volatile, gcc 2.1 produces
completely bogus code when the optimizer is used.  I'm not at all
sure what the correct response to the following C code should be,
but the current behavior is definitely wrong (I'm assuming that
the lack of any error messages means that the compiler should
succeed in the compilation).

Things work correctly when the optimizer is not used.

Test case:

	compiled with: cc1 -O -o foo.s foo.c

foo.c:

main()
{
    volatile double     result1, result2;
    volatile double     one_over(double);

    do {
        result1 = one_over(12);
        result2 = one_over(12);
    } while (result1 == result2);
    exit(0);
}

double
one_over(       double  x)
{
    return (double)( 1.0 / x );
}




Result of the compilation (note the lack of any code in main to
test the return value of one_over, or a call to exit()):

        .file   "foo.c"
gcc2_compiled.:
.text
        .align 2
.globl _main
_main:
        pushl %ebp
        movl %esp,%ebp
        subl $16,%esp
        call ___main
        pushl $1076363264
        pushl $0
        call _one_over
        fstp %st(0)
        .align 2,0x90
        .align 2
LC0:
        .double 0d1.00000000000000000000e+00
        .align 2
.globl _one_over
_one_over:
        pushl %ebp
        movl %esp,%ebp
        fldl LC0
        fdivl 8(%ebp)
        leave
        ret
        .align 2,0x90

Newsgroups: gnu.gcc.bug
From: me@superc.che.udel.edu (Scott M. Stark)
Subject: stage2 make fails on RS6000
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:34:53 GMT

Dear GNUs'

Installation of gcc-2.1 is failing at the 

	make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
portion of the installation.  The RS6000 system is at 03.01.0005.0012
and has the assembler fix APAR IX22829.  The error message produced
at failure is:
  make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
        stage1/gcc    -g -O -Bstage1/   -o cccp cccp.o cexp.o  
version.o obstack.o ` case "stage1/gcc" in "cc") echo alloca.o ;;  
esac `  -lm -lld
stage1/gcc: Internal compiler error: program ld got fatal signal 11
make: 1254-004 The error code from the last command is 1.

Any suggestions?

Scott Stark
stark@superc.che.udel.edu

Newsgroups: gnu.gcc.bug
From: bht@roadnet.COM (Bernie)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 21:10:45 GMT

/*
* I can't get the following piece of code to work when I use
* gcc 1.40 under SunOS 4.1.1 on a SPARC 2 machine.  I'm getting
* a core dump after calling the semctl() function.  When I
* use the Sun C compiler, all is OK and I don't get a core dump.
*
* I'm using standard System V semaphores -- all I want to do
* is set the value of a semaphore to zero.
*
* If you could take a look at this problem and let me know
* what you find out, I'd greatly appreciate it.
*
* Thanks in advance -- Bernie Thuman (bht@roadnet.com).
*/
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

#define SEM_KEY	(key_t) 12345	/* Semaphore key default. */

main ()
{
	int		id;		/* ID of semaphore. */
	union semun 	semctl_arg;	/* semctl() argument. */
	key_t		key = SEM_KEY;	/* value of semaphore key. */

	/* Get a semaphore: */
	if ((id = semget (key, 1, 0666 | IPC_CREAT)) < 0) {
		perror ("semget() failed");
		exit (0);
	}
	/* Set the value of the semaphore to zero: */
	semctl_arg.val = 0;
	if (semctl (id, 0, SETVAL, semctl_arg) < 0) {
		perror ("semctl() failed");
		exit (1);
	}
	exit (0);
}

Newsgroups: gnu.gcc.bug
From: michael@biokyb.uni-duesseldorf.DE (Michael Schoene (5314))
Subject: compiler error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 13:47:48 GMT

The following program crash's the compiler:

---------------------------------

int
main()
{
	int		tmp;
	double	l10;
	
	l10	= 0.9;
	tmp = (l10 >= 0.0) ? (int) l10 : ((int) l10 - 1);

	return 0;
}

--------------------------------

gcc -v test.c
Reading specs from /usr/extras/GNU/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/extras/GNU/lib/gcc-lib/sun4/2.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.c /usr/tmp/cca08610.i
GNU CPP version 2.1 (sparc)
 /usr/extras/GNU/lib/gcc-lib/sun4/2.1/cc1 /usr/tmp/cca08610.i -quiet -dumpbase test.c -version -o /usr/tmp/cca08610.s
GNU C version 2.1 (sparc) compiled by GNU C version 2.1.
gcc: Internal compiler error: program cc1 got fatal signal 11


                  Michael Schoene
              Department of Biophysics
             Division of Biocybernetics
  Heinrich-Heine-Universitaet Duesseldorf, Germany

Newsgroups: gnu.gcc.bug
From: wollman@uvm.edu (Garrett Wollman)
Subject: Re: __main
Organization: University of Vermont, EMBA Computer Facility
Distribution: gnu
Date: Thu, 16 Apr 1992 15:47:21 GMT

In article <9204152102.AA19523@life.ai.mit.edu> cmaeda@cs.cmu.edu writes:
>Then whatever __main does really belongs in __start.

You care to write a completely new crt0 for every single environment
that GCC supports?  I don't.  Nor do I want to give up shared-library
support.  If you don't have access to the source to _start, then the
current mechanism is the only way it can be done.

If it really bothers you, modify the compiler.  You have the source,
why not take advantage of it.  I, for one, consider it a feature that
GCC works with SunOS 4.1...

-GAWollman

-- 
[Y]ou can be pretty sure that if it isn't Usenet now it will be once
it's been in contact with Usenet for long enough. - Ed Vielmetti emv@msen.com
------------------------------
Garrett A. Wollman - wollman@uvm.edu - uvm-gen!wollman

Newsgroups: gnu.gcc.bug
From: tevi@iilcad.intel.com (Devor Tevi)
Subject: Another scheduler bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 15:01:52 GMT

Bug in the scheduler when compiling cp-expc.c/make_temporary_for_reference()
using -O -fschedule-insns

I am using the sources from 25-March-95 configured for i386v4. I
have added functional units.

The bug is related to the case of CC0, as was the previous bug I sent.

For the following set of insns in one of the basic blocks insn 230
is scheduled twice. This results in the linked list of rtl becoming
circular.

(insn 230 228 231 (set (cc0)
       (compare (mem:SI (symbol_ref:SI ("current_binding_level")))
           (mem:SI (symbol_ref:SI ("global_binding_level"))))) -1 (nil)
   (nil))

(note 231 230 232 "" NOTE_INSN_DELETED)

(note 232 231 233 "" NOTE_INSN_DELETED)

(insn 233 232 234 (set (reg:QI 43)
       (eq:QI (cc0)
           (const_int 0))) 139 {seq} (nil)
   (nil))


This happens as follows:

There is no LOG LINK dependence set up between insn 233 and insn 230.

insn 233 is marked as SCHED_GROUP_P.

Now since there is no dependency from 233 to 230 the scheduler decides
to schedule 230 before it ever reaches 233 on it's backward scan. So
by the time we reach 233, 230 has been scheduled (the scheduler decided
it was profitable to do so and the INSN_REF_COUNT(insn 230) became 0).

Now when we reach 233 insn 230 is scheduled again because insn 233
is  SCHED_GROUP_P.

I added a dependency from 233 to 230 but this was not enough since then
when launch_links() was called for insn 233, insn 230 was placed in the
insn_queue. But insn 230 was also immediately scheduled because insn 233 
is SCHED_GROUP_P, and it wasn't removed from the queue. This caused q_size 
to be != 0 at the end of the block - which triggers an abort.

So I also added some code to launch_links() so that insn 230 will not
go into the queue.

My suggested fix for this follows:

Regards,
Tevi.

tevi@iilcad.intel.com
972-4-355675

1217c1217
< 	rtx link;
---
> 	rtx link,prev;
1228c1228,1231
< 	for (link = LOG_LINKS (PREV_INSN (insn)); link; link = XEXP (link, 1))
---
> 	prev = PREV_INSN(insn);
> 	while(GET_CODE(prev)==NOTE)
> 	  prev = PREV_INSN(prev);
> 	for (link = LOG_LINKS (prev); link; link = XEXP (link, 1))
1230a1234,1238
> 	/* add dependence between insn and prev otherwise prev may
> 	   be scheduled before insn and then rescheduled again as
> 	   part of insn's SHED_GROUP_P */
> 	add_dependence(insn,prev,0);
> 
1815a1824
>   rtx prev_rtl = NULL;
1816a1826,1834
>   if(SCHED_GROUP_P(insn))
>     { /* see handling of prev_rtl==prev below */
>       prev_rtl = PREV_INSN(insn);
>       while(GET_CODE(prev_rtl)==NOTE)
> 	{
> 	  prev_rtl = PREV_INSN(prev_rtl);
> 	}
>     }
> 
1829a1848,1854
>       if(prev_rtl==prev)
> 	{ /* this means that prev is part of the group of insns that
> 	     will be scheduled along with insn and therefore should
> 	     not go through the insn_queue or ready list */
> 	  ; /* nothing
> 	}
>       else

Newsgroups: gnu.gcc.bug