RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Zack Weinberg]

Of all the targets using config/rs6000, only *-linux* and *-windiss*
define NO_IMPLICIT_EXTERN_C.  This just bit me good and hard while
trying to use powerpc-eabisimaltivec -- altivec.h assumes it is safe
to use C++ constructs which will spew errors under extern "C".

I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire directory,
in rs6000.h.  What few targets this is inappropriate for -- I'm
willing to bet that's either none, or only AIX 3.1 -- can #undef it
again.

Comments?

zw

	* config/rs6000/rs6000.h: Define NO_IMPLICIT_EXTERN_C here...
	* config/rs6000/linux.h, config/rs6000/linux64.h,
	config/rs6000/windiss.h: ... not here.

===================================================================
Index: config/rs6000/rs6000.h
--- config/rs6000/rs6000.h	4 Nov 2002 16:57:09 -0000	1.234
+++ config/rs6000/rs6000.h	8 Nov 2002 04:49:15 -0000
@@ -24,6 +24,9 @@ Boston, MA 02111-1307, USA.  */
 /* Note that some other tm.h files include this one and then override
    many of the definitions.  */
 
+/* Header files should be C++ aware in general.  */
+#define NO_IMPLICIT_EXTERN_C
+
 /* Definitions for the object file format.  These are set at
    compile-time.  */
 
===================================================================
Index: config/rs6000/linux.h
--- config/rs6000/linux.h	14 Sep 2002 13:12:53 -0000	1.33
+++ config/rs6000/linux.h	8 Nov 2002 04:49:14 -0000
@@ -21,9 +21,6 @@ along with GNU CC; see the file COPYING.
 the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  */
 
-/* Don't assume anything about the header files.  */
-#define NO_IMPLICIT_EXTERN_C
-
 #undef MD_EXEC_PREFIX
 #undef MD_STARTFILE_PREFIX
 
===================================================================
Index: config/rs6000/linux64.h
--- config/rs6000/linux64.h	20 Sep 2002 23:46:59 -0000	1.30
+++ config/rs6000/linux64.h	8 Nov 2002 04:49:14 -0000
@@ -106,9 +106,6 @@ Boston, MA 02111-1307, USA.  */
    So we have to squirrel it away with this.  */
 #define SETUP_FRAME_ADDRESSES() rs6000_aix_emit_builtin_unwind_init ()
 
-/* Don't assume anything about the header files.  */
-#define NO_IMPLICIT_EXTERN_C
-
 /* Override svr4.h  */
 #undef MD_EXEC_PREFIX
 #undef MD_STARTFILE_PREFIX
===================================================================
Index: config/rs6000/windiss.h
--- config/rs6000/windiss.h	7 May 2002 14:42:29 -0000	1.1
+++ config/rs6000/windiss.h	8 Nov 2002 04:49:15 -0000
@@ -45,5 +45,3 @@ Boston, MA 02111-1307, USA.  */
 
 #undef WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE 16
-
-#define NO_IMPLICIT_EXTERN_C

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[David Edelsohn]

> Of all the targets using config/rs6000, only *-linux* and *-windiss*
> define NO_IMPLICIT_EXTERN_C.  This just bit me good and hard while
> trying to use powerpc-eabisimaltivec -- altivec.h assumes it is safe
> to use C++ constructs which will spew errors under extern "C".
>
> I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire directory,
> in rs6000.h.  What few targets this is inappropriate for -- I'm
> willing to bet that's either none, or only AIX 3.1 -- can #undef it
> again.
>
> Comments?

	I could see placing this in sysv4.h, but not rs6000.h.  I do not
believe that GCC's fixincludes completely addresses the C++ issues in the
AIX header files.  IBM Visual Age C++ distributes its own system header
files.

David

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Mark Mitchell]

--On Thursday, November 07, 2002 08:50:46 PM -0800 Zack Weinberg 
<zack@codesourcery.com> wrote:

> Of all the targets using config/rs6000, only *-linux* and *-windiss*
> define NO_IMPLICIT_EXTERN_C.  This just bit me good and hard while
> trying to use powerpc-eabisimaltivec -- altivec.h assumes it is safe
> to use C++ constructs which will spew errors under extern "C".
>
> I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire directory,
> in rs6000.h.  What few targets this is inappropriate for -- I'm
> willing to bet that's either none, or only AIX 3.1 -- can #undef it
> again.

That seems OK to me, but let's let give the RS6000 maintainers
a few days to comment.  If they don't say no, check it in.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Zack Weinberg]

On Fri, Nov 08, 2002 at 10:56:24AM -0500, David Edelsohn wrote:
> >
> > I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire directory,
> > in rs6000.h.  What few targets this is inappropriate for -- I'm
> > willing to bet that's either none, or only AIX 3.1 -- can #undef it
> > again.
> >
> > Comments?
> 
> 	I could see placing this in sysv4.h, but not rs6000.h.  I do not
> believe that GCC's fixincludes completely addresses the C++ issues in the
> AIX header files.  IBM Visual Age C++ distributes its own system header
> files.

Defining or not defining NO_IMPLICIT_EXTERN_C addresses only one C++
issue with system headers.  It should be defined by all targets where
the system headers already wrap declarations in extern "C" { ... }
when appropriate, and not defined otherwise.  Is it really the case
that no AIX release provides extern "C" markers?

zw

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Dale Johannesen]

On Friday, November 8, 2002, at 11:20  AM, Zack Weinberg wrote:

> On Fri, Nov 08, 2002 at 10:56:24AM -0500, David Edelsohn wrote:
>>>
>>> I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire 
>>> directory,
>>> in rs6000.h.  What few targets this is inappropriate for -- I'm
>>> willing to bet that's either none, or only AIX 3.1 -- can #undef it
>>> again.
>>>
>>> Comments?
>>
>> 	I could see placing this in sysv4.h, but not rs6000.h.  I do not
>> believe that GCC's fixincludes completely addresses the C++ issues in 
>> the
>> AIX header files.  IBM Visual Age C++ distributes its own system 
>> header
>> files.
>
> Defining or not defining NO_IMPLICIT_EXTERN_C addresses only one C++
> issue with system headers.  It should be defined by all targets where
> the system headers already wrap declarations in extern "C" { ... }
> when appropriate, and not defined otherwise.  Is it really the case
> that no AIX release provides extern "C" markers?

Darwin headers seem to provide extern "C", at least in the examples I
tried, although I'm not sure I understand what "when appropriate"
is exactly.  However, darwin.h doesn't currently define 
NO_IMPLICIT_EXTERN_C,
and I'm not aware of any problems with the way things work now
(it's possible the same altivec.h problem exists, though), so I'd
request that somebody at least try it on Darwin before changing it.

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Stan Shebs]

Dale Johannesen wrote:

>
> On Friday, November 8, 2002, at 11:20  AM, Zack Weinberg wrote:
>
>> On Fri, Nov 08, 2002 at 10:56:24AM -0500, David Edelsohn wrote:
>>
>>>>
>>>> I am inclined to enable NO_IMPLICIT_EXTERN_C for the entire directory,
>>>> in rs6000.h.  What few targets this is inappropriate for -- I'm
>>>> willing to bet that's either none, or only AIX 3.1 -- can #undef it
>>>> again.
>>>>
>>>> Comments?
>>>
>>>
>>>     I could see placing this in sysv4.h, but not rs6000.h.  I do not
>>> believe that GCC's fixincludes completely addresses the C++ issues 
>>> in the
>>> AIX header files.  IBM Visual Age C++ distributes its own system header
>>> files.
>>
>>
>> Defining or not defining NO_IMPLICIT_EXTERN_C addresses only one C++
>> issue with system headers.  It should be defined by all targets where
>> the system headers already wrap declarations in extern "C" { ... }
>> when appropriate, and not defined otherwise.  Is it really the case
>> that no AIX release provides extern "C" markers?
>
>
> Darwin headers seem to provide extern "C", at least in the examples I
> tried, although I'm not sure I understand what "when appropriate"
> is exactly.  However, darwin.h doesn't currently define 
> NO_IMPLICIT_EXTERN_C,
> and I'm not aware of any problems with the way things work now
> (it's possible the same altivec.h problem exists, though), so I'd
> request that somebody at least try it on Darwin before changing it.
>
Alas, many of the Mach headers are unprotected, even in 6.2, although
I believe that will be fixed in a future release.  So if it got defined in
rs6000.h, we'd have to undef in darwin.h.

Stan

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[Zack Weinberg]

On Fri, Nov 08, 2002 at 01:13:09PM -0800, Stan Shebs wrote:
> >>
> >>Defining or not defining NO_IMPLICIT_EXTERN_C addresses only one C++
> >>issue with system headers.  It should be defined by all targets where
> >>the system headers already wrap declarations in extern "C" { ... }
> >>when appropriate, and not defined otherwise.  Is it really the case
> >>that no AIX release provides extern "C" markers?
> >
> >
> >Darwin headers seem to provide extern "C", at least in the examples I
> >tried, although I'm not sure I understand what "when appropriate"
> >is exactly.  However, darwin.h doesn't currently define 
> >NO_IMPLICIT_EXTERN_C,
> >and I'm not aware of any problems with the way things work now
> >(it's possible the same altivec.h problem exists, though), so I'd
> >request that somebody at least try it on Darwin before changing it.
> >
> Alas, many of the Mach headers are unprotected, even in 6.2, although
> I believe that will be fixed in a future release.  So if it got defined in
> rs6000.h, we'd have to undef in darwin.h.

Okay, with you expressing concerns about Darwin and David expressing
concerns about AIX, it sounds like it's best to move the #define to
rs6000/sysv4.h instead.  That restricts the effect to the Hurd, Linux,
FreeBSD, NetBSD, plain SYSV, Chorus, eabi*, RTEMS, and VxWorks ports.

zw

Re: RS6000 buried treasure - NO_IMPLICIT_EXTERN_C

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> Defining or not defining NO_IMPLICIT_EXTERN_C addresses only one C++
Zack> issue with system headers.  It should be defined by all targets where
Zack> the system headers already wrap declarations in extern "C" { ... }
Zack> when appropriate, and not defined otherwise.  Is it really the case
Zack> that no AIX release provides extern "C" markers?

	AIX does provide extern "C", but there are C++ keyword conflicts
in the system headers.

David