> Of course various parties care about that. But that doesn't necessarily > imply they can or want to run buildbots for a different compiler they don't > care about, there are e.g. security implications to that, resources etc.
This brings us back to the initial issue: the way asan&co are developed. The fact of life is that the development happens in the LLVM tree. The only strategy to keeping GCC's version in sync with upstream that works for us it to have verbatim copy of the sources in GCC and to have the merge process purely mechanical. It has not been purely mechanical with the last merge. Any other strategy would mean that someone else does the merges. This is totally fine as long as the sources do not diverge over time; but I afraid they will diverge. Testing asan&co upstream does not necessary require testing the rest of the LLVM compiler. It would be really great to have someone test the entire LLVM tree on e.g. "old" Fedora, but we can limit such testing just to the compiler-rt project. Ideally for me, GCC would use sanitizer sources from compiler-rt completely verbatim, retaining the entire directory structure with all the tests and not adding any extra files inside that tree. Maybe even use "svn external" for greater simplicity. The GCC's build files (Makefile.am, etc) and GCC-specific tests would live outside of that source tree. This way it would be easy to set up a build bot that takes fresh compiler-rt, puts it into the GCC tree, and runs the GCC testing. The merges than will become purely mechanical: check the bots, put the new sources into gcc (or even update the "svn external" revision!). > > For GCC new ports etc. we never require people running some buildbots, > people just report issues they encounter and those issues are fixed. > >> tsan makes many assumptions about the system (address space, etc) >> which may not hold on old systems anyway. >> And tsan, even if it builds, will not work reliably. >> >> I really think that we need to disable libsanitizer on old systems >> until someone volunteers to set up a proper testing process upstream. >> If no one volunteers -- no one really needs it. > > The problem is that the definition of "old systems" is extremelly fuzzy, > for you it is clearly != "Ubuntu 12.04" or similar, but the unwritten > assumptions libsanitizer makes are not related to one exact version of > a single dependent component, it is a matter of compiler, compiler > configuration, binutils, glibc, kernel, kernel headers, ... > > So, how do you disable libsanitizer on "old systems" when it is so fuzzy? I would start from kernel version and glibc version, this should cover the majority of use cases. --kcc > There may be assumptions you just don't know about, and "fixing" bugreports > by just adding reporter's toolchain combinations to kill lists is certainly > not the way GCC is developed. > > Jakub
