BOZ, F2008 and F2015, and future of gfortran

BOZ, F2008 and F2015, and future of gfortran

[Steve Kargl]

Simply question.  Do people want gfortran to conform to
the F2008 and F2015 standards for boz-literal-constants?
Are people willing to let go of extension?

Consider

program boz
   implicit none
   integer(1) :: i = z'deadbeef'  ! Nonstandard initialization but
   integer(1) j                   ! accepted as-if initialized through
   data j/z'deadbeef'/            ! a data-stmt
   print *, i, j
end program boz

gfortran's current behavior with long lines wrap.

% gfortran6 -static -o z z.f90
z.f90:3:20:

    integer(1) :: i = z'deadbeef'
                    1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1).
This check can be disabled with the option '-fno-range-check'
z.f90:6:13:

    print *, i, j
             1
Error: Symbol 'i' at (1) has no IMPLICIT type
z.f90:5:21:

    data j/z'deadbeef'/
                     1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1).
This check can be disabled with the option '-fno-range-check'
A conforming version of

gfortran conforming to the F2008 and F2015 standards.
% gfcx -o z z.f90 && ./z
  -17  -17

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: BOZ, F2008 and F2015, and future of gfortran

[Jerry DeLisle]

On 10/05/2017 02:10 PM, Steve Kargl wrote:
> Simply question.  Do people want gfortran to conform to
> the F2008 and F2015 standards for boz-literal-constants?
> Are people willing to let go of extension?
> 

Yes, without any doubt we must comply with F2008 and F2015.

We should make anything that is non standard that has worked before (loosely
stated) only behave the same under -std=legacy and only if it makes sense to do so.

If there is a conflict between making sense and giving wrong results, then we
should choose an error. There is no room for ambiguity. If it gives wrong
results then it should give an error. Period!!!

I apologize for not getting in on this discussion sooner, but I have been busy.

Wrong results can not be tolerated, period!!

Jerry

Re: BOZ, F2008 and F2015, and future of gfortran

[Steve Kargl]

On Thu, Oct 05, 2017 at 09:36:06PM -0700, Jerry DeLisle wrote:
> On 10/05/2017 02:10 PM, Steve Kargl wrote:
> > Simply question.  Do people want gfortran to conform to
> > the F2008 and F2015 standards for boz-literal-constants?
> > Are people willing to let go of extension?
> 
> Yes, without any doubt we must comply with F2008 and F2015.
> 
> We should make anything that is non standard that has worked before (loosely
> stated) only behave the same under -std=legacy and only if it makes sense to do so.
> 
> If there is a conflict between making sense and giving wrong results, then we
> should choose an error. There is no room for ambiguity. If it gives wrong
> results then it should give an error. Period!!!
> 
> I apologize for not getting in on this discussion sooner, but I have been busy.
> 
> Wrong results can not be tolerated, period!!
> 

No apologies necessary.  We're all strapped for time and it
seems to be getting harder to attract new blood to fix things.

At the moment, I have a patch that implements F2015 BOZ semantics
with a number GNU Fortran.  There are a few regressions that 
boil down to the following nonstandard code

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.  With my current patch, I have

% tail gcc/testsuite/gfortran/gfortran.sum

# of expected passes            45883
# of unexpected failures        10
# of unexpected successes       6
# of expected failures          97
# of unsupported tests          79

Also note that this is not a small diff

%  svn diff | wc -l
    1437

and wrapping things inside -std=legacy will not be possibly
(or is impractical) as I have almost completely replaced how
gfortran handles BOZ.

I'm fully aware that some may find the new BOZ handling
to be less than satisfying.  Oh well.

-- 
Steve

Re: BOZ, F2008 and F2015, and future of gfortran

[Richard Biener]

On October 6, 2017 7:02:10 AM GMT+02:00, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>On Thu, Oct 05, 2017 at 09:36:06PM -0700, Jerry DeLisle wrote:
>> On 10/05/2017 02:10 PM, Steve Kargl wrote:
>> > Simply question.  Do people want gfortran to conform to
>> > the F2008 and F2015 standards for boz-literal-constants?
>> > Are people willing to let go of extension?
>> 
>> Yes, without any doubt we must comply with F2008 and F2015.
>> 
>> We should make anything that is non standard that has worked before
>(loosely
>> stated) only behave the same under -std=legacy and only if it makes
>sense to do so.
>> 
>> If there is a conflict between making sense and giving wrong results,
>then we
>> should choose an error. There is no room for ambiguity. If it gives
>wrong
>> results then it should give an error. Period!!!
>> 
>> I apologize for not getting in on this discussion sooner, but I have
>been busy.
>> 
>> Wrong results can not be tolerated, period!!
>> 
>
>No apologies necessary.  We're all strapped for time and it
>seems to be getting harder to attract new blood to fix things.
>
>At the moment, I have a patch that implements F2015 BOZ semantics
>with a number GNU Fortran.  There are a few regressions that 
>boil down to the following nonstandard code
>
>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. 

Richard. 

 With my current patch, I have
>
>% tail gcc/testsuite/gfortran/gfortran.sum
>
># of expected passes            45883
># of unexpected failures        10
># of unexpected successes       6
># of expected failures          97
># of unsupported tests          79
>
>Also note that this is not a small diff
>
>%  svn diff | wc -l
>    1437
>
>and wrapping things inside -std=legacy will not be possibly
>(or is impractical) as I have almost completely replaced how
>gfortran handles BOZ.
>
>I'm fully aware that some may find the new BOZ handling
>to be less than satisfying.  Oh well.

Re: BOZ, F2008 and F2015, and future of gfortran

[Steve Kargl]

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.  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

Re: 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

Re: BOZ, F2008 and F2015, and future of gfortran

[Steve Kargl]

On Fri, Oct 06, 2017 at 01:50:04PM +0200, Richard Biener wrote:
> 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).

I'll take a look at native_interpret_expr.  At the moment,
if one has a "gfc_expr *x" that is a BOZ, then my patch
will set

x->expr_type = EXPR_CONSTANT;  // Same as before
x->ts.type = BT_BOZ;           // New basic type; previously set to BT_INTEGER
x->ts.kind = -1;               // New setting; previously gfc_max_integer_kind
x->boz = boz_string;           // New char * that hold copy of BOZ string.

For "integer :: x = z'dead'", I have x->boz="zdead".  If the BOZ needs
to be converted to an INTEGER, then the first character in x->boz is
used to set the radix and the remaining part of the string is fed into
GMP's mpz_set_str() function.   If a BOZ needs to be converted to a
REAL, then I feed the gfc_expr *x through target-memory.c(gfc_convert_boz)
that Tobias wrote awhile ago. 

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow