Compiler Warnung in temporärer Datei

[StinkyWinky (Gast)]

Ich verwende Code:Blocks auf WinXP und programmiere in C.

Seit ich mein Projekt mit dem meines Kollegen zusammengeführt habe, 
erhalte ich neuerdings dutzende Warnungen dieser Art:

C:\DOKUME~1\Username\LOKALE~1\Temp\cc69aaaa.s|6795|Warning: value 0x190 truncated to 0x90|
C:\DOKUME~1\Username\LOKALE~1\Temp\cc69aaaa.s|6811|Warning: value 0x191 truncated to 0x91|
C:\DOKUME~1\Username\LOKALE~1\Temp\cc69aaaa.s|6827|Warning: value 0x192 truncated to 0x92|
(...)

Wie finde ich heraus, woher das kommt? Der Dateiname "cc69aaaa.s" ändert 
bei jedem Durchgang. Es ist mir nicht gelungen, die Datei im Ordner 
"C:\DOKUME~1\Username\LOKALE~1\Temp\" zu betrachten.

Danke für Hinweise.

[Klaus W. (mfgkw)]

1. gibt es nicht eine gcc-Option, um temporäre Dateien zu behalten?
   -save-temps

2. Möglicherweise ist ein Quelltext als Mehrbytecode bzw. Unicode
   gespeichert?

[StinkyWinky (Gast)]

Danke. Der Tipp mit dem -save-temps bringt mich weiter!

Anscheinend wird in einer grossen, konstanten Struktur versucht, Werte 
grösser als 255 in einem Byte zu speichern...

[Peter II (Gast)]

StinkyWinky schrieb:
> Anscheinend wird in einer grossen, konstanten Struktur versucht, Werte
> grösser als 255 in einem Byte zu speichern...

zeige uns doch mal die so eine Zeile.

[StinkyWinky (Gast)]

Der Datentyp:

typedef struct
{
  uint16_t  ParaNo;
  uint16_t  EeprAddr;
  int32_t  Min;
  int32_t  Max;
  int32_t  Default;
  uint16_t  Factor:14;
  uint16_t  ValPropSrc:1;
  uint16_t  Sign: 1;
  uint16_t  Visibility: 2;
  uint16_t  Fct: 3;
  uint16_t  Belong: 3;
  uint16_t  PwLvl: 3;
  uint16_t  PBoxMenu: 3;
  uint16_t  Direction: 2;
  uint16_t  MenuOrder: 8;
  uint16_t  MenuAuxInfo 8;
  uint16_t  IWPosition;
  uint16_t  NameIdx;
  uint16_t  UnitIdx;
  uint16_t  NbListItems;
  uint16_t  SinceParaVersion;
} T_ParaProperties;

Initialisierungsdaten des Records [400]:

{400,4224,  55536,10000,65436,100,  0,SIGN_SIGNED,eVisibility_Normal,0 |FCT_V | 0,eParaBelongType_Install,1,MENU_PARA_PID,eDir_Up,400,AUX_INFO_NONE,1300,TXT_V_START_OFFS,TXT_PERCENT,0,4},

Das Problem wird von "MenuOrder: 8" mit Wert 400 verursacht.
Der Compiler merkt wegen uint16_t nicht, dass 400 den Wertebereich für 8 
Bit übersteigt. Ich ändere das jetzt auf uint8_t, dann gibt es eine 
vernünftige Fehlermeldung.

Übrigens wurde das mit den Bitbreiten gemacht, um den Platzbedarf für 
die knapp 500 Parameter zu optimieren. Zielsystem ist ein Cortex-M3.

[Klaus W. (mfgkw)]

StinkyWinky schrieb:
> Das Problem wird von "MenuOrder: 8" mit Wert 400 verursacht.
> Der Compiler merkt wegen uint16_t nicht, dass 400 den Wertebereich für 8
> Bit übersteigt. Ich ändere das jetzt auf uint8_t, dann gibt es eine
> vernünftige Fehlermeldung.

Das macht m.E. keinen Sinn.
Mit uint8_t gibt man eine Breite vor, ebenso mit :8.

Bitfelder sollte man generell als signed oder unsigned deklarieren, 
zusammen mit dem :...
In deinem Fall also unsigned MenuOrder: 8

Analog natürlich die anderen, uint16_t  ValPropSrc:1 beispielsweise ist 
im besten Fall verwirrend, ggf. aber auch nicht portabel.

[Yalu X. (yalu) (Moderator)]

Das ist aber ein komisches Verhalten des Compilers. Die GCCs für x86 und 
AVR melden

warning: large integer implicitly truncated to unsigned type

und schneiden den Wert von sich aus auf 0x90 ab, so dass es vom 
Assembler nichts mehr zu meckern gibt. Entsprechendes gilt auch für 
kleinere Bitfelder. Es wird immer geprüft, ob der Wert mit der 
jeweiligen Bitzahl überhaupt darstellbar ist.

Könnte das ein Bug im ARM-GCC sein?

[Klaus W. (mfgkw)]

Ist doch nur eine Warnung, die liest nicht jeder :-)

[StinkyWinky (Gast)]

@Yalu
Ich übersetze den Code auf dem PC, Zielsystem PC (gcc 3.4.5). Zusätzlich 
sind da noch ein paar Unit-Tests dabei. Erst wenn das erfolgreich 
durchgelaufen ist, wird es mit uVision (ARM-GCC) für den Cortex-M3 
übersetzt. Letzterer hatte auch nichts angemeckert.

[Kindergärtner (Gast)]

StinkyWinky schrieb:
> Zielsystem PC (gcc 3.4.5)
Aah, bitte einmal auf was nicht-steinzeitliches updaten bevor man über 
eventuelle Bugs spekuliert...

[StinkyWinky (Gast)]

@Klaus
Ursprünglich waren alle Felder 32-bittig, bis die Grösse explodiert ist. 
Dann wurde versucht die Grösse der Struktur zu verkleinern. Um Problemen 
mit dem Alignement aus dem Weg zu gehen, kam jemand auf die seltsame 
Idee, es so zu lösen, wie es jetzt ist.

[amateur (Gast)]

Kann es sein, dass Du zu großzügig zusammen geführt hast?

Also das Du irgendein Make-File oder eine Datei mit Pfaden, die nur bei 
Deinem Kollegen existieren, oder auf die nur er Zugriff hat, mit kopiert 
hast.

Compiler haben relativ komplexe Verfahren bei der Suche nach Dateien 
oder nach Ablagemöglichkeiten für ihren Output.

Wenn mich nicht alles täuscht lautet eins: "Im Zweifelsfalle ins 
Temp-Verzeichnis" - das gibt's doch immer.

[Yalu X. (yalu) (Moderator)]

StinkyWinky schrieb:
> Ich übersetze den Code auf dem PC, Zielsystem PC (gcc 3.4.5).

Ok, der älteste Compiler, auf dem ich das getestet habe, ist 4.2.4, und 
der ist auch schon uralt ;-)

Der 3.4.5 wurde übrigens am 30.11.2005 herausgegeben.

[StinkyWinky (Gast)]

Sorry, dass ich eure Zeit vergeudet habe.
Mit gcc 4.7.2 wärs nicht passiert, der spuckt folgendes aus:

paramProps.c|411|warning: large integer implicitly truncated to unsigned type [-Woverflow]|

Danke für eure Hinweise!