Hallo, hab heute etwas gehabt, was mir wirklich zu denken gibt. Ich habe einen Source-Code, der für drei verschieden AVRs per Defines compiliert werden kann. Bei dem AT90CAN128 funktionierte alles irgendwie nicht richtig. Irgendwann habe ich festgestellt, das der Compiler eine Variable, obwohl sie explizit als volatile deklariert wurde, einfach wegoptimiert hat. Bei den beiden anderen Controllern kann ich die Optimierungsstufe -Os einstellen, bei dem AT90CAN128 funktioniert es nur mit Optimierungsstufe -O3. Wie kann das sein? Gibt es eigentlich bald mal ein Update vom WinAVR? Ist AVR-GCC unter Linux besser?
Harald schrieb: > Hallo, > > hab heute etwas gehabt, was mir wirklich zu denken gibt. Ich habe einen > Source-Code, der für drei verschieden AVRs per Defines compiliert werden > kann. Bei dem AT90CAN128 funktionierte alles irgendwie nicht richtig. > Irgendwann habe ich festgestellt, das der Compiler eine Variable, obwohl > sie explizit als volatile deklariert wurde, einfach wegoptimiert hat. > Bei den beiden anderen Controllern kann ich die Optimierungsstufe -Os > einstellen, bei dem AT90CAN128 funktioniert es nur mit Optimierungsstufe > -O3. Wie kann das sein? Gibt es eigentlich bald mal ein Update vom > WinAVR? Ist AVR-GCC unter Linux besser?
Offenbar war meine Frage so dumm, dass sie mit einem leeren Submit kommentiert wurde :(
die optimierung ist doch nicht CPU anhängig. Kannst du nicht mal ein minimal beispiel zeigen wo der Fehler für andere nachvollziebar ist? Auch die Frage ob es unter Linux anders als unter Windows ist uninnig. Die gleicher Version vom GCC liefert unter windows genau das gleiche Ergbniss wie unter linux.
Das dürfte zwar ein Versehen gewesen sein, aber lies deine Frage mal selber unter der Annahme aus, das du nicht mehr über dein Problem kennst, als im Beitrag steht. Und dann überleg, ob es darauf eine sinnvollere Antwort als KHBs überhaupt geben kann.
>Offenbar war meine Frage so dumm, dass sie mit einem leeren Submit >kommentiert wurde :( Schon nicht ganz! Aber das Problem wird mit 99.99999% Wahrscheinlichkeit am Source-Code liegen und nicht am Compiler.
Peter II schrieb: > die optimierung ist doch nicht CPU anhängig. Das denke ich ja auch. Deshalb verstehe ich das nicht. A. K. schrieb: > Und dann überleg, ob es darauf eine > sinnvollere Antwort als KHBs überhaupt geben kann. Den Code posten darf ich nicht. Nun gut war dämlich hier eine Frage zu stellen.
Harald schrieb: > Offenbar war meine Frage so dumm, dass sie mit einem leeren Submit > kommentiert wurde :( :-) War ein Versehen. Ich wollte eigentlich was schreiben, hab mich aber umentschieden und dabei aus Versehen auf Absenden geklickt. Keine Ahnung warum.
Harald schrieb: > Den Code posten darf ich nicht. Nun gut war dämlich hier eine Frage zu > stellen. eventuell reicht es ja schon den Breich zu zeigen wo die Variabel wegoptimiet wird. Dazu dann auch den Breich aus dem LST file. Damit wird wohl niemand deine Gräte nachbauen können.
Harald schrieb: > Peter II schrieb: >> die optimierung ist doch nicht CPU anhängig. > > Das denke ich ja auch. Deshalb verstehe ich das nicht. > > A. K. schrieb: >> Und dann überleg, ob es darauf eine >> sinnvollere Antwort als KHBs überhaupt geben kann. > > Den Code posten darf ich nicht. Tja. Was erwartest du dann. Ich wollte erst ursprünglich noch was zu deinem volatile schreiben. volatile heisst nicht, dass der Compiler die Variable nicht wegoptimieren darf, wenn sie nirgends mehr verwendet wird! volatile heißt, dass er alle Zugriffe ausführen muss, so wie sie hingeschrieben sind. Bleiben aber keine Zugriffe übrig, dann kann die Variable an sich auch rausfallen.
1 | void foo() |
2 | {
|
3 | volatile int i; |
4 | int j; |
5 | |
6 | j = 5; |
7 | }
|
i wird in der Funktion gar nicht verwendet. Also kann sie der Compiler rausschmeissen. volatile oder nicht - spielt keine Rolle. Wenn du dir also durch ein paar #ifdef abhängig vom Prozessortyp alle Zugriffe auf eine Variable 'stillegst', kann es schon sein dass Variablen rausfliegen. Hängt halt von den genauen Details ab - eigentlich so wie immer, wenn es um Optimierungen geht.
Karl Heinz Buchegger schrieb: > i wird in der Funktion gar nicht verwendet. Also kann sie der Compiler > rausschmeissen. volatile oder nicht - spielt keine Rolle. Das ist ja schön und gut. Bei mir ist es eine Variable SysTime, welche sich durch den kompletten Code zieht und an vielen Stellen abgefragt wird. Der Code wurde von mir so übernommen. Ich mag eigentlich keine globalen Variablen, weil es total gefährlich ist, wenn diese an einer anderen Stelle unbemerkt verändert werden. Beim compilieren für die beiden anderen MCU-Typen ist alles wunderbar. Nur beim AT90CAN128 musste ich in der Hauptschleife ein SysTime=SysTime; einfügen um den Fehler als solchen zu entlarven. Die Änderungen der Optimierungsstufe auf -O3 hat das ganze dann wieder überflüssig gemacht. Es ist durchaus möglich, dass es am Code liegt. Ich glaube das aber nicht, weil es nur diese Variable betraf. Naja, thread einfach löschen...
Harald schrieb: > Es ist durchaus möglich, dass es am Code liegt. Ich glaube das aber > nicht, weil es nur diese Variable betraf. Klar haben Compiler auch Fehler. Aber in den meisten Fällen ist es #wesentlich# wahrscheinlicher, dass das Problem im Code liegt. Wurde ja schon gesagt: Ohne Code lässt sich nur schwer was sagen. Wenn es dich interessiert, konstruier halt einen COde, der das Problem zeigt (oder speck deinen Code ab), dann kann man konkret reden und untersuchen was da warum passiert.
So ist das doch nur rumgerate. Wenn der Code zu geheim ist, dann such in den GCC Fehlerliste, ob dein Ding dabei ist (~176 Treffer): http://gcc.gnu.org/bugzilla/buglist.cgi?list_id=40206&short_desc=volatile&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=allwordssubstr&product=gcc Weiterhin kannst du auch nach der geheimen Version des Compilers filtern oder nach anderen geheimen Eigenschaften.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.