-
Thread
universelle Tasterabfrage von Peter Dannegger
Schalte mal die Optimierung aus. Gruß Fabian
Doch, das Problem kenne ich vom AVR-Studio mit GCC auch. Wenn die Optimierung zu aggressiv ist, dann kann der Debugger (via JTAG-ICE2) die Sprünge nicht mehr korrekt anzeigen. Bisher hatte ich solche Probleme mit Os oder O3. Mit O2 gehts im Allgemeinen
-
Thread
Bekomme USART nicht initialisiert!
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#UART_initialisieren
Optimierung die Zeiten viel länger sind, als eingestellt.
-
Thread
Size Benchmark mit GCC, Imagecraft und IAR
: Ich werde bei der Auswahl des Controllers eine Nummer grösser einsteigen und GCC nehmen. MfG
dem GCC 3.4.x und dem IAR, insofern wäre es interessant, den gleichen Code auch noch einmal auf einem GCC 4.1.0 zu testen. Mehmet, falls du den Code freigeben kannst, biete ich mich für einen Test an.
-
Thread
Nucleo board 401 verliert Programm
nur in den RAM geschrieben wird... Der Haupt-Unterschied zwischen Debug & Release sind die Optimierungen. Man kann auch Relase-Builds debuggen und Debug-Builds ohne Debugger ausführen.
. Release-Mode nicht. Alle mir bekannten IDE's nutzen das als Unterscheidung ob ohne bzw. mit Optimierungen und Debug-Informationen kompiliert wird (also z.B. ob -g -O0 oder -Os -DNDEBUG an den GCC übergeben wird). Was ist denn "Debugger-Freundliches" Flashen? Ich übergebe an den JLink.exe die Option
-
Thread
ATMEGA128 und for Schleife
Code einfach nicht mehr, weil sie nicht benötigt wird. Debuggen sollte man immer *OHNE* Optimierung.
überhaupt sinnvoll läuft (Stichwort Timing) - auch ohne Optimierungen debuggen, da das einfacher ist.
-
Thread
Bizarrer Firmware crash - ATmega4808. Wie Debuggen?
angeht, so werden diese i.d.R in den Release Notes angekündigt sofern erwähnenswert: https://gcc.gnu.org/gcc-8/changes.html#avr https://gcc.gnu.org/gcc-9/changes.html#avr https://gcc.gnu.org/gcc-10/changes.html#avr https://gcc.gnu.org/gcc-11/changes.html#avr https://gcc.gnu.org/gcc-12/changes.html#avr https://gcc.gnu.org/gcc-13/changes.html#avr https://gcc.gnu.org/gcc-14/changes.html#avr https://gcc.gnu.org/gcc-15/changes.html#avr https://gcc.gnu.org/gcc-16/changes.html#avr https://gcc.gnu.org/gcc-17/changes.html
-
Thread
Klasse Optimierung Laufzeit und Speicher CPP
Harald K. schrieb im Beitrag #7650748: > Premature optimization is the root of all evil. Optimierung auf Lesbarkeit keineswegs. Und das ist hier durchaus relevant.
ähnliches: ein int besser als Rückgabewert statt als Referenz. Oder gar ein struct mit 2 ints (kann avr-gcc in Registern halten).
-
Thread
Arithmetikfunktionen in AVR GCC
, dass der ICC-Compiler Arithmetik-Funktionen im Umfang von 1033 Bytes eingebaut hat, der GCC-Compiler hingegen 3292 Bytes. Als Optimierung ist -Os eingestellt, andere Einstellungen liefern noch mehr Code. Die Linker-Option -lm , welche in einem anderen Beitrag vorgeschlagen wurde, bringt keine
nur die Grundrechenarten und Konvertierungen verwendet, höhere mathematische Funktionen nicht. Der GCC-Compiler baut dafür Library-Funktionen aus der "libgcc.a" im Umfang von mehr als 3KBytes ein. Viele Grüße
-
Thread
Hartnäckiger Heisenbug auch ohne Optimierung, am PC (x86_64)
das sein dass es doch die Programmausführung massiv beeinflußt? Zum Kompilieren verwende ich: gcc -Wall -D_REENTRANT -lm -pthread -O0 -o logger logger.c -lrt
war schlicht Call bei value angewendet wo tatsächlich Call by reference gemacht wird. Da könnte der GCC eigentlich eine Warnung ausgeben weil hier eine Race Condition vorliegt, aber bisher macht er das nicht.
-
Thread
probleme mit der Syntax __irq in Ecllipse
){ // A lot of Work VICVectAddr = 0; // Acknowledge Interrupt } [/c] Eher für den GCC geeignet ist (frei nach [[ARM-elf-GCC-Tutorial]]) /Ernst
Vorsicht bei Verwendung dieses Attributs bei arm-gcc (wie auch in Yagarto enthalten). Zumindest ältere Versionen des kommen dabei in straucheln, wenn bei eingeschalteter Optimierung nicht alles im "ARM-mode" kompiliert wird (und mglw. anderen Kombinationen
-
Thread
memcpy funktioniert nicht
gab's doch mal was... Bug 53016 - memcpy optimization can cause unaligned access on ARM https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016 Mit dem schönen Status: RESOLVED INVALID
Programmierer geirrt, nicht der Compiler. Wenn man es partout nicht will, dass der Compiler Optimierungen in Funktionen der Standardbibliothek vornimmt, kann man natürlich immer im freestanding mode compilieren (-ffreestanding) – aber damit verliert man dann /alle/ derartigen Optimierungen auf
-
Thread
gcc: Fehlermeldung: findet Funktionen nicht --> ?
die meine_lib.h zu kopieren, allerdings ohne Erfolg. Was kann noch falsch sein? Oder muss ich dem GCC-dings explizit die meine_lib.h auch noch angeben? Macht für mich keinen Sinn, da dann die #include Anweisung überflüssig ist. Wo könnte es noch Fallstricke geben?
auch zusammengelinkt werden. Am einfachsten geht das, wenn du beim gcc AUfruf einfach beides angibst. gcc test.c meine_lib.c > muss ich dem GCC-dings explizit die meine_lib.h auch noch angeben? Macht > für mich keinen Sinn, da dann die #include Anweisung überflüssig
-
Thread
Compiler optimiert Code weg, was er nicht sollte
aufgerufen werden. Das würde sich entschärfen, wenn die Optimierung ausgeschaltet wird. Klappt eine schnelle Ausgabe eines "Hello World" Textes mit eingeschalteter Optimierung? Wieso wird in lcd_hex() lcd_write() statt lcd_putc() benutzt? Sowas macht mich
Assembler-Listing erzeugen lassen kannst und diese *.LSS Datei angeben lönntest. Dann sieht man welchen Code GCC aus deinem Quelltext produziert hat.
-
Thread
Structs in ISR
> [...] Mein static variablen aber auch? Verwendest Du überhaupt Compiler-Optimierungen? Wenn nicht, sollte ein volatile eigentlich nicht notwendig sein. Aber Du machst die Funktionalität Deines Programms von den Compiler-Optionen (und der Implementierung des Compilers) abhängig
Ich habe volle OPtimierung eingeschaltet
-
Thread
Unsigned Char vergleich beim AVR GCC
dann Bit 0 testen zu können, statt gleich auf's gewünschte Bit loszugehen. Nobody is perfect, auch gcc/avr nicht.
warum nicht? Klar, es müsste ihm ,,nur'' jemand beibiegen. Da alle Architekturen, für die am GCC ,hauptberuflich' gebaut wird, dieses Problem aber nicht haben (deren Register sind eh' alle 32 bits breit), muss sich da wohl jemand aus der Microcontroller-Ecke drum kümmern, dass derartige Optimierungen
-
Thread
LPC2148 ARM7 Interruptroutine beendet nicht richtig
den Saurier und macht es eurer > Ansicht nach Sinn mal umzusteigen:)? Fall ja, auf was bitte? > gcc finde ich im Prinzip für meine Bedürfnisse schon brauchbar. GCC Varianten gibts reichlich, als freie Version beispielsweise Yagarto. Kostenfrei kommerziell mitsamt IDE von Atollic, wenn man kein
übersetztem Code ist für manche Überraschung > gut. Auch dies könnte so ein Effekt sein. Dann kann ich Optimierung mal gleich vergessen - oder? >GCC Varianten gibts reichlich, als freie Version beispielsweise Yagarto. >Kostenfrei kommerziell mitsamt IDE von Atollic, wenn man kein C++ >braucht. Als reine
-
Thread
Verständnis AVR Interrupts Gesperrt
auch doofe Compiler wenn sie optimieren, z.B. bei Inlining oder Loop Unrolling. Insbesondere bei Optimierung auf Geschwindigkeit.
könnte ich dem GCC das schon relativ problemlos beibiegen. Aber der Rest ist Sackstand. Letztlich liefe es darauf hinaus, das halbe Programm doch wieder in Asm zu schreiben (mit der unsäglich grottigen gcc-Inkarnation
-
Thread
MEGA 128 verrechnet sich
aufweisen. Zum Problem selber: Kann's vielleicht sein, dass der Compiler durch irgendwelche Code-Optimierungen die Hälfte vom Code weglässt? Ein ähnliches Problem hatte ich mal ... Abhilfe: Entweder Optimierungen komplett abschalten oder die betreffenden Variablen mit "volatile" deklarieren (bewirkt, das
Arbeit mit doubles sehen. Das Programm habe ich mal auf einem x86 kompiliert mit verschiedenen Optimierungen: ohne: eps is 1.11022e-16 (iter is 53) -O3: eps is 5.42101e-20 (iter is 64) Man sieht sehr deutlich, daß die Genauigkeit der Berechnungen von der Optimierung abhängt. Du kann also in
-
Thread
Bitverarbeitung
und man den Simulator für so einfache Routinen nutzen kann, ehe man die HW am Tisch hat. Die Optimierung habe ich tatsächlich abgeschaltet. Wollte das erst während des Projektverlaufes optimieren. Gibt es keinen Weg das ohne Si zu testen? Gruß Christian
> alternativ hab ich versucht: Was ist falscg daran, die ADC Routine aus dem AVR-GCC-Tutorial als Ausgangspunkt zu nehmen?
-
Thread
Digilent Nexys3 (Spartan6), Microblaze und die Interrupts
mikroblaze gcc-kompilerschalter -s (Optimierung auf size) aktivieren
Bit Wurschtler schrieb im Beitrag #4500639: > mikroblaze gcc-kompilerschalter -s (Optimierung auf size) aktivieren Mit Optimierung auf size sind es leider noch 2984 byte.
-
Thread
msp430-gcc Segmentation Fault
Hallo, wenn ich ein Sourcefile mit dem msp430-gcc ohne Optimierung kompiliere funktioniert alles. Versuche ich das selbe File mit der Optimierung ( -Os) zu kompilieren beendet sich der Compiler mit einer Segmentation Fault. Ich habe schon versucht
Langsame Lösung: Programm gründlich auf das Problem reduzieren (also kein 10000 Zeilen-Paket) und GCC-Bugzilla und ggf passende Mailing-Liste drauf ansetzen.
-
Thread
Interrupt Verständnis Frage
mit dem "volatile". Das denke ich auch. Außerdem solltest Du bei Gelegenheit mal ne neue AVR-GCC-Version installieren. SIGNAL ist veraltet!
ihren Wert acuh ändern, ohne dass du das im Code ablesen kannst. Halte dich also mit möglichen Optimierungen erst mal etwas zurück.
-
Thread
Eine Zeile Code, 2K flash
Hast du die Optimierung des Compilers eingeschaltet? Wenn ja auf welche Optimierung?
Helfer schrieb im Beitrag #5096641: > Hast du die Optimierung des Compilers eingeschaltet? Wenn ja auf welche > Optimierung? Ja, -Os
-
Thread
Kann man folgenden Code platzsparender schreiben
4.7.2 oder höher) bekommt man hier: http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
vielleicht wären ja solche Artefakte (zusammen mit der ja offenbar > insgesamt deutlich mieseren Optimierung) endlich mal ein Anlass für > einen Upgrade der Toolchain? Ja, damit hadere ich schon die ganze Zeit, die Lösung mit aktuellerem GCC und Studio 4.18 wäre eine gute Alternative um das überladene
-
Thread
atmega32 Interrupt Problem
ich nicht so. Auf dem Board ist ein ATMega32. Kompiliert habe ich mit (Resultat vom makefile): avr-gcc -c -Wall -Os -mmcu=atmega32 -o main.lo avr-gcc -o main main.lo avr-objcopy -j .text -j .data -O ihex main main.hex avrdude -cpony-stk200 -patmega32 -Uflash:w:main.hex:i
Im avr-gcc-Aufruf für das Linken fehlt die -mmcu= Option.
-
Thread
Frage: AVR-GCC
Bernd schrieb im Beitrag #4427074: > Keine Variablen in _delay_us mehr erlaubt? Seit welcher AVR-GCC Version > ist das so? M.W.n. war das schon immer so. D.h., erlaubt sind sie schon, aber es kommt nicht das dabei heraus, was du erwartest mangels Gleitkomma-Optimierung... Mach ne Schleife und
Guckst Doku: http://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html
-
Thread
Right-shift bei msp430
%#x\n", val1 ^ (val2>>4)); return 0; }[/c] welches so kompiliert wird: [code] msp430-gcc -mmcu=msp430g2553 -O0 -g -W -Wall -std=c99 -c -o main.o main.c msp430-gcc -mmcu=msp430g2553 -O0 -g -o firmware.elf main.o [/code] Wenn ich dieses Programm nun auf http://www.msp430emulator.com
Allerdings wär man hier mit CLRC/RRC/RRA/RRA/RRA besser bedient. Vielleicht denkt der Compiler bei Optimierung daran.
-
Thread
Probleme mit AVR Studio Optimierung bei uint32_t
Programmieroberfläche und compiler? AVR Studio kenne ich nicht mehr (zu lange her), der C-Compiler ist der AVR-GCC, und von dem halte ich nicht soooooo besonders viel.
funktionierts ja wies soll... bloß beim debuggen eben ned, aber wenn ich das weiß, dann muss ich halt die optimierung ausschalten, wenn ich debugge. Vielen Dank für eure Hilfe!
-
Thread
C++ Compiler für ARM (STM32 M0-M3)
nachher nochmal versuchen dort einzubinden. Gibt es eigentlich gravierende Unterschiede zwischen gcc und Mikroe? Kann gcc irgendwas mehr was mikroe nicht kann? Bugs haben sicher sowieso immer alle..irgendwo..
Chance, dass ein Bug behoben wird, da GCC/ARM weltweit sehr oft genutzt wird. Bei der Optimierung dürfte ein deutlicher Unterschied bestehen. > Kann gcc irgendwas mehr was mikroe nicht kann? Ich kenne microe nicht, aber bei der Unterstützung
-
Thread
Probleme mit WINAVR-20070525
Funktion. Der wesentliche Unterschied alter WinAVR <-> neuer WinAVR (2007) ist die sehr erweiterte Optimierung des moderneren GCC. Ein typ. Fall ist z.B. das ersatzlose Streichen von Leerschleifen, die manche Leute gerne als Ersatz für die Wartefunktionen (_delay_ms,...) benutzt hatten. Vielleicht kannst
los, dass ich mir das Leben mit dem AVR nur unnötig schwer mache, weil ich die Möglichkeiten des AVR GCC nicht nutze. Bis dann Marco
-
Thread
Welche Low Cost 32 Bit MCU Familie? Gesperrt
auf Messen auch kostenlos verteilt. Mit Speck fängt man Mäuse... Und C++ incl. STL konnte man dank gcc auch früh auf den Cortex-M nutzen.
Umso wichtiger ist halt die > Dokumentationen. Das wird mit dem Programmier-Spaß bei der Optimierung mehr als ausgeglichen :) Aber genau so ist es: Dokumentation zu Sinn und Zweck, dem Verfahren, den verwendeten Parametern ist das Ein&Alles. Wenn nun auch noch der Code selber programmsprachlich
-
Thread
Frage zu selbstgeschriebener Funktion - Laufzeit gegenüber Compiler-Variante
hast du wenigsten die Optimierung eingeschaltet? das Problem könnte auch sein das du eine funktion für beides hast. Wenn du es in 2 funktionen zerlegst, dann müsste es schneller sein weil die vergleiche wegfallen.
Mal so nebenbei - arbeitet jemand mit IAR und kann mir sagen, wie ich die Optimierungen einschalte? Oder wie ich einen Release-Build mache?
-
Thread
Device full
Optimierung auf "-Os"?
>Optimierung auf "-Os"? Das gehört zum Compiler-Aufruf. Sollte irgendwo im Makefile stehen...
-
Thread
Software Zertifizierung
sich diese aussage auf eine eingefrorene version des Compilers. Und oft wird verlangt Compiler-Optimierungen auszuschalten. Also prinzipiell kann man den Gcc zertifizieren, da seine Sourcen Offen liegen sollte das sogar einfach möglich sein. Aber Vorsicht, es gibt gcc-Varianten die verhalten lt
? Nein, GCC reicht nicht.
-
Thread
Abstrakte Basisklasse - Fehlermeldung in C++
alleine verwechselt man sonst evtl mit dem "pure"-Funktionsattribut (==Seiteneffektsfrei), das der GCC z.B. für die Optimierung verwendet. (Offtopic: mit dem Prototyp [c]int my_strlen(char*) __attribute__ ((pure));[/c] darf der Compiler dann z.B. [c]int x=my_strlen(a)+my_strlen(a);[/c]
alleine verwechselt man sonst evtl mit dem > "pure"-Funktionsattribut (==Seiteneffektsfrei), das der GCC z.B. für die > Optimierung verwendet. Merci. Werds mir merken. Guter Punkt.
-
Thread
ATtiny2313 Optimierung Problem
Tut er im großen und ganzen auch aber unter bestimmten Umständen gibt es falsche Werte. Ohne Optimierung läuft dass ganze durch, aber dann bringe ich meine Tastenabfrage nicht unter ;-) Der Fehler tritt z.B. bei hue = 510 auf (0x01FE), dann springt der Wert für blau urplötzlich von 0 auf 0xE3 (Das
volatile, Stack overflow bin ich mir nicht sicher, brauchen Routinen auch Stack? Data bringt der gcc 71 Byte [55%], und auch das Kapseln der CalcValues Routine mit cli()/sei() um Interruptprobleme während der Berechnung auszuschliessen hat nichts gebracht. Der zweite HSB Code (auskommentiert) läuft
-
Thread
Funktionspointer als Parameter
Ja, mit C++. GCC bringt dafuer g++ mit.
optimiert wird, ermöglicht das Inlining über Modulgrenzen hinweg. Mit Funktionszeigern ist diese Optimierung i.d.R. nicht möglich, weil der Wert so eines des Zeigers wesentlich schwerer zu eruieren ist als ein Symbol. Allerdings könnte weak hier dem Compiler / LTO reingrätschen und solche Optimierungen
-
Thread
C Frage an die Könner
wird nicht optimiert, sondern ausgerechnet. Beim Kompilieren. Kann man so gesehen auch als Optimierung betrachten ;-)
wird nicht optimiert, sondern ausgerechnet. > > Beim Kompilieren. Kann man so gesehen auch als Optimierung betrachten > ;-) Da es mehr oder weniger schon vom Compiler ausgerechnet werden /muss/ würde ich nicht von Optimierung sprechen.
-
Thread
Position von Code + Variablen in Binary
Werner M. schrieb im Beitrag #3980641: > Was ist "der Linker"? Nachdem das Forum hier "GCC" heißt, wirds wohl auch der GCC Linker sein. Also "ld" um ihn mal zu rufen... > Warum sollten verschiedene Linker die Variablen > nicht verschieden ablegen? exakt das war meine Frage. Gibt es
im Beitrag #3980650: > Werner M. schrieb: >> Was ist "der Linker"? > > Nachdem das Forum hier "GCC" heißt, wirds wohl auch der GCC Linker sein. > Also "ld" um ihn mal zu rufen... > >> Warum sollten verschiedene Linker die Variablen >> nicht verschieden ablegen? > > exakt das war meine Frage
-
Thread
Warum springt der Debugger hier hin?
Hauptprogramm verwendet werden, müssen als "volatile" deklariert sein 2. Debuggen mit eingeschalteter Optimierung (-Os) geht praktisch gar nicht, da der Compiler Befehle umsortiert, Variablen nicht in den Speicher zurück schreibt usw. Schalt mal die Optimierung aus und versuche es nochmal. Gruß Roland
Klappt auch nicht! Hab die Optimierung rausgenommen. Hab für h mal volatile int global Deklariert, klappt auch nicht. Und hab mal die itoa Funktion ins Hauptprogramm verschoben, springt trotzdem in die Routine Gruß Tommy
-
Thread
MPLAB X Broken Breakpoint
Problemen (broken Breakpoints), nicht der Simulator. Einen Versuch ist es aber wert. Die Optimierungen im Compiler sollte man zum Debggen auch abschalten.
Andreas S. schrieb im Beitrag #3680338: > Was meinst du, > Gast, mit "Optimierung abschalten"? Wo mache ich das? Unter "Project properties" --> XC16(Global options): XC16-gcc --> Dort unter "Option categories": Optimizations --> "Optimization level" auf 0 setzen. (
-
Thread
Wie aktuell ist K&R C?
hatte ich schon geschrieben: Ich ignoriere großzügig sämtliche Hinweise auf irgend- welche "Optimierungen" und "Kurzschreibweisen".
schrieb im Beitrag #6192184: > Ich ignoriere großzügig sämtliche Hinweise auf irgend- welche > "Optimierungen" und "Kurzschreibweisen". Hast Du Beispiele? Meinst Du sowas wie *d++=*s++ statt Langversion?
-
Thread
Optimierung scheint zu gut (Code wird nicht ausgeführt)
>Optimierung scheint zu gut (Code wird nicht ausgeführt) An der Optimierung liegt es nicht, und der Code wird auch nicht wegoptimiert. Wenn er nicht ausgeführt wird, kanns nur daran liegen, daß [c]if (Ret
82 std Y+2, r1 ; 0x02 d2: 19 82 std Y+1, r1 ; 0x01 [/c] r1 ist bei GCC immer 0, wenn ich mich nicht irre.
-
Thread
effiziente Initialisirung mit Nullen
Entwickler der glibc gefragt. Er muss > dann memset anders implemtieren. memset ist im Falle von gcc im Compiler implementiert, wie ein Großteil der Standard-Blibliothek. Siehe http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Other-Builtins.html#Other-Builtins > Die Stringbefehle der CPU werden kaum
Peter II schrieb im Beitrag #2743994: > Und wenn gcc hier diese befehle bei memeset verwendet, dann vermute ich > ganz stark das jemand dieses expliziert von hand codiert hat. /Alles/ im GCC hat jemand explizit von Hand codiert. ;-) Oder was dachtest
-
Thread
Transistortester AVR
Software/trunk). Die 1.04k Version ist im Software/tags Ordner als Zip-File abgelegt. Das Meckern des gcc Compilers muß an einer anderen gcc Version liegen. Wenn diese Compilerversion einen const haben will, kann man bei Zeile ~360 in Transistortester.h die Anweisungen mit "extern const" statt "extern
aber in der Arbeitskopie hinzufügen. Wenn neuere gcc Versionen weniger gut optimieren, ist es vielleicht keine gute Idee, diese zu benutzen. Grüße, Karl-Heinz
-
Thread
Mini 2Kanal Oszi per STM32F429-Disco Board
Hier die Änderung, mit der das Oszilloskop auch mit EmBlocks bzw. Optimierung funktioniert: in stm32_ub_systick.h : volatile uint32_t GUI_Timer_ms; ("volatile" empfiehlt sich auch an anderen Stellen, an denen Variablen z.B. im ISR oder anderen Threads modifiziert
per Default "um die Ohren", GCC nicht. Erstaunlich dass solche Fehler dem Hersteller nicht auffallen. Was mir bei meinem STM32F429-Board im Betrieb als Oszilloskop auffiel: Gelegentlich klimpern die niederwertigen Bits vom
-
Thread
sbi und cbi in C
Optimierung einschalten. Bei einigen Ports (z.B. PORTF) geht cbi, sbi nicht mehr.
. Bei dem selben Controller und der selben Optimierungs-Einstellung? Kann ich nur schwer glauben.
-
Thread
Was ist mit dem avr-gcc 12.x passiert? Internal Compiler Errors Gesperrt
Programmen, wie die 2 kleinen Programme Eingangs zeigen. Je größer das Programm umso seltener. Betrifft avr-gcc 10, 11 und 12, wobei die Häufigkeit mit dem 12er gefühlt zugenommen hat. Mich wundert nur das gerade Compiler Errors nicht so ernst genommen werden. Irgendwelche Optimierungen sind doch eher zweitrangig
du schon mal nen Bug in deine Software gehabt, nachdem mal alles funktioniert (hatte)? Ist bei GCC auch so. Jedes Jahr im Frühjahr gibt's eine Major Release, also eine Release, die auch neue Features hat. Dazu gehören neue Sprachen wie Rust oder Modula-2, neue Backkends wie Risc-V, neue Optimierungen
-
Thread
AVR-GCC: Zugriff auf Bytes in uint16, uint32.
Konstrukten direkt auf die Register zuzugreifen, in > denen die Werte liegen? Der Quellcode vom GCC ist öffentlich - niemand hindert dich.
Letzte Woche kam ja raus, dass die Optimierung hinter -fsplit-wide-types den Code auch mal aufbläst statt ihn zu reduzieren (ist als Bug in Arbeit aber noch ohne Lösung). Dieser Teil von GCC ist mit 4.3 neu hinzugekommen, vorher gab's das nicht
-
Thread
Build/Rebuild problem
Ich habe diesmal eine "merkwürdigkeit" beim kompilieren meines projektes mit optimierung in avrstudio bemerkt: Ich habe in meinem projekt eine struktur, die quasi überall im code als globale variable verwendet wird. Wenn ich zu dieser struktur nun elemente hinzufüge, ist gcc offenbar
http://gcc.gnu.org/lists.html Die Macher des GCC sind dort. Nicht hier.