[M3devel] thouhts on -Wall with C backend output
mika at async.caltech.edu
mika at async.caltech.edu
Sun Dec 16 19:55:29 CET 2012
Can you have an option to add an assertion in the output for these cases?
Here either
1. gcc has found a bug in the C code generator and/or front end, in that
there's no default (abortion) case
or
2. the front end has deduced there is no need for abortion because it can
see that the missing ELSE is never going to be exercised, based on the
already existing type information
What I'm proposing is two modes for the compiler:
-- ignore the errors
or
-- add proper assertions to the C code, e.g.,
assert(false, "front-end deduced this cant happen by inspecting type information")
which, when enabled, should make gcc shut up, and instead turn into
runtime checks on the compiler
Mika
Hendrik Boom writes:
>On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote:
>>
>> I've tried to generate "very good C".
>> I've fixed some of what gcc -Wall complains about.
>> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1.
>> (at least one of what I deal with, I think anything newer won't complain..)
>>
>>
>>
>> do-cm3-all with -Wall -Werror gets very far, to:
>>
>> == package /Users/jay/dev2/cm3/m3-db/stablegen ==
>>
>> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++
>> --- building in AMD64_DARWIN ---
>>
>> ignoring ../src/m3overrides
>>
>> w source -> compiling GenCode.m3
>> cc1: warnings being treated as errors
>> GenCode.mc.c: In function âGenCode__BuildMethods__Searchâ:
>> GenCode.mc.c:3505: warning: control reaches end of non-void function
>> m3_backend => 1
>>
>> PROCEDURE Search ( type : Type.Reference;
>> VAR count : INTEGER;
>> VAR top : CARDINAL;
>> umethods: AtomList.T ):
>> ImportList.MethodList RAISES {StablegenError.E} =
>> VAR methods: ImportList.MethodList;
>> BEGIN
>> IF (type = Type.root) OR (type = NIL) THEN (* base of
>> recursion *)
>> RETURN NEW(ImportList.MethodList, ABS(count))
>> ELSE
>> TYPECASE type OF
>> Type.Object (ob) =>
>> IF count <= 0 THEN
>> count:= count - NUMBER(ob.methods^)
>> END;
>> methods := Search(ob.super, count, top, umethods);
>> FOR i := 0 TO LAST(ob.methods^) DO
>> IF umethods = NIL
>> OR AtomList.Member(
>> umethods, ob.methods[i].name) THEN
>> IF AtomList.Member(reserved, ob.methods[i].name) THEN
>> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name)
>> &" is a reserved method name in stable objects. "
>> &"Must not be an update method.")
>> END;
>> methods[top].name := ob.methods[i].name;
>> methods[top].sig := ob.methods[i].sig;
>> INC(top)
>> END
>> END;
>> RETURN methods
>> | Type.Opaque (op) =>
>> RETURN Search(op.revealedSuperType, count, top, umethods)
>> | Type.Reference => <*ASSERT FALSE*>
>> END
>> END
>> END Search;
>>
>> I think we can't expect gcc -Wall -Werror to pass.
>> I really wanted it to, and I tried, and I fixed stuff.
>> But I don't think it is viable.
>> Ok?
>
>Could it be that the TYPECASE doesn't have an ELSE clause, possibly
>translated to a switch withouy a default: label? This would give the
>C code an apparent path to the end of the function. M3 may know that
>the TYPECASE exhausts all the possibilities, but C will not.
>
>-- hendrik
More information about the M3devel
mailing list