|
From: John C. <cr...@gm...> - 2021-12-18 20:08:08
|
Fwiw I'm seeing a failure, snippet below, when running `make check` on
valgrind-3.18.1. The package configures, makes, installs, and, as far as I
can tell, executes successfully.
$ uname -a
Linux foo-Inspiron-3583 5.4.0-91-generic #102-Ubuntu SMP Fri Nov 5 16:31:28
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
$ ./configure --prefix=/my/prefix # seems to work fine
$ make # completes successfully
$ make check
. . . snip ...
c++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind
-I../../include -I../../VEX/pub -I../../VEX/pub -DVGA_amd64=1 -DVGO_linux=1
-DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -std=c++17
-Wno-mismatched-new-delete -MT cxx17_aligned_new-cxx17_aligned_new.o -MD
-MP -MF .deps/cxx17_aligned_new-cxx17_aligned_new.Tpo -c -o
cxx17_aligned_new-cxx17_aligned_new.o `test -f 'cxx17_aligned_new.cpp' ||
echo './'`cxx17_aligned_new.cpp
cxx17_aligned_new.cpp:25:5: error: no matching function for call to
'operator delete'
operator delete(myClass, 64U, std::align_val_t(64U));
^~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/new:154:6:
note: candidate function not viable: no known conversion from 'unsigned
int' to 'std::align_val_t' for 2nd argument
void operator delete(void*, std::align_val_t, const std::nothrow_t&)
|
|
From: Paul F. <pj...@wa...> - 2021-12-19 10:29:16
|
On 18/12/2021 21:07, John Crow wrote:
> Fwiw I'm seeing a failure, snippet below, when running `make check` on
> valgrind-3.18.1. The package configures, makes, installs, and, as far
> as I can tell, executes successfully.
>
> $ uname -a
> Linux foo-Inspiron-3583 5.4.0-91-generic #102-Ubuntu SMP Fri Nov 5
> 16:31:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> $ ./configure --prefix=/my/prefix # seems to work fine
> $ make # completes successfully
> $ make check
> . . . snip ...
>
> c++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
> -I../../coregrind -I../../include -I../../VEX/pub -I../../VEX/pub
> -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1
> -DVGPV_amd64_linux_vanilla=1 -std=c++17 -Wno-mismatched-new-delete
> -MT cxx17_aligned_new-cxx17_aligned_new.o -MD -MP -MF
> .deps/cxx17_aligned_new-cxx17_aligned_new.Tpo -c -o
> cxx17_aligned_new-cxx17_aligned_new.o `test -f 'cxx17_aligned_new.cpp'
> || echo './'`cxx17_aligned_new.cpp
> cxx17_aligned_new.cpp:25:5: error: no matching function for call to
> 'operator delete'
> operator delete(myClass, 64U, std::align_val_t(64U));
> ^~~~~~~~~~~~~~~
> /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/new:154:6:
> note: candidate function not viable: no known conversion from
> 'unsigned int' to 'std::align_val_t' for 2nd argument
> void operator delete(void*, std::align_val_t, const std::nothrow_t&)
>
Hi
That's for me.
You are building with the same compiler that was used at configure time?
configure.ac does contain a test for "operator delete(nullptr,
std::align_val_t(64U));" which I presume passes. It seems strange that
this passes (a C++17 feature) but the sized overload doesn't (which is a
combination of C++14 and C++17).
I'm using GCC 11 and in /usr/include/c++/11/new there is
/** These are replaceable signatures:
* - normal single new and delete (no arguments, throw @c bad_alloc on
error)
* - normal array new and delete (same)
* - @c nothrow single new and delete (take a @c nothrow argument, return
* @c NULL on error)
* - @c nothrow array new and delete (same)
*
* Placement new and delete signatures (take a memory address argument,
* does nothing) may not be replaced by a user's program.
*/
_GLIBCXX_NODISCARD void* operator new(std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
__attribute__((__externally_visible__));
SNIP
#if __cpp_aligned_new
_GLIBCXX_NODISCARD void* operator new(std::size_t, std::align_val_t)
__attribute__((__externally_visible__, __alloc_size__ (1), __malloc__));
SNIP
#if __cpp_sized_deallocation
this is the one we want
void operator delete(void*, std::size_t, std::align_val_t)
_GLIBCXX_USE_NOEXCEPT __attribute__((__externally_visible__));
void operator delete[](void*, std::size_t, std::align_val_t)
_GLIBCXX_USE_NOEXCEPT __attribute__((__externally_visible__));
#endif // __cpp_sized_deallocation
#endif // __cpp_aligned_new
Does yours look similar?
Does the following change help
diff --git a/memcheck/tests/cxx17_aligned_new.cpp
b/memcheck/tests/cxx17_aligned_new.cpp
index 6f574d066..0eeec2ba6 100644
--- a/memcheck/tests/cxx17_aligned_new.cpp
+++ b/memcheck/tests/cxx17_aligned_new.cpp
@@ -22,10 +22,10 @@ int main() {
// sized versions
myClass = new MyClass();
- operator delete(myClass, 64U, std::align_val_t(64U));
+ operator delete(myClass, size_t(64U), std::align_val_t(64U));
myClass5 = new MyClass[5];
- operator delete [](myClass5, 320U, std::align_val_t(64U));
+ operator delete [](myClass5, size_t(320U), std::align_val_t(64U));
MyClass* myClassNt = new (std::nothrow) MyClass;
operator delete(myClassNt, std::align_val_t(64U), std::nothrow);
(a size_t literal suffix may come one day, but not for a few years at
least http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0330r8.html)
A+
Paul
|
|
From: Paul F. <pj...@wa...> - 2021-12-19 16:12:45
|
Hi John On 12/19/21 16:16, John Crow wrote: > I ought to have said at first how much I appreciate having Valgrind > available. It's invaluable, and thank you for your attention. > > 'You are building with the same compiler that was used at configure time?' > Yes. I verified by doing a configure>>make>>make check right now in a > freshly untarred build folder. Outside of specifying --prefix to > configure, defaults all the way. It shouldn't make a difference, but does running the 'autogen.sh' script in the Valgrind root directory before configure make any difference? > > 'I'm using GCC 11 and in /usr/include/c++/11/new there is [snipped] > ... Does yours look similar?' > Yes, for me it's in /usr/include/c++/9/new. > > I'll have to figure out the diff --git suggestion. In both case the unsigned constant for the size [64U and 320U] is changed to be cast to size_t [size_t(64U) and size_t(320U)] > > Two chunks out of config.log that might or might not be pertinent, I > simply searched for 'delete': > > configure:10224: result: no > > > configure:10857: result: yes > configure:10888: checking if g++ supports aligned new and delete > configure:10916: c++ -c -std=c++17 conftest.cpp >&5 > configure:10916: $? = 0 > configure:10919: result: yes That's the one. Can you also try directly compiling the file to try to find out what does and does not work. For instance (tests done with GCC 9.4 on FreeBSD) cd memcheck/tests g++9 -g cxx17_aligned_new.cpp -std=c++17 -o foo // this works g++9 -g cxx17_aligned_new.cpp -std=c++17 -o foo -fno-sized-deallocation cxx17_aligned_new.cpp: In function 'int main()': cxx17_aligned_new.cpp:25:56: error: no matching function for call to 'operator delete(MyClass*&, unsigned int, std::align_val_t)' 25 | operator delete(myClass, 64U, std::align_val_t(64U)); | ^ In file included from cxx17_aligned_new.cpp:2: /usr/local/lib/gcc9/include/c++/new:129:6: note: candidate: 'void operator delete(void*)' 129 | void operator delete(void*) _GLIBCXX_USE_NOEXCEPT [SNIP other candidates and 2nd error] One last suggestion, you can you run the preprocessor and see if the delete overloads are there? g++9 -g cxx17_aligned_new.cpp -std=c++17 -E -o foo.E then view foo.E and look for "operator delete". The last two overloads that I see are void operator delete(void*, std::size_t, std::align_val_t) noexcept __attribute__((__externally_visible__)); void operator delete[](void*, std::size_t, std::align_val_t) noexcept __attribute__((__externally_visible__)); A+ Paul |