{"id":103971,"date":"2022-05-06T15:36:45","date_gmt":"2022-05-06T13:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-nabora-kompilyatorov-gcc-12"},"modified":"2022-05-06T15:36:45","modified_gmt":"2022-05-06T13:36:45","slug":"reliz-nabora-kompilyatorov-gcc-12","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/reliz-nabora-kompilyatorov-gcc-12","title":{"rendered":"Versione del set di compilatori GCC 12","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo un anno di sviluppo, \u00e8 stata rilasciata la versione 12.1 del compilatore GCC, il primo importante rilascio della nuova serie GCC 12.x. Secondo il nuovo schema di numerazione delle versioni, la versione 12.0 \u00e8 stata utilizzata durante lo sviluppo, e poco prima del rilascio di GCC 12.1 \u00e8 stata gi\u00e0 creata la ramificazione GCC 13.0, da cui sar\u00e0 generato il prossimo importante rilascio, GCC 13.1. Il 23 maggio il progetto celebrer\u00e0 35 anni dalla pubblicazione della prima versione di GCC. <\/p>\n
Principali modifiche: <\/p>\n
\n
\u00c8 stato aggiunto il supporto per il formato di debug CTF (Compact Type Format), che consente una memorizzazione compatta delle informazioni sui tipi C, le relazioni tra funzioni e i simboli di debug. Se integrato negli oggetti ELF, il formato permette di utilizzare le tabelle dei simboli EFL per evitare la duplicazione dei dati.\n
\u00c8 stata dichiarata obsoleta la supporto per il formato di memorizzazione delle informazioni di debug \u00abSTABS\u00bb, creato negli anni '80.\n
Continua il lavoro per ampliare il supporto per i futuri standard C2X e C++23 per i linguaggi C e C++. Ad esempio, \u00e8 stato aggiunto il supporto per l'espressione \u00abif consteval\u00bb; \u00e8 consentito l'uso di auto negli argomenti delle funzioni (\u00abf(auto(g()))\u00bb); \u00e8 consentito l'uso di variabili non letterali, goto e etichette in funzioni dichiarate come constexpr; \u00e8 stato aggiunto il supporto per operatori di indicizzazione multidimensionale operator[]; in if, for e switch sono state ampliate le funzionalit\u00e0 dei blocchi di inizializzazione (\u00abfor (using T = int; T e : v)\u00bb).\n
Nella libreria standard C++ \u00e8 stato migliorato il supporto per le sezioni sperimentali degli standard C++20 e C++23. \u00c8 stato aggiunto il supporto per std::move_only_function, , std::basic_string::resize_and_overwrite, , e std::invoke_r. \u00c8 consentito l'uso in funzioni constexpr di std::unique_ptr, std::vector, std::basic_string, std::optional e std::variant.\n
Nel frontend per il linguaggio Fortran \u00e8 stato fornito il supporto completo per la specifica TS 29113, che descrive le capacit\u00e0 di garantire portabilit\u00e0 tra codice scritto nei linguaggi Fortran e C.\n
\u00c8 stato aggiunto il supporto per l'estensione __builtin_shufflevector(vec1, vec2, index1, index2, \u2026), precedentemente aggiunta in Clang e che fornisce una chiamata unica per eseguire operazioni comuni di permutazione e mescolamento dei vettori.\n
Quando si utilizza il livello di ottimizzazione \u00ab-O2\u00bb, \u00e8 attivato per impostazione predefinita l'uso della vettorizzazione (sono attivi i modi -ftree-vectorize e -fvect-cost-model=very-cheap). Il modello \u00abvery-cheap\u00bb consente la vettorizzazione solo se il codice vettoriale pu\u00f2 sostituire completamente il codice scalare vettorizzabile.\n
\u00c8 stata aggiunta la modalit\u00e0 \u00ab-ftrivial-auto-var-init\u00bb che include l'inizializzazione esplicita delle variabili nello stack per il monitoraggio dei problemi e il blocco delle vulnerabilit\u00e0 legate all'uso di variabili non inizializzate.\n
Per i linguaggi C e C++ \u00e8 stata aggiunta la funzione integrata __builtin_dynamic_object_size per determinare la dimensione di un oggetto, compatibile con una funzione simile di Clang.\n
Per i linguaggi C e C++ \u00e8 stato aggiunto il supporto per l'attributo \u00abunavailable\u00bb (ad esempio, \u00e8 possibile contrassegnare le funzioni per le quali, se vengono utilizzate, verr\u00e0 restituito un errore).\n
Per i linguaggi C e C++ \u00e8 stato aggiunto il supporto per le direttive di preprocessore \u00ab#elifdef\u00bb e \u00ab#elifndef\u00bb.\n
\u00c8 stato aggiunto il flag \u00ab-Wbidi-chars\u00bb per generare un avviso in caso di utilizzo scorretto di caratteri UTF-8 che alterano l'ordine di visualizzazione del testo bidirezionale.\n
\u00c8 stato aggiunto il flag \u00ab-Warray-compare\u00bb per generare un avviso quando si tenta di confrontare due operandi che fanno riferimento a array.\n
Continua l'implementazione degli standard OpenMP 5.0 e 5.1 (Open Multi-Processing), che definiscono API e modalit\u00e0 di utilizzo di metodi di programmazione parallela su sistemi multi-core e ibridi (CPU+GPU\/DSP) con memoria condivisa e blocchi di vettorizzazione (SIMD).\n
Migliorata l'implementazione della specifica di programmazione parallela OpenACC 2.6, che definisce i mezzi per l'offloading delle operazioni su GPU e processori specializzati, come NVIDIA PTX.\n
Nel backend di generazione del codice per l'architettura x86 \u00e8 stata aggiunta la supporto per le istruzioni estese Intel AVX512-FP16 e per il tipo _Float16.\n
Per l'architettura x86 \u00e8 stata aggiunta una protezione contro le vulnerabilit\u00e0 nei processori causate dall'esecuzione speculativa delle istruzioni dopo operazioni di salto incondizionato. Il problema si verifica a causa dell'elaborazione anticipata delle istruzioni che seguono immediatamente l'istruzione di salto in memoria (SLS, Straight Line Speculation). Per abilitare la protezione \u00e8 stata proposta l'opzione \u00ab-mharden-sls\u00bb.\n
Nell'analizzatore statico sperimentale \u00e8 stata aggiunta la definizione dell'uso di variabili non inizializzate. \u00c8 stata introdotta un'iniziale supporto per l'analisi del codice assembly nelle inserzioni inline. \u00c8 stato migliorato il tracciamento dello stato della memoria. \u00c8 stato riscritto il codice per la gestione delle espressioni switch.\n
Aggiunti 30 nuove chiamate in libgccjit, una libreria condivisa per l'integrazione di un generatore di codice in altri processi e per l'organizzazione della compilazione JIT del bytecode in codice macchina.\n
Nel backend per la generazione di bytecode BPF \u00e8 stata aggiunta la supporto per il meccanismo CO-RE (Compile Once \u2014 Run Everywhere), che consente di compilare il codice dei programmi eBPF per il kernel Linux una sola volta e di utilizzare un caricatore universale speciale, che adatta il programma caricato al kernel attuale e ai tipi BTF (BPF Type Format). CO-RE risolve il problema della portabilit\u00e0 dei programmi eBPF compilati, che in precedenza potevano essere utilizzati solo con la versione del kernel per cui erano stati compilati, poich\u00e9 la posizione degli elementi nelle strutture dati cambia da versione a versione.\n
Nel backend per l'architettura RISC-V \u00e8 stata aggiunta la supporto per le nuove estensioni dell'architettura del set di istruzioni zba, zbb, zbc e zbs, oltre alle estensioni ISA per le operazioni crittografiche vettoriali e scalari. \u00c8 stata assicurata, di default, la supporto per la specifica RISC-V ISA 20191213. \u00c8 stata aggiunta l'opzione -mtune=thead-c906, che include le ottimizzazioni per i core T-HEAD c906.\n
Nel backend di generazione del codice per GPU AMD basate sull'architettura micro GCN \u00e8 stata aggiunta la supporto per il tipo __int128_t\/integer(kind=16). \u00c8 stata resa possibile l'utilizzo di fino a 40 gruppi di lavoro per blocco computazionale (CU) e fino a 16 fronti di istruzioni (wavefront, insieme di thread, eseguiti in parallelo dal SIMD Engine) per gruppo. In precedenza era consentito l'uso di un solo fronte di istruzioni per CU.\n
Nel backend NVPTX, progettato per generare codice utilizzando l'architettura dell'insieme di istruzioni NVIDIA PTX (Parallel Thread Execution), \u00e8 stata aggiunta la possibilit\u00e0 di utilizzare le opzioni '-march', '-mptx' e '-march-map'. \u00c8 stata implementata la supporto per PTX ISA sm_53, sm_70, sm_75 e sm_80. Di default, viene utilizzata l'architettura sm_30.\n
Nel backend per i processori PowerPC \/ PowerPC64 \/ RS6000 sono state riscritte le implementazioni delle funzioni integrate. Sono state documentate le funzioni integrate __builtin_get_texasr, __builtin_get_texasru, __builtin_get_tfhar, __builtin_get_tfiar, __builtin_set_texasr, __builtin_set_texasru, __builtin_set_tfhar e __builtin_set_tfiar.\n
Nel backend per l'architettura ARM\/AArch64 \u00e8 stata aggiunta la supporto per le CPU Arm Ampere-1 (-mcpu\/-mtune ampere1), Arm Cortex-A510 (cortex-a510), Arm Cortex-A710 (cortex-a710) e Arm Cortex-X2 (cortex-x2). Sono stati aggiunti nuovi varianti dell'architettura ARMv8 da utilizzare con l'opzione «-march»: armv8.7-a, armv8.8-a, armv9-a. \u00c8 stata implementata una nuova funzione integrata nel compilatore per il C (Intrinsics) per il caricamento e il salvataggio atomico dei dati in memoria, basata sull'uso di istruzioni avanzate ARM (ls64). \u00c8 stata aggiunta la supporto per accelerare le funzioni memcpy, memmove e memset tramite l'estensione ARM mopsoption.\n
\u00c8 stata aggiunta una nuova modalit\u00e0 di verifica «-fsanitize=shadow-call-stack» (ShadowCallStack), attualmente disponibile solo per l'architettura AArch64 e funzionante durante la compilazione del codice con l'opzione «-ffixed-r18». Questa modalit\u00e0 offre protezione contro la sovrascrittura dell'indirizzo di ritorno da una funzione in caso di overflow del buffer nello stack. Il principio di protezione consiste nel memorizzare l'indirizzo di ritorno in un «stack ombra» separato dopo aver passato il controllo alla funzione e nel recuperare questo indirizzo prima di uscire dalla funzione. <\/ul>\n