Wie initialisiert man sowas korrekt?

[Mensch Müller (Gast)]

Ich habe zwei Zeichenketten im Flash, die zufällig identisch sind. Lässt 
sich nicht vermeiden (hat mit verschiedenen Sprachen zu tun). Ich habe 
das Ganze mal zu einem Minimalbeispiel zusammengedampft, das nur das 
Wesentliche enthält:

#include <inttypes.h>
#include <avr/io.h>

const __flash char TEST1[] = "test";
const __flash char TEST2[] = "test";

static void use(const __flash char *data) {
  char c;
  while ((c = *data++) != '\0') GPIOR1 = c;
}

int __attribute__((OS_main)) main(void) {
  use(TEST1);
  use(TEST2);
  while (1);
}

Kompiliert wird das Ganze mit avr-gcc 5.2.1 mit u.a. dem Parameter 
-fmerge-all-constants, der in solchen Fällen Platz spart. Nun ist es so, 
dass folgende Warnung erscheint:

test.c: In function 'main':
test.c:5:20: warning: uninitialized variable 'TEST2' put into program memory area [-Wuninitialized]
 const __flash char TEST2[] = "test";

Warum passiert das? Und wie kann ich die Warnung verhindern (ich kann 
nicht auf -Wuninitialized oder -fmerge-all-constants verzichten)?

[Markus F. (mfro)]

Mensch Müller schrieb:
> Warum passiert das?

anscheinend merkt der Compiler nicht, daß er eins von den beiden 
Symbolen schon aufs andere gelegt hat.

Ich würde zunächst mal den Weg des geringsten Widerstandes gehen und 
versuchen, eine der beiden Variablen als const volatile zu deklarieren.

[Di P. (drpepper)]

Könnte es sein, dass -fmerge-all-constants zur Link-Zeit wirkt, und zur 
Compile-Zeit dann TEST2 unintialisiert "aussieht"? Das wäre dann evtl. 
ein Bug. Dein Minimalbeispiel würde ich mal bei 
https://gcc.gnu.org/bugzilla/ melden.

[Johann L. (gjlayde)]

Di P. schrieb:
> Dein Minimalbeispiel würde ich mal bei
> https://gcc.gnu.org/bugzilla/ melden.

Bitte nicht, da gibt's bereis einen PR für.

[Mark B. (markbrandis)]

Johann L. schrieb:
> Di P. schrieb:
>> Dein Minimalbeispiel würde ich mal bei
>> https://gcc.gnu.org/bugzilla/ melden.
>
> Bitte nicht, da gibt's bereis einen PR für.

Kannst Du bitte die ID nennen? Ich hab grad versucht den per 
Volltextsuche zu finden, ist aber nicht so einfach.

[Mensch Müller (Gast)]

Also schonwieder ein Bug. :/ Oh boy...

[Mensch Müller (Gast)]

https://de.m.wikipedia.org/wiki/Programmfehler

GCC arbeitet hier offenkundig nicht korrekt. Die Variable ist im 
Quelltext eindeutig initialisiert.

[Johann L. (gjlayde)]

Es gab mal PR57597.  Aber in deinem Code dürfen TEST1 und TEST2 eh nicht 
gemergt werden.

[Di P. (drpepper)]

Weshalb nicht? (Bitte lass dir nicht alles aus der Nase ziehen...)

[Johann L. (gjlayde)]

Die Warnung kann ich nicht nachvollziehen, ich geb's auf die Optionen zu 
raten...

[Mark B. (markbrandis)]

Johann L. schrieb:
> Aber in deinem Code dürfen TEST1 und TEST2 eh nicht gemergt werden.

Ist das deswegen?

-fmerge-constants
    Attempt to merge identical constants (string constants 
    and floating-point constants) across compilation units.

Mit "across compilation units" ist in dem Beispiel oben ja nüscht.

[Mensch Müller (Gast)]

Warum Optionen raten? Könnt ihr es nicht mit dem Code nachvollziehen? 
Dann muss ich später nochmal gucken, ob ich eine spezielle weitere 
Option verwende.

[Mensch Müller (Gast)]

Da ist eigentlich keine Zauberei dabei. Das reicht für den Fehler:

-mmcu=atmega168 -Os -Wall -fmerge-all-constants

[Mensch Müller (Gast)]

Übrigens ist es sehr positiv, dass die Konstanten "gemergt" werden und 
so Flash frei wird. Ohne diese Option würden wir unsere Software nämlich 
nicht in den Chip reinkriegen.

[Johann L. (gjlayde)]

Okay, damit kann ich's nachvollziehen.  Wenn du nen PR anlegst dann 
bitte ohne Header, z.B.

const __flash char test1[] = "test";
const __flash char test2[] = "test";

char func (unsigned char c)
{
  return test1[c] + test2[c];
}

Die Warnung wird warscheinlich zu spät ausgegeben; sie zu früh 
auszugeben bringt hingegen PR34734 :-)  Bislang wurde das Problem 
wahrscheinlich durch PR57597 maskiert.

Bis das behoben ist kannst du ja -Wuninitialized deaktivieren oder 
rausfiltern falls "progmem memory area" drin vorkommt (ohne NLS, das man 
eh deaktivieren sollte).

Allerdings wüsste ich nicht, dass momentan jemand Zeit in avr-gcc 
investiert.

[Stefan (Gast)]

Johann L. schrieb:
> Allerdings wüsste ich nicht, dass momentan jemand Zeit in avr-gcc
> investiert.

Heißt das, dass man künftig auf deine Beiträge verzichten muss?