Thomas Otto [Sun, 19 Jan 2020 16:49:19 +0000 (17:49 +0100)]
Make cc_process_args() only use local variables
cc_process_args writes into a new ArgsInfo struct and only accesses
local variables (minus guessed_compiler). For now these are mostly
copied into the global variables again after the function call.
Most ccache.cpp global variables moved to legacy_globals.cpp.
Joel Rosdahl [Sat, 25 Jan 2020 10:19:52 +0000 (11:19 +0100)]
Make failure to write a stats file a soft error (#516)
If a stats file update for some reason fails, the exception will bubble
up to ccache_main which just prints the error and exits with an error.
Let’s consider such failures non-fatal and just log them.
Thomas Otto [Sun, 19 Jan 2020 19:47:27 +0000 (20:47 +0100)]
Make failed tests create a testdir.failed symlink (#511)
When the test suite fails 'testdir.failed' now points to the random
'testdir.9876/' directory. This make iterative debugging of failing
tests easier by always using the symlink name or re-issuing 'cd $PWD'
when 'cd'-ed into the 'testdir.failed' directory.
All artifacts can still be removed via 'rm -r testdir.*'.
Joel Rosdahl [Thu, 16 Jan 2020 20:04:09 +0000 (21:04 +0100)]
Send dependency arguments to compiler if run_second_cpp is true
If we run the compiler on the real source code on a cache miss (i.e.,
run_second_cpp is true) we can send the dependency arguments (-MD, etc.)
to the compiler instead of the preprocessor. When doing this there is no
need to add an implicit -MQ option to get the correct object file
location in the dependency file. Do so and also avoid adding an implicit
-MF option since that isn’t needed either. This should re-add support
for EDG-based compilers (see 6d453769 and #460).
If we run the compiler on the preprocessed source code on a cache miss
(i.e., run_second_cpp is false) we still need to let the preprocessor
generate the dependency file (the compiler doesn’t generate a dependency
file when compiling preprocessed source code) and thus we need to add
implicit -MQ and -MF.
This change reverts a fix (97b27781) for the Intel C++ compiler, but if
the Intel compiler still has problems the user can simply avoid setting
run_second_cpp to false.
Joel Rosdahl [Tue, 14 Jan 2020 20:30:29 +0000 (21:30 +0100)]
Avoid passing compilation-only options to the preprocessor redux
25e73c1f (“Include compiler-only arguments in the hash”) attempted to
fix a regression in 5d8585b5 (“Don’t pass -Werror and compilation-only
options to the preprocessor”). It succeeded fixing the regression all
right, but it also essentially reverted the essence of 5d8585b5 (#312)
since compiler-only arguments once again are passed to the preprocessor.
Sigh.
Fix this for real and also write a test that proves it.
Joel Rosdahl [Sat, 4 Jan 2020 18:19:01 +0000 (19:19 +0100)]
Make sure to always log a “Result:” line
Fixes #500.
A side effect of this is that read-only cache misses now will update the
“cache miss” statistics counter, which is consistent with the cache hit
cases (which already now update the counters).
The reason for reverting is that the change introduced a nasty bug: the
dependency file will get an incorrect object file location if 1) build
directory != source directory and 2) -MF is not specified explictly by
the user.
Details: The dependency file is created by the preprocessor pass which
does not have access to the final output file name, so the preprocessor
uses the default object location derived from the source file location
instead.
Note that this partly reverts a compatibility improvement for EDG-based
compilers (see issue #460).
It should be possible to pass the dependency arguments to the compiler
instead of the preprocessor to make -MD/-MMD without -MQ work, but
that’s too risky to be done as a bug fix.
Joel Rosdahl [Sun, 29 Dec 2019 18:21:39 +0000 (19:21 +0100)]
Remove the unify mode
The unify mode has not received enough attention and has at least these
bugs:
1. The direct mode doesn’t work if the unify mode is enabled. This is
because the unify mode doesn’t call into process_preprocessed_file
which stores the paths and hashes of included files needed by the
direct mode.
2. The .incbin directive detection has no effect when using the unify
mode. This is again because the unify mode doesn’t use
process_preprocessed_file which is where the .incbin detection takes
place.
3. The unifier’s tokenizer doesn’t understand C++11 raw string literals.
4. The unifier ignores comments, but comments may have semantic meaning
to modern compilers, e.g. “fall through” comments.
Bugs 3 and 4 are fixable by improving the unifier’s tokenization
algorithm, but since it’s a bit tricky it likely won’t be worth the
effort, especially not as a bug fix.
Bugs 1 and 2 are also fixable by unifying the two code paths, but that’s
a non-trivial effort.
In addition to the bugs, I believe that the usefullness of the unify
mode is low:
* It’s only applicable when not using -g.
* It won't be enabled for C++ unless somebody fixes bug 3.
* It can make line numbers in warning messages and __LINE__ expansions
incorrect.
* Since comments should not be ignored, the unify mode can only make a
difference for some types of whitespace changes, like adding or
removing blank lines or changing a+b to a + b. (a + b is already
normalized to a + b by the preprocessor.)
Therefore I’ll just remove the unify mode to fix the bugs.
Thomas Otto [Sun, 24 Nov 2019 21:27:26 +0000 (22:27 +0100)]
Windows define and include restructuring (#492)
Set the _WIN32_WINNT macro only once in the generated config.h.
Include <windows.h> only once in system.hpp, unless these includes
are in third party libs - however third party includes themselves
should always be behind internal includes. Therefore also make
system.hpp the first include everywhere.
Erik Johansson [Sun, 17 Nov 2019 20:31:49 +0000 (21:31 +0100)]
Add handling of __TIMESTAMP__ macro (#488)
__TIMESTAMP__ is expanded by the pre-processor to asctime() of the source
file's modification time. Handle __TIMESTAMP__ similar to __DATE__ and include
asctime(modification time) in the hash when __TIMESTAMP__ is detected in the
source code.
Joel Rosdahl [Sat, 16 Nov 2019 21:59:33 +0000 (22:59 +0100)]
Always include input file path in direct mode hash
The “file_macro sloppiness” mode is a way of opting out of inclusion of
the input file path in the direct mode hash. This can produce a false
cache hit in the following scenario:
- a/r.h exists.
- a/x.c has #include "r.h".
- b/x.c is identical to a/x.c.
- Compiling a/x.c records a/r.h in the manifest.
- Compiling b/x.c results in a false cache hit since a/x.c and b/x.c
share manifests and a/r.h exists.
Therefore, ditch the file_macro sloppiness mode so that the input file
path is always included in the direct mode hash.
This bug has existed ever since the file_macro sloppiness was introduced
in eb5d9bd3beb5 (ccache 3.0). It has remained undetected since
compilations tend to use .d files and ccache before 3.7.5 added an
implicit “-MQ <output_file_path>” argument, thus in practice including
the output file path in the hash and therefore making manifests unique
when the object file path mirrors the source file path. However, ccache
3.7.5 no longer adds the implicit -MQ option, thus exposing the bug.
Luboš Luňák [Thu, 14 Nov 2019 19:17:22 +0000 (20:17 +0100)]
Allow -fmodules in direct depend mode (#482)
Clang creates the internal on-disk representation of modules
in the background on demand as necessary. This means that ccache does
not need to cache that, all that it needs to cache is the actual
compilation result and the dependencies. Which in the case of modules
includes also the module.modulemap files, and Clang outputs such
dependencies correctly only in the depend mode, in the preprocessed
output there is no way to find out the module dependencies.
Therefore support -fmodules in direct depend mode by more or less
ignoring it. Tested with source build of LLVM/Clang configured
with -DLLVM_ENABLE_MODULES=On (and the build actually occassionally
fails because of module problems, but that happens regardless of ccache).
See also pull request #130 (and this reuses the tests from there).
Erik Johansson [Wed, 23 Oct 2019 18:52:49 +0000 (20:52 +0200)]
Add AVX2 variant of check_for_temporal_macros (#476)
By using AVX (Advanced Vector Extensions) the search for __DATE__ and __TIME__
in the input source becomes much faster. On my machine, ccache spends ~4.9e6
cycles in check_for_temporal_macros when compiling src/ccache.cpp. With USE_AVX
set that figure goes down to ~6.7e5.
Compiling all of ccache with -mavx2 makes the unittest crash with "Illegal
instruction: 4" when run on travis (Mac OS X). My guess is that -mavx2 makes
clang generate code that uses instructions that doesn't work on the CPUs used
on the build server (see [0]).
Instead compile only check_for_temporal_macros_avx2 with -mavx2 as we can
control when that function is called (i.e. only do it when the cpu supports
it).
Joel Rosdahl [Mon, 21 Oct 2019 18:06:22 +0000 (20:06 +0200)]
Don’t fail fatally if temporary cpp_stderr file is missing
If the temporary cpp_stderr file is missing when the compilation command
has finished then either some user removed it or ccache removed it in
clean_up_internal_tempdir (since the compilation took more than hour or
the system clock was adjusted?). In either case, let’s just fall back to
running the real compiler instead of failing fatally.
Joel Rosdahl [Sat, 19 Oct 2019 10:43:39 +0000 (12:43 +0200)]
Improve functions related to (l)stat-ing
Introduced a Stat class that represents a “struct stat”. The class
replaces the utility functions x_lstat, x_stat, file_size_on_disk and
is_symlink, and it provides an easier to use interface than the macros
associated with stat structs.