BOZ, F2008 and F2015, and future of gfortran

[Richard Biener]

On Fri, Oct 6, 2017 at 8:20 AM, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Fri, Oct 06, 2017 at 07:58:58AM +0200, Richard Biener wrote:
>> On October 6, 2017 7:02:10 AM GMT+02:00, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>> >
>> >program foo
>> >   integer :: i(2) = [z'124', z'bed']
>> >   print *, i
>> >end program foo
>> >
>> >First, this is nonstandard in that a BOZ-literal-constant cannot
>> >appear in the above context.  Unfortunately, the above leads
>> >to an ICE.  I need to figure how to walk the array constructor
>> >and have gfortran use the type and type kind parameter of the
>> >lhs to convert the rhs boz.
>>
>> I'm just guessing the semantics but you might find native_encode/interpret_expr useful in this context.
>>
>
> I can handle the needed transformation in the Fortran FE
> once I figure out how we handle array constructors.  In
> Fortran, [z'124', z'bed'] is an array constructor and
> Fortran forbids a BOZ from appearing here.  This is
> currently allowed in gfortran, because gfortran upon
> parsing a BOZ immediately converts it to an INTEGER(N)
> (with N=8 or 16 depending on target).  My patch
> gives a BOZ a basic type of BT_BOZ, which is new and
> treated as a typeless sequence of bits.  I need to catch
> an entity with a BT_BOZ basic type and do essentially a
> JIT conversion to the correct type when translating an
> array constructor.

Yes, and depending on how you represent BT_BOZ
native_interpret_expr is exactly such JIT (interpreting
a memory region in target representation as a tree
object with given type).  native_encode_expr does the
reverse transform (create such memory region from a
constant tree object).

>  Unfortunately, gdb sessions suggest
> that we have a use-after-free bug lurking.
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow