clang zeigt auch Negativa

[Helmut Schellong]

Ich betreibe nach langer Zeit wieder intensive private
C-Entwicklungen.
Im Beruf gcc 4.x für Coldfire.
Nun privat unter FreeBSD 10.1 clang.

Zwei Dinge kann ich berichten:

Die Doku zu clang ist sehr dünn.
Auch das Handbuch auf der Webseite.
Auch clang --help hilft da nicht.
Ich bin dazu übergegangen, die gcc-Doku zu lesen,
um clang-Optionen herauszufinden.

clang verwendet KEINE Sprungtabelle, falls die
case 3: case 4: case 5: .. case 66: case 67:
nicht um 1 steigend sind, sondern beispielsweise
alle(!) um 4 steigend sind.

jmpq *.LJTI4_0(,%rcx,8)

Vorstehend ein Tabellensprung - nur bei 1er-Steigung.
Vor etlichen Jahren (vielleicht 15) hat gcc schon
in Fällen von 2 4 8 etc. %rcx 1 2 3 Bit >>geshiftet, um
die Distanz zu normieren.
clang zieht es leider vor, 50 Vergleiche zu machen,
if (s==11) ...
if (s==12) ...
...
if (s==54) ...
if (s==55) ...
bis die richtige Stelle erreicht ist.
Stärkere Optimierung ändert nichts daran.
Ich hatte einen 4er-Abstand, um bei 3 Werten
evtl. Bits 1 2 3 hinzuzufügen: case HULKO|2:
Dies Konzept kann ich mir abschminken.

Vorteile von clang sind bekanntlich:
Schnelle Kompilierung.
Vorzügliche Ausgabe von Meldungen (error, warning, etc.).
Weitgehende Beherrschung von C11!

[Claus Reibenstein]

[clang]

Hat mit C genau was zu tun?

Gruß
Claus

[Helmut Schellong]

Post by Claus Reibenstein

[clang]

Hat mit C genau was zu tun?

Die absolute Hauptsache.
Ohne C-Compiler wäre C etwas akademisches, theoretisches.

Vieles, was hier gepostet wird, ist kompilierter C-Code,
der nicht läuft.
Ohne Kompilierung gäbe es das nicht.
Dann könnte man den highlighted Code so aus lauter
Langeweile anschauen - "Ach wie schön sieht das aus.";
"Schau mal diese Strukturen an, in Farbe und Abfolge..."

Die Eigenschaften von C-Compilern sind in vielen Bereichen
absolut entscheidend.

Das sieht man z.B. daran, falls C-Compiler C99 und C11
nicht unterstützen.
Man kann dann C99 und C11 nicht nutzen, eventuell
jahrzehntelang.
Folglich hätte man auch auf C99 und C11 verzichten
können.

[Juergen Ilse]

Hallo,

Post by Helmut Schellong

Post by Claus Reibenstein

[clang]

Hat mit C genau was zu tun?

Die absolute Hauptsache.
Ohne C-Compiler wäre C etwas akademisches, theoretisches.

Sehen wir doch mal auf das Thema dieser Gruppe:
-------------------------------
| In dieser Gruppe werden Themen diskutiert, die unmittelbar die Programmier-
| sprache C betreffen. Die Diskussion sollte sich dabei auf die Varianten
| ISO 9899 ("ISO C") und ANSI C3.159 ("ANSI C") bzw. deren Vorgänger (z.B.
| K&R-C, "Kernighan and Ritchie") beschränken. Für plattformspezifische
| Fragen sind andere, geeignete Gruppen zu verwenden.
| Plattformspezifisch sind beispielsweise (aber nicht ausschließlich) Fragen
| nach der Ansteuerung bestimmter Hardware (Drucker, Bildschirm, Tastatur,
| Maus), der Verwendung von Betriebssystemschnittstellen (POSIX, Win32) oder
| Fragen zur Installation des C-Compilers und der Entwicklungsumgebung.
-------------------------------
Mal abgesehen davon, dass diese Charta mal renoviert werden sollte, um auch
die aktuelleren C-Standards mit einzuschliessen:
Auch Fragen zu bestimmten C-Implementierungen (wie z.B. wie bestimmte Compiler
bestimmte Quelltext-Fragmente umsetzen) sind compiler- und damit natuerlich
insbesondere auch plattform-spezifisch, sind also in dieser Gruppe OffTopic.

Post by Helmut Schellong
Die Eigenschaften von C-Compilern sind in vielen Bereichen
absolut entscheidend.

In dieser Gruppe sind nur die Eigenschaften OnTopic, die der C-Standard
vorschreibt, und was fuer Code bestimmte Compiler im einzelnen erzeugen,
zaehlt da nicht dazu (sofern das Ergebnis eine standardkonforme Umsetzung
des Codes ist).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Helmut Schellong]

Post by Juergen Ilse
Hallo,

Post by Helmut Schellong

Post by Claus Reibenstein

[clang]

Hat mit C genau was zu tun?

Die absolute Hauptsache.
Ohne C-Compiler wäre C etwas akademisches, theoretisches.

-------------------------------
| In dieser Gruppe werden Themen diskutiert, die unmittelbar die Programmier-
| sprache C betreffen. Die Diskussion sollte sich dabei auf die Varianten
| ISO 9899 ("ISO C") und ANSI C3.159 ("ANSI C") bzw. deren Vorgänger (z.B.
| K&R-C, "Kernighan and Ritchie") beschränken. Für plattformspezifische
| Fragen sind andere, geeignete Gruppen zu verwenden.
| Plattformspezifisch sind beispielsweise (aber nicht ausschließlich) Fragen
| nach der Ansteuerung bestimmter Hardware (Drucker, Bildschirm, Tastatur,
| Maus), der Verwendung von Betriebssystemschnittstellen (POSIX, Win32) oder
| Fragen zur Installation des C-Compilers und der Entwicklungsumgebung.
-------------------------------
Mal abgesehen davon, dass diese Charta mal renoviert werden sollte, um auch
Auch Fragen zu bestimmten C-Implementierungen (wie z.B. wie bestimmte Compiler
bestimmte Quelltext-Fragmente umsetzen) sind compiler- und damit natuerlich
insbesondere auch plattform-spezifisch, sind also in dieser Gruppe OffTopic.

Post by Helmut Schellong
Die Eigenschaften von C-Compilern sind in vielen Bereichen
absolut entscheidend.

In dieser Gruppe sind nur die Eigenschaften OnTopic, die der C-Standard
vorschreibt, und was fuer Code bestimmte Compiler im einzelnen erzeugen,
zaehlt da nicht dazu (sofern das Ergebnis eine standardkonforme Umsetzung
des Codes ist).

Dann werde ich mal ausführlicher, und lese und verstehe präzise:

1)
Der C-Standard schreibt viel über den C-Compiler ("Translator"):
Er verwendet die weiteren Worte: "translation", "compiler",
"optimizing compiler", "compiler transformations", etc.

2)
Ein C-Standard entsteht stets auch durch intensive Gespräche
mit Compiler-Entwicklern.
Die Sprache C ist folglich mit C-Compilern *untrennbar* verbunden!

Es ist insofern 'witzig' bis albern, jegliches Schreiben
zu C-Compilern als OffTopic zu bezeichnen.

3)
Die Beschreibung des Themas dieser Gruppe enthält auch nicht
die Absicht, jegliches Schreiben zu C-Compilern zu unterbinden.
Es wird *plattformspezifisches* Schreiben als unerwünscht erklärt.

Ich habe keinen plattformspezifischen Inhalt geschrieben!
Ich habe einen C-Compiler genannt, der nicht plattformspezifisch
ist, allein schon wegen OpenSource.
Optimierungsverhalten eines C-Compilers ist ebensowenig
plattformspezifisch.

| Plattformspezifisch sind beispielsweise (aber nicht ausschließlich) Fragen
| nach der Ansteuerung bestimmter Hardware (Drucker, Bildschirm, Tastatur,
| Maus), der Verwendung von Betriebssystemschnittstellen (POSIX, Win32) oder
| Fragen zur Installation des C-Compilers und der Entwicklungsumgebung.

Ich habe nichts zu einer Installation eines Compilers oder zur Installation
einer Entwicklungsumgebung geschrieben.

Oben steht: "der Entwicklungsumgebung", nicht: "zur Entwicklungsumgebung".
Das Wort "Installation" bezieht sich folglich auch auf
"Entwicklungsumgebung".
Oben steht: "Plattformspezifisch sind ... oder Fragen zur ...".
Es wurde nicht "alle Fragen" geschrieben, es wird alles
"beispielsweise" genannt.

Auch wenn nicht der Vorgang des Installierens gemeint ist, sondern
die vollendete Installation als Liegenschaft, ändert das nichts.

Ich habe hier nicht interpretiert, sondern genau das berücksichtigt,
was dort geschrieben steht, sofern man ganz richtig Deutsch kann.


Dann ist das Optimierungsverhalten bei 'switch () { ...' enorm
wichtig!
Es gibt Compiler, die mehrere Optionen zur Verfügung stellen, um
speziell die Optimierung von 'switch ...' zu steuern.
Die Information, die ich gab, kann folglich wichtig bis sehr wichtig
für so manchen sein.

[Juergen Ilse]

Hallo,

Post by Helmut Schellong
3)
Die Beschreibung des Themas dieser Gruppe enthält auch nicht
die Absicht, jegliches Schreiben zu C-Compilern zu unterbinden.
Es wird *plattformspezifisches* Schreiben als unerwünscht erklärt.

Code-Gernerierung eins bestimmten Compilers ist compilerabhaengig und damit
insbesondere auch plattformabhaengig, somit hier OffTopic. Die Diskussion
hatten wir IIRC in der Vergangenheit schon mindestens ein halbes Dutzend
mal. Dein Thread ist hier *OFFTOPIC*.

Post by Helmut Schellong
Ich habe keinen plattformspezifischen Inhalt geschrieben!

Doch. Du hast dich auf die Codegenerierung eines bestimmten Compilers
bezogen. Das ist plattformabhaengig. Und es hat bestenfalls indirekt
Bezug zur Sprache C. Es ist hier eindeutig OffTopic, also frag wo anders.

Post by Helmut Schellong
| Plattformspezifisch sind beispielsweise (aber nicht ausschließlich) Fragen
| nach der Ansteuerung bestimmter Hardware (Drucker, Bildschirm, Tastatur,
| Maus), der Verwendung von Betriebssystemschnittstellen (POSIX, Win32) oder
| Fragen zur Installation des C-Compilers und der Entwicklungsumgebung.
Ich habe nichts zu einer Installation eines Compilers oder zur Installation
einer Entwicklungsumgebung geschrieben.

Die in der Charta stehende Liste ist nicht vollstaendig (wie auch aus der
Charta eindeutig hervorgeht).

Und nun geh mit deiner Frage wo hin, wo sie OnTopic ist, Hier ist das
*NICHT* der Fall.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Helmut Schellong]

Post by Juergen Ilse
Hallo,

Post by Helmut Schellong
3)
Die Beschreibung des Themas dieser Gruppe enthält auch nicht
die Absicht, jegliches Schreiben zu C-Compilern zu unterbinden.
Es wird *plattformspezifisches* Schreiben als unerwünscht erklärt.

Code-Gernerierung eins bestimmten Compilers ist compilerabhaengig und damit
insbesondere auch plattformabhaengig, somit hier OffTopic. Die Diskussion
hatten wir IIRC in der Vergangenheit schon mindestens ein halbes Dutzend
mal. Dein Thread ist hier *OFFTOPIC*.

Post by Helmut Schellong
Ich habe keinen plattformspezifischen Inhalt geschrieben!

Doch. Du hast dich auf die Codegenerierung eines bestimmten Compilers
bezogen. Das ist plattformabhaengig. Und es hat bestenfalls indirekt
Bezug zur Sprache C. Es ist hier eindeutig OffTopic, also frag wo anders.

[...]

Post by Juergen Ilse
Die in der Charta stehende Liste ist nicht vollstaendig (wie auch aus der
Charta eindeutig hervorgeht).
Und nun geh mit deiner Frage wo hin, wo sie OnTopic ist, Hier ist das
*NICHT* der Fall.

Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Da steht drin: "Linux", "Windows", Handles, "CON:", etc.
Das ist massiv OffTopic.
Wenn jedoch von mir eines kommt, wird ganz, ganz, ganz genau hingeschaut...

Ich denke, bei der geringen Frequenz hier sollte man die Gruppe (endlich)
schließen. Es gab z.B. von Februar bis Juni kein einziges Posting hier,
außer der wöchentlichen dclcfaq.
Woanders wird schon lange herumgespöttelt über das extreme
OffTopic-Vorwerfen in dieser Gruppe, seit Jahren.

[Claus Reibenstein]

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".

Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

Gruß
Claus

[Helmut Schellong]

Post by Claus Reibenstein

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

Du hast gerade bestätigt, daß die Begriffe:

"Umleiten" (Input/Output)
"Windows", "Linux", "CON:" (Windows Gerätetreiber),
"Eclipse", "/dev/stdout", "/dev/tty", "Konsole",
"DLL", "Bibliothek", ".dll", "Java", "cmd.exe",
'Patchen einer Bibliothek'.

allesamt OnTopic sind.

Weiterhin war mein Posting 1 Posting.
Der besagte Thread besteht aus 10 Postings.
Folglich war ich berechtigt von 'Massen' zu reden im Vergleich.

Dieser besagte OffTopic-Thread wurde geduldet.
Oder bekam er eine Ermahnung, die für mich unsichtbar ist?

In meinem einzelnen Posting gab es nur den Namen eines
C-Compilers, der bereits Anlaß war für eine OffTopic-Ermahnung:

| Helmut Schellong schrieb:
|
| > [clang]
|
| Hat mit C genau was zu tun?

[Claus Reibenstein]

Post by Helmut Schellong

Post by Claus Reibenstein

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

"Umleiten" (Input/Output)
"Windows", "Linux", "CON:" (Windows Gerätetreiber),
"Eclipse", "/dev/stdout", "/dev/tty", "Konsole",
"DLL", "Bibliothek", ".dll", "Java", "cmd.exe",
'Patchen einer Bibliothek'.
allesamt OnTopic sind.

Interessant. Wo denn? Dort oben jedenfalls nicht, und auch sonst käme
ich nie auf die Idee, derart Abstruses zu behaupten oder gar zu bestätigen.

Post by Helmut Schellong
Weiterhin war mein Posting 1 Posting.
Der besagte Thread besteht aus 10 Postings.

Welcher "besagte Thread"?

Post by Helmut Schellong
Folglich war ich berechtigt von 'Massen' zu reden im Vergleich.

Ohne konkret zu werden? Mitnichten!

Post by Helmut Schellong
Dieser besagte OffTopic-Thread wurde geduldet.
Oder bekam er eine Ermahnung, die für mich unsichtbar ist?

Da Du nirgends einen Thread "besagt" hast, kann ich das nicht nachprüfen.

Post by Helmut Schellong
In meinem einzelnen Posting gab es nur den Namen eines

Du hast nicht nur den Namen dieses Compilers genannt, sondern Dich
ziemlich ausführlich über seine Eigenarten ausgelassen und damit nichts,
aber auch rein gar nichts, zum Thema der Gruppe beigetragen. Im Gegenteil.

Gruß
Claus

[Helmut Schellong]

Post by Claus Reibenstein

Post by Helmut Schellong
"Umleiten" (Input/Output)
"Windows", "Linux", "CON:" (Windows Gerätetreiber),
"Eclipse", "/dev/stdout", "/dev/tty", "Konsole",
"DLL", "Bibliothek", ".dll", "Java", "cmd.exe",
'Patchen einer Bibliothek'.
allesamt OnTopic sind.

Interessant. Wo denn? Dort oben jedenfalls nicht, und auch sonst käme
ich nie auf die Idee, derart Abstruses zu behaupten oder gar zu bestätigen.

Post by Helmut Schellong
Weiterhin war mein Posting 1 Posting.
Der besagte Thread besteht aus 10 Postings.

Welcher "besagte Thread"?

Ich hatte den Thread benannt.
Aus demjenigen Posting habe ich auch die oben
stehenden Begriffe kopiert.

[Herbert Meinl]

Post by Claus Reibenstein

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.
Gruß
Claus

Was ist das denn hier?

Monatelang gibt´s hier nix als FAQ. Dann kommen endlich mal konkrete
Themen. Und schon wird auf die Fragesteller eingedroschen, doch hier
abzuhauen. Weil das nicht in die Charta (Stand: 2008) passt!

Scheint wohl so, dass es tatsächlich Leute gibt, die mit den
wöchentlichen FAQ allein zufrieden sind . . .

[Helmut Schellong]

Post by Herbert Meinl

Post by Claus Reibenstein

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

Was ist das denn hier?
Monatelang gibt´s hier nix als FAQ. Dann kommen endlich mal konkrete Themen.
Und schon wird auf die Fragesteller eingedroschen, doch hier abzuhauen. Weil
das nicht in die Charta (Stand: 2008) passt!
Scheint wohl so, dass es tatsächlich Leute gibt, die mit den wöchentlichen
FAQ allein zufrieden sind . . .

Das hat persönliche und psychische Gründe:

Ich bin einer, der in der Vergangenheit hier etwa 3500 Postings
geschrieben hat, der Rekordhalter oder der Vize-Rekordhalter.
Ich hatte fast immer eine gewisse Vehemenz (Kraft,Unerschrockenheit) drauf.
Das alles störte.
Auch meine makellos funktionierende Shell bsh stört, die ich höchst
erfolgreich jahrzehntelang am Industriearbeitsplatz einsetzte.
(Es gab da auch Schmähschriften.)
Eventuell stört auch, daß ich Autor eines C-Buches bin (akt. 3.Auflage).

Es gab da eine Gruppe von Leuten:
Gunnar Ritter, Jürgen Ilse, geringfügig Felix von Leitner, die
massiv etwas gegen mich hatten.
Man hatte da Einträge in den Admin-Strukturen des Usenet
gegen mich vorgenommen.
Man hatte Albert Rommel, der etwas Positives über mich im
Internet geschrieben hatte, dazu bewegt, dieses Positive
zu entfernen.
Dabei war es z.B. Gunnar Ritter, der unablässig Poster in
de.comp.os.unix.shell höhnisch, sarkastisch, herablassend,
unwürdig, auf's Schwerste beleidigend behandelt hatte.
Man hätte da vielleicht 500 Verfahren wegen Beleidigung
erfolgreich eröffnen können.
Als ich da auftauchte, wurde ich behandelt, als hätte ich
in deren Wohnzimmer gepinkelt.


Dann ist es so, daß in Deutschland extrem gerne 'verboten' wird.
In Deutschland stehen Schilder "Betreten verboten!" auf dem Rasen.
In anderen Ländern steht da eher: "Bitte nicht betreten".

Man will hier Erbsenzählertypen mit ordnungsamtlichem Flair haben.
Andere Typen stören.
Man stelle sich einen Erstklässler vor, der fotografiert wird:
Der sitzt dabei stramm und gerade, mit zusammengekniffenem Mund,
den rechten Zeigerfinger straff ausgestreckt, auf einen
Schreibblock mit Stift zeigend.
Solch ein Typus liegt vor bzw. wird als optimal angesehen.


Helmut Leitner, österreichischer Software-Unternehmer, der hier
damals viel schrieb, hat sich schon vor langer Zeit zurückgezogen.
Er wollte/will sich 'das hier' nicht mehr länger antun.
Er begann auch die folgende Seite für mich:
http://www.dsewiki.org/wiki.cgi?HelmutSchellong

[Claus Reibenstein]

Post by Herbert Meinl
Was ist das denn hier?
Monatelang gibt´s hier nix als FAQ. Dann kommen endlich mal konkrete Themen.
Und schon wird auf die Fragesteller eingedroschen, doch hier abzuhauen. Weil
das nicht in die Charta (Stand: 2008) passt!
Scheint wohl so, dass es tatsächlich Leute gibt, die mit den wöchentlichen
FAQ allein zufrieden sind . . .

Das hat weder persönliche noch psychische, sondern rein sachliche Gründe.

Dass Du diese nicht verstehst, könnte tatsächlich psychische Gründe
haben. Das zu klären, ist aber nicht unsere Aufgabe. Dafür gibt es
Fachleute.

Gruß
Claus

[Claus Reibenstein]

Post by Herbert Meinl
Was ist das denn hier?

Eine Gruppe, die die Programmiersprache C zum Thema hat.

Post by Herbert Meinl
Monatelang gibt´s hier nix als FAQ. Dann kommen endlich mal konkrete
Themen.

Die aber leider nichts mit dieser Gruppe zu tun haben.

Post by Herbert Meinl
Und schon wird auf die Fragesteller eingedroschen, doch hier
abzuhauen. Weil das nicht in die Charta (Stand: 2008) passt!

Genau so ist es, und das ist gut so.

Dass die Charta mal überarbeitet (sprich: aktualisiert) werden müsste,
damit auch neuere C-Versionen offiziell hier on topic werden, wurde hier
im Übrigen bereits erwähnt. Aber auch nur in diese Richtung.

Post by Herbert Meinl
Scheint wohl so, dass es tatsächlich Leute gibt, die mit den
wöchentlichen FAQ allein zufrieden sind . . .

Das scheint nur so.

Gruß
Claus

[Juergen Ilse]

hallo,

Post by Herbert Meinl
Was ist das denn hier?
Monatelang gibt´s hier nix als FAQ. Dann kommen endlich mal konkrete
Themen. Und schon wird auf die Fragesteller eingedroschen, doch hier
abzuhauen. Weil das nicht in die Charta (Stand: 2008) passt!

Wenn gewuenscht ist, dass aucg compiler und/oder systemspeziffische
fragen in dieser Gruppe OnTopic sein sollen, dann sollten diejenigen
die das gern haetten, vielleicht ein Verfahren zur Charta-Aenderung
starten ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Peter J. Holzer]

Post by Claus Reibenstein

Post by Helmut Schellong
Na ja, andere Postings in Massen hier, die von oben bis unten OffTopic
sind, werden hier kommentarlos - wie selbstverständlich - geduldet.

Nein, werden sie nicht. Schon gar nicht "in Massen".
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

Hoffentlich nicht. Ich halte die Frage, wie verschiedene Compiler mit
standard-konformem oder nicht-standard-konformem Code umgehen, für
absolut on-topic. Im Gegensatz zu Eurem Hausmeister-Gekeppel.

hp

[Claus Reibenstein]

Post by Peter J. Holzer

Post by Claus Reibenstein
Und jetzt befolge endlich Jürgens absolut berechtigten Rat.

Hoffentlich nicht. Ich halte die Frage, wie verschiedene Compiler mit
standard-konformem oder nicht-standard-konformem Code umgehen, für
absolut on-topic. Im Gegensatz zu Eurem Hausmeister-Gekeppel.

Dann hast du die Charta nicht verstanden. Sorry.

Gruß
Claus

[Stefan Reuther]

Post by Juergen Ilse

Post by Helmut Schellong

Post by Claus Reibenstein

[clang]

Hat mit C genau was zu tun?

Die absolute Hauptsache.
Ohne C-Compiler wäre C etwas akademisches, theoretisches.

-------------------------------
| In dieser Gruppe werden Themen diskutiert, die unmittelbar die Programmier-
| sprache C betreffen.

Check. Die Qualität eines C-Compilers betrifft unmittelbar die
Programmiersprache C.

Post by Juergen Ilse
Auch Fragen zu bestimmten C-Implementierungen (wie z.B. wie bestimmte Compiler
bestimmte Quelltext-Fragmente umsetzen) sind compiler- und damit natuerlich
insbesondere auch plattform-spezifisch, sind also in dieser Gruppe OffTopic.

Ich hätte ja erwartet, dass man sich in Zeiten, wo die Postingstatistik
so aussieht (Januar bis Mai):

: Nr. : Anzahl : Prozent : Newsgroup :
: 115. : 45 : 0.09% : de.comp.lang.c :
: 214. : 5 : 0.01% : de.comp.lang.c :
: 202. : 6 : 0.01% : de.comp.lang.c :
: 205. : 5 : 0.01% : de.comp.lang.c :
: 208. : 6 : 0.01% : de.comp.lang.c :

mehr damit beschäftigt, was man alles zum Thema machen könnte anstatt
was alles nicht Thema sei.

Das wäre vielleicht notwendig gewesen, als die Statistik noch so aussah:
Prozent Anzahl Typ
0.18 672 de.comp.lang.c
0.13 506 de.comp.lang.c
0.20 729 de.comp.lang.c
0.29 1042 de.comp.lang.c
0.17 558 de.comp.lang.c
(Ende 2003).

Ansonsten bleibt festzuhalten, dass es zum Thema "praktische
Programmierung in Sprache X" einfach keine bessere Newsgruppe als die
Sprachgruppe gibt. clang ist jedenfalls nicht betriebssystemspezifisch.


Stefan

[Peter J. Holzer]

Post by Stefan Reuther
Ich hätte ja erwartet, dass man sich in Zeiten, wo die Postingstatistik
mehr damit beschäftigt, was man alles zum Thema machen könnte anstatt
was alles nicht Thema sei.

In einer toitschen Newsgroup? Da muss alles seine Ordnung haben. Und
Perfektion ist ja bekanntlich dann erreicht, wenn man nichts mehr
wegnehmen kann.

hp

[Juergen Ilse]

Hallo,

Post by Stefan Reuther

Post by Juergen Ilse
-------------------------------
| In dieser Gruppe werden Themen diskutiert, die unmittelbar die Programmier-
| sprache C betreffen.

Check. Die Qualität eines C-Compilers betrifft unmittelbar die
Programmiersprache C.

Nein. Es mag in gewisser Weise das Programmieren in der Sprache betreffen,
sofern man genau diesen Compiler verwendet. Mit der Sprache C an sich (die
das Thema dieser Gruppe ist) hat das aber trotzdem nichrs zu tun.

Post by Stefan Reuther

Post by Juergen Ilse
Auch Fragen zu bestimmten C-Implementierungen (wie z.B. wie bestimmte Compiler
bestimmte Quelltext-Fragmente umsetzen) sind compiler- und damit natuerlich
insbesondere auch plattform-spezifisch, sind also in dieser Gruppe OffTopic.

Ich hätte ja erwartet, dass man sich in Zeiten, wo die Postingstatistik

Wenn du auch andere Themen in dieser Gruppe diskutiert haben moechtest,
kannst du gern versuchen, eine Charta-Aenderung durchzusetzen. Solange
die Charta so aussieht, wie sie momentan aussieht, ist Helmuts Frage
aber OffTopic.

Post by Stefan Reuther
Ansonsten bleibt festzuhalten, dass es zum Thema "praktische
Programmierung in Sprache X" einfach keine bessere Newsgruppe als die
Sprachgruppe gibt. clang ist jedenfalls nicht betriebssystemspezifisch.

In dieser Gruppe ist die Frage *OFFTOPIC*, weil diese Gruppe sich eben
mit der Sprache selbst beschaeftigt, wie sie im Sprachstandard festgelegt
ist. Mit dem, was du als "praktische Programmierung" bezeichnest, be-
schaeftigt sich diese Gruppe ausdruecklich nicht (sie dazu auch due FAQ).
Und da die Frage hier OffTopic ist, kann diese Gruppe auch nicht die
beste Newsgruppe fuer das Thema sein.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Helmut Schellong]

[...]

Post by Stefan Reuther
mehr damit beschäftigt, was man alles zum Thema machen könnte anstatt
was alles nicht Thema sei.

Man muß noch bedenken, daß Anzahl 4..5 die Anzahl der automatisch
wöchentlich geposteten FAQ ist.

Desweiteren:
Es gibt doch z.B. den Thread:
"Umleiten von FILE* (Datei => stdout) bzw fopen ersetzen"
Ich habe nichts gegen den Thread.

Aber er ist substanziell beträchtlich mehr OffTopic
als mein Posting.
Bereits "Umleiten" im Titel ist OffTopic.
Im Inhalt kann man lesen:
"Windows", "Linux", "CON:" (Windows Gerätetreiber),
"Eclipse", "/dev/stdout", "/dev/tty", "Konsole",
"DLL", "Bibliothek", ".dll", "Java", "cmd.exe",
'Patchen einer Bibliothek'.

Zu diesem Thread gab es keine einzige Ermahnung
wegen OffTopic.

Deshalb poste ich noch Infos dazu (Microsoft):
CON Keyboard and display
PRN System list device, usually a parallel port
AUX Auxiliary device, usually a serial port
CLOCK$ System real-time clock
NUL Bit-bucket device
A:-Z: Drive letters
COM1 First serial communications port
LPT1 First parallel printer port
LPT2 Second parallel printer port
LPT3 Third parallel printer port
COM2 Second serial communications port
COM3 Third serial communications port
COM4 Fourth serial communications port


Mein clang-Posting hingegen beschäftigt sich
überwiegend mit purem C:
Ich berichtete von einem "switch" und seinen
"case C:", und daß man - wiederum pures C - die
Abstände 'case 1: case 2: case 3:' im Abstand
von '1' wählen sollte, bei Verwendung des
Compilers clang.

Eine Erwähnung des Compilers war unvermeidlich!
Andernfalls wäre dieser C-Tip (!) nicht
möglich gewesen.
Denn bei gcc z.B. muß man sich um die Abstände
kaum kümmern, denn der optimiert auch switches
mit großen und unterschiedlichen Lücken in
beeindruckender Weise.

Mein Posting war ein C-Tip,
anhand von C-Code.
Die Erwähnung von clang war eine Begründung
für diesen C-Tip, also sekundärer Natur, aber
unverzichtbar.
Folglich ist eine OffTopic-Mahnung im oben beschriebenen
Zusammenhang unverständlich und unbegründet.

[Heinz Saathoff]

Post by Helmut Schellong
Mein clang-Posting hingegen beschäftigt sich
Ich berichtete von einem "switch" und seinen
"case C:", und daß man - wiederum pures C - die
Abstände 'case 1: case 2: case 3:' im Abstand
von '1' wählen sollte, bei Verwendung des
Compilers clang.
Eine Erwähnung des Compilers war unvermeidlich!
Andernfalls wäre dieser C-Tip (!) nicht
möglich gewesen.
Denn bei gcc z.B. muß man sich um die Abstände
kaum kümmern, denn der optimiert auch switches
mit großen und unterschiedlichen Lücken in
beeindruckender Weise.
Mein Posting war ein C-Tip,
anhand von C-Code.
Die Erwähnung von clang war eine Begründung
für diesen C-Tip, also sekundärer Natur, aber
unverzichtbar.
Folglich ist eine OffTopic-Mahnung im oben beschriebenen
Zusammenhang unverständlich und unbegründet.

Also ich fand den Hinweis (es war ja mehr ein Hinweis als eine Frage)
interessant.
Wenn man bedenkt, dass C eine Hardwarenahe Programmiersprache sein
soll, dann sind Übersetzungsstrategien für den Anwender schon
interessant. Solche Sachen wie
- Overhead bei Funktionsaufrufen
- if-else Kettenvergleiche oder switch nutzen
- arrays indizieren oder doch lieber mit pointern arbeiten
- float/double bei Prozessoren ohen FPU

Solche Fragen kann man sicherlich nicht allgemein beantworten, das sie
Compiler- und Prozessorabhängig sind. Bei einer real verwendeten
Programmiersprache spielt eben auch die Implementierbarkeit von
Sprachkonstrukten eine Rolle.
Und das finde ich scho OnTopic


- Heinz

[Michael Baeuerle]

Post by Stefan Reuther

Post by Juergen Ilse

Post by Helmut Schellong

Post by Claus Reibenstein

[clang]

Hat mit C genau was zu tun?

Die absolute Hauptsache.
Ohne C-Compiler wäre C etwas akademisches, theoretisches.

-------------------------------
| In dieser Gruppe werden Themen diskutiert, die unmittelbar die Programmier-
| sprache C betreffen.

Check. Die Qualität eines C-Compilers betrifft unmittelbar die
Programmiersprache C.

Post by Juergen Ilse
Auch Fragen zu bestimmten C-Implementierungen (wie z.B. wie bestimmte Compiler
bestimmte Quelltext-Fragmente umsetzen) sind compiler- und damit natuerlich
insbesondere auch plattform-spezifisch, sind also in dieser Gruppe OffTopic.

Ich hätte ja erwartet, dass man sich in Zeiten, wo die Postingstatistik
mehr damit beschäftigt, was man alles zum Thema machen könnte anstatt
was alles nicht Thema sei.

Volltreffer. Ich war gerade dabei auf "Unsubscribe" zu klicken, weil ich
genau diesen Gedanken im Kopf hatte. Mit dieser Einstellung kann da
nichts mehr draus werden.

[Rainer Weikusat]

Post by Helmut Schellong
Ich betreibe nach langer Zeit wieder intensive private
C-Entwicklungen.
Im Beruf gcc 4.x für Coldfire.
Nun privat unter FreeBSD 10.1 clang.

[...]

Bemerkung, die ich mir hier nicht verkneifen kann: Laengere Diskussionen
ueber einander widerstreitende Interpretationen einer Charta sind hier
jedenfalls auch nicht on topic. Und 'Eigenschaften von clang'
interessieren mich eher.

[Helmut Schellong]

Post by Rainer Weikusat

Post by Helmut Schellong
Ich betreibe nach langer Zeit wieder intensive private
C-Entwicklungen.
Im Beruf gcc 4.x für Coldfire.
Nun privat unter FreeBSD 10.1 clang.

[...]
Bemerkung, die ich mir hier nicht verkneifen kann: Laengere Diskussionen
ueber einander widerstreitende Interpretationen einer Charta sind hier
jedenfalls auch nicht on topic. Und 'Eigenschaften von clang'
interessieren mich eher.

Ernstzunehmende C-Programmierer sollten sich auch dafür interessieren.

Eigenschaften von Compilern können auf die C-Ebene zurückschlagen
und andere Konzepte gestatten oder erzwingen.
(Beispielsweise habe ich einen anderen Wertabstand wählen müssen.)
Insofern ist dieser Zusammenhang OnTopic.

clang scheint 'switch' gar nicht zu optimieren.
Eine Sprungtabelle in jedem Fall ist meiner Meinung nach Standard.

Ich kenne clang aus zwei speziellen Gründen:
o In meinem C-Buch 3.Auflage gibt es ein großes Kapitel C11.
Das ist mit clang gemeinsam erarbeitet worden, denn der
kann C11.
o Ich arbeite seit etwa 2000 mit FreeBSD.
Dort ist seit Release 10.0 clang der Standard-Compiler,
der gcc ablöste.

Man sprach von dem großen Vorteil(?) des clang, nämlich daß der
sehr schnell kompiliert.
Ich weiß/ahne jetzt auch, warum.

Als Ersatz eines switch() kann ein Array aus Funktionspointern dienen.
Etwa [100] reichen aus für z.B. einen Parser.
Es gibt da interessante Aspekte:
Beispielsweise können Funktionen auf einigen Positionen
die Funktionspointer dynamisch austauschen.

[Helmut Schellong]

FORTSETZUNG:

unsigned char sw;
//...
sw-='#'; //35
if (sw > '|'-'#') goto DFLT; //89=124-35

goto table[sw*8];

const unsigned char table[90*8]= {
CASE0 , //je 8 Byte
DFLT ,
DFLT ,
CASE3 ,
DFLT ,
DFLT ,
//...
CASE89
};

DFLT: /*...*/ goto SWEND;
CASE0: /*...*/ goto SWEND;
CASE3: /*...*/ goto SWEND;
//...
CASE89: /*...*/ goto SWEND;
SWEND: /*...*/ ;

Wie vorstehend kann man sich eine switch-Umsetzung
durch einen C-Compiler vorstellen.
# ist das wertniedrigste Zeichen im case, | das werthöchste.
Wenn C ein indirektes goto hätte, könnte man in C
selbst eine Sprungtabelle bauen.

Ich habe mir gcc5 installiert.
Und siehe da, er macht grundsätzlich Sprungtabellen.
Auch bei abgeschalteter Optimierung -O0 !
So muß es auch sein.

clang machte bei 8 switches null Sprungtabellen.
Auch bei -O2 nicht.
Er zog gigantische cmp-jx-jmp-Gefrickel vor.
Eine einzige Tabelle machte clang, nachdem ich einen
durchgehenden case-Wertabstand von 1 herstellte.
Ein durchgehender Wertabstand von 4 genügte ihm nicht.
gcc macht da einfach sw>>=2; vor dem *jump.

Ich bewerte dieses Verhalten von clang quasi als Bug.

[Thomas Koenig]

Post by Helmut Schellong
Wenn C ein indirektes goto hätte, könnte man in C
selbst eine Sprungtabelle bauen.

Naja, ist nicht gerade ein tolles Sprachelement, aber
trotzdem mal 'ne Herausforderung:

Kann man in portablem C eine Sprungtabelle mit setjmp()
und longjmp() hinkriegen?

Wenn es den IOCC noch gäbe, wäre das sicher ein gutes
Stilmittel.

[Rainer Weikusat]

Post by Thomas Koenig

Post by Helmut Schellong
Wenn C ein indirektes goto hätte, könnte man in C
selbst eine Sprungtabelle bauen.

Naja, ist nicht gerade ein tolles Sprachelement, aber
Kann man in portablem C eine Sprungtabelle mit setjmp()
und longjmp() hinkriegen?

Nicht eben nuetzlich und auch nicht ernsthaft unverstaendlich:

#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
jmp_buf jmps[4];
int in;
volatile int found;

in = atoi(argv[1]);
if (in > 3 || in < 0) {
fputs("Mach's selbst!\n", stderr);
exit(-127);
}

do {
if (!setjmp(*jmps))
if (!setjmp(jmps[1]))
if (!setjmp(jmps[2]))
if (!setjmp(jmps[3])) break;
else found = 3;
else found = 2;
else found = 1;
else found = 0;
goto out;
} while (0);

longjmp(jmps[in], 1);

out:
printf("Es war die %d.\n", found);
return 0;
}

[Rainer Weikusat]

[...]

Post by Rainer Weikusat

Post by Thomas Koenig
Kann man in portablem C eine Sprungtabelle mit setjmp()

[...]

Post by Rainer Weikusat
do {
if (!setjmp(*jmps))
if (!setjmp(jmps[1]))
if (!setjmp(jmps[2]))
if (!setjmp(jmps[3])) break;
else found = 3;
else found = 2;
else found = 1;
else found = 0;
goto out;
} while (0);
longjmp(jmps[in], 1);

Aus dem Kopf bin ich mir ueber Konformitaet nicht sicher aber ich finde
es netter:

#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
jmp_buf jmps[4];
int in;
volatile int found;

in = atoi(argv[1]);
if (in > 3 || in < 0) {
fputs("Das ist jenseits allen Zumutbarens.\n", stderr);
exit(-127);
}

setjmp(*jmps) && (found = 0,1)
|| setjmp(jmps[1]) && (found = 1)
|| setjmp(jmps[2]) && (found = 2)
|| setjmps(jmps[3]) && (found = 3)
|| longjmp(jmps[in], 1);

printf("Es war die %d.\n", found);
return 0;
}

Strukturiert programmiert da frei von gotos!

[Rainer Weikusat]

Post by Rainer Weikusat
[...]

Post by Thomas Koenig
Kann man in portablem C eine Sprungtabelle mit setjmp()

[...]

Post by Rainer Weikusat
setjmp(*jmps) && (found = 0,1)
|| setjmp(jmps[1]) && (found = 1)
|| setjmp(jmps[2]) && (found = 2)
|| setjmps(jmps[3]) && (found = 3)
|| longjmp(jmps[in], 1);

Als
setjmp(*jmps) && (found = 0,1)
|| setjmp(jmps[1]) && (found = 1)
|| setjmp(jmps[2]) && (found = 2)
|| setjmp(jmps[3]) && (found = 3)
|| (longjmp(jmps[in], 1),0);

laesst es sich auch tatsaechlich uebersetzen, wenigstens mit gcc 4.7.2,
und funktioniert wie beabsichtigt.

[Helmut Schellong]

Post by Thomas Koenig

Post by Helmut Schellong
Wenn C ein indirektes goto hätte, könnte man in C
selbst eine Sprungtabelle bauen.

Naja, ist nicht gerade ein tolles Sprachelement, aber
Kann man in portablem C eine Sprungtabelle mit setjmp()
und longjmp() hinkriegen?

Diese Funktionen haben eine ganz andere Verwendungsintention.
Trotzdem kann man vieles irgendwie hinkriegen.
Es wäre hier aber grottenschlecht hinsichtlich Performance.

Ich verwende goto; aber goto auch noch ausbauen und besonders
fördern - das muß nicht sein.
Es ist Aufgabe des Compilers, Sprungtabellen zu kreieren.
Pech hat man, wenn der das nicht tut.

[Helmut Schellong]

FORTSETZUNG2:

static byte rng[3][7]= {
{ RNGG_vb, RNGG_vB, RNGG_VB, RNGG_vU, RNGG_VU, RNGG_f, RNGG_F },
{ RNGL_vb, RNGL_vB, RNGL_VB, RNGL_vU, RNGL_VU, RNGL_f, RNGL_F },
{ RNGP_vb, RNGP_vB, RNGP_VB, RNGP_vU, RNGP_VU, RNGP_f, RNGP_F } };

clang legt ein statisches Objekt an.

byte rng[3][7]= {
clang legt ein statisches Objekt an.

auto byte rng[3][7]= {
clang legt ein statisches Objekt an.

gcc legt nur mit 'static' ein statisches Objekt an.
Andernfalls initialisiert er einzeln im Stack.

[Helmut Schellong]

Post by Helmut Schellong
static byte rng[3][7]= {
{ RNGG_vb, RNGG_vB, RNGG_VB, RNGG_vU, RNGG_VU, RNGG_f, RNGG_F },
{ RNGL_vb, RNGL_vB, RNGL_VB, RNGL_vU, RNGL_VU, RNGL_f, RNGL_F },
{ RNGP_vb, RNGP_vB, RNGP_VB, RNGP_vU, RNGP_VU, RNGP_f, RNGP_F } };
clang legt ein statisches Objekt an.
byte rng[3][7]= {
clang legt ein statisches Objekt an.
auto byte rng[3][7]= {
clang legt ein statisches Objekt an.
gcc legt nur mit 'static' ein statisches Objekt an.
Andernfalls initialisiert er einzeln im Stack.

Ich vergaß: Innerhalb einer Funktion!

Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.

[Jens Schweikhardt]

Helmut Schellong <***@schellong.biz> wrote
in <mmlpbh$esk$***@solani.org>:
# On 06/27/15 10:40, Helmut Schellong wrote:
#> On 06/26/15 20:15, Helmut Schellong wrote:
#>> On 06/26/15 13:03, Rainer Weikusat wrote:
#>>> Helmut Schellong <***@schellong.biz> writes:
#>
#> FORTSETZUNG2:
#>
#> static byte rng[3][7]= {
#> { RNGG_vb, RNGG_vB, RNGG_VB, RNGG_vU, RNGG_VU, RNGG_f, RNGG_F },
#> { RNGL_vb, RNGL_vB, RNGL_VB, RNGL_vU, RNGL_VU, RNGL_f, RNGL_F },
#> { RNGP_vb, RNGP_vB, RNGP_VB, RNGP_vU, RNGP_VU, RNGP_f, RNGP_F } };
#>
#> clang legt ein statisches Objekt an.
#>
#> byte rng[3][7]= {
#> clang legt ein statisches Objekt an.
#>
#> auto byte rng[3][7]= {
#> clang legt ein statisches Objekt an.
#>
#> gcc legt nur mit 'static' ein statisches Objekt an.
#> Andernfalls initialisiert er einzeln im Stack.
#
# Ich vergaß: Innerhalb einer Funktion!
#
# Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.

Nur wenn tatsächlich Rekursion im Programm mit dieser Funktion auftritt.

Regards,

Jens

[Helmut Schellong]

[...]

Post by Jens Schweikhardt
#> auto byte rng[3][7]= {
#> clang legt ein statisches Objekt an.
#>
#> gcc legt nur mit 'static' ein statisches Objekt an.
#> Andernfalls initialisiert er einzeln im Stack.
#
# Ich vergaß: Innerhalb einer Funktion!
#
# Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.
Nur wenn tatsächlich Rekursion im Programm mit dieser Funktion auftritt.

Ja, das funktioniert dann nicht; da das Objekt nicht const ist.

Allerdings ein Bug ist es auf jeden Fall, da dies Verhalten
absolut eindeutig gegen den C-Standard verstößt:

An object whose identifier is declared with no linkage and without
the storage-class specifier static has automatic storage duration,

Ein C-Compiler, der das nicht befolgt, ist ...

[Peter J. Holzer]

Post by Helmut Schellong
[...]

Post by Jens Schweikhardt
#> auto byte rng[3][7]= {
#> clang legt ein statisches Objekt an.
#>
#> gcc legt nur mit 'static' ein statisches Objekt an.
#> Andernfalls initialisiert er einzeln im Stack.
#
# Ich vergaß: Innerhalb einer Funktion!
#
# Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.

Hast Du das ausprobiert?

Post by Helmut Schellong

Post by Jens Schweikhardt
Nur wenn tatsächlich Rekursion im Programm mit dieser Funktion auftritt.

Ja, das funktioniert dann nicht; da das Objekt nicht const ist.
Allerdings ein Bug ist es auf jeden Fall, da dies Verhalten
An object whose identifier is declared with no linkage and without
the storage-class specifier static has automatic storage duration,
Ein C-Compiler, der das nicht befolgt, ist ...

... standard-konform. Der Code muss sich nur so verhalten, als ob er
einen Speicherbereich anlegt und beim Verlassen der Funktion wieder
freigibt. Er muss es nicht wirklich tun. Da Du uns den Rest der
Funktion nicht gezeigt hast, nehme ich schwer an, dass sich Deine
Funktion genau gleich verhält, ob der Compiler nun ein Array am Stack
anlegt oder nicht.

Z.B.:


int f(int a, int b) {
int x[3][7] = {
{ 11, 12, 13, 14, 15, 16, 17, },
{ 21, 22, 23, 24, 25, 26, 27, },
{ 31, 32, 33, 34, 35, 36, 37, },
};
return x[a][b];
}

Gcc (4.9.2 für i386) legt hier ein statisches Array mit den Werten an
und beim Aufruf ein automatisches am Stack, das (mittels rep movsl) mit
einer Kopie des statischen Arrays befüllt wird.

Clang (3.5.0) merkt hier offenbar, dass die Kopie völlig unnötig ist,
weil die Funktion die Werte des Arrays nie ändert und es auch keinen
standardkonformen Weg gibt, wie sie von außerhalb geändert werden
könnten. Also wird die Kopie weggelassen und der Code greift direkt auf
die "Vorlage" zu.

Wenn ich das Array aber innerhalb der Funktion ändere (und die Änderung
nicht so trivial ist, dass sie der Optimizer rückgängig machen kann),
dann funktioniert das nicht mehr:

int g(int a, int b) {
int x[3][7] = {
{ 11, 12, 13, 14, 15, 16, 17, },
{ 21, 22, 23, 24, 25, 26, 27, },
{ 31, 32, 33, 34, 35, 36, 37, },
};
for (int i = 0; i < a; i++) {
for (int j = 0; j < b; j++) {
x[i][j]++;
}
}
int s = 0;
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 7; j++) {
s += x[i][j];
}
}
return s;
}

Hier legt auch clang einen Bereich am Stack an und kopiert das statische
Array mittels rep movsl in diesen Bereich.

hp

[Helmut Schellong]

Post by Peter J. Holzer

[...]

Post by Jens Schweikhardt
#> auto byte rng[3][7]= {
#> clang legt ein statisches Objekt an.
#>
#> gcc legt nur mit 'static' ein statisches Objekt an.
#> Andernfalls initialisiert er einzeln im Stack.
#
# Ich vergaß: Innerhalb einer Funktion!
#
# Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.

Hast Du das ausprobiert?

[...]

Nein. Ich hatte erst static const dort stehen.
Ich weiß seit Jahrzehnten, wie andere Compiler
ein initialisiertes auto-Objekt übersetzen, und
wollte mal sehen, wie clang das macht.

Und ich sah, daß er Automatic storage duration
nicht realisierte.
Ich weiß nicht, ob das 'Verhalten, so als ob'
wirklich allumfassend ist. ... (werde ich mal prüfen)

Vorgestellt habe ich mir durchaus, daß clang beispielsweise
bei einem rekursiven Aufruf anders übersetzen könnte.
Ein rekursiver Aufruf kann aber durch beliebig viele andere
Funktionen hindurch erfolgen, die auch extern sein können.

clang müßte folglich pauschal bei jedem Detail, das irgendwie
außerhalb der Funktion liegt, auto realisieren.
Bei jeglichem Funktionsaufruf, bei jeglicher &-Verwendung, etc.

Das ist durchaus eine feine Optimierung von clang.
Umso erschrockener bin ich, daß er partout keine
Sprungtabellen anlegen will.
Das ist wichtiger für mich.

return glp+foo(rng[1]);

Vorstehend ein Funktionsaufruf einer externen Funktion,
der eine Adresse aus dem Array auto char rng[3][7] übergeben wird.
clang legt dennoch EIN statisches Array an!
Beide Funktionen haben Linkage.

gcc5:
movb $14, 96(%rsp) #, rng
movb $15, 97(%rsp) #, rng
movb $16, 98(%rsp) #, rng
movb $17, 99(%rsp) #, rng
...

[Helmut Schellong]

[...]

Post by Helmut Schellong
return glp+foo(rng[1]);

Ich war zu hastig.
Er kopiert das statische Array auf den Stack.

return glp+Foo();
Er benutzt nur das statische Array.

[Rainer Weikusat]

Post by Helmut Schellong
[...]

Post by Helmut Schellong
return glp+foo(rng[1]);

Ich war zu hastig.
Er kopiert das statische Array auf den Stack.
return glp+Foo();
Er benutzt nur das statische Array.

Ich halte das trotzdem fuer problematisch: 'automatich storage duration'
ist die einzige Form von automatischer Ressourcenverwaltung, die C
kennt, und 'ueblicherweise' versteht man darunter, dass fuer ein Objekt
ausserhalb seiner Lebensdauer kein Speicher reserviert ist. Eine
Implementierung, die alle auto-Objekte jedesmal via malloc neuerzeugt
und die alten Zeiger wegwirft, waere zwar vollkommen standard-konform,
aber einen Nutzen haette 'auto' dann nicht mehr. Wenigstens sollte man
diese Verhalten abstellen koennen.

[Helmut Schellong]

Post by Rainer Weikusat

Post by Helmut Schellong
[...]

Post by Helmut Schellong
return glp+foo(rng[1]);

Ich war zu hastig.
Er kopiert das statische Array auf den Stack.
return glp+Foo();
Er benutzt nur das statische Array.

Ich halte das trotzdem fuer problematisch: 'automatich storage duration'
ist die einzige Form von automatischer Ressourcenverwaltung, die C
kennt, und 'ueblicherweise' versteht man darunter, dass fuer ein Objekt
ausserhalb seiner Lebensdauer kein Speicher reserviert ist. Eine
Implementierung, die alle auto-Objekte jedesmal via malloc neuerzeugt
und die alten Zeiger wegwirft, waere zwar vollkommen standard-konform,
aber einen Nutzen haette 'auto' dann nicht mehr. Wenigstens sollte man
diese Verhalten abstellen koennen.

Dem stimme ich zu.
clang erzeugt ein Objekt mit Programmlebensdauer, und definitiv
keine 'automatic storage duration'.

For such an object ..., its lifetime extends from entry into the block
with which it is associated until execution of that block ends
in any way. ... If the block is entered recursively, a new instance
of the object is created each time. The initial value of the object is
indeterminate. If an initialization is specified for the object, it is
performed each time the declaration ... is reached in the execution
of the block; otherwise, the value becomes indeterminate each time
the declaration is reached.

Die vorstehende Beschreibung 'stimmt' nicht mehr.
Das 'So wirken als ob' wird hier doch stark strapaziert.
Warum macht's gcc nicht so?
clang sollte lieber 'switch' besser optimieren.

Ein 'Stack' muß für 'auto' nicht vorhanden sein; das ist bekannt.

[Peter J. Holzer]

Post by Rainer Weikusat

Post by Helmut Schellong
Ich war zu hastig.
Er kopiert das statische Array auf den Stack.
return glp+Foo();
Er benutzt nur das statische Array.

Ich halte das trotzdem fuer problematisch: 'automatich storage duration'
ist die einzige Form von automatischer Ressourcenverwaltung, die C
kennt, und 'ueblicherweise' versteht man darunter, dass fuer ein Objekt
ausserhalb seiner Lebensdauer kein Speicher reserviert ist.

Das ist auch hier der Fall. Die Optimierung bewirkt, dass für das Objekt
auch innerhalb seiner Lebensdauer kein Speicher reserviert wird.

Zur Erinnerung hier nochmal mein Code:

int f(int a, int b) {
int x[3][7] = {
{ 11, 12, 13, 14, 15, 16, 17, },
{ 21, 22, 23, 24, 25, 26, 27, },
{ 31, 32, 33, 34, 35, 36, 37, },
};
return x[a][b];
}

Ein C-Compiler hat im wesentlichen zwei Möglichkeiten, das umzusetzen:

1) Er kann das Array 1:1 initialierieren (ich schreibe das jetzt in
Primitiv-C hin, damit wir uns nicht über Assembler-Syntax den Kopf
zerbrechen müssen):

int f(int a, int b) {
int x[21];
x[0] = 11;
x[1] = 12;
x[2] = 13;
...
x[20] = 37;

t1 = a * 7 + b;
t2 = x[t1];
return t2;
}

2) Er kann die Daten für das Array in einem statischen (read-only)
Bereich ablegen und beim Aufruf kopieren:

static int __x_init[21] = { 11, 12, 13, ... 37 };

int f(int a, int b) {
int x[21];
memcpy(x, __x_init, sizeof(x));

t1 = a * 7 + b;
t2 = x[t1];
return t2;
}

Beides braucht Platz, um die 21 Werte irgendwo dauerhaft abzulegen. Im
ersten Fall in Form von move-Instruktionen, im zweiten in Form eines
statischen Arrays (plus einem Aufruf von memcpy). Dieser Platz ist auf
jeden Fall für die Laufzeit des Programms belegt.

GCC verwendet die zweite Variante, und Clang prinzipiell auch.

Allerdings kommt jetzt bei Clang eine weitere Phase der Optimierung:
Der Compiler bemerk, dass nach dem memcpy __x_init und x den gleichen
Inhalt haben. Somit kann die Zuweisung an t2 durch t2 = __x_init[t1]
ersetzt werden:

static int __x_init[21] = { 11, 12, 13, ... 37 };

int f(int a, int b) {
int x[21];
memcpy(x, __x_init, sizeof(x));

t1 = a * 7 + b;
t2 = __x_init[t1];
return t2;
}

Jetzt wird aber keiner der Werte von x, die durch das memcpy kopiert
wurden, mehr gelesen, also können wir uns das sparen:

static int __x_init[21] = { 11, 12, 13, ... 37 };

int f(int a, int b) {
int x[21];

t1 = a * 7 + b;
t2 = __x_init[t1];
return t2;
}

Und damit wird x gar nicht mehr verwendet, also brauchen wir keinen
Platz dafür:

static int __x_init[21] = { 11, 12, 13, ... 37 };

int f(int a, int b) {

t1 = a * 7 + b;
t2 = __x_init[t1];
return t2;
}

Und damit ist die Optimierung abgeschlossen, das automatische Array x
ist wegoptimiert und es bleibt nur mehr der statische Initializer übrig.

hp

[Rainer Weikusat]

Post by Peter J. Holzer

Post by Rainer Weikusat

Post by Helmut Schellong
Ich war zu hastig.
Er kopiert das statische Array auf den Stack.
return glp+Foo();
Er benutzt nur das statische Array.

Ich halte das trotzdem fuer problematisch: 'automatich storage duration'
ist die einzige Form von automatischer Ressourcenverwaltung, die C
kennt, und 'ueblicherweise' versteht man darunter, dass fuer ein Objekt
ausserhalb seiner Lebensdauer kein Speicher reserviert ist.

Das ist auch hier der Fall. Die Optimierung bewirkt, dass für das Objekt
auch innerhalb seiner Lebensdauer kein Speicher reserviert wird.
int f(int a, int b) {
int x[3][7] = {
{ 11, 12, 13, 14, 15, 16, 17, },
{ 21, 22, 23, 24, 25, 26, 27, },
{ 31, 32, 33, 34, 35, 36, 37, },
};
return x[a][b];
}
1) Er kann das Array 1:1 initialierieren (ich schreibe das jetzt in
Primitiv-C hin, damit wir uns nicht über Assembler-Syntax den Kopf
int f(int a, int b) {
int x[21];
x[0] = 11;

[...]

Post by Peter J. Holzer
2) Er kann die Daten für das Array in einem statischen (read-only)
static int __x_init[21] = { 11, 12, 13, ... 37 };
int f(int a, int b) {
int x[21];
memcpy(x, __x_init, sizeof(x));
t1 = a * 7 + b;
t2 = x[t1];
return t2;
}
Beides braucht Platz, um die 21 Werte irgendwo dauerhaft abzulegen.

[...]

Post by Peter J. Holzer
Und damit wird x gar nicht mehr verwendet, also brauchen wir keinen
static int __x_init[21] = { 11, 12, 13, ... 37 };
int f(int a, int b) {
t1 = a * 7 + b;
t2 = __x_init[t1];
return t2;
}
Und damit ist die Optimierung abgeschlossen, das automatische Array x
ist wegoptimiert und es bleibt nur mehr der statische Initializer übrig.

Der 'statische Initialisierer' ist ein Feld der angeforderten Groesse,
dessen Inhalt mit dem des automatisch bei Eintritt einer Funktion
anzulegenden Feldes uebereinstimmt, mithin wird also fuer ein solches
Feld dauerhaft Platz reserviert. Es ist auch nicht richtig, dass die '21
Werte' dauerhaft irgendwo abgelegt werden muessen, denn sie koennten
aufeinander folgend berechnet werden. In jedem Falls ist das eine
praktisch vollkommen unrelevante Code-Transformation.

[Peter J. Holzer]

Es ist auch nicht richtig, dass die '21 Werte' dauerhaft irgendwo
abgelegt werden muessen, denn sie koennten aufeinander folgend
berechnet werden.

Theoretisch in manchen Fällen ja. In der Praxis wird das wohl kein
Compiler machen - wenn sich der Programmierer schon die Arbeit angetan
hat, die Werte zu berechnen und in seinen Source-Code einzufügen, ist es
ziemlich unsinnig, zu versuchen, aus den Werten diese Berechnung wieder
zu reverse-engineeren und zur Laufzeit durchzuführen.

hp

[Juergen Ilse]

Hallo,

Post by Rainer Weikusat

Post by Peter J. Holzer
Und damit ist die Optimierung abgeschlossen, das automatische Array x
ist wegoptimiert und es bleibt nur mehr der statische Initializer übrig.

Der 'statische Initialisierer' ist ein Feld der angeforderten Groesse,
dessen Inhalt mit dem des automatisch bei Eintritt einer Funktion
anzulegenden Feldes uebereinstimmt, mithin wird also fuer ein solches
Feld dauerhaft Platz reserviert.

Korrekt.

Post by Rainer Weikusat
Es ist auch nicht richtig, dass die '21 Werte' dauerhaft irgendwo abgelegt
werden muessen,

Jein. Im Endeffekt stehen sie in dann in dem Programmcode zur Initialisierung
des arrays.

Post by Rainer Weikusat
denn sie koennten aufeinander folgend berechnet werden. In jedem Falls ist
das eine praktisch vollkommen unrelevante Code-Transformation.

Im hier angesprochenen Fall ist evt. die benoetigte Menge fuer Speicherplatz
fuer den "statischen initalisierer" plus der benoetigten Menge an Speicher-
platz fuer den Programmcode zum kopieren der Daten womoeglich kleiner (oder
zumindest nicht groesser) als der Programmcode zum jeweils einzeln initiali-
sieren aller array-Elemente.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Peter J. Holzer]

Eine Implementierung, die alle auto-Objekte jedesmal via malloc
neuerzeugt und die alten Zeiger wegwirft, waere zwar vollkommen
standard-konform, aber einen Nutzen haette 'auto' dann nicht mehr.

Du schweifst da jetzt ziemlich vom Thema ab, aber ich schweife halt mit:

Es hätte natürlich nach wie vor einen Nutzen: Der Compiler kümmert sich
um den Aufruf vom malloc und free und der Benutzer muss das nicht
machen.

Ich bin mir übrigens ziemlich sicher, dass es Plattformen gibt oder gab,
auf denen Stackframes tatsächlich mittels einer allgemeinen
Allokationsfunktion alloziert werden und nicht einfach linear von einm
vorallozierten Speicherbereich abgeknapst werden. Ich glaube, dass das
sogar bei einer der moderneren Bufferoverflow-Verhütungstechniken der
Fall ist, müsste aber erst danach suchen.

hp

[Rainer Weikusat]

Post by Peter J. Holzer

Eine Implementierung, die alle auto-Objekte jedesmal via malloc
neuerzeugt und die alten Zeiger wegwirft, waere zwar vollkommen
standard-konform, aber einen Nutzen haette 'auto' dann nicht mehr.

Es hätte natürlich nach wie vor einen Nutzen: Der Compiler kümmert sich
um den Aufruf vom malloc und free und der Benutzer muss das nicht
machen.

Von 'free' hatte ich allerdings absichtlich nichts geschrieben.

[Jens Schweikhardt]

Helmut Schellong <***@schellong.biz> wrote
in <mmmljk$o56$***@solani.org>:
# On 06/27/15 18:37, Jens Schweikhardt wrote:
#> Helmut Schellong <***@schellong.biz> wrote
# [...]
#> #> auto byte rng[3][7]= {
#> #> clang legt ein statisches Objekt an.
#> #>
#> #> gcc legt nur mit 'static' ein statisches Objekt an.
#> #> Andernfalls initialisiert er einzeln im Stack.
#> #
#> # Ich vergaß: Innerhalb einer Funktion!
#> #
#> # Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.
#>
#> Nur wenn tatsächlich Rekursion im Programm mit dieser Funktion auftritt.
#
# Ja, das funktioniert dann nicht; da das Objekt nicht const ist.

Das kann so non-const sein, wie es will. WENN der Compiler
feststellen kann, dass es nicht verändert wird, kann er es
genau einmal anlegen, wo es ihm beliebt.

# Allerdings ein Bug ist es auf jeden Fall, da dies Verhalten
# absolut eindeutig gegen den C-Standard verstößt:
#
# An object whose identifier is declared with no linkage and without
# the storage-class specifier static has automatic storage duration,
#
# Ein C-Compiler, der das nicht befolgt, ist ...

...vermutlich schlau. Es steht nirgends geschrieben, dass automatic
storage duration gleichbedeutend ist mit "liegt auf dem Stack".
Wenn der Code die vom Standard vorgeschriebene Semantik hat, ist
alles in Ordnung.

Kannst Du ein minimales vollständiges kompilierbares Beispiel angeben,
wo der Fehler auftritt, d.h. die lokale Variable in einer *rekursiv*
aufgerufenen Funktion nur einmal angelegt wird? Ich kann mir vorstellen,
clang analysiert das Vorhandensein von Rekursion und erzeugt ggfs.
anderen Code.

Regards,

Jens

[Peter J. Holzer]

Post by Jens Schweikhardt
# [...]
#> #> auto byte rng[3][7]= {
#> #> clang legt ein statisches Objekt an.
#> #>
#> #> gcc legt nur mit 'static' ein statisches Objekt an.
#> #> Andernfalls initialisiert er einzeln im Stack.
#> #
#> # Ich vergaß: Innerhalb einer Funktion!
#> #
#> # Das ist ein Bug, u.a. da Rekursivität nicht funktioniert.
#>
#> Nur wenn tatsächlich Rekursion im Programm mit dieser Funktion auftritt.

[...]

Post by Jens Schweikhardt
Kannst Du ein minimales vollständiges kompilierbares Beispiel angeben,
wo der Fehler auftritt, d.h. die lokale Variable in einer *rekursiv*
aufgerufenen Funktion nur einmal angelegt wird? Ich kann mir vorstellen,
clang analysiert das Vorhandensein von Rekursion und erzeugt ggfs.
anderen Code.

#include <stdio.h>

int f(int a, int b) {
int x[3][7] = {
{ 11, 12, 13, 14, 15, 16, 17, },
{ 21, 22, 23, 24, 25, 26, 27, },
{ 31, 32, 33, 34, 35, 36, 37, },
};
if (b > 0) {
return f(a, b-1) + x[a][b];
} else if (a > 0) {
return f(a-1, b) + x[a][b];
} else {
return x[0][0];
}
}

int main(void) {
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 7; j++) {
printf("%d %d %3d\n", i, j, f(i, j));
}
}
return 0;
}

Es ist aber auch in diesem Fall kein Fehler, da das Ergebnis genau das
gleiche ist.

Interessanterweise führt clang diese Optimierung nicht durch, wenn man
ihn mit -std=c11 aufruft, obwohl meines Erachtens nichts im Standard
diese Optimierung verbietet.

hp

[Helmut Schellong]

On 06/24/15 21:21, Helmut Schellong wrote:
[...]

Post by Helmut Schellong
Schnelle Kompilierung.
Vorzügliche Ausgabe von Meldungen (error, warning, etc.).
Weitgehende Beherrschung von C11!

gcc5: 6,8 s
clang: 2,3 s

Beide -O1
Die Geschwindigkeit von clang ist das Dreifache.

[Helmut Schellong]

Post by Helmut Schellong
[...]

Post by Helmut Schellong
Schnelle Kompilierung.
Vorzügliche Ausgabe von Meldungen (error, warning, etc.).
Weitgehende Beherrschung von C11!

gcc5: 6,8 s
clang: 2,3 s
Beide -O1
Die Geschwindigkeit von clang ist das Dreifache.

Ich habe jetzt Geschwindigkeitsmessungen gemacht.
Beispiel:
3.460u 0.000s 0:03.47 99.7% 759+469k 0+0io 0pf+0w
Loop 10000000

Sehr interessant!:
gcc5 4.98 3.70 3.54 3.4 bei -O0 -O1 -O2 -O3
clang 6.85 3.45 3.76 3.7 bei -O0 -O1 -O2 -O3

clang ist also in der Summe besser, bei -O1,
meiner Standard-Opt seit Jahrzehnten.
Aber nur, wenn man bei switch() die Konzepte so
wählt, daß die case-Werte je um 1 steigen!

7.024u 0.000s 0:07.03 99.8% 757+467k 0+0io 0pf+0w

Das Tempo halbiert sich, wenn das nicht getan wird!
(Ich habe hier alle case-Werte um 4 steigen lassen.)

Ich hatte also absolut Recht mit meiner Meckerei.
Sprungtabellen wegzulassen ergibt ganz miserable
Programm-Performance!

[Helmut Schellong]

Post by Helmut Schellong
Ich habe jetzt Geschwindigkeitsmessungen gemacht.
3.460u 0.000s 0:03.47 99.7% 759+469k 0+0io 0pf+0w
Loop 10000000

[...]

Es geht weiter:

C-Quelle:
memset(&o, 0, sizeof(o)); //size=32

gcc5:
movq $0, 136(%rsp)
movq $0, 128(%rsp)
movq $0, 144(%rsp)
movq $0, 152(%rsp)

clang:

xorl %eax, %eax
movq %rax, -869392(%rbp)
movq %rax, -869352(%rbp)
movl $0, %eax
movq %rax, -869408(%rbp)
movl $0, %eax
movq %rax, -869368(%rbp)
movl $0, %eax
movq %rax, -869512(%rbp)
movl $0, %eax
movq %rax, -869568(%rbp)
movl $0, %eax
movq %rax, -869432(%rbp)
movl $0, %edx
movl $0, %eax
movq %rax, -869448(%rbp)
movl $0, %eax
movq %rax, -869552(%rbp)
movl $0, %eax
movq %rax, -869400(%rbp)
movl $0, %eax
movq %rax, -869560(%rbp)
movl $0, %eax
movq %rax, -869416(%rbp)
movl $0, %eax
movq %rax, -869480(%rbp)

Es geht mir um die unsinnigen Wiederholungen von 'mov 0,eax'.
gcc macht das nicht, hat das noch nie getan.

Warum nimmt er nicht xor edx,edx ?
Zu Beginn macht er es doch optimal.
Die Konstanten brauchen viel Platz und dauern oft länger.

Ein Compiler von Fujitsu hatte das Jahrzehnte lang getan.
Fujitsu war stolz, eine entsprechende Optimierung zu berichten.

[Peter J. Holzer]

Post by Helmut Schellong
memset(&o, 0, sizeof(o)); //size=32
movq $0, 136(%rsp)
movq $0, 128(%rsp)
movq $0, 144(%rsp)
movq $0, 152(%rsp)
xorl %eax, %eax
movq %rax, -869392(%rbp)
movq %rax, -869352(%rbp)
movl $0, %eax
movq %rax, -869408(%rbp)
movl $0, %eax
movq %rax, -869368(%rbp)
movl $0, %eax
movq %rax, -869512(%rbp)
movl $0, %eax
movq %rax, -869568(%rbp)
movl $0, %eax
movq %rax, -869432(%rbp)
movl $0, %edx
movl $0, %eax
movq %rax, -869448(%rbp)
movl $0, %eax
movq %rax, -869552(%rbp)
movl $0, %eax
movq %rax, -869400(%rbp)
movl $0, %eax
movq %rax, -869560(%rbp)
movl $0, %eax
movq %rax, -869416(%rbp)
movl $0, %eax
movq %rax, -869480(%rbp)
Es geht mir um die unsinnigen Wiederholungen von 'mov 0,eax'.
gcc macht das nicht, hat das noch nie getan.

clang (3.5) bei mir auch nicht:

init_o: # @init_o
.cfi_startproc
# BB#0:
xorps %xmm0, %xmm0
movaps %xmm0, o+16(%rip)
movaps %xmm0, o(%rip)
retq
.Ltmp0:
.size init_o, .Ltmp0-init_o
.cfi_endproc

Aber Dein Code stammt offensichtlich aus einer längeren Funktion: Da
werden insgesamt 13 8-Byte-Werte mit dem Inhalt von %rax überschrieben
(ist das überhaupt 0, wenn vorher nur ein xorl %eax,%eax und nicht ein
xorl %rax,%rax gemacht wird? Bin jetzt zu faul zum nachlesen) und nicht
nur 4. Also ist das nicht vergleichbar. Die wiederholten Zuweisungen an
ein Register, das sich dazwischen nicht ändern kann, sind aber
jedenfalls seltsam.

hp

[Helmut Schellong]

Post by Peter J. Holzer
Aber Dein Code stammt offensichtlich aus einer längeren Funktion: Da
werden insgesamt 13 8-Byte-Werte mit dem Inhalt von %rax überschrieben
(ist das überhaupt 0, wenn vorher nur ein xorl %eax,%eax und nicht ein
xorl %rax,%rax gemacht wird? Bin jetzt zu faul zum nachlesen) und nicht
nur 4. Also ist das nicht vergleichbar.

Höchstwahrscheinlich wird die obere Hälfte von %rax dadurch auch
gelöscht, weil diese obere Hälfte nicht separat adressierbar ist.
Man spart Opcode dadurch.

Post by Peter J. Holzer
Die wiederholten Zuweisungen an
ein Register, das sich dazwischen nicht ändern kann, sind aber
jedenfalls seltsam.

In der Tat.

Der clang benutzt intensiv xmmN, gcc macht das nicht.