Mark Mitchell is one of the people behind CodeSourcery, but he is mostly known for his major contributions on GCC, the Gnu compiler. These days, Mark is the release manager of GCC and he is working hard trying to get GCC 3.1 out of the door. GCC 3.1 is going to be the first truly stable version of the 3.x source branch and many developers are already looking forward for it. Mark talked to OSNews about the new GCC, the future and the competition.1. Are there any plans about making gcc3 emit C++ code that’s binary-compatible with gcc2.x’s ABI? (this is most useful for BeOS, which is “stuck” with Gnu PRO 2.9x as any effort to use GCC 3.x breaks binary compatibility mostly because BeOS is C++ only, or for Qt/wxWindows C++ applications under Unix)
Mark Mitchell: No, there are not. The previous ABI was inferior, from a technical standpoint. In addition, the G++ development team decided that the costs of maintaining two separate ABIs outweighed the benefits from providing that compatibility. Instead, we are focused on minimizing sure that no changes occur in the current ABI so that binary compatibility will be preserved between releases of G++.
2. Are there any plans for supporting the “native” Crusoe instruction set and maybe some more “exotic” CPUs, like the Infineon C166?
Mark Mitchell: Not to my knowledge.
3. Is there an auto-vectorizer for modern CPUs in place? If not, are there plans for something like it?
Mark Mitchell: Not to my knowledge.
4. What are your thoughts about moving the codegen after the linker, to allow for global optimization/inlining?
Mark Mitchell: There are people you are interested in global optimization, including link-time optimization. As far as I know, those people have generally not contemplated moving *all* compilation after linking; instead, they have considered recompiling some portions of the code at that time.
The profile-directed optimizations in GCC provide another approach to this problem. The linker could simply collect information that is then provided back to the GCC the next time the compiler is run.
5. Is gcc3 written in ANSI-C? For example, can it be compiled with any compliant compiler?
Mark Mitchell: The C front end is written in ANSI/ISO C, and can be compiled with almost any C compiler. Some of the other front ends are written using GNU C extensions, and can only be compiled by GCC itself.
6. What about features found in VC++, like recompiling part of an app while it’s running, or incremental linking? Are these features supported?
Mark Mitchell: No, they are not.
7. Are there plans to make gcc emit more warnings than the MsVC which can greatly help programmers?
Mark Mitchell: There are a lot of different points of view on warnings. Lots of warnings can be helpful, but if there are too many “false positives”, i.e., warnings that do not really indicate problems, people stop paying attention to them.
There is work ongoing to improve the overall quality — as well as quantity.
8. What did you think about the Intel Compiler v6 that came out recently? Did you have time to have a look at it?
Mark Mitchell: I do not have enough information about that compiler to comment on it.
9. Regarding the output of gcc, some people say that Intel’s ICC produces up to 30-35% better code. If this is true, what steps the Gcc team will take for further optimizations?
Mark Mitchell: I do not have concrete data about which compiler is faster, although I have heard reports that ICC is faster. The important thing to remember about benchmarks is that what really matters is how fast *your* code runs. The best way to compare two compilers is to compile your code, or code that is representative of your code.
People are always working on new and improved optimizations in GCC. For example, people are working on a new register allocator that should improve performance. The easy part about implementing an optimization is writing code for the algorithm. The hard part is making sure it works on all the architectures supported by GCC, and tuning the algorithm.
10. As a rough estimate, how much better is Gcc 3.x, compared to Gcc 2.x, for the Motorola G3/G4 architecture?
Mark Mitchell: I really do not know how to measure “better”. We believe that GCC 3.1, which will be released very soon, has better language support, fewer bugs, and in many cases generates faster code. We hope that people will try GCC 3.1, and provide us feedback about what additional features and optimizations they would like.