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

[Richard Biener <richard.guenther@gmail.com>]

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.