Compiling error on ubuntu jammy

[silviucpp]

Tested on on tag v335

In file included from /usr/include/string.h:535,

                 from /esvm/c_src/svm.cc:6:

In function ‘void* memcpy(void*, const void*, size_t)’,

    inlined from ‘void clone(T*&, S*, int) [with S = const signed char; T = signed char]’ at /esvm/c_src/svm.cc:28:8,

    inlined from ‘void Solver::Solve(int, const QMatrix&, const double*, const schar*, double*, double, double, double, Solver::SolutionInfo*, int)’ at /esvm/c_src/svm.cc:516:7:

/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744071562067968 or more bytes at offsets 0 and 0 overlaps 9223372032559808513 bytes at offset -9223372034707292161 [-Werror=restrict]

   29 |   return __builtin___memcpy_chk (__dest, __src, __len,

      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

   30 |                                  __glibc_objsize0 (__dest));

      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

cc1plus: all warnings being treated as errors

[maclin726]

Hello,

Since we cannot reproduce this error, could you please share more details about the compiler and how do you compile the program? Thanks

[silviucpp]

Hello,

Thanks for your response, I built an erlang/elixir port for libsvm and travis failes on ubuntu jammy. The build report you can find here: https://app.travis-ci.com/github/silviucpp/esvm/jobs/631001690 it has all the necessary information including OS version compiler version:

Operating System Details

Description:	Ubuntu 22.04.5 LTS
Release:	22.04
Codename:	jammy
gcc version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

Here is the verbose compiler flags:

g++ -O3 -finline-functions -Wall -fPIC -I /usr/lib/erlang/erts-14.2.1/include/ -I /usr/lib/erlang/lib/erl_interface-5.5/include -DNDEBUG -O3 -fPIC -g -Wextra -Wno-deprecated-declarations -Wno-missing-field-initializers -fno-exceptions -fno-rtti -std=c++11  -c -o /home/silviu/Desktop/esvm/c_src/esvm.o /home/silviu/Desktop/esvm/c_src/esvm.cc

g++ -O3 -finline-functions -Wall -fPIC -I /usr/lib/erlang/erts-14.2.1/include/ -I /usr/lib/erlang/lib/erl_interface-5.5/include -DNDEBUG -O3 -fPIC -g -Wextra -Wno-deprecated-declarations -Wno-missing-field-initializers -fno-exceptions -fno-rtti -std=c++11  -c -o /home/silviu/Desktop/esvm/c_src/svm.o /home/silviu/Desktop/esvm/c_src/svm.cc

[maclin726]

Sorry for late reply.
Based on our investigation, it seems that the compiler detects the number of bytes we're going to copy exceeds the size of the block that the destination pointer points to.
This can be solved by modifying the type for variable n to be unsigned int.
However, we're still studying how the compiler estimates the bytes to make sure our understanding is correct.
After the situation becomes clearer, we will do some modification to solve this warning.

[maclin726]

After more study, we attempt to reproduce the warning with the following code snippets on Ubuntu 22.04 (gcc version 11.4.0):

#include <string.h>

typedef signed char schar;    
static inline void clone_schar(schar*& dst, const schar* src, int n)
{
    dst = new schar[n];
	memcpy(dst, src, sizeof(schar)*n);
}

static inline void clone_double(double*& dst, const double* src, int n)
{
    dst = new double[n];
	memcpy(dst, src, sizeof(double)*n);
}

int *active_set;
double *p;
schar *y;

void solve(int l, const double *p_, const schar *y_)
{
    clone_double(p, p_,l);
    clone_schar(y, y_,l);
    active_set = new int[l]; // the warning disappears after commenting this line 
}

On another Arch-linux machine with latest gcc 14.2.1, the example can even be more simple:

static inline void clone_double(double*& dst, const double* src, int n)
{
    dst = new double[n];
    size_t len = sizeof(double)*n;
	memcpy(dst, src, len);
}

int *active_set;
double *p;

void solve(int l, const double *p_)
{
    clone_double(p, p_,l);
    active_set = new int[l]; // the warning disappears after commenting this line 

}

We regard this as a bug from gcc because the number of bytes in the warning message is unreasonable, showing that gcc somehow wrongly estimates the size we're going to write.
writing between 18446744071562067968 and 18446744073709551615 bytes into a region of size between 0 and 2147483647
We plan to report this bug to see whether it can be fixed in a later version.

[silviucpp]

Nice ! If you report this bug will be nice if you can add here the link to the bug report

Silviu

[maclin726]

See the page on GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119320

[silviucpp]

So basically from what I understand there are two potential fixes:

1. remove -fno-exceptions but this in my opinion is not a proper fix.
2. add an assert into libsvm to inform compiler that the value received is non-negative.

Right ?