Bug #9346
closed
Remove "-include" options after second stage
Added by Evgeny Novikov over 5 years ago.
Updated almost 5 years ago.
Description
It seems that after switching to GCC 7.3.0 we have the following issue. Options "-include" forces a preprocessor to always include corresponding headers at the beginning of source files. So they are included at the second stage first and then at all other stages as well. Sometimes when there just defines in included headers this does not hurt anybody. But, say, in Linux 4.15 there are type definitions that cause redefinition errors and failures in 100% of cases.
Header protecting macros do not help in this case as input files at third and following stages are already preprocessed. Also, option "-x cpp-output" and new option "-fpreprocessed" do not help (most likely the first one helped when Aspectator was based on GCC 4.6). Thus we need to remove all "-include" options after second stage. I hope that other preprocessor options can not break anything.
- Has duplicate Bug #9372: "cif" failed: redefinition of ‘struct ftrace_branch_data’ for net/xfrm/xfrm_user.ko added
- Blocked by Feature #6780: Implement CIF in Python (script and module) added
We investigated this issue more and found out that its reasons are more tricky as mentioned in description. It seems that it is caused somehow by CIF itself. Since we have had too many issues with implementation of CIF in C, the CIF test infrastructure is in Python already and there is #6780 that aims at adding a Python binding, I suggest to reimplement CIF in Python completely. This will simplify its development and support considerably while it will not hurt anybody much since most CIF users are Python applications, and thus, an interface will be even more convenient and there will be no considerable performance overhead.
Evgeny Novikov wrote:
We investigated this issue more and found out that its reasons are more tricky as mentioned in description. It seems that it is caused somehow by CIF itself. Since we have had too many issues with implementation of CIF in C, the CIF test infrastructure is in Python already and there is #6780 that aims at adding a Python binding, I suggest to reimplement CIF in Python completely. This will simplify its development and support considerably while it will not hurt anybody much since most CIF users are Python applications, and thus, an interface will be even more convenient and there will be no considerable performance overhead.
Small nitpick: users do not launch CIF tests, so it really does not matter in what language they are written. That certainly doesn't mean that CIF should be written in Python as well.
Ilya Shchepetkov wrote:
Evgeny Novikov wrote:
We investigated this issue more and found out that its reasons are more tricky as mentioned in description. It seems that it is caused somehow by CIF itself. Since we have had too many issues with implementation of CIF in C, the CIF test infrastructure is in Python already and there is #6780 that aims at adding a Python binding, I suggest to reimplement CIF in Python completely. This will simplify its development and support considerably while it will not hurt anybody much since most CIF users are Python applications, and thus, an interface will be even more convenient and there will be no considerable performance overhead.
Small nitpick: users do not launch CIF tests, so it really does not matter in what language they are written. That certainly doesn't mean that CIF should be written in Python as well.
I didn't say that users launch CIF tests. But I think that for most projects test infrastructures and likely tests themselves are developed in the same programming languages and perhaps using the same frameworks as for corresponding projects. This is not a rule, but this is an alarm. C is great for rather low-level things. For the rest there are many other great means.
- Blocked by deleted (Feature #6780: Implement CIF in Python (script and module))
Because of getting rid of CIF wrapper is too complex task, let's fix this one separately.
- Status changed from New to Resolved
It seems that I fixed the issue in 79a0019.
For anybody who is interested. Indeed, the issue was not due to some memory issue in the CIF wrapper, so, I had to fix it anyway. It was introduced a long ago, when CIF started to treat input files as non-preprocessed at the last stage. That was necessary to establish connections between original source files and auxiliary ones via line directives. I did not revert the latter since it is a very useful feature, but I did exactly that thing that was suggested originally in the issue title except for I changed not all stages after the second one but only the last one that suffers from this bug.
- Status changed from Resolved to Closed
I checked that this really works.
Also available in: Atom
PDF