This is the mail archive of the
mailing list for the GCC project.
Re: Upstreaming very old changes
- From: Jeff Law <law at redhat dot com>
- To: coypu at sdf dot org, gcc at gcc dot gnu dot org
- Date: Fri, 4 Aug 2017 12:04:50 -0600
- Subject: Re: Upstreaming very old changes
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B32886146B
- References: <20170804172000.GA2860@SDF.ORG>
On 08/04/2017 11:20 AM, email@example.com wrote:
> Hi, GCC!
> I believe netbsd is the primary user of the vax target. its status is:
> good: netbsd uses gcc 5.4.0, and cross compiles its userland+kernel with
> this. it runs and is also able to natively build useful programs like perl.
> bad: -O0 in places, text relocations. obvious signs of more bugs not yet
> however, this is with a large diff to gcc. the author of most of the
> changes is Matt Thomas, who is also the GCC vax port maintainer. the
> biggest change is probably shared library support (... from 1998).
> I'm not sure why he hasn't committed his work upstream, but it would be
> nice to bridge the gap, to make it easier for anyone (possibly myself,
> in some future time after education) to adapt the code to non-deprecated
> GCC APIs.
> legal - I don't think this is a real issue - most people involved have
> already signed FSF paperwork, and there's commit history, so I can
> explicitly ask all the people involved to state they are OK with it.
> technical - I am not a compiler expert, and this is a large unexplained
> diff. even originally, the commit messages weren't very verbose. It also
> adds 20 years of effectively "merge local diff to head". however, the
> end result does work well enough to boot, run, etc.
> if I go down this road, how can I begin bridging this gap?
Best advice is to break things down into a series of independent
changes. Ideally with testcases.