On Wed, 8 Jan 2025, Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote: > > > So, this patch is an alternative to the > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html > > > patch, which had the major problem that it required changing all the > > > DWARF consumers to be able to debug C17 or later or C++17 or later > > > sources. > > > > Do you plan to salvage the non-obsoleted parts of the above change? > > No. The switches on DW_AT_language value are a GCC internal thing, > if we never generate say the post-DWARF5 DW_LANG_C_plus_plus_23, > we don't need to handle it in the switch. > > Though, Ada and Fortran could have a similar change to the C/C++ > one, i.e. also add DW_AT_language_{name,version} for newer Ada and Fortran > versions, say DW_LNAME_Ada and then dunno whether 2005, 2012 and 2022 > or 2007, 2012 and 2023, in https://dwarfstd.org/languages-v6.html > the versioning scheme for Ada (as well as Fortran) is YYYY. > Similarly DW_LNAME_Fortran 2018 and 2023. > > The reason I haven't done it myself is that the Ada FE doesn't tell > Ada version at all - there is just "GNU Ada" and dwarf2out.cc right now > implies it is Ada 95 for DWARF3 and Ada 83 otherwise. > And in the Fortran case, while the FE provides a version, it only > does so for Fortran 2003 and 2008 (and just "GNU Fortran" implies Fortran 90 > in dwarf2out). So, no marking of Fortran 2018 or Fortran 2023.
Btw, with DWARF only we now have the opportunity to add langhooks that directly create DWARF DIEs or attributes (for early debug). Richard.
