Re: [ccache] Making ccache and clang compatible
On 16 August 2012 14:54, Max Horn wrote: > On 19.07.2012, at 23:34, Joel Rosdahl wrote: > > Max, do you have a suggestion on which options would make sense to not > > pass to the preprocessor? > > Naively, any preprocessor option would be suspect, I guess. Based on the > clang manpage, that would include at least these: > [...] Thanks for the investigation! Are you (or someone else) interested in mocking up a patch for stripping those arguments from the preprocessor arguments? -- Joel ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
Dear Joel, sorry for the late reply -- I simply overlooked that this thread was resumed :-(. On 19.07.2012, at 23:34, Joel Rosdahl wrote: > On 11 July 2012 14:42, Max Horn wrote: >> On 11.07.2012, at 02:34, Martin Pool wrote: >>> If you are compiling from a .i or .ii file, the -D and -I options can't >>> have any effect. It's reasonable for clang to emit a warning about it, and >>> it would be reasonable for ccache to strip those options when compiling a >>> preprocessed file. >> >> Aye, if that would be acceptable for the ccache authors, that would be the >> best solution I think. It would certainly be much cleaner than trying to >> detect clang and passing options to it to disable that warning... > > I agree, as long as it doesn't introduce regression for other compilers. > > Max, do you have a suggestion on which options would make sense to not > pass to the preprocessor? Naively, any preprocessor option would be suspect, I guess. Based on the clang manpage, that would include at least these: -Dmacroname=value -Umacroname -include filename -Idirectory -Fdirectory -nostdinc -nostdlibinc -nobuiltininc I did some testing with the clang on my OS X 10.7.4 box, which is Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn) This tells me that the following options cause the warning to appear: -U, -I, -include Based on the (Apple) GCC man page, I tested various more options; I am not sure whether these are explicitly supported by Apple the following also all trigger the warning: imacros, idirafter, iprefix, iwithprefix, iwithprefixbefore, isystem, iquote (all takes a path as argument) -I-, -C, -CC, -remap, -fno-working-directory, -MG, -MP, -MD, -MMD, -MF foobar, -MQ foobar, -MT foobar -Xpreprocessor foobar, -Wp,foobar, Interestingly, -imultilib also triggered the warning, but given a bogus path, it also triggered a linker error. This looks like a bug to me, based on the documentation for this switch. These did not trigger the warning: -D (to my surprise), -F (also surprised med), -P, -nostdinc, -nostdlibinc, -nobuiltininc, -isysroot (agrees with documentation), Cheers, Max ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
Lubos Lunak wrote: On Wednesday 11 of J>>> but I think the bug originally described in< https://bugzilla.samba.org/show_bug.cgi?id=8460> could possibly be valid. If you are compiling from a .i or .ii file, the -D and -I options can't have any effect. It's reasonable for clang to emit a warning about it, and it would be reasonable for ccache to strip those options when compiling a preprocessed file. Aye, if that would be acceptable for the ccache authors, that would be the best solution I think. The best option is to use CCACHE_CPP2 with Clang. Giving Clang preprocessed source causes a number of small problems, such as some warnings not being suppressed or error/warning messages quoting modified source code. As a side-effect, this problem with preprocessor options will not exist with CCACHE_CPP2 either. It is a question how much not using CCACHE_CPP2 with Clang would improve performance anyway. This is a good point. Showing errors coming from monolithic preprocessed file and not from actual location is a bad thing to do. Yet there are cases where CCACHE_CPP2 will cause havoc. I found at least one of them when building virtualbox 4.1.18 with gcc 4.2: cc1plus: error: to generate dependencies you must specify either -M or -MM kmk: *** [/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/out/freebsd.amd64/release/obj/RuntimeBldProg/common/checksum/RTSha1Digest.o] Error 1 The failing command: @c++ -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long -Wno-variadic-macros -O2 -fno-omit-frame-pointer -fno-strict-aliasing -m64 -I/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/src/VBox/Runtime/include -I/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/src/libs/liblzf-3.4 -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -I/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/src/libs/boost-1.37.0 -I/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/include -I/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/share/virtualbox-ose\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/share/doc/virtualbox-ose\" -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -D_REENTRANT -DBOOST_DISABLE_ASSERTS -DIN_RING3 -DLOG_DISABLED -DIN_RT_R3 -DIN_SUP_R3 -DLDR_WITH_NATIVE -DLDR_WITH_ELF32 -DLDR_WITH_PE -DRT_WITH_VBOX -DRT_NO_GIP -DRT_WITH_ICONV_CACHE -Wp,-MD,/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/out/freebsd.amd64/release/obj/RuntimeBldProg/common/checksum/RTSha1Digest.o.dep -Wp,-MT,/tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/out/freebsd.amd64/release/obj/RuntimeBldProg/common/checksum/RTSha1Digest.o -Wp,-MP -o /tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/out/freebsd.amd64/release/obj/RuntimeBldProg/common/checksum/RTSha1Digest.o /tmp/ports/.amd_mnt/faz/host/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.18/src/VBox/Runtime/common/checksum/RTSha1Digest.cpp On the other hand preprocessing can be simplified with clang by adding -frewrite-includes flag starting with clang 3.2. This will make clang only rewrite includes and do nothing more than that. (http://llvm.org/bugs/show_bug.cgi?id=13282#c3) -- Sphinx of black quartz judge my vow. ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
On 11 July 2012 14:42, Max Horn wrote: > On 11.07.2012, at 02:34, Martin Pool wrote: >> If you are compiling from a .i or .ii file, the -D and -I options can't >> have any effect. It's reasonable for clang to emit a warning about it, and >> it would be reasonable for ccache to strip those options when compiling a >> preprocessed file. > > Aye, if that would be acceptable for the ccache authors, that would be the > best solution I think. It would certainly be much cleaner than trying to > detect clang and passing options to it to disable that warning... I agree, as long as it doesn't introduce regression for other compilers. Max, do you have a suggestion on which options would make sense to not pass to the preprocessor? -- Joel ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
On Wednesday 11 of July 2012, Max Horn wrote: > On 11.07.2012, at 02:34, Martin Pool wrote: > > On 5 July 2012 21:35, Mike Frysinger wrote: > >> On Wednesday 04 July 2012 09:53:46 Max Horn wrote: > >> err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when > >> running > >> in preprocessor mode (-E). i don't know if clang is broken, or your > >> analysis > >> is incorrect, but certainly that behavior you describe is wrong. > >> -mike > > > > I agree with you there, Mike, > > As do I, actually -- sorry, my email was indeed nonsense and confused. What > I *meant* was that on the second run (the one without -E, with preprocessed > data as input), clang prints out warnings. > > Now, I am not saying that ccache is doing anything wrong here, But you probably could. -I, -D, -U etc. are preprocessor options and not compiler options, and the preprocessor is (at least in the separate compilation steps theory) not run when the driver is fed preprocessed source. > > but I think the bug originally described in < > > https://bugzilla.samba.org/show_bug.cgi?id=8460> could possibly be valid. > > If you are compiling from a .i or .ii file, the -D and -I options can't > > have any effect. It's reasonable for clang to emit a warning about it, > > and it would be reasonable for ccache to strip those options when > > compiling a preprocessed file. > > Aye, if that would be acceptable for the ccache authors, that would be the > best solution I think. The best option is to use CCACHE_CPP2 with Clang. Giving Clang preprocessed source causes a number of small problems, such as some warnings not being suppressed or error/warning messages quoting modified source code. As a side-effect, this problem with preprocessor options will not exist with CCACHE_CPP2 either. It is a question how much not using CCACHE_CPP2 with Clang would improve performance anyway. -- Lubos Lunak [email protected] ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
On 11.07.2012, at 02:34, Martin Pool wrote: > On 5 July 2012 21:35, Mike Frysinger wrote: > >> On Wednesday 04 July 2012 09:53:46 Max Horn wrote: >>> Using ccache with clang tends to generate tons of warnings, which can >> range >>> from simply being annoying, to causing autoconf failures. This is because >>> ccache runs the compiler with "-E" on preprocessed input, but also passes >>> -I, -isystem etc. flags on to the compiler. In clang, this triggers >>> warnings about unused arguments. >> >> err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when >> running >> in preprocessor mode (-E). i don't know if clang is broken, or your >> analysis >> is incorrect, but certainly that behavior you describe is wrong. >> -mike >> > > I agree with you there, Mike, As do I, actually -- sorry, my email was indeed nonsense and confused. What I *meant* was that on the second run (the one without -E, with preprocessed data as input), clang prints out warnings. Now, I am not saying that ccache is doing anything wrong here, and one may argue about the usefulness of this clang warning. But it is here, and it affects people who would otherwise love to use ccache with clang (and that's not just me ;). > but I think the bug originally described in < > https://bugzilla.samba.org/show_bug.cgi?id=8460> could possibly be valid. > If you are compiling from a .i or .ii file, the -D and -I options can't > have any effect. It's reasonable for clang to emit a warning about it, and > it would be reasonable for ccache to strip those options when compiling a > preprocessed file. Aye, if that would be acceptable for the ccache authors, that would be the best solution I think. It would certainly be much cleaner than trying to detect clang and passing options to it to disable that warning... Thanks a lot, Max ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
On 5 July 2012 21:35, Mike Frysinger wrote: > On Wednesday 04 July 2012 09:53:46 Max Horn wrote: > > Using ccache with clang tends to generate tons of warnings, which can > range > > from simply being annoying, to causing autoconf failures. This is because > > ccache runs the compiler with "-E" on preprocessed input, but also passes > > -I, -isystem etc. flags on to the compiler. In clang, this triggers > > warnings about unused arguments. > > err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when > running > in preprocessor mode (-E). i don't know if clang is broken, or your > analysis > is incorrect, but certainly that behavior you describe is wrong. > -mike > I agree with you there, Mike, but I think the bug originally described in < https://bugzilla.samba.org/show_bug.cgi?id=8460> could possibly be valid. If you are compiling from a .i or .ii file, the -D and -I options can't have any effect. It's reasonable for clang to emit a warning about it, and it would be reasonable for ccache to strip those options when compiling a preprocessed file. -- Martin ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Making ccache and clang compatible
On Wednesday 04 July 2012 09:53:46 Max Horn wrote: > Using ccache with clang tends to generate tons of warnings, which can range > from simply being annoying, to causing autoconf failures. This is because > ccache runs the compiler with "-E" on preprocessed input, but also passes > -I, -isystem etc. flags on to the compiler. In clang, this triggers > warnings about unused arguments. err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when running in preprocessor mode (-E). i don't know if clang is broken, or your analysis is incorrect, but certainly that behavior you describe is wrong. -mike signature.asc Description: This is a digitally signed message part. ___ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
