| Message ID | 2d818684-7980-2203-c665-5feadb5d459f@charter.net |
|---|---|
| State | New |
| Headers | show |
On Sun, Oct 30, 2016 at 01:21:41PM -0700, Jerry DeLisle wrote: > See patch below which is very simple. We were handling the case > where we tabbed left of current position in the record by clearing > the seen_eor flag. We were not handling the case where we tab > toward the right and so are still at eor. > > New test case attached. Regression tested on x86-64-linux. > > OK to commit? > OK for all branches.
Hi Jerry, > See patch below which is very simple. We were handling the case where we > tabbed left of current position in the record by clearing the seen_eor > flag. We were not handling the case where we tab toward the right and so > are still at eor. > > New test case attached. Regression tested on x86-64-linux. > > OK to commit? > > This is a regression relative to g77. Its simple enough I think it > should go to 5 and 6 as well. I think so too. OK for all affected branches. Thanks for the patch! Thomas
On 30 October 2016 at 21:40, Thomas Koenig <tkoenig@netcologne.de> wrote: > Hi Jerry, > >> See patch below which is very simple. We were handling the case where we >> tabbed left of current position in the record by clearing the seen_eor >> flag. We were not handling the case where we tab toward the right and so >> are still at eor. >> >> New test case attached. Regression tested on x86-64-linux. >> >> OK to commit? >> >> This is a regression relative to g77. Its simple enough I think it >> should go to 5 and 6 as well. > > > I think so too. OK for all affected branches. > > Thanks for the patch! > Hi, The new test fails at execution on arm and aarch64: gfortran.dg/fmt_t_9.f -O0 execution test gfortran.dg/fmt_t_9.f -O1 execution test gfortran.dg/fmt_t_9.f -O2 execution test gfortran.dg/fmt_t_9.f -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test gfortran.dg/fmt_t_9.f -O3 -g execution test gfortran.dg/fmt_t_9.f -Os execution test seen on gcc-5 and gcc-6 branches. Maybe I missed it on trunk due to larger granularity in validations. Christophe > Thomas >
On 4 November 2016 at 14:48, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 30 October 2016 at 21:40, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Hi Jerry, >> >>> See patch below which is very simple. We were handling the case where we >>> tabbed left of current position in the record by clearing the seen_eor >>> flag. We were not handling the case where we tab toward the right and so >>> are still at eor. >>> >>> New test case attached. Regression tested on x86-64-linux. >>> >>> OK to commit? >>> >>> This is a regression relative to g77. Its simple enough I think it >>> should go to 5 and 6 as well. >> >> >> I think so too. OK for all affected branches. >> >> Thanks for the patch! >> > > Hi, > > The new test fails at execution on arm and aarch64: > > gfortran.dg/fmt_t_9.f -O0 execution test > gfortran.dg/fmt_t_9.f -O1 execution test > gfortran.dg/fmt_t_9.f -O2 execution test > gfortran.dg/fmt_t_9.f -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions execution test > gfortran.dg/fmt_t_9.f -O3 -g execution test > gfortran.dg/fmt_t_9.f -Os execution test > > seen on gcc-5 and gcc-6 branches. Maybe I missed it on trunk due to > larger granularity in validations. > I see it failing on trunk too. > Christophe > > > >> Thomas >>
On 11/04/2016 07:11 AM, Christophe Lyon wrote: > On 4 November 2016 at 14:48, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 30 October 2016 at 21:40, Thomas Koenig <tkoenig@netcologne.de> wrote: >>> Hi Jerry, >>> --- snip --- >> >> The new test fails at execution on arm and aarch64: >> >> gfortran.dg/fmt_t_9.f -O0 execution test >> gfortran.dg/fmt_t_9.f -O1 execution test >> gfortran.dg/fmt_t_9.f -O2 execution test >> gfortran.dg/fmt_t_9.f -O3 -fomit-frame-pointer -funroll-loops >> -fpeel-loops -ftracer -finline-functions execution test >> gfortran.dg/fmt_t_9.f -O3 -g execution test >> gfortran.dg/fmt_t_9.f -Os execution test >> >> seen on gcc-5 and gcc-6 branches. Maybe I missed it on trunk due to >> larger granularity in validations. Hi Christophe, The patch is very non target specific. All I can think at the moment is its related to buffering and flushing details, or an error in the test case. When I get a chance, I would like to send you a test program to maybe help debug this. Or, is there a machine available I cant ssh into and work on it there? Jerry
On 4 November 2016 at 17:28, Jerry DeLisle <jvdelisle@charter.net> wrote: > On 11/04/2016 07:11 AM, Christophe Lyon wrote: >> >> On 4 November 2016 at 14:48, Christophe Lyon <christophe.lyon@linaro.org> >> wrote: >>> >>> On 30 October 2016 at 21:40, Thomas Koenig <tkoenig@netcologne.de> wrote: >>>> >>>> Hi Jerry, >>>> > --- snip --- >>> >>> >>> The new test fails at execution on arm and aarch64: >>> >>> gfortran.dg/fmt_t_9.f -O0 execution test >>> gfortran.dg/fmt_t_9.f -O1 execution test >>> gfortran.dg/fmt_t_9.f -O2 execution test >>> gfortran.dg/fmt_t_9.f -O3 -fomit-frame-pointer -funroll-loops >>> -fpeel-loops -ftracer -finline-functions execution test >>> gfortran.dg/fmt_t_9.f -O3 -g execution test >>> gfortran.dg/fmt_t_9.f -Os execution test >>> >>> seen on gcc-5 and gcc-6 branches. Maybe I missed it on trunk due to >>> larger granularity in validations. > > > Hi Christophe, > > The patch is very non target specific. All I can think at the moment is its > related to buffering and flushing details, or an error in the test case. > > When I get a chance, I would like to send you a test program to maybe help > debug this. Or, is there a machine available I cant ssh into and work on it > there? > I am building cross-compilers, testing with qemu. However, there are aarch64 machines available in the GCC farm, maybe you have access to them? Thanks, Christophe > Jerry >
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index b8eb5ed..5830362 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -1579,7 +1579,8 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind dtp->u.p.current_unit->bytes_left -= dtp->u.p.sf_seen_eor; dtp->u.p.skips -= dtp->u.p.sf_seen_eor; bytes_used = pos; - dtp->u.p.sf_seen_eor = 0; + if (dtp->u.p.pending_spaces == 0) + dtp->u.p.sf_seen_eor = 0; } if (dtp->u.p.skips < 0)
See patch below which is very simple. We were handling the case where we tabbed left of current position in the record by clearing the seen_eor flag. We were not handling the case where we tab toward the right and so are still at eor. New test case attached. Regression tested on x86-64-linux. OK to commit? This is a regression relative to g77. Its simple enough I think it should go to 5 and 6 as well. Regards, Jerry 2016-10-30 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/79123 * io/transfer.c (formatted_transfer_scalar_read): Clear seen_eor only if we have tabbed to left of current position. {