[M3devel] uninitialized + insert_mn

[Jay K]

I found the lame hack that volatizing whatever store follows an insert_mn works.
If it suffices for the entire tree I'll go with it for now.

 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Tue, 1 Jun 2010 16:00:41 +0000
> Subject: [M3devel] uninitialized + insert_mn
>
>
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
>
>
> PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;  cp  : ADDRESS) =
>   VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
>   BEGIN
>     IF ref # NIL THEN
>       VAR
>         h  := HeaderOf(ref);
>         tc := h.typecode;
>       BEGIN
>
>
> It is actually *kind of* true.
> The store to tc uses load tc, insert_mn, store tc.
>
>
> Any idea what to do?
> offset=0
> count=20
>
>
> I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
> Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
> Of course I remember they caused a problem.
> Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?
>
>
> What I'm really doing is looking into removing the heavy use of volatile.
>
>
>  - Jay
>
>