Confirmed, caused by:
2004-07-25  Daniel Jacobowitz  <dan@debian.org> 
        
        * config.gcc (i[34567]86-*-solaris2*, sparc64-*-solaris2*)
        (sparc-*-solaris2*): Include sol2.o and sol2-protos.h.
        * config/sol2-c.c: Include "tm.h", "tm_p.h", "toplev.h",
        "cpplib.h", "c-pragma.h", "c-common.h".

sparc/sol2.h is included in the non solaris headers.

> The embedded SPARC targets have developed a dependency on a Solaris specific
> file.  This is a regression from the 3.3 and 3.4 series.

The embedded SPARC targets are too lazy. ;-)

(In reply to comment #2)
> > The embedded SPARC targets have developed a dependency on a Solaris specific
> > file.  This is a regression from the 3.3 and 3.4 series.
> 
> The embedded SPARC targets are too lazy. ;-)
> 

Any guesses/suggestions on what might fix it. :)

> Any guesses/suggestions on what might fix it. :)

For the specific bug, I guess Daniel is the right guy to ask.  For the general
problem, I think someone who is really interested in sparc-elf or sparc-rtems
should sit down for a couple of hours just after 4.1 has opened and untangle
this mess once for all.  Otherwise I might simply remove the references to
sol2.h from any non-Solaris SPARC-based targets; they are bugs after all...

(In reply to comment #4)
> > Any guesses/suggestions on what might fix it. :)
> 
> For the specific bug, I guess Daniel is the right guy to ask.  For the general
> problem, I think someone who is really interested in sparc-elf or sparc-rtems
> should sit down for a couple of hours just after 4.1 has opened and untangle
> this mess once for all.  Otherwise I might simply remove the references to
> sol2.h from any non-Solaris SPARC-based targets; they are bugs after all...

I tried to build sparc-linux also and it seems to suffer from the same thing.
Can anyone build that?  It might just be my procedures but I doubt it.

> I tried to build sparc-linux also and it seems to suffer from the same thing.
> Can anyone build that?  It might just be my procedures but I doubt it.

http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00086.html

sparc/sol2.h seems to be used just for sparc*-*-solaris* (correct)
and sparc*-*-{elf,rtems}* (incorrectly).  sparc*-*-linux* and
sparc*-*-{free,net,open}bsd* don't use sol2.h at all.

(In reply to comment #7)
> sparc/sol2.h seems to be used just for sparc*-*-solaris* (correct)
> and sparc*-*-{elf,rtems}* (incorrectly).  sparc*-*-linux* and
> sparc*-*-{free,net,open}bsd* don't use sol2.h at all.

Good hint.  That got me much further.  I now have this in config.gcc and it gets
up to assembling sol2-ci.asm (sparc/t-elf says this is the crti.o source file).
 Unfortunately, xgcc doesn't appear to know that ! is a comment character.  The
only ASM_COMMENT_START I see (sparc.h) looks OK.  What this target should be
using for the crti/crtn code?  Or what else could be wrong.  This feels closer.

sparc-*-rtems*)
        tm_file="${tm_file} elfos.h svr4.h sparc/sysv4.h netbsd.h netbsd-elf.h
sparc/netbsd-elf.h sparc/rtemself.h rtems.h"
        # tm_file="${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sol2.h
sparc/sol2.h sparc/elf.h sparc/rtemself.h rtems.h"
        tmake_file="sparc/t-elf sparc/t-crtfm t-rtems"
        extra_parts="crti.o crtn.o crtbegin.o crtend.o"
        ;;

Created attachment 7995 [details]
Rework of sparc-rtems configuration.


This patch is a rework of the sparc-rtems* target based upon the ELF
NetBSD/SPARC 
target.  As a reqork, I was able to also fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14537 (unix is predefined).

With this fix, I can build RTEMS and run C and C++ test applications.

Is it OK to commit?

The sparc-elf target probably be reworked in a similar fashion with some
sharing with sparc-rtems.  If a sparc maintainer feels this is the correct
thing to do, then let's file a PR against sparc-elf and I will fix that.  But
that is beyond my maintainership responsibility.

> This patch is a rework of the sparc-rtems* target based upon the ELF
> NetBSD/SPARC target.  As a reqork, I was able to also fix
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14537 (unix is predefined).
> 
> With this fix, I can build RTEMS and run C and C++ test applications.

Thanks for your efforts.

[Note the bogus reference to PR 14536 in the ChangeLog entry.  And the format
is rather PR target/14537 than the other way around.]

> Is it OK to commit?

I'm not very fond of the patch because it trades an explicit dependency on
Solaris for an implicit dependency on NetBSD, bringing the bugs in the process.
For example:

+/* A 64 bit v9 compiler with stack-bias,
+   in a Medium/Low code model environment.  */
+
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT \
+  (MASK_V9 + MASK_PTR64 + MASK_64BIT /* + MASK_HARD_QUAD */ \
+   + MASK_STACK_BIAS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
+
+#undef SPARC_DEFAULT_CMODEL
+#define SPARC_DEFAULT_CMODEL CM_MEDANY

Note the discrepancy between the comment (Medium/Low) and the actual setting
(Medium/Any).  Then in the specs

+    %{p:-mcmodel=medlow} \
+    %{pg:-mcmodel=medlow}}"

This code model frobbing is a bug that I've asked the NetBSD maintainers to fix,
with no effect for the time being.

> The sparc-elf target probably be reworked in a similar fashion with some
> sharing with sparc-rtems.  If a sparc maintainer feels this is the correct
> thing to do, then let's file a PR against sparc-elf and I will fix that.  But
> that is beyond my maintainership responsibility.

The bugreport for sparc-elf was posted yesterday on gcc-patches so I now think
we need to find a generic solution for all the embedded targets.  I proposed to
duplicate the Solaris configuration files for them and remove the offending bits
from there; this was agreed upon by Daniel and the RM so I'm going to do it now.

Once the work is done, sparc-rtems will very likely build again so your patch
would not be necessary anymore.  But you're an RTEMS maintainer so I can't bar
you from installing it anyway if you deem it profitable.

Sort of fixing.

(In reply to comment #10)

> I'm not very fond of the patch because it trades an explicit dependency on
> Solaris for an implicit dependency on NetBSD, bringing the bugs in the process.

In general, I don't like the rtems targets having much meat to them.  
I don't like the implicit dependency either.  

> For example:
> 
> +/* A 64 bit v9 compiler with stack-bias,
> +   in a Medium/Low code model environment.  */
> +
> +#undef TARGET_DEFAULT
> +#define TARGET_DEFAULT \
> +  (MASK_V9 + MASK_PTR64 + MASK_64BIT /* + MASK_HARD_QUAD */ \
> +   + MASK_STACK_BIAS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
> +
> +#undef SPARC_DEFAULT_CMODEL
> +#define SPARC_DEFAULT_CMODEL CM_MEDANY
> 
> Note the discrepancy between the comment (Medium/Low) and the actual setting
> (Medium/Any).  Then in the specs
> 
> +    %{p:-mcmodel=medlow} \
> +    %{pg:-mcmodel=medlow}}"
> 
> This code model frobbing is a bug that I've asked the NetBSD maintainers to fix,
> with no effect for the time being.

And I unknowingly inherited it.  I trusted that the NetBSD code was right 
to start. :(
 
> > The sparc-elf target probably be reworked in a similar fashion with some
> > sharing with sparc-rtems.  If a sparc maintainer feels this is the correct
> > thing to do, then let's file a PR against sparc-elf and I will fix that.  But
> > that is beyond my maintainership responsibility.
> 
> The bugreport for sparc-elf was posted yesterday on gcc-patches so I now think
> we need to find a generic solution for all the embedded targets.  I proposed to
> duplicate the Solaris configuration files for them and remove the offending bits
> from there; this was agreed upon by Daniel and the RM so I'm going to do it now.

The bug repport was posted or a fix?  This PR covered both sparc-elf and
sparc-rtems* since I verified when I reported it that both were broken.

> Once the work is done, sparc-rtems will very likely build again so your patch
> would not be necessary anymore.  But you're an RTEMS maintainer so I can't bar
> you from installing it anyway if you deem it profitable.

I would rather have a thin sparc-rtems configuration wrapping sparc-elf, so I
won't commit it if you can fix both targets quickly.  Make sure unix is not part
of the cpp predefines on sparc-elf and sparc-rtems when you do, please.

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.

I don't know which target needs this but if it is important to them,
we can override it in rtemself.h.  But I wanted to you watch this one
as you fix sparc-elf/rtems.

(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.

(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. 

> The bug repport was posted or a fix?  This PR covered both sparc-elf and
> sparc-rtems* since I verified when I reported it that both were broken.

Bug report and fix, but the fix was to link sol2-c.c in.

> I would rather have a thin sparc-rtems configuration wrapping sparc-elf, so I
> won't commit it if you can fix both targets quickly.  Make sure unix is not
> part of the cpp predefines on sparc-elf and sparc-rtems when you do, please.

Sure.  I'll post it to gcc-patches and CC the interested parties so that they
could comment, before commiting it.

[About LINK_GCC_C_SEQUENCE_SPEC]

> I don't know which target needs this but if it is important to them,
> we can override it in rtemself.h.  But I wanted to you watch this one
> as you fix sparc-elf/rtems.

It comes from: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00176.html

The V7 variant of libgcc/_muldi3.o has a dependency on .umul (and _divdi3.o on
.udiv) which are provided by the libc because V7 doesn't have the instructions.
So we need the double group-inclusion of "%G %L" by default, unless the linker
is smarter (like on Linux).

> 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.

It is actually ABI-specific.  I think the V7 ABI more or less mandates it.

> FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
> LINK_GCC_C_SEQUENCE_SPEC are broken.

I don't think so.  I can tell you for sure that Solaris is not 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.

Note the Linux variant: "%{static:--start-group} %G %L %{static:--end-group}"
which means that the group "%G %L" is repeatedly searched.  Of course the Sun
linker (at least the ancient versions) is not that smart so we need to use the
double inclusion by default.

> 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.

It is actually ABI-specific.  I think the V7 ABI more or less mandates it.

> I don't really like this. IMO, the sparc backend suffers from its
> SunOS/Solaris history and should be cleaned up.

The default values of settings are indeed chosen for Solaris and I don't expect
to change that in the near future.

(In reply to comment #16)
> > FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
> > LINK_GCC_C_SEQUENCE_SPEC are broken.
> 
> I don't think so.  I can tell you for sure that Solaris is not 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.
> 
> Note the Linux variant: "%{static:--start-group} %G %L %{static:--end-group}"
> which means that the group "%G %L" is repeatedly searched. 

Hmm, we have 
--start-group  -lrtemsbsp -lrtemscpu  -lc -lgcc --end-group
in all of RTEMS-gcc specs. This might explain, why we don't see this issue.

> Of course the Sun
> linker (at least the ancient versions) is not that smart so we need to use the
> double inclusion by default.
Note _Sun_, not _sparc_.

Removing target milestone per: <http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html>.

Subject: Bug 19364

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	ebotcazou@gcc.gnu.org	2005-01-24 21:31:52

Modified files:
	gcc            : ChangeLog config.gcc 
	gcc/config/sparc: liteelf.h openbsd64.h rtemself.h sp64-elf.h 
	                  sp86x-elf.h 
Added files:
	gcc/config/sparc: sp-elf.h 
Removed files:
	gcc/config/sparc: elf.h 

Log message:
	PR bootstrap/19364
	* config.gcc (sparc-*-elf*): Remove sol2.h, sparc/sol2.h and
	sparc/elf.h, add sparc/sp-elf.h.
	(sparc-*-rtems*): Likewise.
	(sparclite-*-elf*): Remove sol2.h, sparc/sol2.h, sparc/elf.h and
	tm-dwarf2.h, add sparc/sp-elf.h.
	(sparc86x-*-elf): Likewise.
	(sparc64-*-elf*): Remove sol2.h, sparc/sol2.h and tm-dwarf2.h.
	* config/sparc/liteelf.h (TARGET_SUB_OS_CPP_BUILTINS): Rename into
	TARGET_OS_CPP_BUILTINS.
	* config/sparc/sp86x-elf (TARGET_SUB_OS_CPP_BUILTINS): Likewise.
	* config/sparc/rtemself.h (TARGET_SUB_OS_CPP_BUILTINS): Likewise.
	Undefine it.
	* config/sparc/openbsd64.h (NO_IMPLICIT_EXTERN_C): Undefine.
	* config/sparc/sp64-elf.h (NO_IMPLICIT_EXTERN_C): New macro.
	(SWITCH_TAKES_ARG): Likewise.
	(LOCAL_LABEL_PREFIX): Likewise.
	(ASM_GENERATE_INTERNAL_LABEL): Likewise.
	(TARGET_N_FORMAT_TYPES): Delete.
	(TARGET_FORMAT_TYPES): Likewise.
	(ASM_DECLARE_FUNCTION_SIZE): Likewise.
	* config/sparc/elf.h: Delete.
	* config/sparc/sp-elf.h: New file.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7264&r2=2.7265
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.gcc.diff?cvsroot=gcc&r1=1.510&r2=1.511
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sp-elf.h.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/liteelf.h.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/openbsd64.h.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/rtemself.h.diff?cvsroot=gcc&r1=1.12&r2=1.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sp64-elf.h.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sp86x-elf.h.diff?cvsroot=gcc&r1=1.17&r2=1.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/elf.h.diff?cvsroot=gcc&r1=1.13&r2=NONE

See http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01532.html