[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65491: [PATCH] Improve performance allocating vectors
From: |
Po Lu |
Subject: |
bug#65491: [PATCH] Improve performance allocating vectors |
Date: |
Mon, 18 Sep 2023 11:08:16 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Even converting them back to their original pointer (which is what we do
>>> with tag/untag pairs) is documented to be well-defined if you compile
>>> using GCC.
>> Only if the consequent pointer designates the same object as the initial
>> pointer (of which I see no scrutable definition within GCC's
>> documentation.)
>
> IIUC the "if" here is talking about the fact that if the object is
> deallocated between the two casts, then you're on your own, of course.
Nope, (gcc)Arrays and Pointers is quite unequivocal:
* `The result of converting a pointer to an integer or vice versa
(C90 6.3.4, C99 and C11 6.3.2.3).'
A cast from pointer to integer discards most-significant bits if
the pointer representation is larger than the integer type,
sign-extends(1) if the pointer representation is smaller than the
integer type, otherwise the bits are unchanged.
A cast from integer to pointer discards most-significant bits if
the pointer representation is smaller than the integer type,
extends according to the signedness of the integer type if the
pointer representation is larger than the integer type, otherwise
the bits are unchanged.
When casting from pointer to integer and back again, the resulting
pointer must reference the same object as the original pointer,
otherwise the behavior is undefined. That is, one may not use
integer arithmetic to avoid the undefined behavior of pointer
arithmetic as proscribed in C99 and C11 6.5.6/8.
and directly cites the apposite portions of the Standard.
> IIUC Mattias bumped into this after he made a few "innocent looking"
> changes to the vector allocation code.
I'll let Mattias fill us in.
- bug#65491: [PATCH] Improve performance allocating vectors, (continued)
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Mattias Engdegård, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Mattias Engdegård, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Po Lu, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Stefan Monnier, 2023/09/17
- bug#65491: [PATCH] Improve performance allocating vectors, Po Lu, 2023/09/17
- bug#65491: [PATCH] Improve performance allocating vectors, Stefan Monnier, 2023/09/17
- bug#65491: [PATCH] Improve performance allocating vectors,
Po Lu <=
- bug#65491: [PATCH] Improve performance allocating vectors, Stefan Monnier, 2023/09/18
- bug#65491: [PATCH] Improve performance allocating vectors, Mattias Engdegård, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Mattias Engdegård, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Mattias Engdegård, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Paul Eggert, 2023/09/16
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/17
- bug#65491: [PATCH] Improve performance allocating vectors, Paul Eggert, 2023/09/17
- bug#65491: [PATCH] Improve performance allocating vectors, Eli Zaretskii, 2023/09/17