[M3devel] gcc tree checking

[Rodney M. Bates]

Jay K wrote:
> One of the (series of) tree type mismatches is like:
> 
> 
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
> 
> GetChar returns word_8 but the call is asserted to return word_64.
> 
> I believe this comes from:
> 
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
> 
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
> 
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
> 
> 
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
> 
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.

This is a very good idea.  It may be a lot of work, but I have found
many times over that regression testing tools of this kind pay for
themselves in the (not so) long run.  Some of the changes found will
be legitimate, but that's a lot easier to verify than to chase obscure
bugs from end symptoms.

> 
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
> 
>  - Jay
> 
>