[Bug c++/104920] New: Unreliable results with memset-elt-size

[Bug c++/104920] New: Unreliable results with memset-elt-size

[kouhzadi at rohumm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

            Bug ID: 104920
           Summary: Unreliable results with memset-elt-size
           Product: gcc
           Version: og11 (devel/omp/gcc-11)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kouhzadi at rohumm dot com
  Target Milestone: ---

Created attachment 52624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52624&action=edit
4 examples where memset-elt-size fails, one where it's successful

* GCC versions: 10.3.1 and 11.2
* System type: GNU/Linux (amd64, aarch64, aarch32)
* Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.2.0-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
* Command line: g++ -Wall -Wextra -O3 source.cpp
* Compiler output: none
* Expected compiler output: warning: ‘memset’ used with length equal to number
of elements without multiplication by element size [-Wmemset-elt-size]
* Sample code (more attached):

#include <cstring>
#include <array>

constexpr std::size_t ARRAY_LEN = 10u;

int main()
{
    int arr[ARRAY_LEN];
    std::memset(arr, 0, ARRAY_LEN); // OK, warning as expected

    std::array<int, ARRAY_LEN> arr2;
    std::memset(arr2.data(), 0, arr2.size()); // No warning; note that both
std::array::data() and std::array::size() are constexpr

    return 0;
}

[Bug c++/104920] Unreliable results with memset-elt-size

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Iirc this warning only works with the language array feature. So if you are
using the library array, the compiler does not know the implementation details
of it.

[Bug c++/104920] Unreliable results with memset-elt-size

[kouhzadi at rohumm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

--- Comment #2 from Ali Kouhzadi <kouhzadi at rohumm dot com> ---
Thanks Andrew for the response. Examples bad_03.cpp and bad_04.cpp (attached)
show a case where this works as expected on an STL array. I guess the point is
that it's somewhat unreliable, and improvements would be greatly appreciated.

[Bug c++/104920] Unreliable results with memset-elt-size

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is nothing unreliable on the warning.  If it sees a memset call with an
base language array and size that constant evaluates to the number of array
elements and the array element has size > 1, it warns.
The warning is implemented in the FEs, so it can't see through functions that
would need to be inlined etc., it really requires the size to be constant
expression.
In some of your testcases, that is the case even when you use std:array, in
others it is not.

[Bug c++/104920] Unreliable results with memset-elt-size

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g. in the above #c0 testcase, you can see it in the -fdump-tree-gimple dump:
        memset (&arr, 0, 10);
        _1 = std::array<int, 10>::data (&arr2);
        memset (_1, 0, 10);
For the arr case, the FE can see the array and the size, while for the other
case
it can only see the size to be constant (even that goes beyond what the
language guarantees, as the size is passed outside of manifestly constant
evaluated context, so nothing guarantees it is constant evaluated).
But, if you e.g. add
    constexpr auto p = arr2.data();
to your #c0 testcase, you'll see it is not a constant expression:
error: ‘(int*)(& arr2.std::array<int, 10>::_M_elems)’ is not a constant
expression

[Bug c++/104920] Unreliable results with memset-elt-size

[kouhzadi at rohumm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104920

Ali Kouhzadi <kouhzadi at rohumm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Ali Kouhzadi <kouhzadi at rohumm dot com> ---
Thanks Jakub for the explanation, it does make more sense now. Although I'm
still not quite sure why the addition of the 2nd member function in bad_04.cpp
triggers the warning, I guess that's a StackOverflow question.