Bug 9396 - [3.4 regression] ambiguities with abs()
Summary: [3.4 regression] ambiguities with abs()
Status: RESOLVED DUPLICATE of bug 11409
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 3.4.0
: P3 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
Keywords: rejects-valid
Depends on:
Reported: 2003-01-22 04:56 UTC by snyder
Modified: 2004-01-17 04:22 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2003-06-07 15:48:01


Note You need to log in before you can comment on or make changes to this bug.
Description snyder 2003-01-22 04:56:00 UTC
When compiling the source below, g++ 3.4 gives the errors:

$ g++ -c  x.cc 
x.cc: In function `double foo(double)':
x.cc:8: error: call of overloaded `abs(double&)' is ambiguous
/usr/include/stdlib.h:699: error: candidates are: int abs(int)
/usr/local/gcc/include/c++/3.4/cstdlib:142: error:                 long long 
   int __gnu_cxx::abs(long long int)

The error goes away if i reverse the order of the two includes
(putting cstdlib before cmath) or if i explicitly qualify the abs()
call with std::.

This source compiles without error with g++ 3.1.

3.4 20030121 (experimental)

System: Linux karma 2.4.19-emp_2419p5a829i #1 Tue Sep 3 17:42:17 EST 2002 i686 unknown
Architecture: i686

	<machine, os, target, libraries (multiple lines)>
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc/configure --prefix=/usr/local/gcc --enable-threads=posix --enable-long-long

#include <cmath>
#include <cstdlib>

using std::abs;

double foo (double x)
  return abs (x);

Comment 1 snyder 2003-01-22 04:56:00 UTC
	<how to correct or work around the problem, if known (multiple lines)>
Comment 2 Wolfgang Bangerth 2003-01-22 16:47:30 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. The reason is that until 3.3, the overload
      std::fabs (double)
    was chosen, which is an exact match (one can see that it
    was chosen by looking at the output of the compiler with
    nm -C). Somehow this overload must have vanished from
    the list of overloads considered.
Comment 3 Andrew Pinski 2003-06-07 15:48:01 UTC
This still happens on the mainline (20030607).
Comment 4 Andrew Pinski 2003-07-06 02:08:44 UTC
Same bug as PR 11409 which has more analysis.

*** This bug has been marked as a duplicate of 11409 ***