Re: GSoC :Project Idea(Before final Submission) for review and feedback
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 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 {
> 3int arr[]={3,4,-10,22,33,37,11};
> 4sort(arr);
> 5int a = arr[3] // Now suppose the programmer missed the semicolon
> here. Which generates a compilation error at line 5;
> 6printf("%d\n",a);
> 7for(i=0;i<7;i++)
> 8{
> 9printf("%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.
>
> Hence the temporary source file after commenting out the erroneous
> part of the code and the code segment that is dependent on this
> erroneous part would be:
>
> 1 int main(void)
> 2 {
> 3int arr[]={3,4,-10,22,33,37,11};
> 4sort(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);
> 7for(i=0;i<7;i++)
> 8{
> 9printf("%d\n",arr[i]);
> 10}
> 11 }
>
> Now this part of the program(broken program) is error free. Now we can
> compile this part using GCC and get the partial executable.
>
> Now the possible output after compilation using this plug in(if
> programmer use it) with GCC would be:
>
> "You have syntax error at Line no. 5. and to generate the partial
> executable Line 5 and Line 6 have removed in the temporary executable
> execute the partial executable excute p.out"
>
> Advantages to the Programmer:
> 1. If programmer can see the result of the partial executable he can
> actually quantify his/her progress in code.
> 2. The debug become easier as this plug-in would suggest about
> possible correction in the code etc.
I don't think it will make the actual debugging task easier. It might
make writing code easier (that's what IDEs are doing these days while
you're typing code...). In order to debug a program, the actual bugs
need to be _in_ the program, otherwise there is nothing to debug.
Removing arbitrary parts of the program could potentially introduce new
artificial bugs, just because of a missing semicolon.
> * I did not understand the worst case that you have mentioned as
> (un)formatted hard disk. Can you kindly explain it?
>
Let's say I'm writing a kind of disk utility that reads and writes
sectors...
-
source1.c:
bool
copy_sector (void* outbuf, const void* inbuf, int bytecount)
{
if (bytecount < 4)
return false;
if ((bytecount & 3) != 0)
return false;
int* out_ptr = (int*)outbuf;
const int* in_ptr = (const int*)inbuf;
int count = bytecount / 4;
do
{
int i = *in_ptr++;
if (i & 1)
i = do_something_special0 (i);
else if (i & (1 << 16))
i = do_something_special1 (i);
*out_ptr++ = i;
} while (--count);
return true;
}
-
source0.c:
int main (void)
{
...
int sector_size = get_sector_size (...);
void* sector_read_buf = malloc (sector_size);
void* sector_write_buf = malloc (sector_size);
while (sector_count > 0)
{
read_next_sector (sector_read_buf);
if (copy_sector (sector_write_buf, sector_read_buf, sector_size))
write_next_sector (sector_write_buf);
}
...
}
Let's assume that in the function copy_sector in source1.c there is a
syntax error:
do
{
int i = *in_ptr++;
if (i & 1)
i = do_something_special0 (i);
else if (i & (1 << 16))
why no shortcut operation for comparion on _Complex operands
Hi, In tree-complex.c's function expand_complex_comparison, gcc just expand comparison on complex operands into comparisons on inner type, like: D.5375_17 = REALPART_EXPR ; D.5376_18 = IMAGPART_EXPR ; g2.1_5 = COMPLEX_EXPR ; D.5377_19 = REALPART_EXPR ; D.5378_20 = IMAGPART_EXPR ; g3.2_6 = COMPLEX_EXPR ; D.5379_21 = D.5375_17 == D.5377_19; D.5380_22 = D.5376_18 == D.5378_20; D.5381_23 = D.5379_21 & D.5380_22; if (D.5381_23 == 1) goto ; else goto ; So is it possible to do shortcut operation for the "&" on the real/imag part of complex data? Thanks -- Best Regards.
Re: GSoC :Project Idea(Before final Submission) for review and feedback
Thank you sir for your excellent example.
On 25 March 2012 15:25, 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 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.
>>
>> Hence the temporary source file after commenting out the erroneous
>> part of the code and the code segment that is dependent on this
>> erroneous part would 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 this part of the program(broken program) is error free. Now we can
>> compile this part using GCC and get the partial executable.
>>
>> Now the possible output after compilation using this plug in(if
>> programmer use it) with GCC would be:
>>
>> "You have syntax error at Line no. 5. and to generate the partial
>> executable Line 5 and Line 6 have removed in the temporary executable
>> execute the partial executable excute p.out"
>>
>> Advantages to the Programmer:
>> 1. If programmer can see the result of the partial executable he can
>> actually quantify his/her progress in code.
>> 2. The debug become easier as this plug-in would suggest about
>> possible correction in the code etc.
>
> I don't think it will make the actual debugging task easier. It might
> make writing code easier (that's what IDEs are doing these days while
> you're typing code...). In order to debug a program, the actual bugs
> need to be _in_ the program, otherwise there is nothing to debug.
> Removing arbitrary parts of the program could potentially introduce new
> artificial bugs, just because of a missing semicolon.
>
>> * I did not understand the worst case that you have mentioned as
>> (un)formatted hard disk. Can you kindly explain it?
>>
>
> Let's say I'm writing a kind of disk utility that reads and writes
> sectors...
>
> -
> source1.c:
>
> bool
> copy_sector (void* outbuf, const void* inbuf, int bytecount)
> {
> if (bytecount < 4)
> return false;
>
> if ((bytecount & 3) != 0)
> return false;
>
> int* out_ptr = (int*)outbuf;
> const int* in_ptr = (const int*)inbuf;
> int count = bytecount / 4;
>
> do
> {
> int i = *in_ptr++;
> if (i & 1)
> i = do_something_special0 (i);
> else if (i & (1 << 16))
> i = do_something_special1 (i);
> *out_ptr++ = i;
> } while (--count);
>
> return true;
> }
>
> -
> source0.c:
>
> int main (void)
> {
> ...
> int sector_size = get_sector_size (...);
> void* sector_read_buf = malloc (sector_size);
> void* sector_write_buf = malloc (sector_size);
>
> while (sector_count > 0)
> {
> read_next_sector (sector_read_buf);
> if (copy_sector (sector_write_buf, sector_read_buf, sector_size))
> write_next_sec
status of GCC & C++
Hello All,
It seems that several Linux distributions are shipping a GCC 4.7 compiled by a
C++
compiler (probably GCC).
This affects plugins makers, as has been already discussed.
Do we have (e.g. for plugin makers) a nice way to know if a given GCC
distribution was
compiled in C or in C++ mode? For instance, compiling a helloworld.c with gcc
-v don't
tell anything about the way that GCC compiler has been built. (ie if it has C++
symbols
or C ones in the executable, and knowing that is mandatory for plugins).
Did we cross the C++ rubicon, in other words is GCC 4.8 scheduled to be
compilable with a
C compiler (not C++) for the C front-end and the middle-end and the
x86_64/GNU/Linux
back-end?
[my imperfect understanding was that GCC 4.7 should have been compilable by
either a
standard C89 or a standard C++03 compiler, if not needing a Go or Ada front-end]
When GCC won't be compilable any more by a C (not C++) compiler, should we make
that a
prominent & documented change? I believe it should also be reflected in our
configure
machinery (by rejecting the build of GCC when a C++ compiler is not available).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: status of GCC & C++
On 3/25/12 1:19 PM, Basile Starynkevitch wrote: When GCC won't be compilable any more by a C (not C++) compiler, should we make that a prominent& documented change? I believe it should also be reflected in our configure machinery (by rejecting the build of GCC when a C++ compiler is not available). Yes. For GCC 4.8, we should move to: - Build all stages with C++ - Remove the option to go back to C. Diego.
Re: status of GCC & C++
> Yes. For GCC 4.8, we should move to: > > - Build all stages with C++ > - Remove the option to go back to C. That would mean you can start to use C++ in the compiler code although, AFAIK, we are still waiting for the long-promised C++ Coding Standard. That seems like putting the car before the horses to me. -- Eric Botcazou
Re: status of GCC & C++
On 3/25/12 1:32 PM, Eric Botcazou wrote: Yes. For GCC 4.8, we should move to: - Build all stages with C++ - Remove the option to go back to C. That would mean you can start to use C++ in the compiler code although, AFAIK, we are still waiting for the long-promised C++ Coding Standard. That seems like putting the car before the horses to me. I don't think so. By simply causing stage 1 to be compilable with a C++ compiler, we are making the transition easier. This is orthogonal to the porting effort. The proposed coding guidelines have been published and will evolve (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a set of rules that will naturally change over time, as we start using it. Diego.
Re: status of GCC & C++
On Sun, 25 Mar 2012 14:04:56 -0400
Diego Novillo wrote:
> On 3/25/12 1:28 PM, Basile Starynkevitch wrote:
> > On Sun, 25 Mar 2012 13:25:34 -0400
[...]
> > I would suggest then to put in a core header file (even used by plugins)
> > something like
> > #ifndef __cpluscplus
> > #error GCC and its plugins need to be compiled by a C++ compiler
> > #endif
> >
> > What do you think? And where should we put that?
>
> First things first. Stage 1 should be compiled with C++. We still need
> someone to volunteer to do that.
Ok. I thought that step was a trivial one.
Now a related question. How can a plugin know that cc1 was compiled with C++ or
just with
plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin
use
ENABLE_BUILD_WITH_CXX)?
And I don't understand why the GCC 4.7 changes don't advertise loudly on
http://gcc.gnu.org/gcc-4.7/changes.html that the C language is obsolete as the
language
in which GCC is coded, and that next release will *need* to be compiled with
C++? Or is
something that tells it somewhere, in strong enough words or typography that
nobody could
skip it? (I am not sure that a casual user, brave enough to compile GCC 4.7
from source,
did notice that C++ would be soon mandatory to compile GCC).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: status of GCC & C++
On Sun, 25 Mar 2012 20:30:31 +0200
Basile Starynkevitch wrote:
>
> How can a plugin know that cc1 was compiled with C++ or just with
> plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a
> plugin use
> ENABLE_BUILD_WITH_CXX)?
Actually, I tend to believe that this is really a bug in GCC 4.7
(specifically). I think
that
A) gcc-4.7 -v should obviously tell if it was compiled in C++ mode or in C
mode, since
this information is crucial to plugins. On Debian/Sid I don't have a simple way
to get
that information.
% /usr/bin/gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-1'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c+
+,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c+
+/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu Thread model: posix gcc version 4.7.0 (Debian
4.7.0-1)
Nothing above tell me about GCC being compiled in C++ flavor
B) the $(gcc-4.7 -print-file-name=plugin)/ directory should have a header
file with
something telling if it was compiled in C++ or C mode. (Perhaps
ENABLE_BUILD_WITH_GCC
might have that role in auto-host.h, but then I think it is grossly misnamed).
Since 4.7 is probably the only release of GCC which can be compiled by C and by
C++ I
believe it is a bug specific to that release.
I'm sure this bug affect several GCC plugins. It does affect GCC MELT for
instance.
https://groups.google.com/forum/?fromgroups#!topic/gcc-melt/PRWr28sQExk
My feeling is that it is not only the plugins' fault (so it is not only a MELT
plugin
bug, but a GCC one)
What do you think? Should 4.7.1 provide a fix to correct that? How? Testing
simply
ENABLE_BUILD_WITH_GCC makes me feel unhappy; that name is really confusing, if
we
understand and use it as GCC_IS_BUILT_WITH_CXX
My wish would be to add, perhaps in gcc/configure.ac of GCC 4.7.1, something
which
defines GCCPLUGIN_IN_CXX in e.g. $(gcc-4.7
-print-file-name=plugin)/plugin-version.h
when gcc-4.7 have been built with a C++ compiler so its plugins need to be
compiled with
a C++ compiler. That information should also be accessible (e.g. for plugin
makers) thru
some invocation of GCC (perhaps gcc -v).
Cheers
PS. Compatibility with C++ plugins was already discussed, but I forgot when...
Here I
focus on a possible bug of GCC 4.7.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: status of GCC & C++
On Sun, Mar 25, 2012 at 3:10 PM, Basile Starynkevitch wrote: > Nothing above tell me about GCC being compiled in C++ flavor I believe the ones that are not compiled with a C++ compiler have a --disable-xxx-something in the output of gcc -v -- Gaby
Re: status of GCC & C++
On Sun, 25 Mar 2012, Basile Starynkevitch wrote: On Sun, 25 Mar 2012 20:30:31 +0200 Basile Starynkevitch wrote: How can a plugin know that cc1 was compiled with C++ or just with plain C? nm thefile | grep _Z (possibly nm -D) You can also look for --disable-bootstrap or --disable-build-with-cxx in the configure options. Or you can just assume that it is built as C++, which is the default after all. People who have anything different should have asked for it and thus know what to expect. -- Marc Glisse
Animation showing 23 years of GCC development
I just stumbled into this video animation showing a graphical representation of GCC's source tree over the years. It is a bit long, but it's amusing to recognize big events in GCC (addition of Java, Ada, tree-ssa, etc) over time. http://www.youtube.com/watch?v=ZEAlhVOZ8qQ It lasts around 30 minutes. Diego.
Re: status of GCC & C++
> The proposed coding guidelines have been published and will evolve > (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a > set of rules that will naturally change over time, as we start using it. That isn't what was decided when the transition to C++ was proposed though. It was agreed that a set of Coding Conventions would be published before the switch to C++. If you think that the above conventions are in good enough a shape to be proposed, then propose them for inclusion in http://gcc.gnu.org/codingconventions.html -- Eric Botcazou
Re: status of GCC & C++
On Sun, Mar 25, 2012 at 17:36, Eric Botcazou wrote: >> The proposed coding guidelines have been published and will evolve >> (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a >> set of rules that will naturally change over time, as we start using it. > > That isn't what was decided when the transition to C++ was proposed though. Really? To start *writing* in C++, sure we want at least an initial version of the coding guidelines. I pointed to those, because they look like a reasonable start. To start *building* in C++, I do not think we need to agree on the coding guidelines. We are already doing stages 2 and 3, doing stage 1 is a straightforward next step. > It was agreed that a set of Coding Conventions would be published before the > switch to C++. If you think that the above conventions are in good enough a > shape to be proposed, then propose them for inclusion in > http://gcc.gnu.org/codingconventions.html This needs to be done, yes. But not for simply building with C++. Diego.
Re: status of GCC & C++
On Sun, Mar 25, 2012 at 4:45 PM, Diego Novillo wrote: > To start *building* in C++, I do not think we need to agree on the > coding guidelines. We are already doing stages 2 and 3, doing stage 1 > is a straightforward next step. I agree with Diego that to start building only with a C++ compiler, we do not need to have approved a C++ coding convention. I also think that the current wiki page is still at brainstorming phase than a sufficiently complete and coherent set. It needs further flushing. For example, I do not believe it makes sense to ban both simple templates (for writing containers) and virtual functions (or to that matter multiple inheritance). There are forms of those features that need to be properly restricted (e.g. it would a real mistake to go banana with the "advanced" template (meta)programming stuff.) Similarly, some of the control/flow and path can be significantly reduced (and bugs fixed!) if simple exception handling is allowed -- think of all those bugs caused by failure to exit early on error_mark_node. -- Gaby
Question about Tree_function_versioning
Hello Everyone, I am currently trying to take certain functions (marked by certain attributes) and create vector version along with the scalar versions of the function. For example, let's say I have a function my_add that is marked with a certain attribute, I am trying to clone it into my_add_vector and still keep the original my_add. For this, I am trying to use tree_function_versioning in cgraphunit.c to clone the cgraph_node into a new function. Does this function actually create a 2nd function (called my_add_vector) and copy the body from my_add function to the my_add_vector function or does it just create a node called my_add_vector and then create a pointer to the body of the my_add? Is there a better approach for doing this? Any help is greatly appreciated! Thanks, Balaji V. Iyer.
RE: GSoC :Project Idea(Before final Submission) for review and feedback
-Original Message-
From: Subrata Biswas [mailto:subrata.i...@gmail.com]
Sent: Sunday, March 25, 2012 12:22 PM
To: Oleg Endo
Cc: gcc
Subject: Re: GSoC :Project Idea(Before final Submission) for review and feedback
Thank you sir for your excellent example.
On 25 March 2012 15:25, 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 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.
>>
>> Hence the temporary source file after commenting out the erroneous
>> part of the code and the code segment that is dependent on this
>> erroneous part would 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 this part of the program(broken program) is error free. Now we
>> can compile this part using GCC and get the partial executable.
>>
>> Now the possible output after compilation using this plug in(if
>> programmer use it) with GCC would be:
>>
>> "You have syntax error at Line no. 5. and to generate the partial
>> executable Line 5 and Line 6 have removed in the temporary executable
>> execute the partial executable excute p.out"
>>
>> Advantages to the Programmer:
>> 1. If programmer can see the result of the partial executable he can
>> actually quantify his/her progress in code.
>> 2. The debug become easier as this plug-in would suggest about
>> possible correction in the code etc.
>
> I don't think it will make the actual debugging task easier. It might
> make writing code easier (that's what IDEs are doing these days while
> you're typing code...). In order to debug a program, the actual bugs
> need to be _in_ the program, otherwise there is nothing to debug.
> Removing arbitrary parts of the program could potentially introduce
> new artificial bugs, just because of a missing semicolon.
>
>> * I did not understand the worst case that you have mentioned as
>> (un)formatted hard disk. Can you kindly explain it?
>>
>
> Let's say I'm writing a kind of disk utility that reads and writes
> sectors...
>
> -
> source1.c:
>
> bool
> copy_sector (void* outbuf, const void* inbuf, int bytecount) {
> if (bytecount < 4)
> return false;
>
> if ((bytecount & 3) != 0)
> return false;
>
> int* out_ptr = (int*)outbuf;
> const int* in_ptr = (const int*)inbuf;
> int count = bytecount / 4;
>
> do
> {
> int i = *in_ptr++;
> if (i & 1)
> i = do_something_special0 (i);
> else if (i & (1 << 16))
> i = do_something_special1 (i);
> *out_ptr++ = i;
> } while (--count);
>
> return true;
> }
>
> -
> source0.c:
>
> int main (void)
> {
> ...
> int sector_size = get_sector_size (...);
> vo
Your friend DEATH of Google (URGENT) has recommended this great product from J&B Brands
Hi gcc@gcc.gnu.org! Your friend, DEATH of Google (URGENT), thought that you would be interested in Krupnik 40%, 1.80l from J&B Brands. Friend Most people just can't believe it This can make you $435 in an HOUR At NO COST http://de.tk/JBoD3 SERIOUSLY. There is nothing to do here, just watch the video as it explains it ALL. http://de.tk/JBoD3 Best regards, Marica Ann Karlsson http://de.tk/JBoD3 --- If you do not wish to receive further email, please send an email to quickclick.commiss...@ymail.com and put NO MORE in the subject line. --- To view the product click on the link below or copy and paste the link into your web browser: http://jbbrands.webhostingstar.com/product_info.php?products_id=65 Regards, J&B Brands http://jbbrands.webhostingstar.com/
