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 ;-).