Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning on GCC 11.4 #280

Open
fstromback opened this issue Feb 21, 2024 · 3 comments
Open

Warning on GCC 11.4 #280

fstromback opened this issue Feb 21, 2024 · 3 comments
Assignees
Labels
needs analaysis The issue needs analysis before it can be resolved.

Comments

@fstromback
Copy link
Contributor

I have been compiling MPS on Linux using GCC 11.4 for a while. Around version 11 (I'm unsure exactly when), the following warning started appearing:

In file included from /home/filip/Projects/storm/mps/code/mps.c:34,
                 from /home/filip/Projects/storm/Gc/MPS/Lib.c:21:
/home/filip/Projects/storm/mps/code/mpm.c: In function ‘WriteULongest.constprop’:
/home/filip/Projects/storm/mps/code/mpm.c:295:12: warning: ‘__builtin_memset’ forming offset [65, 4294967294] is out of the bounds [0, 65] of object ‘buf’ with type ‘char[65]’ [-Warray-bounds]
  295 |     buf[i] = pad;
      |     ~~~~~~~^~~~~
/home/filip/Projects/storm/mps/code/mpm.c:269:8: note: ‘buf’ declared here
  269 |   char buf[MPS_WORD_WIDTH + 1]; /* enough for binary, */
      |        ^~~

It looks like it has found a possible bug in the number formatting code, but my manual inspection tells me it is correct. The warning appears under -O3 -Wall -Wextra, but not under -O2. Furthermore, using clang with -O3 -Wall -Wextra does not cause any warnings. This makes me suspect a bug in GCC, but I am not sure. I will report it to GCC as well and see what happens.

Isolating the code into a separate file, I have further narrowed the problem down. The warning only appears when width is zero or one, and when constants are propagated into the function (as indicated by the name in the warning). The warning also disappears if the loop that pads the output is surrounded by an if (width > 1).

I vaguely remember that you do not officially support -O3, so this might not be relevant. Since it could point to an issue that I fail to see, I thought I'd bring it to your attention at least. I have fixed the issue by adding the above-mentioned check. Since it is not on a critical path, it should not be an issue performance-wise, even if it makes the code a bit less elegant. The link is below if it is of interest to you: fstromback@61e4908

@thejayps
Copy link
Contributor

Thanks for your investigations and for bringing this to our attention. We'll have a look into it!

@thejayps
Copy link
Contributor

Needs analysis to clarify the actively supported optimizations

@thejayps thejayps added the needs analaysis The issue needs analysis before it can be resolved. label Feb 29, 2024
@thejayps thejayps self-assigned this Feb 29, 2024
@fstromback
Copy link
Contributor Author

If it is relevant, I reported this as a possible bug in GCC here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114051

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs analaysis The issue needs analysis before it can be resolved.
Projects
None yet
Development

No branches or pull requests

2 participants