Bug #9574
closedFix support of wide character strings
Added by Ilya Shchepetkov about 5 years ago. Updated over 4 years ago.
0%
Description
Error:
In file included from /home/shchepetkov/work/git/cif/build/x86_64-pc-linux-gnu/libstdc++-v3/include/unordered_set:48:0,
from /home/shchepetkov/work/git/cif/aspectator/libstdc++-v3/include/precompiled/stdc++.h:118:
/home/shchepetkov/work/git/cif/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unordered_set.h:1610:1: internal compiler error: in gt_pch_note_object, at ggc-common.c:276
} // namespace std
The issue is confirmed by me and Ilja. You need to perform a clean build to reproduce it.
Updated by Evgeny Novikov about 5 years ago
Okay, I will see. You can use the latest CIF that was re-built on base of the previous build: https://forge.ispras.ru/attachments/download/6352/cif-1517e57.tar.xz.
Updated by Evgeny Novikov about 5 years ago
- Status changed from New to Open
- Try to build CIF from scratch at clear openSUSE 15.0 and Ubuntu 18.04 without updates.
- Try to build GCC 7.3.0 at openSUSE 15.0 (both clear and updated).
- Try to disable the C++ support that is obviously redundant in C Instrumentation Framework. BTW, before merge with GCC 7.3.0 there was not such the support.
Updated by Ilya Shchepetkov about 5 years ago
I was able to reproduce the issue yesterday on macOS with Clang as stage1 compiler.
Updated by Evgeny Novikov about 5 years ago
Ilya Shchepetkov wrote:
I was able to reproduce the issue yesterday on macOS with Clang as stage1 compiler.
It seems that something changed in the whole world. Perhaps, neutrinos crashed all Intel CPUs :)
Updated by Ilya Shchepetkov about 5 years ago
I was able to build GCC 7.3.0 on Ubuntu 18.10 without issues using similar configuration (configure --enable-languages=c --disable-libsanitizer --disable-multilib --enable-checking=release).
Updated by Evgeny Novikov about 5 years ago
- Status changed from Open to Closed
I created an interesting workaround for this issue in abed03d. After update everyone should "make clean" existing CIF installations before building CIF again.
BTW, I do not know why I did not understand what changes caused the issue. Indeed, it is exactly last changes for #9559. But I still can not understand relations between these changes and the build failure since the latter happens when creating the precompiled C++ header somewhere in the middle. I do not see other ways to implement #9559 at the moment.
The workaround is interesting because I disabled so called bootstrap. You can read about this in details here. In general, CIF is built just one time by a system compiler now. So, there is not the build failure, when CIF builds itself during bootstrap. Besides, one can build CIF from scratch much faster (re-build should be also much faster). On my machine a complete CIF build took only ~3,5 minutes of wall time and ~22,5 minutes of CPU time instead of ~16/~101 minutes respectively.
The workaround is not great nevertheless since if CIF fails when it builds itself, it can also fail one day for other software as well. But let's hope that everything will be okay at least for our target C software.
Updated by Evgeny Novikov about 5 years ago
I forgot to say. In addition to Ilya's experiments, I tried to build CIF from scratch on openSUSE 15.0 and Debian 9.5. These builds succeeded without #9559 changes and failed with them. Updates did not matter.
Besides, I did not investigate much how to disable the C++ support since configuration already does that but it does not help. I suggest that it is because new GCC is in C++ and it is compiled by g++. Thus, to build itself on stages other than the first one the C++ support is obviously required. But now we do not go beyond the first stage, so, in theory we should be able to disable the C++ support. Let's investigate this additionally.
Updated by Ilya Shchepetkov about 5 years ago
I have implemented a proper fix in c2209438.
I strongly suggest to reverse your workaround and return bootstrap back since it is quite a comprehensive consistency check that can be used to detect bugs in our code. It is wrong to simply turn it off just to increase compilation speed.
Updated by Evgeny Novikov about 5 years ago
Ilya Shchepetkov wrote:
I strongly suggest to reverse your workaround and return bootstrap back since it is quite a comprehensive consistency check that can be used to detect bugs in our code. It is wrong to simply turn it off just to increase compilation speed.
Here is a good recommendation:
If your system compiler is the same major version as the compiler version you wish to build (for instance, if you have 4.6.2 and want 4.6.3), then you don't need to bootstrap.
Regarding a new version scheme, as far as I understand, it is enough to use GCC 7.x for building CIF without necessary bootstrapping. I guess that we can check for this automatically pretty well rather than require users to care about some non-obvious environment variables.
As for the particularly detected bug it is not intention of bootstrap. Indeed, it can pass, but CIF will fail to compile some code later. The only thing that can confirm CIF quality well is successful building of target software (or at least building without regressions).
Updated by Evgeny Novikov about 5 years ago
I returned back bootstrap. One can disable it with, say:
ASPECTATOR_CONFIGURE_OPTS="--disable-bootstrap" make -j16
Updated by Evgeny Novikov about 5 years ago
- Related to Bug #9559: C back-end incorrectly prints wide character strings added
Updated by Evgeny Novikov almost 5 years ago
- Subject changed from CIF build is broken to Fix support of wide character strings
- Status changed from Closed to Open
There are still segmentation faults due to dereference of null pointer and absence of strings in a hash table. I will investigate and fix them.
Updated by Evgeny Novikov almost 5 years ago
- Status changed from Open to Resolved
Perhaps I fixed the issue in d06fc42. Indeed, all paths where converted strings change (and later exactly these changed values are used) suffer from this issue. We need to refill a hash table appropriately. I hope that there are no many such cases.
Let's wait for some external test results.
Updated by Evgeny Novikov almost 5 years ago
Another one fix is in d472cc9. It may be dangerous since for all cases when for a (converted) string there is no appropriate slot in a hash table (or when there is not a hash table at all) the converter implements a fallback - it just refers to this string. Sometimes this should be okay, e.g. for PRETTY_FUNCTION corresponding strings are not converted. But there may be other non-standard paths where a conversion is performed.
Updated by Evgeny Novikov almost 5 years ago
I would like to test it within several environments like the Linux kernel and the Juliet test suite where some (many) failures were due to this issue.
Updated by Evgeny Novikov over 4 years ago
- Status changed from Resolved to Closed
It seems that it works since nobody complains thus far.