Date: Mon, 18 Aug 2014 14:27:21 -0500 From: Pedro Giffuni <pfg@freebsd.org> To: Dimitry Andric <dim@FreeBSD.org>, Alexey Dokuchaev <danfe@FreeBSD.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r270099 - in stable: 10/contrib/gcc/config/i386 9/contrib/gcc/config/i386 Message-ID: <53F25399.40204@freebsd.org> In-Reply-To: <9181921C-43BB-48C9-B63D-7C6F99D7A763@FreeBSD.org> References: <201408171308.s7HD8Fnh099147@svn.freebsd.org> <20140817131942.GA38672@FreeBSD.org> <8CA269F6-BCD2-4E78-947F-682214367F36@FreeBSD.org> <20140817134509.GA47327@FreeBSD.org> <9181921C-43BB-48C9-B63D-7C6F99D7A763@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello; On 08/17/14 17:45, Dimitry Andric wrote: > On 17 Aug 2014, at 15:45, Alexey Dokuchaev <danfe@FreeBSD.org> wrote: >> On Sun, Aug 17, 2014 at 03:29:42PM +0200, Dimitry Andric wrote: >>> In principle it is applicable, but the same file also has other changes >>> in head which were not MFCd, so just MFCing this one commit does not >>> make much sense. For example, the earlier cast fixes were part of a >>> much larger commit by Pedro Giffuni, adding "experimental support for >>> amdfam10/barcelona CPUs": >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=251212 >> I'm running my stable/8 with Pedro's patches applied, including r251212, >> no problems so far (although I don't have recent AMD CPUs to play with). >> >>> Does it still make sense to backport such experimental changes to an old >>> stable branch? Of course I could split off just the changes to >>> emmintrin.h, and leave the others out, but then we would have a partial >>> MFC. I'm not sure if that is the usual way of doing things... >> Understood. My goal here is to try to keep stable/8 as alive as possible, >> since I plan to keep using it beyond its official EOL. Hence, when I see >> fixes that potentially help ports to be buildable on it I'd usually ask if >> they can be MFCed (when it's easy enough to do). FWIW, I recall the AMD patch was developed on stable/8 and should be safe to merge. You still need have to teach the build system about the new CPUs (that was a different change that I didn't do) but it should work. I personally stopped merging stuff to the stable/8 branch and more recently to the stable/9 branch as I don't run those anymore. In the case of the stable/8 branch I find the ancient version of binutils a real threat/limitation. I would really suggest people move on to at least stable/9 which has all the clang cleanups and should be functionally much better. Pedro. > Can you please try this diff [1], which merges most of the stable/9 gcc > changes to stable/8? I've ran it through a make universe, and the only > failure I got was with the amd64 XENHVM kernel: > > amd64 XENHVM kernel failed, check _.amd64.XENHVM for deatils > > but I don't know if this is an expected failure or not. Tinderbox seems > to have other trouble with its stable/8 builds. The actual error is: > > In file included from sys/sys/param.h:86, > from sys/compat/ia32/ia32_genassym.c:6: > sys/sys/types.h:44:28: error: machine/endian.h: No such file or directory > > I didn't test any ports yet, though. > > -Dimitry > > [1] http://www.andric.com/freebsd/sync-stable8-gcc-with-stable9-1.diff.xz >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F25399.40204>