Simon Stelling wrote: > Luca Barbato wrote: >> Alternatives: >> >> - as PPC we provide a default cflags & use tuned per certain cpu >> families using profiles, amd64 could provide a nocona profile that bans >> 3dnow* useflags. > > Not really. There are athlon64s and opterons with and without sse3 support. > The > users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as > they expect the flag to do what it says. The problem is even worse for x86: > You'd have to provide own profiles for: > > * i386
there is already isn't it? > * pentium-mmx,k6 people know what they are > * athlon xp,pentium3 ditto > * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting > from > 'willamette' core) those are relatively new > * celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting > from > venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX > (starting > from san diego stepping E4), sempron (starting from palermo stepping E3), Don't complain with me about marketing > pentium4 (starting from 'prescott') and so on... > etc... > > and now you want to let your pentium4(paris)-server, which is running 24/7, > compile a binpkg for your pentium4(prescott), using SSE3 > > have fun 8-) I take the base profile and turn sse3 useflag on, tune the cflags properly and then I issue the emerge -B foo as usual specific profiles are good just for disoriented users that need something working quickly, people knowing their system and what they want would be much happy with the useflags. Having better descriptions for flags could be of help too. Keep in mind that discover what your cpu or another cpu could take as cflags or simdflags requires the same (look at the arch faq about it, parse the cpuinfo, google a bit) > I'm not sure whether I understand this correctly. If we use flameeyes logic > anyway, why keeping the use flags? > Because you may not want all the flags the gcc guess would set for a reason or another (and there are many, including having gcc-X.ugly doing the worst with -msimd_du_jour but having some nicely tuned routines for that simd triggered by --enable-simd_du_jour) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
