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

[Subrata Biswas]

Thank You David for your suggestion and feedback. I'll let you know my
final proposal (after the modification based on your feedback and my
latest study) as early as possible.

I would like to request everyone in this community to kindly enrich me
with more suggestions and guidance to prepare my final project
proposal for GSoC2012.

Thanks a lot to everyone for your active and helpful feedback!!!

On 26 March 2012 17:04, David Brown <david@westcontrol.com> wrote:
> 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.
>
>



-- 
Thanking You,

Regards
Subrata Biswas
MTech (pursuing)
Computer Science and Engineering
Indian Institute of Technology, Roorkee
Mob: +91 7417474559