On Thu, Nov 13, 2014 at 01:08:44PM +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 12:17 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Thu, Nov 13, 2014 at 12:08:01PM +0100, Richard Biener wrote:
> >> Btw, I have nothing against changing TRANSLATION_UNIT_LANGUAGE
> >> to DW_LANG_* directly - we only use it for choosing the language
> >> of the dwarf unit. This would of course mean to change its initialization
> >> from
> >>
> >> TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name;
> >>
> >> to sth like
> >>
> >> TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.dw_lang;
> >>
> >> which means adding a langhook (thus more similar to your original
> >> patch).
> >
> > But that would mean having to include dwarf2 headers in every FE.
>
> Don't see what would be bad about this, but well...
I think strings are better than DWARF constants for middle-end thing,
say if DWARF doesn't make a difference between some language variants but
something different in the middle-end wants, or updating all the backends to
test when C++17 is released and DWARF assigns a language code for it
would be also weird.
If you want an integer instead of strings, it better should be some enum
with major and minor parts in it, so that one can easily test if it is
a C++ family, C family, C/C++ family, Fortran family etc. Still, that would
make things hard for third party frontends, which wouldn't know what values
to use if they don't have a language code in DWARF.
Jakub
