c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage

c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage

[gccfeature]

>Number:         7740
>Category:       c++
>Synopsis:       g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 27 14:26:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Charlie Kilpatrick
>Release:        GCC release 3.2
>Organization:
>Environment:
Linux (Redhat 7.2)

Reading specs from /usr/local/gnu/gcc32/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: /usr/local/gnu/src/gcc-3.2/configure --prefix=/usr/local/gnu/gcc32 --enable-threads=posix --enable-languages=c,c++
Thread model: posix
gcc version 3.2
>Description:
g++ version 3.2 compiles some routines marked as extern 
"C++" with incorrect "C" linkage.  

The following source code reliably demonstrates an example 
of the bug.  

In the sample code, we implement a custom sqrt() routine
and specify that the routine is to have C++ linkage.  We 
also implement another routine called other_name().  In 
this example, the compiler bug results in the sqrt() 
routine having incorrect C linkage in the resulting object
file; however, the other_name() routine is compiled with 
correct C++ linkage.

For example:

// --- test.C ---
extern "C++" {
    double sqrt (double x) { return 10.0; }
    double other_name (double x) { return 10.0; }
}
// --- end ---

To demonstrate the bug, one can place the above code in a 
file named test.C, and then compile and view the resulting 
object file's symbols:

[ using g++ version 3.2 ]
% g++ -Wall -c test.C -o test.o
% nm test.o
0000001a T _Z10other_named
00000000 T sqrt

The above output of the nm program indicates that the sqrt()
routine was incorrectly given C linkage.  In contrast, the
other_name() routine was correctly given C++ linkage.  

However, if we use g++ version 3.0.4 to compile the source 
code, we get the following correct results:

[ using g++ version 3.0.4 ]
% g++ -Wall -c test.C -o test.o
% nm test.o
0000001c T _Z10other_named
00000000 T _Z4sqrtd

Notice that in our sample program, we do not include the
math.h system header file, and so when the source code file
is compiled, the compiler faces no confusion about 
conflicting sqrt() declarations.  However, if we implement 
an extern "C++" routine with almost any other name, then the
compiler will give it the correct C++ linkage in the 
resulting object file.  It appears to be the case that other
math functions like cos(), sin(), and tan() also demonstrate
this bug.

This bug appears in g++ version 3.2 and g++ version 3.1.1.
It is also present in the current CVS development version
of g++ (as of Aug. 27, 2002).  This bug is not present in 
gcc version 3.0.4.  

It is critical for our application that g++ correctly 
compile our custom sqrt() routine with C++ linkage.
>How-To-Repeat:
See the above description for details.  Compile the 
attached test.C file:

[ using g++ version 3.2 ]
% g++ -Wall -c test.C -o test.o
% nm test.o
0000001a T _Z10other_named
00000000 T sqrt

The output of nm indicates that the sqrt() routine, which
we marked as being an extern "C++" routine, was instead 
compiled with incorrect C linkage by g++ version 3.2.

For completeness, the .ii file generated by g++ version 3.2
is included below:

// --- test.ii ---
# 1 "test.C"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "test.C"
# 30 "test.C"
extern "C++" {
    double sqrt (double x) { return 10.0; }
    double other_name (double x) { return 10.0; }
}
// --- end ---

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test.C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.C"

LyoKCiBDb21waWxlIHRoaXMgZmlsZSB3aXRoIGdjYyB2ZXJzaW9uIDMuMiBvciB2ZXJzaW9uIDMu
MS4xIG9uIGxpbnV4OgogCiAlIGcrKyAtV2FsbCAtYyB0ZXN0LkMgLW8gdGVzdC5vCiAKIFRoZW4g
cnVuICdubSB0ZXN0Lm8nLiAgTm90aWNlIHRoYXQgdGhlIG91dHB1dCBvZiBubSBpbmRpY2F0ZXMg
dGhhdAogdGhlIG90aGVyX25hbWUoKSByb3V0aW5lIGhhcyBDKysgbGlua2FnZSwgd2hpbGUgdGhl
IHNxcnQoKSByb3V0aW5lIAogaGFzIChpbmNvcnJlY3QpIEMgbGlua2FnZToKICAgICAgIAogJSBu
bSB0ZXN0Lm8KCiAwMDAwMDAwMCBXIF9aMTBvdGhlcl9uYW1lZAogMDAwMDAwMDAgVyBzcXJ0Cgog
VGhlIHNxcnQoKSBmdW5jdGlvbiBzaG91bGQgaGF2ZSBDKysgbGlua2FnZSwgYXMgaXMgc3BlY2lm
aWVkIGJlbG93IAogaW4gdGhpcyBmaWxlLgoKIEhvd2V2ZXIsIGlmIHlvdSBjb21waWxlIHRoaXMg
ZmlsZSB3aXRoIGdjYyB2ZXJzaW9uIDMuMC40IGFuZCBhZ2FpbgogcnVuICdubSB0ZXN0Lm8nIG9u
IHRoZSBvYmplY3QgZmlsZSwgdGhlbiBib3RoIHJvdXRpbmVzIGhhdmUgdGhlIAogY29ycmVjdCBD
KysgbGlua2FnZToKCiAlIG5tIHRlc3QubwoKIDAwMDAwMDAwIFcgX1oxMG90aGVyX25hbWVkCiAw
MDAwMDAwMCBXIF9aNHNxcnRkCgoqLwoKZXh0ZXJuICJDKysiIHsKICAgIGRvdWJsZSBzcXJ0IChk
b3VibGUgeCkgeyByZXR1cm4gMTAuMDsgfQogICAgZG91YmxlIG90aGVyX25hbWUgKGRvdWJsZSB4
KSB7IHJldHVybiAxMC4wOyB9Cn0K

Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage

[Andrew Pinski]

The following reply was made to PR c++/7740; it has been noted by GNATS.

From: Andrew Pinski <pinskia@physics.uc.edu>
To: Charlie Kilpatrick <charliek@ilm.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with  incorrect "C" linkage
Date: Wed, 28 Aug 2002 21:34:18 -0400

 Look at why gcc does this, people are trying to interrupt the standard:
 http://gcc.gnu.org/ml/libstdc++/2002-03/msg00433.html
 
 It looks like to a hard battle the should be also brought attention to 
 the newsgroup: comp.lang.c++.std
 (I think that is the newsgroup).
 
 Thanks,
 Andrew Pinski
 

Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage

[Charlie Kilpatrick]

The following reply was made to PR c++/7740; it has been noted by GNATS.

From: Charlie Kilpatrick <charliek@ilm.com>
To: gcc-gnats@gcc.gnu.org, Andrew Pinski <pinskia@physics.uc.edu>
Cc:  
Subject: Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with 
 incorrect "C" linkage
Date: Wed, 28 Aug 2002 17:45:25 -0700

 Hi Andrew, 
 
 I don't follow your line of reasoning.  The bug I am writing about
 concerns whether g++ compiles the sqrt() routine with C or C++ linkage. 
 Which namespace the sqrt routine is placed in within the math.h and
 cmath header files is not relevant to this bug report.  
 
 In particular, my test file does not include any header files. 
 Certainly you aren't you claiming that a C++ compiler should have
 built-in knowledge of particular math routines even if no header files
 are included?  
 
 Since reporting this bug, I have discovered that it is not just math
 routines that exhibit this bug.  For example, g++ version 3.2 will give
 the alloca(), strcpy(), strncpy(), and memcpy() routines C linkage no
 matter what.  However, it will give the memmove() routine C++ linkage. 
 On the other hand, g++ version 3.0.4 does not suffer from this bug.  If
 no header files are included, and one specifies C++ linkage for a
 routine, g++ version 3.0.4 correctly gives it C++ linkage in the object
 file.
 
 Here is a slightly longer source code file that demonstrates this
 behavior.
 
 // --- test2.C ---
 typedef unsigned int size_t;
 
 extern "C++" {
     void* alloca( size_t size) { return 0; }
     char* strcpy(char *dest, const char *src) { return 0; }
     char* strncpy(char *dest, const char *src, size_t n) { return 0; }
     void* memmove(void *dest, const void *src, size_t n) { return 0; }
     void* memcpy(void *dest, const void *src, size_t n) { return 0; }
     double sqrt (double x) { return 10.0; }
     double other_name (double x) { return 10.0; }
 }
 // --- end ---
 
 [ using g++ version 3.2 ]
 % g++ -Wall -c test2.C -o test2.o
 % nm test2.o
 0000004c T _Z10other_named
 0000001e T _Z7memmovePvPKvj
 00000000 T alloca
 00000028 T memcpy
 00000032 T sqrt
 0000000a T strcpy
 00000014 T strncpy
 
 Can you explain to me why the memmove() routine is correctly given C++
 linkage by g++ version 3.2, but it incorrectly gives the memcpy()
 routine C linkage?  Observe that I am not including <string.h> in the
 test2.C source code file.  Would you claim that a C++ compiler should
 have built-in knowledge of the memcpy() routine, but not the memmove()
 routine?  What about other routines in the standard library? 
 
 However, g++ version 3.0.4 gives the correct results.  These results
 indicate that this bug is a regression in g++ version 3.2 and version
 3.1.1 as originally stated.
 
 [ using g++ version 3.0.4 ]
 % g++ -Wall -c test2.C -o test2.o
 % nm test2.o
 00000058 T _Z10other_named
 0000003c T _Z4sqrtd
 00000000 T _Z6allocaj
 00000030 T _Z6memcpyPvPKvj
 0000000c T _Z6strcpyPcPKc
 00000024 T _Z7memmovePvPKvj
 00000018 T _Z7strncpyPcPKcj

Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage

[Andrew Pinski]

The following reply was made to PR c++/7740; it has been noted by GNATS.

From: Andrew Pinski <pinskia@physics.uc.edu>
To: gccfeature@yahoo.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/7740: g++ 3.2 compiles routines marked as extern "C++" with incorrect "C" linkage
Date: Tue, 27 Aug 2002 17:32:09 -0400

 I do not think this is a bug with 3.2 or 3.1.1 but was a bug with gcc 
 3.0.x and below,
 I think it is required that sqrt to be in the std namespace and the 
 anonymous namespace.
 
 Thanks,
 Andrew Pinski