GSoC :Project Idea(Before final Submission) for review and feedback

[David Brown]

On 25/03/2012 11:55, Oleg Endo wrote:
> Please reply in CC to the GCC mailing list, so others can follow the
> discussion.
>
> On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote:
>> On 25 March 2012 03:59, Oleg Endo<oleg.endo@t-online.de>  wrote:
>>>
>>> I might be misunderstanding the idea...
>>> Let's assume you've got a program that doesn't compile, and you leave
>>> out those erroneous blocks to enforce successful compilation of the
>>> broken program.  How are you going to figure out for which blocks it is
>>> actually safe to be removed and for which it isn't?
>>
>> I can do it by tracing the code blocks which are dependent on the
>> erroneous block. i.e if any block is data/control dependent(the output
>> or written value of the erroneous part is read) on this erroneous
>> block or line of code will be eliminated.
>>
>>> Effectively, you'll
>>> be changing the original semantics of a program, and those semantic
>>> changes might be completely not what the programmer originally had in
>>> mind.  In the worst case, something might end up with an (un)formatted
>>> harddisk...*
>>>
>>> Cheers,
>>> Oleg
>>>
>> Thank you sir for your great feedback. You have understood it
>> correctly. Now the programmer will be informed about the change in
>> code and the semantics.(Notice that this plug-in is not going to
>> modify the original code!, it just copy the original code and perform
>> all the operations on the temporary file!!!) Even from the partial
>> execution of the code the programmer will get an overview of his
>> actual progress.
>>
>> suppose the program written by the programmer be:
>>
>> 1 int main(void)
>> 2 {
>> 3    int arr[]={3,4,-10,22,33,37,11};
>> 4    sort(arr);
>> 5    int a = arr[3] // Now suppose the programmer missed the semicolon
>> here. Which generates a compilation error at line 5;
>> 6    printf("%d\n",a);
>> 7    for(i=0;i<7;i++)
>> 8    {
>> 9        printf("%d\n",arr[i]);
>> 10    }
>> 11  }
>>
>>
>> Now if we just analyze the data (i.e. variable), we can easily find
>> that there is only data dependency exists between line 5 and line 6.
>> The rest of the program is not being effected due to elimination or
>> commenting line 5.
>>

There is also a dependency between lines 6 and 9 - the second printf 
cannot be done until the first printf is complete.  Anything that 
involves calls to external code, or reading or writing volatile data, 
must be done in order and as specified, and cannot be omitted or 
re-arranged.  So if you omit the first printf, then you must omit all 
later external calls or volatile accesses.  And everything else is then 
subject to dead-code elimination because it has no effect, and can be 
omitted.

In other words, the best you can do is spot the error, replace it with a 
call to abort(), and generate a partial execution up to the failing 
point.  There is no way to continue while still being the same program. 
  And if it is a different program, how does it help anyone to continue?

I'd suggest then that you are better off thinking of a C interpreter, 
that will interpret and execute C code as it goes along.