Re: [ccache] ccache has issues with current Apple compilers

2014-06-01 Thread Joel Rosdahl
Hi,

 I tried to install ccache 3.1.9 on a current Mac system (OS X 10.9.3,
 Xcode 5.1.1).  Configure and compile went cleanly, with the exception
 of two probably-harmless warnings: [...]

Thanks for the patch. The build warning has however already been fixed in
another way in ccache (not released yet, though). You can get hold of the
latest development source code here: http://ccache.samba.org/repo.html

 I did some further experiments and concluded that ccache is in fact kind
 of broken: when I try to compile a large project with it, I get thousands
 of weird warnings that do not appear when using gcc directly (many of them
 the same kind of unused -I argument bleat shown above, but others are
 warnings about C constructs that I don't normally see any warnings about).

As mentioned in the ccache manual: Only works with GCC and compilers that
behave similar enough. You are not using GCC but clang, which does not
behave similar enough...

As a workaround, you can set CCACHE_CPP2, as mentioned by Lubos Lunak. In
the yet unreleased ccache 3.2 version, that shouldn't be necessary.

 In any case, surely it's unexpected that ccache would change
 the compiler's warning behavior?

It's expected if the compiler emits different warnings when compiling from
source code compared with compiling from preprocessed source code since
that's how ccache operates.

-- Joel



On 31 May 2014 20:24, Tom Lane t...@sss.pgh.pa.us wrote:

 I tried to install ccache 3.1.9 on a current Mac system (OS X 10.9.3,
 Xcode 5.1.1).  Configure and compile went cleanly, with the exception
 of two probably-harmless warnings:

 manifest.c:223:2: warning: shift count = width of type
 [-Wshift-count-overflow]
 READ_INT(1, version);
 ^~~~
 manifest.c:150:10: note: expanded from macro 'READ_INT'
 (var) = 8; \
   ^   ~
 manifest.c:230:2: warning: shift count = width of type
 [-Wshift-count-overflow]
 READ_INT(1, mf-hash_size);
 ^~
 manifest.c:150:10: note: expanded from macro 'READ_INT'
 (var) = 8; \
   ^   ~
 2 warnings generated.

 I made this change to silence that, since I think that the C standard
 allows compilers to consider the case undefined behavior:

 $ diff -c manifest.c~ manifest.c
 *** manifest.c~ Sun Jan  6 11:57:59 2013
 --- manifest.c  Sat May 31 13:42:53 2014
 ***
 *** 147,154 
 if (ch_ == EOF) { \
 goto error; \
 } \
 !   (var) = 8; \
 !   (var) |= ch_  0xFF; \
 } \
 } while (0)

 --- 147,153 
 if (ch_ == EOF) { \
 goto error; \
 } \
 !   (var) = (((unsigned int) (var))  8) | (ch_ 
 0xFF); \
 } \
 } while (0)

 but it's probably not really an issue.  However, make test refuses
 to do anything much:

 ...
 PASSED: 178 assertions, 64 tests, 9 suites
 CC='gcc' ./test.sh
 WARNING: Compiler gcc not supported (version: Configured with:
 --prefix=/Applications/Xcode.app/Contents/Developer/usr
 --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1)
 -- not running tests

 I looked at test.sh and concluded that it simply didn't recognize the
 output of gcc --version, which looks like this:

 $ gcc --version
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
 --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
 Target: x86_64-apple-darwin13.2.0
 Thread model: posix

 So I diked out that check from the test script and tried again.
 The first half dozen test suites went OK, but in the basedir
 testsuite I got a lot of chatter:

 clang: warning: argument unused during compilation: '-I
 /Users/tgl/src/ccache-3.1.9/testdir.20963/dir1/include'
 clang: warning: argument unused during compilation: '-I
 /Users/tgl/src/ccache-3.1.9/testdir.20963/dir2/include'
 clang: warning: argument unused during compilation: '-I include'
 clang: warning: argument unused during compilation: '-I include'
 clang: warning: argument unused during compilation: '-I include'
 [ much more in the same vein... ]

 and then the pch testsuite failed altogether:

 starting testsuite pch
 SUITE: pch, TEST: no -fpch-preprocess, -include - Expected cache
 miss to be 1, got 0
 cache directory
 /Users/tgl/src/ccache-3.1.9/testdir.20963/.ccache
 cache hit (direct) 0
 cache hit (preprocessed)   0
 cache miss 0
 preprocessor error 1
 files in cache 0
 cache size 

Re: [ccache] ccache has issues with current Apple compilers

2014-05-31 Thread Lubos Lunak
On Saturday 31 of May 2014, Tom Lane wrote:
 I did some further experiments and concluded that ccache is in fact kind
 of broken: when I try to compile a large project with it, I get thousands
 of weird warnings that do not appear when using gcc directly (many of them
 the same kind of unused -I argument bleat shown above, but others are
 warnings about C constructs that I don't normally see any warnings about).
 The resulting executables seem to work, but I can't use a toolchain that's
 this noisy.  In any case, surely it's unexpected that ccache would change
 the compiler's warning behavior?

 Use CCACHE_CPP2 when using ccache with clang (see e.g. 
http://www.mail-archive.com/ccache@lists.samba.org/msg01045.html).

-- 
 Lubos Lunak
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache