* BOZ, F2008 and F2015, and future of gfortran @ 2017-10-05 21:10 Steve Kargl 2017-10-06 4:36 ` Jerry DeLisle 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2017-10-05 21:10 UTC (permalink / raw) To: fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-05 21:10 BOZ, F2008 and F2015, and future of gfortran Steve Kargl @ 2017-10-06 4:36 ` Jerry DeLisle 2017-10-06 5:02 ` Steve Kargl 0 siblings, 1 reply; 7+ messages in thread From: Jerry DeLisle @ 2017-10-06 4:36 UTC (permalink / raw) To: sgk, fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-06 4:36 ` Jerry DeLisle @ 2017-10-06 5:02 ` Steve Kargl 2017-10-06 5:59 ` Richard Biener 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2017-10-06 5:02 UTC (permalink / raw) To: Jerry DeLisle; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-06 5:02 ` Steve Kargl @ 2017-10-06 5:59 ` Richard Biener 2017-10-06 6:20 ` Steve Kargl 0 siblings, 1 reply; 7+ messages in thread From: Richard Biener @ 2017-10-06 5:59 UTC (permalink / raw) To: sgk, Steve Kargl, Jerry DeLisle; +Cc: fortran 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-06 5:59 ` Richard Biener @ 2017-10-06 6:20 ` Steve Kargl 2017-10-06 11:50 ` Richard Biener 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2017-10-06 6:20 UTC (permalink / raw) To: Richard Biener; +Cc: Jerry DeLisle, fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-06 6:20 ` Steve Kargl @ 2017-10-06 11:50 ` Richard Biener 2017-10-06 17:03 ` Steve Kargl 0 siblings, 1 reply; 7+ messages in thread From: Richard Biener @ 2017-10-06 11:50 UTC (permalink / raw) To: Steve Kargl; +Cc: Jerry DeLisle, fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BOZ, F2008 and F2015, and future of gfortran 2017-10-06 11:50 ` Richard Biener @ 2017-10-06 17:03 ` Steve Kargl 0 siblings, 0 replies; 7+ messages in thread From: Steve Kargl @ 2017-10-06 17:03 UTC (permalink / raw) To: Richard Biener; +Cc: Jerry DeLisle, fortran 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-10-06 17:03 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-05 21:10 BOZ, F2008 and F2015, and future of gfortran Steve Kargl 2017-10-06 4:36 ` Jerry DeLisle 2017-10-06 5:02 ` Steve Kargl 2017-10-06 5:59 ` Richard Biener 2017-10-06 6:20 ` Steve Kargl 2017-10-06 11:50 ` Richard Biener 2017-10-06 17:03 ` Steve Kargl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).