https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63178

Dima Kogan <gccbugs at dima dot secretsauce.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #10 from Dima Kogan <gccbugs at dima dot secretsauce.net> ---
Hi.

I filed this bug against ccache, and its maintainer had some insight and thinks
that this is a gcc issue after all. I'm reopening this bug here with the
salient portion of the comment from the ccache maintainer copied below. Thanks.


I would say that this is not a ccache bug. For ccache to work as expected in
its default operation mode, the compiler must be able to compile its own
preprocessed source code with the same result as compiling without the
preprocessing step.

In essence,

    compiler [OPTIONS] -E source.c -o source.i
    compiler [OPTIONS] -c source.i -o source.o

needs to give the same result as

    compiler [OPTIONS] -c source.c -o source.o

GCC doesn't do that for your test case:

    % gcc-4.9 -Wall -Wextra -E bugreport.c -o bugreport.i
    % gcc-4.9 -Wall -Wextra -c bugreport.i -o /dev/null
    % gcc-4.9 -Wall -Wextra -c bugreport.c -o /dev/null
    bugreport.c: In function ‘fn1’:
    bugreport.c:14:5: warning: passing argument 1 of ‘fff’ from incompatible
pointer type
     fff(&sss,0,0);
         ^
    bugreport.c:6:5: note: expected ‘struct sss_t *’ but argument is of type
‘struct sss_t **’
     int fff( sss_t* ctx, int a, int b);
         ^
    bugreport.c:15:1: warning: control reaches end of non-void function
[-Wreturn-type]
     }
     ^

.....

Digging a bit deeper, the behavior difference comes from this part of the
preprocessed output:

    % tail -n 11 bugreport.i
    int fn1()
    {
        sss_t* sss = ((void *)0);

        printf("%s %d",
     "bugreport.c"
    # 12 "bugreport.c" 3 4
        , 0 )
                      ;
        fff(&sss,0,0);
    }

The flag "3" after '# 12 "bugreport.c"' indicates that the following text comes
from a system header, which doesn't look right. (If bugreport.h is found
locally instead of in /usr/include, then the "3" flag disappears.) Sounds like
a GCC bug to me.

Reply via email to