On 10/27/2017 02:35 AM, Richard Biener wrote: > On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote: >>> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford >>> <richard.sandif...@linaro.org> wrote: >>>> Richard Biener <richard.guent...@gmail.com> writes: >>>>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford >>>>> <richard.sandif...@linaro.org> wrote: >>>>>> This patch adds a POD version of fixed_size_mode. The only current use >>>>>> is for storing the __builtin_apply and __builtin_result register modes, >>>>>> which were made fixed_size_modes by the previous patch. >>>>> >>>>> Bah - can we update our host compiler to C++11/14 please ...? >>>>> (maybe requiring that build with GCC 4.8 as host compiler works, >>>>> GCC 4.3 has -std=c++0x, but I'm quite sure that's not enough). >>>> >>>> That'd be great :-) It would avoid all the poly_int_pod stuff too, >>>> and allow some clean-up of wide-int.h. >>> >>> Can you figure what oldest GCC release supports the C++11/14 POD handling >>> that would be required? >> >> I think it is too early for that, we aren't LLVM or Rust that don't really >> care about what build requirements they impose on users. > > That's true, which is why I asked. For me requiring sth newer than GCC 4.8 > would be a blocker given that's the system compiler on our latest server > (and "stable" OSS) product. > > I guess it depends on the amount of pain we have going forward with C++ > use in GCC. Given that gdb already requires C++11 people building > GCC are likely already experiencing the "issue". It's always going to be a balancing act. Clearly we don't want to go to something like the Rust model. But we also don't want to limit ourselves to such old tools that we end up hacking around compiler bugs or avoiding features that can make the codebase easier to maintain and improve or end up depending on dusty corners of C++98/C++03 implementations that nobody else uses/tests anymore because they've moved on to C++11.
To be more concrete, if I had to put a stake in the ground. I'd want to pick a semi- recent version of Sun, IBM and Clang/LLVM as well as GCC. Ideally it'd be something that supports C++11 as a language, even if the runtime isn't fully compliant. I suspect anything older than GCC 4.8 wouldn't have enough C++11 and anything newer to not work well for the distros (Red Hat included). Jeff
