Newsgroup: it.comp.lang.c
Titolo: Problema ottimizzazioni

Ciao a tutti.
Ho un problema che mi sembra molto strano. E' possibile che compilando
(tramite gcc) un programma in C con l'opzione -O3 questo non si comporti
piu' correttamente?
A me sembra strano, forse perche' concepisco l'ottimizzazione solo in
termini di assembler.
Grazie a chi mi sapra' dare una risposta!
Ciao
Scola

termini di assembler.
Non ho capito bene...

 termini di assembler.
Hai le idee confuse ?! oppure io non ho capito cosa volevi dire.
ciao
donCiccio

 piu' correttamente?
E' un classico; c'e' un errore da qualche parte nel tuo programma, e
due diverse strutture dell'assembler generato dal compilatore, una
ottimizzata (che funziona per caso) ed una no (dove l'errore si
manifesta).  La causa puo' essere ad esempio una diversa disposizione
in memoria delle variabili: l'accesso ad un elemento di array al di
fuori del valore massimo ha conseguenze diverse.
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it

 Non credo.
E' successo anche a me, con il gcc sotto linux; se non ricordo male i
problemi piu' grossi si verificavano con input e output.
Ciao, Luca.
-- 
 Reply to 
luca....@tiscalinet.it

problemi piu' grossi si verificavano con input e output.
Ma, scusami, a questo punto c'e' qualche malfunzionamento (ben
nascosto) nel programma.
Non e' accettabile che l'ottimizzazione *cambi* il comportamento del
codice del programma.
Comunque, se non ricordo male, l'ottimizzazione che compie il gcc non
e' poi cosi' elevata.

 corretto) puo' smettere di funzionare del tutto!
Se e' vero (ed il programma e' corretto), butta via il compilatore.  O
scrivi un bug report.  O entrambe le cose.


 scrivi un bug report.  O entrambe le cose.
Per scrivere i bug-report bisogna averlo comprato il compilatore! ;-]
Sono anni che uso il Bc++3.1 ed ho imparato a convivere con tutti i suoi
bachi, che non sono pochi. Generare l'assembler per capire perche' accadono
le peggio puttanate ai miei programmi, e quasi routine!
Ho provato il 5.02 ma ho gia' scoperto che di bachi ne aveva di nuovi, anche
se alcuni vecchi erano stati risolti, e comunque i miei programmi, aime',
sono troppo legati all'implementazione C della Borland.
ciao
donCiccio

sono troppo legati all'implementazione C della Borland.
Probabilmente non e' il tuo caso, ma ci sono molti programmatori che
partono dall'idea "il mio codice e' perfetto, possibile che questo
compilatore non me lo traduca in modo corretto ?" e sono anche
dell'idea che, prima di giudicare un martello come "bacato", devo
assicurarmi che il mio modo di infilare i chiodi sia quello corretto.
La "perfezione" del proprio codice potrebbe essere una presunzione che
non risponde al vero.
Voglio dire : e' strano che la normale routine di un programmatore sia
quella di verificare il codice assembler per vedere dove vengano
compiuti gli errori, generalmente basta la fase di debug sul codice
sorgente.
Devi ammettere, anche, che i compilatori commerciali vengono
sottoposti a beta-testing, fase nella quale gran parte dei bug vengono
fuori ; e' improbabile che ve ne siano cosi' tanti giunti alla
versione 5.02.
Ovviamente parlo di bug *importanti*, ovvero di quelli che fanno si'
che un codice corretto venga eseguito in modo scorretto.
In ogni caso non escludo che il tuo codice sia effettivamente corretto
e che i bug nel compilatore ci siano, pero' un po' di autocritica sul
proprio modo di programmare non farebbe male... ;)


Ho provato a ricompilarlo con le opzioni -Wall -pedantic -O3 e mi ha
dato un po' di warning per "definizioni implicite" di alcune funzioni,
tra cui fork, pipe, wait. Ho risolto il problema includendo gli header
relativi e mettendo i prototipi di tutte le funzioni(le mie, ovviamente)
prima del main. Pero' non capisco perche' senza l'ottimizzazione gira in
modo corretto, mentre con -O3 il prg termina dopo poche instruzioni.
Mah, vorra' dire che compilero' sempre tutto con -Wall -pedantic, non si
sa mai.


Grazie a quelli che mi hanno risposto. 
Voglio pero' precisare il problema che mi si manifesta. Quello che sto
facendo e' un programma di raytracing, ed il problema e' molto
particolare. Se compilo senza ottimizzazioni, l'immagine viene generata
alla perfezione, mentre se lo ottimizzo il programma non si pianta (non
c'e' errore di "sbordare" un array, sotto UNIX me ne accorgerei con un
Bus Error), ma l'immagine generata ha solo una componente (tipo solo il
blu). Ho pensato ad un errore nel mio codice, ma... vallo a cercare: tra
l'altro, il fatto che mi dia una sola componente del colore (l'immagine
generata per la componente e' corretta), mi fa veramente pensare che
durante la compilazione ci siano dei casini.
Un altro fatto sorprendente e' che la componente scelta dipende
dall'immagine che genero.
Analizzate e ipotizzate ... ;-)
Grazie e ciao
Scola

Ultima novita'...
Ho aggiunto delle cose al programma (senza toccare tutto quello che
c'era prima), e ora funziona di nuovo correttamente com -O3 !!!
Ciao
SCola

sa mai.
Mah....mi sembra molto molto strano...



Rimango dell'idea che il difetto e' dovuto al sorgente e non al
compilatore...

 proprio modo di programmare non farebbe male... ;)
Ti assicuro che non mi sento un dio della programmazione, ed effettivamente
controllo scrupolosamente cio' che ho scritto prima gettarmi nell'assembler
generato dal compilatore, ma rimane il fatto che il BC 3.1 ha dei bachi
niente male!
ciao
donCiccio

niente male!
Hai provato a confrontare questa tua scoperta con altre persone ?
O a cercare materiale in rete che ne parli ?
Di che tipo di bug si tratta ?
Con il Borland C++ 5.02 che tipo di bug hai riscontrato ?

 compilatore...
Probabile...
Cio' che mi risulta strano e' che normalmente gli errori che facevo si
traducevano in disastri... Qui invece solo quel piccolo difetto. E poi
mi fa specie anche il fatto che aggiungendo codice l'errore sia
sparito... non riesco proprio a spiegarmelo.


Se vuoi ti mando il codice (non e' molto) cosi' vedi di persona, pero'
devi compilarlo sotto linux perche' di fare una fork in dos non c'e'
proprio verso ;-)


proprio verso ;-)
No, mi spiace...
Ho riformattato la partizione di Linux perche' avevo dimenticato il
login e la password ;)) ...

 wrote:
[ snip ]
B>Se vuoi ti mando il codice (non e' molto) cosi' vedi di persona, pero'
B>devi compilarlo sotto linux perche' di fare una fork in dos non c'e'
B>proprio verso ;-)
Se vuoi puoi mandarlo a me. Programmo solo sotto Linux e posso
provare a darci un'occhiata.
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

Rettifica: ho scoperto che tutti i problemi erano dovuti alla chiamata
wait() invece che wait(NULL)! Strano pero' che compilando senza
l'opzione -O3 la cosa non creasse qualche malfunzionamento.


 Con il Borland C++ 5.02 che tipo di bug hai riscontrato ?
#define SWITCHTASK    mt_krnl.ctask->stkptr=MK_FP( _SS,_SP ),\
                      mt_krnl.ctask=mt_krnl.ctask->next,     \
                      _SS=FP_SEG( mt_krnl.ctask->stkptr ),   \
                      _SP=FP_OFF( mt_krnl.ctask->stkptr )
Questo e' un pezzo di codice in cui se abiliti l'ottmizazione "reduce
redundant load", la linea _SP= non viene generata.
Provero' piu' in la' a darti un sorgente compilabile!
ciao
donCiccio
PS. ma non e' per far polemica:
noto quanto segue:
1° msg mio 26/06 23:11
risposta   27/06 16:10
2° msg mio 27/06 22:20
risposta   28/06 01:11
3° msg mio 28/06 22:43
risposta   28/06 22:07
accipicchia sei costantemente sincronizzato col NG! :-O
io come puoi notare mi collegao da casa solo ogni tanto...

accipicchia sei costantemente sincronizzato col NG! :-O
Sono un drogato... ;)