HDTenEightyP/NetNews huggingface dataset:
From: kbasye@black.clarku.edu (Ken Basye)
Subject: Make 3.62 bugs
Reply-To: kbasye@black.clarku.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 12:29:37 GMT

I have found what I believe are two bugs (or perhaps limitations) in
GNU make 3.62.  Both bugs concern lack of error detection during the
processing of conditionals.

The first bug is exercised by leaving the ENDIF off of a conditional.
If the conditional has no ELSE, then the error is detected only when
the condition is false.  If there is an ELSE, then the error is
detected when the condition is true.  In either case, if the end of
the file is reached while lines are being ignored, an error is
signalled, whereas if eof is reached while lines are not being
ignored, no error is signaled and lines are all processed.

The second bug is exercised by having a second ELSE following an
IF-ELSE.  This should be an error, but is accepted without complaint,
regardless of whether the condition is true or false.  

ifeq (cond)
    body1
else
    body2
else
    body3
endif

To further confuse things, if cond succeeds, then both body1 and body3
are processed, while if cond fails, then only body2 is processed.  I
discovered these bugs in the process of building a three-way switch,
so that both body2 and body3 were also IF-ENDIF's.  

An example makefile with a correct three-way switch and two fragments
illustrating the bugs follows.  Thanks very much for GNU make and all
the other programs.
    
Sincerely,

kbasye@black.clarku.edu     
Ken Basye
Dept. of Math and CS
Clark University
950 Main St.
Worcester, MA  01610

____________________________________________________________________

# Change this variable to vary conditions
VAR = val3

CC1 = default

# This looks like the correct way to build a three-way switch.
# It works the way it should.
ifeq ($(VAR),val1)
  CC1 = compiler1
else 
  ifeq ($(VAR),val2)
    CC1 = compiler2
  else 
    ifeq ($(VAR),val3)
      CC1 = g++
    endif 
  endif 
endif 


CC2 = default
# This fragment should lose because the first IF has two
# ELSE's.  The second ELSE cannot belong to the second IF, since that
# is terminated by the first ENDIF.  This is accepted silently, and
# the lines following the second ELSE are processed if the first
# condition is true.  In this case, this has no effect.
ifeq ($(VAR),val1)
  CC2 = compiler1
else 
  ifeq ($(VAR),val2)
    CC2 = compiler2
  endif
else
  ifeq ($(VAR),val3)
    CC2 = g++
  endif
endif

CC3 = default

# This fragment should lose because there is no ENDIF for the IF
# It *does* lose if the test succeeds, but not if it fails.  This
# behaviour is reversed if the ELSE is removed.
#ifeq ($(VAR),val1)
#  CC3 = compiler1
#else 
#  CC3 = g++


test : 
	echo $(VAR) $(CC1) $(CC2) $(CC3)






Newsgroups: gnu.utils.bug
From: cliff@cs.cornell.edu (Cliff Krumvieda)
Subject: Prototype problems with wdiff-0.03
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 06:02:58 GMT

Howdy:

I ran into two (easily fixed) problems when compiling wdiff-0.03:

 1. In getopt.h, the prototype for getopt should not specify
    const char arguments unless the GNU library is being used---
    this problem is fixed in most of the getopt.h's distributed
    with the current utilities (including diff 2.0).  Without the
    fix, wdiff would not compile under AIX.
 2. In wdiff.c, the prototype for strstr should not specify a
    const char return value---a strstr prototype specifying a
    char return value is provided in <strings.h> on a number
    of OS's, including AIX, HP-UX, and ULTRIX.

Thanks!

						--Cliff Krumvieda



Newsgroups: gnu.gcc.bug
From: morgan@dl5000.bc.edu (Morgan Stair)
Subject: gcc-2.3.1 bug - ... incompatible pointer type
Organization: Institute for Space Research, Boston College
Distribution: gnu
Date: Tue, 17 Nov 1992 21:31:07 GMT

This code generate the following compiler error in gcc-2.3.1 on my sun
sparc 1+ running SunOS 4.1.1:

gcc -Wunused    t.c   -o t
t.c: In function `main':
t.c:11: warning: passing arg 1 of `func' from incompatible pointer type

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

/* modified from X11/Intrinsic.h XtCallbackProc typedef */
typedef void (*mytype)(
    double *,
    char *,
    char *
);
void func (mytype);
mytype main (double *a, char *b, char *c)
{
  func ((mytype)main);
  func (main);
}
--
***************************************
* Morgan Stair <Morgan@DL5000.BC.EDU> *
* BC / Institute for Space Research   *
* (617)552-8783                       *
***************************************

Newsgroups: gnu.gcc.bug
From: local@moonlite.CAlvacom.FR (Local Unix modifications)
Subject: Floating point problems with gcc 2.3.1 on ISC Unix
Reply-To: JH10@calvacom.fr (John Hughes)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 09:29:26 GMT

As I reported earlier the following little program, when compiled with
gcc 2.3.1 gives a bad answer when run on Interactive Unix 2.2.  It
works when compiled with gcc 2.1.  I can now also report that it works
(even when compiled with gcc 2.3.1) when run on a machine with a FPU.
That is to say the problem is caused by a bug in Interactive's 80387
emulator that is used when no physical 80387 is present.  (Or is it
ATT's emulator?   In other words will the problem affect non ISC
system V.3.2's on 386's ?  How about System V.4 ?

The program:

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

#include <stdio.h>


void Store (float a, float *b) { *b=a; }
float Sum (float a, float b) {float r; Store(a+b, &r); return (r); }
float Diff (float a, float b){float r; Store(a-b, &r); return (r); }
float Mul (float a, float b) {float r; Store(a*b, &r); return (r); }


int main () {
	volatile int digits = 0;
	volatile float b = 1.0;
	volatile float base = 2;

	do {
		digits++;
		b = Mul (b, base);
	}
	while (Diff (Diff (Sum (b, 1.0), b), 1.0) == 0.0);

	printf ("Digits = %d\n", digits);

	return 0;
}

--
John Hughes, RCI CalvaCom, Paris, France

Newsgroups: gnu.gcc.bug
From: sethg@cs.berkeley.edu (Seth C. Goldstein)
Subject: gcc 2.3.1 bug with templates in c++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 05:49:54 GMT

Machine:	sparc
Version:	gcc version 2.3.1
OS:		SunOS Release 4.1.2
problem:	
1 - The methods in a parameterized class are not implemented by the compiler
    if the definitions are not included in the class definition.  For
    example:

	//////////////////////////////// bar.h
	template<class T>
	class Bar
	{
		T data;
	public:
		inline Bar(T i);
		T get(void);
	};
	
	
	template<class T> inline 
	Bar<T>::Bar(T i)
	{
		data = i;
	}
	//////////////////////////////// EOF
	//////////////////////////////// bar.C
	#include "bar.h"
	
	template<class T> T
	Bar<T>::get(void)
	{
		return data;
	}
	//////////////////////////////// EOF
	//////////////////////////////// user.C
	#include <stdio.h>
	#include "bar.h"
	
	main()
	{
		Bar<int> bi(2);
	
		printf("%d\n", bi.get());
	}
	//////////////////////////////// EOF

    when compiled with: gcc-2.3.1 -o test bar.C user.C generates the
    following linktime error:

	ld: Undefined symbol 
	   _get__t3Bar1Zi 


Newsgroups: gnu.gcc.bug
From: jdf@fields.cin.oh.US (Jon Fields)
Subject: Re: gcc 2.3.1/i386-isc bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 04:14:16 GMT

> 
> This is the script I used to compile gcc-2.3.1 under ISC 3.01.
> 
> #!/bin/csh -x
> 
> set MAKE=make
> 
> if (-e Makefile) then
> 	$MAKE distclean
> endif
> ./configure --host=i486-isc --target=i486-isc
> $MAKE LANGUAGES="c" CFLAGS="" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""
> $MAKE LANGUAGES="c" CFLAGS="" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""  stage1
> $MAKE LANGUAGES="c" CC="stage1/xgcc" CFLAGS="-m486 -O -Bstage1/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""
> $MAKE LANGUAGES="c" CC="stage1/xgcc" CFLAGS="-m486 -O -Bstage1/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""  stage2
> $MAKE LANGUAGES="c" CC="stage2/xgcc" CFLAGS="-m486 -O -Bstage2/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS="" 
> foreach f (*.o)
> 	cmp $f stage2/$f
> end
> $MAKE LANGUAGES="c" CC="stage2/xgcc" CFLAGS="-m486 -O -Bstage2/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""  stage3
> $MAKE LANGUAGES="c c++" CC="stage3/xgcc" CFLAGS="-m486 -O -Bstage3/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS="" 
> $MAKE LANGUAGES="c c++" CC="stage3/xgcc" CFLAGS="-m486 -O -Bstage3/" X_CFLAGS="" CLIB="-lcposix -lPW" ENQUIRE_LDFLAGS=""  install install-fixincludes
> -- 
> ------------------\\----------------------\\----------------------------
> Jon Diekema        |    JD's Connection    | You don't get trained here,
> 7719 Park Lane     |  diekema@jdbbs.mi.org | you get here trained!
> Jenison, MI  49428 \\                      \\
> 

Thanks for the help, but I still experience the same symptoms as I
reported in my bug report.  I used your commands pretty much verbatim,
except changing i486 to i386, and removing the -m486.

Note that you have a 486, and are running ISC 3.01.  I have a 386, and
am running ISC 2.2.1.  I have no FP coprocessor.

Jon.

-- 
Internet: jdf@fields.cin.oh.us             Jonathan D. Fields     
    UUCP: ...!uunet!fields!jdf             5080 Kugler Mill Road
   Voice: 513-891-5081 (6-10 PM EST)       Cincinnati, Ohio 45236, USA

Newsgroups: gnu.gcc.bug
From: Colin.DEan@smallworld.co.uk (Colin Dean)
Subject: Build bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 10:14:16 GMT

Author of this bug report
-------------------------

Colin Dean,
Smallworld Systems Limited,
13-15 Newmarket Road,
Cambridge CB5 8EG,
England.

Fax:   +44 223 300692
Email: Colin.Dean@Smallworld.co.uk

20th November 1992

Summary
-------

gcc version 2.3.1, copied by ftp from /pub/gnu/gcc-2.3.1.tar.Z
at prep.ai.mit.edu on 17th November 1992 at around 08:00 GMT.

Built on SPARCstation 2 running SunOS 4.1.1 in sub-directory
sparc-sun-sunos4.1.1 using `../configure sparc-sun-sunos4.1.1'

The build step `make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"'
fails trying to make the Objective C bits, with the message:

make: Fatal error: Don't know how to make target `../assert.h'.

Workaround
----------

If you don't need Objective C support, use LANGUAGES=c or
LANGUAGES="c c++" for this and subsequent `make' stages.

Newsgroups: gnu.gcc.bug
From: leisner@eso.mc.xerox.COM ( Marty Leisner)
Subject: gcc -a doesn't seem to work
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 01:49:04 GMT

I'm using SunOS 4.1.2... gcc -a doesn't seem to include /usr/lib/bb_link.o
automatically...

leisner@annapurna$ gcc -a -v test.c -o test
Reading specs from /usr/gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/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/cca20067.i
GNU CPP version 2.2.2 (sparc)
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/cc1 /usr/tmp/cca20067.i -quiet -dumpbase test.c -a -version -o /usr/tmp/cca20067.s
GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o test.o /usr/tmp/cca20067.s
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/ld -e start -dc -dp -o test /lib/crt0.o -L/usr/lib/X11 -L/usr/openwin/lib -L/usr/marty/lib -L/usr/lib/X11 -L/usr/openwin/lib -L/usr/marty/lib -L/usr/gnu/lib/gcc-lib/sun4/2.2.2 -L/usr/gnu/lib test.o -lgcc -lc -lgcc
ld: Undefined symbol 
   ___bb_init_func 
collect: /usr/bin/ld returned 2 exit status
leisner@annapurna$ cc -a -v test.c -o test
/lib/cpp -undef -Dunix -Dsun -Dsparc test.c >/tmp/cpp.20096.0.i
/lib/ccom - -XO0 /tmp/ccom.20096.2.ir </tmp/cpp.20096.0.i >/tmp/ccom.20096.1.s
rm /tmp/cpp.20096.0.i
/usr/lib/iropt -O0 -o /tmp/iropt.20096.3.ir /tmp/ccom.20096.2.ir
rm /tmp/ccom.20096.2.ir
/usr/lib/cg -A/files3/leisner/tmp/test.d /tmp/iropt.20096.3.ir >/tmp/cg.20096.4.s
/bin/as -o test.o -Q /tmp/ccom.20096.1.s /tmp/cg.20096.4.s
rm /tmp/ccom.20096.1.s
/bin/ld -dc -dp -e start -X -o test /usr/lib/crt0.o /usr/lib/bb_link.o test.o -lc
rm /tmp/iropt.20096.3.ir
rm /tmp/cg.20096.4.s
rm test.o



Newsgroups: gnu.gcc.bug
From: fedor@csn.org (Adam Fedor)
Subject: Re: Fatal signal 10 with ObjC.
Organization: University of Colorado, Boulder
Distribution: gnu
Date: Mon, 23 Nov 1992 20:58:11 GMT

In article <By16vK.oK@unixhub.SLAC.Stanford.EDU> enelson@apnext1.slac.stanford.edu (Eric M. Nelson) writes:
>  The following simple program fails to compile with gcc 2.3.1 on a NeXT  
>running NeXTstep 3.0. Note that <stdarg.h> is required by <objc/Object.h>,  
>but <objc/Object.h> forgets to include it.
>
>#include <stdarg.h>
>#include <objc/Object.h>
>
>int main(){
>  id anObject;
>  anObject=[Object new];
>  }
>

I've got gcc-2.3.1 on a VAXstation (vax-dec-ultrix) and this program
compiles nicely, but when I run it, I get the error:

focus:~/src>test
record.h:123: failed assertion `i'
Illegal instruction

P.S. I don't have gdb on my machine, but hope to get it soon and see if
I can trace this.

P.P.S.  I sort-of remember some kind of mailing list for GNU objective-c
but I forget what it is.  Is it real or am I just imaginging it?


-- 
Adam Fedor. CU, Boulder		    | Fudd's Law of Opposition: Push something  
fedor@boulder.colorado.edu (W)      |   hard enough and it will fall over. 
adam@bastille.rmnug.org (H,NeXTMail)|

Newsgroups: gnu.gcc.bug
From: Colin.DEan@smallworld.co.uk (Colin Dean)
Subject: Build bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 10:16:01 GMT

Author of this bug report
-------------------------

Colin Dean,
Smallworld Systems Limited,
13-15 Newmarket Road,
Cambridge CB5 8EG,
England.

Fax:   +44 223 300692
Email: Colin.Dean@Smallworld.co.uk

20th November 1992

Summary
-------

gcc version 2.3.1, copied by ftp from /pub/gnu/gcc-2.3.1.tar.Z
at prep.ai.mit.edu on 17th November 1992 at around 08:00 GMT.

Built on SPARCstation 2 running SunOS 5.0 (Solaris 2.0) in sub-directory
sparc-sun-sunos5.0 using `../configure sparc-sun-sunos5.0'

The build fails with the message:

make: Fatal error: Don't know how to make target `config/sol2-c1.asm'.

Workaround
----------

>From directory <top>/sparc-sun-sunos5.0:

	mkdir config
	cd config
	ln -s ../../config/sol2-c1.asm
	ln -s ../../config/sol2-ci.asm
	ln -s ../../config/sol2-cn.asm
	ln -s ../../config/gmon-sol2.c
	cd ..

then repeat failed build stage.

Newsgroups: gnu.gcc.bug
From: leisner@eso.mc.xerox.COM (Marty Leisner 27283 )
Subject: Bug??  In front of end of gcc 2.x
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 20 Nov 1992 01:21:14 GMT

I'm running on Sparc, SunOS 4.1.2

This is my program:

main()
{
        int i;

        switch(i) {
                default:
        }
}


gcc1.4.2 sez:
leisner@annapurna$ gcc142 switchbug.c -v -c
gcc version 1.42
 /usr/gnu/src/gcc-1.42/cpp -v -undef -D__GNUC__ -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ switchbug.c /usr/tmp/cca12363.cpp
GNU CPP version 1.42
 /usr/gnu/src/gcc-1.42/cc1 /usr/tmp/cca12363.cpp -quiet -dumpbase switchbug.c -version -o /usr/tmp/cca12363.s
GNU C version 1.42 (sparc) compiled by GNU C version 1.42.
default target switches: -mfpu -mepilogue
switchbug.c: In function main:
switchbug.c:7: parse error before `}'


gcc 2.2.2 sez:
leisner@annapurna$ gcc -v -c switchbug.c
Reading specs from /usr/gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix switchbug.c /usr/tmp/cca12366.i
GNU CPP version 2.2.2 (sparc)
 /usr/gnu/lib/gcc-lib/sun4/2.2.2/cc1 /usr/tmp/cca12366.i -quiet -dumpbase switchbug.c -version -o /usr/tmp/cca12366.s
GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o switchbug.o /usr/tmp/cca12366.s


Since when is the above program valid?


Marty    leisner.henr801c@xerox.com 
 	 leisner@eso.mc.xerox.com 
          Member of the League for Programming Freedom 
 The Feynman Problem Solving Algorithm:
 1) Write down the problem
 2) Think very hard
 3) Write down the answer     -- Murray Gell-mann


Newsgroups: gnu.gcc.bug
From: mikew@kpc.COM
Subject: Bug in DEC Alpha/AXP backend for gcc.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 09:09:49 GMT

In the output_prolog function in config/alpha.c file in gcc-2.3.1,
the sequence "\tadd $30,$28,$15\n" is output. Unfortunately add is
not a legal instruction.  This should probably be an addq instruction.


Newsgroups: gnu.gcc.bug
From: klh@us.oracle.COM (Ken Harrenstien)
Subject: "long long" support
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 16:31:41 GMT

I'm interested in using the "long long" datatype on a SunOS Sparc (to
help with my PDP-10 emulator) but there appear to be some missing
pieces that the 2.0 documentation doesn't mention.

- How do you specify a "long long" integer constant?  Standard C provides
for constructs like "1L"; what's the equivalent for long long?  There
is no explicit assurance that an otherwise normal constant will be
given the extended datatype if its value is larger than can be
accomodated by a long.

- There seems to be no supporting <limits.h> entry for a long long.
The form of this naturally depends on the previous point.

Thanks,
--Ken

Newsgroups: gnu.gcc.bug
From: Colin.DEan@smallworld.co.uk (Colin Dean)
Subject: Installation bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 10:17:53 GMT

Author of this bug report
-------------------------

Colin Dean,
Smallworld Systems Limited,
13-15 Newmarket Road,
Cambridge CB5 8EG,
England.

Fax:   +44 223 300692
Email: Colin.Dean@Smallworld.co.uk

20th November 1992

Summary
-------

gcc version 2.3.1, copied by ftp from /pub/gnu/gcc-2.3.1.tar.Z
at prep.ai.mit.edu on 17th November 1992 at around 08:00 GMT.

Built on SPARCstation 2 running SunOS 5.0 (Solaris 2.0) in sub-directory
sparc-sun-sunos5.0 using `../configure sparc-sun-sunos5.0'

The installation stage of the build fails because instead of copying
from `cc1' to `/usr/local/lib/gcc-lib/sparc-sun-sunos5.0/2.3.1/cc1'
it tries copying the latter to `cc1/cc1', and similarly for other
files installed via the Solaris 2 `install' command.

Workaround
----------

Create an executable script called `install' containing

	#! /bin/sh
	cp $2 $3

and have its directory in your PATH before the standard directories
when doing `make install ...'.

Newsgroups: gnu.gcc.bug
From: stu@digtec.dtro.e-technik.TH-darmstadt.DE (Stefan Ullrich)
Subject: potential gcc-error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 19:05:17 GMT

Dear Sirs,

this a bug report to gcc-2.3.1.

It is a little bug we found in the gcc-2.3.1. It causes no errors
during programm execution but is a little bit confusing since you get a
warning from the compiler.

The problem is that gcc-2.3.1 doesnot accept without warning the
smallest possible integer for a signed long int if it is written in
decimal (-2147483648).  It accepts the same value as hex number
(0x80000000). It also accepts the int number (-2147483647) without
warning. We havenot found any problems during execution.

We wrote a little programm to demonstrate the behaviour of gcc-2.3.1.
This is the little programm called `example.c':

> #include <stdio.h>
>
>
> int main(void){
>
>   long int i,j;
>
>   i = -2147483648;
>   j = 0x80000000;
>   printf("\nmax_neg_dez : %d", i);
>   printf("\nmax_neg_hex : %d\n\n", j);
>   return;
> }

This the compiler call:

> gcc -o example example.c

This is the error message that was produced by gcc:

> example.c: In function `main':
> example.c:8: warning: integer constant is so large that it is unsigned

This is the ouput produced by `example':

>
> max_neg_dez : -2147483648
> max_neg_hex : -2147483648
>

We hope that this bug report will help to improve the new release of gcc.

Many thanks to all who worked on this compiler. It is a great advance
for our work.

Newsgroups: gnu.gcc.bug
From: Colin.DEan@smallworld.co.uk (Colin Dean)
Subject: Build bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 10:19:50 GMT

Author of this bug report
-------------------------

Colin Dean,
Smallworld Systems Limited,
13-15 Newmarket Road,
Cambridge CB5 8EG,
England.

Fax:   +44 223 300692
Email: Colin.Dean@Smallworld.co.uk

20th November 1992

Summary
-------

gcc version 2.3.1, copied by ftp from /pub/gnu/gcc-2.3.1.tar.Z
at prep.ai.mit.edu on 17th November 1992 at around 08:00 GMT.

Built on SPARCstation 2 running SunOS 4.1.1 in sub-directory
sparc-sun-sunos4.1.1 using `../configure sparc-sun-sunos4.1.1'

The build stage `make stage2' issues an `mv' command whose source
file list includes both `*.o' and several explicit object files
such as `crt1.o'.  Obviously, the explicit files cannot be moved
because they've already been moved by the wildcard match, and
so `make' indicates an error.  This may happen for stage 1 too,
I didn't notice.

Workaround
----------

None needed: this error can be ignored: the build continues.

Newsgroups: gnu.gcc.bug
From: gskalla@garm.informatik.uni-osnabrueck.de (Gernot Skalla)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 17:32:20 GMT

Dear Ladies and Gentlemen,

The last few days I tried to compile a program
using Light Weight Processes with 'gcc'.
We are running SunOS 4.1.2 and gcc-2.2.2 on Sparc ELCs.
Are there any known problems?
Is it a bug? In 'gcc'? In the lwp-library?

This is the program:
$ cat lwptest.c
#include <stdio.h>
#include <lwp/lwp.h>

#define MAXPRIO 10

main ( argc, argv )
int     argc;
char    **argv;
{
        int prio, max ;

        (void) pod_setmaxpri (  MAXPRIO );
        prio = lwp_setpri ( SELF, MAXPRIO );
        max  = pod_getmaxpri();
        printf ("MAXPRIO=%d priority=%d\n", max, prio);
        prio = lwp_setpri ( SELF, MAXPRIO );
        printf ("MAXPRIO=%d priority=%d\n", max, prio);
}

$ cc -o lwptest.cc lwptest.c -llwp
$ gcc -o lwptest.gcc lwptest.c -llwp
$ lwptest.cc
MAXPRIO=10 priority=10
MAXPRIO=10 priority=10
$ lwptest.gcc
MAXPRIO=10 priority=1
MAXPRIO=10 priority=10

The manual on 'pod_setmaxpri' tells me:
	"...By using pod_setmaxpri() before any other LWP
         primitives, you can ensure that main will receive the same
         priority as the argument to pod_setmaxpri()."

and on 'lwp_setpri':
	"lwp_setpri() returns the previous priority on success. On
	 failure, it returns -1."

I just cannot figure out, why I have to set the priority explicitly,
when using 'gcc'.

Any hints would be appreciated.
Sincerely
	Gernot Skalla

Newsgroups: gnu.gcc.bug