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 <da...@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.e...@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
