Semantics of -fdump-ast?

[Nathan Sidwell]

Diego Novillo wrote:

> The questions I have are:
> 
> - GCC has traditionally called this IL `tree', but now we also
>   have the name `ast'.  I'm not quite sure which one to use.
> 
>   I went with tradition, but we're starting to have some naming
>   inconsistencies (my switches are named fdump-tree instead of
>   fdump-ast).
> 
>   I'm not arguing for one name or the other.  Both are equally
>   meaningful to me.  But we should probably use a single naming
>   scheme or just use the names interchangeably.
Yes, lets get this consistent. I think Mr Pedant in my head went
into overdrive calling it ast. I've no strong opinion about what
we name it. Perhaps 'tree' is the best word we have. 'tree' is by
far the most popular in the documentation - we should go there.

I know! Let's have several candidate options, have a preliminary
vote among maintainers to eliminate all but two, and then have the
rest of the list vote on the remaining two[*]
 
> - The only dump switch that currently has a bitmask associated is
>   the SSA one.  I didn't want to add a third bitmask to the
>   existing bitmasks because it would be meaningless for the
>   existing fdump-ast-XXX switches and vice-versa.
Not that I've a strong opinion but my take on this is that, as
there's a large number of spare bits, let's not overload their
meaning - unions bad, structs good.

>   The documentation suggests that these bits are interpreted by
>   all the -fdump switches.  This is not the case with fdump-tree.
>   The fdump machinery makes it easy to have different bitmasks
>   for different switches.  It's the documentation that suggests
>   otherwise.
yes the docs should be cleaned up. Ok, as I made the mess I'll clean
it up.

nathan

[*]those in .uk will notice a thinly veiled parody of an ongoing
news event.

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org