From: Xin Wang <xwang@cs.umn.edu>
Date: Thu, 27 Jun 1996 18:27:24 -0500 (CDT)
Subject: mergesuif
Message-Id: <199606272327.SAA13984@cslsgi7.cs.umn.edu>
I tried to use SUIF to compile SPEC92, li.
After using linksuif, I generated .lin files. Then
mergesuif unixstuff.lin xlbfun.lin xlcont.lin xldbug.lin xldmem.lin xleval.lin xlfio.lin xlftab.lin xlglob.lin xlinit.lin xlio.lin xlisp.lin xljump.lin xllist.lin xlmath.lin xlobj.lin xlprin.lin xlread.lin xlstr.lin xlsubr.lin xlsym.lin xlsys.lin li.mer
**** Program: mergesuif
**** Assertion failure in file "symtab.cc" at line 1295 (module libsuif.a)
**** False expression: old_si_entry != NULL
Abort (core dumped)
All I want to do is to merge those file into one file set.
xin wang
From: jhbrown@ai.mit.edu (Jeremy H. Brown)
Date: Thu, 27 Jun 96 13:03:44 EDT
Subject: Spec95 gcc -- still struggling along
Message-Id: <9606271703.AA27933@tarkin.ai.mit.edu>
Well, we've finally caught up to Paul Somogyi
<psomogyi@cs.ualberta.ca> in the problems we're having getting suif to
compile spec95's gcc. In particular, this line in the original source
(it's an expanded macro):
( ( &recipe_obstack )->temp = (char *)( 0 ) - (char *) ( &recipe_obstack )->chunk
turns into
recipe_obstack.temp = (int)(0 - (char *)recipe_obstack.chunk);
which gcc, as the backend compiler, then craps out on:
/usr/local/bin/gcc -c -g bc-optab.out.c -o bc-optab.o
bc-optab.out.c: In function `deduce_conversion':
bc-optab.out.c:1802: invalid operands to binary -
Adding a (char *) by hand:
recipe_obstack.temp = (int)((char *)0 - (char *)recipe_obstack.chunk);
makes it compile fine. Is there a simple patch to get this casting
done automagically?
Jeremy
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Thu, 27 Jun 96 0:56:15 PDT
Subject: Re: inconsistent typedefs
Message-Id: <CMM.0.90.4.835862175.cwilson@Xenon.Stanford.EDU>
> Hi,
> there are inconsistent typedefs in "sf2c.h" and "f2c.h" in
> baseparsuif.:
>
> in sf2c.h
> typedef int flag;
> typedef int ftnlen;
> typedef int ftnint;
>
> while in f2c.h
> typedef long flag;
> typedef long ftnlen;
> typedef int ftnint;
>
> This creates problems when using the I/O routines from libI77_doall.a
> on architectures with differently sized "int" and "long"
>
> Sumit
Thanks for the bug report.
sf2c.h should really be used by all these programs -- that f2c.h was
being used in I77 and I77_doall was a mistake. We found this problem
and fixed it in our internal sources here at Stanford recently because
we were using SUIF on a 64-bit DEC Alpha. It will be fixed in the
next releases of basesuif and baseparsuif.
In the meantime, you can go ahead and replace f2c.h with sf2c.h.
The way the version of f2c on which sf2c is based uses ``int'' and
``long'' on the target machine defies explaination. In some cases it
tries to distinguish them, but in others it assumes they have to be
the same. That's why for sf2c.h we had to replace all uses of
``long'' with ``int'' to get it to work on a 64-bit system.
--Chris
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Thu, 27 Jun 96 0:29:54 PDT
Subject: Re: SunOS 4.1 irritation with libraries
Message-Id: <CMM.0.90.4.835860594.cwilson@Xenon.Stanford.EDU>
> SunOS libraries have the annoying property that if you move them more
> than a minute or two after their initial ranlibing, it looks to ld
> like their ranlib-generated index is now out of date. So, if you
> rebuild part of a package and it reinstalls an already-compiled
> library, ld fails later on when trying to link with that library.
> I've added this code to suif-install to deal with the problem locally;
> this obviously isn't portable to non-SunOS boxes in its current form,
> but perhaps something could be worked out for the next distribution.
>
> Jeremy
Thanks for the tip.
> ------------------------------------------------------------------------
>
> *** suif-install Wed Jun 26 11:58:05 1996
> --- suif-install~ Fri Apr 19 16:11:03 1996
> ***************
> *** 46,60 ****
> exit 1
> fi
>
> - # Sunos addendum -- after you move a library, it looks out of date,
> - # so rerun ranlib. Not clean, but needed.
> - case ${1} in
> - *.a)
> - echo "cleaning up library: ${1}"
> - ranlib ${2}/${1}
> - ;;
> - *)
> - ;;
> - esac
> -
> exit 0
> --- 46,49 ----
That's one way to handle it.
I've chosen to put the new call to ranlib in Makefile.std instead.
The Makefiles already need to have SunOS-specific information about
running ranlib and it's only three lines to add this in one place to
the Makefiles without affect operation on any other system. This
keeps the script files more system-independent.
This change will be included in the next release of basesuif.
--Chris
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Wed, 26 Jun 96 21:56:50 PDT
Subject: Re: snoot misses structure alignment
Message-Id: <CMM.0.90.4.835851410.cwilson@Xenon.Stanford.EDU>
Sorry for the delay in replying. I was on vacation.
> Hello,
> I found a problem in the snoot program.
>
> I found it when I try to make a compiler for a processor
> whose addressable size is NOT 2^n bits.
>
> For example, I rewrote snoot's config.h file
> for a processor whose addressable size is 5 bits as follows:
> (Please notice that all the alignment sizes is 5 bits.)
>
> ----------------------------------------
> IS_BIG_ENDIAN (FALSE)
>
> ADDRESSABLE_SIZE ( 5)
> CHAR_IS_SIGNED (FALSE)
>
> TYPE_SIZE (char, 5)
> TYPE_ALIGN (char, 5)
>
> TYPE_SIZE (short, 5)
> TYPE_ALIGN (short, 5)
>
> TYPE_SIZE (int, 10)
> TYPE_ALIGN (int, 5)
>
> /* ommited... */
>
> ARRAY_ALIGN ( 5)
>
> STRUCT_ALIGN ( 5)
>
> PTR_DIFF_TYPE (C_int)
> ----------------------------------------
>
> Next, I built the snoot program using this config.h file,
> and compiled a test program as follows:
>
> ----------------------------------------
> main()
> {
> struct X{
> int i;
> int j;
> char k;
> int o;
> int p;
> };
>
> struct X x;
> x.i=1;
> }
> ----------------------------------------
>
> And I examined the size of struct X by using printsuif.
> The result is:
>
> ----------------------------------------
> t:p1: struct X (57) {
> i offset=0 t:g16
> j offset=10 t:g16
> k offset=24 t:g14
> o offset=33 t:g16
> p offset=43 t:g16
> }
> ----------------------------------------
>
> I expected that variable k's offset is 20, o's is 25, p's is 35,
> but I got a very strange result.
>
> So I investigated the snoot's source files,
> and found out what causes this strange behavior:
>
> I found macro roundup is defined as follows in file c.h.
>
> #define roundup(x,n) (((x)+((n)-1))&(~((n)-1)))
>
> This macro is used to align x to n-boundary,
> but it works right only when n is a power of 2.
> Since snoot uses this macro to align structure's fields,
> fails in the case like described avobe.
> I guess a right version of this macro is (for example):
>
> #define roundup(x,n) ( (int)(((x)+(n)-1) / (n)) * (n) )
>
> Thank you.
> --
> Tomoto Shimizu
> Department of Electronics and Communication,
> Graduate School of Engineering,
> Kyoto University, Japan
Thank you very much for the bug report and for the fix. This problem
will be fixed in the next release of basesuif.
--Chris