Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.
Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
GCC gets a new Optimizer Framework
GCC gets a new Optimizer Framework
Posted May 13, 2004 14:19 UTC (Thu) by JamesErik (subscriber, #17417)Parent article: GCC gets a new Optimizer Framework
Can anyone comment as to whether the GCC teams has become any more amenable
to the idea of exporting intermediate representations to a user-accesible format such
as XML? The GCC-XML patches do this, but it would be nice if it were a standard
feature of the compiler itself. From what I understand, the GCC team's hesitancy is
for fear of proprietary backends being able to leverage the GCC front-end via a
standardized, accessible IR format. Still, it would be hugely useful for user-level
source code analysis (doxygen, for example) and source code generation (for me).
(Log in to post comments)
GCC gets a new Optimizer Framework
Posted May 13, 2004 17:17 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
While there are a variety of useful debugging dumps from GCC, the FSF is strongly opposed to mechanisms that would allow the complete internal state to be dumped and reloaded (for example, a complete XML representation of the parse trees), because a variety of people will quickly use such mechanisms to add proprietary optimization passes and back ends to GCC, instead of contributing that code in source form under the GPL to GCC. To support their argument, they point out that we only have a GNU C++ front end and a GNU Objective-C front end because these types of interfaces were not present at the time these front ends were developed (in both cases, companies involved tried to find legal ways of making their employees' work proprietary, then gave up and contributed the code).
The FSF will not try to prevent other people from making or distributing "XML patches", but those kinds of patches won't be accepted for the official GCC. At least, not now; it is possible that the policy will have to be relaxed at some point to properly support the C++ "export" keyword, in the sense that some form of pre-parsed external representation will have to be stored. And, in the case of Ada, there is a standard external representation, and the FSF is quite willing to let the GCC developers do what is necessary to support language standards.