This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran lang changes
> Yes, AIX relies on language_string -- AIX does not use Dwarf
> debugging.
Even outside of Dwarf, I don't see where that plays a role.
> In addition to DW_AT_language, I believe that the string itself
> appears in executables and other applications may depend on the string.
No, it doesn't appear, I tried. (With dwarf and with stabs.)
I found the culprit, however:
config/rs6000/rs6000.c: || ! strcmp (language_string, "GNU F95"))
I missed that when I prepared the original patch, I apologize. Would
you test the patch below and tell me if it fixes the issue or if more
is needed?
Index: config/rs6000/rs6000.c
===================================================================
--- config/rs6000/rs6000.c (revision 132845)
+++ config/rs6000/rs6000.c (working copy)
@@ -16892,7 +16892,7 @@ rs6000_output_function_epilogue (FILE *f
if (! strcmp (language_string, "GNU C"))
i = 0;
else if (! strcmp (language_string, "GNU F77")
- || ! strcmp (language_string, "GNU F95"))
+ || ! strcmp (language_string, "GNU Fortran"))
i = 1;
else if (! strcmp (language_string, "GNU Pascal"))
i = 2;
On a related note, I'm amazed by the large number of string
comparisons to the language name, for something that is inherently a
finite set of values (the number of front-ends we support). There is
some wonderful code out there, like config/rs6000/rs6000.c:
/* Skip section anchors for Objective C and Objective C++ until
front-ends fixed. */
if (!TARGET_MACHO && lang_hooks.name[4] != 'O')
flag_section_anchors = 1;
> A more informative email subject than "Misc driver, middle-end and
> doc fixes for Fortran" would have been helpful to get the attention of
> others possibly affected by the patch.
OK, I'll try to do better next time.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/