gcc, strict-aliasing und Horrorgeschichten

Keine horror-Geschichte meiner eigenen, aber hier sind einige Zitate von Linus Torvalds (sorry wenn diese schon in einem der verlinkten Referenzen in der Frage):

http://lkml.org/lkml/2003/2/26/158:

Date Wed, 26 Feb 2003 09:22:15 -0800
Betreff Re: Ungültige Zusammenstellung ohne -fno-strict-aliasing
Von Jean Tourrilhes <>

On Wed, Feb 26, 2003 at 04:38:10PM +0100, Horst von Brand schrieb:

Jean Tourrilhes <> sagte:

Sieht es aus wie ein compiler-bug zu mir...
Einige Benutzer haben sich beschwert, dass, wenn der folgende code
kompiliert ohne-fno-strict-aliasing, die Reihenfolge der schreiben und
memcpy ist invertiert (was bedeutet, eine falsche len mem-kopiert man in das
stream).
Code (aus der linux/include/net/iw_handler.h) :

static inline char *
iwe_stream_add_event(char *   stream,     /* Stream of events */
                     char *   ends,       /* End of stream */
                    struct iw_event *iwe, /* Payload */
                     int      event_len)  /* Real size of payload */
{
  /* Check if it's possible */
  if((stream + event_len) < ends) {
      iwe->len = event_len;
      memcpy(stream, (char *) iwe, event_len);
      stream += event_len;
  }
  return stream;
}

IMHO sollte der compiler haben genug Kontext, um zu wissen, dass die
die Neuordnung ist gefährlich. Jeder Vorschlag zu machen, diesen einfachen code mehr
bullet proof ist zu begrüßen.

Der compiler ist frei, davon auszugehen char * - stream und struct iw_event *iwe Punkt
um separate Speicherbereiche, aufgrund der strengen aliasing.

Was ist wahr und was ist nicht das problem, das ich mich beschwere über.

(Anmerkung im Nachhinein: dieser code ist in Ordnung, aber die Linux-Implementierung von memcpy wurde ein makro, das cast, die long * kopieren in größeren Blöcken. Mit korrekt definierten memcpygcc -fstrict-aliasing ist nicht erlaubt, diese zu brechen-code. Aber es bedeutet, dass Sie inline-asm zu definieren, einen kernel memcpy wenn dein compiler nicht wissen, wie drehen eine byte-Kopie-Schleife in effiziente asm, das war der Fall für den gcc vor gcc7)

Und Linus Torvald ' s Kommentar auf der oben:

Jean Tourrilhes schrieb:
>

Sieht es aus wie ein compiler-bug zu mir...

Warum denken Sie, dass der kernel verwendet "-fno-strict-aliasing"?

Die gcc-Leute sind mehr daran interessiert, versucht herauszufinden, was kann das sein
erlaubt durch die c99-specs als über die Dinge eigentlich Arbeit. Die
aliasing-code in allem ist es nicht einmal Wert ermöglicht, ist es einfach nicht
möglich sanely gcc sagen, wenn einige Dinge können alias.

Einige Benutzer haben sich beschwert, dass, wenn der folgende code
kompiliert ohne-fno-strict-aliasing, die Reihenfolge der schreiben und
memcpy ist invertiert (was bedeutet, eine falsche len mem-kopiert man in das
stream).

Das "problem" ist, dass wir inline memcpy(), an welcher Stelle gcc nicht
Sorge über die Tatsache, dass es alias, so werden Sie nur wieder, um
alles und behaupten, es ist aus eigenem Verschulden. Obwohl es keine vernünftige
Weg für uns, um auch gcc sagen, über Sie.

Habe ich versucht, einen vernünftigen Weg vor ein paar Jahren, und die gcc-Entwickler wirklich
habe keine sorgen über die Reale Welt in diesem Bereich. Ich würde überrascht sein, wenn das
hatte sich verändert, die Beurteilung durch die Antworten, die ich schon gesehen haben.

Ich werde nicht zu stören, Sie zu bekämpfen.

Linus

http://www.mail-archive.com/[email protected]/msg01647.html:

Type-based alias dumm. Es ist so unglaublich dumm, dass es ist nicht sogar lustig. Es ist gebrochen. Und gcc nahm die kaputte Vorstellung und machte es um so mehr, indem Sie ein "von-der-Brief-von-der-Gesetz", was keinen Sinn macht.

...

Ich weiß, für eine Tatsache , gcc-würde wieder bestellen Schreibzugriffe, die waren deutlich zu (statisch) die gleiche Adresse. Gcc würde plötzlich denken, dass

unsigned long a;

a = 5;
*(unsigned short *)&a = 4;

könnte neu geordnet, um es zu 4 ersten (weil Sie es offensichtlich nicht alias - durch das Lesen der standard), und dann, weil nun die Zuweisung 'a=5' später wurde die Zuordnung der 4 könnte erstellte ganz! Und wenn jemand sich beschwert, dass der compiler ist verrückt, die compiler-Leute würden sagen, "nyaah, nyaah, die Normen Leute sagte, wir können dies tun", mit absolut keine introspection zu Fragen, ob es irgendeinen SINN machte.

InformationsquelleAutor der Antwort Michael Burr

gcc, aliasing-und 2-D-variable-length-arrays: Der folgende code kopiert eine 2x2-matrix:

#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;
}

Mit gcc 4.1.2 auf CentOS, bekomme ich:

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

Ich weiß nicht, ob das allgemein bekannt, und ich weiß nicht, ob das ein bug oder ein feature ist. Kann ich nicht duplizieren das problem mit gcc 4.3.4 auf Cygwinso kann es haben, wurde behoben. Einige Workarounds:

• Verwenden __attribute__((noinline)) zum kopieren().
• Verwendung der gcc-Schalter -fno-strict-aliasing.
• Ändern Sie den Dritten parameter von copy() von b[][n] zu b[][2].
• Nicht verwenden -O2 oder -O3.

Weitere Hinweise:

• Dies ist eine Antwort, nach einem Jahr und einem Tag, um meine eigene Frage (und ich bin ein bisschen überrascht, es sind nur zwei andere Antworten).
• Verlor ich mehrere Stunden mit diesem auf meinem eigentlichen code, ein Kalman-filter. Scheinbar kleine änderungen hätte drastische Auswirkungen, vielleicht aufgrund der änderung der gcc-automatische inlining (dies ist eine Vermutung, ich bin immer noch unsicher). Aber es wahrscheinlich nicht qualifiziert als horror story.
• Ja, ich weiß, Sie würde nicht schreiben copy() wie diese. (Und, nebenbei, ich war etwas überrascht zu sehen, dass gcc nicht entrollen die Doppel-Looping.)
• Keine gcc-Warnung Schalter, zählen -Wstrict-aliasing=hat hier nichts.
• 1-D variable-length arrays scheinen in Ordnung zu sein.

Update: Das oben nicht wirklich beantworten die OP ' s Frage, da er (also ich) wurde gefragt, über die Fälle, wo strenge aliasing 'legitim' brach Ihr code, in der Erwägung, dass die oben genannten einfach zu sein scheint, eine Garten-Sorte compiler-Fehler.

Ich meldete es GCC Bugzillaaber Sie waren nicht daran interessiert, die alte 4.1.2, obwohl (ich glaube) es ist der Schlüssel zu der $1-Milliarden-RHEL5. Kommt es nicht in 4.2.4.

Und ich habe einen etwas einfacheren Beispiel von einem ähnlichen bug, mit nur einer matrix. Der code:

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;
}

produziert die Ergebnisse:

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

Es scheint, ist es die Kombination -fstrict-aliasing mit -finline die Ursachen der Fehler.

InformationsquelleAutor der Antwort Joseph Quinsey

hier ist meiner:

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

es verursacht bestimmte Formen in einem CAD-Programm gezeichnet werden, falsch. danken Sie Güte, die für das Projekt Staats-und Regierungschefs den Aufbau einer regression test-suite.

den Fehler nur manifestierte sich, auf bestimmten Plattformen, die mit älteren Versionen von GCC und ältere Versionen bestimmter Bibliotheken. und dann nur mit -O2 aktiviert. -fno-strict-aliasing gelöst.

InformationsquelleAutor der Antwort don bright