On Mon, Dec 20, 2010, Mark Mitchell wrote: > I certainly understand that desire; I'm just asking how sustainable it > is and where the commitments ought to lie. I'd just guess that this > would be an ongoing problem, and that there will be a tension between > "make the best possible ARM Linux system" and "don't break other > architectures".
Upstream faces the same problem, yet manages to move the compiler forward. Since Linaro's goal is for all new developments to make it upstream, we should simply live by upstream's standards when developing patches. This thread is going into Linaro toolchain policies at the worst time of the year while key stakeholders are away (/me waves to Michael Hope) but I believe the position on the goals of the Linaro Toolchain were made extremely clear: neutral on correctness (no regression introduced by Linaro changes) and focus on improving performance on modern ARM CPUs (ARMv7+). Now you bring up more subtle problems, pointing out that there is a grey area when e.g. performance improves vastly on ARM and degrades on other arches. I am pretty sure upstream has a good approach to solve this use case, I would expect that the feature is either disabled by default on non-ARM or only enabled on ARM, or that it's protected by a flag and that people with a clue about the flag only use it on ARM or never use it on non-ARM. I'm sure there are better approaches than manual "ifdefs" or "ifs" to deal with these issues as well, for instance the compiler actually checking whether it will generate slower code or not, and selecting the best course of action for you. But my point is not how to solve each particular problem, it's rather that we should solve the problem exactly how it would be solved to get it upstream. Another question is the one of testing; we're testing on ARM and on x86. Testing can always be improved, and it will improve over time. I don't think we can be expected to test all possible architectures, just like the other contributors to GCC don't test all architectures when submitting code changes. Concerning PPC, we wouldn't want to regress it any more than other architectures, and if PPC-specific issues are triggered by Linaro patches, heck we should fix them! But I don't expect we'll validate each and every patch on PPC, MIPS, SH... I think what happened here is exactly what we wanted to happen: some PPC specific regressions were discovered once the patches got wider adoption, Ulrich did the right thing in raising the conflict between PPC expectations and the Linaro changes and we need to discuss a good path forward so that these patches can be included upstream. Exactly as this would be discovered/discussed upstream :-) We can meet in Dallas in ~20 days and discuss this face to face as well :) -- Loïc Minier _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
