[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