On Wed, Nov 14, 2012 at 5:01 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > "H.J. Lu" <hjl.to...@gmail.com> writes: > >>>> I think all changes should go upstream first. It was a mistake >>>> to check sparc changes into GCC tree. >>> >>> I disagree, as do others: it is undesirable for gcc maintainers to have >>> to interact with many different upstream communities to get their >>> changes in. This is far better dealt with by the respective >>> subsystem/library maintainers who have links to both communities. >> >> This may work for a mature library. libsanitizer keeps changes. >> Local changes make it hard to sync with upstream. > > I'm not talking about local changes, just about a liaison to take care > of moving changes started on the gcc side upstream. Say you're working > on a platform not supported by LLVM (e.g. Solaris, I haven't checked): > why should you be forced to deal with them and their infrastructure > (mailinglists etc.) to get asan in gcc working on your platform? > > This is exactly how Ian moves my libgo changes upstream and imports > upstream libgo once in a while. >
We don't have a maintainer is a problem, not go upstream first. I have a patch pending to enable mulltib. But libsanitizer doesn't work on x32 and it doesn't cause bootstrap problem with x32 enabled on Linux/x86-64. As soon as multlib is enabled, my bootstrap will fail since libsanitizer doesn't compile for x32. It has been fixed upstream. Should we apply a local fix or copy from upstream? -- H.J.
