On quinta-feira, 15 de agosto de 2013 12:57:04, Knoll Lars wrote: > >What's more, on x86, the default 32-bit build is just nonsense today. > >CPUs > >from the past 10 years from both Intel and AMD have had support for SSE2. > > THat's a somewhat separate problem, but I agree that it's time to fix our > default build flags for Qt. We can IMO assume at least standard SSE2 > instructions. If someone needs something for an older processor, compile > yourself.
Uh... no, I don't think we can assume that. I'm afraid of Sune and other distro packagers! :-) I do think our buildsystem is already enough. If CXXFLAGS is set on the environment, we'll pick it up. If a distribution wants to raise their build flags, they can easily do that. In fact, I imagine they already do, in their standard buildsystems. We may consider doing the same in our own binaries. That's our choice. > >4) Restrict any CPU-specific code to C or C++ source files with limited > >#include > > > >This is the solution I prefer (suggested by Shane on IRC). We'd keep the > >special compilers, but we'd drop all the include paths for Qt headers. > >Those > >sources would be restricted to system headers, which include the support > >for > >intrinsics. > > > >For C++ sources, we need to ensure no Standard Library headers are > >included > >(same problem as Qt headers). ISO C headers are fine, since C89 doesn't > >support > >inlines, and C99 inlines are just plain weird. Most C headers use "static > >inline" for inlines, which is fine. > > > >For that reason, I think we should stick to C, unless there's a very good > >reason why not (like GCC's dispatch feature, which is only supported in > >C++). > > I'd agree that option (4) is the cleanest solution. Have you checked how > much we'd need to change to implement it? No, not yet. I don't think it will be too hard because those routines are still fairly limited. I will look into this soon. It's good I never got to cleaning up and pushing my experiments of 18 months ago, which I still have in my tree. That went in the complete opposite direction of moving more C++ code into the specially-compiled files. The idea isn't incompatible (moving more code), but we need to be very careful now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
