On Thu, 6 Jul 2006 13:49:39 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote: > | > Sounds rather flaky and unreliable... > | Sounds rather vague and without arguments. > > Well, you're assuming that a) everyone's using a C compiler, > b) that gcc has the slightest clue what it's doing, We're mostly talking about specially-written assembler code, not stuff like vectorisation or the intrinsics (which very few packages use, if any). > c) that the user has no > problem using nasty hacks to regain control, Control is easy. Specify the relevant -march in CFLAGS. > d) that this information is only needed at compile time, Where a package does run-time detection, there's no need for any conditional compilation as they build for everything anyway, so such packages wouldn't use mmx/sse/sse2 etc USE flags anyway. > e) that various gcc internal definitions won't change... Unlikely for these macros, as that would break a lot of existing code regardless what we do. > You're adding a lot of complexity, and > thus room for very weird breakages, to something that doesn't need it. I'd argue the current approach is the more complex approach, involving the user having to discover the relationship between their processor (which they've already set via -march in CFLAGS) and the various bits that their processor has. There are relatively few packages affected (<1%), so I think it's worth a try. In the end it may be that a few packages need to deal with stuff manually like with the current USE flags, but they'd be local USE flags at that point. -- Kevin F. Quinn
signature.asc
Description: PGP signature
