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 

[ccache] ccache has issues with current Apple compilers

2014-05-31 Thread Tom Lane
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 0 Kbytes
max cache size   1.0 Gbytes
TEST FAILED
Test data and log file have been left in testdir.20963
make: *** [test] Error 1

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?

I don't know enough about ccache to debug this, but will be happy
to supply further info if given directions how to get it.

(BTW, I successfully installed the same ccache source code on two
older Apple systems, and it's working as expected there.)

regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


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