Re: static const int optimization fails in conditional expressions

["Martin v. Loewis" <martin@v.loewis.de>]

> Right.  I'm reporting that
> 
> 1) gcc's behavior changed in this regard in 2.96 and 3.00 from 2.95 and
>    previous, and 

Why is that a problem? The compiler does not need to be consistent.

> 2) gcc sometimes uses these values directly without defining the variables,
>    while other times gcc chooses not to use these values directly.

Again, why is this a problem?

> As I understand, gcc used these values directly with the described
> conditional expression in 2.95, so that there was never a need to
> define these variables.

There always was a need: Your program is ill-formed if you don't
define a static member. The compiler is not required to diagnose this
error (and it sometimes doesn't), but it is still an error.

> On this requirement, gcc is not consistent:  sometimes it uses the values
> directly, while other times, it requires you define the variables.  It
> should not special case :? to fail.

Actually, it must do so. In a ?: expression, if both arguments are
lvalues, the result must be an lvalue. Therefore, the compiler must
not inline the expression, but keep the reference. Consider the
program

#include <stdio.h>

class Foo {
 public:
  static const int erf = 0;
  static const int foo = 1;
};

const int Foo::erf, Foo::foo;

void test(const int& p)
{
	if(&p == &Foo::erf || &p == &Foo::foo)
		printf("PASS\n");
	else
		printf("FAIL\n");
}

int main(int argc,char **argv) {
  test(argc%2 ? Foo::erf : Foo::foo);
  return 0;
}

This program prints, correctly, "PASS" with gcc 3, but prints "FAIL"
in gcc 2.95 because the compiler erroneously inlined the value (and
then found the need to bind p to a temporary). So this change in
behaviour was the result of a bug fix; since it did not introduce a
new bug, I fail to see the essence of your report.

> There are two ways gcc can be made consistent:  

Why is it desirable that gcc is consistent?

> 1) disable the use of these values directly in all cases, or 

That would hurt performance in the cases where the value can be taken.

> 2) re-enable the use of these values in the ?: conditional expressions.

That would violate the C++ standard.

Regards,
Martin