This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cross target report on gcc 3.1-20020423
Jim Wilson wrote:
>
> >a29k is officially deprecated so I lean to disabling Fortran for it
> >and let it go. How does one disable a language for a particular CPU?
> >Where is the configurery magic? It must be inside the gcc directory
> >instead of the top level one.
>
> I think the best option would be to stop building and testing the a29k port.
:) Actually this is my thinking but I wanted to know that the compiler
was in a clean buildable state when we deprecated it.
> As for disabling a language for a particular CPU, there isn't a supported way
> to do this. We used to do this by adding a LANGUAGES= line to a target
> Makefile fragment, but this was never elegant, and is no longer supported.
>
> Current mechanism for users is to use --enable-language when configuring to
> choose which languages they want to build. We can specify in target specific
> docs that the user should use this to avoid building Fortran, but that isn't
> very elegant.
>
> Better would be to have some sort of unsupported_language variable that a
> target can set, but not the user. We can then warn about unsupported languages
> and avoid configuring them. If the user gives a --enable-language configure
> option that conflicts with the target dependent unsupported_language then
> we give an error.
This would be a nice features but I agree with your argument below in
spite
of the fact that CPUs like the h8 don't support enough memory to truly
be
useful for some languages.
> The problem with allowing unsupported_languages is that some people may use
> this as an excuse to do incomplete ports. If they don't care about C++, then
> they just mark it as an unsupported_language. So we may not want to support
> this feature. That takes us back to documenting that the a29k port is broken
> for Fortran, and askin g the user to specify --enable-languages at configure
> time
I kind of agree but think that not supporting a language should be a
documented
thing and that the error must point you to something that explains the
rationale. One of the only downsides to the multi-language gcc source
tree is that some languages are not supported by all ports. Some can't
be
(h8) and some port communities simply don't care about some languages.
I think that the existing state must be documented and unfortunately
that
does allow future porters an out. At least when a new port is accepted,
we can require them to document the state of all languages and the
configurery can point out that information until it is believed to be
supported.
Right now, one can be cynical and point out that Ada was
added and that most of the ports have not been even been compiled for
Ada yet. :)
> >>i960-coff - libobjc/encoding.c:887 XFmode undeclared.
> >This is beyond my area of expertise but I have a comment below. :)
>
> There are really only two practical choices here.
>
> 1) Stop building objc for i960.
IMO this is perfectly reasonable. If there was a general way to
note the port/language status. When someone cares, they can fix it.
Otherwise, people have to simply know which ports are broken for
which languages and avoid them. FWIW this is why I often test
with only C/C++ and that isn't enough to survive builds on all CPUs.
> 2) Apply a hack that makes the build failure go away, while accepting the
> fact that this won't make objc work.
Hacks like this are bad.
> The first one works only if we tell the user to use --enable-languages at
> configure time. The second one is not too hard, and is probably what I will
> try to do.
That's fine with me but long-term, I am not so unsure that adding a way
to avoid languages for a CPU isn't bad. We already avoid run-time
libraries
on a per CPU basis. Why force languages on CPUs when no one is
interested.
Fortran on the i960 may be a text book example. :)
> Jim
--joel