Actually, I was thinking about the case "g(a(), b());".
Let's imagine the gimplified code (because of your change) looks like:
t1 = a();
t2 = b();
g(t1, t2);
Are we always sure that t1 and t2 will not be pushed again in the
CALL_EXPR by further transformations?
No, and that's a good thing. W
Andrew Haley wrote:
Roberto COSTA writes:
> Andrew Haley wrote:
> > Chris Jefferson writes:
> >
> > > One thing which comes up regularly in various C and C++
> > > messageboards is that statements like "f() + g()" and "a(f(), g())"
> > > do not declare which order f() and g() will be
Roberto COSTA writes:
> Andrew Haley wrote:
> > Chris Jefferson writes:
> >
> > > One thing which comes up regularly in various C and C++
> > > messageboards is that statements like "f() + g()" and "a(f(), g())"
> > > do not declare which order f() and g() will be executed in.
> > >
>
Andrew Haley wrote:
Chris Jefferson writes:
> One thing which comes up regularly in various C and C++
> messageboards is that statements like "f() + g()" and "a(f(), g())"
> do not declare which order f() and g() will be executed in.
>
> How hard would it be to fix the order of execution i
"Chris Jefferson" <[EMAIL PROTECTED]> writes:
> One thing which comes up regularly in various C and C++ messageboards
> is that statements like "f() + g()" and "a(f(), g())" do not declare
> which order f() and g() will be executed in.
>
> How hard would it be to fix the order of execution in gcc
Chris Jefferson writes:
> One thing which comes up regularly in various C and C++
> messageboards is that statements like "f() + g()" and "a(f(), g())"
> do not declare which order f() and g() will be executed in.
>
> How hard would it be to fix the order of execution in gcc/g++?
> Could so
Apologises for the slightly off-topic message.
One thing which comes up regularly in various C and C++ messageboards
is that statements like "f() + g()" and "a(f(), g())" do not declare
which order f() and g() will be executed in.
How hard would it be to fix the order of execution in gcc/g++? Co
