824317 - call of overloaded 'abs(int64_t&)' is ambiguous

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Oleg Romashin (:romaxa)]

Cannot compile gecko on Harmattan platform due to error in xpcom:

c++ -o nsMultiplexInputStream.o -c  -fvisibility=hidden -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -DEXCLUDE_SKIA_DEPENDENCIES  -DOS_POSIX=1 -DOS_LINUX=1  -D_IMPL_NS_COM -Iipc/chromium/src -Iipc/glue -I../../ipc/ipdl/_ipdlheaders  -I.. -Ixpcom/io -I. -I../../dist/include  -Iobj-build-n9-qt-dbg/dist/include/nspr -Iobj-build-n9-qt-dbg/dist/include/nss      -fPIC  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -fno-exceptions -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DDEBUG -D_DEBUG -DTRACING -gdwarf-2 -Os -freorder-blocks  -fno-strict-aliasing -fno-omit-frame-pointer    -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsMultiplexInputStream.o.pp  xpcom/io/nsMultiplexInputStream.cpp
xpcom/io/nsMultiplexInputStream.cpp: In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32_t, int64_t)':
xpcom/io/nsMultiplexInputStream.cpp:514: error: call of overloaded 'abs(int64_t&)' is ambiguous
/usr/include/stdlib.h:720: note: candidates are: int abs(int)
/usr/include/c++/4.4/cstdlib:139: note:                 long int std::abs(long int)
/usr/include/c++/4.4/cmath:94: note:                 double std::abs(double)
/usr/include/c++/4.4/cmath:98: note:                 float std::abs(float)
/usr/include/c++/4.4/cmath:102: note:                 long double std::abs(long double)

gcc version 4.4.1 ('cs2009q3-hard-67-sb16') 
libstdc++6-4.4-dev

Comment 1

[Jeff Walden [:Waldo]]

Sounds like std::llabs is probably what's wanted here.  It's a pity all the abs functions are specified on natural types, and not on <stdint.h> types, as it means calling one on a non-natural presents something of a minefield concerning exactly what underlying type's used.

Comment 2

[Oleg Romashin (:romaxa)]

looks like std::llabs also not available... only llabs from stdlib.h

Comment 3

[Masatoshi Kimura [:emk]]

FYI nsAlgorithm.h defines a long long version of std::abs shim for MSVC9.
https://mxr.mozilla.org/mozilla-central/source/xpcom/string/public/nsAlgorithm.h?rev=16037c152c36#45

Comment 4

[Masatoshi Kimura [:emk]]

Again, MFBT should sort out the issue somehow.

Comment 5

[Mats Palmgren (inactive)]

I would prefer a shim so that we can continue using std::abs everywhere.
An alternative to the MFBT way would be to add that shim to our wrapped <cstdlib>.

Comment 6

[Oleg Romashin (:romaxa)]

Attachment: Can we fix it this way?

Possible option

Comment 7

[Jan Beich]

I have somewhat similar error on FreeBSD i386.

g++47 -o nsMultiplexInputStream.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include ../../../config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -DEXCLUDE_SKIA_DEPENDENCIES  -DOS_POSIX=1 -DOS_FREEBSD=1 -DOS_BSD=1  -D_IMPL_NS_COM -I../../../ipc/chromium/src -I../../../ipc/glue -I../../ipc/ipdl/_ipdlheaders  -I.. -I../../../xpcom/io -I. -I../../dist/include  -I/usr/local/include/nspr -Iobj-i386-portbld-freebsd8.3/dist/include/nss -fPIC -isystem/usr/local/include -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -O2 -pipe -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pipe  -DNDEBUG -DTRIMMED -fno-omit-frame-pointer -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsMultiplexInputStream.o.pp  xpcom/io/nsMultiplexInputStream.cpp
xpcom/io/nsMultiplexInputStream.cpp: In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32_t, int64_t)':
xpcom/io/nsMultiplexInputStream.cpp:532:83: error: no matching function for call to 'NS_MIN(int64_t&, __gnu_cxx::__enable_if<true, double>::__type)'
xpcom/io/nsMultiplexInputStream.cpp:532:83: note: candidate is:
In file included from ../../dist/include/nsTArray.h:17:0,
                 from ../../dist/include/nsCOMArray.h:12,
                 from xpcom/io/nsMultiplexInputStream.cpp:18:
../../dist/include/nsAlgorithm.h:31:1: note: template<class T> const T& NS_MIN(const T&, const T&)
../../dist/include/nsAlgorithm.h:31:1: note:   template argument deduction/substitution failed:
xpcom/io/nsMultiplexInputStream.cpp:532:83: note:   deduced conflicting types for parameter 'const T' ('long long int' and '__gnu_cxx::__enable_if<true, double>::__type {aka double}')
xpcom/io/nsMultiplexInputStream.cpp: At global scope:
xpcom/io/nsMultiplexInputStream.cpp:93:1: warning: 'bool SeekableStreamAtBeginning(nsIInputStream*)' defined but not used [-Wunused-function]
gmake[4]: *** [nsMultiplexInputStream.o] Error 1
gmake[4]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory `obj-i386-portbld-freebsd8.3/xpcom/io'
gmake[3]: *** [libs] Error 2

With clang/libstdc++ the output is a bit different

xpcom/io/nsMultiplexInputStream.cpp:514:17: error:
      call to 'abs' is ambiguous
            if (std::abs(remaining) < streamPos) {
                ^~~~~~~~
/usr/include/stdlib.h:83:6: note: candidate function
int      abs(int) __pure2;
         ^
/usr/include/c++/4.2/cstdlib:142:3: note: candidate function
  abs(long __i) { return labs(__i); }
  ^
/usr/include/c++/4.2/cmath:88:3: note: candidate function
  abs(double __x)
  ^
/usr/include/c++/4.2/cmath:92:3: note: candidate function
  abs(float __x)
  ^
/usr/include/c++/4.2/cmath:96:3: note: candidate function
  abs(long double __x)
  ^
xpcom/io/nsMultiplexInputStream.cpp:522:24: error:
      call to 'abs' is ambiguous
            } else if (std::abs(remaining) > streamPos) {
                       ^~~~~~~~
/usr/include/stdlib.h:83:6: note: candidate function
int      abs(int) __pure2;
         ^
/usr/include/c++/4.2/cstdlib:142:3: note: candidate function
  abs(long __i) { return labs(__i); }
  ^
/usr/include/c++/4.2/cmath:88:3: note: candidate function
  abs(double __x)
  ^
/usr/include/c++/4.2/cmath:92:3: note: candidate function
  abs(float __x)
  ^
/usr/include/c++/4.2/cmath:96:3: note: candidate function
  abs(long double __x)
  ^
xpcom/io/nsMultiplexInputStream.cpp:532:64: error:
      call to 'abs' is ambiguous
                    int64_t newPos = streamPos + NS_MIN(avail, std::abs(remaining));
                                                               ^~~~~~~~
/usr/include/stdlib.h:83:6: note: candidate function
int      abs(int) __pure2;
         ^
/usr/include/c++/4.2/cstdlib:142:3: note: candidate function
  abs(long __i) { return labs(__i); }
  ^
/usr/include/c++/4.2/cmath:88:3: note: candidate function
  abs(double __x)
  ^
/usr/include/c++/4.2/cmath:92:3: note: candidate function
  abs(float __x)
  ^
/usr/include/c++/4.2/cmath:96:3: note: candidate function
  abs(long double __x)
  ^
3 errors generated.

FWIW, clang/libc++ case isn't affected by the bug.

Comment 8

[Jeff Walden [:Waldo]]

The problem is this isn't really a bug in gcc, or clang, or MSVC, or any compiler -- int64_t may validly be either long or long long, and the difference determines whether std::abs or std::llabs should be used.  It's just different compilers choosing different defaults in ways we stumble over.

A part of me thinks we should have mozilla::Abs with overloads for all the different fixed-size types, and maybe for the natural types, and use that everywhere, and std::abs nowhere, because std::abs is broken when used on anything other than natural types (or typedefs that map to known, fixed natural types -- which is not <stdint.h> types because those are outside our control, and do vary across platforms).  I'd obviously rather not reinvent something standard, but when the standard thing is broken, ya gotta do what ya gotta do.  Maybe.  Anyone else (CCing everyone on the NS_ABS bug) have thoughts here?

Comment 9

[(no longer active)]

I think implementing mozilla::Abs makes sense here.  Sadface.

Comment 10

[Oleg Romashin (:romaxa)]

Can we just use NS_ABS? or copy NS_ABS impl into mozilla::Abs?

Comment 11

[Mats Palmgren (inactive)]

I prefer the fix suggested in Oleg's patch -- i.e. that we continue
to define std::abs(long long) on platforms that need it.  It's a kludge
but it allows us to use the more readable std::abs everywhere.

We should put it in a mfbt header though, as bug 818809 suggests.

Comment 12

[Jeff Walden [:Waldo]]

I filed bug 835542 to add mozilla::Abs to MathAlgorithms.h, given comment 9 here and bug 818809 comment 1.

Comment 13

[Jan Beich]

Attachment: gcc 4.8 version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686

I'm still using the workaround on firefox20 and firefox21.

Comment 14

[Jeff Walden [:Waldo]]

With bug 835542 fixed, mozilla::Abs stands ready to fix all these cases.

There are only a couple hits for std::abs in the tree any more (added after I converted everything to mozilla::Abs [now mozilla::DeprecatedAbs], but before I blogged about mozilla::Abs existing).  Those are for int32_t via fields of nsPoint, and for LONG via TS_SELECTION_ACP, so I think we could remove the hacked-in std::abs specializations in our tree now.  I might file the bug to do that sometime, when I have a spare moment to do so.