Re: [ccache] ccache has issues with current Apple compilers
Lubos Lunak writes: > Use CCACHE_CPP2 when using ccache with clang (see e.g. > http://www.mail-archive.com/ccache@lists.samba.org/msg01045.html). Indeed, that seems to do the trick. Thanks! 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
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 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
Re: [ccache] ccache has issues with current Apple compilers
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
[ccache] ccache has issues with current Apple compilers
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
