[Ada] Fix bogus noreturn warning

[Steven Bosscher]

On Sun, Jun 27, 2010 at 6:00 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 27 June 2010 17:26, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Sun, Jun 27, 2010 at 5:17 PM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>
>>> How can anyone know that they are trespassing the interface
>>> between FEs and the rest of the compiler when such interface is not
>>> defined anywhere.
>>
>> Defining an interface is what I've been trying to do, to some extend,
>> with the project to remove include files from the front ends and/or
>> move function prototypes around to files that front ends do need (e.g.
>> tree.h).
>
> 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 problem is that things are so much entangled now, that it really
is just a matter of disentangling the worst first, then define
something and move to match it.


> The other
> way around will get quickly reverted, as we are seeing. I am actually
> surprised this is not happening more often.

It is not that surprising, because for the most part nothing has been
done yet. I've only cleaned up the really obvious parts so far.


>> I was hoping people would take the time to move a function out of a
>> header file if it is a middle-end header and a function is defined
>> there that is needed in a front end.
>
> The problem is that this is not a trivial task, for two reasons: 1)
> where to move it? There is no clearly defined interface between FEs
> and other parts of the compiler (is tree.h, gimple.h, basic-block.h?)
> 2) the chain of hidden dependencies that is broken when such move
> occurs.
>
> Why block_may_fallthru is declared in tree-flow.h? It is defined in
> gimple-low.c Should be in gimple.h? It doesn't seem to use anything
> gimple related. Who may call this function? Notice that there is also
> a gimple_stmt_may_fallthru. This is just a little example of why it is
> so much easier to just add another header. (And why the GCC code
> appears to be a mess for any outsider).

Fully agreed.  I also don't know off hand where block_may_fallthru
should be moved.

The silly thing is, it is even mis-named because it doesn't look at
blocks but at statement lists.  So it could live in tree.h, or
tree-iterator.h perhaps. Not basic-block.h or gimple.h because it
doesn't have anything to do with those.


> The above are reasons why I think that the headers cleanup, despite
> being something eventually necessary, it is pointless to do before
> fully specifying the boundaries between modules. Without that, someone
> will come and undo your work. Once the boundaries and dependencies are
> defined, then moving things around and cleaning up the headers
> dependencies is a fairly mechanic task that people will be "forced" to
> do whenever they want to use a function that is currently misplaced.

This is how things would be done in an environment with strong
leadership and a common design plan. But this is not how I would
describe the GCC community. You wouldn't be able to force anyone to do
anything, and you have to move things around before you can enforce a
boundary. This is what I have tried with the RTL headers (and note:
the 3 places that violate this have not received any attention to
finish the job).

Ciao!
Steven