Adriaan van Os <[EMAIL PROTECTED]> wrote: >> and people are >> responsible for fixing all front ends when they do backend changes. > > I don't believe that, they would just say, "oh, it is broken" or "oh, > it is not a primary language" or whatever excuse.
You probably don't follow GCC development enough. Every middle-end/backend change *must* go through a full bootstrap and regression free cycle, for all active languages, either minor or major. So it should never happen that a change to the optimizer breaks the Pascal frontend. If it does, you can blame it on the person who did the change, and ask him to fix it (or revert it). This is how GCC development. Even for cases where the frontend is not active by default (eg. Ada), people are still helpful and often test and fix the Ada frontend, when the bugs are properly reported in Bugzilla. There is cooperation going on. You can often see GCC middle-end/back-end maintainers cooperating and producing patches to fix Ada bugs. >>> Also, flexibility in choosing the back-end >>> version sometimes has its advantages, dependent on the platform, >>> given the fact that reported gcc bugs are not always fixed. >> >> So you could help fix them, instead of forcing people to stick to >> older backends ;-) > > We are not forcing anybody, we offer full choice. Not fixing > backend-end bugs is what is actually forcing people. And even patches > that do fix bugs are often not accepted. There are often reasons for this. Sometimes the patches refer to bugs which are triggered by GNU pascal frontend only, and you need a way to reproduce the bug to have the patch accepted. Having the GNU pascal integrated, means that you can show a pascal testacase for the bug, have a proper PR number in Bugzilla for the issue, and thus having the patch reviewed and accepted. If you enter the full development cycle of GCC, you are making this process many times easier. Giovanni Bajo
