Godot: Vector.length() of some tiny numbers results in -inf when compiled with Clang

[retrotails]

Godot version:
3.0.rc3.custom_build.a98e949
OS/device including version:
Arch Linux
Issue description:

example below is wrong, above pic shows more like what I experienced.
print((Vector2(.1, .1)/(10^10000000000000000000)).length())
this prints "-inf". Vector3() will also produce -inf.
that tiny vector, after division, prints as "(-0, -0)"
strangely, Vector2(1,1)/(10^...).length() will return the expected 0, as will writing .00000000000000000001.
this does not appear to happen in godot 2.1.4-2, though I can only get it working in this version with some tiny numbers, it seems like the way the number is written makes a difference which probably comes down to floating point weirdness.
I feel like this probably isn't limited to .length(), though I can't find any other examples, so this is as far as I can reduce it.
I noticed this because I have some easing code that goes exponentially towards 0, so it makes some really tiny numbers after a few seconds.

[Omicron666]

I am not sure how there is anything or any bug to be fixed here, you are computing operations with invalid numbers.
10^10000000000000000000 is not a valid integer number in first place, in a range that can be handled by C++ see http://docs.godotengine.org/en/stable/development/cpp/core_types.html#definitions for available integer types in Godot : 64 bits maximum.
To store this number as integer you would need log(10^10000000000000000000)/log(2)+1 ≈ 33,219,280,948,873,630,000 bits integer type !
You might like to try using 10.^10000000000000000000 as float, though.

[Ace-Dragon]

It might be better to just cut off the ease function when it reaches a certain value (eventually, you'll get numbers that are too small to create any visual or logic impact in a game).

The only time one would care about an exponentially tiny number is if the person was a scientist or was writing an app. for academic purposes or was wanting to do some hyper-accurate simulation.

[Zylann]

Isn't ^ the XOR binary operator?

[retrotails]

@Zylann shit, that's correct. updated my main comment with a better example. It's actually the same problem since that's just a huge number, it's just not the one you'd expect.
@Ace-Dragon I see what you mean and I have fixed it in my code, but it sure took a while to debug why my character disappeared off the screen when I stopped moving the joystick for 5 seconds. I imported my script from a godot 2 project, where this problem doesn't happen.

[Omicron666]

Have you run exact same code in 2.1.4-2 ?
Checking length() definition

real_t Vector2::length() const {

    return Math::sqrt(x * x + y * y);
}

At your first -inf output, 19th value, x must equal 10^-20.
During computation you have x*x that is 10^-40.
According to http://www.cplusplus.com/reference/cfloat/
Minimum negative integer value for the exponent of a base-10 expression that would generate a normalized floating-point number is -37, exactly where your example starts bugging.

[retrotails]

@Omicron666
I have tested it in 2.1.4-2, and after a hundred or so iterations it looks as I'd expect.

[bojidar-bg]

Can't confirm on 3.0.2, 3.0.5, or 9eb082004d9d6f9003ca5c0c64e3d5b10b210e60 (old master). Arch linux, 64 bit.

[Chaosus]

_I cannot confirm it too, feel free to create a new issue or reopen this one if its still happened. Closed by bugsquad._

[retrotails]

I don't know if I can reopen this, or whether it should be reopened, but I think I found the problem, and it's when godot is compiled with clang. godot-git on the arch user repository uses the following:
scons platform=x11 target=release_debug CXX=clang++ -j(nproc)
when I compile myself from source using those arguments, I get the -inf problem. when I use GCC, which I guess is default with:
scons platform=x11 target=release_debug
the problem goes away.

[Chaosus]

Than it should be reopened.

[reduz]

This is weird, it should never become inf. Something is odd here. Can you give it a check, @hpvb ? it may be a compiler bug.

[akien-mga]

Can you still reproduce this in the current master branch? -ffast-math was causing various issues and was removed in #24855, that might have fixed this.

[retrotails]

Can you still reproduce this in the current master branch? -ffast-math was causing various issues and was removed in #24855, that might have fixed this.

that seems to have fixed it. I wonder if it's technically a clang bug still, or if that sort of behavior is acceptable with those optimizations.