Cosa si dovrebbe fare quando l'aggiornamento del compilatore introduce bug nel progetto esistente?

Spesso, "l'aggiornamento del compilatore ha introdotto un bug" significa davvero "l'aggiornamento del compilatore ha rivelato un bug esistente".

Questo è particolarmente vero per C e C ++, dove le specifiche del linguaggio hanno molte aree in cui il comportamento di tale e così non è definito. L'ottimizzazione aggressiva può causare cambiamenti nel comportamento del codice che si allontana dall'involucro di ciò che viene definito.

(OTOH, potrebbe essere un vero bug del compilatore / ottimizzatore, tuttavia, prima di iniziare a puntare le dita, hai bisogno di prove concrete.

What steps should be taken when this kind of situation occurs?

Ci sono alcune idee:

• Ricompila con gli avvisi del compilatore al massimo e vai a correggere il codice in modo che gli avvisi scompaiano.

• Esegui il codice tramite Lint o un correttore di bug equivalente e risolvi ogni problema segnalato.

• Riduci / rimuovi l'ottimizzazione. Il lato negativo è che il tuo codice verrà eseguito più lentamente.

• Ripristina il vecchio compilatore. Il rovescio della medaglia è che rischi di rimanere bloccato.

• Consulta il database delle note di rilascio / forum / problemi per la suite di sviluppo per vedere se ci sono indizi su ciò che potrebbe avere delle modifiche.

• Se sei disposto a svolgere qualche difficile lavoro di investigazione, prova a isolare la posizione del problema su un determinato file, quindi confronta il codice macchina delle versioni funzionanti / non funzionanti del codice.

Also when upgrading compiler, what should be done to ensure that it will not break any build?

Non c'è niente che tu possa davvero fare. Devi solo provarlo e vedere cosa succede. Ovviamente, ciò significa che devi essere in grado per ripristinare la vecchia catena di strumenti (almeno come soluzione a breve termine) se qualcosa non funziona.

L'altra cosa è uscire dalla mentalità che una costruzione distrutta è un disastro ... o essere imbarazzata. È solo un grosso problema se la build rotta ha conseguenze reali per i sistemi di produzione ... o per i tuoi clienti (definiti in modo approssimativo).

I compilatori che vengono aggiornati fanno parte del "debito tecnico" che tutte le applicazioni devono superare e devono essere prese in considerazione regolarmente.

Se è considerato uguale a qualsiasi altra libreria utilizzata dal programma, è chiaro che dovrebbe essere aggiornato solo in un punto in cui non danneggerà se si rompe (come vicino a una scadenza) e che è necessario eseguire un controllo di qualità completo nello stesso modo in cui si farebbe se si apportassero altre modifiche al programma.

Nota che potresti voler mantenere il vecchio ambiente in una vecchia macchina virtuale, ma hai poi posticipato tutti l'aggiornamento in un secondo momento, rendendolo molto più doloroso se sei forzato per l'aggiornamento.

Penso che l'aggiornamento del compilatore utilizzato per i progetti esistenti sia una pessima idea per le ragioni che hai chiaramente scoperto. Realisticamente, se si modifica il compilatore, qualsiasi nuova versione del prodotto esistente deve passare attraverso un ciclo di controllo qualità completo come se fosse nuovo di zecca. Non puoi supporre che tutto funzioni.

Nella situazione specifica che hai descritto sopra, sarei disposto a scommettere che esiste una variabile o un numero di variabili che dovrebbe avere il qualificatore volatile che non lo è. Un modo per provare e confermare questa teoria sarebbe quello di disattivare le ottimizzazioni del compilatore. Se la build funziona, allora c'è un strong supporto per questa teoria.

Onestamente, sono un po 'sorpreso da tutti i feedback sul motivo per cui stai aggiornando il tuo compilatore. I compilatori sono software, come tutti gli altri. Hanno un ciclo vitale, come tutti gli altri. A un certo punto, è necessario smettere di utilizzare software precedente e passare alla versione più recente supportata dal fornitore e dotata di supporto per le nuove funzionalità.

O vuoi essere il ragazzo che finisce su TheDailyWTF per entrare nell'ufficio dell'amministrazione IT chiedendo che una macchina sia configurata con Windows 95 in modo da poter compilare il tuo software perché questa è l'ultima versione del compilatore per il tuo software installerà su? Sarai lo stesso di chi fa gli amministratori della sicurezza facepalm all'unisono quando afferma che il suo software ha bisogno di Java 1.4.

L'aggiornamento del compilatore (o dell'ambiente di runtime) dovrebbe essere trattato come l'aggiornamento di qualsiasi libreria collegata di terze parti (perché è essenzialmente quello che è): test, test, test. Dovrebbe essere una parte completamente normale della manutenzione del software e quella che si pianifica per il futuro. Il tuo software di sviluppo ha un ciclo di vita proprio come il codice che produci. Essere consapevoli che sarà alla fine della vita.

Non sono completamente d'accordo con @Pemdas. IMO dipende da due fattori:

• Il primo fattore è la dimensione del progetto. Per i progetti di piccole dimensioni non è necessario aggiornare il compilatore e si può rimanere aggiornati fino a quando il progetto non viene consegnato al cliente ed evitare il dolore dell'aggiornamento. OTOH, se il progetto è grande e tu o l'organizzazione impiegherete anni nella manutenzione, sarà molto più doloroso per lo sviluppatore in seguito mantenere entrambe le vecchie applicazioni e usare vecchi strumenti. L'aggiornamento in questo caso offrirà ulteriori vantaggi, come le nuove funzionalità da offrire al cliente e il miglioramento del prodotto con uno sforzo semplice e di poco maggiore che contribuirà a promuovere il prodotto sul mercato.
• L'altro fattore è il compilatore stesso. Se il fornitore del compilatore ha la reputazione di mantenere una buona compatibilità con le versioni precedenti, non è necessario investire molto per testare tutto. OTOH, se il fornitore del compilatore di solito disapprova le funzionalità e apporta modifiche di rottura con ogni versione, saprai che sarà un doloroso aggiornamento.

Per evitare dolori di aggiornamento dovresti:

• Leggi attentamente la documentazione prima di iniziare e potresti dedicare un po 'di tempo a un maggior numero di persone della community a fare il passo e iniziare a scrivere su blog in modo che il tuo percorso sia più chiaro.
• Se utilizzi componenti o librerie di terze parti, puoi scegliere di attendere fino a quando non hanno terminato l'aggiornamento o se è open source e semplice puoi iniziare con loro.
• Crea una copia di backup, ovviamente, ed esegui l'aggiornamento su un ramo diverso del tuo sistema di controllo della versione. Se per qualche motivo non si desidera eseguire questa operazione E se tutti i file sono file di origine (testo di natura non risorse binarie), è possibile utilizzare le direttive del compilatore per rendere la fonte in grado di compilare sia il vecchio che il nuovo compilatore.
• Scegli un buon punto di partenza come un componente o una libreria con poche dipendenze per essere un pilota da sapere in anticipo se fallirà o meno.

Tuttavia, devo dire che questo non garantirà che non infrangerà le nuove build, ma fare gli aggiornamenti in modo organizzato ti aiuterà a risolvere i problemi e a risolvere rapidamente i problemi.

Manteniamo un set abbastanza completo di test automatizzati su tutto il nostro codice in modo da poter essere relativamente sicuri durante l'aggiornamento di compilatori e altri strumenti. Può essere complicato testare alcune cose nel mondo embedded, ma in genere vale la pena se riesci a farlo.