AVR Freaks

Nope.  C99.  Actually, gnu99, but same results.

 

That's the thing.  It >>is<< an integer constant expression.  From the .i:

typedef char STATIC_ASSERT_FAILED___T1_must_be_larger_than_T0___LINE_218___UID_0 [2*(!!((2.1 > -23.6)))-1] __attribute__ ((__unused__));

So the expression is:

2*(!!((2.1 > -23.6)))-1

While there are floats in there, they are the arguments to the conditional operator '>'.  The result of that sub-expression is an integer.  Specifically, 0 if false, 1 if true.  The rest of the expression is all integer.

 

Right, but the sub-expression (conditional with two float arguments) isn't used directly to size the array.  The integer result of that sub-expression becomes an argument to the remaining all-integer sub-expressions.  Does this still violate the rule?

 

C99, no.  C11 perhaps, but then there would be no point to this macro, since it provides _Static_assert.

 

I understand that, and I understand why.  My question was whether the underlying reason for the two issues was the same, i.e. the compiler cannot simplify expressions containing floating point literals, it is obliged to evaluate them at run-time.

 

You mean -funsafe-math-optimisations?  I've tried that (and the individual options it implies).  I also tried the broader -ffast-math.  No dice.

 

Or did you mean something else?

Funny, the original reason I wrote that macro (well, adapted someone else's) was to overcome the preprocessor's inability to work with fp expressions.  At the time it worked fine and without any errors because I was using it at function scope.  I only recently tried it with fp literals at file scope and got the warning.

 

What confuses me is that something like this:

int main(void) {
  volatile int bar = (2.1 > -23.6);
  while (1);
}

Results in (even with -O0):

00000000 <main>:
int main(void) {
   0:   cf 93           push    r28
   2:   df 93           push    r29
   4:   00 d0           rcall   .+0             ; 0x6 <__zero_reg__+0x5>
   6:   cd b7           in      r28, 0x3d       ; 61
   8:   de b7           in      r29, 0x3e       ; 62
  volatile int bar = (2.1 > -23.6);
   a:   81 e0           ldi     r24, 0x01       ; 1
   c:   90 e0           ldi     r25, 0x00       ; 0
   e:   9a 83           std     Y+2, r25        ; 0x02
  10:   89 83           std     Y+1, r24        ; 0x01
  while (1);
  12:   ff cf           rjmp    .-2             ; 0x12 <__zero_reg__+0x11>

 

So the compiler is able to reduce the expression (2.1 > -23.6), which is composed strictly of literals, at compile time down to the expected value of 1.  In other words, the fp expression is evaluated in the translation environment.  That can only be true if all operands are constants.

 

Indeed it does.  That is curious.

 

That would preclude it's use in function scope.  One of the 'goals' of this mechanism is to be able to use the same mechanism at both file and function scope.

 

Possibly, but another 'goal' is to avoid the use of tool-chain specific extensions.

 

EDIT:

Apparently not:

typedef char fred[__builtin_choose_expr((2.1> -23.0),1,0)];

error: first argument to '__builtin_choose_expr' not a constant
 typedef char fred[__builtin_choose_expr((2.1> -23.0),1,0)];
                   ^

So (2.1 > -23.0) is apparently not considered to be a constant.  I can't explain that.

 

Again, 4.3.4 has no problem with the above.

 

/EDIT

 

With gcc, yes.  On avr-gcc, no.  That made me wonder about compiler versions.  The gcc on this machine is 4.3.4, while avr-gcc is from the Atmel toolchain (3.4.5, so gcc 4.8.1).  I tried avr-gcc 4.3.4 from the machine's distro, and it works fine just like gcc 4.3.4.  So it seems that it is either new standard-compliant behaviour in 4.8.1 (or earlier), or it is a regression.

 

When condition is already a conditional expression or a boolean expression, yes.  However it is there to transform any non-zero expression to '1'.  Although pedantic at best, the use of '!!' costs nothing.

 

I don't mean to be obtuse, but I don't understand why, nor can I locate any text in the standard which prohibits this, including in section 6.6 as referenced by Andy above (both in his linked PDF, and in n1256).  Can you quote the specific section in the standard which spells out this prohibition?

 

Oh wait:

6.6.6 An integer constant expression⁹⁹⁾ shall have integer type and shall only have operands that are integer constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and floating constants that are the immediate operands of casts. Cast operators in an integer constant expression shall only convert arithmetic types to integer types, except as part of an operand to the sizeof operator.

 

99) An integer constant expression is used to specify the size of a bit-field member of a structure, the value of an enumeration constant, the size of an array, or the value of a case constant. Further constraints that apply to the integer constant expressions used in conditional-inclusion preprocessing directives are discussed in 6.10.1.

Well, that's damned inconvenient! ;-)

 

And 6.6.7 explains why int bar = (2.1 > -23.6); works without complaint:

6.6.7 More latitude is permitted for constant expressions in initializers. Such a constant expression shall be, or evaluate to, one of the following:

— an arithmetic constant expression,

— a null pointer constant,

— an address constant, or

— an address constant for an object type plus or minus an integer constant expression.

 

I am still troubled by the application of 6.6.6 against conditional expressions.  I'm troubled because, even though a conditional expression may have non-integer operands, the result of any conditional expression is always an integer.  And just in case I'm wrong about that and a conditional expression with fp arguments results in fp, note that:

typedef char fred[(int)(2.1> -23.0)];

... also fails.

 

So while the >>arguments<< of a conditional sub-expression may fail to satisfy 6.6.6/⁹⁹⁾, it does not seem correct for that failure to propagate all the way up the chain of nested sub-expressions.  It seems too literal (pun intended) an interpretation of the standard.

 

EDIT2:  Same warnings issued with gcc 4.7.2 (i.e. on the host gcc, didn't try avr-gcc)  /EDIT2

Yes: the compiler can do it, but the preprocessor can't.

That's why I said >>translation environment<<.  There has been no question of this being done by the preprocessor.  In fact:

the original reason I wrote that macro (well, adapted someone else's) was to overcome the preprocessor's inability to work with fp expressions.

 

I can't help but conclude that this warning is incorrect behaviour, and an overly zealous interpretation of the standard.

 

I'd be interested to see what other compilers do in the same situation, like CV or ICC, but I don't have those.

 

Depending on the implementation you may get a true or false result for these comparisons.

Yes, but this can be determined in the translation environment i.e. at compile time.