Bug 1350086

Summary: ccache-3.2.4-2 and 3.2.7-1 cause clang 3.8.0 to emit bogus "past the end of the array" warnings using strings.h functions and optimizer
Product: [Fedora] Fedora Reporter: Matthias Andree <matthias.andree>
Component: ccacheAssignee: Ville Skyttä <ville.skytta>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: airlied, davejohansen, joel, jv+fedora, matthias.andree, roman, sbergman, ville.skytta
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ccache-3.2.7-2.fc24 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-02 19:54:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
minimal demonstrator program.
none
full clang output none

Description Matthias Andree 2016-06-25 10:46:03 UTC
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

Comment 1 Matthias Andree 2016-06-25 10:48:12 UTC
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.

Comment 2 Stephan Bergmann 2016-07-01 13:59:08 UTC
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?)

Comment 3 Roman Tsisyk 2016-07-22 12:19:18 UTC
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.

Comment 4 Stephan Bergmann 2016-07-23 20:37:49 UTC
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?

Comment 5 Matthias Andree 2016-07-24 09:46:51 UTC
(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.

Comment 6 Ville Skyttä 2016-07-24 14:36:36 UTC
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

Comment 7 Matthias Andree 2016-07-25 09:40:59 UTC
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.

Comment 8 Ville Skyttä 2016-07-25 13:49:28 UTC
Cc'ing ccache upstream

Comment 9 Joel Rosdahl 2016-07-25 15:21:20 UTC
> ... 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.)

Comment 10 Fedora Update System 2016-07-26 15:00:20 UTC
ccache-3.2.7-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-813d040de1

Comment 11 Fedora Update System 2016-07-26 15:00:35 UTC
ccache-3.2.7-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-813d040de1

Comment 12 Ville Skyttä 2016-07-26 15:02:46 UTC
(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.

Comment 13 Joel Rosdahl 2016-07-26 15:06:16 UTC
> > 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.

Comment 14 Ville Skyttä 2016-07-26 15:08:23 UTC
Ok, thanks for the clarification!

Comment 15 Fedora Update System 2016-07-28 06:02:02 UTC
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

Comment 16 Fedora Update System 2016-08-02 19:53:56 UTC
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.