gcc 3.4.2 zum gcc 4.2.0 problem

[Tomi (Gast)]

Hallo

Bin nach langer zeit auf den neuen gcc 4.2.0 umgestigen.
Habe vorher 3.4.2 benutzt. (Von WinAVR20060421 aud WinAVR20071221)

Habe Problem mit lokalen variablen. Mit gcc 3.4.2 ist alles wunderbar.
Wenn ich mir AVRStudio debugge sehen ich die lokalen variablen.

Mit 4.2.0 sagt mir AVRStudio "Location not valid".

Das gleiche Problem habe ich auch mit WinAVR20070521.

Anbei der Code ausschnitt und AVRStudio Screenshot.

Hat jemand von euch eine Idee was daran unterschiedlich ist?

Danke erstmal.

BYE

[Stefan B. (stefan)]

Hast du auch AVR Studio wie vorgesehen auf 4.13 geupdated?

Welche Optimierungsstufe benutzt du beim Übersetzen bzw. passiert das 
auch bei -O0 (keine Optimierung)?

[Tomi (Gast)]

Ich habe AvrStudio 4.13.
Optimierung habe ich bei beiden -O2

BYE

[Markus B. (Firma: Embedit Mikrocontrollertechnik) (_mb_)]

mit aktiver Optimierung funktioniert das Debugging nicht

[Jörg W. (dl8dtl) (Moderator)]

Markus Burrer wrote:

> mit aktiver Optimierung funktioniert das Debugging nicht

Das ist in dieser Pauschalität Quatsch.

Allerdings kann es natürlich mit aktiver Optimierung z. B. passieren,
dass der Compiler bestimmte Variablen (auch lokale) komplett
eliminiert.  Dann kann man sich logischerweise deren Wert nicht
ansehen.

[Markus B. (Firma: Embedit Mikrocontrollertechnik) (_mb_)]

Also bei mir hat es mit Optimierung noch nie funktioniert. Der Debugger 
läuft zwar, aber irgendwann stimmt die Programmposition nicht mehr mit 
der Position im Sourcecode überein.

[Ha Jo (Gast)]

Markus Burrer wrote:
> Also bei mir hat es mit Optimierung noch nie funktioniert. Der Debugger
> läuft zwar, aber irgendwann stimmt die Programmposition nicht mehr mit
> der Position im Sourcecode überein.

Das ist normal bei eingeschalteter Optimierung. Da kannst Compiler 
nehmen wie Du willst. Er sortiert halt so um, dass es nach seinem 
Ermessen OPTIMAL wird.
Deshalb paßt es dann unter Umständen nicht mehr mit dem Sourcecode 
zusammen.
Das er dabei diesen nicht mit umsortiert, ist schade, liegt wohl an der 
Bequemlichkeit des Compilers ;-)

@Tomi
Schalte mal die Optimierung ganz aus.

Hajo

[klogang beendet (Gast)]

Man sollte nie auf eine neuere WinAVR updaten, wenn es nicht unbedingt 
notwendig ist. Es gab bisher keine einzige Version, bei der man nicht 
Änderungen an seinem Programm vornehmen musste, um es kompilieren zu 
können. Mal ganz abgesehen davon, dass in jeder neuen Version 
zusätzliche Bugs enthalten sind und die alten Bugs einfach nicht behoben 
werden.

Mit vorzüglicher Hchachtung

klogang beendet

[Ha Jo (Gast)]

@Klogang

Der GCC ist absolut nicht so schlecht, wie er manchmal hier von einigen 
Leuten gemacht wird. Und wenn der Compiler nach einem Versionswechsel 
plötzlich viele Warnungen ausspukt, ist das nicht ein Problem des 
Compilers, sondern dort sitzt dann das Problem vor dem Bildschirm 
zwischen den Kopfhörern.

Das Problem beim Debuggen mit optimiertem Code ist schon gar kein 
Problem des Compilers.

Dieser Compiler wird in unzähligen kommerziellen Projekten verwenden, 
auch in der Raumfahrt. Perfekt ist er damit sicher nicht.

Außerdem kostet er nichts. Und dafür ist seine Leistung mehr als 
großartig. Und wem das trotzdem nicht gefällt, der kann doch auch einen 
anderen Compiler verwenden und nicht ständig darüber jammern.

So, das mußte mal gesagt werden.

Happy New Year an alle.
Hajo

[Jörg W. (dl8dtl) (Moderator)]

klogang beendet wrote:

> Mal ganz abgesehen davon, dass in jeder neuen Version
> zusätzliche Bugs enthalten sind und die alten Bugs einfach nicht behoben
> werden.

Teil 1 des Satzes ist mehr oder weniger logisch.
Teil 2 des Satzes wirst du uns dann sicher noch beweisen wollen, damit
man dich nicht der üblen Nachrede (amerikanisch FUD: “fear, uncertainty,
disinformation”) bezichtigen kann.

[Rolf Magnus (Gast)]

> Es gab bisher keine einzige Version, bei der man nicht Änderungen an
> seinem Programm vornehmen musste, um es kompilieren zu können.

Das passiert vor allem dann, wenn "man" Fehler im Programm hat, die der 
alte noch nicht erkannt hat. Neuere Versionen werden vor allem 
restriktiver, was die Konformität zur C-Norm angeht.

> Mal ganz abgesehen davon, dass in jeder neuen Version zusätzliche Bugs
> enthalten sind und die alten Bugs einfach nicht behoben werden.

Hast du davür konkrete Beispiele? Gibt es dazu Bugreports?

[Paris (Gast)]

Das geilste war, als sich die Interruptgeschichte geändert hat und man 
die ISRs seiner Programme ändern musste.

[Rolf Magnus (Gast)]

Das war aber keine Änderung am gcc, sondern an der avr-libc.

[Tomi (Gast)]

Hallo.

Wollte ungern über die Qualität von gcc diskutieren.

Problem ist nur mit gcc 3.4.2 funktioniert die Funktion auch bei 
Optimierung.
Bei 4.2.0 geht sie nicht.

Man kann ja jetzt schlecht alle funktionen durchgehen wenn man gern 
updaten möchte.

BYE

[Karl H. (kbuchegg)]

Tomi wrote:
> Hallo.
>
> Wollte ungern über die Qualität von gcc diskutieren.
>
> Problem ist nur mit gcc 3.4.2 funktioniert die Funktion auch bei
> Optimierung.
> Bei 4.2.0 geht sie nicht.

Dann zeig doch mal die Funktion her.
Und wenn du 'funktioniert nicht' bitte noch etwas
präzisieren könntest.
Was auch gut wäre: Was soll denn die Funktion grundsätzlich
machen?

[die ??? (Gast)]

Karl heinz Buchegger wrote:
> Was soll denn die Funktion grundsätzlich machen?

Funktionieren!?



Entschuldige Chef, musste sein  ;-)

duck und wecccch