* C++ PATCH: PR 15815
@ 2004-06-07 19:58 Mark Mitchell
2004-06-08 12:10 ` Ranjit Mathew
` (3 more replies)
0 siblings, 4 replies; 15+ messages in thread
From: Mark Mitchell @ 2004-06-07 19:58 UTC (permalink / raw)
To: gcc-patches; +Cc: gp
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-07 19:58 C++ PATCH: PR 15815 Mark Mitchell
@ 2004-06-08 12:10 ` Ranjit Mathew
2004-06-08 15:41 ` Jason Merrill
2004-06-08 16:57 ` Jason Merrill
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Ranjit Mathew @ 2004-06-08 12:10 UTC (permalink / raw)
To: mark; +Cc: gcc-patches, java
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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-08 12:10 ` Ranjit Mathew
@ 2004-06-08 15:41 ` Jason Merrill
0 siblings, 0 replies; 15+ messages in thread
From: Jason Merrill @ 2004-06-08 15:41 UTC (permalink / raw)
To: Ranjit Mathew; +Cc: mark, gcc-patches, java
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-07 19:58 C++ PATCH: PR 15815 Mark Mitchell
2004-06-08 12:10 ` Ranjit Mathew
@ 2004-06-08 16:57 ` Jason Merrill
2004-06-08 22:54 ` Gerald Pfeifer
2004-06-09 14:25 ` Ranjit Mathew
3 siblings, 0 replies; 15+ messages in thread
From: Jason Merrill @ 2004-06-08 16:57 UTC (permalink / raw)
To: mark; +Cc: gcc-patches, gp
I'll incorporate this into my VA_ARG_EXPR lowering patch, which I will be
applying shortly.
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-07 19:58 C++ PATCH: PR 15815 Mark Mitchell
2004-06-08 12:10 ` Ranjit Mathew
2004-06-08 16:57 ` Jason Merrill
@ 2004-06-08 22:54 ` Gerald Pfeifer
2004-06-09 14:25 ` Ranjit Mathew
3 siblings, 0 replies; 15+ messages in thread
From: Gerald Pfeifer @ 2004-06-08 22:54 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-07 19:58 C++ PATCH: PR 15815 Mark Mitchell
` (2 preceding siblings ...)
2004-06-08 22:54 ` Gerald Pfeifer
@ 2004-06-09 14:25 ` Ranjit Mathew
2004-06-09 15:41 ` Mark Mitchell
3 siblings, 1 reply; 15+ messages in thread
From: Ranjit Mathew @ 2004-06-09 14:25 UTC (permalink / raw)
To: gcc-patches; +Cc: gp
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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 14:25 ` Ranjit Mathew
@ 2004-06-09 15:41 ` Mark Mitchell
2004-06-09 18:27 ` Geoff Keating
0 siblings, 1 reply; 15+ messages in thread
From: Mark Mitchell @ 2004-06-09 15:41 UTC (permalink / raw)
To: Ranjit Mathew; +Cc: gp, gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 15:41 ` Mark Mitchell
@ 2004-06-09 18:27 ` Geoff Keating
2004-06-09 19:09 ` Mark Mitchell
0 siblings, 1 reply; 15+ messages in thread
From: Geoff Keating @ 2004-06-09 18:27 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gp, gcc-patches
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 18:27 ` Geoff Keating
@ 2004-06-09 19:09 ` Mark Mitchell
2004-06-09 20:09 ` Jason Merrill
2004-06-09 20:12 ` Geoff Keating
0 siblings, 2 replies; 15+ messages in thread
From: Mark Mitchell @ 2004-06-09 19:09 UTC (permalink / raw)
To: Geoff Keating; +Cc: gp, gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 19:09 ` Mark Mitchell
@ 2004-06-09 20:09 ` Jason Merrill
2004-06-09 20:10 ` Mark Mitchell
2004-06-09 20:12 ` Geoff Keating
1 sibling, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2004-06-09 20:09 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Geoff Keating, gp, gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 20:09 ` Jason Merrill
@ 2004-06-09 20:10 ` Mark Mitchell
2004-06-10 8:14 ` Ranjit Mathew
0 siblings, 1 reply; 15+ messages in thread
From: Mark Mitchell @ 2004-06-09 20:10 UTC (permalink / raw)
To: Jason Merrill; +Cc: Geoff Keating, gp, gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 19:09 ` Mark Mitchell
2004-06-09 20:09 ` Jason Merrill
@ 2004-06-09 20:12 ` Geoff Keating
1 sibling, 0 replies; 15+ messages in thread
From: Geoff Keating @ 2004-06-09 20:12 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gp, gcc-patches
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-09 20:10 ` Mark Mitchell
@ 2004-06-10 8:14 ` Ranjit Mathew
2004-06-10 14:50 ` Mark Mitchell
0 siblings, 1 reply; 15+ messages in thread
From: Ranjit Mathew @ 2004-06-10 8:14 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc-patches, jason
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/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-10 8:14 ` Ranjit Mathew
@ 2004-06-10 14:50 ` Mark Mitchell
2004-06-10 17:27 ` Jason Merrill
0 siblings, 1 reply; 15+ messages in thread
From: Mark Mitchell @ 2004-06-10 14:50 UTC (permalink / raw)
To: Ranjit Mathew; +Cc: gcc-patches, jason
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCH: PR 15815
2004-06-10 14:50 ` Mark Mitchell
@ 2004-06-10 17:27 ` Jason Merrill
0 siblings, 0 replies; 15+ messages in thread
From: Jason Merrill @ 2004-06-10 17:27 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Ranjit Mathew, gcc-patches
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-06-10 15:26 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-07 19:58 C++ PATCH: PR 15815 Mark Mitchell
2004-06-08 12:10 ` Ranjit Mathew
2004-06-08 15:41 ` Jason Merrill
2004-06-08 16:57 ` Jason Merrill
2004-06-08 22:54 ` Gerald Pfeifer
2004-06-09 14:25 ` Ranjit Mathew
2004-06-09 15:41 ` Mark Mitchell
2004-06-09 18:27 ` Geoff Keating
2004-06-09 19:09 ` Mark Mitchell
2004-06-09 20:09 ` Jason Merrill
2004-06-09 20:10 ` Mark Mitchell
2004-06-10 8:14 ` Ranjit Mathew
2004-06-10 14:50 ` Mark Mitchell
2004-06-10 17:27 ` Jason Merrill
2004-06-09 20:12 ` Geoff Keating
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).