Why assert if the signs don't match? I would expect the operator== to simply return false if the signs don't match...
Why only accept 'int'? The APInt underlying system naturally would support int64_t. Why use isSameValue()? To be consistent with APInt's operators, you shouldn't support zero-extending. I would test for sign, handle than, and then explicitly delegate to APInt::operator== Then for operator!=, I would implement it directly in terms of negating operator==. I find the definition of APInt's operator== deeply troubling. Why *assert* if the bit widths aren't equal? That doesn't make a lot of sense to me. The function that it calls to actually implement it turns around and considers mismatched bitwdiths to cause *inequality*. However it seems that there is a very simple definition of equality we could use instead: zero-extended equality for APInt, and sign-extended equality for APSInt. I wonder if there would be general support for making APInt::operator== and APSInt::operator== work in this more rational model... On Tue, Jul 17, 2012 at 4:04 PM, Richard Trieu <[email protected]> wrote: > This patch adds missing operator== and operator!= to APSInt. Currently, > comparing two APSInt's will compare them with APInt's operator==, which > does not check signedness. This may lead to a problem where a large > unsigned APSInt will equal a negative APSInt, such as -1 and 0xffff. > > One patch is to LLVM to add the functions. The other is to fix up the > uses in Clang. > > _______________________________________________ > llvm-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
