This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Ada] Fix bogus noreturn warning
On Sun, 27 Jun 2010, Manuel López-Ibáñez wrote:
> On 27 June 2010 20:03, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Sun, 27 Jun 2010, Manuel López-Ibáñez wrote:
> >
> >> I really appreciate what you are trying to do but I insist once more
> >> that the ideal interface should be first defined somewhere for people
> >> to read, and then start moving things around to match it. The other
> >
> > I would strongly advocate incremental development in this area as in
> > others. ?Small patches can be made that improve modularity in one area
>
> You do not need any patch to define what and what not should be
> included by other parts of the compiler. I am asking for that. A
> simple question: what headers should and should not be included
> (ideally) by FEs?
My claim is that there are two answers. One is so high-level and general
as to be almost useless: only those headers relating to general purpose
interfaces shared by all of GCC, or to the interfaces for lowering from
front-end IR to GIMPLE, or to the interfaces for giving information about
the target required by the front end. The other, a precise list of
headers, can only be derived through a series of incremental patches that
create the headers in question, separate interfaces at different levels
and result in front ends including exactly the headers they should
include; this process will converge on the answer at the same time as the
front ends conform to the answer, and the headers in question may not
exist until that process of convergence is finished. The way to get the
precise answer is to use the general answer as a guide to the *general
direction* of patches towards that convergence.
If someone claims they can look 20 steps ahead and see exactly what new
headers will be needed at each stage and what declarations should go in
what header, I don't believe them. I don't think it's useful to look more
than two or three steps ahead in that level of detail (say, decide you
want to create gimplify.h, discover a problem in the course of
implementation and so instead do a smaller patch to fix that problem
before seeing if there are other obstacles to creating gimplify.h).
Ask not what the overall ideal interface is. Pick a single modularity
issue you don't see how to fix and open a discussion of possible
approaches for that issue on its own, or pick one you do see how to fix
and fix it.
--
Joseph S. Myers
joseph@codesourcery.com