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@xxxxxxxxxx]
Sent: Thursday, May 22, 2014 3:46 PM
To: Regan, Brian (EPC COE)
Cc: 'gcc-help@xxxxxxxxxxx'
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
