Forum: Compiler & IDEs avr-gcc-10 - "volatile deprecated [-Wvolatile]" Warnungen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:

> Wie jetzt? Hat Johann hingeschmissen?

Kennst du diese Diskussion denn nicht?

Beitrag "gcc11 könnte das avr Backend verlieren"

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> Sind sie nicht, vor allem in C++ nicht (getrennte Operatorüberladung).
>
> Da ist allerdings was dran (hatte ich ja auch viel weiter oben schon
> erwähnt).

Wenn ich drüber nachdenke: für die Basistypen (für die volatile im 
Zusammenhang mit Hardware wichtig ist) kann man die Operatoren sowieso 
nicht überladen. Man könnte wahrscheinlich gut damit leben, volatile nur 
für solche Datentypen überhaupt noch zuzulassen (also Ganz- und 
Gleitkommazahlen, boolean, sowie Zeiger) und für alle anderen Typen das 
Verhalten als undefined zu erklären. Damit hätte sich das Problem 
überladener Operatoren in dieser Hinsicht erledigt.

Grenzfall wären enums: sie sind natürlich nützlich für 
Hardware-Abbildungen, aber für sie ist operator overloading zugelassen.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Veit D. schrieb:
>
>> Wie jetzt? Hat Johann hingeschmissen?
>
> Kennst du diese Diskussion denn nicht?
> Beitrag "gcc11 könnte das avr Backend verlieren"

Ja das kenne ich. Das klang jetzt leider für mich so das Johann gar 
nichts mehr für gcc macht, stimmt ja so auch nicht. 64bit Double hat er 
vor kurzem erst eingebaut bzw. gcc zur Verfügung gestellt, wie auch 
immer, ist von ihm. Das er dagegen keine Energie ins Backend steckt kann 
ich nachvollziehen.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> und für alle anderen Typen das
> Verhalten als undefined zu erklären.

Was ist z.B. mit einem Ringbuffer zwischen Applikation und Interrupt?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Was ist z.B. mit einem Ringbuffer zwischen Applikation und Interrupt?

Da musst du doch nur die head- und tail-Zeiger volatile machen.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Da musst du doch nur die head- und tail-Zeiger volatile machen.

Auch wieder wahr, der Buffer selber muß ja nur den Bereich 
bereitstellen. Muß man halt im Hinterkopf behalten, das mit Pointern und 
nicht mit Indizes zu implementieren.

von A. B. (Firma: uc++) (mitschreiberin)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Veit D. schrieb:

> Ich habe da mal was vorbereitet ...
> ...
> x86-64 gcc 10.1:  https://godbolt.org/z/xFAisg

Mit volatile int a,b,c,d
************************
siehe oben
oder hier https://godbolt.org/z/2JSzC_

x86-64 gcc 10.1
***************
4 x identisch und 3 x warning deprecated

von aweng (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
A. B. schrieb:
> 4 x identisch und 3 x warning deprecated

Was willst du jetzt damit beweisen? Dass irgendein Compiler irgendwas 
macht?

von A. B. (Firma: uc++) (mitschreiberin)


Bewertung
0 lesenswert
nicht lesenswert
gcc 10.1 übersetzt die verschiedenen Schreibweisen in identischen Code, 
akzeptiert aber nur die lange Schreibweise als nicht deprecated.

von aweng (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
A. B. schrieb:
> gcc 10.1 übersetzt die verschiedenen Schreibweisen in identischen Code,
> akzeptiert aber nur die lange Schreibweise als nicht deprecated.

und jetzt? Was schließt du daraus?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
aweng schrieb:
> Was schließt du daraus?

Dass die Überschrift des Threads just dieses aussagt? ;-)

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nö, es ging mir darum die Aussage von S.R.
Beitrag "Re: avr-gcc-10 - "volatile deprecated [-Wvolatile]" Warnungen"
und weit vorher von paar anderen Usern nachzuvollziehen bzw. zu 
widerlegen, die Compilierungen widerlegen es jedoch. Das heißt meine 
Gedanken das eh alles das Gleiche ist stimmt. Hat A.B. nochmal 
bestätigt.
Deswegen kann ich den gesamten Aufriss von gcc und der Warnung 
nachwievor nicht nachvollziehen. Wir drehen uns im Kreis.

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Veit D. schrieb:
> die Compilierungen widerlegen es jedoch.

"Deprecated" heißt ja auch nur, daß es ZUKÜNFTIG mal gänzlich entfernt 
werden könnte und man sich deswegen VORBEUGEND darum kümmern sollte.

von Bäm (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Veit D. schrieb:
> und weit vorher von paar anderen Usern nachzuvollziehen bzw. zu
> widerlegen, die Compilierungen widerlegen es jedoch. Das heißt meine
> Gedanken das eh alles das Gleiche ist stimmt.

Damit hast du nur gezeigt, dass ganz bestimmte Compilerimplementierungen 
dies tun.
Das sagt über den Standard und wie dieser sein sollte überhaupt nichts 
aus.
Es sagt auch nichts über die Standardkonformität der Compiler aus.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Bitte ein Nutzername pro Thread!

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
S. R. schrieb:
> Veit D. schrieb:
>> Also wo ist das Problem das standardmäßig vor der eigentlichen
>> Übersetzung mit der Langschreibweise zu ersetzen?
>
> In deiner Annahme, dass sie das gleiche wären.
> Sind sie nicht, vor allem in C++ nicht (getrennte Operatorüberladung).

Die Volatile-Deprecation erstreckt sich nicht auf überladene Operatoren.
Das wäre auch unsinnig, da sich die Semantik von überladenen Operatoren
beliebig von derjenigen der Basisoperatoren unterscheiden kann.

Dies kann man sich zunutze machen, um für memory-mapped I/O-Register
auch zukünftig Compound-Assignments verwenden zu können: Man verpackt
das zugrunde liegende Speicherobjekt einfach in eine Klasse, für die die
fraglichen Operatoren überladen werden.

Ich habe das einmal exemplarisch für die AVR-Familie versucht:

Im angehängten Header io-c++20.h wird eine Template-Klasse deklariert,
in der I/O-Register unterschiedlicher Bitbreite verpackt werden können.
Des Weiteren werden drei Makros aus der AVR-Libc so umdefiniert, dass
sie diese Klasse nutzen.

Wird nun in einem Anwendungsprogramm io-c++20.h anstelle von avr/io.h
inkludiert, werden die Beschränkungen durch die neuen Volatile-Regeln
umgangen, ohne dass dabei (außer der Include-Zeile) etwas am Quellcode
geändert werden muss. Auch die AVR-Libc muss dazu nicht angefasst
werden.

Falls das Standardisierungsgremium die neuen Regeln irgendwann bindend
macht (was ich nicht hoffe), könnte das ein Ansatz sein, die AVR-Libc
(und auch andere I/O-Bibliotheken) "C++2x-aware" zu machen, so dass
deren Nutzer ihren Quellcode ohne Änderungen weiterverwenden können.

Aber Vorsicht: Der angehängte Header ist ganz sicher weder vollständig
noch fehlerfrei, sondern dient lediglich als Proof-of-Concept. Also
bitte nicht hauen, wenn ihr den Header testet und dabei euer gesamter
AVR-Bestand in Flammen aufgeht ;-)

Das beiliegende Beispiel funktioniert mit GCC 10.1.0 und Clang 10.0.0.
Anders als Clang hat der GCC allerdings Probleme, die Operatporen <<=
und >>= in einfache 8-Bit-Shifts umzusetzen. Die anderen Operatoren,
insbesondere die häufig verwendeten |= und &= werden aber wie erwartet
übersetzt.

Anwendungsbeispiel:

#include <stdint.h>
#ifdef CLASSIC
#  include <avr/io.h>
#else
#  include "io-c++20.h"
#endif

uint8_t a;

int main() {

  PORTB |= 1<<PB3;      // 8 Bit
  PORTB &= ~(1<<PB5);
  PORTB ^= 1;
  ++PORTB;
  a = PORTB++;
  PORTB >>= 2;
  OCR1A += 4;           // 16 Bit

  return 0;
}

Generierter Assemblercode für den ATmega8:

; GCC 10.1.0           Clang 10.0.0

  sbi 0x18,3           sbi    24, 3

  cbi 0x18,5           cbi    24, 5

  in r24,0x18          ldi    r24, 1
  ldi r25,lo8(1)       in    r25, 24
  eor r24,r25          eor    r25, r24
  out 0x18,r24         out    24, r25

  in r24,0x18          in    r24, 24
  subi r24,lo8(-(1)    inc    r24
  out 0x18,r24         out    24, r24

  in r24,0x18          in    r24, 24
  add r25,r24          mov    r25, r24
  out 0x18,r25         inc    r25
  sts a,r24            out    24, r25
                       sts    a, r24

  in r24,0x18          in    r24, 24
  ldi r25,0            lsr    r24
  asr r25              lsr    r24
  ror r24              out    24, r24
  asr r25
  ror r24
  out 0x18,r24

  in r24,0x2a          in    r24, 42
  in r25,0x2a+1        in    r25, 43
  adiw r24,4           adiw    r24, 4
  out 0x2a+1,r25       out    43, r25
  out 0x2a,r24         out    42, r24

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Danke für deine Antwort & Arbeit.

von c und aliasing regeln (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und was tut man gegen die fiesen strict-aliasing Regeln?
(*(_IO<uint8_t > *)(mem_addr))

müsste ja gegen strict aliasing verstoßen.. eigentlich müsste da noch 
ein bit_cast drüber gewrapped werden

von Alias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c und aliasing regeln schrieb:
> müsste ja gegen strict aliasing verstoßen.

Nein. Warum?

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c und aliasing regeln schrieb:

> müsste ja gegen strict aliasing verstoßen..

Aliasing kann überhaupt nur dann vorliegen wie der Name andeutet), wenn 
unter wenigstens ZWEI inkompatiblen Zeigertypen auf dieselbe 
Speicherstelle zugegriffen wird.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Anders als Clang hat der GCC allerdings Probleme, die Operatporen <<=
> und >>= in einfache 8-Bit-Shifts umzusetzen.
>
> [...] Generierter Assemblercode für den ATmega8: [...]
>
>   in r24,0x18          in    r24, 24
>   ldi r25,0            lsr    r24
>   asr r25              lsr    r24
>   ror r24              out    24, r24
>   asr r25
>   ror r24
>   out 0x18,r24

Altbekanntes Problem, das nicht in avr-gcc auftritt sondern nur mit 
avr-g++:

http://gcc.gnu.org/PR82658

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wenn wir das Problem nicht lösen können, definieren wir es weg?
>
> Klingt für mich eher nach Vogel Strauß als nach einer sinnvollen
> Alternative.
>
> Ich schrieb doch schon, von mir aus soll man sowas als
> implementation-defined festlegen, oder implementation-dependant oder was
> auch immer, aber nicht einfach nur den Deckel aufmachen, und das Problem
> in der Tonne versenken wollen.

100% ACK

SFRs unterschiedlicher Controller(-Familien) sind einfach zu 
unterschiedlich, als dass sich das sinnvoll über den Sprachstandard 
regeln ließe.

Ergo: volatile sollte Implementation Defined sind, was effektiv bedeutet 
dass Compiler der (E)ABI des Hardware-Herstellers folgen.  Für AVR gibt 
es aber m.W. kein solches EABI — weder von Atmel noch von µChip.

Und zur Synchronisation von Prozesse über Core-Grenzen hinweg taugt 
volatile eh nicht, da zu "schwach".

Wie sieht's eigentlich mit den 3 avr-libc Innovationen aus: math.h 
(64-Bit double), Pimp für Multilib und mehr Support für Devices aus 
avrxmega3?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wie sieht's eigentlich mit den 3 avr-libc Innovationen aus

Ähem, hmm, ja, [verlegen guck]

будет, будет, все будет :)

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Johann L. schrieb:
>> Wie sieht's eigentlich mit den 3 avr-libc Innovationen aus
>
> Ähem, hmm, ja,

Gibt's denn Probleme mit den Änderungen?

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Jörg W. schrieb:
>> Johann L. schrieb:
>>> Wie sieht's eigentlich mit den 3 avr-libc Innovationen aus
>>
>> Ähem, hmm, ja,
>
> Gibt's denn Probleme mit den Änderungen?

Vermutlich wären sie groß genug für eine neue Release.
Was Jörg auch indirekt bestätigt hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Vermutlich wären sie groß genug für eine neue Release.

Ja, und ein Release für AVRDUDE ist schon lange überfällig. :/

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Johann L. schrieb:
>> Jörg W. schrieb:
>>> Johann L. schrieb:
>>>> Wie sieht's eigentlich mit den 3 avr-libc Innovationen aus
>>>
>>> Ähem, hmm, ja,
>>
>> Gibt's denn Probleme mit den Änderungen?
>
> Vermutlich wären sie groß genug für eine neue Release.

Muss ja keine neue Release sein, in trunk würd schon reichen.

von Carsten P. (r2pi)


Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> cbi 0x18,5           cbi    24, 5
> in r24,0x18          ldi    r24, 1

Genau, so macht man das (nicht). Nicht den Inhalt von r24 testen, 
einfach rein damit. Und dann sich beschweren und kreischen, wieso die 
eigene Anwendung zickt... Die hardwaremäßige Eingangsseite hast du 
bestimmt einfach auf den Pin gelötet und betest dann, dass alles schon 
funktioniert, bis das Geld auf dem Konto ist? So macht man den Ruf von 
Selbständigen kaputt, hauptsache schnell und billig.

von MaWin O. (mawin_original)


Bewertung
0 lesenswert
nicht lesenswert
Carsten P. schrieb:
> Genau, so macht man das (nicht). Nicht den Inhalt von r24 testen,
> einfach rein damit. Und dann sich beschweren und kreischen, wieso die
> eigene Anwendung zickt...

Ehm, was bitte?
Schlecht geschlafen?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carsten P. schrieb:
> Genau, so macht man das (nicht).

Hast du dir Yalus Beitrag denn überhaupt durchgelesen, bevor du dich 
hier nach 1,5 Monaten über sowas beklagst?

Das ist die Ausgabe des Compilers! Der darf das, denn das ist in seinem 
ABI so festgelegt, wofür R24 verwendet werden kann.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.