🚀 go-pugleaf

Axel Thimm (axl@zedat.fu-berlin.de) wrote:

>  I tried CC and cc but e.g. neither recognizes 'bool' as an integrated
> type. Are there any flags, I should have put into the compiler line? I
> looked at the man pages but found nothing. The C++ progs have .cc
> suffices.

C doesn't have a bool type anyway. The C++ bool type is relatively new, and
the 6.1 compiler doesn't have it. The -64 and -n32 compilers on Irix 6.2
will recognize bool.

In the meantime, there's a simple source workaround for bool, which will
interoperate with the real bool when you get Irix 6.2 (after its release):

    #ifndef _BOOL
    /* Builtin bool not available - use typedef */
    typedef unsigned char bool;
    static const bool false = 0;
    static const bool true = 1;
    #endif /* _BOOL */

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar

shankar@engr.sgi.com (Shankar Unni) wrote:

>Axel Thimm (axl@zedat.fu-berlin.de) wrote:

>>  I tried CC and cc but e.g. neither recognizes 'bool' as an integrated
>> type. Are there any flags, I should have put into the compiler line? I
>> looked at the man pages but found nothing. The C++ progs have .cc
>> suffices.

>C doesn't have a bool type anyway. The C++ bool type is relatively new, and
>the 6.1 compiler doesn't have it. The -64 and -n32 compilers on Irix 6.2
>will recognize bool.

>In the meantime, there's a simple source workaround for bool, which will
>interoperate with the real bool when you get Irix 6.2 (after its release):

[...]

Well, overcoming the bool problem is not very difficult, enums, classes
or defines can help there. (I have received a lot of email about that,
thank you all).
My fears are that it will not stop there. Even gcc violated many ARM
(not yet ANSI/ISO) rules, which should have become standard since 1990.
I refer to the template problems mostly (gcc 2.7.x has cured a lot of
those violations.)
In another thread I read about how much better gcc conforms to the
standards compared to CC. So it seems to me that CC might also have
problems with templates. I think that incorporating bool types should
not be a problem for the compiler writers, fixing template classes will
almost certainly be.
Is there someone with experience in template programming under CC? If
pointed to the problems one could possibly avoid defining problematic
templates.

Thank you,
	Axel Thimm
===
Axel Thimm <axl@zedat.fu-berlin.de>
Freie Universitaet Berlin
===

Axel Thimm (axl@zedat.fu-berlin.de) wrote:

> Is there someone with experience in template programming under CC? If
> pointed to the problems one could possibly avoid defining problematic
> templates.

I'll leave it to the other readers of this group to comment on their
experiences with templates. We've fixed many, many bugs with templates, and
certainly all of the ARM stuff works. The new ANSI stuff (the proposed ANSI
template compilation model, partial specialization, member templates, etc)
are not in, however.

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar

: > If the SGI compiler is really that bad, then I would like to install
: >gcc/g++. Are there any convenient precompiled versions I could download,
: >or will I have to install gcc myself? (I am already a little scared.)

My experience is that g++ is more up to date, and has much better
template handling. However, SGI C++ produces much better code. I would
avoid uses of templates that SGI does not support, since gnu is known 
to implmement things before they are completely defined.

--jono

--
"The human mind is a dangerous plaything, boys. When it's used for evil, 
watch out! But when it's used for good, then things are much nicer." 
                                                            -- The Tick
<Home Page: http://www.cse.ucsc.edu/~jono>

Bruce Leasure <bleasure> writes:

>axl@zedat.fu-berlin.de (Axel Thimm) wrote:
>>
>> If the SGI compiler is really that bad, then I would like to install
>>gcc/g++. Are there any convenient precompiled versions I could download,
>>or will I have to install gcc myself? (I am already a little scared.)

>Photon C++ is also available on SGI systems. It is much closer to the draft
>standard than SGI C++, and is link compatible with SGI C++.  It does support 
>the bool type. It is available on the web, in precompiled form. 30 day
>evaluation licenses are available, so you can see if it solves your problem 
>for free. For more information see:

>    http:/www/kai.com/photon/photon_what_is.html

I was about to order several copies, when I found out that they don't
support SGI's debugging enhancements, so its code is un-debuggable within
CaseVision WorkShop. Too bad too, because it did seem pretty fast.

>-- 
>Bruce Leasure      Kuck & Associates, Inc.   bleasure@kai.com
>                   1906 Fox Drive            Voice: 217-356-2288
>                   Champaign, IL 61820       Fax:   217-356-5199
>		   USA

--
Paul Miller                  | paul@elastic.avid.com
SGI Senior Software Engineer | "I am Homer of Borg. You will... Oh! Donuts!"
     Elastic Reality - a division of Avid Technology, Inc.

In article <4fbhs0$eo3@fido.asd.sgi.com>, shankar@engr.sgi.com (Shankar Unni) writes:
> 
> I'll leave it to the other readers of this group to comment on their
> experiences with templates. ...


Well, while not exactly in the bugs department, but I have found
	that the SGI implementation of templates is significantly
	slower than GCC-

The GNU complex library uses templates, and when compiled
	by the SGI compiler, it's about 2 times slower
	than when compiled by G++ (both using -mips2 -O).
	If the GNU complex library is modified (to get rid
	of templates), the SGI-compiled code becomes as fast
	as the GCC-compiled code.


C.O.

In article <4ffu78$b2j@cnn.Princeton.EDU>, tim@franck says...
>Don't be.  gcc is easier to install than, for example, Perl.

Are you referring to installing a previously compiled GCC binary?  I found
PERL far easier to build from source than GCC.  Of all the software I've 
built from source, PINE was the easiest...it required a single step.
GCC took several attempts and many steps...or am I missing something not
mentioned in the GCC documentation?

-- 
============================================================================
matthew black, network analyst  | opinions expressed herein are mine and
california state university     | may not reflect those of my employer
cecs department                 |
long beach, ca 90840            | email: black@csulb.edu
=============================(c) 1996 by Matthew Black, all rights reserved=

In article <4fnoka$d1n@garuda.csulb.edu>,
	black@csulb.edu (Matthew Black) writes:
>In article <4ffu78$b2j@cnn.Princeton.EDU>, tim@franck says...

>Are you referring to installing a previously compiled GCC binary?  I found
>PERL far easier to build from source than GCC.  Of all the software I've 
>built from source, PINE was the easiest...it required a single step.

Blech. Try to build pine with any options other than ones they've
decided are best for you and you'll be editting files all day long.
Optimizing the code so it runs reasonably well takes another week.

>GCC took several attempts and many steps...or am I missing something not
>mentioned in the GCC documentation?

As long as you aren't building on an unsupported platform, or building a
cross-compiler, you can just do:

./configure [config-options]
make bootstrap
make install

jonathan
-- 
+++ Jonathan Rozes, Unix Systems Administrator, Tufts University
++  jrozes@tcs.tufts.edu, http://gumbo.tcs.tufts.edu/~jrozes/
+   Ultimately, thinking is a very inefficient method of processing
    data.... [Surfing the Himalayas, 0-312-14147-5]

In article <4fnrbe$v3u@d2.tufts.edu>, jrozes@gumbo.tcs.tufts.edu (Jonathan Rozes) writes:
> In article <4fnoka$d1n@garuda.csulb.edu>,
> 	black@csulb.edu (Matthew Black) writes:
> >In article <4ffu78$b2j@cnn.Princeton.EDU>, tim@franck says...
> 
> >GCC took several attempts and many steps...or am I missing something not
> >mentioned in the GCC documentation?
> 
> As long as you aren't building on an unsupported platform, or building a
> cross-compiler, you can just do:
> 
> ./configure [config-options]
> make bootstrap
> make install


Yes? And it takes only a couple of attempts to find out what
	these "[config-options]" are. And then you have to
	hand-build and hand-install the 'collect2' program.


C.O.

In article <4fl2nh$b66@sun20.ccd.bnl.gov>, olchansk@a2.phy.bnl.gov (Konstantin Olchanski) writes:
- 
- Well, while not exactly in the bugs department, but I have found
- 	that the SGI implementation of templates is significantly
- 	slower than GCC-
- 
- The GNU complex library uses templates, and when compiled
- 	by the SGI compiler, it's about 2 times slower
- 	than when compiled by G++ (both using -mips2 -O).
- 	If the GNU complex library is modified (to get rid
- 	of templates), the SGI-compiled code becomes as fast
- 	as the GCC-compiled code.

Essentially that is because the gcc implementation of templates is along
the lines of "proovide the minimum necessary to get it going", while
the ATT code (on which the SGI compiler is based) used a more general
approach.

The "complex" derived type is effectively too small to show the benefit 
of this generality, but gets to bear the full cost of it.

                             Thomas
-- 
*** Why not use metric units and get things right first time, every time.
*   email: cmaae47@ic.ac.uk (Thomas Sippel - Dau)
*   voice: +44 171 594 6904 (day), +44 171 594 6958 (fax), +44 171 385 6540
*   snail: ICSTM, Computing Services, Kensington SW7 2BX, Great Britain

Thomas Sippel - Dau (vulture@imperial.ac.uk) wrote:

> Essentially that is because the gcc implementation of templates is along
> the lines of "proovide the minimum necessary to get it going", while
> the ATT code (on which the SGI compiler is based) used a more general
> approach.

Umm, the SGI compiler is NOT ATT-based (at least, not since
Irix 5.3/Irix 6.0.1).

I assume the original poster meant that the generated code ran slowly, not
that the compilation itself was slower..

There *is* a known bug that I found recently (for which there won't be a fix
in Irix 6.2, since we found the problem too late to get into that release - it
will be fixed in a patch), where if you declare a template member function
in the following way, it's NOT inlined:

  template <class T> class Foo {
      ...
      void memfunc();	/* no inline specification here */
      ...
  };

  template <class T> inline Foo<T>::memfunc()
  {
    /* defined as inline, but compiler will fail to inline it */
  }


The workaround for this problem is to stick the inline keyword before the
declaration of the member function inside the template class.

This *may* be the reason for the slowness.  In all other respects, there
should be no difference between template and non-template code.
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar

shankar@mti.sgi.com (Shankar Unni) writes:

>There *is* a known bug that I found recently (for which there won't be a fix
>in Irix 6.2, since we found the problem too late to get into that release - it
>will be fixed in a patch), where if you declare a template member function
>in the following way, it's NOT inlined:

>  template <class T> class Foo {
>      ...
>      void memfunc();	/* no inline specification here */
>      ...
>  };

>  template <class T> inline Foo<T>::memfunc()
>  {
>    /* defined as inline, but compiler will fail to inline it */
>  }


>The workaround for this problem is to stick the inline keyword before the
>declaration of the member function inside the template class.

Is there any similar problem with inlining non-member template functions?
What is the easiest way to tell if a function actually did get inlined?

------------------------------------------------------------------------
Laurence G. Yaffe		lgy@phys.washington.edu
University of Washington	1-206-543-3902 (fax: 1-206-543-9523)

Laurence Yaffe (lgy@newton.phys.washington.edu) wrote:

> Is there any similar problem with inlining non-member template functions?

No.

> What is the easiest way to tell if a function actually did get inlined?

Run "nm" on a .o that calls the inline function, and see if there's a
symbol for the name of the inline function. If there is, that function did
not get inlined in one or more places..

(Actually, in releases before patch 556, turning on -g would cause dummy
bodies to be emitted for inline functions - the theory being that you would
maybe want to call them from a debugger command line - but we've stopped
doing that now. Still, this "nm" test is really reliable only for an object
compiled without -g).

We're looking into putting in warnings in the compiler whenever it can't
inline something that's declared inline.  This wouldn't have caught the
template case above (that was a plain bug where the compiler dropped the
respecification on the floor), however..
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar