¿Está permitida esta optimización de punto flotante?

Intenté comprobar dónde floatpierde la capacidad de representar exactamente números enteros grandes. Así que escribí este pequeño fragmento:

int main() {
    for (int i=0; ; i++) {
        if ((float)i!=i) {
            return i;
        }
    }
}

Este código parece funcionar con todos los compiladores, excepto clang. Clang genera un bucle infinito simple. Godbolt .

Esta permitido? Si es así, ¿es un problema de QoI?

Como señaló @Angew , el !=operador necesita el mismo tipo en ambos lados. (float)i != ida como resultado la promoción del RHS para que flote también, así que lo hemos hecho (float)i != (float)i.

g ++ también genera un bucle infinito, pero no optimiza el trabajo desde dentro. Puede ver que convierte int-> float con cvtsi2ssy se ucomiss xmm0,xmm0compara (float)iconsigo mismo. (Esa fue su primera pista de que su fuente de C ++ no significa lo que pensaba que hacía, como explica la respuesta de @ Angew).

x != xsolo es cierto cuando está "desordenado" porque xera NaN. (se INFINITYcompara a sí mismo en matemáticas IEEE, pero NaN no. NAN == NANes falso, NAN != NANes verdadero).

gcc7.4 y versiones anteriores optimizan correctamente su código jnpcomo la rama del bucle ( https://godbolt.org/z/fyOhW1 ): siga repitiendo mientras los operandos x != x no sean NaN. (gcc8 y versiones posteriores también verifican jeuna ruptura del bucle, sin optimizar en función del hecho de que siempre será cierto para cualquier entrada que no sea NaN). x86 FP compara set PF en desordenado.

Y por cierto, eso significa que la optimización de clang también es segura : solo tiene que CSE (float)i != (implicit conversion to float)icomo lo mismo, y demostrar que i -> floatnunca es NaN para el rango posible de int.

(Aunque dado que este bucle llegará a UB de desbordamiento firmado, se le permite emitir literalmente cualquier conjunto que desee, incluida una ud2instrucción ilegal, o un bucle infinito vacío independientemente de cuál sea el cuerpo del bucle en realidad). Pero ignorando el UB de desbordamiento firmado , esta optimización sigue siendo 100% legal.

GCC no puede optimizar el cuerpo del bucle incluso -fwrapvpara hacer que el desbordamiento de enteros con signo esté bien definido (como envoltura de complemento a 2). https://godbolt.org/z/t9A8t_

Incluso habilitar -fno-trapping-mathno ayuda. ( Desafortunadamente, el valor predeterminado de GCC es habilitar
-ftrapping-matha pesar de que la implementación de GCC está rota / con errores ). Int-> conversión flotante puede causar una excepción FP inexacta (para números demasiado grandes para ser representados exactamente), por lo que con excepciones posiblemente desenmascaradas, es razonable no hacerlo optimizar el cuerpo del lazo. (Porque la conversión 16777217a flotante podría tener un efecto secundario observable si se desenmascara la excepción inexacta).

Pero con -O3 -fwrapv -fno-trapping-math, es una optimización 100% perdida no compilar esto en un bucle infinito vacío. Sin #pragma STDC FENV_ACCESS ON, el estado de las banderas adhesivas que registran las excepciones de FP enmascaradas no es un efecto secundario observable del código. No int-> la floatconversión puede resultar en NaN, por x != xlo que no puede ser cierto.

Todos estos compiladores están optimizando para implementaciones de C ++ que usan IEEE 754 de precisión simple (binary32) floaty 32 bits int.

El bucle corregido(int)(float)i != i tendría UB en implementaciones de C ++ con 16 bits estrechos inty / o más anchos float, porque alcanzaría UB de desbordamiento de enteros con signo antes de llegar al primer entero que no era exactamente representable como float.

Pero UB bajo un conjunto diferente de opciones definidas por la implementación no tiene consecuencias negativas cuando se compila para una implementación como gcc o clang con el x86-64 System V ABI.

Por cierto, podría calcular estáticamente el resultado de este bucle desde FLT_RADIXy FLT_MANT_DIG, definido en <climits>. O al menos puede floathacerlo en teoría, si realmente se ajusta al modelo de un flotante IEEE en lugar de algún otro tipo de representación de números reales como Posit / unum.

No estoy seguro de cuánto define el estándar ISO C ++ sobre el floatcomportamiento y si un formato que no se basó en un exponente de ancho fijo y campos significativos sería compatible con los estándares.

En comentarios:

@geza ¡Me interesaría escuchar el número resultante!

@nada: es 16777216

¿Está afirmando que tiene este bucle para imprimir / devolver 16777216?

Actualización: dado que ese comentario ha sido eliminado, creo que no. Probablemente el OP solo esté citando floatantes del primer número entero que no se puede representar exactamente como un 32 bits float. https://en.wikipedia.org/wiki/Single-precision_floating-point_format#Precision_limits_on_integer_values, es decir, lo que esperaban verificar con este código defectuoso.

Por supuesto, la versión corregida se imprimirá 16777217, el primer número entero que no es exactamente representable, en lugar del valor anterior.

(Todos los valores flotantes más altos son números enteros exactos, pero son múltiplos de 2, luego 4, luego 8, etc. para valores de exponentes más altos que el ancho significativo. Se pueden representar muchos valores enteros más altos, pero 1 unidad en el último lugar (del significado) es mayor que 1, por lo que no son números enteros contiguos. El finito más grande floatestá justo por debajo de 2 ^ 128, que es demasiado grande para par int64_t).

Si algún compilador saliera del bucle original e imprimiera eso, sería un error del compilador.

Tenga en cuenta que el operador integrado !=requiere que sus operandos sean del mismo tipo y lo logrará utilizando promociones y conversiones si es necesario. En otras palabras, su condición es equivalente a:

(float)i != (float)i

Eso nunca debería fallar, por lo que el código eventualmente se desbordará i, dando a su programa un comportamiento indefinido. Por tanto, cualquier comportamiento es posible.

Para verificar correctamente lo que desea verificar, debe devolver el resultado a int:

if ((int)(float)i != i)