Re: Remove obsolete Tru64 UNIX V5.1B support

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

Tristan,

>> * As I've mentioned, I've ripped out the #pragma extern_prefix support:
>>  while VMS has something similar, it doesn't use the common code.
>
> in fact VMS use some of the already existing #pragma extern_prefix support.  You're removing too much code here !

oops, seems I was too eager to get rid of the cruft ;-)

> Commenting only the relevant part:
>
>> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
>> --- a/gcc/c-family/c-cppbuiltin.c
>> +++ b/gcc/c-family/c-cppbuiltin.c
>> @@ -1,6 +1,6 @@
>>  /* Define builtin-in macros for the C family front ends.
>> -   Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
>> -   Free Software Foundation, Inc.
>> +   Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
>> +   2011, 2012 Free Software Foundation, Inc.
>>  
>>  This file is part of GCC.
>>  
>> @@ -886,9 +886,6 @@ c_cpp_builtins (cpp_reader *pfile)
>>    /* Show the availability of some target pragmas.  */
>>    cpp_define (pfile, "__PRAGMA_REDEFINE_EXTNAME");
>>  
>> -  if (targetm.handle_pragma_extern_prefix)
>> -    cpp_define (pfile, "__PRAGMA_EXTERN_PREFIX");
>
> VMS doesn't reference this macro, so you could remove it.

It's not even used in the Tru64 UNIX system headers; I suppose it was
introduced for symmetry with __PRAGMA_REDEFINE_EXTNAME.

>> -/* GCC supports two #pragma directives for renaming the external
>> +/* GCC supports a #pragma directive for renaming the external
>>     symbol associated with a declaration (DECL_ASSEMBLER_NAME), for
>> -   compatibility with the Solaris and Tru64 system headers.  GCC also
>> +   compatibility with the Solaris system headers.  GCC also
>>     has its own notation for this, __asm__("name") annotations.
>>  
>>     Corner cases of these features and their interaction:
>>  
>> -   1) Both pragmas silently apply only to declarations with external
>> +   1) The pragma silently applies only to declarations with external
>>        linkage (that is, TREE_PUBLIC || DECL_EXTERNAL).  Asm labels
>>        do not have this restriction.
>>  
>> -   2) In C++, both #pragmas silently apply only to extern "C" declarations.
>> +   2) In C++, the #pragma silently applies only to extern "C" declarations.
>>        Asm labels do not have this restriction.
>>  
>> -   3) If any of the three ways of changing DECL_ASSEMBLER_NAME is
>> +   3) If any of the two ways of changing DECL_ASSEMBLER_NAME is
>>        applied to a decl whose DECL_ASSEMBLER_NAME is already set, and the
>>        new name is different, a warning issues and the name does not change.
>>  
>>     4) The "source name" for #pragma redefine_extname is the DECL_NAME,
>> -      *not* the DECL_ASSEMBLER_NAME.
>> -
>> -   5) If #pragma extern_prefix is in effect and a declaration occurs
>> -      with an __asm__ name, the #pragma extern_prefix is silently
>> -      ignored for that declaration.
>> -
>> -   6) If #pragma extern_prefix and #pragma redefine_extname apply to
>> -      the same declaration, whichever triggered first wins, and a warning
>> -      is issued.  (We would like to have #pragma redefine_extname always
>> -      win, but it can appear either before or after the declaration, and
>> -      if it appears afterward, we have no way of knowing whether a modified
>> -      DECL_ASSEMBLER_NAME is due to #pragma extern_prefix.)  */
>> +      *not* the DECL_ASSEMBLER_NAME.  */
>
> I think the comments would still apply.

Ok.  I had assumed that the vms handling of #pragma extern_prefix is
completely independent of the one in c-pragma.c.

>> -/* #pragma extern_prefix "prefix" */
>> -static void
>> -handle_pragma_extern_prefix (cpp_reader * ARG_UNUSED (dummy))
>> -{
>> -  tree prefix, x;
>> -  enum cpp_ttype t;
>> -
>> -  if (pragma_lex (&prefix) != CPP_STRING)
>> -    GCC_BAD ("malformed #pragma extern_prefix, ignored");
>> -  t = pragma_lex (&x);
>> -  if (t != CPP_EOF)
>> -    warning (OPT_Wpragmas, "junk at end of %<#pragma extern_prefix%>");
>> -
>> -  if (targetm.handle_pragma_extern_prefix)
>> -    /* Note that the length includes the null terminator.  */
>> -    pragma_extern_prefix = (TREE_STRING_LENGTH (prefix) > 1 ? prefix : NULL);
>> -  else if (warn_unknown_pragmas > in_system_header)
>> -    warning (OPT_Wunknown_pragmas,
>> -	     "#pragma extern_prefix not supported on this target");
>> -}
>> -
>
> Currently, the #pragma __extern_prefix is handled by vms-c.c, which is slightly more powerful than the tru64 version.
> It would be easier to me if the above version were removed!

Yup, will do.

>>  /* Hook from the front ends to apply the results of one of the preceding
>>     pragmas that rename variables.  */
>>  
>> @@ -580,35 +545,12 @@ maybe_apply_renaming_pragma (tree decl, 
>>  	    return asmname;
>>  	  }
>>  
>> -	/* Otherwise we use what we've got; #pragma extern_prefix is
>> -	   silently ignored.  */
>> +	/* Otherwise we use what we've got.  */
>>  	return build_string (IDENTIFIER_LENGTH (newname),
>>  			     IDENTIFIER_POINTER (newname));
>>        }
>>  
>> -  /* If we've got an asmname, #pragma extern_prefix is silently ignored.  */
>> -  if (asmname)
>> -    return asmname;
>> -
>> -  /* If #pragma extern_prefix is in effect, apply it.  */
>> -  if (pragma_extern_prefix)
>> -    {
>> -      const char *prefix = TREE_STRING_POINTER (pragma_extern_prefix);
>> -      size_t plen = TREE_STRING_LENGTH (pragma_extern_prefix) - 1;
>> -
>> -      const char *id = IDENTIFIER_POINTER (DECL_NAME (decl));
>> -      size_t ilen = IDENTIFIER_LENGTH (DECL_NAME (decl));
>> -
>> -      char *newname = (char *) alloca (plen + ilen + 1);
>> -
>> -      memcpy (newname,        prefix, plen);
>> -      memcpy (newname + plen, id, ilen + 1);
>> -
>> -      return build_string (plen + ilen, newname);
>> -    }
>> -
>> -  /* Nada.  */
>> -  return 0;
>> +  return asmname;
>>  }
>
> So this code shouldn't be removed because vms-c.c set pragma_extern_prefix.

Ok, I'll keep it and add a comment referencing that use.

I'll rework the patch accordingly (also incorporating the other review
comments), most likely over the weekend.  I'll try an i386-solaris x
alpha-vms cross build to ensure cc1 at least builds.

> Thank you Rainer for all the Tru64 maintainership work!

Thanks, it has been an interesting journey :-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University