[M3devel] gcc tree checking

Jay K jay.krell at cornell.edu
Tue Jun 29 14:17:27 CEST 2010


Changing in_memory breaks cm3.
The fix is therefore probably in parse.c to cast or convert, similar to what m3back does.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc tree checking
> Date: Tue, 29 Jun 2010 09:25:37 +0000
>
>
> 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.
>
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>
>  - Jay
>
>
 		 	   		  


More information about the M3devel mailing list