This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]