This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: statement expressions and extended asm bug?


    static inline void increment (int * ptr) { *ptr++; return 0; }
    func (increment (&a), increment (&a));

No, it is just as undefined.  The compiler is free to call
either the "left" or the "right" increment() first.

Why is this undefined? Isn't it just unspecified? If I understand the DR Joseph pointed me too, the order of the two function calls is unspecified, but they do not overlap and there is a sequence point just before each call (after the arguments have been evaluated), and a sequence point before each returns.

Yes, I overlooked the fact that increment() always return 0, instead of the value of *ptr++. So either order the arguments to func() are evaluated, you get the same values, so this is fine. (with the obvious s/void/int/ , of course).

It's just the same as

	increment(&a);
	increment(&a);
	func(0, 0);

The original stmt-expr problem is more akin to the following (if stmt-exprs
were to produce rvalues in a return-like way),
int var;
static inline int frob (int x) {var = x; return var;}
func (frob (12), frob (13));
Are you saying this is undefined too?

The return values of the two "calls" to frob() are not dependent on the order of those calls; so no.

Sorry for the confusion.


Segher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]