Re: free (static_array)
On Tuesday 01 July 2008 08:38, Sajish V wrote:
> Hi All,
> Can you please let me know why GCC does not crib when we try to free a static
> array?
> main ()
> {
> char array[100];
> free (array);
> }
> The above code compiles without any hitch.
> Thanks,
> Sajish.
# ./a.out
*** glibc detected *** ./a.out: free(): invalid pointer: 0xffa8b530 ***
=== Backtrace: =
/lib/libc.so.6[0xf7ecb7a7]
/lib/libc.so.6(__libc_free+0x79)[0xf7ecc0ad]
./a.out[0x804834e]
/lib/libc.so.6(__libc_start_main+0x138)[0xf7e8da74]
./a.out[0x80482b5]
=== Memory map:
08048000-08049000 r-xp 08:06 1315925
/.local/tmp/a.out
08049000-0804a000 rwxp 08:06 1315925
/.local/tmp/a.out
0804a000-0806b000 rwxp 0804a000 00:00 0 [heap]
f7e6f000-f7e76000 r-xp 08:05 46193
/app/gcc-3.3.3/lib/libgcc_s.so.1
f7e76000-f7e77000 rwxp 6000 08:05 46193
/app/gcc-3.3.3/lib/libgcc_s.so.1
f7e77000-f7e78000 rwxp f7e77000 00:00 0
f7e78000-f7f6 r-xp 08:0
--
vda
Re: free (static_array)
Thanks for the reply, Denys.
My question was, why doesn't gcc catch it during compilation? It is clear that
we are trying to free a variable from stack. Shouldn't gcc flag an error for
this during compilation?
Regards,
Sajish.
- Original Message
From: Denys Vlasenko <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
Cc: Sajish V <[EMAIL PROTECTED]>
Sent: Tuesday, July 1, 2008 2:44:06 PM
Subject: Re: free (static_array)
On Tuesday 01 July 2008 08:38, Sajish V wrote:
> Hi All,
> Can you please let me know why GCC does not crib when we try to free a static
> array?
> main ()
> {
> char array[100];
> free (array);
> }
> The above code compiles without any hitch.
> Thanks,
> Sajish.
# ./a.out
*** glibc detected *** ./a.out: free(): invalid pointer: 0xffa8b530 ***
=== Backtrace: =
/lib/libc.so.6[0xf7ecb7a7]
/lib/libc.so.6(__libc_free+0x79)[0xf7ecc0ad]
./a.out[0x804834e]
/lib/libc.so.6(__libc_start_main+0x138)[0xf7e8da74]
./a.out[0x80482b5]
=== Memory map:
08048000-08049000 r-xp 08:06 1315925
/.local/tmp/a.out
08049000-0804a000 rwxp 08:06 1315925
/.local/tmp/a.out
0804a000-0806b000 rwxp 0804a000 00:00 0 [heap]
f7e6f000-f7e76000 r-xp 08:05 46193
/app/gcc-3.3.3/lib/libgcc_s.so.1
f7e76000-f7e77000 rwxp 6000 08:05 46193
/app/gcc-3.3.3/lib/libgcc_s.so.1
f7e77000-f7e78000 rwxp f7e77000 00:00 0
f7e78000-f7f6 r-xp 08:0
--
vda
Re: Feature request - a macro defined for GCC
On Tuesday 01 July 2008 07:33, x z wrote: > > I would like to see that GCC define a macro in the case it is being used to > compile a program. Currently there is a __GNUC__ macro defined by the GNU C > preprocessor CPP. That does not suit the need. As the CPP Manual says: > __GNUC__ is "defined by all GNU compilers that use the C preprocessor". My monitor is not wide enough for your lines. > It seems to imply that any (non-GNU) compiler that > uses the GNU C preprocessor would also have __GNUC__ defined. Did you test this theory? > According to their respective manuals, Intel C++ Compiler > and Portable C Compiler also pre-define __GNUC__, possibly > because they use the GNU CPP. It's their fault that they lie to the user. > Therefore, the fact that __GNUC__ is defined does not necessarily mean the > GCC compiler proper is being used. There is a need for a macro that > definitely confirms that GCC is being used. (It is another matter if another > complier deliberately misleads people by defining the same macro.) And I hope > that macro can be documented in the GCC Manual. -- vda
Re: free (static_array)
On Tuesday 01 July 2008 09:24, Sajish V wrote: > Thanks for the reply, Denys. > My question was, why doesn't gcc catch it during compilation? It is clear > that we are trying to free a variable from stack. Shouldn't gcc flag an error > for this during compilation? How gcc can know that free() is not supposed to be used like that? -- vda
Re: Feature request - a macro defined for GCC
x z wrote: > I would like to see that GCC define a macro in the case it is being > used to compile a program. Currently there is a __GNUC__ macro > defined by the GNU C preprocessor CPP. That does not suit the need. > As the CPP Manual says: __GNUC__ is "defined by all GNU compilers > that use the C preprocessor". It seems to imply that any (non-GNU) > compiler that uses the GNU C preprocessor would also have __GNUC__ > defined. According to their respective manuals, Intel C++ Compiler > and Portable C Compiler also pre-define __GNUC__, possibly because > they use the GNU CPP. They don't use GNU CPP. > Therefore, the fact that __GNUC__ is defined does not necessarily > mean the GCC compiler proper is being used. I don't think you've thought about this thoroughly. Any compiler that is not GNU C but defines __GNUC__ is lying to its users. If we define __REAL_GNUC__ they'll just define that as well. Andrew.
Re: Feature request - a macro defined for GCC
Andrew Haley wrote: x z wrote: I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP. That does not suit the need. As the CPP Manual says: __GNUC__ is "defined by all GNU compilers that use the C preprocessor". It seems to imply that any (non-GNU) compiler that uses the GNU C preprocessor would also have __GNUC__ defined. According to their respective manuals, Intel C++ Compiler and Portable C Compiler also pre-define __GNUC__, possibly because they use the GNU CPP. They don't use GNU CPP. Therefore, the fact that __GNUC__ is defined does not necessarily mean the GCC compiler proper is being used. I don't think you've thought about this thoroughly. Any compiler that is not GNU C but defines __GNUC__ is lying to its users. If we define __REAL_GNUC__ they'll just define that as well. Perhaps we could trademark _REAL_HONEST_GNU_CC_ and then sue anyone who used the trademark (since this would pretty clearly be a case of trademark dilution I would think!) After all you can't put GUCCI on your knock off shoe designs :-) Andrew.
Re: free (static_array)
On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote: > On Tuesday 01 July 2008 09:24, Sajish V wrote: > > Thanks for the reply, Denys. > > My question was, why doesn't gcc catch it during compilation? It is clear > > that we are trying to free a variable from stack. Shouldn't gcc flag an > > error for this during compilation? It could. Nobody has written the code to do so, and as they say patches are welcome (assuming you have done the paperwork to legally contribute to GCC). Have you filed a feature request via bugzilla so that it can be tracked? > How gcc can know that free() is not supposed to be used like that? Unless you use the -ffreestanding or -fno-builtin switches, the compiler is free to know about any function mentioned in the ISO C standard (or C++, etc. depending on your language). -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
Re: free (static_array)
On Tue, 1 Jul 2008, Michael Meissner wrote: > On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote: > > On Tuesday 01 July 2008 09:24, Sajish V wrote: > > > Thanks for the reply, Denys. > > > My question was, why doesn't gcc catch it during compilation? It is clear > > > that we are trying to free a variable from stack. Shouldn't gcc flag an > > > error for this during compilation? > > It could. Nobody has written the code to do so, and as they say patches are > welcome (assuming you have done the paperwork to legally contribute to GCC). > Have you filed a feature request via bugzilla so that it can be tracked? An error is inappropriate; undefined behavior only occurs on execution of the call to free, not on compilation of the program. A warning would be fine (as would converting the call to free into an abort). -- Joseph S. Myers [EMAIL PROTECTED]
Re: Feature request - a macro defined for GCC
Robert Dewar: [ Charset ISO-8859-1 converted... ] > Andrew Haley wrote: > > x z wrote: > > > >> I would like to see that GCC define a macro in the case it is being > >> used to compile a program. Currently there is a __GNUC__ macro > >> defined by the GNU C preprocessor CPP. That does not suit the need. > >> As the CPP Manual says: __GNUC__ is "defined by all GNU compilers > >> that use the C preprocessor". It seems to imply that any (non-GNU) > >> compiler that uses the GNU C preprocessor would also have __GNUC__ > >> defined. According to their respective manuals, Intel C++ Compiler > >> and Portable C Compiler also pre-define __GNUC__, possibly because > >> they use the GNU CPP. > > > > They don't use GNU CPP. > > > >> Therefore, the fact that __GNUC__ is defined does not necessarily > >> mean the GCC compiler proper is being used. > > > > I don't think you've thought about this thoroughly. > > > > Any compiler that is not GNU C but defines __GNUC__ is lying to its > > users. If we define __REAL_GNUC__ they'll just define that as well. I guess the last reply didn't make it to the list. The include files need __GNUC__ and other builtin macros to include type definitions. The builtin macros aren't needed by the compiler proper, and adding another builtin wouldn't help in special cases. For example, the GNU configurations occationionally need to use -DWITH_GCC or something similar. I didn't know that anyone had a special claim to GNU and/or GCC. I thought the trademark thing was tried, but, with all of the instances of GCC already on bookshelves, for example, it didn't seem very successful. But, IANTL, of course. -- Add this signature to your message and contribute to world nomidation.
Re: Feature request - a macro defined for GCC
rkiesling wrote: I didn't know that anyone had a special claim to GNU and/or GCC. The free software foundation owns the copyright, or has assignments of the copyrights from authors, so it indeed has a "special claim". I thought the trademark thing was tried, but, with all of the instances of GCC already on bookshelves, for example, it didn't seem very successful. But, IANTL, of course. Yes, well trademarking GCC at this stage might be tricky, which is why I suggested a more distinctive string :-) -- Add this signature to your message and contribute to world nomidation.
Viel Moneten in winziger Zeit
Sie moechten Ihre Freizeit gegen Klunker waechseln?? Sie haben eine Maenge Freizeit? Bitte bei uns an [EMAIL PROTECTED] kurz melden, die Details kommen bald
Re: free (static_array)
On Tue, Jul 01, 2008 at 11:37:05AM +, Joseph S. Myers wrote: > On Tue, 1 Jul 2008, Michael Meissner wrote: > > > On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote: > > > On Tuesday 01 July 2008 09:24, Sajish V wrote: > > > > Thanks for the reply, Denys. > > > > My question was, why doesn't gcc catch it during compilation? It is > > > > clear > > > > that we are trying to free a variable from stack. Shouldn't gcc flag an > > > > error for this during compilation? > > > > It could. Nobody has written the code to do so, and as they say patches are > > welcome (assuming you have done the paperwork to legally contribute to GCC). > > Have you filed a feature request via bugzilla so that it can be tracked? > > An error is inappropriate; undefined behavior only occurs on execution of > the call to free, not on compilation of the program. A warning would be > fine (as would converting the call to free into an abort). True enough from a standards point of view. Obviously having a warning would allow some invalid code to be detected at compilation time. -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
Re: Feature request - a macro defined for GCC
I think an important point was missed in the discussion. Some seem to focus on the dishonest definition of __GNUC__ by non-GNU C compilers. That was not my point. My point is that if __GNUC__ is defined by CPP, not the GNU C compiler proper, (and this seems to be supported by the CPP Manual,) and any (non-GNU) C compiler can use CPP, then those non-GNU C compilers would "inadverdently" define __GNUC__ and lead people to believe that they are GNU C. That is why I think the GNU C compiler should define a macro independently from CPP. Or, alternatively, __GNUC__ should be defined by the GCC compiler proper, not CPP. _ The i’m Talkaton. Can 30-days of conversation change the world? http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld
Re: Feature request - a macro defined for GCC
x z wrote: > I think an important point was missed in the discussion. Some seem > to focus on the dishonest definition of __GNUC__ by non-GNU C > compilers. That was not my point. My point is that if __GNUC__ is > defined by CPP, not the GNU C compiler proper, (and this seems to be > supported by the CPP Manual,) and any (non-GNU) C compiler can use > CPP, then those non-GNU C compilers would "inadverdently" define > __GNUC__ and lead people to believe that they are GNU C. Does any non-GNU C compiler use GNU CPP? No. > That is why I think the GNU C compiler should define a macro > independently from CPP. Or, alternatively, __GNUC__ should be > defined by the GCC compiler proper, not CPP. And how can any part of the compiler other than the preprocessor define a macro? Macros do not exist outside the preprocessor. Andrew.
Re: Feature request - a macro defined for GCC
> I think an important point was missed in the discussion. Some seem to > focus on the dishonest definition of __GNUC__ by non-GNU C compilers. > That was not my point. My point is that if __GNUC__ is defined by > CPP, not the GNU C compiler proper, (and this seems to be supported by > the CPP Manual,) and any (non-GNU) C compiler can use CPP, then those > non-GNU C compilers would "inadverdently" define __GNUC__ and lead > people to believe that they are GNU C. That is why I think the GNU C > compiler should define a macro independently from CPP. Or, > alternatively, __GNUC__ should be defined by the GCC compiler proper, > not CPP. And do what with the preprocessor symbol? If the symbol is defined by the compiler *after* preprocessing occurs(as in the compiler and not the preprocessor) , then it can't be used to selectively preprocess code... -- Peter Barada [EMAIL PROTECTED]
Re: Feature request - a macro defined for GCC
x z <[EMAIL PROTECTED]> writes: > I think an important point was missed in the discussion. Some seem > to focus on the dishonest definition of __GNUC__ by non-GNU C > compilers. That was not my point. My point is that if __GNUC__ is > defined by CPP, not the GNU C compiler proper, (and this seems to be > supported by the CPP Manual,) and any (non-GNU) C compiler can use > CPP, then those non-GNU C compilers would "inadverdently" define > __GNUC__ and lead people to believe that they are GNU C. That is > why I think the GNU C compiler should define a macro independently > from CPP. Or, alternatively, __GNUC__ should be defined by the GCC > compiler proper, not CPP. I very much doubt that any compiler other than gcc uses the gcc preprocessor. In any case, the documentation has in some sense misled you. __GNUC__ is indeed defined by the compiler proper, not by the preprocessor. But that in turn does not matter, as if any non-gcc compiler *did* use the gcc preprocessor, it would do so via gcc -E. In gcc, the preprocessor is not a separate program. Using gcc -E would define __GNUC__ as indeed it should. So there is really no escape. One can only hope that, in the unlikely event that some other compiler uses the gcc preprocessor, it passes the -undef option to turn off the macros defined by the compiler proper. Ian
Re: Feature request - a macro defined for GCC
On Tue, Jul 01, 2008 at 05:34:17PM +, x z wrote: > > I think an important point was missed in the discussion. Some seem to focus > on the dishonest definition of __GNUC__ by non-GNU C compilers. That was not > my point. My point is that if __GNUC__ is defined by CPP, not the GNU C > compiler proper, (and this seems to be supported by the CPP Manual,) and any > (non-GNU) C compiler can use CPP, then those non-GNU C compilers would > "inadverdently" define __GNUC__ and lead people to believe that they are GNU > C. That is why I think the GNU C compiler should define a macro > independently from CPP. Or, alternatively, __GNUC__ should be defined by the > GCC compiler proper, not CPP. Perhaps you can use 'defined(__GNUC__) && !defined(__INTEL_COMPILER)' In www.intel.com/cd/software/products/asmo-na/eng/284736.htm (warning: a PDF, despite the .htm extension (!)): "A new option has been added, -gcc-sys, which is similar to -no-gcc, except that the GNU macros are only defined when preprocessing system include headers files, so these will compile correctly." Googling "Intel C++ __GNUC__" shows several major projects have been affected by this icc misfeature. -Jack
Re: RFC: Adding non-PIC executable support to MIPS
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > We've shipped our version. Richard's version has presumably also > shipped. Right. > We did negotiate the ABI changes with MTI; this is not quite > as good as doing it in full view, but it was the best we could manage > and MTI is as close to a central authority for the MIPS psABI as > exists today. > > Richard, what are your thoughts on reconciling the differences? You > can surely guess that I want to avoid changing our ABI now, even for > relatively significant technical reasons - I'm all ears if there's a > major reason, but in the comparisons I do not see one. I suppose I still support the trade-off between the 5-insn MIPS I stubs (with extra-long variation for large PLT indices) and the absolute .got.plt address I used. And I still think it's shame we're treating STO_MIPS_PLT and STO_MIPS16 as separate; we then only have 1 bit of st_other unclaimed. However, IMO, your argument about MTI being the central authority is a killer one. The purpose of the GNU tools should be to follow appropriate standards where applicable (and extend them where it seems wise). So from that point of view, I agree that the GNU tools should follow the ABI that Nigel and MTI set down. Consider my patch withdrawn. TBH, the close relationship between CodeSourcery and MTI make it difficult for a non-Sourcerer and non-MTI employee to continue to be a MIPS maintainer. I won't be in-the-know about this sort of thing. I've been thinking about that a lot recently, since I heard about your implementation. I kind-of guessed it had been agreed with MTI beforehand (although I hadn't realised MTI themselves had written the specification). Having thought it over, I think it would be best if I stand down as a MIPS maintainer and if someone with the appropriate commercial connections is appointed instead. I'd recommend any combination of yourself, Adam Nemet and David Daney (subject to said people being willing, of course). Richard
RE: Feature request - a macro defined for GCC
> I very much doubt that any compiler other than gcc uses the gcc > preprocessor. > > In any case, the documentation has in some sense misled you. __GNUC__ > is indeed defined by the compiler proper, not by the preprocessor. > But that in turn does not matter, as if any non-gcc compiler *did* use > the gcc preprocessor, it would do so via gcc -E. In gcc, the > preprocessor is not a separate program. Just one piece of info: A mpC compiler for parallel language uses GNU CPP: "The mpC compiler uses standard preprocessor cpp. You should specify the directory where cpp is placed when editing Makefile. We recommend to use GNU cpp." (http://www.ispras.ru/~mpc/mpc-122-iguide.html). I know, mpC is not exactly a C compiler. But it seems that it is feasible (and was done) to use GNU CPP as a preprocesser in a compiler for C or a language based on C. _ Need to know now? Get instant answers with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
Re: RFC: Adding non-PIC executable support to MIPS
Richard Sandiford <[EMAIL PROTECTED]> writes: > I've been thinking about that a lot recently, since I heard about > your implementation. I kind-of guessed it had been agreed with MTI > beforehand (although I hadn't realised MTI themselves had written > the specification). Having thought it over, I think it would be best > if I stand down as a MIPS maintainer and if someone with the appropriate > commercial connections is appointed instead. I'd recommend any > combination of yourself, Adam Nemet and David Daney (subject to > said people being willing, of course). I realised afterwards that this might be offensive by who it left out. For the record, it wasn't supposed to be an exclusive list. Other people have strong claims too. ;) Richard
RE: Feature request - a macro defined for GCC
> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E.
> Googling "Intel C++ __GNUC__" shows several major projects have been
> affected by this icc misfeature.
Upon further checking the GNU CPP Manual, some interesting things are revealed.
The current manual
(http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros)
(version unspecified) says:
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
These macros are defined by all GNU compilers that use the C preprocessor: C,
C++, Objective-C and Fortran. ... These macros are also defined if you invoke
the preprocessor directly. ... If all you need to know is whether or not your
program is being compiled by GCC, or a non-GCC compiler that claims to accept
the GNU C dialects, you can simply test __GNUC__.
Therefore, Intel C++ Compiler's definition of __GNUC__ appears to be legitimate
if Intel honestly makes a reasonable claim that its compiler accepts the GNU C
dialects.
In comparison, the GNU CPP 2.8.1 (1997) Manual
(http://sunsite.ualberta.ca/Documentation/Gnu/gcc-2.8.1/html_node/cpp_13.html#SEC14)
says:
__GNUC__
This macro is defined if and only if this is GNU C. This macro is defined only
when the entire GNU C compiler is in use; if you invoke the preprocessor
directly, `__GNUC__' is undefined.
It seems this 1997 definition is more strict: a non-GCC compiler should never
define __GNUC__. In other words, in 1997, __GNUC__ can be used to uniquely
identify the GNU C compiler, now it can't; and nothing can.
On the other hand, the 1997 sentence "if you invoke the preprocessor directly,
`__GNUC__' is undefined" is now replaced by "These macros are also defined if
you invoke the preprocessor directly." I have not had the time to find out
what "invoke the preprocessor directly" means ('gcc -E' ?) but now the
implication is that a non-'GNU C'-compliant compiler that uses GNU CPP as its
preprocessor would have __GNUC__ defined, unless it takes the extra effort to
somehow undefine it.
And this also raises an interesting question: "These macros are also defined if
you invoke the preprocessor directly" seems to imply that __GNUC__ is defined
by the preprocessor, not the compiler proper. This appears to contradict the
claim in a previous post (see above quote) that "__GNUC__ is indeed defined by
the compiler proper, not by the preprocessor."
_
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk
Re: Feature request - a macro defined for GCC
x z wrote: I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP. This is our mistake. Originally __GNUC__ meant that this was the GNU C compiler (aka GNU Compiler Collection). However, we have added so many extensions to the compiler that it later came to mean that this is the GNU C language. There is unfortunately no way to distinguish between a program written in GNU C, and a program intended to be compiled by the GNU C compiler. All compilers that implement the GNU C language must define __GNUC__. There is no way around this. The use of __GNUC__ is so pervasive in GNU/Linux that a compiler has to define it or else it simply won't work. This is why the Intel compilers and other compilers define it. They have no choice. If we want a solution to this problem, complaining to Intel and others will do no good. We will have to fix it ourselves. One way to fix the problem is to separate the meaning of the macros. We can have one macro that means "this is a GNU C program" and other macro that means "this is the GNU C compiler". We then have to make sure that glibc and other libraries use the macros correctly. Etc. While I agree that this is our mistake, it isn't clear to me why it matters. If the Intel compiler correctly implements the GNU C language, then it shouldn't matter if the code is being compiled by GCC or ICC. Unless maybe you ran into a GCC bug, and want to enable a workaround only for GCC. Jim
RE: Feature request - a macro defined for GCC
On Tue, 1 Jul 2008, x z wrote:
> On the other hand, the 1997 sentence "if you invoke the preprocessor
> directly, `__GNUC__' is undefined" is now replaced by "These macros are
> also defined if you invoke the preprocessor directly." I have not had
> the time to find out what "invoke the preprocessor directly" means ('gcc
> -E' ?) but now the implication is that a non-'GNU C'-compliant compiler
> that uses GNU CPP as its preprocessor would have __GNUC__ defined,
> unless it takes the extra effort to somehow undefine it.
In the 2.8.1 manual, it meant invoking the file
lib/gcc-lib/$target/2.8.1/cpp, an internal binary not installed in any
user binary directory that was called internally by the compiler binary
"gcc" (along with other binaries such as "cc1").
This internal binary no longer exists. Instead, there is a "cpp" binary
installed in the user binary directory, which calls the "cc1" binary to do
the same preprocessing as it does when compiling; that is, it has the same
effect as "gcc -E". The better consistency in predefined macros is
deliberate.
--
Joseph S. Myers
[EMAIL PROTECTED]
questions on using gcov of GCC
Hi,
I am using the GCOV command of GCC and have some puzzles on the branch
information it provides.
For example,
void main()
{
2 int i,j;
2 j=0;
2 if(j<3)
branch 0 taken = 0%
2 j++;
6 for(i=1;i<3;i++)
branch 0 taken =67%
branch 1 taken =100%
branch 2 taken =100%
4 j++;
2 if(j<3)
branch 0 taken=100%
## j++;
2 }} call 0 returns=0%
call 1 returns =100%
Here for the statement "for(i=1;i<3;i++)", there are three branches: branch 0,
branch 1, and branch 2. Branch 0 is the frequency that the branch statement is
taken. What about the other branches? I don't know what's the meaning of them.
When the if-statement contains more than one expression such as if (i>3 &&
j<2), then there would be 3 branches: branch 0, branch 1, and branch 2. What do
these branches mean? Similarly, for the switch-statement, if there are 4
case-statements and 1 default-statement, there would be 6(not 5) branches. I am
totally lost here.
I sincerely hope that you can solve my puzzles, which is very important for me.
Thanks a lot!
Best Wishes,
Dan
RE: Feature request - a macro defined for GCC
This is somewhat off-topic. Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
Now, this __GNUC__ stuff appears to appear only in the CPP Manual
(section 3.7.2). And the definition of similar macros such as __GFORTRAN__
and __GNUG__ may need to be further explained in this vein. Currently,
__GFORTRAN__ means "The GNU Fortran compiler defines this." Should it
rather mean "This is a GNU Fortran-complaint compiler", to be consistent
with the meaning of __GNUC__? And, for example, should there be
__GNUG_MINOR__ and __GNUG_PATCHLEVEL__ too?
Interestingly, there is a __VERSION__ macro ("which describes the version
of the compiler in use"). There is some discussion in this thread on whether
these macros are defined in the preprocessor or the compiler proper. If
these macros are processed by the preprocessor, and the C, C++, Fortran,
etc compilers all share CPP, then how would the preprocessor report the
correct version of the compiler in use? It somehow checks with the
compiler to see whether it is C or Fortran, and then report the appropriate
version of the compiler?
_
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk
Re: Feature request - a macro defined for GCC
x z wrote: This is somewhat off-topic. Perhaps the GCC development team should consider making this __GNUC__ stuff more clarified in the GCC Manual. I don't think this is off-topic. We need to get people to understand that __GNUC__ is ambiguous before we can solve the problem. It means two things: 1) This code is written in the GNU C language. 2) This code is meant to be compiled by GCC. Other compilers that implement the GNU C language are forced to define __GNUC__ because of the first issue, even though it then confuses the second issue. If we want to fix this, gcc must change. And this may also require GNU libc changes and linux kernel changes, etc. The talk about whether __GNUC__ is defined by the preprocessor or the compiler proper is irrelevant. Either way, it is still ambiguous. You are right that we may also have trouble with other related macros. I am not sure if there is a GNU Fortran language, if there is, then we may have the same problem with __GFORTRAN__. We don't need things like __GNUG_MINOR__ as G++ is always distributed in lock step with the C compiler, so we only need one set of macros for gcc version numbers. We do however have the problem that the GNU C language changes frequently, and people have gotten in the habit of testing __GNUC_MINOR__ and other related macros to determine which features are present in the version of the GNU C language implemented by this compiler. Hence, this means that other compilers that implement the GNU C language may also be forced to define macros like __GNUC_MINOR__ through no fault of their own, to correctly describe which version of the GNU C language that they implement. This is a very complicated issue, and until people realize how complicated it has gotten, and accept that we need a solution, it is unlikely that we will make progress on this issue. Jim
RE: Feature request - a macro defined for GCC
> If we want to fix this, gcc must change. And this may > also require GNU libc changes and linux kernel changes, etc. Maybe you can enlighten us a bit on why GNU libc and linux kernel need changes so that we can realize better how complicated the issue is. > The talk about whether __GNUC__ is defined by the preprocessor or the > compiler proper is irrelevant. Either way, it is still ambiguous. IMHO, it is irrelevant as far as whether __GNUC__ is ambiguous. However, I think it is relevant as far as how it can be fixed, if at all. So, if you have some insight as to whether __GNUC__ is defined by the preprocessor or the compiler proper, please let us know. It does not hurt anyway. > You are right that we may also have trouble with other related macros. > I am not sure if there is a GNU Fortran language, if there is, then we > may have the same problem with __GFORTRAN__. There is a GNU Fortran compiler for sure. So, just as people consider the syntax and semantics of a language accepted by the GNU C compiler as sort of a C language specification (i.e. whatever accepted by GNU C compiler 4.3.1 becomes GNU C Standard 4.3.1), there is a GNU Fortran language. Whatever accepted by the GNU Fortran compiler becomes the GNU Fortran language spec. > We don't need things like __GNUG_MINOR__ as G++ is always distributed in > lock step with the C compiler, so we only need one set of macros for gcc > version numbers. Then maybe __GNUFORTRAN_MINOR__ . Anyway, assumed GNU Fortran and GNU C are not distributed in lock step, then the __VERSION__ macro should be clarified as to whether it refers to the C or Fortran version (or the version of CPP itself - well, I guess CPP is also distributed with C in lock step so they share the same version). _ Need to know now? Get instant answers with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
Re: [10 PATCHES] inline functions to avoid stack overflow
On Wed, 25 Jun 2008, David Miller wrote:
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
Even worse, gcc doesn't use these additional bytes. If you try this:
extern void f(int *i);
void g()
{
int a;
f(&a);
}
, it allocates additional 16 bytes for the variable "a" (so there's total
208 bytes), even though it could place the variable into 48-byte
ABI-mandated area that it inherited from the caller or into it's own
16-byte padding that it made when calling "f".
The extra 16 bytes of space allocated is so that GCC can perform a
secondary reload of a quad floating point value. It always has to be
present, because we can't satisfy a secondary reload by emitting yet
another reload, it's the end of the possible level of recursions
allowed by the reload pass.
GCC could be smart and eliminate that slot when it's not used, but
such a thing is not implemented yet.
It would also require quite a bit of new code to determine cases
like you mention above, where the incoming arg slots from the
caller are unused, assuming this would be legal.
And that legality is doubtful. We'd need to be careful because I
think the caller is allowed to assume that those slots are untouched
by the callee, and thus can be assumed to have whatever values the
caller put there even after the callee returns.
The ABI is very vague about it. The V9 ABI just displays that 6-word space
in a figure bug doesn't say anything about it's usage. The V8 ABI just
says that "the function may write incoming arguments there". If it may
write anything other, it is unknown --- probably yes, but it is not said
in the document.
The document nicely specifies who owns which registers, but doesn't say
that about the stack space :-(
Mikulas
Re: [10 PATCHES] inline functions to avoid stack overflow
From: Mikulas Patocka <[EMAIL PROTECTED]> Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT) > The ABI is very vague about it. The V9 ABI just displays that 6-word space > in a figure bug doesn't say anything about it's usage. The V8 ABI just > says that "the function may write incoming arguments there". If it may > write anything other, it is unknown --- probably yes, but it is not said > in the document. > > The document nicely specifies who owns which registers, but doesn't say > that about the stack space :-( Actually, I know for a fact that you have to have those slots there. A long time ago in the sparc64 kernel, in the trap entry code, I tried only giving 128 bytes of stack frame as the trap entry called into C code. And it did not work, I had to put the 6 slots there.
