Comeau C++

[Greg_Comeau]

In article <9ng5fn$m27$1@inn.qnx.com>,
Bill Caroselli (Q-TPS) <qtps@earthlink.net> wrote:

“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9ne03b$8j$> 1@panix3.panix.com> …
I’m not saying gcc wasn’t or isn’t slower, just trying to
understand exactly what was tested, and under what auspices.
I find that comparison rarely ever really fairly compare.

I know that this, and several other threads started out with the issue that
the GNU C++ compiler is not very complient and is sometimes buggy.

Just to be clear: This is a non issue if we use gcc as the backend.

But the secondary issue is also true. The GCU C compiler is slow and fat
adn produces code that is slow and fat. While it is certainly true that
this is less important than not being complient or being buggy, it does
matter a lot to some of us.

I don’t negate this, but was just looking for clear qualification
of what “slow” means.

I think you’ll find that damn near ANY benchmark of GNU C under RTP will
fall short of another compiler anywhere else.

I’d still be curious of the auspices of the tests
(on a different note, once upon a time, gcc was considered
to generate fast code, I have to confess to not keep up with this
in the past, oh say, 5-6 years, but I find this surprising).
Anyway, the thing is that I don’t know what it means to compare
gcc under RTP with VC++ under MS-Windows.

Hey, here’s an idea. Why don’t we just compile the GNU C compiler
code with Watcom? Oh, never mind. That gets us no where.

I was going to mention the possibility of using Watcom as the
back end C compiler, but I don’t know where that leads to.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <9ng94k$o3u$1@inn.qnx.com>,
Mario Charest <mcharest@nowayzinformatic.com> wrote:

“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9ne03b$8j$> 1@panix3.panix.com> …
In article <9ndv51$eb3$> 1@inn.qnx.com> >,
Mario Charest <> mcharest@nowayzinformatic.com> > wrote:
“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9ndutq$rhl$> 1@panix3.panix.com> …
In article <9nbm4m$47q$> 1@inn.qnx.com> >,
Mario Charest <> mcharest@nowayzinformatic.com> > wrote:
“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9nbev6$194$> 1@panix3.panix.com> …
In article <> 3B9939D3.AA339A28@faac.com> >,
Dean Douthat <> ddouthat@faac.com> > wrote:
Since it uses GCC, I’m assuming it will work for any of the QNX6
target
platforms. Right?

If we don’t make it so, then that’s not right.
If we do make it so, then that is right.
It really must be ported, literally, to every platform
(as mentioned in another post, when I say “platform”
that includes at least the CPU, OS, and C compiler).
It’s not enough to do it for one and expect meaningful
results for another platform. Make sense?

So that means it’s using GCC ;-( I think that if QNX was
to support another compiler, it should be something that
has nothing to do with GCC.

I’m not clear on what or what this is a problem?

Because code generate by GNU C isn’t that great, I would like
better. Many customer I worked with were rather pissed
at seeming the same software run 10-20% faster when compile
with VC for example.

Or am I mistaken; would Comeau C/C++ generate assembly
or object file directly.

You’re not mistaken on this last sentence. However,
isn’t it so that VC can’t be used with/for QNX?

If the object files generated by VC can be understood by
a QNX linker I guess that’s possible. However I’m fairly
sure VC generated it’s own private .o format?

Yes, it’s “private”. And yes, somebody could write something
to understand it, but so long as they don’t, there is still
an issue of what means what.

If so, isn’t it so that the gcc used apparently under Windows
will not be the same code generator used with gcc under QNX
and/or other things can effect it?

The code should be the same, if the library are the also from
the same source, executable should be close to identical.

Should being the operative word

I’m not saying gcc wasn’t or isn’t slower, just trying to
understand exactly what was tested, and under what auspices.
I find that comparison rarely ever really fairly compare.

Project A compile with VC under NT for NT: Execution 1000 per sec
Project A compile with GCC under NT for NT: Execution 800 per sec
Project A compile with GCC under QNX for QNX: Execution 790 per sec.

The difference between the two gcc is negligable and shows they
produce very comparable code. But VC is much bettern then GCC.
The code is in C++ had lots of floating point and made heavy use of STL.

But that’s just the point. If for instance it doesn’t use
floating point, then such tests could flip completely the other way,
so making carte blanche statements is risky IMO.

Also, I’m not sure what you mean by “X per sec”. X what?

Also, when comparing across OSs, it’s easy to miss aspects
of paging/virtual memory, static vs dynamic images/loading,
how process memory gets initialized, etc. and stuff like that
that can effect timings too.

Last but not least, when one says something like “gcc under NT”
I fail to understand what that means. For instance, there is
gcc directly from gnu.org but there is also DJGPP, mingw, cygwin,
bloodshed, etc. and I would be surprised if they all have exactly
the same code generation and optimizations.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Mario_Charest1]

“Greg Comeau” <comeau@panix.com> wrote in message
news:9ne03b$8j$1@panix3.panix.com…

In article <9ndv51$eb3$> 1@inn.qnx.com> >,
Mario Charest <> mcharest@nowayzinformatic.com> > wrote:
“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9ndutq$rhl$> 1@panix3.panix.com> …
In article <9nbm4m$47q$> 1@inn.qnx.com> >,
Mario Charest <> mcharest@nowayzinformatic.com> > wrote:
“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9nbev6$194$> 1@panix3.panix.com> …
In article <> 3B9939D3.AA339A28@faac.com> >,
Dean Douthat <> ddouthat@faac.com> > wrote:
Since it uses GCC, I’m assuming it will work for any of the QNX6
target
platforms. Right?

If we don’t make it so, then that’s not right.
If we do make it so, then that is right.
It really must be ported, literally, to every platform
(as mentioned in another post, when I say “platform”
that includes at least the CPU, OS, and C compiler).
It’s not enough to do it for one and expect meaningful
results for another platform. Make sense?

So that means it’s using GCC ;-( I think that if QNX was
to support another compiler, it should be something that
has nothing to do with GCC.

I’m not clear on what or what this is a problem?

Because code generate by GNU C isn’t that great, I would like
better. Many customer I worked with were rather pissed
at seeming the same software run 10-20% faster when compile
with VC for example.

Or am I mistaken; would Comeau C/C++ generate assembly
or object file directly.

You’re not mistaken on this last sentence. However,
isn’t it so that VC can’t be used with/for QNX?

If the object files generated by VC can be understood by
a QNX linker I guess that’s possible. However I’m fairly
sure VC generated it’s own private .o format?

If so, isn’t it so that the gcc used apparently under Windows
will not be the same code generator used with gcc under QNX
and/or other things can effect it?

The code should be the same, if the library are the also from

the same source, executable should be close to identical.

I’m not saying gcc wasn’t or isn’t slower, just trying to
understand exactly what was tested, and under what auspices.
I find that comparison rarely ever really fairly compare.

Project A compile with VC under NT for NT: Execution 1000 per sec
Project A compile with GCC under NT for NT: Execution 800 per sec
Project A compile with GCC under QNX for QNX: Execution 790 per sec.

The difference between the two gcc is negligable and shows they
produce very comparable code. But VC is much bettern then GCC.
The code is in C++ had lots of floating point and made heavy use of STL.

–
Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> > http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[system]

Greg Comeau <comeau@panix.com> wrote:

In article <9navsi$lan$> 1@inn.qnx.com> >, <> tom_usenet@hotmail.com> > wrote:
Greg Comeau <> comeau@panix.com> > wrote:
In article <9naoa6$gqo$> 1@inn.qnx.com> >,
2. his compiler is fully compliant, and

It’s not, not C++ compiler is currently fully compliant,
but we’re clsoe.

I am pretty knowledgeable about C++ compiler/library conformance
issues, and Comeau C++ is the closest.

I think in the CUJ roundup we came out 98% for language issues.

I just had another look at that and was surprised that Kai C++
actually did just as well (possibly better) in the tests. I assume
that this was due to issues with your beta version, since Kai doesn’t
implement 2 stage template lookup, unlike Comeau (is that the only
major difference?)

This is perhaps so, but I believe that Dinkum is the most compliant
BTW, STLport works with Comeau C++ too, and we have a project underway
to formerly check it out with all our existing platforms by the end of
this year – again, having a choice matters IMO.

STLport doesn’t work on Windows (yet), I discovered over the weekend.
There’s a bit of work to be done for a como-vc.mak file, and changes
to the config header, and possibly other changes. In Windows, there is
a problem of what make system people will use (which is why you have a
batch file for libcomo, I suppose). I personally use GNU make under
Cygwin. Incidently, do you know how to tune automake and autoconf to
work well with como? AC_PROG_CXX produces an error.

I’ve done an STLport (> www.stlport.com> ) for QNX 6.0. If I decide
Dinkum is too slow (unlikely - I’ve examined the source code and
they seem to make reasonable use of memcpy optimisations, and
std::string uses the small string optimisation), I may do a
6.1 port too (obviously the C standard libraries have all changed,
requiring a new port).

There’s one thing I’ve been unclear about, and that whether or
just how much STLPort is still being made compliant. I mean,
I sure it is, but I’m not cclear on exactly how that effort proceeds.

I believe that many of the conformance problems related to the missing
amendment 1 features of the C library. Dinkum has their own C library
and are therefore free of these potential problems, but I haven’t seen
STLport tested with the Dinkum C library. This would be practical
under QNX once I get around to the port of STLport, although I
obviously don’t have access to any conformance testing software.

As for continued conformance upgrades, ask Boris on the STLport
forums. But I assume that increasing conformance (where possible),
ironing out bugs and adding new platforms are their priorities,
followed by optimisation.

Speaking of optimisation, does or will Comeau ever provide some kind
of handle to is_POD::value and has_trivial_destructor::value,
etc, as found in Boost and in STLport?

Tom

[Greg_Comeau]

In article <9ni5jv$rpl$1@inn.qnx.com>, <tom_usenet@hotmail.com> wrote:

Greg Comeau <> comeau@panix.com> > wrote:
In article <9navsi$lan$> 1@inn.qnx.com> >, <> tom_usenet@hotmail.com> > wrote:
Greg Comeau <> comeau@panix.com> > wrote:
In article <9naoa6$gqo$> 1@inn.qnx.com> >,
2. his compiler is fully compliant, and
It’s not, not C++ compiler is currently fully compliant,
but we’re clsoe.

I am pretty knowledgeable about C++ compiler/library conformance
issues, and Comeau C++ is the closest.

I think in the CUJ roundup we came out 98% for language issues.

I just had another look at that and was surprised that Kai C++
actually did just as well (possibly better) in the tests. I assume
that this was due to issues with your beta version, since Kai doesn’t
implement 2 stage template lookup, unlike Comeau (is that the only
major difference?)

I’m not sure which version KAI is up to.

This is perhaps so, but I believe that Dinkum is the most compliant
BTW, STLport works with Comeau C++ too, and we have a project underway
to formerly check it out with all our existing platforms by the end of
this year – again, having a choice matters IMO.

STLport doesn’t work on Windows (yet), I discovered over the weekend.
There’s a bit of work to be done for a como-vc.mak file, and changes
to the config header, and possibly other changes. In Windows, there is
a problem of what make system people will use (which is why you have a
batch file for libcomo, I suppose). I personally use GNU make under
Cygwin. Incidently, do you know how to tune automake and autoconf to
work well with como? AC_PROG_CXX produces an error.

I know a while ago we tried it and it “just worked”. But that
was not under Windows. But that’s exactly the point of the
project that’s underway: To make sure it’s ok on all platforms,
and furthermore, to not have people have to tweak this and that.

I believe that many of the conformance problems related to the missing
amendment 1 features of the C library. Dinkum has their own C library
and are therefore free of these potential problems, but I haven’t seen
STLport tested with the Dinkum C library. This would be practical
under QNX once I get around to the port of STLport, although I
obviously don’t have access to any conformance testing software.

That would be interesting.

As for continued conformance upgrades, ask Boris on the STLport
forums. But I assume that increasing conformance (where possible),
ironing out bugs and adding new platforms are their priorities,
followed by optimisation.

Speaking of optimisation, does or will Comeau ever provide some kind
of handle to is_POD::value and has_trivial_destructor::value,
etc, as found in Boost and in STLport?

Actually, does any compiler have hooks for those?

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[system]

Greg Comeau <comeau@panix.com> wrote:

Speaking of optimisation, does or will Comeau ever provide some kind
of handle to is_POD::value and has_trivial_destructor::value,
etc, as found in Boost and in STLport?

Actually, does any compiler have hooks for those?

According to type_traits.h in stlport/stl, SGI’s N64 and N32 compilers have
these hooks in, automatically generating specialisations of __type_traits
if they are instantiated. How much work would it be to add it to EDG and
Comeau? Perhaps one for next year, when you’ve hit “100%” language
conformance. At that point, will you consider adding some kind of
optimiser? I have discovered that como-msc does pretty badly in the
Stepanov benchmark in the Double bit - it can’t optimise out small structs
yet. Double (a double encapsulated in a class) was over 10 times slower
than using a double. Interestingly, g++ had this one sorted, producing
identical results to Kai’s claimed figures (i.e. each abstraction having zero
penalty). MSVC++ 6 was generally worse than comeau-msc
(surprisingly, since it could in theory optimize objects), although it did
better with the Double class. Basically, Comeau is currently unsuitable
for performance computation using the std::complex class. I don’t
remember the precise OOPACK results, but Comeau was generally
comparable to g++ and MSVC. It appears that most compiler writers,
like Comeau, have yet to write small object optimisers. I’d like to see
how Intel C++ does here, with it’s claims of excellent C optimisation.
We know that Kai C++ does well (perfectly in fact) from results posted
on their site.

If you don’t mind me asking, how many employees does Comeau
Computing have? You appear to have an amazing ability to be
everywhere at once, quickly answering everyone’s questions while
producing prompt new versions of Comeau and attending ANSI meetings,
etc!

Tom

[Rennie_Allen2]

I would have no problem with g++ if compiled code closer to compliance
(99 percent is where I feel comfortable). I have no problems whatsoever
with the code that gcc produces. It is generally faster than Watcom,
although it is also generally fatter than Watcom (gcc obviously has a
bent toward time over size).

Actually I will probably be happy with g++ 3.0, once it is 3.2

-----Original Message-----
From: Bill Caroselli (Q-TPS) [mailto:qtps@earthlink.net]
Posted At: Sunday, September 09, 2001 9:34 AM
Posted To: devtools
Conversation: Comeau C++
Subject: Re: Comeau C++


Hi Greg

I know that this, and several other threads started out with the issue
that
the GNU C++ compiler is not very complient and is sometimes buggy.

But the secondary issue is also true. The GCU C compiler is slow and
fat
adn produces code that is slow and fat. While it is certainly true that
this is less important than not being complient or being buggy, it does
matter a lot to some of us.

I think you’ll find that damn near ANY benchmark of GNU C under RTP will
fall short of another compiler anywhere else.

Hey, here’s an idea. Why don’t we just compile the GNU C compiler code
with
Watcom? Oh, never mind. That gets us no where.

Bill Caroselli


“Greg Comeau” <comeau@panix.com> wrote in message
news:9ne03b$8j$1@panix3.panix.com…

I’m not saying gcc wasn’t or isn’t slower, just trying to
understand exactly what was tested, and under what auspices.
I find that comparison rarely ever really fairly compare.

[Colin_Burgess1]

Miguel Simon <simon@ou.edu> wrote:

Hi Colin…

I wonder if you have any more comment on the subject?

Hi there. I’ve been away in Boston for the last week, so I’ve been out
of touch.

Greg and I have been conversing (before I went away), and we’re looking
into it. I can’t really say much more yet, since I haven’t really had
a chance to get up to date.

However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

Bests…

Miguel.



Colin Burgess wrote:

Thanks, I’ll take a look.

Tom <> the_wid@my-deja.com> > wrote:
Has Comeau C++ been considered by the QNX team as an alternative C++ (and C99)
compiler? It only costs $50 a license (which I would be very happy to pay). Its
back end generates C code, and many ports to custom platforms, including
embedded ones, are already available. Existing ports to gcc on several platforms
should make the QNX port very easy (and cheap!)…

If executable sizes and speeds are good, then it might just be the solution for
the C++ developers annoyed by g++. It also happens to be, when combined with
the Dinkumware C and C++ Libraries, the most ISO compliant C++ compiler
available. It also has a large number of compatibility switches for compiling
older code.

Check out > www.comeaucomputing.com

Tom

–
cburgess@qnx.com

–

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

–
cburgess@qnx.com

[Colin_Burgess1]

Greg Comeau <comeau@panix.com> wrote:

Colin is currently on vacation as I understand it.

Actually a working trip, I was at ESC Boston.

In article <> 3B95947F.10F79461@ou.edu> >, Miguel Simon <> simon@ou.edu> > wrote:
Hi Colin…

I wonder if you have any more comment on the subject?

Colin Burgess wrote:

Thanks, I’ll take a look.

Tom <> the_wid@my-deja.com> > wrote:
Has Comeau C++ been considered by the QNX team as an alternative C++ (and C99)
compiler? It only costs $50 a license (which I would be very happy to pay). Its
back end generates C code, and many ports to custom platforms, including
embedded ones, are already available. Existing ports to gcc on several platforms
should make the QNX port very easy (and cheap!)…

If executable sizes and speeds are good, then it might just be the solution for
the C++ developers annoyed by g++. It also happens to be, when combined with
the Dinkumware C and C++ Libraries, the most ISO compliant C++ compiler
available. It also has a large number of compatibility switches for compiling
older code.

Check out > www.comeaucomputing.com

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> > http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

–
cburgess@qnx.com

[Rennie_Allen2]

I agree, my interest is not stirred unless benchmark results are of a
different magnitude, 10-20% performance differences with one particular
piece of code, might simply mean that one compiler does better with a
particular coding and/or design style. If this happens to be your
design/coding style, then it might behoove you to select the compiler
that does better, but this certainly doesn’t serve as a good
generalization (as if there is such a thing as a good generalization


Mario, you can make no assumption at all, as to what the final
executables performance would be from Comeau C object code compiled with
gcc without testing your C++ code with the actual toolchain (this sucks,
but that’s life - who knows it might be 30-40% slower, or 10-20% faster
. Personally, I would much rather use a 99% compliant compiler
that’s 20% slower, than a 90% compliant compiler that just so happens to
“like” my (possibly non-C++) coding style.

-----Original Message-----
From: comeau@panix.com (Greg Comeau) [mailto:comeau@panix.com]
Posted At: Saturday, September 08, 2001 1:47 PM
Posted To: devtools
Conversation: Comeau C++
Subject: Re: Comeau C++


In article <9ndv51$eb3$1@inn.qnx.com>,
Mario Charest <mcharest@nowayzinformatic.com> wrote:

“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9ndutq$rhl$> 1@panix3.panix.com> …
In article <9nbm4m$47q$> 1@inn.qnx.com> >,
Mario Charest <> mcharest@nowayzinformatic.com> > wrote:
“Greg Comeau” <> comeau@panix.com> > wrote in message
news:9nbev6$194$> 1@panix3.panix.com> …
In article <> 3B9939D3.AA339A28@faac.com> >,
Dean Douthat <> ddouthat@faac.com> > wrote:
Since it uses GCC, I’m assuming it will work for any of the QNX6
target
platforms. Right?

If we don’t make it so, then that’s not right.
If we do make it so, then that is right.
It really must be ported, literally, to every platform
(as mentioned in another post, when I say “platform”
that includes at least the CPU, OS, and C compiler).
It’s not enough to do it for one and expect meaningful
results for another platform. Make sense?

So that means it’s using GCC ;-( I think that if QNX was
to support another compiler, it should be something that
has nothing to do with GCC.

I’m not clear on what or what this is a problem?

Because code generate by GNU C isn’t that great, I would like
better. Many customer I worked with were rather pissed
at seeming the same software run 10-20% faster when compile
with VC for example.

Or am I mistaken; would Comeau C/C++ generate assembly
or object file directly.

You’re not mistaken on this last sentence. However,
isn’t it so that VC can’t be used with/for QNX?
If so, isn’t it so that the gcc used apparently under Windows
will not be the same code generator used with gcc under QNX
and/or other things can effect it?

I’m not saying gcc wasn’t or isn’t slower, just trying to
understand exactly what was tested, and under what auspices.
I find that comparison rarely ever really fairly compare.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Miguel_Simon1]

Hi Colin…

Colin Burgess wrote:

Miguel Simon <> simon@ou.edu> > wrote:
Hi Colin…

I wonder if you have any more comment on the subject?

Hi there. I’ve been away in Boston for the last week, so I’ve been out
of touch.

welcome back!

Greg and I have been conversing (before I went away), and we’re looking
into it. I can’t really say much more yet, since I haven’t really had
a chance to get up to date.

However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

According to some of the comments made by others, it seems that a
perceived problem is the gcc compiler, and that this being the case,
then Comeau C++ will not necessarily help at compile time.

If the above is true, then what is the advantage of having a ‘front-end’
over gcc if the compiler will be the same regardless -namely gcc?

Regards…

Miguel

<…>

–
cburgess@qnx.com

–

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

[Tom2]

“Miguel Simon” <simon@ou.edu> wrote in message
news:3B9D48F0.921E293@ou.edu…

Greg and I have been conversing (before I went away), and we’re looking
into it. I can’t really say much more yet, since I haven’t really had
a chance to get up to date.

However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

According to some of the comments made by others, it seems that a
perceived problem is the gcc compiler, and that this being the case,
then Comeau C++ will not necessarily help at compile time.

If the above is true, then what is the advantage of having a ‘front-end’
over gcc if the compiler will be the same regardless -namely gcc?

My problem is with g++. gcc compiles quickly, seems bug free and C89
compliant, and produces reasonably small, fast code. OTOH, g++ has regular
internal compiler errors, is very slow at compiling, doesn’t implement the
full C++98 standard, and produces enormous executables. The latter is what
Comeau C++ may well address. I believe that g++ will take a couple of years
to iron out these problems.

As a C++ programmer, I’m being driven to despair by limitations of g++,
spending hours working around strange internal compiler errors (last time it
was because I had too many anonymous namespace level objects in a
translation unit (they were registering message classes with a factory
singleton) - why is there a limit!?).

Tom

[Wave]

Miguel Simon <simon@ou.edu> wrote:

Hi Colin…

If the above is true, then what is the advantage of having a ‘front-end’
over gcc if the compiler will be the same regardless -namely gcc?

Regards…

well, gcc seem to compile fine C code but has many problems when working
with C++.

I don’t know how comeau c/c++ can be also a C compiler since it uses an
external c one (gcc or anything else).

Another question about comeau c++… how does it handle profiling?
It simply passes a profiling flag to the system compiler or adds itself
profiling code?

–
Wave++

[Greg_Comeau]

In article <9nip5u$i9b$1@inn.qnx.com>, <tom_usenet@hotmail.com> wrote:

Greg Comeau <> comeau@panix.com> > wrote:
Speaking of optimisation, does or will Comeau ever provide some kind
of handle to is_POD::value and has_trivial_destructor::value,
etc, as found in Boost and in STLport?

Actually, does any compiler have hooks for those?

According to type_traits.h in stlport/stl, SGI’s N64 and N32 compilers have
these hooks in, automatically generating specialisations of __type_traits
if they are instantiated. How much work would it be to add it to EDG and
Comeau? Perhaps one for next year, when you’ve hit “100%” language
conformance. At that point, will you consider adding some kind of
optimiser?

Our focus so far has kind of been to be unfocused, but now we are
so solid and stable that we need to starting moving into platform
specific things, optimizations, quality of implementation, etc.
We already have various projects going on, some are research
projects, others are not, on many things. I won’t comment which
will out first since that would be premature.

I have discovered that como-msc does pretty badly in the
Stepanov benchmark in the Double bit - it can’t optimise out small structs
yet. Double (a double encapsulated in a class) was over 10 times slower
than using a double. Interestingly, g++ had this one sorted, producing
identical results to Kai’s claimed figures (i.e. each abstraction having zero
penalty). MSVC++ 6 was generally worse than comeau-msc
(surprisingly, since it could in theory optimize objects), although it did
better with the Double class. Basically, Comeau is currently unsuitable
for performance computation using the std::complex class. I don’t
remember the precise OOPACK results, but Comeau was generally
comparable to g++ and MSVC. It appears that most compiler writers,
like Comeau, have yet to write small object optimisers. I’d like to see
how Intel C++ does here, with it’s claims of excellent C optimisation.
We know that Kai C++ does well (perfectly in fact) from results posted
on their site.

It’s already been stated that KAI is the only compiler doing
these kinds of thing.

If you don’t mind me asking, how many employees does Comeau
Computing have? You appear to have an amazing ability to be
everywhere at once, quickly answering everyone’s questions while
producing prompt new versions of Comeau and attending ANSI meetings,
etc!

Oh, I do more than that, but that’s the benefit of being a
Siamese-sextuplet Seriously, there’s only a handful of us,
but it’s testimony to non-nonsense skilled professionals.
It does get to be an unrealistic juggling act at times. OTOH,
it’s lots of fun. Too, I simply cannot imagine what big
multi-billion dollar companies with hundreds of staff working
on similar thing must be doing.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <64F00D816A85D51198390050046F80C9B481@exchangecal.hq.csical.com>,
Rennie Allen <RAllen@csical.com> wrote:

I would have no problem with g++ if compiled code closer to compliance
(99 percent is where I feel comfortable). I have no problems whatsoever
with the code that gcc produces. It is generally faster than Watcom,
although it is also generally fatter than Watcom (gcc obviously has a
bent toward time over size).

Actually I will probably be happy with g++ 3.0, once it is 3.2 >

Well, it won’t be at 99% yet, and I don’t think anybody knows when.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <3B9D48F0.921E293@ou.edu>, Miguel Simon <simon@ou.edu> wrote:

Colin Burgess wrote:
However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

According to some of the comments made by others, it seems that a
perceived problem is the gcc compiler, and that this being the case,
then Comeau C++ will not necessarily help at compile time.

It depends what you’re tying to “help”.

If the above is true, then what is the advantage of having a ‘front-end’
over gcc if the compiler will be the same regardless -namely gcc?

The compiler systems (the whole thing) won’t be the same, by virtue
of the “front end”.

I’m not quite sure what you’re asking and/or getting at in
your post.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <9njj9l$3n2$1@inn.qnx.com>, Tom <tom_usenet@hotmail.com> wrote:

“Miguel Simon” <> simon@ou.edu> > wrote in message
news:> 3B9D48F0.921E293@ou.edu> …
Greg and I have been conversing (before I went away), and we’re looking
into it. I can’t really say much more yet, since I haven’t really had
a chance to get up to date.

However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

According to some of the comments made by others, it seems that a
perceived problem is the gcc compiler, and that this being the case,
then Comeau C++ will not necessarily help at compile time.

If the above is true, then what is the advantage of having a ‘front-end’
over gcc if the compiler will be the same regardless -namely gcc?

My problem is with g++. gcc compiles quickly, seems bug free and C89
compliant, and produces reasonably small, fast code.

Yet Bill Caroselli (Q-TPS) <qtps@earthlink.net> wrote:

The GCU C compiler is slow and fat adn produces code that is slow and fat.

It can’t be both!

OTOH, g++ has regular
internal compiler errors, is very slow at compiling, doesn’t implement the
full C++98 standard, and produces enormous executables. The latter is what
Comeau C++ may well address. I believe that g++ will take a couple of years
to iron out these problems.

This is a reasonable assessment.

As a C++ programmer, I’m being driven to despair by limitations of g++,
spending hours working around strange internal compiler errors (last time it
was because I had too many anonymous namespace level objects in a
translation unit (they were registering message classes with a factory
singleton) - why is there a limit!?).

We hear this kind of thing often (and not just about gcc).

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <9njjtk$3nd$1@inn.qnx.com>, Wave++ <wavexx@apexmail.com> wrote:

Miguel Simon <> simon@ou.edu> > wrote:
I don’t know how comeau c/c++ can be also a C compiler since it uses an
external c one (gcc or anything else).

I guess this is a bad time to mention that it’s also possible
for us to generate C++ with Comeau (I’m serious.)

The thing is we analyze the code and put it into symbol tables,
trees, and an intermediate form. At that point the original
input source code is essentially tossed (this is so for any
compiler). Then the code generation phase uses the tables,
trees and intermediate info to generate the code. This means
that even if the output language is the “same” as the input
language (actually it’s not) then the possibility for it being
able to compile stuff that the output need not contain exists.

Imagine a simple example. Consider that we extend C to allow
label@ as well as label: to indicate a label. So we record
thislabel@ and thatlabel: in the same way, just as labels.
Then, when we inspect the compile information, we just output
both as label:, so that would give thislabel: and thatlabel:
Of course I’ve trivialized lots here, but “lowering” one language
to another is what a compiler does anyway,

Another question about comeau c++… how does it handle profiling?
It simply passes a profiling flag to the system compiler or adds itself
profiling code?

There’s some implementation concerns here (again, this is yet
another reason we need to tailor it to a particular C compiler)
but we don’t need to add the raw profiling code itself, the C
compiler can do that.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Greg_Comeau]

In article <64F00D816A85D51198390050046F80C9B568@exchangecal.hq.csical.com>,
Rennie Allen <RAllen@csical.com> wrote:

I agree, my interest is not stirred unless benchmark results are of a
different magnitude, 10-20% performance differences with one particular
piece of code, might simply mean that one compiler does better with a
particular coding and/or design style. If this happens to be your
design/coding style, then it might behoove you to select the compiler
that does better, but this certainly doesn’t serve as a good
generalization (as if there is such a thing as a good generalization >

I’m not saying that benchmarks should be ignored, quite the
contrary in many cases. But I do think that they are often not
characterized properly.

Mario, you can make no assumption at all, as to what the final
executables performance would be from Comeau C object code compiled with
gcc without testing your C++ code with the actual toolchain (this sucks,
but that’s life - who knows it might be 30-40% slower, or 10-20% faster
> . Personally, I would much rather use a 99% compliant compiler
that’s 20% slower, than a 90% compliant compiler that just so happens to
“like” my (possibly non-C++) coding style.

Or 500 times faster, but with a broken optimization
(IOWs, fast code that does the wrong thing). Anyway, yes,
we can be across the board here depending upon OS, styles, etc.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

[Miguel_Simon1]

Hi…

Greg Comeau wrote:

In article <> 3B9D48F0.921E293@ou.edu> >, Miguel Simon <> simon@ou.edu> > wrote:
Colin Burgess wrote:
However, I don’t see any reasons why this shouldn’t work out, especially
since it just sits on top of gcc.

According to some of the comments made by others, it seems that a
perceived problem is the gcc compiler, and that this being the case,
then Comeau C++ will not necessarily help at compile time.

It depends what you’re tying to “help”.

Ok, please keep in mind that my particular background is in controls,
embedded systems, robotics, etc., BUT NOT in computer science, compilers
and the like. In general I use compilers as tools, but I am not well
versed in the art of compilers at large.

Having said that, then how will Comeau ‘front-end’ help given…

C code => gcc => ok, not too bad |
| => obj file => exec bin file
C++ code => g++ => buggy, very bad |

when we want both C/C++ to generate (please, think embedded systems for
hard real-time applications which is an application realm with very
different needs to that of desk-OS, soft real-time, pseudo real-time and
postmortem data analysis platform and the like such as UNIX (SGI,
Solaris, Linux et. all), $$indow$, etc.):

1. bug free code => robust…
2. fast executable code => opt. or near optimal in exec. time…
3. small sized code => because of limited memory…

THEN enter Comeau front-end…

C code => | | gcc |
| => Comeau => | | => exec.obj => exec.bin
C++ code => | | g++ |

needed??
optional??

What I do not see is what does Comeau do to "help" attain points (1),
(2), (3) in any optimal combination?  By modifying the original code via
<Comeau-front-end>, and then presenting the whole thing to the gcc or
g++ compiler?

Then, if I read correctly, you mentioned in another sub-thread that
Comeau *could* do away with g++ altogether?

I understand that there are some trade off.  How will Comeau "help" with
both the C and C++ cases?  Do you optimize one over the other (say C
over C++)?  So if I hear you correctly, Greg, it seems that you can
"help" in some measure... which one: (1), (2), (3), a combination?  All
three?  For both C and C++?  Could you clearly stay what Comeau
would/could/will/can/wouldn't/couldn't/will-not/can-not do to help with
the needs of the QNX/Neutrino hard real-time community of embedded
developers and their applications?  (I guess that I am asking for a
white paper tailored to the aforementioned community?)

Please enlighten me at will for I rather be ignorant this one time as
opposed to remaining ignorant the rest of my life.

Thanks...

Bests Regards...

Miguel.

> If the above is true, then what is the advantage of having a 'front-end'
> over gcc if the compiler will be the same regardless -namely gcc?
>
> The compiler systems (the whole thing) won't be the same, by virtue
> of the "front end".
>
> I'm not quite sure what you're asking and/or getting at in
> your post.
> --
> Greg Comeau         export ETA: Dec 1    10% "End of Summer" Offer
> Comeau C/C++ ONLINE ==>     > http://www.comeaucomputing.com/tryitout
> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

--
---
my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.
---
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com