RE: help understanding behaviour of unsuffixed float constants

["Regan, Brian (EPC COE)" <brian dot regan at honeywell dot com>]

It might have been clearer if I included the objdump disassembly:

It should be apparent below the difference when I force the unsuffixed float to double (big value) and the second case where I have a second(but smaller) unsuffixed double. Based on the ASNI item highlighted in the original email (6.1.3.1 "An unsuffixed floating constant has type double.") this difference is unexpected. The concern is not a technical one - it is one of understanding and documenting the deviation from the ANSI standard.


--------------------dump starts here --------------------------
/* would have expected conversion from float constant double to variable single */
static float a = 100.0;

int test(void) {
 1800074:	94 21 ff f0 	stwu    r1,-16(r1)
 1800078:	7c 08 02 a6 	mflr    r0
 180007c:	93 e1 00 0c 	stw     r31,12(r1)
 1800080:	90 01 00 14 	stw     r0,20(r1)
 1800084:	7c 3f 0b 78 	mr      r31,r1

	/* force a double and get implicit conversion as expected */
    if (a < 200.0E40) {
 1800088:	3d 20 01 81 	lis     r9,385
 180008c:	80 09 01 54 	lwz     r0,340(r9)
 1800090:	7c 03 03 78 	mr      r3,r0
 1800094:	48 00 00 89 	bl      180011c <__extendsfdf2>
 1800098:	7c 69 1b 78 	mr      r9,r3
 180009c:	7c 8a 23 78 	mr      r10,r4
 18000a0:	7d 23 4b 78 	mr      r3,r9
 18000a4:	7d 44 53 78 	mr      r4,r10
 18000a8:	3c a0 48 b6 	lis     r5,18614
 18000ac:	60 a5 f5 78 	ori     r5,r5,62840
 18000b0:	3c c0 c4 e0 	lis     r6,-15136
 18000b4:	60 c6 a0 61 	ori     r6,r6,41057
 18000b8:	48 00 00 81 	bl      1800138 <__ltdf2>
 18000bc:	7c 60 1b 78 	mr      r0,r3
 18000c0:	2f 80 00 00 	cmpwi   cr7,r0,0
 18000c4:	41 9c 00 08 	blt-    cr7,18000cc <test+0x58>
 18000c8:	48 00 00 10 	b       18000d8 <test+0x64>
    	a = 0.0;
 18000cc:	3d 20 01 81 	lis     r9,385
 18000d0:	38 00 00 00 	li      r0,0
 18000d4:	90 09 01 54 	stw     r0,340(r9)
    }

	/* per ANSI 6.1.3.1 this constant should also be double and implicit conversion is expected */
    if (a < 200.0) {
 18000d8:	3d 20 01 81 	lis     r9,385
 18000dc:	81 29 01 54 	lwz     r9,340(r9)
 18000e0:	3c 00 43 48 	lis     r0,17224
 18000e4:	13 89 02 cd 	.long 0x138902cd            
 18000e8:	41 9d 00 08 	bgt-    cr7,18000f0 <test+0x7c>
 18000ec:	48 00 00 10 	b       18000fc <test+0x88>
    	a = 0.0;
 18000f0:	3d 20 01 81 	lis     r9,385
 18000f4:	38 00 00 00 	li      r0,0
 18000f8:	90 09 01 54 	stw     r0,340(r9)
   }

	return 0;

---------------  dump ends ---------------------------------------------------

(Note, at address 18000e4, objdump did not decode the SPE instruction correctly. The opcode is the single precision less than in the ppc SPE extension.) 

Regards
Brian

-----Original Message-----
From: Jakub Jelinek [mailto:jakub@redhat.com] 
Sent: Thursday, May 22, 2014 3:46 PM
To: Regan, Brian (EPC COE)
Cc: 'gcc-help@gcc.gnu.org'
Subject: Re: help understanding behaviour of unsuffixed float constants

On Thu, May 22, 2014 at 07:36:24PM +0000, Regan, Brian (EPC COE) wrote:
> Don't misunderstand - I like the behaviour. I don't want the unnecessary implicit conversions).
> 
> My concern stems only from the compliance to the standard. Some of our 
> internal software standards require ISO99 compliance, as do standards 
> imposed by our customers (e.g.  Boeing via their D6).

I don't understand why you think it is not a strict standard compliance.
The C99 standard doesn't say what helper function should be called to perform the comparison, or what hardware instruction should be used, and programs overriding those helper functions (if used) is not conforming, because they are using names reserved for the implementation.

And, as a conforming program can't observe the difference between casting the float variable to double and performing comparison in double vs. not extending the float variable and performing comparison in float, there is no deviation from the standard.

	Jakub