{"id":582,"date":"2008-08-03T00:08:22","date_gmt":"2008-08-03T07:08:22","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/ccache-makes-gcc-crash\/"},"modified":"2008-08-06T22:21:45","modified_gmt":"2008-08-07T05:21:45","slug":"ccache-makes-gcc-crash","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/ccache-makes-gcc-crash\/","title":{"rendered":"ccache Makes gcc Crash"},"content":{"rendered":"

Well this is mildly disconcerting: ccache<\/a> can make gcc<\/a> crash. Now, I am the first person to extol the virtues of ccache; the tool dramatically decreases the amount of time that the FATE farm<\/a> has to spend rebuilding FFmpeg. But the crash is quite reproducible.<\/p>\n

If you have kept up with FATE for any length of time, you know that there is a chronic problem with compiling FFmpeg<\/a> using SVN versions of gcc on PowerPC — in particular, the build phase tends to crash with an internal compiler error. Last night, I upgraded the gcc-SVN compilers on all the FATE machines. Tonight, I was determined to sit down and finally go through all the steps to submit the highest quality gcc bug report<\/a> I could. I thought it would be prudent to report the full command line without the ccache command. Wouldn’t you know, the problem file compiles fine. From there, it takes over 20 minutes instead under 5 to compile the whole tree. Running the FATE test suite<\/a> also passes with flying colors. <\/p>\n

So there’s a bug here. Where do you think the problem lies? ccache or gcc? I have a bad feeling that this is the kind of problem both camps are likely to blame on the other. All I know is that the following command:
\n
\n$ \/usr\/bin\/ccache \/usr\/local\/gcc-138544-20080801\/bin\/gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I. -I”\/home\/melanson\/ffmpeg\/ffmpeg-main” -fomit-frame-pointer -maltivec -mabi=altivec -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -O3 -fno-math-errno -fno-signed-zeros -fPIC -DPIC -c -o libavcodec\/imc.o \/home\/melanson\/ffmpeg\/ffmpeg-main\/libavcodec\/imc.c
\n<\/em><\/p>\n

yields the output:
\n
\n\/home\/melanson\/ffmpeg\/ffmpeg-main\/libavcodec\/imc.c: In function ‘imc_decode_init’:
\n\/home\/melanson\/ffmpeg\/ffmpeg-main\/libavcodec\/imc.c:146: warning: assignment from incompatible pointer type
\n\/home\/melanson\/ffmpeg\/ffmpeg-main\/libavcodec\/imc.c: In function ‘imc_decode_frame’:
\n\/home\/melanson\/ffmpeg\/ffmpeg-main\/libavcodec\/imc.c:808: internal compiler error: in tree_node_structure, at tree.c:2412
\nPlease submit a full bug report,
\nwith preprocessed source if appropriate.
\nSee http:\/\/gcc.gnu.org\/bugs.html<\/a> for instructions.
\n<\/em><\/p>\n

Removing the prepended \/usr\/bin\/ccache command makes the internal compiler error go away. For the time being, I have removed ccache, but only from the problematic FATE configuration. The PowerPC machine will not be nearly as efficient at performing FATE work, but at least it will keep abreast of gcc-SVN changes.<\/p>\n

Update, 2008-08-05:<\/strong> Great news: Recent revisions of FFmpeg<\/a> have been causing the gcc-SVN copy for PPC crash, and without ccache. It looks like I will be able to pin this on gcc after all.<\/p>\n

Followup:<\/strong><\/p>\n