One of my colleagues started today to fix all broken code in our database system that prevents gcc 4.0 from building it because he wants to have his workstation updated to SUSE Linux 10.0. He also requested to appear in this blog for this heroic action and thus I am reporting here what I have seen during the day while being the local C++ coding consultant for this project.
Most bugs where quite simple stuff like not including include files for interfaces that were used, funny (but unfortunately wrong) syntax variants for template specification or instantiation, broken namespace usage, encapsulation of an interface part, type conversion errors, and stuff like that.
But then after the boring stuff we discovered a bug that made the project stop for some hours. First we did only see gcc crash with an internal compiler error. I was immediately alarmed because this happened with a file that was generated by the compiler construction toolkit we use. This toolkit is famous for being quite unreadable and unportable code and randomly odd behavior. I tracked down the gcc bug and found that it was a bug fixed some days after the SUSE gcc for 10.0 was branched. At the same time I found that the generated parser code is non-valid and definitely silently produces incorrect binaries independent of the compiler used. A stripped down version of the broken code is "int a[1]; int* b = &a[-1]; int* c = b;", just for the case you want to crash the SUSE Linux 10.0 gcc. To enable my colleague continuing his heroic project I have built a replacement cc1plus binary for the system compiler. It seems quite unlikely to be able to fix the used parser generator thus the only solution here seems to be migrating to a different toolkit, especially because the current toolkit doesn't run on x86_64 anyway.
No comments:
Post a Comment