brunner@bullhead.uucp (08/24/89)
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. Eric Brunner, IBM AWD Palo Alto inet: brunner@monet.berkeley.edu or brunner%ibmsupt@uunet.uu.net uucp: uunet!ibmsupt!brunner (415) 855-4486
esj@bikini.cis.ufl.edu (Eric S. Johnson) (08/31/89)
In article <1830@ibmpa.UUCP> brunner@ibmsupt.UUCP () writes: > > >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. > If someone at a Internet site has picked this up, could you contact me and make arrangments for us to get a copy? We can show all the appropriate licenses and such, we just don't have dial out UUCP access right now. And, on a slightly related note, is anyone using the if_un.c posted as V1.12 on a 6152 with more then 1 ethernet card. The driver seems to have fixed the earlier crashes we were having, as long as the machine is running a kernal configured for 1 ethernet card. If we try to boot a kernal with >1 ethernet card support, it crashes at the probe. We realy want to use this 6152 as a gateway! Thanks for any help or suggestions, Eric Johnson U of Florida <esj@ufl.edu>
kriso@northstar5 (Kris Olander) (09/01/89)
Has anyone compiled the X11R3 Xibm code with the new compiler?
(Jeff W. aka: Skippy The WH -- what results have you had?)
I had some problems with vgaData.c and mpelData.c.
-- make output --
-- for mpelData.o --
rm -f mpelData.o
hc -c -g -L/usr/cs/lib -I. -I../BSDrt -I../../mfb -I../ppc
-I../../../include -I../../../.././X11 -I../common
-I../../../../extensions/include -DUNIXCPP -DNOSTDHDRS -DHCVERSION=21018
-DBSDrt -DRTIO mpelData.c
E "mpelData.c",L226/C2: mpelSetColor
| Type "void(unsigned long number,unsigned short red,unsigned short green,
unsigned short blue,VisualPtr pVisual)" is not assignment compatible with
type "void(*)()".
1 user error No warnings
*** Exit 8
Hc1.4 has no problems producing object code from these C files.
Also, note that when I check out the HCVERSION using the method suggested
in Rt.macros, the version of hc2.1 is reported as 'hc2.1r' NOT 'hc2.1s'
as stated by ACIS. ???????
The new compiler also finds alot of "...Expression has no side effects",
and "...Result of comparison never varies" comments when compiling the
Magic program from the Berkeley VLSI tools. We usually jump ship and switch
to hc1.4 when we see these kinds of errors.
-Kris Olander
(just in case .sig) Sys. Eng.
(doesn't get appended) Project NORTHSTAR
# Kris Olander ---- ---- arpa: kriso@northstar.dartmouth.edu #
# ---------------------------------------------------------- #
# System Eng. Project NORTHSTAR #
# Thayer School of Eng., Dartmouth College #brunner@bullhead.uucp (09/06/89)
In article <20803@uflorida.cis.ufl.EDU> esj@bikini.cis.ufl.edu (Eric S. Johnson) writes: >In article <1830@ibmpa.UUCP> brunner@ibmsupt.UUCP () writes: >> (hc 2.1s' virtues and availability, deleted) Let me know if you can't get the 2.1s version via channels, we're phoning all the known/official IBM/4.3 contacts, and it will help us in fixing the support system's problems. >And, on a slightly related note, is anyone using the if_un.c >posted as V1.12 on a 6152 with more then 1 ethernet card. >The driver seems to have fixed the earlier crashes we were having, >as long as the machine is running a kernal configured for 1 ethernet >card. If we try to boot a kernal with >1 ethernet card support, it >crashes at the probe. We realy want to use this 6152 as a gateway! We know about the 2 card crashes -- and we are working on it. We did not think to test the two-ethernet card configuration, to our chagrin! Eric Brunner, IBM AWD Palo Alto inet: brunner@monet.berkeley.edu or brunner%ibmsupt@uunet.uu.net uucp: uunet!ibmsupt!brunner (415) 855-4486
lmb@ghoti.uucp (Larry Breed) (09/16/89)
In article <15356@dartvax.Dartmouth.EDU> kriso@northstar5.dartmouth.edu (Kris Olander) writes: > >The new compiler also finds alot of "...Expression has no side effects", >and "...Result of comparison never varies" comments when compiling the >Magic program from the Berkeley VLSI tools. We usually jump ship and switch >to hc1.4 when we see these kinds of errors. > Kris, did you look at the source code that caused those warnings? We have found many of errors in BSD source with the help of the hc warnings. "result of comparison never varies" usually occurs on an if statement like if (c<0) ... where c has an unsigned type. This is usually a porting problem, coming from a default-signed-char environment. A statement like x+0; will cause the "expression has no side-effects" warning. Maybe someone typed '+' where they meant '='. Maybe they meant to declare x as volatile. Or maybe it's deliberate -- but worth checking out, no? If you don't like to be warned, well, that's what -w is for. Speaking of porting problems, if you suspect that an assumption of chars being signed is causing trouble, try recompiling with -Hoff=char_default_unsigned . "plain" chars will be signed and you can see if the problem goes away. Disclaimer: Don't blame my employer, blame: Larry Breed (415) 855-4460 uucp: uunet!ibmsupt!lmb inet: ibmsupt!lmb@uunet.uu.net