HDTenEightyP/NetNews huggingface dataset:
From: mitch@.UUCP (Mitchell N. Perilstein)
Subject: conversion from literal to double in 2.1
Organization: CAD Language Systems, Inc.
Distribution: gnu
Date: Wed, 30 Dec 1992 21:37:21 GMT

Conversion from int to double is working, but conversion from a literal
to a double is broken. gcc 2.1 on Sparc SunOS 4.1.2 and on RISC Ultrix
4.2 produces an unexpected result:

    convert int to double: -2147483648 -> -2147483648.000000
    convert lit to double: -2147483648 -> 2147483648.000000

I expected
    
    convert int to double: -2147483648 -> -2147483648.000000
    convert lit to double: -2147483648 -> -2147483648.000000

The vendor /bin/cc gave the second result on both platforms. Here is the
code. 

#define INT_MIN (-2147483648)	/* - (2^31) */

int main()
{
    double from_int, from_literal;
    int i;

    i = INT_MIN;
    from_int = i;
    printf("convert int to double: %d -> %f\n", i, from_int);

    from_literal = INT_MIN;
    printf("convert lit to double: %d -> %f\n", INT_MIN, from_literal);
}

Respectfully,
---
 Mitchell N. Perilstein   CAD Language Systems, Inc.   410-992-5700 x225 
 Member, League for Programming Freedom.  Mail lpf@uunet.uu.net for info.

Newsgroups: gnu.gcc.bug
From: mybg@cs.huji.ac.il (Michael Ben-Gershon)
Subject: Bug Report
Organization: Gnus Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 12:19:28 GMT

Date:       30 Dec 1992
Version:    2.3.3
Machine/OS: Acorn RISCiX

I am presently working actively on fixing gcc for RISCiX (UNIX for the ARM
processor).  Although included in the gcc distribution it is not yet
complete, but is almost there :-) .  I need to allow for 3 mutually exclusive
flags to be set, setting which 'compilation environment' the compiled program
has been designed to work with: BSD, XOPEN or strict ANSI conformance.  This
facility is allowed for in RISCiX, and is provided by the 'standard' RISCiX
compiler.

I have implemented these flags as -menv-BSD, -menv-XOPEN and -menv-strict.
These can be tested by the specs in gcc.c, to ensure that only one is given.
After 'as' has compiled an object, it is then post-processed to insert
debugging info into the object (the RISCiX assembler does not support stabs
directives) like the MIPS version.  Following this, a system-provided
utility, symrename, is called to rename any symbols according to whether
BSD, XOPEN or strict was set, as described above.

What I hoped to do was to implement the test for only one -menv option via
CPP_SPEC.  This is inserted into the specs by gcc at the point marked by %C.
However, when an error is generated (by %e) in specs included by %C, the
compilation continues.  This is not the case when the error is generated
in the specs themselves.  This is annoying, because I had hoped to avoid
having to rewrite the specs and put the RISCiX version in a big #ifdef
just because of a few extra bits! As it is, 90% of the specs are identical,
but are duplicated to avoid this problem.

An additional problem is that there is no spec which returns the file name
of the source sent to the assembler.  If an assembler  post-processor is used,
then the spec will not work both for normal compiles and compiles of .s files.
For normal compiles, the spec is %g.o.  However, if a .s file is 'compiled',
then %g.o invents a new temporary filename, rather than giving the equivalent
of %i (the source filename).

Finally, because the assembler post-processor needs to read the assembler
source file it cannot be piped into the assembler, but must be saved to a
temporary file first.  However, that does not mean that I want to stop pipes
being used to transfer stuff from cpp to cc1 etc.  There does not seem to be
a way of doing this without removing the '|' from the line before the call to
'as'.  However, this would mean having a special version of the specs for
RISCiX, which (although I have done it that way for the moment) is not really
desirable.

Michael Ben-Gershon
mybg@cs.huji.ac.il

Newsgroups: gnu.gcc.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: GCU CPP fails to set macro as predefined if it is a predefinition.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 17:16:30 GMT

gcc version: gcc-2.3.1

machine: sparc-sun-sunos4.1.1

Brief:

  Those macros that are predefined, such as 'sparc 1', fail to have
  their defn->predefined field set correctly.

Description:

  In the function 'create_definition' in the file cccp.c there is the
  following lines:

    /* OP is null if this is a predefinition */
    defn->predefined = !op;

  Unfortunately, op does not come in as null when the macro is a
  predefinition.

  Here is the back trace:

    (gdb) bt
    #0  create_definition (buf=0xf7fff680 "sparc 1", limit=0xf7fff687 "", op=0x20fa8) at cccp.c:4772
    #1  0xcc94 in do_define (buf=0xf7fff680 "sparc 1", limit=0xf7fff687 "", op=0x20fa8, keyword=0x1c380) at cccp.c:4808
    #2  0x16280 in make_definition (str=0xf7fff70a "sparc", op=0x20fa8) at cccp.c:8333
    #3  0x3ba0 in main (argc=2, argv=0xf7fff7fc) at cccp.c:1399
    (gdb) 

  It appears to me that main() should call make_definition() with its
  second argument as null when doing the standard defines, as shown
  below.

  /* Do standard #defines and assertions
     that identify system and machine type.  */

  if (!inhibit_predefs) {
    char *p = (char *) alloca (strlen (predefs) + 1);
    strcpy (p, predefs);
    while (*p) {
      char *q;
      while (*p == ' ' || *p == '\t')
	p++;
      /* Handle -D options.  */ 
      if (p[0] == '-' && p[1] == 'D') {
	q = &p[2];
	while (*p && *p != ' ' && *p != '\t')
	  p++;
	if (*p != 0)
	  *p++= 0;
	if (debug_output)
	  output_line_command (fp, &outbuf, 0, same_file);
	/* make_definition (q, &outbuf); */
---->	make_definition (q, NULL);
	while (*p == ' ' || *p == '\t')
	  p++;


Tom


Newsgroups: gnu.gcc.bug
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Subject: Wrong line number info generated by GCC 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 18:56:00 GMT

The debugging info generated by GCC 2.2.2 treated the following two
lines as two lines:

  for (i = 0; i < 10; ++i)
    j += i;

The debugging info generated by GCC 2.3.1 thru 2.3.3 treats those two
lines as *ONE* line.  The debugger doesn't let one step into the body
of the loop, the GDB STEP command executes the entire loop.  Correct
debugging information is generated for the following rewritten code:

  for (i = 0; i < 10; ++i)
    {
      j += i;
    }

Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug
From: ler@lerami.lerctr.ORG (Larry Rosenman)
Subject: 2.3.3 amix bad float constant? FIXED
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 09:46:42 GMT

Larry Rosenman writes:
> I just ran into a bad float constant being generated by gcc 2.3.3
> configured for amix....
> 
> for the constant 1.15 2.3.3 generated:  0x2800c5865
> 
> 					  1.40.5 generated: 0x3ff2666666666666
> 
> the 2nd one is correct, the first one is some very small number...
> 
> any ideas ?
yup, I had "Fixed" m68k.c in the 2.2.? days when we had a problem 
outputting the floating operands.  I had mis-fixed it, and the diffs 
never fixed my "fixes"

I put the "current" m68k.c output for double constant operands and re-built cc1,
and all is well again.

Sorry for the spurious report.
> 
> I may have a bad copy of one or more of the config files....

-- 
Larry Rosenman                            Internet: ler@lerami.lerctr.org
ATT: +1 214-399-0210 (voice)  BIX: ler    UUCP: ..!utacfd.uta.edu!lerami!ler
US Mail: 900 Lake Isle Circle, Irving, TX 75060-7726

Newsgroups: gnu.gcc.bug
From: pab@cs.arizona.edu (Peter A. Bigot)
Subject: 2.3.3 fixincludes bug+patch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 05:30:54 GMT

There is a bug in fixincludes which arises given a certain configuration of
/usr/include.  We have /usr/include/X11 as a symlink to
/usr/X11R5/include/X11.  /usr/X11R5/include/X11 has several subdirectories
(e.g., phigs).  fixincludes as distributed detects these subdirectories when
building the subdirectories list of /usr/include, and creates them in the
LIB directory.  However, it then proceeds to delete the entire
${LIB}/include/X11 hierarchy and replace it with a symlink to
${LIB}/include/root/usr/X11R5/include/X11.  The subdirectories that were in
$LIB/include/X11 are not recreated.  As a result, when
/usr/include/X11/phigs/phigs.h is being fixed, the copy to
$LIB/include/X11/phigs/phigs.h fails since the phigs subdirectory doesn't
exist.

The following patch makes fixincludes duplicate the subdirectory creation in
the new root area.

--- fixincludes.orig	Fri Dec  4 17:49:22 1992
+++ fixincludes	Sat Jan  2 10:31:14 1993
@@ -177,6 +177,17 @@
 	      dirname=`echo $dirname | sed -e 's|[^/]*/||'`
 	    done
 	  fi
+          # Duplicate directory structure created in ${LIB}/$file in new
+          # root area.
+          for file2 in $files; do
+            if expr ${file2} : "${file}/.*" > /dev/null ; then
+              dupdir=${LIB}/root$x/`echo $file2 | sed -n "s|^${file}/||p"`
+#              echo "Duplicating from ${file}'s ${file2} to ${dupdir}"
+              if [ ! -d ${dupdir} ] ; then
+                mkdir ${dupdir}
+                fi
+              fi
+            done
 	  rm -fr ${LIB}/$file > /dev/null 2>&1
 	  ln -s ${LIB}/root$x ${LIB}/$file > /dev/null 2>&1
 	  treetops="$treetops $x ${LIB}/root$x"

--
                     Peter A. Bigot -- pab@cs.arizona.edu
          Dept. of Computer Science, University of Arizona, Tucson AZ
---------------------------- The current quote is: ----------------------------
 "That's all for now.  This is Miss Lidia, saying: 'Bye-bye'--and remember,
		 the better you look, the more you'll see."

-- 
                     Peter A. Bigot -- pab@cs.arizona.edu
          Dept. of Computer Science, University of Arizona, Tucson AZ
---------------------------- The current quote is: ----------------------------
 "That's all for now.  This is Miss Lidia, saying: 'Bye-bye'--and remember,
		 the better you look, the more you'll see."

Newsgroups: gnu.gcc.bug
From: eurdang@advtech.USwest.COM (Erik Urdang)
Subject: Re: RPC problem?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 17:06:08 GMT

Oops.

I've just learned that I was using an older version of gcc. The
problem has been resolved. Thank you.


Erik Urdang

Newsgroups: gnu.gcc.bug
From: meyering@cs.utexas.edu (Jim Meyering)
Subject: getting gcc to use ANSI ctype macros on SGIs
Keywords: SGI, Irix-4.0.5, gcc, ANSI, ctype macros
Organization: U of TX at Austin CS Dept
Distribution: gnu
Date: Mon, 21 Dec 1992 10:26:34 GMT

I noticed recently that cc (without -ansi) and gcc on SGIs running
irix-4.0.5 have ANSI ctype macros that aren't ANSI.  The problem is
that all macros but isascii are undefined for non-ASCII character codes.
E.g. compiled with `cc' this program aborts

  #include <ctype.h>
  main() {if (isprint (0377)) abort(); exit(0);}

With `cc -ansi' it exits normally.
The only difference I could see is that plain `cc' uses /usr/lib/crt1.o
and `cc -ansi' uses /usr/lib/acrt1.o.

I want gcc to get the ANSI ctype tables, so I changed the specs file
so that gcc uses acrt1.o.

So far, this is the only difference I know of -- other than what nm
told me: that a couple of entrypoints like `environ' are in crt1.o, but
not in acrt1.o.

Is there any reason not to make gcc use the ANSI start file?

-- 
Jim Meyering             | Member of the League for Programming Freedom
meyering@cs.utexas.edu   | Contact me or lpf@uunet.uu.net for more info.

Newsgroups: gnu.gcc.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Inlining varargs functions
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Mon, 21 Dec 1992 15:18:45 GMT

I want to write code like this:
#ifndef DEBUG_TRACE 
static void inline test_args()
{
}
#else
static void debug_trace( char *fmt, ...)
{
        va_list args;

        va_start(args, fmt);

        vfprintf(stderr, fmt, args);

        va_end(args);
}
#endif


where I have debug calls sprinkled in my code like:
        debug_trace("writing %x = %d\n", address, word);

I've never seen a clean way to do this (normally, it results in a series of macros, where
each macro has a certain number of arguments, etc...)

When I don't want debugging, a function appears, its null, and the compiler should be smart
enough to just leave it out...

In integrate.c, there's a function:
/* Zero if the current function (whose FUNCTION_DECL is FNDECL)
   is safe and reasonable to integrate into other functions.
   Nonzero means value is a warning message with a single %s
   for the function's name.  */

char *
function_cannot_inline_p (fndecl)
     register tree fndecl;


If the function is empty, it should always be safe to inline... 

Perhaps there should be a special case for this (how do I tell an empty function
from fndecl?  Is it safe to say:
	if(EMPTY(fndecl))
		return 0;

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.gcc.bug
From: shap@halifax.syncomas.com
Subject: Bug in config/i386bsd.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 00:12:00 GMT

Encountered in GCC versions: 2.2.*, 2.3, 2.3.*
Configuration:	configure -host=i386v4 -target=i386-bsd  (but see note below)

This is a pretty simple one.  When compiling i386bsd.h with a compiler which
is attempting to be pre-ansi compatible, stringification occurs.  This can
be verified with gcc by cd'ing to the config/ subdirectory of the GCC
distribution, and typing:

	gcc -Wtraditional -I. -I.. -E i386bsd.h > /dev/null

String replacement is definitely NOT wanted in these macros.

The problem is that the macro argument names appear within the strings.
Suggested solution is to rename the arguments from 'a' to 'aa', 'b' to 'bb',
etc.

Recommend that while you're there you check any other headers you think
might be suspect.

I'ld have sworn that I've reported this one before.

Note about the configuration: This problem was encountered on a private
configuration that is similar to i386-bsd (identical in all but name,
in fact, but it may not stay that way over time).


Jonathan S. Shapiro
Synergistic Computing Associates
shap@halifax.syncomas.com

Newsgroups: gnu.gcc.bug
From: istewart@dlvax2.datlog.co.UK (Ian Stewartson)
Subject: Problems with GCC 2.3.2 on Sparc System V.4 (part 1 of 3)
Reply-To: istewart@datlog.co.uk
Organization: Data Logic Ltd. (A Raytheon Company)
Distribution: gnu
Date: Wed, 23 Dec 1992 20:23:58 GMT

- Start of Problem Report -

GNU CC version:
	Reading specs from /usr/local/lib/gcc-lib/sparc-icl-sysv4/2.3.2/specs
	gcc version 2.3.2

Input files:				See parts 2 and 3.


Hardware:				ICL DRS 6000 (sparc)
					(I believe this is the reference
					 system for sparc V.4 ports from
					 USL).
OS Name:				ICL DN/NX
					(System V.4.0)
OS Version number:			Release 4.0 Level 6.02
Configure operands:			sparc-icl-sysv4
Modifications made to the compiler:	None.
Other Deviations:			None.

Problem 1:

When building the libg++ 2.3 libraries, the following errors are generated.
This is the output from the build, excluding the terimating aborts.

	gcc -O -g -save-temps -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c Obstack.cc
/usr/ccs/bin/as: "Obstack.s", line 298: error: redefinition of symbol ".L_E1221"
/usr/ccs/bin/as: "Obstack.s", line 313: error: redefinition of symbol ".L_E1296"
/usr/ccs/bin/as: "Obstack.s", line 328: error: redefinition of symbol ".L_E1297"
/usr/ccs/bin/as: "Obstack.s", line 1805: error: redefinition of symbol ".L_b20"
/usr/ccs/bin/as: "Obstack.s", line 2444: error: redefinition of symbol ".L_b26"
/usr/ccs/bin/as: "Obstack.s", line 2738: error: redefinition of symbol ".L_b28"
/usr/ccs/bin/as: "Obstack.s", line 3088: error: redefinition of symbol ".L_b30"
/usr/ccs/bin/as: "Obstack.s", line 3452: error: redefinition of symbol ".L_b32"
/usr/ccs/bin/as: "Obstack.s", line 3769: error: redefinition of symbol ".L_b34"
/usr/ccs/bin/as: "Obstack.s", line 4038: error: redefinition of symbol ".L_b36"

Problem 2:

If I attempt to re-build gcc using gcc by replace the value of the macro CC
in the makefile with gcc (at line 53), I get the following error:

	gcc  -DIN_GCC -DSVR4  -g   -o genextract \
	 genextract.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "gcc"@"alloca.o" in "cc"@?*) echo alloca.o ;; esac ` ` case "" in ?*) echo  ;; esac `   
Undefined			first referenced
 symbol  			    in file
alloca                              rtl.o
ld: genextract: fatal error: Symbol referencing errors. No output written to genextract

I thought alloca was handled internally by gcc.  Have I mis-understood
something; can you not rebuild the compiler with itself or is there another
problem?



Newsgroups: gnu.gcc.bug
From: srmorin@risky.ecs.umass.edu (Steven R Morin)
Subject: Compiling groff with gcc-2.3.2
Organization: University of Massachusetts, Amherst
Distribution: gnu
Date: Wed, 30 Dec 1992 21:21:01 GMT

Recently, I tried building groff-1.06 with gcc-2.3.2 on a DECStation
5000/240, Ultrix-4.2A with the following results:

Making all in include
Making all in libgroff
Making all in libdriver
Making all in libbib
Making all in groff
Making all in troff
Making all in tbl
Making all in pic
gcc -O -I. -I. -I../include -I./../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -
DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1 -DHAVE_CC_UNISTD_H=1 -D
STDLIB_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DHAVE_MMAP=1 -DHAVE_REN
AME=1 -DHAVE_SYS_SIGLIST=1 -DWCOREFLAG=0200 -g  -c object.cc
object.cc: In method `circle_object::circle_object (double)':
object.cc:1030: Internal compiler error.
object.cc:1030: Please report this to `bug-g++@prep.ai.mit.edu'.
*** Error code 1

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.
buzzer%

Has anyone come accross this before?  Any help would be appreciated.

Steve Morin

Newsgroups: gnu.gcc.bug
From: dorai@cs.rice.edu (Dorai Sitaram)
Newsgroups: gnu.gcc.help,comp.msdos.programmer
Subject: dosshell's Ctrl-Esc disabled by djgpp go32?  Fix?
Date: 21 Dec 92 16:30:07 GMT
Organization: Rice University, Houston

It appears that I cannot use dosshell's task swapping
mechanism when one of the active programs relies on the
DJGPP go32.  The Ctrl-Esc combination used to escape from an
running "active" program to the shell doesn't work.  Is
there a solution to this?  

Thanks in advance.

--d


-- 

dorai@cs.rice.edu      !    It may be that the gulfs will wash us down;
dorai@owlnet.rice.edu  !      it may be we shall touch the Happy Isles.
Newsgroups: gnu.gcc.help
From: wsaker01@starbase.spd.louisville.edu (Willard S. Akers)
Subject: Compiling GCC on SYSVr3.2 (att i386)
Date: Tue, 29 Dec 1992 06:19:04 GMT
Organization: University of Louisville
Keywords: stdio.h

I'm having problems making GCC on our AT&T SYSV machine.  I ran configure with
this system arguement: i386-att-sysvr3

Then I got the first stage compiled using cc.  Then when I tried to use xgcc to
compile itself, it gave me some symbol referencing errors in the link stage.
It could not find the symbols putc() and fseek().  It had the same problem when
it try to compile the enquire.c program.  I solved that problem by using CC to
compile enquire instead of GCC.  Unfortunately I can't get by with that at
this point.

When xgcc compiled itself, it does appear to link in the C library (I'm using
the ld linker), so I *THINK* there error is in the stdio.h files declarations.
I think the GCC must be defining some symbols that CC does not and therefore
missing the declarations of fseek() and putc().  I just can't figure out what
symbols these are!  It could be __STDC__ or it might be __POSIX__ but I thought
maybe someone else might have had this problem.  I'm not sure what version of
CC we have installed.

If anyone could help me, I would greatly appreciate it.  I got the dern compiler
to compile things like tinymud which require an ANSI compliant compiler (as CC
is not compliant). Now I am stuck trying to get GCC to compile when what I 
really want to compile can't be until I'm successful with GCC.

Steve

Newsgroups: gnu.gcc.help
From: greg@mobius.viewlogic.com (Gregory Larkin)
Subject: Problems compiling GCC 2.2.2 on IBM RS/6000
Originator: greg@mobius
Organization: Viewlogic Systems, Inc.
Date: Mon, 21 Dec 1992 19:17:34 GMT



Hi there,

I would like to compile GCC 2.2.2 on an IBM RS/6000 and I
am running into problems when it is trying to construct
libgcc.

Here is what I am getting:

/u/mobius/greg/elvis/gcc-2.2.2>make
        rm -f tmplibgcc2.a
        set -e; \
                for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2  
_lshrdi3 _lshldi3 _ashldi3 _ashrdi3   _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf
_floatdisf  _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi 
_fixsfdi  _varargs _eprintf _builtin_new _builtin_New _builtin_del  _bb 
_shtab _clear_cache _trampoline __main _exit; \
                do \
                  echo ${name}; \
                  ./gcc -O2    -g -B./ -g1 -I. -I. -I./config -c -DL${name} \
                      ./libgcc2.c -o ${name}.o; \
                  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
                  ar rc tmplibgcc2.a ${name}.o; \
                  rm -f ${name}.o; \
                done
_muldi3
Assembler:
/tmp/ccTD8Dmb.s: line 25: Error In Syntax
The error code from the last failed command is 1.

Make Quitting.
/u/mobius/greg/elvis/gcc-2.2.2>


Does anyone know how to fix this problem?

Thanks for any help!

-- 
              Greg Larkin, Software Engineer, Waveform Analysis
                 Viewlogic Systems, Inc.  Marlboro, MA 01752
                            greg@Viewlogic.COM
Newsgroups: gnu.gcc.help
From: hueni@optolab.unibe.ch (Hermann Hueni)
Subject: Cross compiling for Philips ERM4.0 (68k)
Reply-To: hueni@optolab.unibe.ch
Organization: Physiological Institute, University of Berne, Switzerland
Date: Mon, 21 Dec 1992 10:26:12 GMT

We more or less successfully used gcc, gas & gld to cross compile on a SUN Sparc
for the Philips ERM4.0 'embedded realtime monitor' 68k system.

Gcc was configured for 'sun3'.
Philips has allowed us to  recompile the source code
of their library with gcc such that we were able
to link ERM support code in.

We provided a tape with the whole installation back to our
philips representative such that other cudstomers who
may have the same need could take advantage of it.

We experienced a compilation speed improvement of a factor
40 over our old Philips PG9000 with UNIX SysV.2 which has previously
been used for cross compilation.

hueni@optolab.unibe.ch




Newsgroups: gnu.gcc.help
From: youngdale@v6550c.nrl.navy.mil (Eric Youngdale)
Subject: Re: Loading gcc 2.2 from Mango
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 16:38:36 GMT

>In article <1hjludINN34t@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
>> In article <1hierfINNp7t@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J
>> Lydick) writes:
>>
>> a lot of stuff based on a wild-assed guess about something that
>> 	In article <gnusenet1992Dec20.232210.23638@bnlux1.bnl.gov>,
>> 	kushmer@bnlux1.bnl.gov (christopher kushmerick) writes:
>> I'd appreciate any feedback as to whether my guess was accurate.  In
>> particular, was this person abusing a VMSINSTALlable kit?
>
>	Mango has minor problems.  For one, saveset D is corrupt.  (The C++
>stuff.)  But other than that VMSINSTAL ran fine on our 8650.
>	Still, even with minor problems it's a heck of a lot better than the
>munged *.com files out of the straight GNU distribution.

	I am the person who assembled the VMSINSTAL stuff on mango.  I cannot
do anything about the corrupt D saveset, since a disk drive died the day
after I left for Christmas vacation (my office mate said that timing was
everything :-).  It is possible that there was a transmission error when you
downloaded it, and it might still be OK.  I would like someone to fill me in on
what this thread is all about, though.

	If anyone sent me any mail between 15 Dec and this morning, it got
lost.  I can be reached at youngdale@v6550c.nrl.navy.mil or
eric@tantalus.nrl.navy.mil.

-Eric
Newsgroups: gnu.gcc.help