The more I think about this the more annoyed I am with gcc... as Ali says, if the optimization of eliminating the assert is potentially unsafe, then just don't do it. Maybe it's normally a warning to let you know that it could do the optimization if the type was unsigned, and -Werror is promoting it, but still it ought to be possible to turn the warning off.
Furthermore, I'm particularly annoyed because I think the whole issue is bogus: even if the types are unsigned, there's still a potential overflow issue, it just happens at a different point and it overflows to small positive values instead of negative values. So how does signedness really matter here? Why doesn't it warn about assuming you don't get unsigned overflow? Perhaps the cast to UTick is still the right answer, but we should be clear that we're working around gcc stupidity, and the fact that making Tick unsigned would avoid the need for this workaround is a coincidence and not further evidence that Tick really should be unsigned. Steve On Fri, Mar 25, 2011 at 2:58 PM, Korey Sewell <ksew...@umich.edu> wrote: >>> /** >>> * Clock cycle count type. >>> * @note using an unsigned breaks the cache. >>> */ >>> typedef int64_t Tick; >>> >>> though offhand I'm not sure why that's true. I just grepped through the >>> code and it looks like there are places where the code subtracts two tick >>> values and may expect the difference to be less than zero if the first one >>> is smaller than the second... that's probably at least part of it. >> >> I can't remember if I created UTick, but I think I did, and I'm pretty >> sure that I did it because I couldn't change the type of Tick. Do we >> care? > The safe thing to do is just use UTick in assertion "Tick" checks but > it seems like a Tick should be unsigned anyway and since we are going > to a Ruby memory system, then this time might be a good time to change > Tick officially to unsigned. > > However, if there is code that actually relies on Tick values being > negative then I would agree that the hassle is probably just too much > to go through some kind of big overhaul for. > > > > -- > - Korey > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
