[Fwd: Re: more on gcc 2.95 C++ problem (FIXED)]

[joel.sherrill at OARcorp.com (Joel Sherrill)]

-------- Original Message --------
Subject: Re: more on gcc 2.95 C++ problem (FIXED)
Date: Sat, 28 Aug 1999 15:01:19 +0200
From: Ralf Corsepius <corsepiu at faw.uni-ulm.de>
Reply-To: corsepiu at faw.uni-ulm.de
Organization: Ralf Corsepius
To: joel at oarcorp.com
CC: rtems-snapshots at oarcorp.com
References: <Pine.LNX.4.10.9908041540260.21996-200000 at oar3remote>

joel at oarcorp.com wrote:

> Hi,
>
> I have not investigated this much but have found a hint that may trip
> someone else into figuring this one out. :)
>
> If you take the preprocessed output of rtemsEvent.cc on the targets that
> fail and compile it by hand, you can reproduce the error.  Save this
> output in a new file.  Remove EVERY line that starts with a "#" and then
> it compiles without problems.  I can spot nothing wrong with the cpp
> output that would cause this but thought this might give someone else a
> hint who knew more C++.
>
> The sequence I have that reproduces this is in the attached file.  I did
> this on the m68k-rtemself/gen68360 configuration but many others have the
> same C++ problem.

I think, I have found the cause of our problems:

g++ -B<path>/ ...
invokes:
cpp --lang-c++ -isystem <path>/include ...

However, directories passed to cpp with -isystem, apparently may only contain
"C" headers (No C++ headers!!!) with gcc-2.95.X.

Proof:

The preprocessor output of the example I had posted previously in this thread
looks like this:

> # 1 "tmp.cc"
> # 1 "../lib/include/tmp.h" 1 3 4
> class rtemsTask
> {
> public:
>
>   virtual ~rtemsTask();
>
>
>   const rtemsTask& operator = (const rtemsTask& task);
> };
> # 1 "tmp.cc" 2
>
>

The revealing line is the second line above:
# 1 "../lib/include/tmp.h" 1 3 4

The "3" on this line means system-header, the "4" on this line means "C
header in C++" as this fragment from gcc-2.95.1/gcc/cccp.c, approx. at line
8280 clearly documents:


>  /* Tell cc1 if following text comes from a system header file.  */
>   if (ip->system_header_p) {
>     *line_end++ = ' ';
>     *line_end++ = '3';
>   }
> #ifndef NO_IMPLICIT_EXTERN_C
>   /* Tell cc1plus if following text should be treated as C.  */
>   if (ip->system_header_p == 2 && cplusplus) {
>     *line_end++ = ' ';
>     *line_end++ = '4';
>   }
> #endif
>

This means that a system include path passed with -isystem <path>/include,
therefore also -B<path>/,  *must not* contain any C++ code.

I.e. when compiling librtems++, the include files were interpreted as C files
and the compiler choked badly on them.


Obvious fixes coming into my mind are
1) Let's not use -B for c++ headers anymore, but use an arbitrary c++include
directory instead.
2) Add NO_IMPLICIT_EXTERN_C to all gcc/config/<target>/rtems.h headers.

The patch below tries to implement 2). Though this patch should fix this
problem for all RTEMS' targets, I have only tested it by building the
toolchain and rtems-19990820 for sh-rtems so far. Now librtems++ compiles
again ...

The patch is against gcc-2.95.1 with Joel's latest gcc-2.95.1 patch applied
(gcc-2.95.1-rtems-diff-19990820).

Ralf.

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-2.95.1-rtems-rc-19990828.diff.gz
Type: application/x-gzip
Size: 967 bytes
Desc: not available
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19990830/8b2a2464/attachment.gz