hisa@kepler.mita.keio.ac.jp (hirohisa ogawa) (11/09/89)
We cannot compile whole atk latest distribution with hc -g option on RT aos.
Our hc version is 2.1n. Eli , bush and rofftext didn't work correctly.
If you have any infomation about hc,please send me.
hisa@slab.math.keio.ac.jpdba+@ANDREW.CMU.EDU (David Anderson) (11/11/89)
I do not believe we've tried compiling atk with hc 2.1n. Because of a variety of problems in early versions of hc 2.1 we've continued to use hc 1.4 here at the ITC. I've heard from a group who seems happier with hc 2.1s, though I don't know if they've compiled atk with it. --david
brunner@ibmpa.UUCP (MH 6.6, Eric Brunner) (11/16/89)
The current version is 2.1s, described below. There are still bugs in 2.1s, e.g., optimization code generation. Send in your bugs/apars and I'll forward them to MetaWare. Eric ------- Forwarded Message > Received: from Messages.7.12.N.CUILIB.3.45.SNAP.NOT.LINKED.kepler.rt.r3 > via MS.5.6.kepler.rt_r3; > Thu, 9 Nov 89 20:59:29 +0900 > Message-Id: <8ZKKOVa56zsJ86O0VQ@kepler> > Date: Thu, 9 Nov 89 20:59:29 +0900 > From: hirohisa ogawa <ibmsupt!uunet!kepler.mita.keio.ac.jp!hisa> > To: info-andrew@andrew.cmu.edu > Subject: problems with hc -g option on RT aos > > We cannot compile whole atk latest distribution with hc -g option on RT aos. > Our hc version is 2.1n. Eli , bush and rofftext didn't work correctly. > If you have any infomation about hc,please send me. > > > hisa@slab.math.keio.ac.jp Hirohisa, The current version of MetaWare's High C compiler for IBM/4.3 or ACIS (aka "AOS") is 2.1s. Whoever handles site support at your facility should be able to get a copy from the Pacific Regional Support Office, in Japan. I sent them a tape with all of the context diffs (patches) to the sources (except hc) and a compressed tar image of /usr/lib/hc?com files about six weeks ago. If you have a problem getting the compiler, or have bugs to report, please let me know via direct email, as I don't always read the info-andrew traffic promptly. Here is the blurb I sent out to the comp.sys.ibm.pc.rt newsgroup announcing the 2.1s compiler, I hope to send out a new compiler before Christmas with fixes for bugs that have been found since 2.1s was made available, as well as for bugs found during internal use of later versions. A five part patch/shar kit to dbx was poseted to the same newsgroup and which you may be interested in. This will be sent shortly to the Pacific and European regional support centers. Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner (begin blurb) The current (2.1s) hc compiler is now available as a compressed tar file on ibmsupt. This version replaces all earlier versions of the hc compiler and corrects all reported problems with the compiler, including some reported as problems with the dbx. The compressed tar image contains the first and second pass of the hc compiler, /usr/lib/hc?com. The driver, /bin/hc is unchanged and is not included. This version has compiled X11 r.3, the Andrew Tool Kit, etc. No effort has yet been made to compile the AT&T C++ cfront code as the sources to AT&T's licensed code are not immediately at hand. The 2.1s hc compiler is available via UUCP, the path is: ibmsupt!/usr/spool/uucppublic/ibm43-fixes/hc2.1s.tar.Z - -rwxr-xr-x 1 root wheel 319488 Aug 3 16:07 hc1com* - -rwxr-xr-x 1 root wheel 342016 Aug 3 16:07 hc2com* A brief list of the fixes follows: o System errors, particularly when compiling with -g, are fixed. o Very long stabs now output as multiple stabs using the stab continuation convention. o -Hnocpp prevents recursive macro replacement, to conform to ANSI. (draft ANSI C standard, section 3.8.3.4). o -Hanno annotates .s files with only the source file, without including text from header files. o All reported problems have been fixed involving register allocation and lost register values. o Trace tables record the correct number of function argument words. o "Stabs" for float, double, and void types, and for arrays of more than 65535 elements, are corrected. o Too-large displacement fields, causing assembler errors, are fixed. o Warning added for empty declaration in parameter declaration area. o Compile-time evaluation of floating-point expressions has been limited to constant operands, to support nondefault ieee exception and rounding modes at run time. o Unsigned short or char functions with signed return values now truncate return values correctly. o A name-scope problem is fixed that involved an "extern" declaration within a nested block. Related fixes: V1.10 o correction to a relocation error for stabs in /bin/ld.c This version of the C compiler fixes a dbx problem with static functions, however a minor problem exists with the version of gdb in use at IBM Palo Alto. A patch to this problem will be posted to gnu.gdb.bug when our version of gdb is updated and the correction made. ------- End of Forwarded Message
tobeye@NORTHSTAR.DARTMOUTH.EDU (Anthony Edwards) (11/17/89)
> Excerpts from mail: 10-Nov-89 Re: problems with hc -g opt.. David Anderson@andrew.cm (283+0) > I do not believe we've tried compiling atk with hc 2.1n. Because of a > variety of problems in early versions of hc 2.1 we've continued to use > hc 1.4 here at the ITC. I've heard from a group who seems happier with hc 2.1s, though I don't know if they've compiled atk with it. --david Here at NORTHSTAR, we use hc1.4 all the time, but I find that certain files of the ATK Beta tape will not compile. So I switch over to hc2.1('s' maybe) for those files. (The files that choke up look like they were created with a code generator). I don't use hc2.1s to do the whole compile because a) I don't trust it and b) it can't compile certain files that hc1.4 can... The joy of hc on RT's... - Anthony Edwards
wdc@ATHENA.MIT.EDU (Bill Cattey) (11/18/89)
FYI: As of Patch level 2, I have successfully compiled ALL of andrew, including the ODA stuff using hc2.1s. The resulting system is at least as reliable as the system I compiled on a BSD4.3 Vax with pcc. The only problem is that there is, as yet, no version of GCC which will debug the resulting binaries. This is due to a change in the procedure call address specification between hc1 and hc2. -wdc