The error given:
..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) :
error C2668: 'abs' : ambiguous call to overloaded function
f:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(539): could be 'long double abs(long double)'
f:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(491): or 'float abs(float)'
f:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(487): or 'double abs(double)'
f:\Program Files\Microsoft Visual Studio
8\VC\include\math.h(485): or 'long abs(long)'
f:\Program Files\Microsoft Visual Studio
8\VC\include\stdlib.h(415): or 'int abs(int)'
while trying to match the argument list '(int64_t)'
It should be rather obvious from the message. The error is in
LoopStrengthReduce.cpp on line 1016:
(unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0))
>From looking at the code and what it looks like it should be doing, I
cannot really tell whether it should use the 32-bit override, or if it
should use something like the long double override, considering this
is a 64-bit integer.
Either way, will not compile until a specific type override is given
of the form (just an example, I do not know if the 32-bit version is
what is wanted here):
(unsigned(abs((int)SInt)) < SSInt || (SInt % SSInt) != 0))
On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote:> The error given: > > ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : > error C2668: 'abs' : ambiguous call to overloaded function > > It should be rather obvious from the message. The error is in > LoopStrengthReduce.cpp on line 1016: > (unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) > >> From looking at the code and what it looks like it should be doing, I > cannot really tell whether it should use the 32-bit override, or if it > should use something like the long double override, considering this > is a 64-bit integer.It should be a 64-bit integer abs, although gcc seems to be generating code for 32-bit integer (which, in this code, would give the expected answer in any reasonable example). There are 4 occurrences of this usage in that file (with 3 different authors) so I think we need to write one; apparently nobody realized there wasn't one in the standard libraries (I didn't either).> Either way, will not compile until a specific type override is given > of the form (just an example, I do not know if the 32-bit version is > what is wanted here): > (unsigned(abs((int)SInt)) < SSInt || (SInt % SSInt) != 0)) > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> wrote:> > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the message. The error is in >> LoopStrengthReduce.cpp on line 1016: >> (unsigned(abs(SInt)) < SSInt || (SInt % SSInt) != 0)) >> >>> From looking at the code and what it looks like it should be doing, I >> cannot really tell whether it should use the 32-bit override, or if it >> should use something like the long double override, considering this >> is a 64-bit integer. > > It should be a 64-bit integer abs, although gcc seems to be generating > code for 32-bit integer (which, in this code, would give the expected > answer in any reasonable example). There are 4 occurrences of this > usage in that file (with 3 different authors) so I think we need to > write one; apparently nobody realized there wasn't one in the standard > libraries (I didn't either).Ah, I mentioned it before, but was told that the error was not appearing with GCC and they were busy at the time, so I just have been inserting an (int) in my version ever since, but it reappeared when I synced back to trunk today since I deleted my version, and I have just been reporting random things I have been crossing. I noticed a few other warnings about struct/class forward declarations as well, but did not catch them in time, I intend to look through it closely later and report more. So, for now, just keep using (int) in my version until it is fixed in trunk?