Re: opinions wanted on control of extern inlines

Jason Merrill <jason@cygnus.com>
4 Aug 1998 22:16:34 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Language Books rkneusel@post.its.mcw.edu (1998-07-27)
opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-07-27)
Re: opinions wanted on control of extern inlines dwight@pentasoft.com (1998-07-28)
Re: opinions wanted on control of extern inlines saroj@my-dejanews.com (1998-07-30)
Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-02)
Re: opinions wanted on control of extern inlines bothner@cygnus.com (1998-08-02)
Re: opinions wanted on control of extern inlines jason@cygnus.com (Jason Merrill) (1998-08-04)
Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-10)
| List of all articles for this month |
From: Jason Merrill <jason@cygnus.com>
Newsgroups: comp.compilers
Date: 4 Aug 1998 22:16:34 -0400
Organization: Cygnus Solutions, Sunnyvale, CA
References: 98-07-131 98-07-187 98-07-198 98-07-208 98-07-223 98-07-230 98-08-006
Keywords: GCC, C++

>>>>> Rachel-Louise Koktava <KittyCrap@severins-child.demon.co.uk> writes:


> The use of other compilers is questionable. Wind River Systems (WRS) do
> not support the loading of ELF object files onto an embedded sparc
> target so any compiler must produce the default a.out-coff format for
> sparc chips.


This is unfortunate, since egcs g++ (and 2.8.x) support for
eliminating duplication is much better under ELF (and Windows
PE/COFF); the GNU linker just throws away extra copies. a.out is not
flexible enough to support this. I think COFF probably could, but
this hasn't been implemented, and a quick check indicates that SPARC
VxWorks uses a.out.


> My original suggest seems to be flawed. The #pragma interface and
> #pragma implementation directives cause a closed set of templates


Only if you use the obsolete -fexternal-templates flag. Without that
flag, they still serve their original purpose of controlling the
placement of vtables and extern inlines.


> However the repo patch cannot be employed as a viewpathing mechanism is
> used to undertake changes to code. The repo patch can (and does) try to
> recompile official build source from down the viewpath, which fails
> since since users don't have write permission to these directories.


The repo patch (which is folded into egcs) only tries to rebuild
object files with associated .rpo files, so you can control where it
tries to insert template instantiations. I'm not sure what your exact
situation is, but you can compile some files with -frepo and others
with -fno-implicit-templates, and then only the ones compiled with
-frepo will be considered. This may or may not be useful to you.


> As always, opinion and advise would be most welcome, and once again
> thanks to all who answered my original mail.


As the g++ maintainer, I'd like to work out something that could be
folded into the standard distribution, so that other people can
benefit from it. Let's talk.


Jason
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.