Hilfe - AVR-GCC "optimiert" Schleife zur Endlosschleife

Holger G. schrieb:
>     int i = 0;
>     while (--i)
>         wdt_reset();

Recht hat er. Du vertraust hier auf den (negativen) Überlauf einer 
Variablen mit Vorzeichen. Das ist undefiniertes Verhalten.

Holger G. schrieb:
> Das Verrückte ist: Wenn ich aus dem "int" ein "unsigned int" mache, dann
> funktioniert alles:

Bei vorzeichenlosen Variablen ist das Überlaufverhalten klar definiert.

Walter Tarpan schrieb:
> Wo ist das Problem?

Sein Problem liegt in der Schleife davor.

A. K. schrieb:

> Recht hat er. Du vertraust hier auf den (negativen) Überlauf einer
> Variablen mit Vorzeichen. Das ist undefiniertes Verhalten.

Versteh' ich nicht. Was soll denn daran undefinierter sein als der 
Rollover einer vorzeichenlosen 16-bit-Variablen beim "Dekrementieren" 
von 0 auf 65535?

Abgesehen davon darf er von mir aus warnen, schimpfen, Exceptions werfen 
- nur nicht stillschweigend so einen Blödsinn compilieren.

Holger G. schrieb:
> Versteh' ich nicht. Was soll denn daran undefinierter sein als der
> Rollover einer vorzeichenlosen 16-bit-Variablen beim "Dekrementieren"
> von 0 auf 65535?

Diesen Unterschied kannst du auch unter "par ordre du mufti" 
zusammenfassen. Das steht schlicht so im C-Standard.

> Abgesehen davon darf er von mir aus warnen, schimpfen, Exceptions werfen
> - nur nicht stillschweigend so einen Blödsinn compilieren.

Der Compiler darf alles optimieren, was im Rahmen der Sprachdefinition 
zum richtigen Ergebnis führt. Und das ist hier der Fall.

Höflicher wärs natürlich, wenn er nett darauf hinweist, dass er hier 
eine Schluderei des Programmierers ausnutzt. Wobei er nicht immer 
erkennt, dass dies so ist.

Ich würde sagen: <0 ist beim gcc FALSE. Also hat er die komplette 
Schleife rausgeworfen, und die for() blieb übrig.

Random ... schrieb:
> Ich würde sagen: <0 ist beim gcc FALSE.

Bei "int"?

Holger G. schrieb:
> Abgesehen davon darf er von mir aus warnen, schimpfen, Exceptions werfen
> - nur nicht stillschweigend so einen Blödsinn compilieren.

Der Compiler erkennt, dass die Bedingung innerhalb der Sprachdefinition 
nie falsch sein wird. Und er erkennt auch, dass "i" nirgends sonst 
verwendet wird. Also ist es äquivalent zu
  while (1) wdt_reset();

c.m. schrieb:
> ich hätte jetzt darauf getippt das die decrementierung einer variablen
> immer "true" zurückgibt - aber ich bin c-anfänger.
> kommt irgendwie aus der gleichen ecke wie der beliebte java-fehler
> 'while (var = 5) {...}'.

Das Decrementieren einer Variablen gibt natürlich das Ergebnis nach dem 
Decrement wieder **kopfschüttel**

A. K. schrieb:
> Random ... schrieb:
>> Ich würde sagen: <0 ist beim gcc FALSE.
>
> Bei "int"?
>
> Holger G. schrieb:
>> Abgesehen davon darf er von mir aus warnen, schimpfen, Exceptions werfen
>> - nur nicht stillschweigend so einen Blödsinn compilieren.
>
> Der Compiler erkennt, dass die Bedingung innerhalb der Sprachdefinition
> nie falsch sein wird. Und er erkennt auch, dass "i" nirgends sonst
> verwendet wird. Also ist es äquivalent zu
>   while (1) wdt_reset();

Da hast du dich verlesen :-)
Der Compiler schmeisst die ganze while() Schleife raus und lässt nur die 
for() dahinter drin.
Das deckt sich mit meiner Annahme, dass werte <0 FALSE entsprechen. Und 
von daher kann er while(FALSE) rausnehmen.

> Der Compiler erkennt, dass die Bedingung innerhalb der Sprachdefinition
> nie falsch sein wird.
a) Nehmen wir an, der zählt tatsächlich los, dann ist mind. (--i == 0) 
FALSE :-)
b) dann würde nach deiner Annahme da ein while(TRUE) WDT(); stehen 
bleiben.

Random ... schrieb:
> Der Compiler schmeisst die ganze while() Schleife raus und lässt nur die
> for() dahinter drin.

Nein, denn es bleibt das übrig:
  24:   a8 95       wdr
  26:   fe cf       rjmp  .-4    ; 0x24 <main>
und das ist eben
  while (1) wdt_reset();

Sorry für das Ungemach, aber ich kann lesen. Insbesondere den Output 
von Compilern. ;-)

Random ... schrieb:
> a) Nehmen wir an, der zählt tatsächlich los, dann ist mind. (--i == 0)
> FALSE :-)

Aber das steht da nicht. Da steht
  while (--i)
     wdt_reset();
also
  while (--i != 0)
     wdt_reset();
und --i wird bei int und Anfangswert 0 niemals wieder definiert 0.

Was ist los? Schlechten Tag erwischt?

A. K. schrieb:

> Der Compiler darf alles optimieren, was im Rahmen der Sprachdefinition
> zum richtigen Ergebnis führt. Und das ist hier der Fall.

Wäre es nicht sinnvoller, wenn der Compiler alles optimieren darf, was 
zum selben Verhalten wie der unoptimierte Code führt? Alles andere ist 
doch kreuzgefährlich und nützt absolut niemandem.

> Höflicher wärs natürlich, wenn er nett darauf hinweist, dass er hier
> eine Schluderei des Programmierers ausnutzt. Wobei er nicht immer
> erkennt, dass dies so ist.

Mit Höflichkeit hat das nicht viel zu tun. Ein kommerzielles Produkt 
würde Spießruten laufen, wenn es den Programmierer unter lapidarem 
Verweis auf den C-Standard so im Regen stehen lässt. Aber Open Source 
darf das wohl.

Den GCC-lern sitzt machnmal der Schalk im Nacken und dann nehmen sie die 
Variante, die sich der Autor möglichst wenig vorgestellt hat.

Da signed Unterlauf nicht definiert ist, könnte es ja sein, daß der Wert 
beim Minimalwert kleben bleibt.

Wird mit ner positiven Zahl initialisiert, funktioniert es.

A. K. schrieb:
> Random ... schrieb:
>> Der Compiler schmeisst die ganze while() Schleife raus und lässt nur die
>> for() dahinter drin.
>
> Nein, denn es bleibt das übrig:
>   24:   a8 95       wdr
>   26:   fe cf       rjmp  .-4    ; 0x24 <main>
> und das ist eben
>   while (1) wdt_reset();
>
> Sorry für das Ungemach, aber ich kann lesen. Insbesondere den Output
> von Compilern. ;-)

Tatsächlich sehe ich hier nur das ergebnis der for() schleife :-)
Wo ist denn der call zum wdt?

Random ... schrieb:

> Der Compiler schmeisst die ganze while() Schleife raus und lässt nur die
> for() dahinter drin.

Nein.

Hier nochmal im Klartext, also generierter Assemblercode (in diesem
Falle vom GCC 4.7.2):

1

.L2:

2

/* #APP */

3

 ;  7 "foo.c" 1

4

        wdr

5

 ;  0 "" 2

6

/* #NOAPP */

7

        rjmp .L2

Das ist nicht nur irgendwie ein Ausschnitt, nein, das ist das
komplette main(), welches er generiert.

> Das deckt sich mit meiner Annahme, dass werte <0 FALSE entsprechen. Und
> von daher kann er while(FALSE) rausnehmen.

Deine Annahme ist falsch.  Der C-Standard definiert ganz eindeutig,
dass nur der Wert 0 als Wahrheitswert “false” entspricht, alle anderen
Werte entsprechen “true”.

Es ist schon so, wie A. K. es schreibt.  Der Code verlässt sich darauf,
dass der Überlauf von -MAX_INT - 1 beim weiteren Herunterzählen
eine 0 ergibt.  Ein solcher Überlauf ist aber in C nicht definiert.

Wenn man -Wstrict-overflow mit in die Optionen aufnimmt, bekommt man
auch die entsprechende Warnung:

1

foo.c: In function 'main':

2

foo.c:6:11: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]

Alternativ bekommt man mit -fno-strict-overflow das vom TE erhoffte
Ergebnis:

1

        ldi r24,0

2

        ldi r25,0

3

        rjmp .L2

4

.L3:

5

/* #APP */

6

 ;  7 "foo.c" 1

7

        wdr

8

 ;  0 "" 2

9

/* #NOAPP */

10

.L2:

11

        sbiw r24,1

12

        brne .L3

13

.L4:

14

        rjmp .L4

Holger G. schrieb:
> Wäre es nicht sinnvoller, wenn der Compiler alles optimieren darf, was
> zum selben Verhalten wie der unoptimierte Code führt?

Ist dir eigentlich klar, was das für Folgen hätte?

Probiers mal im Kleinen aus: Schreib in deinem Program vor alle 
Variablen "volatile" davor, und schau an was dabei rauskommt. Ist ja ein 
Standardproblem, wenn der Compiler Zugriffe wegoptimiert und damit die 
Änderung im Interrupt übersieht.

A. K. schrieb:
> Random ... schrieb:
>> a) Nehmen wir an, der zählt tatsächlich los, dann ist mind. (--i == 0)
>> FALSE :-)
>
> Aber das steht da nicht. Da steht
>   while (--i)
>      wdt_reset();
> also
>   while (--i != 0)
>      wdt_reset();
> und --i wird bei int und Anfangswert 0 niemals wieder definiert 0.
>
> Was ist los? Schlechten Tag erwischt?

Also, wenn <0 FALSE entspricht wird der while - Ausdruck genau einmal 
mit while(-1) == while(FALSE) aufgerufen. Damit kann der Compiler den 
ganzen Aufruf incl. wdt rauswerfen.

Ich meinte, falls <0 TRUE entspräche und der einmal in die Runde 
laufen würde, wäre irgendwann das Ergebnis von --i NULL.

Peter II schrieb:
> Matthias schrieb:
>> Nochmal um klar zu stellen warum der Compiler das komplette
>> while-Statement entsorgt. Dort steht für ihn nachweisbar in diesem
>> Scope:
>
> mach er doch überhaupt nicht. Es wird nur eine endlosschleife.

Nope, der macht keine Endlosschleife. Die Endlosschleife ist das for() !

Sorry den Befehl wdr kannte ich nicht (bin nicht mit AVR asm unterwegs). 
Jetzt wirds interessant :-)

Faultier schrieb:
>>Also, wenn <0 FALSE entspricht wird der while - Ausdruck genau einmal
>>mit while(-1) == while(FALSE) aufgerufen. Damit kann der Compiler den
>>ganzen Aufruf incl. wdt rauswerfen.
>
> An dem Argument ist etwas dran, denke ich. Der Punkt ist nur, das eben
> die GCC-Autoren sich anders entschieden haben, und dabei die Tatsache,
> dass das Verhalten für solche Fälle "implementierungsabhängig" ist zu
> ihrer Rechtferigung benutzen können. Durchaus legitim, meine ich.

Wenn !=0 TRUE entspricht (also auch <0) sollte - rein technisch - 
irgendwann der Überlauf und dann auch die (--i == NULL) kommen. (ich 
schreibe --i, da ja das Ergebnis des Aufrufes, und nicht der aktuelle 
Wert von i zählt).

Aber da schlägt wohl das Argument von Peter II (Gast) zu.

A. K. schrieb:
> Holger G. schrieb:
>> Wäre es nicht sinnvoller, wenn der Compiler alles optimieren darf, was
>> zum selben Verhalten wie der unoptimierte Code führt?
>
> Ist dir eigentlich klar, was das für Folgen hätte?
>
> Probiers mal im Kleinen aus: Schreib in deinem Program vor /alle/
> Variablen "volatile" davor, und schau an was dabei rauskommt. Ist ja ein
> Standardproblem, wenn der Compiler Zugriffe wegoptimiert und damit die
> Änderung im Interrupt übersieht.

"volatile" bezieht sich auf die Vermeidung von Seiteneffekten durch 
Interrupts. Das ist aber etwas anderes, als einen deterministischen 
Programmablauf umzuwürfeln. Ich hab grad noch mal ohne Optimierungen 
kompiliert und folgenes erhalten:

1

  int i = 0;

2

  2e:  1a 82         std  Y+2, r1  ; 0x02

3

  30:  19 82         std  Y+1, r1  ; 0x01

4

  32:  01 c0         rjmp  .+2        ; 0x36 <__CCP__+0x2>

5

    while (--i)

6

    wdt_reset();

7

  34:  a8 95         wdr

8

#include <avr/wdt.h>

9

10

int main (void)

11

{

12

  int i = 0;

13

    while (--i)

14

  36:  89 81         ldd  r24, Y+1  ; 0x01

15

  38:  9a 81         ldd  r25, Y+2  ; 0x02

16

  3a:  01 97         sbiw  r24, 0x01  ; 1

17

  3c:  9a 83         std  Y+2, r25  ; 0x02

18

  3e:  89 83         std  Y+1, r24  ; 0x01

19

  40:  89 81         ldd  r24, Y+1  ; 0x01

20

  42:  9a 81         ldd  r25, Y+2  ; 0x02

21

  44:  00 97         sbiw  r24, 0x00  ; 0

22

  46:  b1 f7         brne  .-20       ; 0x34 <__CCP__>

23

  48:  ff cf         rjmp  .-2        ; 0x48 <__SREG__+0x9>

24

25

0000004a <_exit>:

26

  4a:  f8 94         cli

Hier macht er es also so, wie es dasteht, und pfeift auf den C-Standard. 
Und ich hätte mindestens erwartet, daß er mir eine Warnung ausgibt, wenn 
er diese eindeutig endende Schleife entfernt und einfach durch eine 
Endlosschleife ersetzt.

Random ... schrieb:
> Wenn !=0 TRUE entspricht (also auch <0) sollte - rein technisch -
> irgendwann der Überlauf und dann auch die (--i == NULL) kommen.

Technisch geht auch mehr. Beispielsweise saturierende Arithmetik, dann 
bleibt der Wert bei MIN_INT kleben. Wäre bei DSPs denkbar. Es könnte 
auch einen Overflow-Trap geben.

Faultier schrieb:
>>Holger G. schrieb:
>> Wäre es nicht sinnvoller, wenn der Compiler alles optimieren darf, was
>> zum selben Verhalten wie der unoptimierte Code führt?
>
> Genau das tut er ja.
> Es ist ja nur eine von mehreren Möglichkeit, das im Standard
> "undefiniertes" Verhalten, da es ohne Optimierung ja doch in irgendeiner
> Weise entschieden werden muss, genau zu dem Verhalten führt, das Du für
> sinnvoll hälst.
> Genauso plausibel wäre etwa ein "stehenbleiben" bei INT_MIN oder auch
> anderes.

Wenn er also ein Konstrukt erkennt, das wie meines laut Standard zu 
"undefiniertem" Verhalten führt und er einen Ausweg finden muss - ist es 
da zuviel verlangt, mich davon per Warnung in Kenntnis zu setzen? Genau 
das ist ja der Punkt, daß ich nicht weiß, wieviele solche Eier noch im 
eigenen (oder in fremdem) Code versteckt sind, und der einzige, der mich 
darüber informieren könnte, eben der gcc, es nicht tut!

Faultier schrieb:
> Der Punkt ist nur, das eben die GCC-Autoren sich anders entschieden
> haben, und dabei die Tatsache, dass das Verhalten für solche Fälle
> "implementierungsabhängig" ist zu ihrer Rechtferigung benutzen können.

Nein, es ist nicht "implementierungsabhängig", sondern es ist
undefiniert.  Der Standard schreibt dazu einleitend:

1

  3.4.3

2

1 undefined behavior

3

  behavior, upon use of a nonportable or erroneous program construct or of erroneous data,

4

  for which this International Standard imposes no requirements

5

2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable

6

  results, to behaving during translation or program execution in a documented manner characteristic of the

7

  environment (with or without the issuance of a diagnostic message), to terminating a translation or

8

  execution (with the issuance of a diagnostic message).

9

3 EXAMPLE         An example of undefined behavior is the behavior on integer overflow.

Holger G. schrieb:

> Wenn er also ein Konstrukt erkennt, das wie meines laut Standard zu
> "undefiniertem" Verhalten führt und er einen Ausweg finden muss - ist es
> da zuviel verlangt, mich davon per Warnung in Kenntnis zu setzen?

Du musst die Warnung einschalten (wie alle anderen Warnungen auch).
Wie das geht, schrieb ich weiter oben.

Das Einzige, was man den GCC-Entwicklern hier vorwerfen könnte ist,
dass sie diese Warnung nicht bei -Wextra automatisch mit aktivieren.

p.s.:

Holger G. schrieb:
> Und ich hätte mindestens erwartet, daß er mir eine Warnung ausgibt, wenn
> er diese eindeutig endende Schleife entfernt und einfach durch eine
> Endlosschleife ersetzt.

Dass er deine "eindeutig endende" Schleife entfernt, ist ja dann nur
eine Folge davon.  An der Stelle, wo er das tut, weiß er vermutlich
gar nicht mehr, was die Ursache dafür war.

Faultier schrieb:
> Eine Unaufmerksamkeit bei der Formulierung von mir. Ich meinte auch
> undefiniert.

Die ist aber durchaus folgenschwer.

"Implementierungsabhängig" (im Sinne von "implementation-defined")
ist nämlich ein sehr wohl definiertes Verhalten, bei dem sich ein
Compiler eine bestimmte Variante aus mehreren aussuchen kann, diese
aber dann dokumentieren muss.  Unter gleichen Umständen muss er sich
dann auch jedesmal gleich entscheiden.

Bei undefiniertem Verhalten muss der Compiler rein gar nichts, er
muss es nichtmal bemerken.  Er darf es auch bei jedem 13. Compilevorgang
völlig anders umsetzen als sonst.

Holger G. schrieb:
> Wenn er also ein Konstrukt erkennt, das wie meines laut Standard zu
> "undefiniertem" Verhalten führt und er einen Ausweg finden muss

Falsch gedacht. Es ist der Programmierer, der einen Ausweg finden muss. 
Der Compiler muss es nicht, der hat nämlich kein Problem damit.

In diesem Fall freilich entdeckt er, dass der Programmierer Mist gebaut 
hat. Weshalb er davor nicht stets warnt, sondern nur auf Anforderung, 
weiss ich nicht. Möglicherweise gibt es zu viel funktionierenden Code, 
der haufenweise solche Warnungen wirft. Aber mindestens in -Wextra hätte 
das wohl schon hineingepasst.

Aber es kann auch vorkommen, dass Optimierungen aufgrund undefinierten 
Verhaltens durch den Compiler nicht klar ersichtlich sind.

Jörg Wunsch schrieb:
> Du musst die Warnung einschalten (wie alle anderen Warnungen auch).
> Wie das geht, schrieb ich weiter oben.
>
> Das Einzige, was man den GCC-Entwicklern hier vorwerfen könnte ist,
> dass sie diese Warnung nicht bei -Wextra automatisch mit aktivieren.

Danke für den Tip. Ich hatte mit -Wall kompiliert und war bisher der 
Meinung, dass im Code nichts Schwerwiegendes falsch ist, wenn bei -Wall 
keine Warnung kommt. Man lernt nie aus...

A. K. schrieb:
> Aber mindestens in -Wextra hätte das wohl schon hineingepasst.

Sehe ich allerdings auch so.  Sollte man einen enhancement request
dafür einreichen?

Ja.

Auch Ja.

Ich hab das mal fixx mit dem armcc ausprobiert bei -O0 sowie -O3, und 
der zählt brav runter und steigt bei --i == 0 aus :-)

1

volatile unsigned int xxx=0;

2

3

void foo() {

4

  xxx--;

5

}

6

7

int main()

8

{

9

  signed char i=0;

10

11

  while(--i) {

12

    foo();

13

  }

14

}

Random ... schrieb:
> Ich hab das mal fixx mit dem armcc ausprobiert bei -O0 sowie -O3, und
> der zählt brav runter und steigt bei --i == 0 aus :-)

Das ist ebenso zulässig. Undefiniertes Verhalten schliesst auch jenes 
Verhalten ein, das der Programmierer erwartet. :-)

A. K. schrieb:
> Ja.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301

Ich habe das mal vom AVR weg verallgemeinert.  Letztlich ist das
wdt_reset() ja weiter nichts als ein asm("wdr"), und indem man da
ein asm("nop") schreibt, passt das am Ende für praktisch jedes
Target.  Damit hat man auch die Leute noch erreicht, die bei AVR im
Subject gleich weiterlesen würden. ;-)

Random ... schrieb:
> und der zählt brav runter und steigt bei --i == 0 aus :-)

Mit deinem Code.  Nun benutze mal das Äquivalent zum obigem Code:

1

int main(void)

2

{

3

  int i = 0;

4

  while (--i)

5

    asm("nop");

6

  for (;;) ;

7

}

Was bekommst du?

1

.L2:

2

      nop

3

      b .L2

Also letztlich dasselbe wie oben.

Faultier schrieb:
> Aber warum schreibst Du das mir?

Nicht dir, sondern ich wollte nur allgemein nochmal den Unterschied
zwischen "undefined" und "implementation-defined" behaviour
hervorheben.  Für den Hinterkopf gewissermaßen.

Fred schrieb:
> Ja, dann schalt die Warnung eben einfach ein. Wurde dir ebenfalls schon
> mitgeteilt, wie das geht.
>
> Mehr noch, es gibt sogar eine Option, das von dir gewünschte Verhalten
> einzuschalten.
>
> Was willst du eigentlich?

Kam nur beim Schreiben nicht mit Lesen hinterher. Aber nun ist alles 
klar. Vielen Dank an alle.

Jörg Wunsch schrieb:
> A. K. schrieb:
>> Ja.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301
>
> Ich habe das mal vom AVR weg verallgemeinert.  Letztlich ist das
> wdt_reset() ja weiter nichts als ein asm("wdr"), und indem man da
> ein asm("nop") schreibt, passt das am Ende für praktisch jedes
> Target.  Damit hat man auch die Leute noch erreicht, die bei AVR im
> Subject gleich weiterlesen würden. ;-)

Danke!

Zählt auch brav runter. Bei -O0 und -O3.

-O0:

1

    64: int main(void) 

2

    65: { 

3

0x08000610 4770      BX       lr

4

    66:   int i = 0; 

5

0x08000612 2000      MOVS     r0,#0x00

6

    67:   while (--i) 

7

0x08000614 E000      B        0x08000618

8

    68:     __NOP(); 

9

0x08000616 BF00      NOP      

10

0x08000618 1E41      SUBS     r1,r0,#1

11

0x0800061A 0008      MOVS     r0,r1

12

0x0800061C D1FB      BNE      0x08000616

13

    69:   for (;;) ; 

14

0x0800061E BF00      NOP      

15

0x08000620 E7FE      B        0x08000620

Ein unerwartetes Optimierungsverhalten war auch bei diesem Code 
festzustellen. Das durchlaufen der Schleife ist unsicher.

  do{
    if (GPIOA->IDR & 0x0001)
    {
      GPIO_ResetBits(GPIOD,GPIO_Pin_15);
    }
    else
    {
      GPIO_SetBits(GPIOD,GPIO_Pin_15);
    }
  } while (1);

Random ... schrieb:
> Zählt auch brav runter. Bei -O0 und -O3.

Dann hast du einen anderen ARM-GCC als ich.  Bei mir kam das raus,
was ich oben gepostet habe.

> -O0:

-O0 brauchst du nicht posten, dabei werden sämtliche relevanten
Betrachtungen nicht angeworfen.  Es muss also mindestens -O1 sein.

Ich bin auf der Suche für das Verhalten dieser Schleife.

Diese fragt bei stm 32 Board  eine Taste ab, und schaltet dann eine LED 
an oder aus. Bei zwei unterschiedlichen Board arbeitet diese Abfrage 
unzuverlässig.

Leider habe ich das fehlerhaft compilierte File, bei dem es nicht ging 
nicht mehr.
Der Code wurde so übersetzt, das die Abfrage nur einmal erfolgte,
oder die Schleife läuft endlos.
Möglicherweise erkennt der Compiler Endlosschleifen. Ich hoffe das 
möglicherweise noch andere Codebeispiele für optimierte Schleifen 
gefunden werden.

lutz h. schrieb:
> Ich bin auf der Suche für das Verhalten dieser Schleife.

Dann starte bitte einen eigenen Thread dafür.

Jörg Wunsch schrieb:
> Random ... schrieb:
>> Zählt auch brav runter. Bei -O0 und -O3.
>
> Dann hast du einen anderen ARM-GCC als ich.  Bei mir kam das raus,
> was ich oben gepostet habe.

Ich schrieb armcc, ohne 'g' :-)
Darum habe ich das asm("nop"); auch gegen die CMSIS Variante __NOP(); 
getauscht.

Wenn ich als Programmierer auf Nummer Sicher gehen will, dann enabliere 
ich also:

-Wall
-Wextra

Und was noch alles? :-)

Faultier schrieb:
>>enabliere
>
> WAS machst Du?

Büschn Spaß.

One switch to rule them all, One switch to find them,
One switch to print the warnings and in the darkness bind them

Faultier schrieb:
>>Büschn Spaß.
>
> Sehr spassig. Da lache ich am Wochende mal in Ruhe drüber.

hmmm. Gehst du dazu in den Keller?
Heute mit dem falschen Fuß zuerst aufgestanden?

nix für ungut...

Random ... schrieb:
> Ich schrieb armcc, ohne 'g' :-)

OK, flasch verstanden, schließlich sind wir ja im GCC-Forum.  Wer auch
immer einen armcc bastelt.

Jörg Wunsch schrieb:
> Wer auch immer einen armcc bastelt.

Damals(tm) wurde der ARMCC von Norcroft entwickelt und von ARM als ARM 
SDT (Software Development Toolkit) vertrieben. Um 2000 gab es die 
Umstellung auf ARM ADS, ebenfalls von Norcroft und ARM.

Mit dem Kauf von Keil durch ARM wurden jedoch die Compiler durch die 
entsprechenden Produkte von Keil ersetzt, ohne dies allzu publik zu 
machen.

Andreas Schweigstill schrieb:
> Mit dem Kauf von Keil durch ARM wurden jedoch die Compiler durch die
> entsprechenden Produkte von Keil ersetzt, ohne dies allzu publik zu
> machen.

Nicht wirklich. Das MDK-ARM (also die µVision IDE) werkelt seit dem auch 
mit dem armcc. Der ursprüngliche ARM Compiler von Keil wurde 
eingestellt.