GNU bug report logs - #65491
[PATCH] Improve performance allocating vectors

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65491 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, monnier <at> iro.umontreal.ca
Subject: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 16 Sep 2023 19:22:54 +0200

16 sep. 2023 kl. 19.09 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Sorry, I cannot accept this kind of "discussions" when such tricky
> issues come up.  What's the rush of installing changes when you still
> didn't answer my questions, and we still are not sure these changes
> are correct?

I'm confident that they are correct. Moreover, I'm also confident that the old code was incorrect, which is why the change was carried out. Both the C standard and modern C compilers agree.

There's nothing strange or unusual that the 32-bit --with-wide-int configuration sees unexpected warnings when code is changed. You must have seen that many times before. It doesn't mean that there is anything wrong with the change; in this case it was just a somewhat pedantic GCC warning, quickly silenced.

>>> It does, but LISP_WORD_TAG(type) is a 64=bit type with the only bits
>>> set above 32 bit, so how casting it to uintptr_t is TRT?
>> 
>> Because XUNTAG is used to get the pointer part; we don't want the tag bits. 
> 
> Then just casting should do, no?  Why the subtraction?

Because when Lisp_Object is pointer-sized we need to remove the tag bits from the word. Only in the special configuration with a Lisp_Object that is larger than pointers can we simply cast away the tag bits.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.