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

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

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