Re: Remove obsolete Tru64 UNIX V5.1B support
Rainer, this chunk: --- a/gcc/ada/sysdep.c +++ b/gcc/ada/sysdep.c @@ -252,27 +254,27 @@ __gnat_ttyname (int filedes) #endif ^L #if defined (linux) || defined (sun) || defined (sgi) \ - || (defined (__osf__) ! defined (__alpha_vxworks)) || defined (WINNT) \ + || ! defined (__alpha_vxworks) || defined (WINNT) \ || defined (__MACHTEN__) || defined (__hpux__) || defined (_AIX) \ || (defined (__svr4__) defined (i386)) || defined (__Lynx__) \ || defined (__CYGWIN__) || defined (__FreeBSD__) || defined (__OpenBSD__) \ || defined (__GLIBC__) || defined (__APPLE__) is not correct, '! defined (__alpha_vxworks)' should have been removed too. I will commit this fix (as obvious): ada/ 2012-03-13 Tristan Gingold ging...@adacore.com * sysdep.c: Adjust condition after removal of __osf__. Indent nested directives. diff --git a/gcc/ada/sysdep.c b/gcc/ada/sysdep.c index 0669c2f..37cb8d7 100644 --- a/gcc/ada/sysdep.c +++ b/gcc/ada/sysdep.c @@ -254,27 +254,27 @@ __gnat_ttyname (int filedes) #endif #if defined (linux) || defined (sun) || defined (sgi) \ - || ! defined (__alpha_vxworks) || defined (WINNT) \ + || defined (WINNT) \ || defined (__MACHTEN__) || defined (__hpux__) || defined (_AIX) \ || (defined (__svr4__) defined (i386)) || defined (__Lynx__) \ || defined (__CYGWIN__) || defined (__FreeBSD__) || defined (__OpenBSD__) \ || defined (__GLIBC__) || defined (__APPLE__) -#ifdef __MINGW32__ -#if OLD_MINGW -#include termios.h -#else -#include conio.h /* for getch(), kbhit() */ -#endif -#else -#include termios.h -#endif +# ifdef __MINGW32__ +# if OLD_MINGW +# include termios.h +# else +# include conio.h /* for getch(), kbhit() */ +# endif +# else +# include termios.h +# endif #else -#if defined (VMS) +# if defined (VMS) extern char *decc$ga_stdscr; static int initted = 0; -#endif +# endif #endif /* Implements the common processing for getc_immediate and
Re: Remove obsolete Tru64 UNIX V5.1B support
On 03/12/2012 05:06 PM, Rainer Orth wrote: I think the remaining changes are either obvious or covered by osf or testsuite maintainerships, so I've applied the patch. Thanks. Rainer Thanks, but please remove all the spurious 'libstdc++v3' from the ChangeLog entry and make sure it's wrapped to 80 columns. Thanks, Paolo.
Re: Remove obsolete Tru64 UNIX V5.1B support
Paolo Carlini paolo.carl...@oracle.com writes: On 03/12/2012 05:06 PM, Rainer Orth wrote: I think the remaining changes are either obvious or covered by osf or testsuite maintainerships, so I've applied the patch. Thanks. Rainer Thanks, but please remove all the spurious 'libstdc++v3' from the ChangeLog entry and make sure it's wrapped to 80 columns. Oops, sorry, will do ASAP. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
David Daney david.da...@cavium.com writes: On 03/06/2012 05:14 AM, Rainer Orth wrote: Joseph S. Myersjos...@codesourcery.com writes: There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. I've never tried this. Given that the .class file lives below libjava/classpath and has to be synced with upstream Classpath anyway, I hope the Java maintainers will take care of that. This it documented (although perhaps badly) in install/configure.html You should use --enable-java-maintainer-mode, this will cause the build to use ecj and gjavah to regenerate all the generated files in the 'standard' manner. I tried that route, but failed: even with ecj1 and gjavah scripts in PATH, I get /var/gcc/gcc-4.8.0-20120309/11-gcc/./gcc/gcj -B/var/gcc/gcc-4.8.0-20120309/11-gcc/i386-pc-solaris2.11/amd64/libjava/ -B/var/gcc/gcc-4.8.0-20120309/11-gcc/i386-pc-solaris2.11/amd64/libjava/ -B/var/gcc/gcc-4.8.0-20120309/11-gcc/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -C -g -fsource=1.5 -ftarget=1.5 --bootclasspath='' --classpath=/vol/gcc/src/hg/trunk/solaris/libjava:/var/gcc/gcc-4.8.0-20120309/11-gcc/i386-pc-solaris2.11/amd64/libjava:/vol/gcc/src/hg/trunk/solaris/libjava/classpath:/vol/gcc/src/hg/trunk/solaris/libjava/classpath/external/w3c_dom:/vol/gcc/src/hg/trunk/solaris/libjava/classpath/external/sax:/vol/gcc/src/hg/trunk/solaris/libjava/classpath/external/relaxngDatatype:/vol/gcc/src/hg/trunk/solaris/libjava/classpath/external/jsr166:.:: -d /vol/gcc/src/hg/trunk/solaris/libjava/classpath/lib @classes no classpath specified make[6]: *** [compile-classes] Error 1 I gave up and checked in the File.class file produced with Sun javac. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
David Daney david.da...@cavium.com writes: I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. I've never tried this. Given that the .class file lives below libjava/classpath and has to be synced with upstream Classpath anyway, I hope the Java maintainers will take care of that. This it documented (although perhaps badly) in install/configure.html You should use --enable-java-maintainer-mode, this will cause the build to use ecj and gjavah to regenerate all the generated files in the 'standard' manner. Ok, I'll try it when incorporating review comments and testing the result. ecj-4.5.jar is still the right file to use? The contrib/download_ecj script mentioned in HACKING doesn't exist any longer. At least with the javac-built File.class I had no libjava testsuite failures. It probably results in a usable .class file, but is error prone and not very reproducible. No doubt about that: it took me several iterations to get the right invocation. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
On Mar 5, 2012, at 6:28 PM, Richard Henderson wrote: On 03/05/2012 09:14 AM, Rainer Orth wrote: * In the alpha backend, there are a couple of cases that might be osf-specific, but I cannot tell for certain: macro osf5.halpha.h TARGET_AS_CAN_SUBTRACT_LABELS 1 TARGET_GAS I cannot tell if !TARGET_GAS configurations exist, especially Alpha VMS. Also, in alpha.h there are some references to mips-tfile, which is gone with osf. If there are no non-gas configrations remaining, that stuff can go, too. Given that GAS supports VMS, I suspect that all targets are now GAS. I'll let the adacore folks answer that for certain however. Yes, that's my understanding too. TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128 Same here: any configurations with !TARGET_LONG_DOUBLE_128? I wouldn't think so; glibc before version 2.4, circa 1998? OpenVMS long double is 128 bits (also I was never personally tested it). Tristan. HAVE_STAMP_H1 In my understanding, this is purely a OSF thing and can go, but maybe other OSes on alpha mimiced OSF here? I've no idea what that actually is. I'll have a look at the patch in detail later r~
Re: Remove obsolete Tru64 UNIX V5.1B support
The gnattools and gcc/ada parts are OK, except for the comment removal in s-tassta.adb: this comment is still useful, and needs to be revisited at some point ratheer than removed silently as you did, to understand why we can't use a when E: others = construct. So either remove the s-tassta.adb hunk, or extend the comment, but removing it would be wrong. Arno
Re: Remove obsolete Tru64 UNIX V5.1B support
Rainer,
On Mar 5, 2012, at 6:14 PM, Rainer Orth wrote:
The Tru64 UNIX V5.1 port has been obsoleted in GCC 4.7, and it's now
time to remove it from mainline. The following patch does just that,
and should be mostly uncontroversial, like removing target-specific
fixincludes hacks, files, and testsuite support.
Then, there are target-specific features only used by this port (like
support for #pragma extern_prefix),
[…]
* 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 !
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.
-
/* Make the choice of the stack protector runtime visible to source code.
The macro names and values here were chosen for compatibility with an
earlier implementation, i.e. ProPolice. */
diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1,6 +1,6 @@
/* Handle #pragma, system V.4 style. Supports #pragma weak and #pragma pack.
Copyright (C) 1992, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
- 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+ 2006, 2007, 2008, 2009, 2010, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -369,37 +369,26 @@ handle_pragma_weak (cpp_reader * ARG_UNU
}
}
-/* 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.
typedef struct GTY(()) pending_redefinition_d {
tree oldname;
@@ -494,30 +483,6 @@ add_to_renaming_pragma_list (tree oldnam
p-newname = newname;
}
-/* The current prefix set by #pragma extern_prefix. */
-GTY(()) tree pragma_extern_prefix;
This variable is referenced by gcc/config/vms/vms-c.c, so it shouldn't be
removed.
-
-/* #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
Re: Remove obsolete Tru64 UNIX V5.1B support
Jonathan Wakely jwakely@gmail.com writes: On 5 March 2012 17:01, Rainer Orth wrote: * The libstdc++ testsuite is messy since every thing pthread test includes the complete list of targets where it should be run, and the options required. I've long meant to clean this up, but this will have to wait until after osf and irix are gone from the tree. That would be fantastic if you do clean it up some time. This has been on my agenda for a long time. Hopefully I'll get around to it this time ;-) The libstdc++ parts of this patch are OK. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
Joseph S. Myers jos...@codesourcery.com writes: There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. I've never tried this. Given that the .class file lives below libjava/classpath and has to be synced with upstream Classpath anyway, I hope the Java maintainers will take care of that. At least with the javac-built File.class I had no libjava testsuite failures. * With the removal of #pragma extern_prefix support, gcc/po/gcc.pot needs to be regenerated. Since I'm not positive I have the right tools and trying found unrelated changes, I've omitted that change. There is no expectation that anyone changing diagnostics regenerates this file; it's regenerated as needed before submission to the Translation Project. Ok, thanks. gcc: * config.gcc (alpha*-dec-osf5.1*): Remove. I'd suggest removing the extra_passes mechanism in the followup since this was the only user of that mechanism in config.gcc. Yup, will do. * target.def (handle_pragma_extern_prefix): Remove. Removed hooks should be poisoned in system.h. Ok. Greping for current occurences obviously missed this :-) Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
Bruce Korb bk...@gnu.org writes: On Mon, Mar 5, 2012 at 3:13 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 5 Mar 2012, Rainer Orth wrote: * There are some fixincludes hacks that from their names seem to be osf-specific, but are not restricted to alpha*-dec-osf*. Bruce, what's the best way to handle those? Disable them e.g. with a mach clause like unused-alpha*-dec-osf* and see if anything else breaks? I'd favour just removing any fixes that it seems likely are no longer useful. I favor it for now, but I think being more aggressive is a good thing. #define REGEX_COUNT 265 #define MACH_LIST_SIZE_LIMIT 181 #define FIX_COUNT223 I believe that headers have likely improved in the last decade. I do doubt that there are twice as many actively needed patches to headers required now versus then. Certainly true, especially with old targets like Tru64 UNIX and IRIX on the way out. My current list of fixes that are likely osf-specific, but isn't tagged as such, includes alpha___assert alpha_assert alpha_if_semicolon (osf4) alpha_parens cxx_unready osf_namespace_a, tests/base/reg_types.h osf_namespace_c, tests/base/regex.h sysv68_string (ffs) ultrix_const ultrix_const2 Some of them appear to be more generic, so it's probably safer to keep them until your proposed mechanism for collecting usage data is in place. Either way, they don't need to go in the first round of the removal patch. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
Arnaud Charlet char...@adacore.com writes: The gnattools and gcc/ada parts are OK, except for the comment removal in s-tassta.adb: this comment is still useful, and needs to be revisited at some point ratheer than removed silently as you did, to understand why we can't use a when E: others = construct. So either remove the s-tassta.adb hunk, or extend the comment, but removing it would be wrong. Ok, I'll just keep it. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
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;
-
-
Re: Remove obsolete Tru64 UNIX V5.1B support
On 03/06/2012 05:14 AM, Rainer Orth wrote: Joseph S. Myersjos...@codesourcery.com writes: There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. I've never tried this. Given that the .class file lives below libjava/classpath and has to be synced with upstream Classpath anyway, I hope the Java maintainers will take care of that. This it documented (although perhaps badly) in install/configure.html You should use --enable-java-maintainer-mode, this will cause the build to use ecj and gjavah to regenerate all the generated files in the 'standard' manner. At least with the javac-built File.class I had no libjava testsuite failures. It probably results in a usable .class file, but is error prone and not very reproducible. David Daney
Re: Remove obsolete Tru64 UNIX V5.1B support
On 03/05/2012 05:01 PM, Rainer Orth wrote: * In libjava, there were several workarounds for OSF bugs/quirks. I've ripped them out as explained above. There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. OK. Andrew.
Re: Remove obsolete Tru64 UNIX V5.1B support
On 03/05/2012 09:14 AM, Rainer Orth wrote: * In the alpha backend, there are a couple of cases that might be osf-specific, but I cannot tell for certain: macro osf5.halpha.h TARGET_AS_CAN_SUBTRACT_LABELS 1 TARGET_GAS I cannot tell if !TARGET_GAS configurations exist, especially Alpha VMS. Also, in alpha.h there are some references to mips-tfile, which is gone with osf. If there are no non-gas configrations remaining, that stuff can go, too. Given that GAS supports VMS, I suspect that all targets are now GAS. I'll let the adacore folks answer that for certain howeverl. TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128 Same here: any configurations with !TARGET_LONG_DOUBLE_128? I wouldn't think so; glibc before version 2.4, circa 1998? HAVE_STAMP_H1 In my understanding, this is purely a OSF thing and can go, but maybe other OSes on alpha mimiced OSF here? I've no idea what that actually is. I'll have a look at the patch in detail later r~
Re: Remove obsolete Tru64 UNIX V5.1B support
CF: fixincludes: * inclhack.def (alpha___extern_prefix): Remove. (alpha___extern_prefix_standards): Remove. (alpha___extern_prefix_sys_stat): Remove. (alpha_bad_lval): Remove. (alpha_pthread): Remove. (alpha_pthread_gcc): Remove. (alpha_pthread_init): Remove. * fixincl.x: Regenerate. * tests/base/pthread.h [ALPHA_PTHREAD_CHECK]: Remove. [ALPHA_PTHREAD_GCC_CHECK]: Remove. [ALPHA_PTHREAD_INIT_CHECK]: Remove. * tests/base/standards.h: Remove. * tests/base/sys/stat.h [ALPHA___EXTERN_PREFIX_SYS_STAT_CHECK]: Remove. * tests/base/testing.h [ALPHA___EXTERN_PREFIX_CHECK]: Remove. [ALPHA_BAD_LVAL_CHECK]: Remove. Seems reasonable to me...
Re: Remove obsolete Tru64 UNIX V5.1B support
On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote: TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128 Same here: any configurations with !TARGET_LONG_DOUBLE_128? I wouldn't think so; glibc before version 2.4, circa 1998? No idea about MIPS, but for ppc/ppc64/s390/s390x/sparc32 the selectable size long double support is from 2006. Jakub
Re: Remove obsolete Tru64 UNIX V5.1B support
On 3/5/2012 9:28 AM, Richard Henderson wrote: On 03/05/2012 09:14 AM, Rainer Orth wrote: * In the alpha backend, there are a couple of cases that might be osf-specific, but I cannot tell for certain: macro osf5.halpha.h TARGET_AS_CAN_SUBTRACT_LABELS 1 TARGET_GAS I cannot tell if !TARGET_GAS configurations exist, especially Alpha VMS. Also, in alpha.h there are some references to mips-tfile, which is gone with osf. If there are no non-gas configrations remaining, that stuff can go, too. Given that GAS supports VMS, I suspect that all targets are now GAS. I'll let the adacore folks answer that for certain howeverl. All Alpha/VMS targets use GAS. --Doug
Re: Remove obsolete Tru64 UNIX V5.1B support
Jakub Jelinek ja...@redhat.com writes: On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote: TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128 Same here: any configurations with !TARGET_LONG_DOUBLE_128? I wouldn't think so; glibc before version 2.4, circa 1998? No idea about MIPS, but for ppc/ppc64/s390/s390x/sparc32 the selectable size long double support is from 2006. ... which leaves us with the BSDs. No idea about those. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
On 5 March 2012 17:01, Rainer Orth wrote: * The libstdc++ testsuite is messy since every thing pthread test includes the complete list of targets where it should be run, and the options required. I've long meant to clean this up, but this will have to wait until after osf and irix are gone from the tree. That would be fantastic if you do clean it up some time. The libstdc++ parts of this patch are OK.
Re: Remove obsolete Tru64 UNIX V5.1B support
Richard Henderson r...@redhat.com writes: HAVE_STAMP_H1 In my understanding, this is purely a OSF thing and can go, but maybe other OSes on alpha mimiced OSF here? I've no idea what that actually is. It's used to emit .verstamp directives for ECOFF objects. I've just checked again: all of Linux, *BSD, and VMS use ELF, so HAVE_STAMP_H support (and any code for !OBJECT_FORMAT_ELF) can go. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Remove obsolete Tru64 UNIX V5.1B support
On Mon, 5 Mar 2012, Rainer Orth wrote: * There are some fixincludes hacks that from their names seem to be osf-specific, but are not restricted to alpha*-dec-osf*. Bruce, what's the best way to handle those? Disable them e.g. with a mach clause like unused-alpha*-dec-osf* and see if anything else breaks? I'd favour just removing any fixes that it seems likely are no longer useful. There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. * With the removal of #pragma extern_prefix support, gcc/po/gcc.pot needs to be regenerated. Since I'm not positive I have the right tools and trying found unrelated changes, I've omitted that change. There is no expectation that anyone changing diagnostics regenerates this file; it's regenerated as needed before submission to the Translation Project. gcc/c-family: * c-cppbuiltin.c (c_cpp_builtins): Remove #pragma extern_prefix handling. * c-pragma.c: Remove #pragma extern_prefix documentation. (pragma_extern_prefix): Remove. (handle_pragma_extern_prefix): Remove. (maybe_apply_renaming_pragma): Remove #pragma extern_prefix handling. (init_pragma): Don't register extern_prefix. * c-pragma.h (pragma_extern_prefix): Remove. These changes are OK. gcc/po: * EXCLUDES (mips-tdump.c, mips-tfile.c): Remove. This is OK. gcc: * config.gcc (alpha*-dec-osf5.1*): Remove. I'd suggest removing the extra_passes mechanism in the followup since this was the only user of that mechanism in config.gcc. * target.def (handle_pragma_extern_prefix): Remove. Removed hooks should be poisoned in system.h. -- Joseph S. Myers jos...@codesourcery.com
Re: Remove obsolete Tru64 UNIX V5.1B support
On Mon, Mar 5, 2012 at 3:13 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 5 Mar 2012, Rainer Orth wrote: * There are some fixincludes hacks that from their names seem to be osf-specific, but are not restricted to alpha*-dec-osf*. Bruce, what's the best way to handle those? Disable them e.g. with a mach clause like unused-alpha*-dec-osf* and see if anything else breaks? I'd favour just removing any fixes that it seems likely are no longer useful. I favor it for now, but I think being more aggressive is a good thing. #define REGEX_COUNT 265 #define MACH_LIST_SIZE_LIMIT 181 #define FIX_COUNT223 I believe that headers have likely improved in the last decade. I do doubt that there are twice as many actively needed patches to headers required now versus then.
