search

davidmalcolm / gcc-python-plugin

GCC plugin that embeds CPython inside the compiler
GNU General Public License v3.0
199 stars 58 forks source link

invalid flag "WITH_CPYCHECKER_RETURNS_BORROWED_REF_ATTRIBUTE" when using ccache #81

Open davidmalcolm opened 7 years ago

davidmalcolm commented 7 years ago

When building the plugin with "make", it builds fine, but all tests immediately fail: e.g. {{{ --- Expected stderr +++ Actual stderr @@ -1,13 +1,4 @@ -tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/input.c: In function 'incorrect_usage_of_S_and_U': -tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/input.c:33:21: warning: Mismatching type in call to PyArg_Parse with format code "SU" [enabled by default]

returncode: 1 compiling: gcc -c -o tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/output.o -fplugin=/home/tomspur/scratch/src/gcc-python-plugin.git/python.so -fplugin-arg-python-script=tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/script.py -I/usr/include/python2.7 tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/input.c Stdout:

Stderr: tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/input.c:1:1: error: invalid flag "WITH_CPYCHECKER_RETURNS_BORROWED_REF_ATTRIBUTE" in line directive tests/cpychecker/PyArg_Parse/incorrect_codes_S_and_U/input.c:1:48: warning: extra tokens at end of ## directive [enabled by default] /usr/include/stdio.h:35: confused by earlier errors, bailing out Preprocessed source stored into /tmp/cclgFJfX.out file, please attach this to your bugreport. }}} {{{ $ rpm -q python gcc glibc-headers python-2.7.2-5.2.fc16.x86_64 gcc-4.6.3-2.fc16.x86_64 glibc-headers-2.14.90-24.fc16.6.x86_64 }}}

10 lines around line 35 in stdio.h (what you also asked for online): {{{ 23 24 #ifndef _STDIO_H 25 26 #if !defined need_FILE && !defined _needFILE 27 # define _STDIO_H 1 28 # include 29 30 BEGIN_DECLS 31 32 # define need_size_t 33 # define need_NULL 34 # include 35 36 # include <bits/types.h> 37 # define need_FILE 38 # define need_FILE 39 #endif / Don't need FILE. / 40 41 42 #if !defined FILE_defined && defined need_FILE 43 44 / Define outside of namespace so the C++ is happy. / 45 struct _IO_FILE; 46 47 BEGIN_NAMESPACE_STD 48 / The opaque type of streams. This is the definition used elsewhere. / 49 typedef struct _IO_FILE FILE; 50 END_NAMESPACE_STD 51 #if defined USE_LARGEFILE64 || defined __USE_SVID || defined USE_POSIX \ 52 || defined USE_BSD || defined __USE_ISOC99 || defined USE_XOPEN \ 53 || defined __USE_POSIX2 54 __USING_NAMESPACE_STD(FILE) 55 #endif 56 }}}

davidmalcolm commented 7 years ago

Imported from trac issue 41. Created by tomspur on 2012-04-30T13:06:24, last modified: 2013-03-21T01:50:27

davidmalcolm commented 7 years ago

Trac comment by dmalcolm on 2012-05-07 12:36:03:

I started running into this on a freshly installed F17 box, and it seems to be a bad interaction between the plugin and ccache.

I was able to reproduce it with an empty source file (apart from comments) and with tests/plugin/macros/correct/script.py, when ccache is installed an active. With that reproducer, I was able to make the error go away by setting either {{{ CCACHE_DISABLE=1 }}} or by uninstalling ccache.

The error comes from: {{{ if (token->type != CPP_EOF) cpp_error (pfile, CPP_DL_ERROR, "invalid flag \"%s\" in line directive", cpp_token_as_text (pfile, token)); }}} within gcc's libcpp/directives.c:read_flag; this function has this comment: {{{ / Subroutine of do_linemarker. Read possible flags after file name. LAST is the last flag seen; 0 if this is the first flag. Return the flag if it is valid, 0 at the end of the directive. Otherwise complain. / }}}

do_linemarker has this comment: {{{ / Interpret the # 44 "file" [flags] notation, which has slightly different syntax and semantics from #line: Flags are allowed, and we never complain about the line number being too big. / }}} The plugin tries to inject a {{{

define WITH_CPYCHECKER_RETURNS_BORROWED_REF_ATTRIBUTE

}}} but gcc is trying to interpret that as the flag in such a directive, presumably injected by ccache.

I've seen other bad interactions between the plugin and ccache. It's probably best to simply require that ccache be disabled when using the python plugin, though there may be a clean way to fix this (e.g. somehow inject a CPP_EOF token before injecting the #define).

davidmalcolm commented 7 years ago

Trac comment by mcepl on 2013-03-21 01:50:27:

Yes, I can reproduce with gcc-4.7.2-8.el7.x86_64 (gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)). And yes, setting CCACHE_DISABLE makes results being much better.