Closed Bug 824317 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: XPCOM, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: romaxa, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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
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.
looks like std::llabs also not available... only llabs from stdlib.h
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
Again, MFBT should sort out the issue somehow.
Depends on: 818809
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>.
Attached patch Can we fix it this way? (obsolete) — Splinter Review
Possible option
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.
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?
I think implementing mozilla::Abs makes sense here.  Sadface.
Can we just use NS_ABS? or copy NS_ABS impl into mozilla::Abs?
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.
I filed bug 835542 to add mozilla::Abs to MathAlgorithms.h, given comment 9 here and bug 818809 comment 1.
Depends on: 835542
Attached patch gcc 4.8 versionSplinter Review
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686

I'm still using the workaround on firefox20 and firefox21.
Attachment #695312 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.