On Fri, Jan 22, 2021 at 12:39 AM Martin Sebor via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> The hack I put in compute_objsize() last January for pr93200 isn't
> quite correct. It happened to suppress the false positive there
> but, due to what looks like a thinko on my part, not in some other
> test cases involving vectorized stores.
>
> The attached change adjusts the hack to have compute_objsize() give
> up on all MEM_REFs with a vector type. This effectively disables
> -Wstringop-{overflow,overread} for vector accesses (either written
> by the user or synthesized by GCC from ordinary accesses). It
> doesn't affect -Warray-bounds because this warning doesn't use
> compute_objsize() yet. When it does (it should considerably
> simplify the code) some additional changes will be needed to
> preserve -Warray-bounds for out of bounds vector accesses.
> The test this patch adds should serve as a reminder to make
> it if we forget.
>
> Tested on x86_64-linux. Since PR 94655 was reported against GCC
> 10 I'd like to apply this fix to both the trunk and the 10 branch.
The proposed code reads even more confusingly than before.
What is called 'ptr' is treated as a reference and what you
then name ptrtype is the type of the reference.
That leads to code like
+ if (code == MEM_REF && TREE_CODE (ptrtype) == VECTOR_TYPE)
what? the pointer type is a VECTOR_TYPE?!
I think you are looking for whether the reference type is a VECTOR_TYPE.
Part of the confusion is likely because the code commons
if (code == ARRAY_REF || code == MEM_REF)
but in one case operand zero is a pointer to the object (MEM_REF) and
in one case
it is the object (ARRAY_REF).
Please refactor this code so one can actually read it literally
without second-guessing proper variable names.
Thanks,
Richard.
> Martin
