Created attachment 1172210 [details] minimal demonstrator program. Description of problem: When several conditions are met: - my code is compiled with clang-3.8.0 - the code is to be optimized (-O is sufficient) - warnings are requested Then clang issues bogus warnings of the kind: minimal.c:7:2035: warning: array index 3 is past the end of the array (which contains 3 elements) [-Warray-bounds] Version-Release number of selected component (if applicable): Not sure which package causes the issue, if it's the libc or the compiler. How reproducible: Always Steps to Reproduce: 1. install clang 2. use attached minimal.c code, shown inline below for convenience 3. run: clang -O -W -c minimal.c // ==== minimal.c ==== #include <string.h> void f(void) { volatile char *c = strchr("blah", 'a'); volatile size_t sz = strspn("blah", "ab"); sz = strcspn("blah", "ab"); volatile int i = strcmp("blah", "''"); } // ==== end of minimal.c ==== Actual results: Compiler emits warnings that should not be there. minimal.c:5:592: warning: array index 3 is past the end of the array (which contains 3 elements) [-Warray-bounds] minimal.c:6:565: warning: array index 3 is past the end of the array (which contains 3 elements) [-Warray-bounds] minimal.c:7:2035: warning: array index 3 is past the end of the array (which contains 3 elements) [-Warray-bounds] 3 warnings generated. Expected results: The code should compile without warning. GCC 6.1 achieves just that. Additional info: glibc-headers-2.23.1-8.fc24.x86_64 clang-3.8.0-1.fc24.x86_64
Created attachment 1172223 [details] full clang output Note that under the hood, some massive expansion of macros and extensions is going on that is not listed here for brevity, please review the full clang output attached here.
Do the warnings only get emitted when you run clang on a -E preprocessed version of minimal.c, and not when run on the minimal.c as attached? (I cannot reproduce your problem. However, I can reproduce it wit a -E preprocessed version of minimal.c. But in that case, such warnings should probably not be unexpected?)
These warning are definitely false positive. I also affected by this problem: https://github.com/tarantool/tarantool/issues/1626 https://bitbucket.org/xi/libyaml/issues/23/ Clang 3.8.1 from an other distro is OK.
Smells like your "clang" command isn't actually clang proper but some ccache wrapper, in which case setting the CCACHE_CPP2 environment variable should help. What is the output of "which clang", and does "ccache -C && CCACHE_CPP2=1 clang -O -W -c minimal.c" suppress the warnings?
(In reply to Stephan Bergmann from comment #4) > What is the output of "which clang", and does "ccache -C && CCACHE_CPP2=1 > clang -O -W -c minimal.c" suppress the warnings? Confirmed, ccache's fault: [mandree@fed ~]$ which clang /usr/lib64/ccache/clang [mandree@fed ~]$ ccache -C && CCACHE_CPP2=1 clang -O -W -c minimal.c Cleared cache And ccache -C + re-running clang without CCACHE_CPP2 brings the warning back. This is with ccache-3.2.4-2.fc24.x86_64 - bug reassigned to ccache. My apologies for complaining about clang.
Please try ccache which is currently in testing -- it includes a number of bug fixes over 3.2.4, including some clang specific ones. https://ccache.samba.org/releasenotes.html#_ccache_3_2_7
No improvement with ccache-3.2.7-1.fc24.x86_64 downloaded from http://mirror.bytemark.co.uk/fedora/linux/updates/testing/24/x86_64/c/ Note that the release notes do NOT hint to relevant fixes.
Cc'ing ccache upstream
> ... setting the CCACHE_CPP2 environment variable should help. Since the compiler can't compile its own preprocessed output correctly, setting CCACHE_CPP2 is the correct fix. See "Errors when compiling with ccache" on https://ccache.samba.org/manual.html#_errors_when_compiling_with_ccache. FYI: ccache 3.3 will make CCACHE_CPP2 (AKA run_second_cpp) the default since modern compilers tend to no longer work like they used to in this regard, see https://github.com/ccache/ccache/issues/116. Ville Skyttä: Feel free to set CCACHE_CPP2 in /etc/profile.d/ccache.sh until ccache 3.3 has been released. (Then please remove it again, and also remove CCACHE_HASHDIR.)
ccache-3.2.7-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-813d040de1
(In reply to Joel Rosdahl from comment #9) > Feel free to set CCACHE_CPP2 in /etc/profile.d/ccache.sh until > ccache 3.3 has been released. Done in ccache-3.2.7-2.* > and also remove CCACHE_HASHDIR. That discussion was in bug 759592, I'm not aware of anything having changed that would change the outcome as far as I'm concerned. I added a link to that bug in the profile.d snippets though.
> > and also remove CCACHE_HASHDIR. > > That discussion was in bug 759592, I'm not aware of anything having changed > that would change the outcome as far as I'm concerned. I added a link to that > bug in the profile.d snippets though. Sorry for being unclear. I meant that ccache 3.3 will make hash_dir default to true as well (see https://github.com/ccache/ccache/issues/117), so when you package ccache 3.3, CCACHE_HASHDIR should be removed from profile.d since it otherwise will override user configuration in e.g. $CCACHE_DIR/ccache.conf.
Ok, thanks for the clarification!
ccache-3.2.7-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-813d040de1
ccache-3.2.7-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.