[RFC PATCH] Emit DW_LANG_Fortran{03,08}

[RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Jakub Jelinek]

Hi!

DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
accepted into DWARF5.  This patch changes GCC to handle those similarly to
how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.

As it will take some time for consumers to catch up, I'm enabling that
only if -gdwarf-5 is used for now.

2015-01-27  Jakub Jelinek  <jakub@redhat.com>

	* dwarf2.h (enum dwarf_source_language): Add DW_LANG_Fortran03
	and DW_LANG_Fortran08.
	* dwarf2out.c (is_fortran): Also return true for DW_LANG_Fortran03
	or DW_LANG_Fortran08.
	(lower_bound_default): Return 1 for DW_LANG_Fortran03 or
	DW_LANG_Fortran08.
	(gen_compile_unit_die): Handle "GNU Fortran2003" and
	"GNU Fortran2008" language strings.
	* dbxout.c (get_lang_number): Use lang_GNU_Fortran.
	* langhooks.h (lang_GNU_Fortran): New prototype.
	* langhooks.c (lang_GNU_Fortran): New function.
fortran/
	* options.c: Include langhooks.h.
	(gfc_post_options): Change lang_hooks.name based on
	selected -std= mode.

--- include/dwarf2.h.jj	2014-11-26 20:35:01.000000000 +0100
+++ include/dwarf2.h	2015-01-27 17:55:18.086122137 +0100
@@ -312,6 +312,8 @@ enum dwarf_source_language
     DW_LANG_C_plus_plus_11 = 0x001a, /* dwarf5.20141029.pdf DRAFT */
     DW_LANG_C11 = 0x001d,
     DW_LANG_C_plus_plus_14 = 0x0021,
+    DW_LANG_Fortran03 = 0x0022,
+    DW_LANG_Fortran08 = 0x0023,
 
     DW_LANG_lo_user = 0x8000,	/* Implementation-defined range start.  */
     DW_LANG_hi_user = 0xffff,	/* Implementation-defined range start.  */
--- gcc/dwarf2out.c.jj	2015-01-27 17:54:13.000000000 +0100
+++ gcc/dwarf2out.c	2015-01-27 19:03:30.632411565 +0100
@@ -4736,7 +4736,9 @@ is_fortran (void)
 
   return (lang == DW_LANG_Fortran77
 	  || lang == DW_LANG_Fortran90
-	  || lang == DW_LANG_Fortran95);
+	  || lang == DW_LANG_Fortran95
+	  || lang == DW_LANG_Fortran03
+	  || lang == DW_LANG_Fortran08);
 }
 
 /* Return TRUE if the language is Ada.  */
@@ -16720,6 +16722,8 @@ lower_bound_default (void)
     case DW_LANG_Fortran77:
     case DW_LANG_Fortran90:
     case DW_LANG_Fortran95:
+    case DW_LANG_Fortran03:
+    case DW_LANG_Fortran08:
       return 1;
     case DW_LANG_UPC:
     case DW_LANG_D:
@@ -19781,8 +19785,17 @@ gen_compile_unit_die (const char *filena
     {
       if (strcmp (language_string, "GNU Ada") == 0)
 	language = DW_LANG_Ada95;
-      else if (strcmp (language_string, "GNU Fortran") == 0)
-	language = DW_LANG_Fortran95;
+      else if (strncmp (language_string, "GNU Fortran", 11) == 0)
+	{
+	  language = DW_LANG_Fortran95;
+	  if (dwarf_version >= 5 /* || !dwarf_strict */)
+	    {
+	      if (strcmp (language_string, "GNU Fortran2003") == 0)
+		language = DW_LANG_Fortran03;
+	      else if (strcmp (language_string, "GNU Fortran2008") == 0)
+		language = DW_LANG_Fortran08;
+	    }
+	}
       else if (strcmp (language_string, "GNU Java") == 0)
 	language = DW_LANG_Java;
       else if (strcmp (language_string, "GNU Objective-C") == 0)
@@ -19796,7 +19809,7 @@ gen_compile_unit_die (const char *filena
 	}
     }
   /* Use a degraded Fortran setting in strict DWARF2 so is_fortran works.  */
-  else if (strcmp (language_string, "GNU Fortran") == 0)
+  else if (strncmp (language_string, "GNU Fortran", 11) == 0)
     language = DW_LANG_Fortran90;
 
   add_AT_unsigned (die, DW_AT_language, language);
@@ -19806,6 +19819,8 @@ gen_compile_unit_die (const char *filena
     case DW_LANG_Fortran77:
     case DW_LANG_Fortran90:
     case DW_LANG_Fortran95:
+    case DW_LANG_Fortran03:
+    case DW_LANG_Fortran08:
       /* Fortran has case insensitive identifiers and the front-end
 	 lowercases everything.  */
       add_AT_unsigned (die, DW_AT_identifier_case, DW_ID_down_case);
--- gcc/dbxout.c.jj	2015-01-15 20:25:30.000000000 +0100
+++ gcc/dbxout.c	2015-01-27 18:58:58.286033152 +0100
@@ -967,7 +967,7 @@ get_lang_number (void)
     return N_SO_CC;
   else if (strcmp (language_string, "GNU F77") == 0)
     return N_SO_FORTRAN;
-  else if (strcmp (language_string, "GNU Fortran") == 0)
+  else if (lang_GNU_Fortran ())
     return N_SO_FORTRAN90; /* CHECKME */
   else if (strcmp (language_string, "GNU Pascal") == 0)
     return N_SO_PASCAL;
--- gcc/langhooks.c.jj	2015-01-09 21:59:54.000000000 +0100
+++ gcc/langhooks.c	2015-01-27 18:58:37.375387995 +0100
@@ -731,3 +731,11 @@ lang_GNU_CXX (void)
 {
   return strncmp (lang_hooks.name, "GNU C++", 7) == 0;
 }
+
+/* Returns true if the current lang_hooks represents the GNU Fortran frontend.  */
+
+bool
+lang_GNU_Fortran (void)
+{
+  return strncmp (lang_hooks.name, "GNU Fortran", 11) == 0;
+}
--- gcc/langhooks.h.jj	2015-01-05 13:07:13.000000000 +0100
+++ gcc/langhooks.h	2015-01-27 18:57:51.139172602 +0100
@@ -509,5 +509,6 @@ extern tree add_builtin_type (const char
 
 extern bool lang_GNU_C (void);
 extern bool lang_GNU_CXX (void);
+extern bool lang_GNU_Fortran (void);
  
 #endif /* GCC_LANG_HOOKS_H */
--- gcc/fortran/options.c.jj	2015-01-12 21:29:11.000000000 +0100
+++ gcc/fortran/options.c	2015-01-27 19:07:33.729285229 +0100
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
 #include "cpp.h"
 #include "diagnostic.h"	/* For global_dc.  */
 #include "tm.h"
+#include "langhooks.h"
 
 gfc_option_t gfc_option;
 
@@ -398,6 +399,11 @@ gfc_post_options (const char **pfilename
 
   gfc_cpp_post_options ();
 
+  if (gfc_option.allow_std & GFC_STD_F2008)
+    lang_hooks.name = "GNU Fortran2008";
+  else if (gfc_option.allow_std & GFC_STD_F2003)
+    lang_hooks.name = "GNU Fortran2003";
+
   return gfc_cpp_preprocess_only ();
 }
 

	Jakub

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[David Malcolm]

On Tue, 2015-01-27 at 19:19 +0100, Jakub Jelinek wrote:
> Hi!
> 
> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5.  This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
> 
> As it will take some time for consumers to catch up, I'm enabling that
> only if -gdwarf-5 is used for now.
> 
> 2015-01-27  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* dwarf2.h (enum dwarf_source_language): Add DW_LANG_Fortran03
> 	and DW_LANG_Fortran08.
> 	* dwarf2out.c (is_fortran): Also return true for DW_LANG_Fortran03
> 	or DW_LANG_Fortran08.
> 	(lower_bound_default): Return 1 for DW_LANG_Fortran03 or
> 	DW_LANG_Fortran08.
> 	(gen_compile_unit_die): Handle "GNU Fortran2003" and
> 	"GNU Fortran2008" language strings.
> 	* dbxout.c (get_lang_number): Use lang_GNU_Fortran.
> 	* langhooks.h (lang_GNU_Fortran): New prototype.
> 	* langhooks.c (lang_GNU_Fortran): New function.
> fortran/
> 	* options.c: Include langhooks.h.
> 	(gfc_post_options): Change lang_hooks.name based on
> 	selected -std= mode.

(...snip...)

> --- gcc/fortran/options.c.jj	2015-01-12 21:29:11.000000000 +0100
> +++ gcc/fortran/options.c	2015-01-27 19:07:33.729285229 +0100
> @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
>  #include "cpp.h"
>  #include "diagnostic.h"	/* For global_dc.  */
>  #include "tm.h"
> +#include "langhooks.h"
>  
>  gfc_option_t gfc_option;
>  
> @@ -398,6 +399,11 @@ gfc_post_options (const char **pfilename
>  
>    gfc_cpp_post_options ();
>  
> +  if (gfc_option.allow_std & GFC_STD_F2008)
> +    lang_hooks.name = "GNU Fortran2008";
> +  else if (gfc_option.allow_std & GFC_STD_F2003)
> +    lang_hooks.name = "GNU Fortran2003";
> +

Did you test this on rs6000?

In particular, rs6000_output_function_epilogue has a:
      else if (! strcmp (language_string, "GNU F77")
	       || ! strcmp (language_string, "GNU Fortran"))
	i = 1;

Does that conditional need updating to track the langhooks.name change
(maybe to use your new lang_GNU_Fortran function?)

Dave

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Jakub Jelinek]

On Tue, Jan 27, 2015 at 01:52:12PM -0500, David Malcolm wrote:
> > @@ -398,6 +399,11 @@ gfc_post_options (const char **pfilename
> >  
> >    gfc_cpp_post_options ();
> >  
> > +  if (gfc_option.allow_std & GFC_STD_F2008)
> > +    lang_hooks.name = "GNU Fortran2008";
> > +  else if (gfc_option.allow_std & GFC_STD_F2003)
> > +    lang_hooks.name = "GNU Fortran2003";
> > +
> 
> Did you test this on rs6000?
> 
> In particular, rs6000_output_function_epilogue has a:
>       else if (! strcmp (language_string, "GNU F77")
> 	       || ! strcmp (language_string, "GNU Fortran"))
> 	i = 1;

You're right, missed that.  Consider that changed to lang_GNU_Fortran ().

	Jakub

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Tobias Burnus]

Jakub Jelinek wrote:
> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5.  This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.

For completeness: gfortran currently produces "GNU Fortran" and 
DW_LANG_Fortran95; GCC itself also handles ...Fortran77 and 
...Fortran90, but those are not produced with gfortran.

With the patch, it produces for -gdwarf-2/3/4 (4 is default) or 
"-gdwarf-5 -std=f95" the same as above. For -std=f2003 -gdwarf-5, it 
yields "GNU Fortran2003" and DW_LANG_Fortran2003. And for -gdwarf-5 and 
the rest of -std= (f2008, f2008ts, gnu, legacy), it produces "GNU 
Fortran2008" and DW_LANG_Fortran2008.

(In principle, they could have prepared for the future and added Fortran 
2015 as well.)


Regarding the change: it is fine with me. (However, I wonder how much 
will break, once the "|| !dwarf_strict" is enabled, knowing that 
compilers are often more frequently updated as debuggers, valgrind and 
similar programs. On the other, except of debuggers, most tools should 
care much about the DW_LANG.)

Tobias

PS: Talking about DWARF5, do you know when it will be available as 
public draft? I am especially looking forward to 
http://dwarfstd.org/ShowIssue.php?issue=121221.1 (Allow DW_AT_type with 
DW_TAG_string_type), which would be a low-hanging fruit in terms of 
implementation. Contrary to the array additions of 130313.5.

> As it will take some time for consumers to catch up, I'm enabling that
> only if -gdwarf-5 is used for now.
>
> 2015-01-27  Jakub Jelinek  <jakub@redhat.com>
>
> 	* dwarf2.h (enum dwarf_source_language): Add DW_LANG_Fortran03
> 	and DW_LANG_Fortran08.
> 	* dwarf2out.c (is_fortran): Also return true for DW_LANG_Fortran03
> 	or DW_LANG_Fortran08.
> 	(lower_bound_default): Return 1 for DW_LANG_Fortran03 or
> 	DW_LANG_Fortran08.
> 	(gen_compile_unit_die): Handle "GNU Fortran2003" and
> 	"GNU Fortran2008" language strings.
> 	* dbxout.c (get_lang_number): Use lang_GNU_Fortran.
> 	* langhooks.h (lang_GNU_Fortran): New prototype.
> 	* langhooks.c (lang_GNU_Fortran): New function.
> fortran/
> 	* options.c: Include langhooks.h.
> 	(gfc_post_options): Change lang_hooks.name based on
> 	selected -std= mode.

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Cary Coutant]

> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5.  This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
>
> As it will take some time for consumers to catch up, I'm enabling that
> only if -gdwarf-5 is used for now.

My concern with enabling -gdwarf-5 at this point is that all we're
really doing with it is enabling a subset of DWARF-5 features (as we
did with -gdwarf-4). We're still putting a version number of 2 in the
compilation unit header! But I guess even upgrading the CU header to
version 3 is something not all consumers are yet ready for. As long as
we selectively enable DWARF-5 features while still claiming to be
DWARF-2, I guess we're OK, but how will we decide to upgrade fully
beyond DWARF-2, and what option will we use for that?

The DWARF bits of this patch are OK with me.

-cary

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Cary Coutant]

> PS: Talking about DWARF5, do you know when it will be available as public
> draft? I am especially looking forward to
> http://dwarfstd.org/ShowIssue.php?issue=121221.1 (Allow DW_AT_type with
> DW_TAG_string_type), which would be a low-hanging fruit in terms of
> implementation. Contrary to the array additions of 130313.5.

It should be available for public review in 3-4 months. We need to do
a thorough review of the draft document, and tidy up a few loose ends,
but it's pretty much done.

I see no reason why you couldn't go ahead and implement what's in
121221.1 as an extension under a (!dwarf_strict) guard. Unless it
would really confuse old debuggers, I don't think you'd need to guard
it with -gdwarf-5.

-cary

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 01:58:32PM -0800, Cary Coutant wrote:
> > DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> > accepted into DWARF5.  This patch changes GCC to handle those similarly to
> > how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
> >
> > As it will take some time for consumers to catch up, I'm enabling that
> > only if -gdwarf-5 is used for now.
> 
> My concern with enabling -gdwarf-5 at this point is that all we're
> really doing with it is enabling a subset of DWARF-5 features (as we

Yeah, sure, at this point -gdwarf-5 is highly experimental, mainly meant
for coordination with consumers.  We'll incrementally add bits to it, until
DWARF5 will be released and we implement everything we'll want to from the
new standard.  Then we need to wait for consumers to catch up and only then
we can switch to -gdwarf-5 by default (perhaps GCC 7.0 timeframe?).

> did with -gdwarf-4). We're still putting a version number of 2 in the
> compilation unit header! But I guess even upgrading the CU header to

We are not.  On most targets we default to -gdwarf-4 and emit v. 4:
        .section        .debug_info,"",@progbits
.Ldebug_info0:
        .long   0xae    # Length of Compilation Unit Info
        .value  0x4     # DWARF version number
        .long   .Ldebug_abbrev0 # Offset Into Abbrev. Section
        .byte   0x8     # Pointer Size (in bytes)
        .uleb128 0x1    # (DIE (0xb) DW_TAG_compile_unit)
        .long   .LASF0  # DW_AT_producer: "GNU C11 5.0.0 20150204 (experimental) -g -O2"

It is only Darwin where because of broken toolchain we need to stick to
DWARF2, because otherwise the buggy tools crash on it (and I think VxWorks).

	Jakub

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Cary Coutant]

>> did with -gdwarf-4). We're still putting a version number of 2 in the
>> compilation unit header! But I guess even upgrading the CU header to
>
> We are not.  On most targets we default to -gdwarf-4 and emit v. 4:

Oops, sorry, you're right. I carelessly misread this:

  dw2_asm_output_data (2, ver, "DWARF version number");

and read the "2" as the version, not the size. As long as we're
capping the version number at 4 until we can actually write a proper
version 5 header, this is fine.

-cary

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Mark Wielaard]

On Wed, 2015-02-04 at 23:19 +0100, Jakub Jelinek wrote:
> On Wed, Feb 04, 2015@01:58:32PM -0800, Cary Coutant wrote:
> > > DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> > > accepted into DWARF5.  This patch changes GCC to handle those similarly to
> > > how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
> > >
> > > As it will take some time for consumers to catch up, I'm enabling that
> > > only if -gdwarf-5 is used for now.
> > 
> > My concern with enabling -gdwarf-5 at this point is that all we're
> > really doing with it is enabling a subset of DWARF-5 features (as we
> 
> Yeah, sure, at this point -gdwarf-5 is highly experimental, mainly meant
> for coordination with consumers.  We'll incrementally add bits to it, until
> DWARF5 will be released and we implement everything we'll want to from the
> new standard.  Then we need to wait for consumers to catch up and only then
> we can switch to -gdwarf-5 by default (perhaps GCC 7.0 timeframe?).

I documented the new GCC/GNU DWARF[5] extensions at:
https://fedorahosted.org/elfutils/wiki/DwarfExtensions
And submitted patches to support the new DW_LANG_Fortran(03,08} to
elfutils, valgrind, gdb, binutils and gold.

Cheers,

Mark