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. gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.0.20050109/gcc -I../../gcc-4.0.20050109/gcc/. -I../../gcc-4.0.20050109/gcc/../include -I../../gcc-4.0.20050109/gcc/../libcpp/include \ ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c -o sparc.o ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: `solaris_insert_attributes' undeclared here (not in a function) ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: initializer element is not constant ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: (near initialization for `targetm.insert_attributes') ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: initializer element is not constant ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: (near initialization for `targetm.calls') ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: initializer element is not constant ../../gcc-4.0.20050109/gcc/config/sparc/sparc.c:504: error: (near initialization for `targetm.cxx') make[1]: *** [sparc.o] Error 1 make[1]: Leaving directory `/home/rtems/src/packages/SOURCES/b-gcc/b-gccsparccelf/gcc' make: *** [all-gcc] Error 2
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