This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: float to int conversion
- From: "Warlich, Christof" <christof dot warlich at siemens dot com>
- To: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Mon, 22 Apr 2013 11:44:58 +0000
- Subject: RE: float to int conversion
- References: <6D83E89737156549AEA25EF9ED712C5DD11B at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <5174F57B dot 4080701 at redhat dot com> <6D83E89737156549AEA25EF9ED712C5DD14A at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <20130422120325 dot 6168e915 at ketmar dot no-ip dot org> <6D83E89737156549AEA25EF9ED712C5DD1A0 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <517510BC dot 6020306 at redhat dot com>
Andrew Haley [aph@redhat.com] wrote:
> What do you think the conversion should do in this case? I find
> the current behaviour to be the least surprising.
Well, it should at least give consistent values regardless of
the level of optimization being used. I'm even having a more complex
C++ program that gives different values for each of the optimization
levels -O0, -O1 and -O2! I'd be really surprised if this doesn't
come to a surprise to anyone ;-).
To me (and the colleagues I've talked to), the "most expected" behaviour
would be:
any flaot equal to or bigger than the biggest integer -> biggest integer
any flaot equal to or smaller than the smallest integer -> smallest integer
This could even be driven further:
INF+ -> biggest integer
INF- -> smallest integer
and just to have one consistent definition for that:
QNAN -> 0
SNAN -> floating point exception
But imho, anything, even "undefined (but fixed)", would be better than
"varying depending on the level of optimization".