From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Wed, 26 Jun 96 21:21:15 PDT
Subject: Re: Snoot bug in casting enums: fix; libuseful bug in folding
Message-Id: <CMM.0.90.4.835849275.cwilson@Xenon.Stanford.EDU>
Sorry for the delay in responding. I've been on vactaion.
> I figured out a correct fix to the enum casting problem; basically,
> nothing should have been calling constnode with a negative value
> argument, so I just duplicated the relevant code inline where it was
> used with enum values in expr.cc. Here's the patch:
>
> ------------------------------------------------------------------------------------------
> *** expr.cc Tue Jun 25 11:32:51 1996
> --- expr.cc~ Mon Apr 8 02:55:34 1996
> ***************
> *** 1311,1325 ****
> if (tsym->sclass == ENUM)
> {
> t = gettok();
> !
> ! /* stolen from constnode*/
> ! {
> ! type_node *result_type = tsym->type;
> ! if (isarray(tsym->type)) result_type = atop(result_type);
> ! return cast(genop(operand(new in_ldc(result_type, operand(),
> ! immed(tsym->u.enum_value))),
> ! new tree_node_list), inttype);
> ! }}
> else
> {
> genop result;
> --- 1311,1319 ----
> if (tsym->sclass == ENUM)
> {
> t = gettok();
> ! return cast(constnode(tsym->u.enum_value, tsym->type),
> ! inttype);
> ! }
> else
> {
> genop result;
>
> ------------------------------------------------------------------------------------------
Thanks for the bug report and fix.
Your fix is correct. An alternate fix is to make constnode a bit more
general by making its first argument an i_integer instead of ``int''
or ``unsigned'', either of which could overflow in some cases.
> Now, on to the new problem: gcc does this sort of thing all over:
>
> typedef int *rtx;
> rtx foo() {
> return (rtx) -1;
> }
>
> However, this causes badness:
>
> s2c:Warning: constant too large for type
>
> extern int *foo()
> {
> return 4294967295;
> }
>
> -------------
I'm not quite clear on why this is bad. SUIF knows there are 32-bits
in a pointer, so it is using (2^32)-1 as the result of casting a -1 to
a pointer type. Just like casting -1 to ``unsigned''.
> To the best of my ability to tell, this happens when porky does
> constant-folding; in useful/eval.cc, fit_immed incorrectly decides
> that the -1 (32 bit int) won't fit in the 32 bit pointer and things go
> downhill from there.
Actually, it correctly decides ``-1'' won't fit in a pointer and
chooses to use (2^32)-1 instead. SUIF prefers to have pointer
constants be non-negative integers. (2^32)-1 is the natural
non-negative integer to choose to map -1 into when pointers are 32
bits.
> I _think_ the problem is in the i_integer checks around line 363:
>
> i_integer mask = i_integer(-1) << size;
> i_integer new_value = immed_to_ii(*value);
> if (non_negative(base_type))
> {
> if ((new_value & mask) != 0)
>
> For whatever reason, that new_value & mask is coming up non-zero, even
> though gdb shows me that size is 32 and value is -1. The way I figure
> it, it should be:
>
> mask = -1x2^32 == .....fffffffff00000000 (since it's overflowing standard 32 bit int len.)
> new_value = -1 == ffffffff (since it's a standard 32 bit int)
> and thus
> mask & new_value == ...000000000000000000000
The mistake in what you wrote above is the line:
> new_value = -1 == ffffffff (since it's a standard 32 bit int)
i_integers are all infinite precision, so when *value is -1, then
immed(*value) is the same as immed(-1). If you want to represent it
as an infinite series of hex digits, it's a sequence of all ``f''s,
.....fffffffffffffffffffffffffffffff, not just the 32-bit ffffffff.
Another way of putting it is that when you convert from a signed
32-bit int to an i_integer, it gets sign extended, if you're thinking
of the i_integer as an infinite series of bits.
Since all the bits in new_value are set, bitwise anding it with mask
just gives back mask. Which is non-zero.
> After several hours of staring at it, I'm giving up on trying to
> analyze the i_integer code to see what's going on. Any fixes would be
> most appreciated.
>
> Jeremy
You really have to be careful to think in terms of an i_integer
representing any integer _value_. When you convert from an int to an
i_integer, the value is the same. So converting from an int
representing -1 to an i_integer gives you the i_integer for -1, not
the two's complement bit-pattern of the representation of the int -1.
I hope that helps clarify what's going on here.
--Chris
From: Sumit Roy <sumit@atharvan.eng.wayne.edu>
Date: Wed, 26 Jun 1996 19:57:16 -0400
Subject: inconsistent typedefs
Message-Id: <199606262357.TAA09986@atharvan.eng.wayne.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
From: jhbrown@ai.mit.edu (Jeremy H. Brown)
Date: Wed, 26 Jun 96 12:43:58 EDT
Subject: SunOS 4.1 irritation with libraries
Message-Id: <9606261643.AA21921@tarkin.ai.mit.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
------------------------------------------------------------------------
*** 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 ----