This is the mail archive of the
mailing list for the GCC project.
Re: GNU Pascal branch
Adriaan van Os <email@example.com> 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
>>> 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