This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc/gcc config.gcc config/sparc/linux.h config ...
From: "David O'Brien" <obrien@FreeBSD.org>
Date: Fri, 5 Apr 2002 17:47:53 -0800
Uh... perhaps you miss one of the points of me contributing
config/sparc/freebsd.h rather than just keep it in the FreeBSD source
tree -- that is so that it evolves with the rest of the GCC code.
I did not realize I was going to have to watch ever gcc/config/sparc
commit to keep config/sparc/freebsd.h from going stale.
Just because you've merged your code into the tree, this doesn't
obviate the need for you to do some maintainence to keep things
in sync.
Lots of times, new features will require an understanding of the
target to implement support for that feature correctly. If I add such
a feature, I will add support for the platforms I understand and can
verify. If freebsd users or developers desire support for the feature
too, someone who understands that target has to implement the support.
I was, in fact, trying to limit potential damage from my changes
should I have made a mistake. Part of doing that was not adding
support for the feature to targets I was not familiar with or could
not do a full bootstrap/make-check on. That is what it means to make
responsible changes to the stable branch of the compiler.
Unless you actually built an embedded sparc64-ELF compiler and ran it on
some embedded target
There are people doing exactly this.
Would you please do this since you made the original enhancement and
commit.
Sure, no problem. I'm checking this in now to both the mainline
and the 3.1 branch.
This commit was easy to miss -- I only noticed it because I was
actually watching the output of `gcc_update' on my 3.1 branch check out.
And I am only paying very high attention to GCC (and only 3.1) right now
because I am about to make 3.1 the FreeBSD system compiler.
Your platform will certainly not get every nice new optimization
feature, especially one's requiring nontrivial support from the
target, if you aren't going to do the work to implement and verify
that support.
This is called maintaining the port.
Franks a lot,
David S. Miller
davem@redhat.com