[chaboud]

I'd be more curious what Clang did for values that would result in different behaviors for some ranges of a. I understand that there are limits, and that there is range checking in literals for escalation to, for instance, 64-bit values, but it seems like an optimization that is:

A) fraught with edge-case peril

and

B) easily accounted for by the developer (e.g. write "a *= 10;")...

[gergo_barany]

> I'd be more curious what Clang did for values that would result in different behaviors for some ranges of a.

I don't think I understand what you mean. Can you give an example?

As for "the developer should write what they mean", one standard answer from compiler developers is along the lines of "but this code might not be hand-written, it might come from a primitive code generator". You can decide whether that convinces you or not ;-)

[chaboud]

Yeah. I'm partially unconvinced. That is to say that, if the compiler Dev wants to take on the completeness responsibility, cool. If not, I'm okay with that, too. Adding the optimization and screwing up the edge cases is the only way to end up on my bad side.

An example number might be 8388608.0 (or 2^23). Hell could have broken out more than four million integer values before that, but it's as nice a test as any (except maybe the exact edge).

There could also be interesting cases of compound arithmetic literal statements. And then, of course, there are other side-effect considerations (e.g. the x87 opcode register).

I'll stick to getting my literal types right in the first place, but, as stated above, it doesn't feel like a real miss to me. Either a dev or a code generator wrote ".0". I'm inclined to respect that to some degree.

Probably because I'm old.

I'll compile this in gcc and clang and see what shakes out. My bet is that clang does the right thing once the value is out of safe range.