GCC "stringop-overread" warnings

[niekbouman]

Dear flint-devs,

Maybe this is already known, but when compiling with GCC v11.2.1 I get several "stringop-overread" warnings, like:

In file included from set_fmpz_poly.c:12:
In function ‘fq_default_poly_set_fmpz_mod_poly’,
    inlined from ‘fq_default_poly_set_fmpz_poly’ at set_fmpz_poly.c:33:4:
/flint/fq_default_poly.h:510:7: warning: ‘fq_zech_poly_set_fmpz_mod_poly’ reading 88 bytes from a region of size 8 [-Wstringop-overread]
  510 |       fq_zech_poly_set_fmpz_mod_poly(rop->fq_zech, op, ctx->ctx.fq_zech);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

kind regards,
Niek

[wbhart]

Thanks for the report. I don't have any insight but I'll mark it as needing to be fixed for the next release.

[albinahlback]

I think I looked at this 6 months ago, and I think it was because of ctx structures. Don't know why. You get alot more of these in Arb when doing stuff like arb_midref(x) where x is const arb_t and such.

[albinahlback]

Please see flintlib/arb#407 for my suggestion.

[wbhart]

@albinahlback I have no idea what this issue is about. We are planning to do a 2.9 release by the end of next week or so. Would it be possible for you to investigate in the meantime and make a recommendation or better yet a PR to address this?

stringop-overread sounds like it should be to do with strings, so I don't completely understand how this could be related to our structs. Perhaps an explanation on this ticket could also help clear that up.

When I try to Google stringop-overread I get a whole pile of links to issues about "bogus stringop-overread" messages and people complaining they have encountered this issue, but not information on what it actually is.

[albinahlback]

Yeah, GCC 11 complains when you have some function on the form

int
foo(const mystruct input[FIXED_NUMBER]);

and only inputing a pointer (as compared to an array of said size) via

mystruct * ptr = /* whatever */;
myfunction(ptr);

I was thinking of waiting until GCC 12 was being released, as I read somewhere that something similar to this should have been fixed in the master branch. However, as it still hasn't been released yet, I am going to compile the current head of GCC now to see if the problem is still there.

[albinahlback]

It is still relevant:

[albinahlback]

Perhaps it is also relevant to ping @fredrik-johansson here. As mentioned in another issue, I think a change to XXX_[src]ptr would be most suiting. I suspect this can be one reason why GMP and MPFR follows such a naming scheme.

[fredrik-johansson]

I'm puzzled by the fact that unity_zp_coeff_inc generates the warning your screenshot but unity_zp_coeff_add doesn't. They contain the same kind of context object access.

[albinahlback]

Yeah, I have no idea actually. Perhaps it the generated code gets generated in such a way that that it tries to fetch that data, while it doesn't do that for other functions. I don't know.

[fredrik-johansson]

What is a minimal code example that triggers this warning? gcc11 compiles the following without problems for me:

typedef int int_ref[1];

int f(int_ref x)
{
    return x[0];
}

int main()
{
    int x = 0;
    int * y = &x;
    return f(y);
}

[albinahlback]

Yeah, I've tried similar things with no result.

Do you get these warnings when compiling FLINT (or Arb)? Is it GCC 11.2 you're using?

[fredrik-johansson]

No. I installed it from ubuntu-toolchain-r which only provides version 11.1.

[albinahlback]

Obtained GCC 12 today on Arch Linux. This message still pops up.