C++ overload resolution of _Quad and complex _Quad types

[Andras_Pataki]

I'm having trouble using the 128-bit extended/quad precision floating point types in C++. It seems that the overload resolution is not distinguishing correctly between the real and the complex 128-bit types:


#include
#include

#define quad _Quad
#define cquad complex _Quad
// #define quad __float128
// #define cquad _Complex float __attribute__((mode(TC)))

void fff(double) { printf("Called fff(double)\\n"); }
void fff(complex double) { printf("Called fff(complex double)\\n"); }
void fff(quad) { printf("Called fff(quad)\\n"); }
void fff(cquad) { printf("Called fff(complex quad)\\n"); }

int main()
{
double v1 = 0.0;
complex double v2 = 0.0 + 0.0i;
quad v3 = 0.0q;
cquad v4 = 0.0q + 0.0qi;

fff(v1);
fff(v2);
fff(v3);
fff(v4);

return 0;
}


Compiling it with
$ icpc -Qoption,cpp,--extended_float_type -o test1 test1.cc

I get the output:
Called fff(double)
Called fff(complex double)
Called fff(quad)
Called fff(quad)

looking at the symbols:
$ nm test1 | grep fff
0000000000400a40 T _Z3fffCd
0000000000400a30 T _Z3fffd
0000000000400a20 T _Z3fffg

I see that while there are the two overloaded functions for double and complex double, there is only one funciton generated for quad, and the complex quad function is completely missing. It seems that both '_Quad' and 'complex _Quad' get mangled to the same name, so the linker eliminates the second one.

Running the same under gcc (with the other set of #define's uncommented for its quad type):
$ g++ -o test1 test1.cc

the output:
Called fff(double)
Called fff(complex double)
Called fff(quad)
Called fff(complex quad)

$ nm test1 | grep fff
00000000004005bd T _Z3fffCd
0000000000400604 T _Z3fffCg
00000000004005a4 T _Z3fffd
00000000004005eb T _Z3fffg

all the overloaded functions are accounted for.

I know that there is a C++ complex<> template that can be used, and that I am using the C99 complex type, the reason for not using it has to do with performance.

The compiler is the latest 64-bit icpc:
$ icpc -V
Intel C++ Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100414

Any ideas/help would be appreciated.

Thanks,

Andras

[Milind_Kulkarni__Int]

Hi Andras,

I have reproduced your issue with Intel compiler. However, for g++ 4.2.x , I get the same result & name-mangling as with Intel compiler. And with other like g++ 4.4 & 4.3.x, I cannot even compile, as those _Quad, and complex keywords are not recognized. May be I am doing something wrong.

However, I have escalated this issue to the developer team, and will let you know on this.
The bug record is:-- DPD200155329

Regards
Milind

[Andras_Pataki]

Hi Milind,

In the working gcc example, I am using g++ 4.4.3 on Fedora 12:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)

Yes, gcc has a different keyword for _Quad and complex _Quad, so you need to uncomment the other pair of #define's in the sample code (__float128 and that other somewhat confusing definition for the complex type).

Thanks very much for your help,

Andras

[Milind_Kulkarni__Int]

Hi Andras,

This issuehasbeenverified and fixed in the latest 12.0 compiler. Please verify.

[Andras_Pataki]

Yes, confirmed. The issue has been fixed and quad complex types now work well.

Thanks,

Andras