[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[joel at gcc dot gnu dot org]

------- Additional Comments From joel at gcc dot gnu dot org  2005-01-20 12:42 -------
(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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19364