# wann wird gcc-3.4 endlich stable

## hakker82

der neue gcc ist schon lange maskiert.

hat jemand eine Ahnung, wann er demaskiert wird?

----------

## Aldo

Wenn er *alle* Programme die der 3.3.x übersetzt auch fehlerfrei übersetzen kann.

(Denke ich einfach mal)

----------

## hoschi

oder wenn alle programme so umgeschrieben wurden, dass sie fehlerfrei mit gcc 3.4 kompiliert werden können

----------

## deejay

ich benutze gcc-3.4 und so fehlerfrei ist das ding noch nicht....

ich glaube das wird noch nen moment dauern........

----------

## zielscheibe

Da der 3.4er gcc nun einmal restriktiver bei Schludrigkeiten im Programmcode ist, kann man dies  nicht als Argument gegen ihn verwenden, wenn ein Paket nicht durchkompiliert.

Man hat immer noch die Möglichkeit, die betreffenden ebuilds, durch umswitchen zum "alten" 3.3er zu kompilieren. Damit läßt sich sein Speedvorteil beim "backen" des Codes IMHO ohne Reue ausnutzen.

----------

## Regnaron

Ich für meinen Teil würde mich zwar auch darüber freuen wenn ich den GCC nicht mehr manuell demaskieren müsste, aber IMHO ist es so wie es aktuell ist besser. Denn mal ehrlich: Was wiegt schlimmer: Ein paar Prozent weniger Performance, oder ein Programm dass mit irgendeiner komischen Fehlermeldung abbricht? Ich denke eher diejenigen welche unbedingt den 3.4er nutzen wollen werden auch die Anleitungen finden wo beschrieben wird wie sie ihn nutzen können. Klar sollten kaputte Programme nicht ein Grund dafür sein dass bessere (strengere) Compiler zurückgehalten werden, (und sind ein Ärgerniss an sich) aber IMHO wiegt die Möglichkeit eines kaputten Systems schlimmer als die paar Prozent Geschwindigkeit durch den GCC... Das sollte zwar nicht ewig so gehen lassen, aber so extrem alt ist der GCC 3.4 auch noch nicht... Wurde ja gerade mal vor 6 Monaten released... Ein "bisschen" Zeit kann man also IMHO durchaus noch ins Land ziehen lassen.

----------

## Genone

Abgesehen davon produziert die 3.4er Version anscheinend auch kaputten sse2 Binärcode (weswegen sse2 auch durch das Ebuild generell deaktiviert wird).

----------

## Haldir

Ansonsten halt als zweit compiler installieren, aber stable is der net wirklich und es ist eine Sache Schludrigkeiten im Code anzumahnen oder gleich voll abzubrechen. Geschwindigkeitstechnisch bringt der jetzt auch nicht den Overkill (außer du schaltest wirklich alles ein und dann compiled fast nix mehr), viele größere Ebuilds strippen eh die meisten cflags...

----------

## Regnaron

 *Haldir wrote:*   

> es ist eine Sache Schludrigkeiten im Code anzumahnen oder gleich voll abzubrechen.

 

Hm, gehe ich recht in der Annahme das das ein "Angriff" auf den gcc werden sollte?  :Smile: 

Falls ja, muss ich dir widersprechen. Es gibt einen C++ Standard an den man sich halten kann, und wenn man sich an den gehalten hat, dann läuft das Programm auch unter dem gcc 3.4, und wird auch noch unter dem gcc 4.0 laufen. Ich weiß zwar nicht wie es bei den alten Versionen vom gcc war, aber ich denke mal dass die entsprechenden Konstrukte schon Warnungen geworfen haben, oder? Hier würde ich das ganze nämlich in der Tat schon für einen Fehler des Programmierers halten wenn dieser sich sagt: Och, der Compiler erzeugt eine executeable, also wird es schon passen. Die 100 Warnungen kann ich ja ignorieren oder ausschalten  :Wink:  (Die ganzen IE Optimierten Webseiten sind das gleiche in blau. Es gibt einen Standard, und wenn man sich an den hält, dann wird man auch mit der Ausführung des Codes in 5 Jahren noch keine Probleme haben. (es sei denn der Standard sollte sich auf einmal ändern...))

----------

## zappi

 *Haldir wrote:*   

> Ansonsten halt als zweit compiler installieren, aber stable is der net wirklich und es ist eine Sache Schludrigkeiten im Code anzumahnen oder gleich voll abzubrechen. Geschwindigkeitstechnisch bringt der jetzt auch nicht den Overkill (außer du schaltest wirklich alles ein und dann compiled fast nix mehr), viele größere Ebuilds strippen eh die meisten cflags...

 

Das mag für x86 gelten, allerdings für amd64 ist der 3.4.x ein großer Sprung nach vorne.

zappi

----------

## Haldir

Regnaron, der sog. Standard wird von jedem Compiler anders interpretiert (so würds wohl MS ausdrücken), trotzdem haben ältere Versionen nicht zwingend alles angemahnt was jetzt nicht mehr geht, teilweise auch weils sies nicht wußten  :Wink: . Grundsätzlich find ichs aber nett das du gleich an den C++ Standard denkst  :Razz: , mir ist halt teilweise insbesondere beim obj-c für OGo aufgefallen. (Welch ein Horror den mit 3.3 zu compilieren zu kriegen, kein Kommentar über 3.4  :Wink: )

Apropos für amd64, da gilt soweit ich das mitgekriegt hab das gleiche wie für x86, wenn du das "Interessante" anschaltest geht nicht mehr viel, und die Ebuilds strippen trotzdem noch zuviel.

Aber fürn x86-64 seh ichs noch ein, wobei ich eher aufn 3.5 warten würd mit hoffentlich funktionierendem Vectorizer  :Smile: 

----------

## Genone

Nicht jeder Entwickler testet seinen Code mit jedem Compiler (mal abgesehen davon dass manche Projekte keine Entwickler mehr haben), ausserdem muss man sich doch fragen, warum ältere Versionen diese "Schudrigkeiten" (oftmals sind das auch explizit eingebaute GCC Erweiterungen) erlaubt haben wenn sie nun nach und nach verboten werden.

----------

## Marlo

 *Haldir wrote:*   

> ...
> 
> Apropos für amd64, da gilt soweit ich das mitgekriegt hab das gleiche wie für x86, wenn du das "Interessante" anschaltest geht nicht mehr viel, und die Ebuilds strippen trotzdem noch zuviel....
> 
> 

 

Habe mal für mich ein Testsystem  aufgesetzt:

```

Portage 2.0.51-r2 (gcc34-amd64-2004.1, gcc-3.4.2, glibc-2.3.4.20040808-r1,glibc-2.3.4.20040605-r0, 2.6.9-nitro2 x86_64)

=================================================================

System uname: 2.6.9-nitro2 x86_64 AMD Athlon(tm) 64 Processor 3500+

Gentoo Base System version 1.4.16

Autoconf: sys-devel/autoconf-2.59-r5

Automake: sys-devel/automake-1.8.5-r1

Binutils: sys-devel/binutils-2.15.90.0.1.1-r3

Headers:  sys-kernel/linux26-headers-2.6.6-r1,sys-kernel/linux26-headers-2.6.8.1-r1

Libtools: sys-devel/libtool-1.5.2-r5

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="no"

CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -frename-registers"

CHOST="x86_64-pc-linux-gnu"

COMPILER=""

CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -frename-registers"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoaddcvs ccache distlocks sandbox"

GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"

MAKEOPTS="-j2"

--schnapp--

```

Das, was bereits an ebuilds freigegeben ist läuft sehr gut. Auch xorg und kde. Aber es sind noch zu viele Anwendungen masked, auf die ich nicht verzichten möchte. Es gibt zwar jede Menge dirty  Tipps, aber damit hat man in der Regel auch viel zu tun. Es ist  sehr, sehr zeitaufwändig das alles hinzupfrimeln. Ansonsten macht der 3.4 er einen guten Eindruck.

Gruß

Ma

----------

## Regnaron

 *Haldir wrote:*   

> Regnaron, der sog. Standard wird von jedem Compiler anders interpretiert (so würds wohl MS ausdrücken), trotzdem haben ältere Versionen nicht zwingend alles angemahnt was jetzt nicht mehr geht, teilweise auch weils sies nicht wußten .
> 
> 

 

Genau! Aber genau das "Problem" hat der gcc seit 3.4 ja (zumindest bei c++, dazu später mehr *g*) verbessert. Die sachen die nicht mehr gehen gingen zwar vorher, waren aber eigentlich im Standard nie so vorgesehen. Jedenfalls steht im Cahangelog irgendwas von wegen "jetzt noch näher am c++ Standard) Somit wird IMHO hier ein Bug im gcc gefixed, auf den Programme vorher aufgesetzt haben. Wenn ich ein Programm schreibe welches auf einem Bug aufbaut, dann sollte ich mich IMHO nicht wundern wenn dieser Bug irgendwann mal gefixed wird  :Wink: 

Aber ok, falls nicht alle nun korrigierten Konstrukte angemahnt wurden, dann hätte ich persönlich in der Tat noch eine Zwischenversion eingeschoben welche Warnungen geworfen hätte statt direkt abzubrechen. (aber wie gesagt: Das Problem sollte bei einem halbwegs vernünftigen Programmdesign nicht so oft auftreten)

 *Haldir wrote:*   

> 
> 
> Grundsätzlich find ichs aber nett das du gleich an den C++ Standard denkst 
> 
> 

 

*g* Naja, da meine Bevorzugte Sprache momentan halt c++ ist habe ich mich insbesondere beim gcc mit dem c++ Teil beschäftigt. Über die Änderungen am Fortran oder Ada Code kann ich halt nix sagen da ich mich mit den Sprachen und insbeondere mit den Sprachen im Bezug auf den gcc noch nie beschäftigt habe *g* Deswegen wollte ich mich an der Stelle nicht zu sehr aus dem Fenster lehnen *g*

----------

## Regnaron

 *Genone wrote:*   

> ausserdem muss man sich doch fragen, warum ältere Versionen diese "Schudrigkeiten" (oftmals sind das auch explizit eingebaute GCC Erweiterungen) erlaubt haben wenn sie nun nach und nach verboten werden.

 

Hm, keine Ahnung warum man die Sachen vorher als Features in den gcc eingebaut hatte. Aber ich persönlich sehe das ganze trotzdem als Bugfixing Prozess an. Früher hat man - aus welchen Gründen auch immer - nicht standardisierten Code zugelassen. Genau dieses Problem behebt man nun. Ist doch alles in allem eine positive Entwicklung, oder?

Klar, es wäre besser der Compiler hätte sich schon immer an die Standards gehalten, aber nur weil er sich jetzt einige Jahre lang nicht an die Standards gehalten hat verlangen dass dies so weitergeht? Bei HTML hatten wir doch das gleiche Problem: Erst bauen MS und NS Features um Features ein um mit dem anderen Browser inkompatibel zu sein, und nach und nach gewinnt der eigentliche HTML Standard immer mehr gewicht, und die Browser halten sich auch wieder enger an den Standard. (naja, bis auf einen   :Twisted Evil:  )

----------

## therjak

der standard fuer c++ ist auch noch nicht wirklich so alt, wie eine c++ unterstuetzung im gcc vorhanden ist. c++ ist doch erst seit ein paar jahren echt standardisiert

----------

## hoschi

 *Haldir wrote:*   

> Ansonsten halt als zweit compiler installieren, aber stable is der net wirklich und es ist eine Sache Schludrigkeiten im Code anzumahnen oder gleich voll abzubrechen. Geschwindigkeitstechnisch bringt der jetzt auch nicht den Overkill (außer du schaltest wirklich alles ein und dann compiled fast nix mehr), viele größere Ebuilds strippen eh die meisten cflags...

 

striktes und "gnadenloses" vorgehen finde ich gut, mal ein kleiner vergleich:

HTML!

wo dieses "ach drücken wir mal eine auge zu"-verhalten von den browser hingeführt hat (allen voran natürlich der browser aus re...) sehen wir ja heute  :Sad: 

----------

## spielc

 *hoschi wrote:*   

> 
> 
> striktes und "gnadenloses" vorgehen finde ich gut, mal ein kleiner vergleich:
> 
> HTML! wo dieses "ach drücken wir mal eine auge zu"-verhalten von den browser hingeführt hat (allen voran natürlich der browser aus re...) sehen wir ja heute 

 

Und deswegen hoffen wir alle ja auf XHTML und das es sich ENDLICH durchsetzt damit dem endlosen Browsergewurschtel endlich ein Ende gesetzt wird...    :Very Happy: 

----------

