[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