🚀 go-pugleaf

En <news:pxbmzmfyjrf.fsf@news.bourguet.org>,
    Jean-Marc Bourguet va escriure:
> Ce n'est permis evidemment que quand ces parametres sont des
> expressions sans appels de fonction, sinon il y a quelques points de
> sequencement en plus

Oui.

> (mais leur ordre relatif n'est pas fixe).

Oui.

> Pour reprendre mon exemple:
>
> int incr(int* i) {
>    return (*i)++;
> }
> i = 0;
> k = f(incr(i), incr(i));

Mmmh, avoir deux objets nomm�s i n'aide pas...

> ici on est sur que l'appel a f se fait avec a=0 et b=1 ou a=1 et b=0.
> (Ou alors il y a autre chose qui m'echappe).

Bon, � moi il y a beaucoup de choses qui m'�chappent ;-)
Tu as fait beaucoup trop de copier-coller avant de poster :-)

Alors, on part de main::i (qui est donc devenu int*), initialis� � NULL (!)
Bouh. On va donc corriger cela pour �crire plut�t

  k = f(incr(&i), incr(&i));  /* ;-) */

Reprenons : on part de main::i, initialis� � 0. Dans le contexte de l'appel
de la fonction f, avant le point de s�quence de l'appel, nous avons deux
appels (ind�pendants, th�oriquement ex�cutables sur deux processeurs
distincts pour reprendre le cas de Chqrlie) ; vu que les deux appels
modifient tous les deux l'objet main::i, il faut s'attendre � des soucis
;-).

Certes, chacun des deux appels � incr sont OK : pour chacun d'entre eux, on
cr�e un objet (avec type pointeur, incr::i), on lui donne une valeur
(&main::i), on a un point de s�quence dans le sous-fil (sans effet notable),
puis deux op�rations s�rialis�es (affectation du r�sultat et
incr�mentation), puis un autre point de s�quence, puis destruction de
incr::i et mise � disposition du r�sultat.
Mais ces points de s�quence n'affectent _pas_ l'autre appel � incr (on se
demande bien comment il ferait).
R�sultat, le comportement est ind�fini.


> Plus subtil, est-ce que
>
> k = f(incr(i), i++);
>
> a les memes garanties?

De comportement ind�fini ? Oui.


> Naturellement, je laisse
>
> int j = 0;
> incr(int*i) { j++; return (*i)++;}
> k = f(incr(i), i++ + j++);
>
> a ceux qui veulent reellement s'amuser.

Tu penses probablement �

int j = 0; /*globale*/
static int incr(int*p) { j++; return (*p)++;}  /*changement de nom*/
extern int f(int a, int b);
int main(){
  int i=0;
  return k= f(incr(&i), i++ + j++); }

i est modifi� deux fois avant l'appel � f, j aussi, le comportement est
ind�fini (deux fois).

Un compilateur moyennement optimisateur va simplifier cela en

  return k= f( (0, j++, i++), i++ + j++); }

(le 0, repr�sente le point de s�quence � l'appel de incr), et le probl�me
devrait �tre �vident.


> Une chose qui m'echappe c'est un exemple realiste ou ca apporte un
> gain et ou la regle du "as-if" ne permet pas le meme gain.

Je ne comprend pas la question. Gain pour qui ?

La r�gle de comportement ind�fini vient du fait qu'avant la normalisation,
on rendontrait les diff�rentes possibilit�s dans la nature (quelquefois sur
le m�me compilo avec des options diff�rentes), et rien ne justifiait de
privil�gier un sens plut�t qu'un autre ; et au contraire on voyait bien le
parti que pouvait tirer les optimisateurs sur la possibilit� d'ordonner les
�valuations de sous-expressions � leur guise, y compris dans les expressions
complexes quand il y a p�nurie de registres (spilling).
Donc la libert� a �t� donn�e aux compilateurs, et pas aux programmeurs.


Antoine