Re: [vile] vile-9.7[stu] gets stuck "working..."

[Gary Jennejohn]

On Fri, 30 Oct 2009 19:15:56 -0400 (EDT)
Thomas Dickey <address@hidden> wrote:

> On Sat, 31 Oct 2009, Ramil Farkhshatov wrote:
> 
> > On Fri, Oct 30, 2009 at 06:14:39PM -0400, Thomas Dickey wrote:
> >> On Sat, 31 Oct 2009, Ramil Farkhshatov wrote:
> >>
> >>> On Fri, Oct 30, 2009 at 05:42:50AM -0400, Thomas Dickey wrote:
> >>>> On Fri, 30 Oct 2009, Ramil Farkhshatov wrote:
> >>>>
> >>>>> On Fri, Sep 04, 2009 at 05:02:51PM -0400, Clem Taylor wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm a long time vile user and I recently switched to a new desktop
> >>>>>> machine and have been unable to build a working version of vile. I'm
> >>>>>> using a x86_64 Fedora 11 system with gcc 4.4.1 and I built vile with:
> >>>>>> ./configure LEX=reflex --with-builtin-filters=all
> >>>>>>
> >>>>>> During normal use (typically inserting text or deleting a line) vile
> >>>>>> gets stuck in a "working..." "...working" loop. I saw mention of this
> >>>>>> problem in the list archive, but didn't notice a resolution:
> >>>>>>
> >>>>>> <skipped>
> >>>>>
> >>>>> Have same issue with __working...__ loop on archlinux x86_64,
> >>>>> vile-9.7-[stuw] and flex instead of reflex. And for me it occurs every
> >>>>> time I press __dd__. But when I've rebuilt vile with -O0 in CFLAGS
> >>>>> problem disappeared.
> >>>>
> >>>> I got a second report this week (off-list).  I've not been able to
> >>>> reproduce the bug, so I need help from someone who can...
> >>>
> >>> I'm reproducing it by just pressing __dd__ (that should kill a line).
> >>> I've discovered that enabling -ftree-vrp (included in -O2) gcc
> >>> optimization flag triggers the issue. I hope this information can be
> >>> useful.
> >>
> >> not directly (to me).  I don't have the same platform.  (I've tested
> >> mostly 32-bit platforms, but have tested 64-bit Solaris - which
> >> would
> >> still be different).
> >
> > As far as I could investigate issue is in ldel_bytes. But if I add
> > fprintf(stderr, ";; nbytes: %u\n", nbytes);
> > just after `while` issue disappears. Asm listings of line.s with
> > fprintf and without differs heavily. I'm not good at x86_64
> > assembler though to make any conclusions. Can it be a compiler bug?
> > Forgot to mention that I'm using gcc-4.4.1.
> 
> It's possible that it's a compiler bug, but I usually assume the problem's
> in my own code.
> 
> I'm suspecting that there's some sign-extension or similar bug that's not 
> apparent, e.g., if I mixed types that are 32-bit and 64-bit at the wrong 
> place.  ldel_bytes does some tweaking between signed/unsigned types, and
> they seem to be long/unsigned long (should not be a problem).
> 
> (I've been thinking for a while about adding another computer at home, but
> time and space are limited ;-).
> 

Just as a data point - I'm running vile-9.7t (I know, a different version)
on FreeBSD AMD64 and haven't observed any problems, but then again, I'm
not using any special flags to the compiler, or even the same version of gcc
(FreeBSD still uses 4.2.1).

I don't know whether the code in question has changed between 9.7t and
9.7u.

Guess it's time to update to the most recent version and see what happens.

---
Gary Jennejohn