HDTenEightyP/NetNews huggingface dataset:
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  gcc 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 07:13:58 GMT

> From: Norbert Hoelken <hoelken@iml.fhg.de>
> Date: Mon, 6 Apr 92 18:08:01 +0200
> Message-Id: <9204061608.AA00897@iml.fhg.de>

The gcc bug list/group is not the right place to report your problem.
Please use g++-bug for future problems with the C++ compiler.

> I just received version 2.1 of GNU CC, but there seems to be a bug
> with static data members in C++.

No, there is no bug.

> The following program was compiled without any options (only saying
> g++ <name>.cc) and produced the linker error

> 		undefined reference to `__4test$Global_Value'

This is correct behavior.

> I tried all combinations of GNU as/ld and systems as/ld with the
> same result.

As it should be.

> The error disappeares when i try to initialize the static member Global_Value
> (commented out in the example).

That is correct beahvior.

> The program works fine with an old release of g++ (g++ 1.37.1).

That is true, but does not matter.  It is a desupported feature if you
will.  Please read a recent ANSI draft or the ARM.  The short of it
is, the commented out line IS necessary.

> --- example -----
> #include <stream.h>

> class test
> {
>   public:
>     test();
>     ~test() {}
>     static int Global_Value;
> };

> test::test()
> {
>     cout << Global_Value << "\n";
> }

> // int test::Global_Value = 1;

> int main()
> {
>     test *t_ptr;
>     t_ptr = new test;
> }
> ------ end --------

Newsgroups: gnu.gcc.bug
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Subject: preventing -lang-c from being passed to cpp
Reply-To: friedman@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 15:29:29 GMT

   I would like to install older versions of gcc (e.g. 1.40) in the same
directory hierarchy that the 2.0+ programs are arranged in so that we can
run them by doing "gcc -V 1.40 foo.c".  This seems to work just fine
(provided I rename some of the binaries) except that older versions of cpp
don't understand the -lang-c (and similar) arguments.  I tried writing a
specs file to turn this off but I clearly don't understand what I'm doing
or it doesn't work at all, because I haven't figured out a way to do this.

   Does anyone have any advice?  I tried simply subsituting cpp 2.1 in
place of 1.40, but I got complaints like

        foo.c:30: #-lines for entering and leaving files don't match

from cc1 (1.41)



Newsgroups: gnu.gcc.bug
From: dgreenbe@sable.bio.dfo.ca (Dave Greenberg)
Subject: gcc on DG AViiON 310
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 18:27:41 GMT

-- 
_______________________________________________________________________
|David A. Greenberg                    email dgreenbe@sable.bio.dfo.ca|
|Bedford Institute of Oceanography     OMNET c/o J.LODER              | 
|P.O. Box 1006                         phone (902) 426-2431           | 
|Dartmouth, Nova Scotia                fax   (902) 426-7827           | 
|CANADA B2Y-4A2                        home  (902) 865-7511           |
_______________________________________________________________________

Newsgroups: gnu.gcc.bug
From: cmaeda@mc8.mach.cs.cmu.edu (Christopher Maeda)
Subject: __main
Reply-To: cmaeda@cs.cmu.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 03:16:44 GMT

   Date: Tue, 14 Apr 92 22:55:21 -0400
   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
   Message-Id: <9204150255.AA21925@vlsi1.ultra.nyu.edu>
   To: cmaeda@cs.cmu.edu
   Subject: Re:  __main

       Why do all C programs call __main?  The change logs seem to say __main
       is for C++ programs and shared libraries.

   Nothing to do with shared libraries, but it does have to do with C++
   The issue is that you might have a C main program calling a C++ function.

Huh?  If I'm compiling a C program (and I tell you as much, either by
naming my file foo.c or giving gcc the -x c option) why should I get a
bunch of crap for C++?



Newsgroups: gnu.gcc.bug
From: fiedler@avlcvx.AT (Fiedler)
Subject: gcc v2.0 stage2/3 mismatch on sparc-sun-sunos4.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 17:50:04 GMT

	GCC V 2.0 GENERATION:	Stage2 - Stage3 MISMATCH
	================================================

	Hi,

	This is to report a problem faced in making gcc version 2.0
	on a Sun SparcStation IPX running SunOS 4.1.1.
	
	We have already installed gcc version 1.40
	and used this to commence the bootstrap.

	We used ``config sparc-sun-sunos4.1'' to configure.
	After stage2, while comparing the .o's produced, we found that
	cccp.o and stage2/cccp.o do not match.

	The difference is as follows (disassembled for your benefit).
	stage2/cccp.o seems to have slightly smarter code.


	Diff between cccp.o and stage2/cccp.o	::
	==========================================
	(Note: text offset 0x948c is byte-offset 0x94ad of cccp.o)
	
	217,221c217,221
	< 0x948c <check_assertion+856>:	add %i2, %o0, %o1
	< 0x9490 <check_assertion+860>:	st %o1, [%i0+8]
	< 0x9494 <check_assertion+864>:	ld [%i2+%o0], %o1
	< 0x9498 <check_assertion+868>:	st %o1, [%i0]
	< 0x949c <check_assertion+872>:	st %i0, [%i2+%o0]
	---
	> 0x948c <check_assertion+856>:	add %i2, %o0, %i2
	> 0x9490 <check_assertion+860>:	st %i2, [%i0+8]
	> 0x9494 <check_assertion+864>:	ld [%i2], %o0
	> 0x9498 <check_assertion+868>:	st %o0, [%i0]
	> 0x949c <check_assertion+872>:	st %i0, [%i2]
	
	Another piece of information: If we use the Sun native CC
	instead of gcc v 1.4 to commence the bootstrap, then again
	cccp.o differs from stage2/cccp.o (all other .o's match).
	However, the differences are much more. (Sorry, I haven't
	disassembled those ).

	We are deferring installation till we hear from you or get a fix.
	Please give us a go ahead if it is harmless.

	Thanks.

	Ajith Narayanan		email: fiedler@avlcvx.uucp
	AVL List GmbH
	Graz, Austria.

Newsgroups: gnu.gcc.bug
From: hsw@columbia.sparta.com (Howard Weiss)
Subject: GCC 2.1 on ISC UNIX
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 05:02:47 GMT

I have successfully compiled gcc 2.1 on my ISC UNIX box (sysVr3) after
having a terrible time not being able to compile gcc 2.0.  I just ran
a test of some code (the UDel Network Time Protocol - NTP) whose makefile
uses gcc as the default C compiler.  This code compiled using gcc 1.39.
Now, using gcc 2.1, I get the following message from the second file (after
the first one successfully compiles):
	gcc: Internal compiler error: program cc1 got fatal signal 6

This results in a core dump.

Any ideas what is happening?

Thanks,

Howard Weiss

Newsgroups: gnu.gcc.bug
From: stolcke@icsi.berkeley.edu (Andreas Stolcke)
Subject: Re: preventing -lang-c from being passed to cpp
Reply-To: stolcke@icsi.berkeley.edu (Andreas Stolcke)
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Distribution: gnu
Date: Wed, 15 Apr 1992 07:34:00 GMT

In article <9204141529.AA27455@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu writes:
>   I would like to install older versions of gcc (e.g. 1.40) in the same
>directory hierarchy that the 2.0+ programs are arranged in so that we can
>run them by doing "gcc -V 1.40 foo.c".  This seems to work just fine
>(provided I rename some of the binaries) except that older versions of cpp
>don't understand the -lang-c (and similar) arguments.  I tried writing a
>specs file to turn this off but I clearly don't understand what I'm doing
>or it doesn't work at all, because I haven't figured out a way to do this.

To achieve this we wrote a little wrapper script for cpp to massage
the options.  All other programs invoked by gcc seem to be compatible.
The problem with specs is that they don't allow you to modify the
arguments that are compiled into gcc (look at the string constants
containing all those % thingies in gcc.c ...).  But then maybe
I am missing something, too.

Anyway the cpp wrapper is included below.

--Andreas 

#!/bin/sh

# do some options massaging to let the gcc 2.0 driver call gcc 1.4

cpp=/usr/local/lib/gcc-cpp

newargs=
echo=

for arg
do
	case "$arg" in
	-v)	echo=true
		newargs="$newargs $arg"
		;;
	-g)		# ignore
		;;
	-lang-c)	# suppress
		;;
	-lang-objc)
		echo "No Objective-C support available for this version." >&2
		exit 1
		;;
	-lang-c++)	# use old c++ preprocessor flag
		newargs="$newargs -+"
		;;
	-D__GNUC__=2)
		newargs="$newargs -D__GNUC__"
		;;
	-D__GNUG__=2)
		newargs="$newargs -D__GNUG__"
		;;
	*)	# make sure funny args are preserved 
		newargs="$newargs '$arg'"
		;;
	esac
done

cmd="$cpp $newargs"

if [ "$echo" ]; then
	echo $cmd >&2
fi

eval "exec $cmd"
-- 
Andreas Stolcke					stolcke@icsi.berkeley.edu
International Computer Science Institute	stolcke@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704	(510) 642-4274 ext. 126

Newsgroups: gnu.gcc.bug
From: purtill%idacrd@uunet.uu.net (Mark Purtill)
Subject: Bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 15:41:47 GMT

On a Sparcstation 2 (which is not connected to the outside;  I'm
typing this in from a printed transcript, so I might err).
% gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
gcc version 2.1
% more /etc/motd
SunOS Release 4.1.1 (CARS_2) #3: Thu Aug 15 10:35:49 EDT 1991
% cat >bugs.C
volatile void abort() ;
volatile void oink() ;
    void
oink() {
    abort() ;
    }
^D
% gcc -c bugs.C
bugs.C: In function `void  oink ()':
bugs.C:6: warning: `volatile' function does return
%
	Of course, the warning is erroneous, since oink calls abort,
which doesn't return, so `oink' doesn't either.  This problem did not
occur on g++ 1.37.1 (I think), which we had here until recently.

^.-.^ Mark Purtill, IDA/CCR-P, Thanet Road, Princeton NJ  08540; (609)924-4600.
((")) Email: purtill%idacrd@princeton.edu; uunet!idacrd!purtill. (609)497-0526.


Newsgroups: gnu.gcc.bug
From: wollman@uvm.edu (Garrett Wollman)
Subject: Bug in (sparc) va_start
Organization: University of Vermont, EMBA Computer Facility
Distribution: gnu
Date: Sun, 12 Apr 1992 19:24:17 GMT

Imagine you have a function like this...

void foo(uchar a,uchar b,...) {
  va_list args;

  va_start(args,b);
  do_something_with(va_arg(args,int));
  va_end(args)
}

On the Sparc, at any rate, such a function will be struck dead with a
wand of bus error.  &b turns out to be an odd address, and so va_start
initializes args to be (effectively) &b + 4, which is also an odd
address.  Bleah.

Now don't ask me how &b turns out to be odd..

The temporary work-around to this is to put an int argument first, and
va_start off of that, which then breaks ANSI compliance.

-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: miron@cs.sfu.ca (Miron Cuperman)
Subject: Re: GCC 2.0 - 2.1 Debug on Irix 4.0.1
Organization: Simon Fraser University
Distribution: gnu
Date: Tue, 7 Apr 1992 23:27:06 GMT

laf4@uhura.cc.rochester.edu (Lawrence Fried) writes:

>Subject: GCC 2.0 - 2.1 Debug on Irix 4.0.1
>Summary: GCC Debug broke when moving from Irix 3.3 to Irix 4.0.1
>Expires: 
>References: <9204061332.AA05164@northstar.dartmouth.edu>
>Sender: Larry Fried (larry@liouville.chem.rochester.edu)
>Followup-To: 
>Distribution: gnu
>Organization: University of Rochester (Rochester, NY)
>Keywords: 

>Does anybody know if GCC is supposed to produce debug information
>under Irix 4.0.1 ??

I do '-ggdb'.  I also managed to get gdb limping on this OS.  Drop
me a note if you are interested.
-- 
Forever, Miron Cuperman <miron@cs.sfu.ca>		(NeXTmail ok)

	Laissez faire.

Newsgroups: gnu.gcc.bug
From: fk@tv.tv.tek.COM
Subject: gcc 2.1 -fstrength-reduce compiler-abort
Reply-To: fk@tv.tv.tek.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 11:48:11 GMT

Greetings

With gcc 2.1 on a sparc, SunOS 4.1.1.  When compiling the following
function with '-O -fstrength-reduce', the compiler returns:

gcc: Internal compiler error: program cc1 got fatal signal 6

Note this script:

> Script started on Thu Apr  9 18:38:57 1992
> 1 % cat zz.c
> 
> joe()
>   {
>     int j;
> 
>     while( 1 )
>       {
>         for( j = 0; j < 4; j++ )
>           ;
>         for( j = 0; j < 4; j++ )
>           ;
>       }
>   }
> 
> 2 % gcc -v -O -fstrength-reduce -c zz.c
> Reading specs from /tv/lib/gcc/sparc/2.1/specs
> gcc version 2.1
>  /tv/lib/gcc/sparc/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 -D__OPTIMIZE__ zz.c /usr/tmp/cca01009.i
> GNU CPP version 2.1 (sparc)
>  /tv/lib/gcc/sparc/2.1/cc1 /usr/tmp/cca01009.i -quiet -dumpbase zz.c -O -version -fstrength-reduce -o /usr/tmp/cca01009.s
> GNU C version 2.1 (sparc) compiled by GNU C version 2.0.
> gcc: Internal compiler error: program cc1 got fatal signal 6
> 
> 3 % exit
> 
> script done on Thu Apr  9 18:39:41 1992

Thanks

Francis Kauth
fk@tv.tv.tek.com

Newsgroups: gnu.gcc.bug
From: fn@trinity.do.open.DE (Frank Nobis)
Subject: Bug in gcc 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 05:17:00 GMT

I got a fatal compiler error from cc1plus.

This is the code wich produced the bug.

-----------------------------------------------------------------------------
// This may look like C code, but it is really -*- C++ -*-

class t {
  int	some_data;
public:
  typedef unsigned long ulong;
  t() { some_data = 0; };
  void some_function(void) { some_data++; };
};

int main()
{
  t	t1;

  t1.some_function();

  return (0);
}
------------------------------------------------------------------------------

This code will compile without errors if you move the typedef before
the definition of the class. But I think this it is legal to put a
typedef inside a class definiton.

This is the output from gcc.

Reading specs from /usr/local/lib/gcc-lib/i386sco/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/i386sco/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -DM_UNIX -DM_I386 -DM_COFF -DM_WORDSWAP -DSCO -DUSG -D__unix__ -D__i386__ -D__M_UNIX__ -D__M_I386__ -D__M_COFF__ -D__M_WORDSWAP__ -D__SCO__ -D__USG__ -D__unix -D__i386 -D__M_UNIX -D__M_I386 -D__M_COFF -D__M_WORDSWAP -D__SCO -D__USG bug.cc /usr/tmp/cca01420.i
GNU CPP version 2.1 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386sco/2.1/cc1plus /usr/tmp/cca01420.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca01420.s
GNU C++ version 2.1 (80386, ATT syntax) compiled by GNU C version 2.1.
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 10


I compiled gcc on SCO ODT 3.2 on a 80386 CPU without 80387
#!/bin/sh
# GCC was configured as follows:
./configure --gas i386sco

For the bootstrap gcc I used rcc as suggested without optimizer, but
with debug option.
For the stage1 and stage2 compiler I used 
CFLAGS="-O -g -B./stage{1,2}/"
I did not make any change to the source.

The comparison between the stage2 and stage3 compiler did not
differantiate.

I hope this may help you to fix this.


MfG
   Frank
-- 
 fn@trinity.do.open.de  oo   Unsere Sache ist ein Geheimnis in einem Geheimnis,
 +49 231 103640 Voice  _\/_  das Geheimnis von etwas, das verhuellt bleibt,
 4600 Dortmund 1,     /\__/\ ein Geheimnis, das nur ein anderes Geheimnis
 Grosse Heimstr. 50    /\/\  erklaeren kann, ein Geheimnis ueber ein Geheimnis,
                       \__/  Das sich mit einem Geheimnis befriedigt.

Newsgroups: gnu.gcc.bug
From: bjork@telebit.COM (Steven Bjork)
Subject: gcc 2.1, sun2, sunos 4.0.3 build report
Organization: Telebit Corporation; Sunnyvale, CA, USA
Distribution: gnu
Date: Sun, 12 Apr 1992 17:43:52 GMT

On sun2, sunos 4.0.3 cc, compile fails:
"recog.c", line 1684: compiler error: expression causes compiler loop:
try simplifying

Compiled with gcc 1.39 built on sunos 3.4, compile succeeded.
Then, added gcc 1.39 gcc-gnulib to link list for stage1 link.

This allowed stage1 to successfully complete.

Full stage2 then worked.

Attempts to gcc 2.1 compile (something) that included netinet/ip.h
resulted in error of unlabeled union. Add to union definition on
line 81: ipt_timestamp

Next step, attempt R4 build with gcc 2.1.

Steven

11 apr 1992

Newsgroups: gnu.gcc.bug
From: miron@cs.sfu.ca (Miron Cuperman)
Subject: gcc-2.1 50% slower with -O than 2.0
Organization: Simon Fraser University
Distribution: gnu
Date: Thu, 9 Apr 1992 19:10:20 GMT

Is it just me?  My (large) program runs 50% slower under gcc-2.1 -O than
with gcc-2.0 -O.  This is on a sparc.  Any ideas?  I'll see if I can
track down particular functions.
-- 
Forever, Miron Cuperman <miron@cs.sfu.ca>		(NeXTmail ok)

	Laissez faire.

Newsgroups: gnu.gcc.bug
From: taylor@think.com (David Taylor)
Subject: gcc should accept "-u symbol"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 00:36:26 GMT

Gcc should accept "-u symbol" as a way of telling the linker that it
should treat the symbol as undefined.

Alternatively, and even nicer, would be an option to allow you to pass
arbitrary options to the linker -- something like Sun's "-Qoption prog opt".

David
--
David Taylor
taylor@think.com, ...{ames,bloom-beacon,harvard}!think!taylor

Newsgroups: gnu.gcc.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Working around tiny command line limit in Vax-Ultrix
Organization: University of California, Berkeley
Distribution: gnu
Date: Tue, 7 Apr 1992 20:32:34 GMT

Please use subject lines!  Your message arrived here with "Subject: (none)"
In article <9204071319.AA16534@uiucmath.math.uiuc.edu> dan@uiucmath.math.uiuc.edu (Daniel R. Grayson) writes:
>In compiling gdb 4.4 on a vaxstation II with ultrix 2.0 I get this strange gcc
>error:
>
>gcc -c -g     -I. -I. -I./../include -I./../readline -I./vx-share  breakpoint.c
>make[1]: execve: /usr/local/bin/gcc: Arg list too long
>make[1]: *** [breakpoint.o] Error 127
>make: *** [just-gdb] Error 1

For some reason, Vax-ultrix has a tiny command line length limit in execve
and in /bin/sh.  But for some reason, /bin/csh takes a much longer command
line.

Ultrix for DecStations doesn't have this problem.  Someone needs to tell
DEC to fix this one.

Given that, you can get gdb built by saving the "make" output into a file;
the make will fail with the message you show above.  Then edit the file
to remove everything but the gcc command that does the link.  Then get
csh to execute the file by saying "source file" from csh, where file is
the file you made by editing make's output.

(At least, you can get gdb built if there aren't other problems).

--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.gcc.bug
From: drg@bubba.ma30.bull.com (Daniel R Guilderson)
Subject: Re: Problem building stage3 compiler
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 17:54:59 GMT

Oops.  I was trying to build gcc-2.1.

Newsgroups: gnu.gcc.bug
From: wood@dg-rtp.dg.com (Tom Wood)
Subject: Re: object comparison failure w/ gcc 2.1 and m88k
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 16:57:13 GMT

Jim Robinson writes:
   
   GCC-2.1 was configured as m88k-sysv3 on a Motorola SVR3 88k (R32V3 M88100).
   The standard procedure was followed and everything  worked up until the
   comparison of stage 2 object files with stage 3 object files. A number of
   files differed:
   	cse.o emit-rtl.o integrate.o regclass.o reload1.o sched.o tree.o
   
It appears this is a bug in the native C compiler (Green Hills 1.8.5).
A few folks have run into this problem and each has come to this conclusion.
I suspect that the stage 3 compiler is actually good.  If this is true,
you should be able to make the stage 4 compiler and compare those objects
with the ones in stage3.

          make stage3
          make CC=stage3/gcc CFLAGS="-g -O -Bstage3/"

          for file in *.o; do
          tail +10c $file > foo1
          tail +10c stage3/$file > foo2
          cmp foo1 foo2 || echo $file
          done

Should you find that the miscompares go away, this indicates a bug in the
Green Hills compiler.

A second approach is to use GNU C to bootstrap (in a sense, that's what
the above is all about).  However, there is a 88open BCS compliant binary
release of GNU C version DG-1.37.29 available via anonymous ftp to
dg-rtp.dg.com:

-r--r--r--   1 1040753 Mar  6  1991 gcc-dg.1.37.29-88k.usr.tar.Z
-r--r--r--   1 2907221 Mar  6  1991 gcc-dg.1.37.29.tar.Z

The *.usr.tar.Z is the binary release; the *.tar.Z is the source release.

I have also been told that the miscompares did not happen with GCC 2.0.
A third alternative would be to use that to bootstrap GCC 2.1.

Newsgroups: gnu.gcc.bug
From: lextrait@essi.cerisi.fr (Lextrait Vincent)
Subject: behavior of gcc-cpp 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 20:16:59 GMT

gcc-cpp 2.1 refuses the following input:
'
It says:

:1: unterminated string or character constant

I do not mean it is a bug, but it makes gcc-cpp use unpossible
except for c-family languages. cpp is used by many other tools
other than c compilers. Just one (important) example: imake. I
have numerous other examples.
The behavior regarding simple quotes is all the more disturbing
as the quote is used by some object-oriented languages to perform
a call to a method.
Did I miss some option ? I don't see anything helping in the man.

Vincent Lextrait
lextrait@essi.cerisi.fr

Newsgroups: gnu.gcc.bug
From: tevi@iilcad.intel.com (Devor Tevi)
Subject: bug in scheduler
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 17:54:19 GMT

Bug in scheduler - abort() in sched_analyze_2 () at line #1223 in sched.c

I am using gcc from 25-March-92 configured for i386v4.

For the function cppp.c/collect_expansion() compiled -O -fschedule-insns.
(Note I have enabled scheduling - i.e. defined functional units).
We have the following sequence.


(insn 663 662 664 (set (cc0)
       (compare (reg/v:SI 31)
           (reg/v:SI 72))) -1 (nil)
   (nil))

(note 664 663 665 "" NOTE_INSN_DELETED)

(insn 665 664 667 (set (mem/s:QI (plus:SI (reg/v:SI 79)
               (const_int 5)))
       (eq:QI (cc0)
           (const_int 0))) 135 {seq} (nil)
   (nil))


sched.c/sched_analyze_2()  is called with :
 insn = insn 665   and   x = cc0
And this causes an abort in sched_analyze_2() as follows:

	/* User of CC0 depends on immediately preceding insn.
	   All notes are removed from the list of insns to schedule before we
	   reach here, so the previous insn must be the setter of cc0.  */
	if (GET_CODE (PREV_INSN (insn)) != INSN)
	  abort ();

The comment states that the note (664) is remove before we get here,
but from what I can see this is done by the procedure unlink_notes().
Now unlink_notes() is called after sched_analyze() in schedule_block(), 
and sched_analyze() calls sched_analyze_2().

Regards,
Tevi.

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


Newsgroups: gnu.gcc.bug
From: cmaeda@mc8.mach.cs.cmu.edu (Christopher Maeda)
Subject: principle of least expectation
Reply-To: cmaeda@cs.cmu.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 21:04:42 GMT

Oops.  Make that principle of least surprise.

Maybe it was a Freudian slip...

Chris

Newsgroups: gnu.gcc.bug