[M3devel] gcc tree checking

Jay K jay.krell at cornell.edu
Tue Jun 29 22:28:53 CEST 2010


I staked a claim, put in the start of something and made it work.
But then got lazy. I've been using m3core as my test.
Compiling all of it with cm3 -keep.
mv AMD64_DARWIN AMD64_DARWIN.1
make a compiler change
cm3 -keep again
diff -u AMD64_DARWIN.1 AMD64_DARWIN

And then often recompiling compiler with itself to push the change further.
 Hoping the compiler itself gets pretty good coverage, which has proven
  right and wrong through the years.

The test I put in can still be developed further.

 - Jay


----------------------------------------
> Date: Tue, 29 Jun 2010 12:59:01 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc tree checking
>
>
>
> 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
>>
>>
 		 	   		  


More information about the M3devel mailing list