gcc, alias estrictos e historias de terror

SWIG genera código que depende de que el alias estricto esté desactivado, lo que puede causar todo tipo de problemas.

SWIGEXPORT jlong JNICALL Java_com_mylibJNI_make_1mystruct_1_1SWIG_12(
       JNIEnv *jenv, jclass jcls, jint jarg1, jint jarg2) {
  jlong jresult = 0 ;
  int arg1 ;
  int arg2 ;
  my_struct_t *result = 0 ;

  (void)jenv;
  (void)jcls;
  arg1 = (int)jarg1; 
  arg2 = (int)jarg2; 
  result = (my_struct_t *)make_my_struct(arg1,arg2);
  *(my_struct_t **)&jresult = result;              /* <<<< horror*/
  return jresult;
}

Gcc, aliasing y arrays de longitud variable 2-D: El siguiente código de ejemplo copia una matriz 2x2:

#include <stdio.h>

static void copy(int n, int a[][n], int b[][n]) {
   int i, j;
   for (i = 0; i < 2; i++)    // 'n' not used in this example
      for (j = 0; j < 2; j++) // 'n' hard-coded to 2 for simplicity
         b[i][j] = a[i][j];
}

int main(int argc, char *argv[]) {
   int a[2][2] = {{1, 2},{3, 4}};
   int b[2][2];
   copy(2, a, b);    
   printf("%d %d %d %d\n", b[0][0], b[0][1], b[1][0], b[1][1]);
   return 0;
}

Con ccg 4.1.2 en CentOS, obtengo:

$ gcc -O1 test.c && a.out
1 2 3 4
$ gcc -O2 test.c && a.out
10235717 -1075970308 -1075970456 11452404 (random)

No se si esto es generalmente conocido, y no se si esto es un error o una característica. No puedo duplicar el problema con gcc 4.3.4 en Cygwin, por lo que puede haber sido arreglado. Algunas soluciones:

• Use __attribute__((noinline)) para copy().
• Utilice el conmutador gcc -fno-strict-aliasing.
• Cambia el tercer parámetro de copy() de b[][n] a b[][2].
• No use -O2 o -O3.

Notas adicionales:

• Esta es una respuesta, después de un año y un día, a mi propia pregunta (y estoy un poco sorprendido de que solo haya otras dos respuestas).
• Perdí varias horas con esto en mi código real, un filtro Kalman. Cambios aparentemente pequeños tendrían efectos drásticos, tal vez debido al cambio de inserción automática de gcc (esto es una suposición; estoy todavía incierto). Pero probablemente no califica como una historia de terror .
• Sí, sé que no escribirías copy() así. (Y, como un aparte, me sorprendió un poco ver que gcc no desenrolló el doble bucle.)
• No hay interruptores de advertencia gcc, incluir -Wstrict-aliasing=, hizo nada aquí.
• Los arrays de longitud variable 1-D parecen estar bien.

Actualizar: Lo anterior no responde realmente a la pregunta del OP, ya que él (i. e.) estaba preguntando sobre casos en los que el aliasing estricto' legítimamente ' rompió su código, mientras que lo anterior parece ser un error de compilador de variedad de jardín.

Lo informé a GCC Bugzilla, pero no estaban interesados en el viejo 4.1.2, a pesar de que (creo) es la clave para el RHEL5 de 1 1 mil millones. No ocurre en 4.2.4 arriba.

Y tengo un ejemplo un poco más simple de un error similar, con una sola matriz. El código:

static void zero(int n, int a[][n]) {
   int i, j;
   for (i = 0; i < n; i++)
   for (j = 0; j < n; j++)
      a[i][j] = 0;
}

int main(void) {
   int a[2][2] = {{1, 2},{3, 4}};
   zero(2, a);    
   printf("%d\n", a[1][1]);
   return 0;
}

Produce los resultados:

gcc -O1 test.c && a.out
0
gcc -O1 -fstrict-aliasing test.c && a.out
4

Parece que es la combinación -fstrict-aliasing con -finline que causa el error.

El siguiente código devuelve 10, bajo gcc 4.4.4. Nada malo con la unión método o gcc 4.4.4?

int main()
{
  int v = 10;

  union vv {
    int v;
    short q;
  } *s = (union vv *)&v;

  s->v = 1;

  return v;
}

Aquí está el mío:

Http://forum.openscad.org/CGAL-3-6-1-causing-errors-but-CGAL-3-6-0-OK-tt2050.html

Causó que ciertas formas en un programa CAD se dibujaran incorrectamente. gracias a Dios por el trabajo de los líderes del proyecto en la creación de un conjunto de pruebas de regresión.

El error solo se manifestó en ciertas plataformas, con versiones anteriores de GCC y versiones anteriores de ciertas bibliotecas. y luego solo con-O2 activado. -fno-estricto-aliasing lo resolvió.

La regla de Secuencia Inicial Común de C solía interpretarse como que lo hace posible escribir una función que podría trabajar en la porción principal de a amplia variedad de tipos de estructura, siempre que comiencen con elementos de coincidencia tipo. Bajo C99, la regla se modificó para que solo se aplicara si la estructura los tipos involucrados eran miembros de la misma unión cuya declaración completa era visible en el punto de uso.

Los autores del ccg insisten en que el idioma en cuestión solo es aplicable si los accesos se realizan a través del tipo unión, sin perjuicio de los hechos que:

1. No habría ninguna razón para especificar que la declaración completa debe ser visible si los accesos tuvieran que realizarse a través del tipo de unión.

2. Aunque la regla de la CEI se describió en términos de sindicatos, su principal la utilidad radica en lo que implica sobre la forma en que las estructuras diseñado y accedido. Si S1 y S2 fueran estructuras que compartieran a CEI, no habría manera de que una función que acepta un puntero a un S1 y un S2 de una fuente externa podría cumplir con las reglas CIS de C89 sin permitir que el mismo comportamiento sea útil con punteros a estructuras que no estaban realmente dentro de un objeto union; especificando CIS por lo tanto, el apoyo a las estructuras habría sido redundante, dado que ya especificado para los sindicatos.