Re: New branch opened: dataflow-branch

[Steven Bosscher]

On Thursday 06 October 2005 16:17, Daniel Berlin wrote:
> This branch contains the work Ken Zadeck and I have been doing
> replacing the backend dataflow (such as live register analysis) with
> df.c based dataflow.

Very cool! :-)

Gr.
Steven

Speed impact of virtual inheritance

[Frans Englich]

Hello all,

In a large project I'm participating in, a design dilemma have arrived. Adding 
virtual inheritance would solve it beautifully on the source code level, but 
a potential drawback is the speed penalty it brings. Measurement is always 
the way of approaching performance questions, but since that sometimes can be 
tricky, I thought of starting with getting a theoretical understanding of 
virtual inheritance.

Consider this code:

//--
class Shared
{
public:
Shared() : m_ref(0) { }
virtual ~Shared() { }

int refCount() const { return m_ref; }

void ref() { m_ref++; }

void deref()
{
if(m_ref) m_ref--;
if(!m_ref) delete this;
}

protected:
unsigned int m_ref;
};

class B : public virtual Shared {};
class C : public virtual Shared {};
class D : public Shared {};
class BC : public B, public C {};
class DerivedB : public B {};
//--

Follows do plenty of questions:

* Is class DerivedB in anyway affected by that its sub class B is a public 
virtual of Shared? And if so, how?

* What are the differences in memory usage between an instance of class D and 
an instance of class B? (if any)

* What are the performance differences of invoking BCinstance->ref() compared 
to Dinstance->ref()?

* What are the performance differences in constructing and destructing an 
instance of class BC and D?

Speaking in general terms, what are the penalties of virtual inheritance? 

Consider that a class previously was as class D, and then became class BC. How 
would that affect performance? Hard to tell? Definitely a performance 
disaster? Or perhaps that "the additional level of indirection has a slight 
performance overhead, but it's a small price to pay"?[1]

Detailed replies, pointers to documentation, is much appreciated. A googling 
showed relatively contradictory results on the performance of virtual 
inheritance, so solid information would be a relief(explanations to why it is 
as it is would also be interesting to hear).


Thanks in advance,

Frans

1.
http://www.devx.com/tips/Tip/12789

Re: Speed impact of virtual inheritance

[Jonathan Wakely]

Frans Englich wrote:

> In a large project I'm participating in, a design dilemma have arrived. 
> Adding 
> virtual inheritance would solve it beautifully on the source code level, but 
> a potential drawback is the speed penalty it brings. Measurement is always 
> the way of approaching performance questions, but since that sometimes can be 
> tricky, I thought of starting with getting a theoretical understanding of 
> virtual inheritance.

If you don't mean "virtual inheritance as implemented by GCC" then this
is probably the wrong place for such a question.

For an understanding of how it's implemented try "Inside the C++ Object
Model" by Stan Lippmann, and this draft report (especially section 5.3.6)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1666.pdf

That's by a well-respected member of the standard committee, so you can
take it pretty seriously.  I'd certainly give it more credence than
unsubstantiated claims thrown up by googling.

Regards,

jon

Successful gcc 4.0.2 build on alphaev68-dec-osf5.1bTru64(c,c++,f95,objc,java,treelang)

[Stefano Curtarolo, Ph.D.]

Dear list,


[EMAIL PROTECTED]:~/GNU/gcc-4.0.2/SRC#gcc -v
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with:
../configure
--host=alphaev68-dec-osf5.1b
--enable-threads=posix
--enable-languages=c,c++,f95,objc,java,treelang
--prefix=/usr/local
--enable-version-specific-runtime-libs
--enable-shared
--enable-libgcj
--enable-nls
--enable-interpreter
Thread model: posix
gcc version 4.0.2


see my previous email:
http://gcc.gnu.org/ml/gcc/2005-07/msg00601.html
for f95 and java compilation.


Sincerely,
Stefano Curtarolo


--
Prof. Stefano Curtarolo
Assistant Professor of Materials Science
Duke University, Dept. Mechanical Engineering and Materials Science
144 Hudson Hall, Box 90300, Durham, NC  27708-0300
phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu
--

The chief enemy of creativity is "good" sense (Picasso).
Conformity is the refuge of the unimaginative.

Re: Speed impact of virtual inheritance

[Frans Englich]

On Monday 10 October 2005 16:12, Jonathan Wakely wrote:
> Frans Englich wrote:
> > In a large project I'm participating in, a design dilemma have arrived.
> > Adding virtual inheritance would solve it beautifully on the source code
> > level, but a potential drawback is the speed penalty it brings.
> > Measurement is always the way of approaching performance questions, but
> > since that sometimes can be tricky, I thought of starting with getting a
> > theoretical understanding of virtual inheritance.
>
> If you don't mean "virtual inheritance as implemented by GCC" then this
> is probably the wrong place for such a question.

Yes, sorry for not being specific on that. It was concerning GCC, more 
specifically 3.3 and/or 4.0. (If there's anything specific to GCC not 
mentioned in the below referenced draft report, I will of course with 
interest read it).

> For an understanding of how it's implemented try "Inside the C++ Object
> Model" by Stan Lippmann, and this draft report (especially section 5.3.6)
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1666.pdf
>
> That's by a well-respected member of the standard committee, so you can
> take it pretty seriously.  I'd certainly give it more credence than
> unsubstantiated claims thrown up by googling.

Exactly, that's what's needed.


Thanks,

Frans

Mainline now closed to all changes which do not fix regressions

[Mark Mitchell]

As previously announced, here:

http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html

the mainline is now subject to the usual release-branch rules: only
fixes for regressions.

The goal is to quickly reduce the current 219 oustanding regressions
against 4.1 to approximately 100 -- in part by me retargeting some of
the bugs -- so that we can create the 4.1 release branch.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Mainline now closed to all changes which do not fix regressions

[Steven Bosscher]

On Monday 10 October 2005 19:35, Mark Mitchell wrote:
> As previously announced, here:
>
> http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html
>
> the mainline is now subject to the usual release-branch rules: only
> fixes for regressions.

How does this affect gfortran, and what about already posted
but still unreviewed patches?

Gr.
Steven

Re: Mainline now closed to all changes which do not fix regressions

[Mark Mitchell]

Steven Bosscher wrote:
> On Monday 10 October 2005 19:35, Mark Mitchell wrote:
> 
>>As previously announced, here:
>>
>>http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html
>>
>>the mainline is now subject to the usual release-branch rules: only
>>fixes for regressions.
> 
> 
> How does this affect gfortran, and what about already posted
> but still unreviewed patches?

I'm still willing to consider gfortran a special case.  (After 4.1, that
will probably no longer be true.)  So, you can be more lenient with
gfortran.

Outstanding unreviewed patches may still be applied, after review.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: RFC: IPO optimization framework for GCC

[Devang Patel]

On 10/7/05, Steve Ellcey <[EMAIL PROTECTED]> wrote:

[snip]

> In the meantime I would be interested in any opinions people have on
> what level we should be writing things out at.  Generic?  Gimple?  RTL?
> (Just kidding on that last one.)  Also any opinions on what format to
> write things out in; binary form vs. an ascii file, XML?  ANDF?  If you
> know of any good papers I should read I would like to hear about those
> too.

It is useful to get clear understanding of few simpler things before
tackling IL issue.

First question is - What is the user interface ? Few alternatives :

1)  gcc  -fenable-ipo input1.c input2.c input3.c -o output

 Here, writing IL on the disk, and reading it back, and optimizing it,
etc.. are all hidden from users.

2)  gcc  -fwrite-ipo input1.c -o input1.data
 gcc  -fwrite-ipo input2.c -o input2.data
 gcc  -fwrite-ipo input3.c -o input3.data

 gcc  -fread-ipo input1.data input2.data input3.data -o output

3)  gcc  -fwrite-ipo input1.c -o input1.data
 gcc  -fuse-ipo input1.data input2.c -o input2.data
 gcc  -fuse-ipo input2.data input3.c -o output

4)  gcc  -fwrite-ipo input1.c -o input1.data
 gcc  -fwrite-ipo input2.c -o input2.data
 gcc  -fwrite-ipo input3.c -o input3.data

 glo  -fread-ipo input1.data input2.data input3.data -o output

and so on...

Second question is - When to put info on the disk? Few alternatives,
1) Before gimplfication
2) Before optimizing tree-ssa
3) After tree-ssa optimization is complete
4) Immediately after generating RTL
5) Halfway throuh RTL passes
etc.. And answer to this question largely depend on the optimization
passes that work on whole program info.

I do not know whether these two questions are already answered or not.

And finally, reading and writing one or other form of trees (GENERIC,
GIMPLE,...), it is not a show stopper. It can be done as a last resort,
but you want to check all possible alternatives first.

-
Devang

Re: Speed impact of virtual inheritance

[Mark Mitchell]

Frans Englich wrote:
> Hello all,
> 
> In a large project I'm participating in, a design dilemma have arrived. 
> Adding 
> virtual inheritance would solve it beautifully on the source code level, but 
> a potential drawback is the speed penalty it brings. Measurement is always 
> the way of approaching performance questions, but since that sometimes can be 
> tricky, I thought of starting with getting a theoretical understanding of 
> virtual inheritance.

In GCC, the performance cost is very slight.

In constrast to older implementations (in GCC and other compilers),
there is very little cost in terms of bytes per object for use virtual
inheritance.  (The only cost is that the most derived class must have a
virtual table pointer; if the hierarchy has at least one virtual
function, then there is no additional cost relative to that.)  There is
an increase in the size of the virtual table (of which there is one
instance per class, not one instance per object) proportionate to the
number of virtual base classes.

The execution-time cost is two memory references required when casting
to a virtual base class (as opposed to zero in the case of a cast to a
non-vritual base class).  Calling a virtual function will require a few
additional instructions if virtual bases are involved; however, a
function call is itself expensive, and virtual function calls typically
cause i-cache misses, so the virtual-base part of the cost is quite small.

There may be negative secondary optimization effects if the optimizers
are no longer able to reason effectively about your code.

My advice would be to use virtual bases in your class hierarchy where
that seems attractive from a design point of view, but to avoid virtual
function calls to small functions in performance critical loops, whether
or not your hierarchy uses virtual bases.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

[gomp]

[Christian Joensson]

well, trying to build the gomp branch, LAST_UPDATED: Mon Oct 10
16:34:17 UTC 2005, on this system:

Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:

(auroralinux corona + rathann's and rzm's FC3 updates)

binutils-2.16.91.0.2-4.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.3-22.sparc.sparc
gcc4-4.0.0-0.41.sparc.sparc
glibc-2.3.5-0.fc3.1.sparcv9
glibc-2.3.5-0.fc3.1.sparc64
glibc-devel-2.3.5-0.fc3.1.sparc
glibc-devel-2.3.5-0.fc3.1.sparc64
glibc-headers-2.3.5-0.fc3.1.sparc
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.12-1.1505sp3.sparc64
package kernel-devel is not installed
package kernel-smp is not installed
libgcc-3.4.3-22.sparc.sparc
libgcc-3.4.3-22.sparc.sparc64
libstdc++-3.4.3-22.sparc.sparc
libstdc++-3.4.3-22.sparc.sparc64
libstdc++-devel-3.4.3-22.sparc.sparc
libstdc++-devel-3.4.3-22.sparc.sparc64
make-3.80-5.sparc
nptl-devel-2.3.5-0.fc3.1.sparcv9
tcl-8.4.7-2.sparc

../gcc.gomp/configure   --enable-__cxa_atexit --enable-shared --with-cpu=v7 --
enable-languages=c,ada,c++,fortran,java,objc,treelang

sparc64-linux

I get this error:

/bin/sh ./libtool --tag=GCJ --mode=link
/usr/local/src/branch/objdir.gomp/gcc/gcj
-B/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/
-B/usr/local/src/branch/objdir.gomp/gcc/
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava
-g -O2  -m64 -m64 -o jv-convert --main=gnu.gcj.convert.Convert -rpath
/usr/local/lib/../lib64 -shared-libgcc  
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/.libs
libgcj.la
/usr/local/src/branch/objdir.gomp/gcc/gcj
-B/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/
-B/usr/local/src/branch/objdir.gomp/gcc/ -g -O2 -m64 -m64 -o
.libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc 
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/.libs
./.libs/libgcj.so
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libstdc++-v3/src
-L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs
-lpthread -ldl -L/usr/local/src/branch/objdir.gomp/./gcc/64
-L/usr/local/lib -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc
-lgcc_s -Wl,--rpath -Wl,/usr/local/lib/../lib64
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::isArray()'
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::getComponentType()'
./.libs/libgcj.so: undefined reference to `_Jv_InitClass'
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::isInterface()'
./.libs/libgcj.so: undefined reference to
`java::lang::Class::getComponentType()'
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::getModifiers()'
./.libs/libgcj.so: undefined reference to `java::lang::Class::getModifiers()'
./.libs/libgcj.so: undefined reference to `java::lang::Class::isPrimitive()'
./.libs/libgcj.so: undefined reference to `java::lang::Class::isInterface()'
./.libs/libgcj.so: undefined reference to `java::lang::Class::isArray()'
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::getSuperclass()'
./.libs/libgcj.so: undefined reference to `java::lang::Class::getSuperclass()'
./.libs/libgcj.so: undefined reference to `hidden alias for
java::lang::Class::isPrimitive()'
collect2: ld returned 1 exit status
make[6]: *** [jv-convert] Error 1
make[6]: Leaving directory
`/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
`/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
`/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/libjava'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
`/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/libjava'
make[2]: *** [all-target-libjava] Error 2
make[2]: Leaving directory `/usr/local/src/branch/objdir.gomp'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/branch/objdir.gomp'
make: *** [bubblestrap] Error 2
[EMAIL PROTECTED] objdir.gomp]$

Is gomp not doing java yet?

--
Cheers,

/ChJ

Re: [gomp] libgcj.so: undefined reference to `hidden alias for java::lang::Class::isArray()' and more...

[Christian Joensson]

Sorry, I forgot the subject...

On 10/10/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> well, trying to build the gomp branch, LAST_UPDATED: Mon Oct 10
> 16:34:17 UTC 2005, on this system:
>
> Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:
>
> (auroralinux corona + rathann's and rzm's FC3 updates)
>
> binutils-2.16.91.0.2-4.sparc
> bison-1.875c-2.sparc
> dejagnu-1.4.4-2.noarch
> expect-5.42.1-1.sparc
> gcc-3.4.3-22.sparc.sparc
> gcc4-4.0.0-0.41.sparc.sparc
> glibc-2.3.5-0.fc3.1.sparcv9
> glibc-2.3.5-0.fc3.1.sparc64
> glibc-devel-2.3.5-0.fc3.1.sparc
> glibc-devel-2.3.5-0.fc3.1.sparc64
> glibc-headers-2.3.5-0.fc3.1.sparc
> glibc-kernheaders-2.6-20sparc.sparc
> gmp-4.1.4-3sparc.sparc
> gmp-4.1.4-3sparc.sparc64
> gmp-devel-4.1.4-3sparc.sparc
> gmp-devel-4.1.4-3sparc.sparc64
> kernel-2.6.12-1.1505sp3.sparc64
> package kernel-devel is not installed
> package kernel-smp is not installed
> libgcc-3.4.3-22.sparc.sparc
> libgcc-3.4.3-22.sparc.sparc64
> libstdc++-3.4.3-22.sparc.sparc
> libstdc++-3.4.3-22.sparc.sparc64
> libstdc++-devel-3.4.3-22.sparc.sparc
> libstdc++-devel-3.4.3-22.sparc.sparc64
> make-3.80-5.sparc
> nptl-devel-2.3.5-0.fc3.1.sparcv9
> tcl-8.4.7-2.sparc
>
> ../gcc.gomp/configure   --enable-__cxa_atexit --enable-shared --with-cpu=v7 --
> enable-languages=c,ada,c++,fortran,java,objc,treelang
>
> sparc64-linux
>
> I get this error:
>
> /bin/sh ./libtool --tag=GCJ --mode=link
> /usr/local/src/branch/objdir.gomp/gcc/gcj
> -B/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/
> -B/usr/local/src/branch/objdir.gomp/gcc/
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava
> -g -O2  -m64 -m64 -o jv-convert --main=gnu.gcj.convert.Convert -rpath
> /usr/local/lib/../lib64 -shared-libgcc
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/.libs
> libgcj.la
> /usr/local/src/branch/objdir.gomp/gcc/gcj
> -B/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/
> -B/usr/local/src/branch/objdir.gomp/gcc/ -g -O2 -m64 -m64 -o
> .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava/.libs
> ./.libs/libgcj.so
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libstdc++-v3/src
> -L/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libstdc++-v3/src/.libs
> -lpthread -ldl -L/usr/local/src/branch/objdir.gomp/./gcc/64
> -L/usr/local/lib -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc
> -lgcc_s -Wl,--rpath -Wl,/usr/local/lib/../lib64
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::isArray()'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::getComponentType()'
> ./.libs/libgcj.so: undefined reference to `_Jv_InitClass'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::isInterface()'
> ./.libs/libgcj.so: undefined reference to
> `java::lang::Class::getComponentType()'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::getModifiers()'
> ./.libs/libgcj.so: undefined reference to `java::lang::Class::getModifiers()'
> ./.libs/libgcj.so: undefined reference to `java::lang::Class::isPrimitive()'
> ./.libs/libgcj.so: undefined reference to `java::lang::Class::isInterface()'
> ./.libs/libgcj.so: undefined reference to `java::lang::Class::isArray()'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::getSuperclass()'
> ./.libs/libgcj.so: undefined reference to `java::lang::Class::getSuperclass()'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> java::lang::Class::isPrimitive()'
> collect2: ld returned 1 exit status
> make[6]: *** [jv-convert] Error 1
> make[6]: Leaving directory
> `/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava'
> make[5]: *** [all-recursive] Error 1
> make[5]: Leaving directory
> `/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/64/libjava'
> make[4]: *** [multi-do] Error 1
> make[4]: Leaving directory
> `/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/libjava'
> make[3]: *** [all-multi] Error 2
> make[3]: Leaving directory
> `/usr/local/src/branch/objdir.gomp/sparc64-unknown-linux-gnu/libjava'
> make[2]: *** [all-target-libjava] Error 2
> make[2]: Leaving directory `/usr/local/src/branch/objdir.gomp'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/branch/objdir.gomp'
> make: *** [bubblestrap] Error 2
> [EMAIL PROTECTED] objdir.gomp]$
>
> Is gomp not doing java yet?
>
> --
> Cheers,
>
> /ChJ
>


--
Cheers,

/ChJ

Re: [gomp] libgcj.so: undefined reference to `hidden alias for java::lang::Class::isArray()' and more...

[Diego Novillo]

On Monday 10 October 2005 16:51, Christian Joensson wrote:

> > Is gomp not doing java yet?
> >
It's due to changes in pragma processing in the C++ FE.  For now just 
disable java when configuring the compiler.

Re: Speed impact of virtual inheritance

[Frans Englich]

On Monday 10 October 2005 18:53, Mark Mitchell wrote:
> Frans Englich wrote:
> > Hello all,
> >
> > In a large project I'm participating in, a design dilemma have arrived.
> > Adding virtual inheritance would solve it beautifully on the source code
> > level, but a potential drawback is the speed penalty it brings.
> > Measurement is always the way of approaching performance questions, but
> > since that sometimes can be tricky, I thought of starting with getting a
> > theoretical understanding of virtual inheritance.
>
> In GCC, the performance cost is very slight.
>
> In constrast to older implementations (in GCC and other compilers),
> there is very little cost in terms of bytes per object for use virtual
> inheritance.  (The only cost is that the most derived class must have a
> virtual table pointer; if the hierarchy has at least one virtual
> function, then there is no additional cost relative to that.)  There is
> an increase in the size of the virtual table (of which there is one
> instance per class, not one instance per object) proportionate to the
> number of virtual base classes.
>
> The execution-time cost is two memory references required when casting
> to a virtual base class (as opposed to zero in the case of a cast to a
> non-vritual base class).  Calling a virtual function will require a few
> additional instructions if virtual bases are involved; however, a
> function call is itself expensive, and virtual function calls typically
> cause i-cache misses, so the virtual-base part of the cost is quite small.

Followup question: what is the increased cost of calling a non-virtual, 
inlined function('inline' keyword) on a virtual base? The Shared::ref() 
function given in the initial mail could be used as example, it uses a member 
on the object. I could reason about possible answers, but I think it would 
make little good.

> There may be negative secondary optimization effects if the optimizers
> are no longer able to reason effectively about your code.
>
> My advice would be to use virtual bases in your class hierarchy where
> that seems attractive from a design point of view, but to avoid virtual
> function calls to small functions in performance critical loops, whether
> or not your hierarchy uses virtual bases.

Yes, sounds sensible to me too. 

What makes me ask these questions, is that I have code which(according to my 
opinion) severely needs virtual inheritance(VI). The code VI would affect is 
not under my veto power, and the maintainers of that code have so far given 
as comment "VI is out of the question. Period," without giving a deeper 
motivation, except "performance."

The alternative solution proposed to my VI problem would require adding 
another memory management layer on top of the current(another smart ptr, and 
so forth). I, who am of the "Go for readability, flexibility, and afterwards 
optimize according to measurements"-school, find this alarming, and worries 
that the non-VI solution can be counterproductive, even in the area it tries 
to excel(due to code complexity, that optimizers have difficulty 
introspecting).

Jonathan's and your's replies, as well as the report Jonathan referenced, does 
in my opinion show a nuanced picture of VI. I don't think an engineer can 
with this information as background take a decision motivated with 
performance, without taking a very close look at the specific case.

I wonder -- and goes outside the scope of this mailing list -- what does on 
do, when code is about to be obfuscated in the name of performance, without 
substantial evidence for doing so? Is there a paper or something special I 
can do, in order to reduce "empty" performance arguments?[1]


Cheers,

Frans

1.
I ask it, because I think it is somewhat a phenomena that programmers argue 
performance without having concrete evidence to back it up.

Re: Speed impact of virtual inheritance

[Joe Buck]

On Mon, Oct 10, 2005 at 09:25:15PM +, Frans Englich wrote:
> Followup question: what is the increased cost of calling a non-virtual, 
> inlined function('inline' keyword) on a virtual base?

If the function is successfully inlined, then the question really refers
to the cost of the code inside the function.

If this code accesses a member of a virtual base object, from a pointer
or reference to the derived object, this involves an extra level of
dereferencing that would not be present for a non-virtual base.  The
derived part of the object has a pointer to the virtual base, so this
pointer must be dereferenced to find the base object, then the actual
member is found using a constant offset from the beginning of the base.
If nonvirtual inheritance were used, the member could be found directly,
at an offset from the address of the object as a whole.

Explicit NOPs for a VLIW Machine

[Balaji V. Iyer]

Hi Everyone,
I am porting GCC 4.0.0 to a proprietary VLIW machine, and I want to
insert NOPs explicitly wherever there is an Output/Flow/Anti dependencies. I
am currently doing this insertion in the machine dependent reorganization
phase. Is there a way to do this in machine description file (or during
scheduling phase) itself (or a better way to do this)?

Thanks,

Balaji V. Iyer.

Re: [gomp]

[Richard Henderson]

On Mon, Oct 10, 2005 at 10:49:52PM +0200, Christian Joensson wrote:
> ../gcc.gomp/configure   --enable-__cxa_atexit --enable-shared --with-cpu=v7 --
> enable-languages=c,ada,c++,fortran,java,objc,treelang

Only C and Fortran are expected to build at the moment.

What you're seeing is C++ pragmas being broken.  I expect to have this
fixed sometime this week.


r~

Re: Speed impact of virtual inheritance

[Mark Mitchell]

Frans Englich wrote:

> Followup question: what is the increased cost of calling a non-virtual, 
> inlined function('inline' keyword) on a virtual base? 

None, if the function is inlined -- and whether it is inlined or not
should not be affected by whether or not it is in a virtual base.

> What makes me ask these questions, is that I have code which(according to my 
> opinion) severely needs virtual inheritance(VI). The code VI would affect is 
> not under my veto power, and the maintainers of that code have so far given 
> as comment "VI is out of the question. Period," without giving a deeper 
> motivation, except "performance."

There are a number of C++ features (templates are another) which, for
various reasons, including inferior initial implementations, have gotten
a bad reputation.  Often, with current G++, using such features has
near-zero cost.  However, sometimes people who had bad experiences, or
just incorrect perceptions, are very hard to persuade.  I don't have a
secret formula for arguing against such objections; usually, I just try
to directly attack the problem by modifying the code in question, or
using similar test programs, to show that there is little or no cost.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Speed impact of virtual inheritance

[Frans Englich]

On Monday 10 October 2005 22:29, Mark Mitchell wrote:
> Frans Englich wrote:
> > Followup question: what is the increased cost of calling a non-virtual,
> > inlined function('inline' keyword) on a virtual base?
>
> None, if the function is inlined -- and whether it is inlined or not
> should not be affected by whether or not it is in a virtual base.

Ok, let me check my understanding of Joe's and your's reply, by an example:

//--
class Shared {
public:
// 
inline void ref() { m_ref++; }
// ...
protected:
unsigned int m_ref;
};

class B : public virtual Shared {};
class C : public virtual Shared {};
class BC : public B, public C {};
//--

Running the expression "BCinstance->ref()" leads to the penalty that accessing 
the "m_ref" variable requires an indirection, if I've understood correctly.

What can safely be concluded from that? For example, could register allocation 
make it uncertain exactly how much the indirection costs?


Cheers,

Frans

Re: Speed impact of virtual inheritance

[Mark Mitchell]

Frans Englich wrote:
> On Monday 10 October 2005 22:29, Mark Mitchell wrote:
> 
>>Frans Englich wrote:
>>
>>>Followup question: what is the increased cost of calling a non-virtual,
>>>inlined function('inline' keyword) on a virtual base?
>>
>>None, if the function is inlined -- and whether it is inlined or not
>>should not be affected by whether or not it is in a virtual base.
> 
> 
> Ok, let me check my understanding of Joe's and your's reply, by an example:
> 
> //--
> class Shared {
> public:
>   // 
> inline void ref() { m_ref++; }
>   // ...
> protected:
> unsigned int m_ref;
> };
> 
> class B : public virtual Shared {};
> class C : public virtual Shared {};
> class BC : public B, public C {};
> //--
> 
> Running the expression "BCinstance->ref()" leads to the penalty that 
> accessing 
> the "m_ref" variable requires an indirection, if I've understood correctly.

Yes.

> What can safely be concluded from that? For example, could register 
> allocation 
> make it uncertain exactly how much the indirection costs?

Yes.  (There are even scenarios where the indirection could actually
help, rather than hurt.)  You'll just have to measure.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

warning on i686-pc-cygwin

[bobby mcnulty]

This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005



CONFIG_FILES= CONFIG_HEADERS=config.h:../../../gcc/libiberty/config.in 
/bin/sh .

/config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default commands
if [ x"" != x ]; then \
 /home/snyder100/gcc/o/./gcc/xgcc -B/home/snyder100/gcc/o/./gcc/ 
-B/usr/tempo/i
686-pc-cygwin/bin/ -B/usr/tempo/i686-pc-cygwin/lib/ -isystem 
/usr/tempo/i686-pc-
cygwin/include -isystem /usr/tempo/i686-pc-cygwin/sys-include -c 
-DHAVE_CONFIG_H
-O2 -g -O2  -I. -I../../../gcc/libiberty/../include  -W -Wall -pedantic 
-Wwrite
-strings -Wstrict-prototypes  ../../../gcc/libiberty/regex.c -o 
pic/regex.o; \

else true; fi
/home/snyder100/gcc/o/./gcc/xgcc -B/home/snyder100/gcc/o/./gcc/ 
-B/usr/tempo/i68
6-pc-cygwin/bin/ -B/usr/tempo/i686-pc-cygwin/lib/ -isystem 
/usr/tempo/i686-pc-cy
gwin/include -isystem /usr/tempo/i686-pc-cygwin/sys-include -c 
-DHAVE_CONFIG_H -
O2 -g -O2  -I. -I../../../gcc/libiberty/../include  -W -Wall -pedantic 
-Wwrite-s

trings -Wstrict-prototypes ../../../gcc/libiberty/regex.c -o regex.o
../../../gcc/libiberty/regex.c:130: warning: function declaration isn't 
a protot

ype
../../../gcc/libiberty/regex.c:130: warning: conflicting types for 
built-in func

tion 'malloc'
../../../gcc/libiberty/regex.c:131: warning: function declaration isn't 
a protot

ype
In file included from ../../../gcc/libiberty/regex.c:638:
../../../gcc/libiberty/regex.c: In function 'byte_regex_compile':
../../../gcc/libiberty/regex.c:2439: warning: implicit declaration of 
function '

free'
../../../gcc/libiberty/regex.c: In function 'byte_re_compile_fastmap':
../../../gcc/libiberty/regex.c:4835: warning: implicit declaration of 
function '

abort'
../../../gcc/libiberty/regex.c:4835: warning: incompatible implicit 
declaration

of built-in function 'abort'
../../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal':
../../../gcc/libiberty/regex.c:7421: warning: incompatible implicit 
declaration

of built-in function 'abort'
../../../gcc/libiberty/regex.c: In function 'xregerror':
../../../gcc/libiberty/regex.c:8078: warning: incompatible implicit 
declaration

of built-in function 'abort'
../../../gcc/libiberty/regex.c: In function 'byte_regex_compile':
../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: error: invariant not recomputed 
when ADDR_E

XPR changed
&_ctype_D.1917[1];

../../../gcc/libiberty/regex.c:2285: internal compiler error: 
verify_stmts faile

d
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory `/home/snyder100/gcc/o/i686-pc-cygwin/libiberty'
make[2]: *** [all-target-libiberty] Error 2
make[2]: Leaving directory `/home/snyder100/gcc/o'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/snyder100/gcc/o'
make: *** [bootstrap] Error 2

[EMAIL PROTECTED] ~/gcc/o
$

Re: warning on i686-pc-cygwin

[Brian Dessent]

bobby mcnulty wrote:
> 
> This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005

You're running into PR21766.

Thanks [was Re: Speed impact of virtual inheritance]

[Frans Englich]

On Monday 10 October 2005 15:21, Frans Englich wrote:
> Hello all,
>
> In a large project I'm participating in, a design dilemma have arrived.
> Adding virtual inheritance would solve it beautifully on the source code
> level, but a potential drawback is the speed penalty it brings. Measurement
> is always the way of approaching performance questions, but since that
> sometimes can be tricky, I thought of starting with getting a theoretical
> understanding of virtual inheritance.

Jonathan, Joe, Mark,

Thank you for taking time and sharing your knowledge and experiences. I hope 
your added information will bring the case closer to the right answers in my 
matter.


Cheers,

Frans

Re: RFC: IPO optimization framework for GCC

[Steve Ellcey]

Thanks to everyone who replied to my mail, I am currently waiting for
some follow-ups to replies I got off-list.  In the mean time I wonder if
we could talk about Devang's questions on what this might look like to
a user.

> From: Devang Patel <[EMAIL PROTECTED]>
>
> It is useful to get clear understanding of few simpler things before
> tackling IL issue.
> 
> First question is - What is the user interface ? Few alternatives :
> 
> 1)  gcc  -fenable-ipo input1.c input2.c input3.c -o output
> 
>  Here, writing IL on the disk, and reading it back, and optimizing it,
> etc.. are all hidden from users.

But at the cost of having to put all the source compiles on one GCC
command line.  We could probably do this today without reading or
writing anything to disk (as long as we didn't run out of memory).

> 2)  gcc  -fwrite-ipo input1.c -o input1.data
>  gcc  -fwrite-ipo input2.c -o input2.data
>  gcc  -fwrite-ipo input3.c -o input3.data
> 
>  gcc  -fread-ipo input1.data input2.data input3.data -o output
> 
> 3)  gcc  -fwrite-ipo input1.c -o input1.data
>  gcc  -fuse-ipo input1.data input2.c -o input2.data
>  gcc  -fuse-ipo input2.data input3.c -o output
> 
> 4)  gcc  -fwrite-ipo input1.c -o input1.data
>  gcc  -fwrite-ipo input2.c -o input2.data
>  gcc  -fwrite-ipo input3.c -o input3.data
> 
>  glo  -fread-ipo input1.data input2.data input3.data -o output

Could we just have -fwrite-ipo create a '.o' file that contains the
intermediate representation (instead of being a real object file).

Then when the linker is called it would call the compiler with all the
files that have intermediate code instead of object code and finish up
the compilation.  Actually, maybe we could add the restriction that
you have to use GCC to call the linker when doing IPO and that way 
GCC could finish up the compilations before it calls the linker.

> Second question is - When to put info on the disk? Few alternatives,
> 1) Before gimplfication
> 2) Before optimizing tree-ssa
> 3) After tree-ssa optimization is complete
> 4) Immediately after generating RTL
> 5) Halfway throuh RTL passes
> etc.. And answer to this question largely depend on the optimization
> passes that work on whole program info.

I would think one would want to put the info out before optimizing
tree-ssa since you would hope that the IPO data from other modules would
let you do better tree-ssa optimizations.

> I do not know whether these two questions are already answered or not.

I don't think anything has been answered yet.

Steve Ellcey
[EMAIL PROTECTED]

Re: warning on i686-pc-cygwin

[bobby mcnulty]

Brian Dessent wrote:


bobby mcnulty wrote:
 


This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005
   



You're running into PR21766.


 


So its been reported already. OK.
Bobby

Re: RFC: IPO optimization framework for GCC

[Daniel Berlin]

> > Second question is - When to put info on the disk? Few alternatives,
> > 1) Before gimplfication
> > 2) Before optimizing tree-ssa
> > 3) After tree-ssa optimization is complete
> > 4) Immediately after generating RTL
> > 5) Halfway throuh RTL passes
> > etc.. And answer to this question largely depend on the optimization
> > passes that work on whole program info.
> 
> I would think one would want to put the info out before optimizing
> tree-ssa since you would hope that the IPO data from other modules would
> let you do better tree-ssa optimizations.

Actually, you want to do it right after what the ipa-branch does
early-optimizations.

That will write out a cleaned up IL that has had CCP and DCE run on it.

We discussed almost *all* of this stuff at the summit.
There are people working on detailed plans for IPA (Mark Mitchell and
Ken Zadeck).
You really should email or call them and find out what they are doing.

Re: Update on GCC moving to svn

[Giovanni Bajo]

Daniel Berlin <[EMAIL PROTECTED]> wrote:

> Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was
> converting it, but it looks like they shutdown the machines at watson)
> and do a few test branch merges to make sur eall the commit mails come
> out okay for very large cases.

Will the final conversion include the old-gcc repository?
 
Giovanni Bajo

Re: Update on GCC moving to svn

[Daniel Berlin]

On Tue, 2005-10-11 at 02:02 +0200, Giovanni Bajo wrote:
> Daniel Berlin <[EMAIL PROTECTED]> wrote:
> 
> > Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was
> > converting it, but it looks like they shutdown the machines at watson)
> > and do a few test branch merges to make sur eall the commit mails come
> > out okay for very large cases.
> 
> Will the final conversion include the old-gcc repository?
>  

Yes.

> Giovanni Bajo
> 

Re: Running ranlib after installation - okay or not?

[Alexandre Oliva]

On Sep 29, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote:

> I posted a patch that nobody has had time to look at for this, even if
> it is not acceptable (it would probably be better if it reset the
> permissions after calling ranlib) I'd appreciate some feedback :)

> 

I'd missed it, sorry.

The patch is ok, but it's not in yet because the format of the
ChangeLog entries will require manual application in every one of the
files, and that takes time.  If you'd repost the patch in a format
that enables it to be installed with say cl2patch, or even with the
raw ChangeLog diffs such that I use clcleanup and cl2patch to apply it
to the current tree, I'll check it in when the mainline policy allows
it.

Thanks,

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

RFC: weakref GCC attribute and .weakref assembly directive

[Alexandre Oliva]

I'll probably post a patch for the assembler, that implements this,
tonight.  The compiler still needs a bit more work in the testsuite
(or in the implementation, to make it independent from assembler
support) so it might take longer.

Comments are welcome.

 Using weakrefs to avoid weakening strong references
   
 Alexandre Oliva <[EMAIL PROTECTED]>
  2005-10-10
   
Introduction


Consider a header file that defines inline functions that would like
to use (or just test for a definition of) a certain symbol (function,
variable, wahtever), if it is defined in the final program or one of
the libraries it links with, but that have alternate code paths in
case the symbol is not defined, so it would like to not force the
symbol to be defined.

This is the case of gthr-* headers in GCC, that libstdc++ uses and
exposes to users, creating a number of problems.

Such a header has traditionally been impossible to implement without
declaring the symbol as weak, which has the effect that any references
to the symbol in the user's code will also be regarded as weak.  This
has two negative side effects:

- if the function is defined in a static library, and the library is
linked into the program, the object file containing the definition may
not be linked in, because all references to it are weak, even
references that should have been strong.

- if the user accidentally fails to link in the library providing the
referenced symbol, she won't get an error message, and the code that
assumed strong references is likely to crash.


Existing solutions
==

One way to avoid this problem is to move the direct reference to the
symbol from the inline function into a function in a separate library,
or even move the entire function there.  The library references the
symbol weakly, without affecting user code.  This probably impacts
performance negatively, and may require a new library to be linked in,
which an all-inline header file (say, C++ template definitions) would
rather avoid.

Another way to avoid the problem it is to create a variable in a
separate library, initialized with a weak reference to the symbol, and
access the variable in the inline function.  This still has a small
impact on performance and may require a new library, but the most
serious problem is that it defines a variable as part of the interface
of a library, which is generally regarded as poor practice.


Weakrefs


The idea to address the problem is to enable the compiler to
distinguish references that are intended to be weak from those that
are to be strong, and combine them in the same way that the linker
would combine an object file with a weak undefined symbol and another
object containing a symbol with the same name.  The idea was to enable
people to write code as if they had combined two such object files
into a single translation unit.

The idea of a weak alias may immediately come to mind, but this is not
what we are looking for.  A weak alias is a definition that is in
itself weak (i.e., it yields to other definitions), that holds the
same value as another definition in the same translation unit.  This
other definition can be strong or weak, but it must be a definition.
A weak alias cannot reference an undefined symbol, weak or strong.

What we need, in contrast, is some means to define an alias that
doesn't, by itself, cause an external definition of the symbol to be
brought in.  If the symbol is referenced directly elsewhere, however,
then it must be defined.  This is similar to the notion of weak
references in garbage collection literature, in which a strong
reference stops an object from being garbage-collected, but a weak
reference does not.  I've decided to name this kind of alias a
weakref.


I could have introduce means in the compiler to create such weakrefs,
and handled them entirely within the compiler, as long as it can see
the entire translation unit before deciding whether to issue or not a
.weak directive for the referenced symbol.

However, since the notion can be useful in the assembler as well,
especially for large or complex preprocessed assembly sources, I went
ahead and decided to implement it in the assembler, and get the
compiler to use that.

This notion may also be useful for compilers that combine multiple
translation units into a single assembly output file.


Assembler implementation


The following syntax was chosen for assembly code:

  .weakref , 

The semantics are as follows:

- if  is referenced or defined, then .weakref has no effect
whatsoever on its symbol;

- if  is never referenced or defined other than in .weakref
directives, but  is, then  is marked as weak undefined
in the symbol table;

- multiple aliases may be weakrefs to the same target, and the effect
is equivalent to having a single weakref

- if  is redefined, it ceases

4.0.2 bootstrap comparison failure on AIX 5.3

[Albert Chin]

I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
bootstrap comparison failure:
  $ cd /opt/build
  $ bzip2 -dc gcc-4.0.2.tar.bz2 | tar xf -
  $ mkdir gcc
  $ cd gcc
  $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \
  /opt/fsw/bin/bash /opt/build/gcc-4.0.2/configure \
  --with-included-gettext --enable-shared --enable-threads \
  --enable-languages="c,c++" --disable-multilib
  ...
  $ gmake bootstrap
  ...
  Bootstrap comparison failure!
  ./fold-const.o differs
  gmake[1]: *** [slowcompare] Error 1
  gmake[1]: Leaving directory `/opt/build/gcc/gcc'
  gmake: *** [bootstrap] Error 2

The AIX 5.3 system:
  $ oslevel -r
  5300-02
  $ lslpp -L vac.C
  vac.C  7.0.0.3A FIBM XL C Compiler

I don't see anything on
http://gcc.gnu.org/install/specific.html#x-ibm-aix specific to AIX
5.3. I have also built on AIX 5.1 with the same result.

-- 
albert chin ([EMAIL PROTECTED])

Re: 4.0.2 bootstrap comparison failure on AIX 5.3

[David Edelsohn]

> Albert Chin writes:

Albert> I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
Albert> bootstrap comparison failure:
Albert> $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \

Albert> I don't see anything on
Albert> http://gcc.gnu.org/install/specific.html#x-ibm-aix specific to AIX
Albert> 5.3. I have also built on AIX 5.1 with the same result.

I have bootstrapped on AIX 5.1 and AIX 5.2 using GCC without
problem. 

David