#include <cstdlib>
#include <iostream>
// Liste an Kompilezeit-Konstanten (in der "richtigen" Reihenfolge)
static const double c0 = 65.6758;
static const double c1 = 90.9146;
static const double c2 = 45.5458;
//..
static const double c511 = 54.6342;

void f(double *p)
{
	p[0] *= c0;
	p[1] *= c1;
	p[2] *= c2;
//...
	p[511] *= c511;
}

int main()
{
	double arr[512];
	for(int i=0; i!=512; ++i)
		arr[i] = (100.*std::rand())/RAND_MAX;

	f(arr);

	for(int i=0; i!=512; ++i)
		std::cout<<arr[i];
}

Das Problem: Clang und VS13 vektorisieren den Code, nur der gcc scheitert:

Clang 3.4 mit -mtune=native -march=native -Ofast: http://goo.gl/tLpIQ5
g++ 4.8 mit -mtune=native -march=native -Ofast: http://goo.gl/jfC74j
VS2013 mit /fp:fast /arch:AVX2 /Ox /Ot: Vektorisiert auch, aber dafür gibts leider keinen online Code

Kann sich jemand vorstellen, was den gcc am vektorisieren hindert?

P.S.: Ich würde das Ganze gerne ohne Schleife lösen, weil es so meinem "realen" Problem näher kommt.

Ist klar, dass das im Prinzip eine geunrollte Schleife darstellen soll, aber das muss der Vektorisierer nicht wissen.

Vielleicht greift der Autovektorisierer vom GCC nur bei ausgeschriebenen Schleifen?

Diesen Eindruck habe ich auch.
Ausserdem sollte man sich noch um vernünftiges Alignment kümmern (bei clang scheint dass allerdings nicht zu helfen). http://goo.gl/tN4t8u
Aussgeschrieben dürfte der Spass allein schon wegen der Codegröße langsamer sein.
-ffast-math ist dagegen nicht erforderlich.

-ffast-math ist dagegen nicht erforderlich.

Warum, die Berechnung operiert doch mit Fließkommazahlen (laut dem Manual ist das Flag daher nötig)? Und -ffast-math wird doch durch -Ofast aktiviert?

Edit: Achso, man braucht es nur für Reduktionen, oder?