C++ PATCH: PR 15815

C++ PATCH: PR 15815

[Mark Mitchell]

This patch deprecates "#pragma interface" and "#pragma implementation"
as per PR 15815.  I'll remove these before 3.5.0.

Gerald, are we supposed to add to the top of gcc-3.4/changes.html or
make a new file to announce these kinds of changes?

Tested on i686-pc-linux-gnu, applied on the 3.4 branch and the
mainline.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2004-06-07  Mark Mitchell  <mark@codesourcery.com>

	PR c++/15815
	* lex.c (handle_pragma_interface): Deprecate.
	(handle_pragma_implementation): Likewise.

2004-06-07  Mark Mitchell  <mark@codesourcery.com>

	PR c++/15815
	* doc/extend.texi: Deprecate #pragma interface and #pragma
	implementation.

Index: cp/lex.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/lex.c,v
retrieving revision 1.323.2.2
diff -c -5 -p -r1.323.2.2 lex.c
*** cp/lex.c	1 Mar 2004 20:39:10 -0000	1.323.2.2
--- cp/lex.c	7 Jun 2004 19:16:00 -0000
*************** handle_pragma_interface (cpp_reader* dfi
*** 528,537 ****
--- 528,540 ----
  {
    tree fname = parse_strconst_pragma ("interface", 1);
    struct c_fileinfo *finfo;
    const char *main_filename;
  
+   warning ("`#pragma interface' is deprecated and will be removed in a "
+ 	   "future version of GCC");
+ 
    if (fname == (tree)-1)
      return;
    else if (fname == 0)
      main_filename = lbasename (input_filename);
    else
*************** handle_pragma_implementation (cpp_reader
*** 570,579 ****
--- 573,585 ----
  {
    tree fname = parse_strconst_pragma ("implementation", 1);
    const char *main_filename;
    struct impl_files *ifiles = impl_file_chain;
  
+   warning ("`#pragma implementation' is deprecated and will be removed in a "
+ 	   "future version of GCC");
+ 
    if (fname == (tree)-1)
      return;
  
    if (fname == 0)
      {
Index: doc/extend.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.177.4.9
diff -c -5 -p -r1.177.4.9 extend.texi
*** doc/extend.texi	15 May 2004 10:04:03 -0000	1.177.4.9
--- doc/extend.texi	7 Jun 2004 19:16:00 -0000
*************** use of the header file.
*** 7968,7977 ****
--- 7968,7980 ----
  
  @table @code
  @item #pragma interface
  @itemx #pragma interface "@var{subdir}/@var{objects}.h"
  @kindex #pragma interface
+ This @samp{#pragma} has been deprecated and will be removed in a
+ future release of GCC.
+ 
  Use this directive in @emph{header files} that define object classes, to save
  space in most of the object files that use those classes.  Normally,
  local copies of certain information (backup copies of inline member
  functions, debugging information, and the internal tables that implement
  virtual functions) must be kept in each object file that includes class
*************** use this form, you must specify the same
*** 7988,7997 ****
--- 7991,8003 ----
  implementation}.
  
  @item #pragma implementation
  @itemx #pragma implementation "@var{objects}.h"
  @kindex #pragma implementation
+ This @samp{#pragma} has been deprecated and will be removed in a
+ future release of GCC.
+ 
  Use this pragma in a @emph{main input file}, when you want full output from
  included header files to be generated (and made globally visible).  The
  included header file, in turn, should use @samp{#pragma interface}.
  Backup copies of inline member functions, debugging information, and the
  internal tables used to implement virtual functions are all generated in

Re: C++ PATCH: PR 15815

[Ranjit Mathew]

Mark Mitchell wrote:

> This patch deprecates "#pragma interface" and "#pragma implementation"
> as per PR 15815.  I'll remove these before 3.5.0.

Hi Mark,

    The warnings introduced by this patch cause these
failures in the libjava testsuite:

  FAIL: natPR9577.cc compilation
  FAIL: natlongfield.cc compilation
  FAIL: natshortfield.cc compilation

To fix these, I tried to remove all instances of
"#pragma interface" and "#pragma implementation" from
GCJ and libjava.

However, this caused a link failure for libjava where
the linker is unable to find "_Jv_InitClass".

This function is declared 'extern "C"' in
"libjava/java/lang/Class.h" (and elsewhere, as needed).

The same header file defines this function as an "inline friend"
function. It had a "#pragma interface" (and
"libjava/java/lang/natClass.cc" had the corresponding
"#pragma implementation") that I was trying to remove.

So what's the best way out of this situation without
adversely impacting the performance? (_Jv_InitClass() is
heavily used all over the place.)

(FYI, I'm on Red Hat Enterprise Linux 3 Update 2, binutils
is 2.14.90.0.4 20030523.)

Thanks,
Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: C++ PATCH: PR 15815

[Jason Merrill]

On Tue, 08 Jun 2004 12:53:07 +0530, Ranjit Mathew <rmathew@gmail.com> wrote:

> However, this caused a link failure for libjava where
> the linker is unable to find "_Jv_InitClass".
>
> This function is declared 'extern "C"' in
> "libjava/java/lang/Class.h" (and elsewhere, as needed).
>
> The same header file defines this function as an "inline friend"
> function.

This function should not be declared inline, since it's a hook for the Java
front end.

Jason

Re: C++ PATCH: PR 15815

[Jason Merrill]

I'll incorporate this into my VA_ARG_EXPR lowering patch, which I will be
applying shortly.

Jason

Re: C++ PATCH: PR 15815

[Gerald Pfeifer]

On Mon, 7 Jun 2004, Mark Mitchell wrote:
> This patch deprecates "#pragma interface" and "#pragma implementation"
> as per PR 15815.  I'll remove these before 3.5.0.
> 
> Gerald, are we supposed to add to the top of gcc-3.4/changes.html or
> make a new file to announce these kinds of changes?

This is an interesting case, for we usually didn't make changes of this
kind for a point release.

I just added a new section at the end of gcc-3.4/changes.html, but
given the impact of this change (that is, deprecation), I would consider
documenting this change both there _and_ in the main part of that file,
with a note that the change applies to 3.4.1 and later.

Gerald

Re: C++ PATCH: PR 15815

[Ranjit Mathew]

Mark Mitchell wrote:
> This patch deprecates "#pragma interface" and "#pragma implementation"
> as per PR 15815.  I'll remove these before 3.5.0.

Hang on - what's the alternative that does the same
thing? That is, inline wherever possible and emit a
backup copy once. (The "once" bit is not necessary
with GNU ld but the "backup" bit is.)

Consider:
--------------------------- 8< ---------------------------
~/src/test/inline > cat x.h
#pragma interface

class X
{
public:
  void junk( void) { }
};

~/src/test/inline > cat x.cpp
#pragma implementation

#include "x.h"

~/src/test/inline > ~/gcc/bin/g++ -O2 -c x.cpp

~/src/test/inline > nm x.o
00000000 W _ZN1X4junkEv
--------------------------- 8< ---------------------------

If I remove the two "#pragma"-s, the definition
for "junk()" is not emitted at all, even if I
specify "-fkeep-inline-functions".

"-fno-default-inline" would unnecessarily pessimise
things.

So what's the practical alternative?

Thanks,
Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: C++ PATCH: PR 15815

[Mark Mitchell]

Ranjit Mathew wrote:

> Mark Mitchell wrote:
> 
>>This patch deprecates "#pragma interface" and "#pragma implementation"
>>as per PR 15815.  I'll remove these before 3.5.0. 

> Hang on - what's the alternative that does the same
> thing? That is, inline wherever possible and emit a
> backup copy once. (The "once" bit is not necessary
> with GNU ld but the "backup" bit is.)

In a conforming program, there's no need for the backup version.

If you need an out of line copy, write a non-inline function that calls 
the inline function.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: C++ PATCH: PR 15815

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> Ranjit Mathew wrote:
> 
> > Mark Mitchell wrote:
> >
> >>This patch deprecates "#pragma interface" and "#pragma implementation"
> >> as per PR 15815.  I'll remove these before 3.5.0.
> 
> > Hang on - what's the alternative that does the same
> > thing? That is, inline wherever possible and emit a
> > backup copy once. (The "once" bit is not necessary
> > with GNU ld but the "backup" bit is.)
> 
> In a conforming program, there's no need for the backup version.
> 
> If you need an out of line copy, write a non-inline function that
> calls the inline function.

I can think of one case.  Suppose you're writing a shared library, and
you want to make as much shared as possible.  It would be nice to be
able to force a single out-of-line copy of the inline function, so
that it doesn't get put in every application that uses the library.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: C++ PATCH: PR 15815

[Mark Mitchell]

Geoff Keating wrote:

> I can think of one case.  Suppose you're writing a shared library, and
> you want to make as much shared as possible.  It would be nice to be
> able to force a single out-of-line copy of the inline function, so
> that it doesn't get put in every application that uses the library.

In that case, you probably didn't really want it to be inline.  If you 
really did want it to be inline with the shared object, but not in other 
parts of your application, then you need to create two different copies 
of the function -- an inline one and a non-inline one, which calls the 
inline version.  Or, you can make the inline body visible only within 
the shared library, using macros.

"#pragma interface" and "#pragma implementation" are just unportable 
ways of doing that kind of thing.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: C++ PATCH: PR 15815

[Jason Merrill]

On Wed, 09 Jun 2004 11:06:54 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> Geoff Keating wrote:
>
>> I can think of one case.  Suppose you're writing a shared library, and
>> you want to make as much shared as possible.  It would be nice to be
>> able to force a single out-of-line copy of the inline function, so
>> that it doesn't get put in every application that uses the library.
>
> In that case, you probably didn't really want it to be inline.  If you
> really did want it to be inline with the shared object, but not in other
> parts of your application, then you need to create two different copies of
> the function -- an inline one and a non-inline one, which calls the inline
> version.  Or, you can make the inline body visible only within the shared
> library, using macros.
>
> "#pragma interface" and "#pragma implementation" are just unportable ways
> of doing that kind of thing.

Unportable, but much simpler than the workarounds you describe, and still
quite widespread--throughout libjava, for instance.  Removing this
extension will cause a lot of headaches.

The PR is about misleading documentation.  Removing the feature seems like
a significant overreaction.

Jason

Re: C++ PATCH: PR 15815

[Mark Mitchell]

Jason Merrill wrote:

> The PR is about misleading documentation.  Removing the feature seems like
> a significant overreaction.

Well, OK.

I was just doing what the PR said to do, based on what seemed to have 
been agreed on the mailing list, as referenced by the PR...

Let's go ahead and revert the patch.  I actually asked Andrew to help 
with that yesterday, since I had ridiculously poor network access, but 
if it hasn't already happened, I'll take care of it now.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: C++ PATCH: PR 15815

[Geoff Keating]

On 09/06/2004, at 11:06 AM, Mark Mitchell wrote:

> Geoff Keating wrote:
>
>> I can think of one case.  Suppose you're writing a shared library, and
>> you want to make as much shared as possible.  It would be nice to be
>> able to force a single out-of-line copy of the inline function, so
>> that it doesn't get put in every application that uses the library.
>
> In that case, you probably didn't really want it to be inline.  If you 
> really did want it to be inline with the shared object, but not in 
> other parts of your application, then you need to create two different 
> copies of the function -- an inline one and a non-inline one, which 
> calls the inline version.  Or, you can make the inline body visible 
> only within the shared library, using macros.

No, no.  You want it to be inlined everywhere.  However, there are 
cases where it can't be inline (someone takes an address, -O0, 
whatever).  In those cases, you'd like them to use one copy in the 
shared library, not a copy in each application.  This is actually worse 
when the routine *is* a good candidate for inlining, because that's 
when it's least likely that the routine will end up in the shared 
library anyway.

Re: C++ PATCH: PR 15815

[Ranjit Mathew]

Mark Mitchell wrote:
> Jason Merrill wrote:
> 
> 
>>The PR is about misleading documentation.  Removing the feature seems like
>>a significant overreaction.
> 
> 
> Well, OK.
> 
> I was just doing what the PR said to do, based on what seemed to have 
> been agreed on the mailing list, as referenced by the PR...
> 
> Let's go ahead and revert the patch.  I actually asked Andrew to help 
> with that yesterday, since I had ridiculously poor network access, but 
> if it hasn't already happened, I'll take care of it now.

Sorry Mark, it was not my intention to get you to revert
the patch at all - I was just trying to understand if there's
an equivalent "conformant" way of doing what these #pragma-s
did *with the same ease of use*. If there is, I'm willing
to work out a patch for Java that implements the alternative.

I like #pragma proliferation as much as your neighbour's dog
and I would be happy if you deprecate these for 3.5 (but not
for 3.4) and if you remove it in 3.6 *provided* you (or anyone
else) can tell me how it can be done with the same ease
of use.

With respect to inlining, these two #pragma-s inline functions
defined in the class declaration while creating a single
backup implementation. Alternatives could be:

1. Manually write a non-inlined stub that calls the inlined
   function as you suggested. However, this is cumbersome and
   IMHO is something that a compiler should do for me - you can
   say that I've been spoiled by these #pragma-s. ;-)

2. Always generate a backup copy for inlined functions for
   each compilation unit (or each compiler invocation). This
   might not work with linkers that do not understand linkonce
   semantics.

I do not know C++ that well - someone please correct me if
I'm horribly mistaken.

BTW, for the purpose of these #pragma-s, the C++ front end
seems to treat each header file separately (i.e. not go with
the abstraction of considering a fully-preprocessed source
file for compilation) - does the same apply for inlining
functions defined in class declarations? That is, would
functions defined in class declarations in indirectly included
headers also be inlined?

Thanks,
Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: C++ PATCH: PR 15815

[Mark Mitchell]

> With respect to inlining, these two #pragma-s inline functions
> defined in the class declaration while creating a single
> backup implementation. Alternatives could be:
> 
> 1. Manually write a non-inlined stub that calls the inlined
>    function as you suggested. However, this is cumbersome and
>    IMHO is something that a compiler should do for me - you can
>    say that I've been spoiled by these #pragma-s. ;-)
> 
> 2. Always generate a backup copy for inlined functions for
>    each compilation unit (or each compiler invocation). This
>    might not work with linkers that do not understand linkonce
>    semantics.

I think (1) is the best alternative to the #pragma approach; anything 
else will also require a compiler modification, and there's not much win 
in removing one set of compiler modifications only to replace it with 
another.

> BTW, for the purpose of these #pragma-s, the C++ front end
> seems to treat each header file separately (i.e. not go with
> the abstraction of considering a fully-preprocessed source
> file for compilation) - does the same apply for inlining
> functions defined in class declarations? That is, would
> functions defined in class declarations in indirectly included
> headers also be inlined?

I have no idea. :-)  Part of the reason I was glad that people seemd to 
have agreed to remove these #pragma directives was that nobody seemed 
very sure exactly what they were suppoed to do.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: C++ PATCH: PR 15815

[Jason Merrill]

On Thu, 10 Jun 2004 06:59:59 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

>> BTW, for the purpose of these #pragma-s, the C++ front end seems to
>> treat each header file separately (i.e. not go with the abstraction of
>> considering a fully-preprocessed source file for compilation) - does the
>> same apply for inlining functions defined in class declarations? That
>> is, would functions defined in class declarations in indirectly included
>> headers also be inlined?

Inlining is not affected by the #pragmas, only the out-of-line copies.

> I have no idea. :-)  Part of the reason I was glad that people seemd to
> have agreed to remove these #pragma directives was that nobody seemed very
> sure exactly what they were suppoed to do.

I'm pretty clear on it.  I'll fix the docs.

Jason