ccache bugs are pretty nasty when they happen. I have not seen one in a while...

Can you post the preprocessed files and compiler command lines for dpu_plane.c and dpu_hw_sspp.c?

team - what component can we assign to this bug so it does not show up in Chrome OS UI triage?

> Can you post the preprocessed files and compiler command lines for dpu_plane.c and dpu_hw_sspp.c?

I can try.  I'm not sure it's going to be terribly easy to inject myself into the kernel's build system to do this, but I can try to futz it...

will add "build" as a component. ccache is not part of the toolchain but I don't know if it has a clear owner.

easiest is prob to update our ccache version and see if that addresses things.  otherwise, debugging ccache errors like this is a bit of a pita :/.

To generate the pre-processed files add the following to drivers/gpu/drm/msm/Makefile:

subdir-ccflags-y += -save-temps

there is probably a smaller hammer to only apply the flag to the files you are interested in, however I dunno how to specify that for files in sub-directories.

I wonder if this is because the msm display driver is weirdly integrated into the kernel build system and doesn't use the normal recursive makefile rules that all other kernel drivers use. Instead it splits up the driver into many sub-directories and then combines them all into one big module. It's been on my todo list to undo this and make either individual modules for each sub-component of the larger graphics "card" driver or flatten the hierarchy out and put things into one directory instead of so many sub-directories.

Either way, does the ccache corruption happen anywhere else in the kernel? Because if it does then I'm totally wrong and this isn't related to the problem at hand. Otherwise, it's all the more reason to fix the way this driver is built in the kernel.

> subdir-ccflags-y += -save-temps

Oddly this causes the compile to fail.  

/mnt/host/source/src/third_party/kernel/v4.19/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1739:45: error: address of 'dpu_enc->base' will always evaluate to 'true'
      [-Werror,-Wpointer-bool-conversion]
 trace_dpu_enc_vsync_event_work(((&dpu_enc->base) ? (&dpu_enc->base)->base.id : -1), wakeup_time);
                                   ~~~~~~~~~^~~~  ~

...which seems like a bug, but why did it only get reported when I turned on -save-temps?  If I add "-save-temps" more globally I start getting tons of warnings.  Do you want me to file a bug about this, or is it expected?

In any case I'm slightly worried that adding "-save-temps" will be enough to make ccache stop showing the problem.  

===

I'm also a little worried because I didn't think and I did a "repo sync" today.  That probably means my compiler changed and (hopefully) ccache will ignore all the old stuff.  I'll try to repro anyway...  Doh, looks like I can't...

===

I'm inclined to wait to see if this type of thing happens again and/or upgrade ccache.  ...then refer back to this.

Can you pass "-Wno-error" in addition to "-save-temps". I have seen that clang produces extra warnings with "-save-temps" that can cause compiles to fail.

I find getting the new warnings only under -save-temps very weird. 
Can you file a separate bug for that? 

The only instance of that I have seen before is documented in https://bugs.chromium.org/p/chromium/issues/detail?id=649740

and there is an update to that in http://peter.eisentraut.org/blog/2014/12/01/ccache-and-clang-part-3/

but I cannot see how what dianders is getting is related to that.

@12: created bug #916736

===

I'll also note that with my chroot upgrade my old ccache doesn't seem to repro the problem anymore.  Sigh.  If I see it again I'll try to find a way to gather more data.