| Message ID | Pine.LNX.4.64.1012071425210.11834@digraph.polyomino.org.uk |
|---|---|
| State | New |
| Headers | show |
Ping. This patch <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00566.html> is pending review. Note that this target has no maintainer so it's not going to be reviewed by a target maintainer.
On Tue, 14 Dec 2010, Joseph S. Myers wrote: > Ping. This patch > <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00566.html> is pending > review. Note that this target has no maintainer so it's not going to > be reviewed by a target maintainer. Then, really, I think it should be okay for you to go ahead and we should consider deprecating the port with GCC 4.6. I also did not find any testresults for the months of October and November. Gerald
On Tue, Dec 14, 2010 at 1:30 AM, Joseph S. Myers <joseph@codesourcery.com> wrote: > Ping. This patch > <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00566.html> is pending > review. Note that this target has no maintainer so it's not going to be > reviewed by a target maintainer. Consider all of your cleanup patches to targets without a maintainer pre-approved. I btw agree with Gerald, those ports should be deprecated. Thanks, Richard. > -- > Joseph S. Myers > joseph@codesourcery.com >
On Wed, 15 Dec 2010, Richard Guenther wrote: > On Tue, Dec 14, 2010 at 1:30 AM, Joseph S. Myers > <joseph@codesourcery.com> wrote: > > Ping. This patch > > <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00566.html> is pending > > review. Note that this target has no maintainer so it's not going to be > > reviewed by a target maintainer. > > Consider all of your cleanup patches to targets without a maintainer > pre-approved. That's arc, lm32 and score (I'm not sure why the last two were accepted without maintainers, lm32 in particular is recent). > I btw agree with Gerald, those ports should be deprecated. Possible deprecations to consider for 4.6 if someone wants to work out details of target triplets and implement the deprecations: * arc. * Interix target OS (doesn't build at present). * Generic COFF/PE targets (arm-*-pe* other than arm*-wince-pe*, mcore-*-pe*) (i[34567]86-*-pe isn't actually such a target, it's an alias for the Cygwin configuration, but as previously discussed "canonical" aliases - ones left unchanged by config.sub - have their own problems, so maybe it should be deprecated as well). * a.out BSD configurations where there are corresponding ELF configurations as well. * m68k-*-uclinuxoldabi*. * If GNU as is made to work for alpha*-dec-osf5.1*, then I'd like to eliminate mips-tdump, mips-tfile and the extra_passes and extra_programs mechanisms in config.gcc. (Actually, only extra_passes is used at all at present, not extra_programs.)
"Joseph S. Myers" <joseph@codesourcery.com> writes: > * If GNU as is made to work for alpha*-dec-osf5.1*, then I'd like to > eliminate mips-tdump, mips-tfile and the extra_passes and extra_programs > mechanisms in config.gcc. (Actually, only extra_passes is used at all at > present, not extra_programs.) I'd love to do that, but although gas is supposed to have been working on Tru64 UNIX at some point, it fails for the simplest programs right now, cf. binutils PRs gas/11518 Support explicit relocations for Alpha ECOFF gas/11517 Fatal error assembling ldgp for Alpha ECOFF gas/11516 Fatal error assembling jsr for Alpha ECOFF I still haven't gotten around to investigate what's wrong there. I agree that mips-tfile is a mess, and only works natively. Rainer
diff -rupN --exclude=.svn gcc-mainline-3/gcc/config/arc/arc.h gcc-mainline/gcc/config/arc/arc.h --- gcc-mainline-3/gcc/config/arc/arc.h 2010-12-02 09:39:19.000000000 -0800 +++ gcc-mainline/gcc/config/arc/arc.h 2010-12-07 06:20:01.000000000 -0800 @@ -29,6 +29,7 @@ along with GCC; see the file COPYING3. #undef ASM_SPEC #undef LINK_SPEC +#undef LIB_SPEC #undef STARTFILE_SPEC #undef ENDFILE_SPEC #undef SIZE_TYPE @@ -66,6 +67,8 @@ along with GCC; see the file COPYING3. #define LINK_SPEC "%{v} %{EB} %{EL}" +#define LIB_SPEC "-lc" + #define STARTFILE_SPEC "%{!shared:crt0.o%s} crtinit.o%s" #define ENDFILE_SPEC "crtfini.o%s" diff -rupN --exclude=.svn gcc-mainline-3/gcc/config.gcc gcc-mainline/gcc/config.gcc --- gcc-mainline-3/gcc/config.gcc 2010-12-06 03:31:49.000000000 -0800 +++ gcc-mainline/gcc/config.gcc 2010-12-07 06:09:45.000000000 -0800 @@ -761,7 +761,7 @@ alpha*-dec-*vms*) extra_options="${extra_options} vms/vms.opt" ;; arc-*-elf*) - tm_file="dbxelf.h elfos.h svr4.h newlib-stdint.h ${tm_file}" + tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}" extra_parts="crtinit.o crtfini.o" ;; arm-wrs-vxworks)
This patch starts the series of patches removing svr4.h from the headers used by particular targets in GCC. All of these patches are relative to a tree with the first three patches for particular macros <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00362.html> <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00460.html> <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00518.html> applied. This patch stops arc-*-elf* from using svr4.h. The only macro used from that header was LIB_SPEC. The svr4.h definition #undef LIB_SPEC #define LIB_SPEC "%{!shared:%{!symbolic:-lc}}" seems inappropriate for generic ELF targets (in general you do want to link with -lc even when building a shared library) so I used the simpler "-lc" for LIB_SPEC and will do so as applicable for other targets currently inheriting this macro setting from svr4.h. Tested building cc1 and xgcc for a cross to arc-elf. OK to commit? (NB there is no listed maintainer for this target at present.) 2010-12-07 Joseph Myers <joseph@codesourcery.com> * config/arc/arc.h (LIB_SPEC): Define. * config.gcc (arc-*-elf*): Don't use svr4.h.