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?
On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote:> 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?I checked in a fix.
On Tue, May 12, 2009 at 6:26 PM, Dale Johannesen <dalej at apple.com> wrote:> > On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > >> 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? > > I checked in a fix.Also, IndVarSimplify.cpp has the same problem, only one abs usage in it, line 700: if (Max.getZExtValue() > static_cast<uint64_t>(abs(intEV - intIV))) Following your style change: if (Max.getZExtValue() > static_cast<uint64_t>(abs64(intEV - intIV))) Also, why make an abs64, why not just override abs with 64 bit parameters?