[Issue 10763] (&x)[0 .. 1] doesn't work in CTFE

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10763



--- Comment #10 from Iain Buclaw <ibuclaw at ubuntu.com> 2013-08-19 07:44:59 PDT ---
(In reply to comment #9)
> 
> I veto any new addition that is x87 specific - or, more accurately endian
> specific.
> 
> Remember its:
> 
> version(BigEndian)
>   short sign_exp = (cast(ushort*)&x)[0];
> else
>   short sign_exp = (cast(ushort*)&x)[5];

Wrote a quick toy routine to paint real->ushort[real.sizeof/2] (based on
backend routine that interprets a value as a vector).

--- pseudo code ---
Expression* e = RealExp(42.0L);
size_t len = native_encode_expr(e, buffer);

(gdb) p buffer
"\000\000\000\000\000\000\000\250\004@\000\000\000\000\000\000`\365f\001\000\000\000\000\300\341\377\377\377\177\000\000\000\000\000\000\00
0\000\000\000\023\340Z\000\000\000\000\000`As\001\000\000\000\000\006\000\000\000\000\000\000"


tree cst = native_interpret_array (TypeSArray(ushort, 8), buffer, len);

(gdb) p debug_tree(cst)
{[0]=0, [1]=0, [2]=0, [3]=43008, [4]=16388, [5]=0, [6]=0, [7]=0}
---


OK, lets check this output against run-time results.
---
writeln(*cast(ushort[8]*)(&x));

=> [0, 0, 0, 43008, 16388, 0, 32672, 0]


Which looks like at a first glance that the real->ushort[real.sizeof/2]
conversion isn't correct... up until the point you realise that the '32672'
value is just garbage in padding.


So... this might be very well doable, but will have to be *extremely* careful
about it.  Also, I'm assuming that CTFE is able to get values from constant
static arrays?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------