HDTenEightyP/NetNews huggingface dataset:
From: joost@cadlab.CAdlab.DE (Michael Joosten)
Subject: Lazy archiving with GNU make
Reply-To: joost@cadlab.cadlab.de
Organization: CADLAB, Paderborn, FRG
Distribution: gnu
Date: Sat, 5 Sep 1992 18:49:52 GMT

Hello,

I've stumbled now for days to teach make-3.62 a "lazy archiving" style. I know
that the default rule "(%): %" works like a charm, but....

The situation is as follows: sources are on a (normally overloaded) NFS
server, source type is C++ for cfront -> HUGE objects with -g and I want to
avoid letting unused ".o" files lying around. The problem with the default
rule is that it runs "ar" after every compilation instead of waiting until all
objects are made and "ranlib" is triggered. The library is ca. 2MB large and
each ".o" has 100-200KB. Especially with the SGI Irix "ar" (System V, bah!)
the archiving of last files takes three times as much as the compilation
proper!

What I've in mind can easily achieved with a System V make:

.c.a:
        $(CC) -c $(CFLAGS) $<

libtest.a       : libtest.a(stacks.o) libtest.a(fifos.o) libtest.a(adt.o)
        ar rv $@ $?
        rm $?

libtest.a(fifos.o):     fifos.c
libtest.a(adt.o):       adt.c adt.h
libtest.a(stacks.o): stacks.c adt.h

An equivalent GNUmakefile looks like this:
(%.o): %.c
        $(CC) -c $(CFLAGS) $<

libtest.a       : libtest.a(stacks.o) libtest.a(fifos.o) libtest.a(adt.o)
        ar rv $@ $?
        rm $?


libtest.a(fifos.o):     fifos.c
libtest.a(adt.o):       adt.c adt.h
libtest.a(stacks.o): stacks.c adt.h

But this does not work due to two reasons:
1) $? is evaluated to "libtest.a(adt.o) libtest.a(stacks.o)" instead of
   "adt.o stacks.o". Furthermore, this violates POSIX .2 and XPG4.

2) Even if I would fix this bug, GNU make apparently tries to be very fussy
   because the second rule is not run at all! Seems that make checks if the
   library has been modified (mtime?) - a "make -n" at least *prints* the
   "ar" command.

While the first bug seems to be easy to fix (set_file_variables() in
commands.c), I'm not sure if the latter is deliberate decision or a glitch.

I don't want to use SysV-make, because the subsystem is supposed to run on a
variety of platforms and I need some other features like a working VPATH (hear
me, Sun? 8-). 

Or does anybody have a good workaround (except keeping the objects lying
around?) Help !!

Michael




--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Newsgroups: gnu.utils.bug
From: jtt@pizza.cs.columbia.edu (James Tanis)
Subject: Re: GNU Finger 1.35 .fingerrc problem with restricted shell
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 14:58:20 GMT

>>>>> On Wed, 9 Sep 92 23:04:55 EDT, ezk@chestnut.cs.columbia.edu (Erez "HWank1" Zadok) said:

	ez> Our serverhost is one which some users are not allowed to login.
	ez> Those users are allowed to login to all other hosts in our
	ez> domain.  We do this by setting up NIS netgroups.  On the
	ez> restricted host we have at the end of /etc/passwd:

	ez> 	+::0:0:::/bin/restricted

	ez> which prints a message telling them they cannot login to this
	ez> restricted host, and exits.  On all of the other machines we
	ez> have

	ez> 	+::0:0:::

	ez> which lets those users a local login.

	ez> If such a restricted user on that host has a .fingerrc file, all
	ez> they get when anyone fingers them is the output from
	ez> /bin/restricted, because that is the shell that is exec-ed in
	ez> the maybe_exec_as_user() function.  I had to hack it so that if
	ez> they have a restricted shell, but are valid uses on our system,
	ez> and have a .fingerrc file, finger will at least execute /bin/sh
	ez> for their .fingerrc.

	ez> Erez.

Although I wasn't able to get this idea working quickly, I would like to try
it sometime when I'm not exec'ing your environment on .fingerrc.  Do you
think that someone could arrange a login on cs by writing a .fingerrc

exec /bin/ksh

and then fingering user@cs?  

/jtt
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Newsgroups: gnu.utils.bug
Subject: (none)
Date: 7 Sep 92 10:06:44 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Subject: cpio-1.5 on Mach/386, ESIX Sys V.4, and NeXT

configure; make

## runs ok up to

gcc -O -g -I. -DSIGTYPE=int -c xstrdup.c
In file included from xstrdup.c:21:
/usr/include/strings.h:51: warning: conflicting types for built-in function `strlen'
Make:  Don't know how to make #.  Stop.

## apparently the line from Makefile.in
@LIBOBJS@ @ALLOCA@
## is not correctly expanded by configure (it is blank in Makefile).
Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: binutils-2.0 vs. Am29000
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 19:22:25 GMT

Is the 2.0 release of binutils meant to include all of the current Cygnus work
on 29k? I tried it out (configure sun4 -target=ebmon29k) and the binutils
(objdump,nm at least) work fine but I have problems with the linker.

ld -r complains about "Warning, can't find entry symbol start, defaulting to 
00000000" and dumps core. ld works fine in the normal (absolute output) mode.

With the following patch to ld/ebmon29k.sc-sh ...

*** ebmon29k.sc-sh      Wed Sep  9 12:11:59 1992
--- ebmon29k.sc-sh~     Mon Mar  2 14:22:37 1992
***************
*** 1,6 ****
  cat <<EOF
  OUTPUT_FORMAT("${OUTPUT_FORMAT}")
! ${RELOCATING+ENTRY(start)}
  
  SECTIONS {
    .text ${RELOCATING+${TEXT_START_ADDR}} : 
--- 1,6 ----
  cat <<EOF
  OUTPUT_FORMAT("${OUTPUT_FORMAT}")
! ENTRY(start)
  
  SECTIONS {
    .text ${RELOCATING+${TEXT_START_ADDR}} :



... the complaint about "start" goes away but it still aborts and dumps core:


(gdb) i s
#0  0xf775c120 in ?? ()
#1  0x219e8 in coff_write_relocs (...) (...)
#2  0x2312c in coff_write_object_contents (...) (...)
#3  0x1484c in bfd_close (...) (...)
#4  0xc2d0 in main (...) (...)

Any ideas? Did my previous patches to the old Cygnus 29k ld get incorporated
into ld-2.0 ?



Andrew Smith
SynOptics Communications Inc.


Newsgroups: gnu.gcc.bug
From: klute@tommy.informatik.uni-dortmund.de (Rainer Klute)
Subject: Re: problems compiling X11R5 PL17 with gcc 2.2.2 [sun4, SunOS 4.1.2]
Organization: CS Department, Dortmund University, Germany
Distribution: gnu
Date: Tue, 15 Sep 1992 10:28:31 GMT

In article <9209141908.AA03141@phantom.cislabs.pitt.edu>,
qralston@cislabs.pitt.EDU (James Ralston Crawford) writes:
|> 
|> gcc -fpcc-struct-return -c -O2    -I../../.      gram.c
|> In file included from twm.h:297, from gram.c:44:
|> /long_gcc_path/include/stdlib.h:29: conflicting types for `malloc'
|> gram.c:1: previous declaration of `malloc'
|> /long_gcc_path/include/stdlib.h:33: conflicting types for `realloc'
|> gram.c:1: previous declaration of `realloc'


The problem stems from the broken SunOS yacc which prepends the generated
code with non-ANSI definitions for malloc() and realloc(). The following
patch to twm's Imakefile "fixes" the problem by brute force:


*** /tmp/RCSAa24446     Tue Sep 15 12:23:32 1992
--- mit/clients/twm/Imakefile   Thu Aug 13 18:18:07 1992
***************
*** 32,41 ****
--- 32,48 ----
  ComplexProgramTarget(twm)
  InstallNonExecFile(system.twmrc,$(TWMDIR))
  
+ #if HasGcc2 && defined (SunArchitecture)
  gram.h gram.c: gram.y
        yacc $(YFLAGS) gram.y
+       sed -e 's/^extern char \*malloc(), \*realloc();//g' y.tab.c >gram.c
+       $(MV) y.tab.h gram.h
+ #else
+ gram.h gram.c: gram.y
+       yacc $(YFLAGS) gram.y
        $(MV) y.tab.c gram.c
        $(MV) y.tab.h gram.h
+ #endif
  
  clean::
        $(RM) y.tab.h y.tab.c lex.yy.c gram.h gram.c lex.c deftwmrc.c 


-- 
  Dipl.-Inform. Rainer Klute      klute@irb.informatik.uni-dortmund.de
  Univ. Dortmund, IRB
  Postfach 500500         |)|/    Tel.: +49 231 755-4663
D-W4600 Dortmund 50       |\|\    Fax : +49 231 755-2386

Newsgroups: gnu.gcc.bug
From: francour@ia3.u-strasbg.fr (DEA)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 18:11:38 GMT

Bugs in GCC 2.2


I used GCC version 2.2 (for my own use only) for several
months, and discovered a problem when passing parameters
notably float parameters. Just look at the two following
small programs, they seems to be similiar, compile them,
run them, compare their result and drop me a line if I'm
wrong.


/* file f1.c */


void print_args(float, float, float);

main()
{
 print_args(1.0, 67.89, 3.141592654);
}

/* end of file f1.c */


/*file f2.c */

#ifdef NORM 

void print_args(float a, float b, float c)
{
 printf("a = %f  b = %f   c = %f\n", (double)a, (double)b, (double)c);
}

#else

void print_args(a, b, c)
float a, b, c; 
{
 printf("a = %f  b = %f   c = %f\n", (double)a, (double)b, (double)c);
}
#endif

/* end of file f2.c */


/*********** Now these are the two programs *******/

program 1: gcc -o prog1 f1.c f2.c
program 2: gcc -o prog2 -DNORM f1.c f2.c

Now run prog1 as result I've got "a = 0.007813  b = 50.123871   c = 0.000000"
but not "a = 1.0  b = 67.89  c = 3.141592654" expected.
prog2 give me the correct result.


Please give me answer if you can understand this.

Friendly,
FRANCOURT Daniel
francour@ia3.u-strasbg.fr

Newsgroups: gnu.gcc.bug
From: kburton@iowa.UUCP (Kevin Burton)
Subject: RE: Building glibc-1.03 BUG Report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 14:41:41 GMT

>        Having beaucoup problems building the glibc-1.03 on a Sun sparc.
>        The sequence is:
>
>        sh configure sun4
>        edited Makeconfig file, commenting out lines 92,93,94 as I'm using 
>                gcc 2.2.2
>        make
>		.
>		.
>		.
>make: fopen: sun4/depend-: No such file or directory
>(for file in sysdep.dep set-init.dep version.dep start.dep; do echo "include 
>sun4/$file"; done) > sun4/depend-
>make: fopen: sun4/sysdep.dep: No such file or directory
>make: fopen: sun4/set-init.dep: No such file or directory
>make: fopen: sun4/version.dep: No such file or directory
>make: fopen: sun4/start.dep: No such file or directory
>cd sun4; gcc -pipe sysdeps/unix/bsd/make-local_lim.c -o make-local_lim
>/usr/local/lib/gcc-lib/sparc-sun-sunos4.2/2.2.2/cpp: 
>sysdeps/unix/bsd/make-local_lim.c: No such file or directory
>make: *** [sun4/make-local_lim] Error 1

It is not much help but I am having a simliar problem with glibc-1.04 on
a Sparcstation 1. The build does not even start. I get the following
output.

	{kburton@iowa(2.2):7} gmake MAKE=gmake
	gmake: fopen: sysdep.dep: No such file or directory
	gmake: fopen: munch-init.dep: No such file or directory
	gmake: fopen: version.dep: No such file or directory
	gmake: fopen: start.dep: No such file or directory
	gmake: *** No way to make target `start.dep'.  Stop.

This was only after I edited the Makefile to take out a comment that make
would not understand. 

-
This is not an official statement of Noran Instruments. No warranty is
expressed or implied. The information included herein is not to be construed
as a committment on Noran's part.

Kevin Burton
Noran Instruments				voice: (608) 831-6511 x317
2551 West Beltline Highway, Room 532		  FAX: (608) 836-7224
Middleton, WI 53562				email: kburton@noran.com

Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: gcc-2.2.2 -O2 and non-optimal code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 14:32:40 GMT

| We are using gcc as a cross-compiler, the host is sparc and the target is mips.
| The target assembler is a modified version of the OSF assembler, ours produces
| coff instead of rose object format.  In the following test case gcc does not
| produce very good code even with the optimizer turned on.  With proper code
| scheduling and register allocation all of the nops could be eliminated.
| 
| 		Marvin Wyckoff
| 		marvinw@orca.wv.tek.com
| 		503-685-2985

I sent mail to Marvin, and forgot to send it to the mailing list.  The
short answer is fixed in GCC 2.3.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

Newsgroups: gnu.gcc.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: "cin" bug?
Organization: U. C. Berkeley
Distribution: gnu
Date: Tue, 15 Sep 1992 20:56:21 GMT

In article <9209150106.AA15049@brain.diag.amdahl.com> brm30@diag.amdahl.COM (Brian Moyle) writes:
>Hello,
>
>     I'm fairly new to C++ programming, but I've run into a little
>problem that seems to qualify as a bug.  The following program was 
>taken from The Waite Group's, "C++ Programming," by John Berry,
>copyright 1988 (fourth printing -- 1990).  On page 44, the following
>paragraph provides an explanation of how the 'while' loop is exited:

Brian, I'm about to flame John Berry.  This is not directed at you.

This has got to be the worst C++ book I have ever seen.  Run, not walk,
away from it.  Do your best to forget whatever it said.  Mr. Berry
is clearly not competent to write a C++ text.  Of the 10 or so C++
books I have reviewed, this one is by far the worst.  The fact that
it's now in its fourth printing gives evidence to the old adage: there's
a sucker born every minute.

The program in question is incorrect; you'll get the same symptoms
if you build it with cfront.  He is relying on a stupid hack, assuming
that if he says

	double x, y;
	char op;

that if he then says

	cin >> x >> opr >> y;

and you type "exit", the x character will wind up in "opr".  But that
is not how streams work!  A double cannot begin with "e", therefore
nothing is consumed from cin.  The e remains on the input, and opr
does not change.  The only way to read more stuff from cin is to clear
its error flag.  Perhaps an early streams implementation he used happened
to work this way.  But no competent programmer would ever rely on such
an accidental feature.

Even if this program did happen to work, Mr. Berry should be condemned
for teaching beginners to program this way.  What an ugly, disgusting
kludge.




--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: built-in conflict resolved, more or less
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 06:51:30 GMT

| OK, I understand the situation better now:
| 
| The ANSI standard for size_t is long unsigned int, and the seq386.h header
| file does not redefine SIZE_TYPE to int to agree with the system headers.

Umm, the ANSI standard does NOT specify size_t is long unsigned.  All
it specifies is that it is an unsigned type, large enough to hold any
sizeof expression.

| However, libg++/utils/gen-params checks the system headers before the gcc
| headers to find out what size_t is, so it finds the typedef of size_t to
| int in sys/types.h.
| 
| There are two solutions I see:
| 1) Redefine SIZE_TYPE in config/seq386.h to agree with the system headers.
| 2) Alter gen-params to use the definition of size_t in the gcc headers.
| 
| Which is preferable?

#1 is generally preferable.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

Newsgroups: gnu.gcc.bug
From: marvinw@intrepid18.wv.tek.COM
Subject: gcc-2.2.2 -O2 and non-optimal code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 00:09:40 GMT

We are using gcc as a cross-compiler, the host is sparc and the target is mips.
The target assembler is a modified version of the OSF assembler, ours produces
coff instead of rose object format.  In the following test case gcc does not
produce very good code even with the optimizer turned on.  With proper code
scheduling and register allocation all of the nops could be eliminated.

		Marvin Wyckoff
		marvinw@orca.wv.tek.com
		503-685-2985

---------------------------------------------------------------------------
intrepid% uname -a
SunOS intrepid 4.1A.1 4.1.1 sun4

intrepid% cat config.status
#!/bin/sh
# GCC was configured as follows:
../configure --host=sparc --target=mips-mips-bsd

intrepid% ./gcc -B./ -S -O2 -msoft-float -g m.c
m.c:1137: warning: static declaration for `miRoundCap' follows non-static

---------------------- sched.c ----------------------------------
char arr[10];
char n;
main()
{
	n = arr[0];
	arr[0] = arr[3];
	arr[3] = n;
	n = arr[2];
	arr[2] = arr[1];
	arr[1] = n;
}
---------------------- sched.s ----------------------------------
	.file	1 "sched.c"

 # GNU C 2.2.2 [AL 1.1, MM 19] BSD Mips compiled by CC

 # Cc1 defaults:

 # Cc1 arguments (-G value = 8, Cpu = default, ISA = 1):
 # -mgas -mgpopt -quiet -dumpbase -O2 -o

gcc2_compiled.:
	.text
	.align	2
	.globl	main

	.comm	arr,16

	.comm	n,8

	.text

	.loc	1 4
	.ent	main
main:
	.frame	$sp,0,$31
	.mask	0x00000000,0
	.fmask	0x00000000,0
	la	$2,arr
	.set	noreorder
	lbu	$3,0($2)
	nop
	.set	reorder
	sb	$3,n
	.set	noreorder
	lbu	$3,arr+3
	nop
	.set	reorder
	sb	$3,0($2)
	.set	noreorder
	lbu	$3,n
	nop
	.set	reorder
	sb	$3,arr+3
	.set	noreorder
	lbu	$3,arr+2
	nop
	.set	reorder
	sb	$3,n
	.set	noreorder
	lbu	$3,arr+1
	nop
	.set	reorder
	sb	$3,arr+2
	.set	noreorder
	lbu	$3,n
	nop
	.set	reorder
	sb	$3,arr+1
	j	$31
	.end	main

Newsgroups: gnu.gcc.bug
From: jet@nas.nasa.gov (J. Eric Townsend)
Subject: bug in 2.2.2 sys-types.h?
Organization: Numerical Aerodynamic Simulation, NASA Ames
Distribution: gnu
Date: Thu, 10 Sep 1992 19:18:45 GMT

line 164 of sys-types.h reads:

typedef va_list;

I thought that typedef always required at least *two* tokens, one of
the type, and one of the new typedef'd name.

comments?  (other than "C", "/* */", etc... :-)
--
             J. Eric Townsend --  jet@nas.nasa.gov -- 415.604.4311
                              '92 R100R, DoD# 0378
 "Nude wheelies are probably the ultimate in squidliness."  -- someone at
                                                          Lissa's party

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  floating point accuracy???
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 08:13:23 GMT

This is a problem with the backend I believe.  If it is not, then the
problem in the front-end has been fixed.

On a sun4 I now get:

pow (4,6)= 4096.000000
pow (4,6)= 4096

> Message-Id: <m0mUHwh-000AWzC@sophists.com>
> Date: Mon, 14 Sep 92 11:02 EDT
> From: lewis@sophists.com (Lewis G. Pringle)
> To: bug-gcc@prep.ai.mit.edu
> Reply-To: lewis@sophists.com

> /*
>  * I'm not sure if this is a bug, a feature, or a configuration
>  * problem, but the results of these math calls were a bit
>  * surprising to me.
>  *
>  * This code we compiled with:
>  *	gcc -o fred x.cc -lm
>  * on a 68k box running a sysVr2.2 variant using gcc 2.2.1.
>  *
>  * The output was:
>  *	pow (4,6)= 4096.000000
>  *	pow (4,6)= 4095
>  */

> #include <math.h>
> #include <stdio.h>

> main ()
> {
>  printf ("pow (4,6)= %f\n", pow (4,6));
>  printf ("pow (4,6)= %d\n", ((unsigned) pow (4,6)));
> }

Newsgroups: gnu.gcc.bug
From: jack@solucor.UUCP (Jacques Gelinas)
Subject: gcc 2.2.2 on hpux generate bad assembly code
Organization: solucorp
Distribution: gnu
Date: Sat, 12 Sep 1992 05:14:59 GMT

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.

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

The problem seems to happen with more than 4 parameters and
a combination of double and integer parameter.


I have ordered an assembly language reference manual. Maybe someone
have seen these problems. Any suggestion ?

Does a PA-RISC 1.1 can do single precision computation directly ?

Thanks in advance ?

-- 

--------------------------------------------------------
Jacques Gelinas (jack@solucor.uucp)
Today it's my opinion

Newsgroups: gnu.gcc.bug
From: john@feith1.UUCP (John L. Wehle)
Subject: Patch01 to gcc version 2.2.2 configuration files for we32000
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 00:20:30 GMT

Hello,

Here is a small patch which corrects the definition of SIZE_TYPE
for the AT&T we32k.  Thanks go to carlson@tis.llnl.gov (John Carlson)
for finding this.

Sincerely,
John Wehle
john@feith1.uucp
---------------------------------------------------------------------------
*** config/we32k.h.original	Wed Sep  9 13:56:02 1992
--- config/we32k.h	Wed Sep  9 13:54:30 1992
***************
*** 627,632 ****
--- 627,635 ----
  /* Define this as 1 if `char' should by default be signed; else as 0.  */
  #define DEFAULT_SIGNED_CHAR 0
  
+ /* Specify the size_t type.  */
+ #define SIZE_TYPE "unsigned int"
+ 
  /* Max number of bytes we can move from memory to memory
     in one reasonably fast instruction.  */
  #define MOVE_MAX 4


Newsgroups: gnu.gcc.bug
From: rjc@devo.unify.COM
Subject: bug in the interactions of gcc-2.2.2 and gas-1.38.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 01:51:00 GMT

I submitted a report for this bug to bug-gnu-utils yesterday, but am
not really satisfied that this is entirely a gas bug.

Software: gcc-2.2.2 (configure i386-sequent-bsd --gas --with-gnu-ld)
          [ld is from g++-1.39.  the fact that binutils-2.0 won't build
           for this platform "out of the box" is another matter.]
Hardware: Sequent Symmetry running DYNIX 3.0.12 in the ucb universe.

Bug:      While building the stage2 compiler, genattr cores in
          init_rtl().  The problem appears to be that the stage1
          compiler is (for a reason unknown to me) putting ".align 2"s
          in the middle of the assembly generated for the function
          init_rtl() in rtl.c.

	.align 2
.globl _init_rtl
_init_rtl:
	pushl %ebp
	movl %esp,%ebp
	subl $32,%esp
	pushl %edi
	pushl %ebx
	xorl %edx,%edx
	.align 2           <---------------- this guy right here.
L201:
	movl _rtx_format(,%edx,4),%edi
	xorb %al,%al
	movl $-1,%ecx

	  The system assembler correctly fills the void with "nop"s,
          but gas is filling the void with zeros.  Obviously gas has a
          bug, but I am left scratching my head and wondering why gcc
          felt it had to align the label (since gcc-1.39 did not do
          this).  I have built the compiler without gas, but I need
          gas to handle the stabs generated by g++.  I am open to
          patches and/or suggestions on how to proceed...  :-)

--
Ronald Cole           +----------------------+  internet: rjc@unify.com
Software Engineer II  | This space for rent. |  uucp:     uunet!unify!rjc
Unify Corporation     +----------------------+  voice:    +1 916 928 6238
          "THE BILL OF RIGHTS --- Void where prohibited by law"

Newsgroups: gnu.gcc.bug