gcc: Seltsames Verhalten in compile-time Berechnung

[Foka M. (foka)]

Hallo Zusammen,

ich will zur comple-Zeit bestimmte Konstanten berechnen. Doch aus irgend 
einem Grund, wenn ich den avr-gcc verwende, werden diese nicht so 
gerechnet wie ich es erwarten wuerde.

Die Konstanten sind jedoch richtig wenn der 'normale' gcc (ubuntu 
systemcompiler) verwendet wird.

Folgender Code sollte fuer jede test-Variable 31 ergeben (8000000/(256 * 
1000)):

#include <stdint.h>
#define LARGE_NUMBER (8000000UL)

//static const uint16_t mPrescaler = 256;
#define mPrescaler ((uint16_t)256)

const uint16_t myTestVariable1 = LARGE_NUMBER / (mPrescaler * 1000);
const uint16_t myTestVariable2 = LARGE_NUMBER / ((uint16_t)256 * 1000);
const uint16_t myTestVariable3 = LARGE_NUMBER / 256000;

int main() {
   return 0;
}

Uebersetzt man das mit:

gcc -Wall -Wextra --save-temps -c testCalc.c -o testCalc.o

Dann ist alles in Ordnung, jede Variable hat den Wert den ich erwarten 
wuerde (testCalc.s):

  .file  "testCalc.c"
  .globl  myTestVariable1
  .section  .rodata
  .align 2
  .type  myTestVariable1, @object
  .size  myTestVariable1, 2
myTestVariable1:
  .value  31
  .globl  myTestVariable2
  .align 2
  .type  myTestVariable2, @object
  .size  myTestVariable2, 2
myTestVariable2:
  .value  31
  .globl  myTestVariable3
  .align 2
  .type  myTestVariable3, @object
  .size  myTestVariable3, 2
myTestVariable3:
  .value  31
  .text
  .globl  main
  .type  main, @function
main:
.LFB0:
  .cfi_startproc
  pushq  %rbp
  .cfi_def_cfa_offset 16
  .cfi_offset 6, -16
  movq  %rsp, %rbp
  .cfi_def_cfa_register 6
  movl  $0, %eax
  popq  %rbp
  .cfi_def_cfa 7, 8
  ret
  .cfi_endproc
.LFE0:
  .size  main, .-main
  .ident  "GCC: (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413"
  .section  .note.GNU-stack,"",@progbits

Wenn ich es jedoch mit dem avr-gcc uebersetze:

avr-gcc -c  -mmcu=atmega328p -Os -Wall -Wextra -Wundef --save-temps testCalc.c -o testCalc.o

Dann ist:

  .file  "testCalc.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
  .section  .text.startup,"ax",@progbits
.global  main
  .type  main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
  ldi r24,0
  ldi r25,0
  ret
  .size  main, .-main
.global  myTestVariable3
  .section  .rodata
  .type  myTestVariable3, @object
  .size  myTestVariable3, 2
myTestVariable3:
  .word  31
.global  myTestVariable2
  .type  myTestVariable2, @object
  .size  myTestVariable2, 2
myTestVariable2:
  .word  134
.global  myTestVariable1
  .type  myTestVariable1, @object
  .size  myTestVariable1, 2
myTestVariable1:
  .word  134
  .ident  "GCC: (GNU) 6.1.0"
.global __do_copy_data

Ich habe auch den avr-gcc 4.9.2 ausprobiert. Ergebnis ist gleich.
Das Verhalten ist auch gleich egal ob 'mPrescaler' ein '#define' ist 
oder eine 'static const' variable (im C++ Fall).

Warum wird myTestVariable3 korrekt gerechnet, waehrend die anderen zwei 
falsch sind?
Es scheint, dass die Multiplikation im Nenner schief geht.
Mir ist auch nicht klar wie der compiler gerade auf '134' kommt...

Sitzt der Bug jetzt vor dem Rechner oder im avr-gcc?
Wenn vor dem Rechner, wo ist dann mein Denkfehler?

Vielen Dank fuer Eure Hilfe,
-Foka

[Max (Gast)]

Dein uint16_t reicht nicht für 256*1000

[Max (Gast)]

Mach mal 256UL * 1000.

Oder rechne in zwei Schritten: LARGE_NUMBER  256  1000

[Max (Gast)]

Forum hat die Slashes verschluckt...

LARGE_NUMER / 256 / 1000

[Foka M. (foka)]

Max schrieb:
> Forum hat die Slashes verschluckt...
>
>

LARGE_NUMER / 256 / 1000

Oh, prima!
Danke fuer den Tipp, so funktioniert es.

Bliebe nur noch die Frage warum der 'normale' gcc den gleichen Code 
richtig(er) uebersetzt.

-Foka

[Max (Gast)]

Wahrscheinlich (ich weiß es nicht genau), weil gcc nur zu int promoted 
und "int" beim avr eben 16 Bit breit sind und beim x86 32 Bit.

[Kernelhacker (Gast)]

Integer promotion ist die Ursache dieses Verhaltens.

[Markus F. (mfro)]

Kernelhacker schrieb:
> Integer promotion ist die Ursache dieses Verhaltens.

Nein. Integer promotion ist zwar ein hübsches Stichwort, stimmt aber 
hier nicht. Integer promotion ist die automatische Erweiterung von 
Parametern arithmetischer Operationen, die kleiner als int sind, auf 
int.

Hier gibt's keine integer promotion, weil die Konstanten schon int sind.

Das ist ein ganz simpler Überlauf bei der Berechnung des 
Klammerausdrucks.

256 * 1000 ist nun mal 256000 und das passt nicht in ein AVR 16-bit int.

[Carl D. (jcw2)]

Vermutlich hat der avr-gcc über Warnungen auch gemeldet, daß es da einen 
int-Überlauf gibt, nur - wer liest schon Warnungen. Ist doch einfacher 
einen Compiler-Fehler zu vermuten.  ;-(

Der Compiler muß im Übrigen zur Compile-Time exakt so rechnen, wie es 
die HW auch tun würde, inkl. Überlauf, sonst wäre das tatsächlich ein 
Compiler-Fehler.

[Foka M. (foka)]

Carl D. schrieb:
> Vermutlich hat der avr-gcc über Warnungen auch gemeldet, daß es da einen
> int-Überlauf gibt, nur - wer liest schon Warnungen. Ist doch einfacher
> einen Compiler-Fehler zu vermuten.  ;-(
>

Das stimmt so nicht.
Wenn Du den Code, den ich oben gepostet habe, mit dem avr-gcc 
duchrkompiliertst wirst Du feststellen, dass der Compiler nicht warnt.
Ich gehoere zu der Sorte die immer das '-Wall -Wextra' mit auf die 
command-line aufnehmen.

Aufgefallen ist es mir auch nur weil ich eine Art 'sanity check' 
eigebaut habe:

typedef struct { uint8_t a[255 - (3 * myTestVariable1)]; } Error_TestVariableLargerThan255;

-Foka

[Bernd K. (prof7bit)]

Markus F. schrieb:
> Kernelhacker schrieb:
>> Integer promotion ist die Ursache dieses Verhaltens.
>
> Nein. Integer promotion ist zwar ein hübsches Stichwort, stimmt aber
> hier nicht.

Doch. Integer-promotion ist der Grund warum es auf dem x86 nicht 
überäuft.

[Foka M. (foka)]

Ich habe mir noch kurz angeschaut was der 'normale' gcc im 32-Bit modus 
macht wenn im Nenner der Ueberlauf passiert:

#include <stdint.h>
#define LARGE_NUMBER (24500000000)
#define mPrescaler (70000)

volatile const uint32_t myTestVariable1 = LARGE_NUMBER / (mPrescaler *  70000);
volatile const uint32_t myTestVariable2 = LARGE_NUMBER / (70000 * 70000);
volatile const uint32_t myTestVariable3 = LARGE_NUMBER / 4900000000;

int main() {
   return 0;
}

compiliert mit:

gcc -m32 -Wall -Wextra --save-temps -c testCalc.c -o testCalc.o

ergibt auch eine Warnung:

testCalc.c:19:68: warning: integer overflow in expression [-Woverflow]
 volatile const uint32_t myTestVariable1 = LARGE_NUMBER / (mPrescaler *  70000);
                                                                    ^
testCalc.c:20:66: warning: integer overflow in expression [-Woverflow]
 volatile const uint32_t myTestVariable2 = LARGE_NUMBER / (70000 * 70000);

Und die, vom compiler angemeckerten, Variablen sind auch falsch 
berechnet.
So wuerde ich es vom avr-gcc erwarten.
Der Vorschlag von Max funktioniert hier ueberigens auch sehr gut.

Allerdings gilt es auch nicht mehr wenn ich den Code mit dem g++ 
uebersetze und wie folgt anpasse:

#include <stdint.h>
#define LARGE_NUMBER (24500000000)
static const uint32_t mPrescaler = 70000;

volatile const uint32_t myTestVariable1 = LARGE_NUMBER / (mPrescaler *  70000);
volatile const uint32_t myTestVariable2 = LARGE_NUMBER / (70000 * 70000);
volatile const uint32_t myTestVariable3 = LARGE_NUMBER / 4900000000;

int main() {
   return 0;
}

Das ergibt nur eine Warning ufer 'myTestVariable2'. 'myTestVariable1' 
ist falsch berechnet und es gab keine Warnung:

g++ -m32 -Wall -Wextra --save-temps -c testCalc.c -o testCalc.o
testCalc.c:20:66: warning: integer overflow in expression [-Woverflow]
 volatile const uint32_t myTestVariable2 = LARGE_NUMBER / (70000 * 70000);
                                                                  ^
mi@thinkfoka:~/devel/RTV_RI$ cat testCalc.s 
  .file  "testCalc.c"
  .section  .rodata
  .align 4
  .type  _ZL10mPrescaler, @object
  .size  _ZL10mPrescaler, 4
_ZL10mPrescaler:
  .long  70000
  .data
  .align 4
  .type  _ZL15myTestVariable1, @object
  .size  _ZL15myTestVariable1, 4
_ZL15myTestVariable1:
  .long  40
  .align 4
  .type  _ZL15myTestVariable2, @object
  .size  _ZL15myTestVariable2, 4
_ZL15myTestVariable2:
  .long  40
  .align 4
  .type  _ZL15myTestVariable3, @object
  .size  _ZL15myTestVariable3, 4
_ZL15myTestVariable3:
  .long  5
  .text
  .globl  main
  .type  main, @function
main:
.LFB0:
  .cfi_startproc
  pushl  %ebp
  .cfi_def_cfa_offset 8
  .cfi_offset 5, -8
  movl  %esp, %ebp
  .cfi_def_cfa_register 5
  movl  $0, %eax
  popl  %ebp
  .cfi_restore 5
  .cfi_def_cfa 4, 4
  ret
  .cfi_endproc
.LFE0:
  .size  main, .-main
  .ident  "GCC: (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413"
  .section  .note.GNU-stack,"",@progbits

Auch wenn das Verhalten schon etwas besser ist als das von avr-gcc ist 
es leider immer noch nicht perfekt und man muss doch hoellisch 
aufpassen.


-Foka

[Bernd K. (prof7bit)]

Foka M. schrieb:
> und man muss doch hoellisch aufpassen.

Ja.

Aber mit der Zeit bekommt man ein Auge dafür.

[Yalu X. (yalu) (Moderator)]

Der GCC gibt bei Unsigned-Operationen niemals eine Overflow-Warnung aus,
da Unsigned-Operationen nach C-Standard nicht überlaufen können, sondern
per modulo 2**n auf den gültigen Wertebereich reduziert werden.

Deswegen warnt der AVR-GCC zwar bei

  256 * 1000

nicht aber (wie im Eröffnungsbeitrag) bei

  (uint16_t)256 * 1000

[Kernelhacker (Gast)]

Markus F. schrieb:
> Kernelhacker schrieb:
>> Integer promotion ist die Ursache dieses Verhaltens.
>
> Nein. Integer promotion ist zwar ein hübsches Stichwort, stimmt aber
> hier nicht. Integer promotion ist die automatische Erweiterung von
> Parametern arithmetischer Operationen, die kleiner als int sind, auf
> int.

Doch natürlich handelt es sich bei der Ursache des unterschiedlichen 
Verhaltens hier um Promotion.
Der Code ist:

(uint16_t)256 * 1000

Das funktioniert nicht, wenn es keine Promotion von uint16_t auf ein 
32 Bit int gibt. Wie es eben auf dem AVR der Fall ist, weil int dort 16 
Bit hat.

Das es ohne den Cast genau so wenig funktioniert, ist ja wieder eine 
separate Sache.

[Markus F. (mfro)]

Bernd K. schrieb:
> Markus F. schrieb:
>> Kernelhacker schrieb:
>>> Integer promotion ist die Ursache dieses Verhaltens.
>>
>> Nein. Integer promotion ist zwar ein hübsches Stichwort, stimmt aber
>> hier nicht.
>
> Doch. Integer-promotion ist der Grund warum es auf dem x86 nicht
> überäuft.

Blödsinn. Der Grund, warum es auf dem x86 nicht überläuft ist die Größe 
eines ints auf dieser Plattform.

Wie willst Du ein int auf ein int promoten?

[Kernelhacker (Gast)]

Markus F. schrieb:
> Wie willst Du ein int auf ein int promoten?

Das ist nicht der Fall. Es ist eine uint16_t zu int Promotion auf x86.

[Markus F. (mfro)]

Kernelhacker schrieb:
> Markus F. schrieb:
>> Wie willst Du ein int auf ein int promoten?
>
> Das ist nicht der Fall. Es ist eine uint16_t zu int Promotion auf x86.

Stimmt. Ich hab' den Cast nicht gesehen, sorry.