GCC 3.4.0 Released - Page 1

From: Mark Mitchell <mark at codesourcery dot com>
To: gcc at gcc dot gnu dot org, gcc-announce at gcc dot gnu dot org
Date: Tue, 20 Apr 2004 21:44:17 -0700
Subject: GCC 3.4.0 Released
Organization: CodeSourcery, LLC

The GCC 3.4.0 release is now (or will soon be) available from the sites listed at:

http://www.gnu.org/order/ftp.html

This release contains a large number of new features relative to GCC 3.3.3 as well as over 900 fixes for defects in previous releases.

Visit:

http://gcc.gnu.org/gcc-3.4/changes.html

for a list of the changes in this release.

The GCC 3.4.1 will follow in approximately two months. It will contain only fixes for regressions in GCC 3.4.0 release to previous releases of GCC. The next major release of GCC (whose version number is still undecided) will be released in late 2004 or early 2005.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

-

Ouééé, encore une série de bêtas pour TIGCC en vue

J'avais prévu d'attendre TIGCC 0.96 Beta 1 pour GCC 3.4. La 0.95 finale est censée sortir dans très peu de temps normalement. Mais il pourrait y avoir quelques délais. Je vais discuter avec Sebastian avant de prendre une décision.

-

M'en fous. mechant
Je suis deja passe sous GCC 3.5 CVS depuis longtemps (au moins 1 mois) . Il plante bien #yes#, mais produit quand meme du code + joli a lire en asm.
(Plus serieusement, j'ai toujours d'installer GCC 2.95, 2.96, 3.0, 3.1, 3.2, 3.3.2, 3.3.3, 3.4-1, 3.4-2, 3.4-3, GCC 3.5-1, GCC 3.5-2
Et je vais pouvoir simplifer les versions 3.4 en une seule ).

Ce qui est pas mal dans la 3.4, c'est le nombre accru de fonctions builtin !
Et les headers precompiles en C++, mais il parait que c'est tres difficile d'utilisation et limite inutile (c'est pas moi qui ai fait le test).
Par contre, elle produit du code moins efficace pour x86 (Comme la 3.3 produisait du code - efficace que la 3.2).

Par contre, ce qui sera c'est que GCC calculera les constantes mathematiques en compile time:
x = sin(0.152);
sera evalue statiquement (Ce qui pose des problemes de mode d'arrondi).

Question:
On peut plus utilise ansi2knr pour compiler GCC ?

PpHd
: Je suis deja passe sous GCC 3.5 CVS

Sauter 3.4 et passer directement à 3.5-tree-ssa est aussi une option pour TIGCC. Mais je pense quand-même qu'il sera plus simple de faire le portage étape par étape, sinon je ne vais plus m'en sortir.

Ce qui est pas mal dans la 3.4, c'est le nombre accru de fonctions builtin !

Désolé, je serai obligé d'en désactiver la plupart pour TIGCC (comme je le fais déjà actuellement), parce qu'il n'y a pas d'implémentation pour notre format de flottants. Sauf si tu m'envoies un patch avec cette implémentation en un état intégrable à notre GCC (c'est-à-dire du C GNU portable avec les bons prototypes - je me contrefiche des trucs du style conventions de formatage, compilabilité avec non-GCC etc.)...

Par contre, elle produit du code moins efficace pour x86 (Comme la 3.3 produisait du code - efficace que la 3.2).

Il est plus petit au moins, le code? Je me contrefiche de la vitesse.

Je conseille fortement de garder GCC 3.3 car GCC 3.4 casse certains build...
Car il veut que dans la declaration et dans la definition, le prototype de la fonction soit le meme (Avec les regparms)...

Legerement moins efficace, la taille je ne me souvient plus.

Car il veut que dans la declaration et dans la definition, le prototype de la fonction soit le meme (Avec les regparms)...

Euh, ça me paraît normal, ça...

Sinon si tu regardes les bugs corrigés dans GCC 3.4 (http://gcc.gnu.org/bugs.html#known), tu te dis qu'il faut upgrader au plus vite (si tu veux développer des progs, pas si tu veux compiler des progs existants) :

Parse errors for "simple" code.

GCC gave parse errors for seemingly simple code, such as

struct A
{
  A();
  A(int);
};

struct B
{
  B(A);
  B(A,A);
  void foo();
};

A bar()
{
  B b(A(),A(1));  // Variable b, initialized with two temporaries
  B(A(2)).foo();  // B temporary, initialized with A temporary
  return (A());   // return A temporary
}

Ca fait assez peur, comme bug

ah? legerement moins efficace? j'ai lu sur gnu.org que la vitesse d'exec des progs compiles avec la 3.4 augmentait de 6-7% en moyenne sur x86 (ca m'a paru bcp qd meme )
t'as teste sur quoi?

./9: C'est du C++.
./10: Sur les progs que je developpe.

et c'est quoi comme genre de progs que tu developpe?

Des progs qui mettent 20h a finir sur un bi-opteron 2.3Ghz avec 8G de RAM, en optimisation max, avec des algorithmes optimaux, une implantation de qualite et en utilisant a fond l'architecture 64 bits.
Pkoi?
(Remarque il est l'opteron. Sur un P4 3Ghz, c'est au moins 80h de calcul ).

PpHd :
Pkoi?

juste pke il peut sans doute optimiser mieux certains trucs que d'autres, et si les trucs critiques point de vue perfs sont tres particuliers dans ce que tu fais c'est ptetre normal (ou si t'optimise a la main en asm les parties critiques )

"Des progs qui mettent 20h"
t1 c'est lent...

>t1 c'est lent...
Bof tu sais, il y a meme pas 1 an, ca aurait ininvisageable de faire ce programme. Alors. 20h c'est peu (Ben en fait, 20h c'est un probleme simplifie qui me permet de me roder avant de lancer le vrai calcul qui devrait durer plus de 10000h).

Mais si tu veux, je peux faire un bench.

non c'est bon

lol 10000 heures...
et au bout de 9990 heures... coupure de courant

Et c'est censé être utile, au moins ?

nan nan, ca determine juste la probabilite pour que la tartine tombe du cote beurre.

mais attention, c'est généralisable à toutes les pièces de monnaie de tous les pays d'europe en fonction deur face variable par nation !

./19: Non, c'est bon. Le programme peut rendre la ou il en etait.
./20: Oui c'est utile.

Resultat d'un bench comparatif entre les differentes versions de GCC.
Finalement la 3.4 est pas si mauvaise (Je retire ce que j'ai dit) :
(Athlon 1.7Ghz / -O2 )

GCC 2.95:
 add: 83 / 141.56 / 178
 sub: 107 / 154.18 / 178
 mul: 181 / 194.21 / 214
 div: 402 / 425.18 / 449
 sqrt: 818 / 879.01 / 972
 cmp: 26 / 29.70 / 43
 sgn: 6 / 9.43 / 10
 set: 42 / 43.85 / 44
 set0: 18 / 18.52 / 19
 set1: 70 / 70.98 / 71
 swap: 24 / 24.00 / 24

GCC 3.2.3:
 add: 83 / 136.01 / 172
 sub: 97 / 145.09 / 169
 mul: 166 / 180.55 / 202
 div: 385 / 407.98 / 432
 sqrt: 796 / 849.43 / 933
 cmp: 28 / 30.17 / 40
 sgn: 6 / 8.96 / 10
 set: 40 / 41.19 / 42
 set0: 18 / 19.46 / 20
 set1: 67 / 67.38 / 68
 swap: 24 / 24.00 / 24

GCC 3.3.2:
 add: 83 / 133.58 / 168
 sub: 100 / 145.13 / 165
 mul: 165 / 177.49 / 196
 div: 385 / 406.32 / 428
 sqrt: 802 / 850.36 / 926
 cmp: 30 / 30.75 / 44
 sgn: 6 / 9.53 / 10
 set: 42 / 42.88 / 43
 set0: 18 / 19.77 / 20
 set1: 65 / 65.00 / 65
 swap: 24 / 24.00 / 24

GCC 3.4:
 add: 78 / 125.89 / 166
 sub: 86 / 137.01 / 167
 mul: 168 / 179.33 / 198
 div: 373 / 394.68 / 419
 sqrt: 790 / 839.35 / 917
 cmp: 23 / 24.08 / 29
 sgn: 6 / 9.47 / 10
 set: 35 / 37.89 / 39
 set0: 16 / 17.10 / 18
 set1: 59 / 59.80 / 60
 swap: 24 / 24.00 / 24

GCC 3.5 (CVS version du 20040327):
 add: 76 / 122.86 / 161
 sub: 85 / 133.32 / 159
 mul: 168 / 180.18 / 198
 div: 373 / 395.52 / 419
 sqrt: 784 / 830.93 / 907
 cmp: 23 / 24.58 / 29
 sgn: 9 / 9.93 / 10
 set: 35 / 35.98 / 36
 set0: 16 / 17.35 / 18
 set1: 62 / 62.96 / 63
 swap: 23 / 23.89 / 24

Resultats en cycles: MIN / MOY / MAX. (mais chaque resultat est filtre par un filtre passe bas).

ma question n'était pas tellement de savoir si ct utile (je me doute bien que ça l'est ), mais de savoir de quoi ça parlait Cela dit, c'est peut-être top secret ^^

Tu devrais aussi tester tree-ssa. (Ça n'a pas encore été intégré à la 3.5 du CVS HEAD.)

Non, c'est top secret car sinon vous vous rendrez compte que j'ai exagere

./26: Ok. Laissez moi le temps de le compiler

Compilation faite, mais GCC-TREE-SSA est trop instable. Je peux pas compiler mon programme sans obtenir des internal errors.