branches within C++ destructors
HI all,
I have another query related to virtual destructor in gcc.
In present gcc version 4.4.3 for class for sample program:-
class A
{
public:
A()
{
}
virtual ~A();
};
A::~A()
{
}
int main(int argc, char ** argv)
{
A a;
return 0;
}
--
we have only two branches as:-
---
-:8:virtual ~A();
-:9:};
function A::~A() called 1 returned 100% blocks executed 75%
function A::~A() called 0 returned 0% blocks executed 0%
1: 10:A::~A()
-: 11:{
1: 12:}
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
call2 never executed
call3 never executed
call4 never executed
--
which I has interpreted as :
In virtual destructor there are actually two destructors in which one
takes care about base classes and other about the same class.(am I
correct ??) So to have two branches looks OK
But for same program the result are different in gcc version 4.1.2.The
result contains 6 branches and the output is as :
8:virtual ~A();
-:9:};
function A::~A() called 0 returned 0% blocks executed 0%
function A::~A() called 1 returned 100% blocks executed 75%
function A::~A() called 0 returned 0% blocks executed 0%
1: 10:A::~A()
-: 11:{
1: 12:}
branch 0 never executed
branch 1 never executed
call2 never executed
branch 3 taken 0% (fallthrough)
branch 4 taken 100%
call5 never executed
branch 6 never executed
branch 7 never executed
call8 never executed
-: 13
---
Can someone tell me the logic about these branches and what optimizer
improvements were done in newer version.
==
Also in the gcov branch coverage we have something like at end of code :-
function __static_initialization_and_destruction_0(int, int) called 1
returned 100% blocks executed 100%
function global constructors keyed to main called 1 returned 100% blocks
executed 100%
3: 54:}
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
branch 2 taken 100% (fallthrough)
branch 3 taken 0%
call4 returned 100%
It is not the part of actual code, why do we have it and what its
significance in terms of branches . Can we omit it from the coverage??
Thanks,
ROHIT
Re: Change x86 default arch for 4.5?
On 02/25/2010 08:07 AM, Uros Bizjak wrote: On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill wrote: On 02/18/2010 07:46 PM, Joseph S. Myers wrote: On Thu, 18 Feb 2010, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? My position remains that configuring for i686-* should default to -march=i686 rather than -mtune=i686. http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html Perhaps someone would like to review HJ's patch to that effect? http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html Perhaps one of the i386 maintainers? The default arch should be based on what _users_ expect from the configure process, so it is IMO up to distributors and finally Release Managers to decide. As far as the proposed patch is concerned, I think that it is the step in the right direction, and is OK for 4.6, but also please also add -march=native choice. It works OK nowadays. Since this is build patch, it also needs OK from build maintainer (CCd). There are plenty of global reviewers in the CC list. :-) Paolo
Re: a gcc plugin to show cfg graphically when debug gcc
On Thu, Feb 25, 2010 at 8:48 AM, Eric Fisher wrote: > Hi, > > I just wrote a little gcc plugin, which can be used to show GIMPLE cfg > graphically when debug gcc. Currently, it's still a very initial > version. It, > * transfers tree dump into vcg file, > * then invokes vcgview (or aisee etc.) to show the graph. > > I would like to improve it to support both tree level and rtl level > vcg visualization later. > > Any suggestions would be appreciated. > > http://code.google.com/p/toolbox-of-eric/ I've been using the attached in debug sessions a lot (and I have similar patch for the cgraph). I've been wanting to transform this into a gdb python script but sofar didn't get along to do it ... The nice thing with using dot is that it listens to file changes and so with xlib output you get a nice cfg "movie" when invoking the generation function when hitting a breakpoint. Richard. > Thanks, > Eric > gimple-cfg2dot Description: Binary data
Overhead in C and C++
Hellow gcc,
i'm working on the topic "overhead and codesize in C and C++". The goal of
this work is to find out, why C++ is not as fast as normal C code (in same
application).
But already by the beginning we found out something very interesting.
The Code:
int main(int argc, char *argv[])
{
return 0;
}
No function so far. But this compiled with gcc and g++ (on Linux Redhead EL5,
Intel Xeon 5130 (x86_64))
Codesize in C: 7820
Codesize in C++: 8175
But much more interesting is the number of instructions (mesured with
callgrind/kcachegrind):
For main:
Ir in C: 7
Ir in C++: 7
Whole program (you see, there is no include)
Ir in C: 80 158 (a lot)
Ir in C++: 1 295 980 (massive!!)
C++ has a mulitple of C-Instructions. Why is that such enorm?
Is there any idea or better documenation about this topic? Thank you for your
answer
Regards from Switzerland
MAC
Re: Overhead in C and C++
On Thu, Feb 25, 2010 at 3:35 PM, wrote:
> Hellow gcc,
>
> i'm working on the topic "overhead and codesize in C and C++". The goal of
> this work is to find out, why C++ is not as fast as normal C code (in same
> application).
>
> But already by the beginning we found out something very interesting.
>
> The Code:
> int main(int argc, char *argv[])
> {
> return 0;
> }
> No function so far. But this compiled with gcc and g++ (on Linux Redhead EL5,
> Intel Xeon 5130 (x86_64))
>
> Codesize in C: 7820
> Codesize in C++: 8175
>
> But much more interesting is the number of instructions (mesured with
> callgrind/kcachegrind):
> For main:
> Ir in C: 7
> Ir in C++: 7
> Whole program (you see, there is no include)
> Ir in C: 80 158 (a lot)
> Ir in C++: 1 295 980 (massive!!)
>
> C++ has a mulitple of C-Instructions. Why is that such enorm?
>
> Is there any idea or better documenation about this topic? Thank you for your
> answer
The least you should do before anyone can answer this, is tell us what
compiler options you used.
Ciao!
Steven
Re: Defining a libgnat.so, libgnarl.so ABI
On 02/25/2010 08:51 AM, Arnaud Charlet wrote:
The main "mangling" (in Ada parlance, we talk rather about "encoding")
that is performed by GNAT is to handle packages ("namespace" in C++) and
to differentiate overloaded functions (and there, a simple counter is all
that is needed).
One of the advantages of "mangling" overloaded functions C++-style,
instead of using a simple counter is that the latter makes it basically
impossible to define a stable ABI.
Paolo
RE: Overhead in C and C++
> i'm working on the topic "overhead and codesize in C and C++". The
> goal of this work is to find out, why C++ is not as fast as normal C
> code (in same application).
Why do you believe this is true?
> But already by the beginning we found out something very interesting.
>
> The Code:
> int main(int argc, char *argv[])
> {
> return 0;
> }
> No function so far. But this compiled with gcc and g++ (on Linux
> Redhead EL5, Intel Xeon 5130 (x86_64))
>
> Codesize in C: 7820
> Codesize in C++: 8175
>
> But much more interesting is the number of instructions (mesured with
> callgrind/kcachegrind):
> For main:
> Ir in C: 7
> Ir in C++: 7
Well, of course.
> Whole program (you see, there is no include)
> Ir in C: 80 158 (a lot)
> Ir in C++: 1 295 980 (massive!!)
So? You started out asking about performance. Code size is a completely
independent property. Since the semantics of C++ are more complex than those
of C (due to things like constructors, exceptions, etc.) it is to be expected
that a complete program is slightly larger. That doesn't mean it is slower.
Note also that a valid comparison is between C++ and equivalent C. For
example, a comparison between regular function calls in C and virtual method
calls in C++ is invalid. A comparison between virtual method calls in C++ and
calls through a table of function pointers in C is valid -- and will produce
the same performance since you are in fact doing the same thing.
paul
Re: Defining a libgnat.so, libgnarl.so ABI
> One of the advantages of "mangling" overloaded functions C++-style, instead > of using a simple counter is that the latter makes it basically impossible > to define a stable ABI. It actually is not such a problem in Ada, where declarations are first class citizens with specific rules about placement, etc..., and order of declarations is something you can count on. Arno
Re: Defining a libgnat.so, libgnarl.so ABI
On Wed, 2010-02-24 at 16:10 +0100, Rainer Orth wrote: > As the last of the shared GCC runtime libraries, libgnat.so and > libgnarl.so lack symbol versioning support and a defined ABI. > Currently, they use libgnat-4.5.so and libgnarl-4.5.so SONAMEs, what > libtool calls release versioning. If the libgnat/libgnarl ABI is really > that fluent that it changes from release to release, there's obviously > no point in defining one, but given the Ada Reference Manual, I cannot > really believe this, but assume that this is just being cautious. The Ada reference manual gives lots of freedom for compiler implementors to perform optimizations (1). Inventing an ABI in addition to the work it represents by itself will likely restrict the allowable optimizations for all future compilers and generally increase the maintenance burden of future compilers. Also the Ada reference manual provides the "Restrictions" pragma, each one allowing more optimizations by disallowing use of certain language feature. How do we handle the possible 2^N combinations of Restrictions pragmas in an "ABI" document? On the other side what do we gain then from setting in stone forever an "Ada" (really GCC-specific) ABI compared to the current situation of per-branch SONAME? Note that the Ada language allows those who want to set in stone their library ABI to do so via Import/Export pragmas, reusing C/C++/Fortran existing ABIs where possible. Sincerely, Laurent (1) Example of such optimizations that would break an "Ada" ABI: 2005-06-14 Jose Ruiz Arnaud Charlet * a-sytaco.ads, a-sytaco.adb (Suspension_Object): These objects are no longer protected objects. They have been replaced by lower-level suspension objects made up by a mutex and a condition variable (or their equivalent given a particular OS) plus some internal data to reflect the state of the suspension object. (Initialize, Finalize): Add this initialization procedure for Suspension_Object, which is a controlled type. (Finalize): Add the finalization procedure for Suspension_Object, which is a controlled type.
Re: Change x86 default arch for 4.5?
On Thu, Feb 25, 2010 at 2:01 PM, Jason Merrill wrote: > On 02/25/2010 05:37 AM, Paolo Bonzini wrote: >>> >>> Since this is build patch, it also needs OK from build maintainer (CCd). >> >> There are plenty of global reviewers in the CC list. :-) > > Yep, I've just been trying to get people who might know why the status quo > is the way it is to weigh in before I approve it. > > H.J., could you update your patch to support --with-arch/cpu=native as Uros > requested? > Here it is: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01095.html -- H.J.
Re: Change x86 default arch for 4.5?
On 02/25/2010 05:37 AM, Paolo Bonzini wrote: Since this is build patch, it also needs OK from build maintainer (CCd). There are plenty of global reviewers in the CC list. :-) Yep, I've just been trying to get people who might know why the status quo is the way it is to weigh in before I approve it. H.J., could you update your patch to support --with-arch/cpu=native as Uros requested? Jason
gcc-4.5-20100225 is now available
Snapshot gcc-4.5-20100225 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100225/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 157074 You'll find: gcc-4.5-20100225.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100225.tar.bz2 C front end and core compiler gcc-ada-4.5-20100225.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100225.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100225.tar.bz2 C++ front end and runtime gcc-java-4.5-20100225.tar.bz2 Java front end and runtime gcc-objc-4.5-20100225.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100225.tar.bz2The GCC testsuite Diffs from 4.5-20100218 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
