This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap
- From: "joel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Jan 2005 14:17:58 -0000
- Subject: [Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap
- References: <20050110151452.19364.joel@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From joel at gcc dot gnu dot org 2005-01-20 14:17 -------
(In reply to comment #13)
> (In reply to comment #12)
> >
> > FYI Ralf tracked down one warning we got linking sparc apps to this:
> >
> > >>>I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC:
> > >>>
> > >>>#define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G %L"
>
> > The RTEMS LIB_SPEC includes a "-T linkcmds" which can only show up in the
> > final ld command once. The double inclusion of %L seems to appear and
> > disappear from release to release. 3.2.x did not have it.
> We had a local fix for 3.*.
>
> > I don't know which target needs this but if it is important to them,
> FWIW: IMO, all targets implcitly relying on the sparc/sparc.h's
> LINK_GCC_C_SEQUENCE_SPEC are broken.
> Grep'ing the sources reveals all major sparc-targets to override this
> LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much harm.
>
> Probably, "%G %L %G %L" also is SunOS/Solaris specific and actually does not
> belong into sparc.h. Also, I fail to understand how "LINK_GCC_C_SEQUENCE_SPEC"
> can be target-cpu specific. It is target-os specific.
>
> > we can override it in rtemself.h.
> I don't really like this. IMO, the sparc backend suffers from its SunOS/Solaris
> history and should be cleaned up.
Ralf pointed out in a private email that this definition in sparc.h is
inconsistent with that used by other targets and the generic config/rtems.h
works fine on all other *-rtems* targets. He is really right. The sparc
is inconsistent and if Solaris really needs this, they should override the
normal GCC value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19364