Internal Error compiling ddd
Hi,
I get the following error when compiling ddd-3.2.1 on IA-64:
c++ -DHAVE_CONFIG_H -DNDEBUG -O2 -g -W -Wall -trigraphs -c -I. -I. -I./.. -isystem /usr/X11R6/include -o DataDisp.o DataDisp.C BoxPoint.h: In function `void DataDisp::newCB (_WidgetRec *, void *, void *)':
BoxPoint.h:1352: Internal compiler error in `fix_lexical_addr', at function.c:5409
Please submit a full bug report.
The version of gcc is 2.9-ia64-000216-final.
Let me know if I can provide better info to debug this.
Mike Madore
Software Engineer
TurboLinux, Inc.
BoxPoint.h:1352: Internal compiler error in `fix_lexical_addr', at function.c:5409
Probably a known bug with the C++ front end in the February (000216) toolchain. I'd suggest trying different optimization options -O1 or -O0.
The February toolchain is based on an FSF snapshot from Jan 3, and there were unfortuntely some instabilities in the C++ front end at that time due to C++ front end development. These bugs have all been fixed long ago. But since they were fixed by additional C++ front end development, the patches aren't really suitable for a released toolchain.
I think the best fix for this is to make a new release, and hope that the new release has a more stable C++ front end. Unfortunately, this is likely to continue to be a problem until the FSF makes a release, since there continues to be a lot of development work going into the C++ front end and other parts of gcc.
Red Hat is working on a new toolchain release for the ia64-linux project. We made a CVS branch for the release last Monday, based on the July 10 FSF gcc snapshot, and we are now testing the compiler and fixing bugs. I could make a pre-release at any time, but I think we need to fix a couple of more bugs before that will be really useful.
Jim
Quoted 7 lines · Jim Wilson
Red Hat is working on a new toolchain release for the ia64-linux project. We made a CVS branch for the release last Monday, based on the July 10 FSF gcc snapshot, and we are now testing the compiler and fixing bugs. I could make a pre-release at any time, but I think we need to fix a couple of more bugs before that will be really useful.
Hi, Jim,
I assume you are aware that EH of glibc/gcc is currently broken under ia64. I have proprosed a fix:
http://gcc.gnu.org/ml/gcc/2000-07/msg00168.html
http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html
Could you please make sure the new ia64 toolchain is ok?
Thanks.
H.J.
I am aware of your messages on this subject to the FSF gcc mailing lists. However, none of your messages actually report any bugs. You just claim that bugs exist and propose solutions for them. Your proposed solutions involve a redesign of gcc, are highly controversial, and very unlikely to be adopted anytime soon. Thus I am in a position where I can't fix anything because I don't have anything to work with.
As I understand it, glibc needs to know about frame_object which is a gcc internal variable. The gcc hackers didn't know about this until you pointed it out. frame_object had to be changed in gcc to support the Intel defined IA-64 exception handling model. Thus glibc will have to be changed to match the gcc changes. I see nothing in gcc to fix. Since I'm not doing glibc work, you need to report this to one of the glibc maintainers, e.g. Jes or Ulrich, and ask them to fix glibc. Perhaps this work has already been done for glibc 2.2, I don't know. If so, then there is nothing left to fix.
glibc 2.1.3 and the current FSF gcc sources would still be broken, but it has never been anyone's intent to make that work. You should be using the February (000216) release with glibc 2.1.3.
Jim