pro64-support
[Top] [All Lists]

RE: sgicc, __GNUC__, and -rdynamic

To: suneel_jain@xxxxxx, pro64-support@xxxxxxxxxxx, arnold@xxxxxxxxxx, Aharon Robbins <arnold@xxxxxxxxxx>
Subject: RE: sgicc, __GNUC__, and -rdynamic
From: mpm@xxxxxxxxxxxxxxxxx (Michael Murphy)
Date: Thu, 26 Apr 2001 10:30:50 -0700 (PDT)
Cc: beebe@xxxxxxxxxxxxx
Sender: owner-pro64-support@xxxxxxxxxxx
        From: Aharon Robbins <arnold@xxxxxxxxxx>
        
        I stand corrected.  That the two compilers share the same front-end
        wasn't obvious.  Since that is the case, I'll agree that adding
        -rdynamic support is the right way to go.
        
As Suneel explained, I think we should define __GNUC__.
It looks like all gcc does with -rdynamic is to pass -export-dynamic
to collect2.  Is that correct?  One question is why not just pass
-export-dynamic instead of -rdynamic?  sgicc currently doesn't handle
either one, but I can add that easily enough.  In the meantime you
could use -Wl,-export-dynamic.

        This information then leads one to ask if the IA-64 back end will
        eventually be merged into the main GCC code base?  And in the
        meantime, for IA-64, why not just make sgicc be gcc?
        
There is a separate ia64 gcc, that uses the gcc back-end.
GCC (at least the people we talked to), is not interested in using
our backend.  So we have two competing compilers.

        Thanks!
        
        Arnold
        
        > From: "JAIN,SUNEEL (HP-Cupertino,ex1)" <suneel_jain@xxxxxx>
        > To: "'Aharon Robbins'" <arnold@xxxxxxxxxx>,
        >         "'pro64-support@xxxxxxxxxxx'" <pro64-support@xxxxxxxxxxx>
        > Subject: RE: sgicc, __GNUC__, and -rdynamic
        > Date: Thu, 26 Apr 2001 08:51:19 -0700
        >
        > > Nelson understates the case. The -rdynamic flag can't be the only 
part
        > > of GCC that sgicc doesn't support. There are a slew of 
        > > language extensions
        > > that GNU code often makes use of --- properly ifdef-ed, of 
        > > course --- and
        > > defining __GNUC__ is just shouting a request for trouble.
        > > 
        > > Hmmm, I guess I just paraphrased what Nelson said, didn't I?  Oh 
well.
        > >:-)
        > > 
        > > > Fix (2) is less desirable, since leaving __GNUC__ defined can have
        > > > other side effects, as noted in the previous paragraph.  However, 
it
        > > > still may be useful to add support for -rdynamic, possibly under a
        > > > different name, provided __GNUC__ remains undefined.
        > > 
        > > The two issues are and should be treated orthogonally.  
        > > Undefining __GNUC__
        > > for sgicc should be done in any case, whether or not support 
        > > for -rdynamic
        > > is added.
        >
        > The sgicc and sgiCC compilers share frontends, preprocessor,
        > assembler, linker, debugger with GNU gcc/g++ compilers. They support 
        > the same language extensions that the GNU compilers do. One way to 
        > view the SGI compilers is that they provide an alternate 
        > backend for the IA64 architecture. 
        >
        > Given this, I think it is perfectly reasonable for sgicc to 
        > define __GNUC__. It should be plug compatible to gcc and
        > adding support for -rdynamic seems like the right answer.
        >
        > - Suneel Jain
        
-- Mike Murphy
-- mpm@xxxxxxx
-- quote of the day:
--  "Time is the most valuable coin in your life.  You and you alone will
--   determine how that coin will be spent.  Be careful that you do not let
--   other people spend it for you."  (Carl Sandburg)

<Prev in Thread] Current Thread [Next in Thread>