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

[gccfeature at yahoo dot com]

>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