Re: [gentoo-dev] Replacing cpu-feature USE flags
* Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] schrieb: On Thursday 06 July 2006 13:00, Stuart Herbert wrote: The one advantage of using USE flags for this is that the support can be controlled very easily on a per-package basis. CFLAGS is much more of a system-wide setting. There is always the bashrc to set CFLAGS on a per-package basis. hmm, quite inconsitent. Would be better if we had something similar to package.use, but for things like CFLAGS. (btw: evrything that can be controlled by environment should be also available through such per-package tables in /etc/portage/) Are there examples where we'd want to have these CPU feature flags enabled for one package, but disabled for another (for performance or stability reasons)? I think the main issue would be with hardened, where mmx is already a problem on some packages, but I think this can be solved. IMHO there was some hardened useflag. Is it the place where such things should go ? For any package where enabling mmx create stability problem, it's likely the support should be removed altogether anyway, as the flag is enabled for the majority of users already (the same goes for the other flags). hmm, for most users this should be okay. But what's w/ people who want to play around w/ this ? BTW: is there a way for masking an useflag of some package ? Lets say, we've got some package which has special mmx support. The package itself (w/o mmx) has been proven as stable, but the mmx stuff hasn't. Is it then possible to mask only the MMX stuff ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
* Donnie Berkholz [EMAIL PROTECTED] schrieb:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Maybe it goes out of gentoo's scope, but I'm developing an
universal toolchain wrapper which also supplies an gcc-style
libtool frontend:
http://wiki.metux.de/public/Universal_Toolchain
Perhaps someone likes to have a look at it.
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
* Ned Ludd [EMAIL PROTECTED] schrieb: snip Non gcc compilers have never been supported and probably never will be. If someone decides to work on that topic, IMHO the best approach would be providing an gcc-style frontend, so we actually get an drop-in-replacement (at least from the command line view). I've done something similar w/ my universal toolchain project, which works compiler-independent (although I currently have only an gcc backend ;-o) and also provides an drop-in-replacement for libtool w/ gcc as an additional frontend. http://wiki.metux.de/public/Universal_Toolchain cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
* Kevin F. Quinn [EMAIL PROTECTED] schrieb: 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. Well, there are still valid reasons: if you *know* you'll run the binary only on non-mmx systems, you'd probably get rid of it to make the binary smaller and reduce possible points of errors. I'd consider the runtime-detection just as an extra failsafe check. snip 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. ACK. Nobody forbids some packages having their own local useflags, if really necessary. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Tue, Jul 25, 2006 at 02:14:46PM +0200, Enrico Weigelt wrote: * Ned Ludd [EMAIL PROTECTED] schrieb: snip Non gcc compilers have never been supported and probably never will be. If someone decides to work on that topic, IMHO the best approach would be providing an gcc-style frontend, so we actually get an drop-in-replacement (at least from the command line view). What would it do if a gcc-specific option is used for which the real compiler does not provide any option, even with a different name? If it would ignore it, things would break horribly (just think of -funsigned-char). If it would error out, are any options other than those already specified by POSIX (`man 1p c99`) available on all systems? (If not, no gcc-style frontend is necessary, because the options are already the same for all compilers intended to be usable as a (Unix-like-)system compiler.) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. well i cant answer it if you havent asked it ... me not answering you on irc when i'm not around does not constitute being ignored and anyone who relies on irc in this respect really needs to learn more about irc I also mentioned it in a bugzilla comment, though admittedly not as a question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to assume read, right? the log message looks pretty clear to me, i dont see this hidden message you're referring to the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. this is also the reason i havent added USE=vanilla to glibc, too many users would simply break their boxes No complaints there. :) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). And of course promising so long as the stubs do not get applied with nossp, that you will handle all breakage in that area. Although I do not know if its still really fair to expect Jakub et ell to sacrifice time to process the bugs, and get them to you if its related to something failing due to the missing stubs. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 15:18 -0500, Tushar Teredesai wrote: On 7/7/06, Ned Ludd [EMAIL PROTECTED] wrote: You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. LFS http://www.linuxfromscratch.org/lfs has always been based on a vanilla toolchain. Never ran into issues. Of course, we do apply upstream patches when needed. They patch gcc as needed also. http://www.linuxfromscratch.org/hlfs/ -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 23:09 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 Option 3: Enlighten me. I have explained why I feel the way I do, so if there's some big flaw in my understanding, please do correct it. Sigh... I'm not going to sit here and bicker with you. At the end of the day here is what matters.. Your giving Mike a hard time on the most vital of all programs in this distro and that just sucks so please stop and just be happy that the toolchain works as well as it does. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. I guess that's a fair point. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? I actually do file bugs there when I run into them. The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). Since I'm more interested in vanilla GCC, I think there's little to help maintain from Gentoo's side (support in ebuilds, and possibly the build process, that's it). If that's something you think help would be good for anyway, though, sure, if I can. And of course promising so long as the stubs do
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 13:51 +0200, Harald van Dijk wrote: On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. Actually it does if it cuts back his time by a very large percentage so that he cannot do the other things he wants/needs to. I assume this was the case if he added that in the first place, and still refuse to change it. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. Hmm, thought I might have had it a tad wrong. I still though do not understand what the whole fuss is about stubs for some 5 flags. (which is what you are left with with USE=vanilla nossp currently if my memory is correct). Maybe read down a bit before replying here. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. I think its reasonable to no force the feature on you, but add the stubs if it became a maintenance headache. I am pretty sure it was not toolchain who brought the whole situation about in the first place. You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Not at all. I thought you think its reasonable to just keep loading work on other people - or possible did not see that that would have been the end result. More about this to the end. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. From the length of this email, and you not wanting to see the reasoning, or not having started to fix the tree so that your wish can be full filled, It rather sounded like you did demand it. Or this was at least the impression I got. Also once again I do not see what the big issue with the stubs is. You keep making a big issue out of it without giving concrete examples or serious issues it is causing. The problem was there before they were added, and not due to
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Saturday 08 July 2006 02:20, Harald van Dijk wrote: I also mentioned it in a bugzilla comment, though admittedly not as a question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to assume read, right? the gcc2 bug has a lot of things in there i need to review/merge so it's in my little TODO box like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. well, vanilla is marked the same way, yet people use it ;) but as i said, i'll add 'use vanilla || apply_stub' logic once 4.1.x goes stable, just no sooner -mike pgpSz5fZ8qFvV.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
(Not commenting on the whole message, just parts.) On Sat, Jul 08, 2006 at 03:46:24PM +0200, Martin Schlemmer wrote: You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. I ask again: would such patches be accepted? (Mike stated he would remove stubs once GCC 4.1 is stable -- thanks -- so users wouldn't run into problems often regardless.) Vanilla, Gentoo patched - they all have bugs which bugzilla have more than enough of in. Ah yes, I see some that definitely apply to USE=vanilla builds. I'll see if there's anything I can understand. :) OK, maybe I was just too dense to see it before, or maybe you kept dancing around the issue. To put it clear (or try at least), your whole issue currently is that you cannot use a 'Vanilla' gcc (ie without the stubs) to build everything in the tree ? No, being able to use vanilla GCC as Gentoo's system compiler would be a nice addition, and if it's agreed as a good idea I don't mind helping out with getting it working, but I can live without it. And not as much the stubs them selfs ? Being able to check software for unofficial compiler flags is for some cases a must. I repeat: two separate issues. They keep getting mixed up here. I think you understood wrongly. If the stubs were to be just removed say tomorrow, and breakage in the tree is still of such an extend that bugs starts to flood in again, its not just you that will have to read the mail. If the user is clueless, then Jakub have to reassign the bug to either toolchain or the package maintainer. If he could not determine it was due to the missing CFLAG, The error is very clear: cc1: error: unrecognized command line option -fno-stack-protector Maybe I have a little bit more confidence in people, sorry if that's misplaced. :) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Harald van Dijk wrote: If the stubs were to be just removed say tomorrow, and breakage in the tree is still of such an extend that bugs starts to flood in again, its not just you that will have to read the mail. If the user is clueless, then Jakub have to reassign the bug to either toolchain or the package maintainer. If he could not determine it was due to the missing CFLAG, The error is very clear: cc1: error: unrecognized command line option -fno-stack-protector Maybe I have a little bit more confidence in people, sorry if that's misplaced. :) Erm, yeah I can recognize the error, but it's really not very productive to dupe the bugs over and over again. Killing the stubs breaks glibc compile [1] and it breaks perl compile [2] as well. [1] http://bugs.gentoo.org/show_bug.cgi?id=101471 [2] http://bugs.gentoo.org/show_bug.cgi?id=106965 I don't really see how is this a good idea to break two pretty critical packages for users that have no clue what USE=vanilla does w/ gcc. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Curtis Napier wrote: I could find a million threads in the forums supporting what Ciaran is saying here. We have been told over and over and over until my head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. That's because CFLAGS=-msse currently doesn't do what the user would think it does. Which is the real problem, which we're solving with the change Diego suggested. To change this behavior now after all this time would be crazy IMHO. It might have become some sort of policy, but if the policy doesn't have a god-like status. Sometimes it becomes obsolete and new (better) rules are put in place. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
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 * pentium-mmx,k6 * athlon xp,pentium3 * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from 'willamette' core) * 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), pentium4 (starting from 'prescott') 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-) - as before but provide an eclass that uses flameeyes infrastructure to warn about possible mismatch between what the cflags could do and what you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning and disable it I'm not sure whether I understand this correctly. If we use flameeyes logic anyway, why keeping the use flags? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
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
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | No, we never spent years telling them not to use your so-called | CFLAGS hacks that are rather a proper usage of what the compiler | gives you. Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. Yes, we did. Were we wrong? Out of a purest point of view ... maybe. The problem was though that earlier gcc's was very bad at generating sse/sse2, and sometimes mmx code. Users being what they are though (ricers should say it all), they enabled every flag that sounded like it could make their old box two times faster. This included -msse, -msse2, etc. Which quite frankly produced bad code in many cases. So we told the users to not add any -m* flags, and let gcc do its job with the proper -march. So yeah, I can see that general use flags for cpu features might become more tedious with the many new modules of processors out there, but to say handle it by adding -msse, etc to CFLAGS, will surely if not on gcc4, but then on gcc3 systems just ask for trouble. And yes, I know you are saying that that is not exactly what you are proposing, but the users will see it as a clear passport to stick all those nice sounding flags just right back in, and then it will be too late to tell them its not proper thing to do when the bugs start flooding in. Anyway, I tried to give some history and some what ifs, but as I admitted many times in the past, I am no great writer. You had to be 'there' I guess, *shrug*. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote: On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | No, we never spent years telling them not to use your so-called | CFLAGS hacks that are rather a proper usage of what the compiler | gives you. Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. Yes, we did. Were we wrong? Out of a purest point of view ... maybe. The problem was though that earlier gcc's was very bad at generating sse/sse2, and sometimes mmx code. Users being what they are though (ricers should say it all), they enabled every flag that sounded like it could make their old box two times faster. This included -msse, -msse2, etc. Which quite frankly produced bad code in many cases. So we told the users to not add any -m* flags, and let gcc do its job with the proper -march. So yeah, I can see that general use flags for cpu features might become more tedious with the many new modules of processors out there, but to say handle it by adding -msse, etc to CFLAGS, will surely if not on gcc4, but then on gcc3 systems just ask for trouble. And yes, I know you are saying that that is not exactly what you are proposing, but the users will see it as a clear passport to stick all those nice sounding flags just right back in, and then it will be too late to tell them its not proper thing to do when the bugs start flooding in. Dumb question, but what really blocks them from doing that now for x86 (for example)? Yes, can't enable certain flags for non x86/x86_64 arches, but the con you're pointing at exists now for the most part. ~harring pgpYOnT8LDWmY.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 04:28 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 03:15, Mike Frysinger wrote: x86_64 toolchain accepting 3dnow on a nocona arch? :) that isnt a cross-compile nor a different architecture This is the whole point of my solution. From what you discussed above, it sounds more like a problem due to short-sightedness on the amd64 team's part (no offence to amd64 team, just stating things as I see them) because they just enabled 3dnow for stuff that worked regardless. Stupid question though ... does the gcc test thingy list __3dNOW__ on nocona ? I would think that it does, as there is no -march=nocona (or whatever) yet. So now you want to instead of fixing the amd64 profiles to be more flexible, implement something that will give the green light to users on x86 to use flag combinations, especially on older gcc's that causes great pain for themselfs and developers ? Sure, nocona should have had CFLAGS=-march=k8 -mno-3dnow, but it would never have been an issue if the '3dnow' USE flag worked as expected on amd64 ;) Anyhow, just ranting - I understand the reasoning for doing it that way, but you should also see it from the x86 side where -msse could really mean a broken system, and maybe rethink your solution. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote: On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote: On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | No, we never spent years telling them not to use your so-called | CFLAGS hacks that are rather a proper usage of what the compiler | gives you. Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. Yes, we did. Were we wrong? Out of a purest point of view ... maybe. The problem was though that earlier gcc's was very bad at generating sse/sse2, and sometimes mmx code. Users being what they are though (ricers should say it all), they enabled every flag that sounded like it could make their old box two times faster. This included -msse, -msse2, etc. Which quite frankly produced bad code in many cases. So we told the users to not add any -m* flags, and let gcc do its job with the proper -march. So yeah, I can see that general use flags for cpu features might become more tedious with the many new modules of processors out there, but to say handle it by adding -msse, etc to CFLAGS, will surely if not on gcc4, but then on gcc3 systems just ask for trouble. And yes, I know you are saying that that is not exactly what you are proposing, but the users will see it as a clear passport to stick all those nice sounding flags just right back in, and then it will be too late to tell them its not proper thing to do when the bugs start flooding in. Dumb question, but what really blocks them from doing that now for x86 (for example)? Yes, can't enable certain flags for non x86/x86_64 arches, but the con you're pointing at exists now for the most part. I thought it was obvious, but apparently I overrated my writing skills :/ Anyhow, because now we can say 'don't do that!', or just close the bug as INVALID. If not, you can still try it, but the user might say we told him to enable sse/whatever like that. Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable tailored mmx/sse/whatever code, that should be working fine, as it was not gcc doing some shot in the dark at optimising, where if its enveloped with the CFLAGS, you cannot disable broken gcc optimisations, but enabled mmx/sse/whatever that should work on those older gcc's. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
Martin Schlemmer [EMAIL PROTECTED] writes: Stupid question though ... does the gcc test thingy list __3dNOW__ on nocona ? I would think that it does, as there is no -march=nocona (or whatever) yet. There is an -march=nocona (which I think was introduced in gcc 3.4) which works for both 32bit (x86) and 64bit (amd64) systems. At least on x86 it does NOT define __3dNOW__. Also, for x86 -march=prescott defines __SSE3__ whereas -march=pentium4 does not. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote: The more I think about the issue and the more I like the complete profiles for amd64 more than the other solutions. I don't even *want* to think of what this would be for x86. These are what I can think of, so far, with regards to different support on different chips. x86 (everything) i586 (everything i586-compatible) i586 + mmx (pentium-mmx) i686 (everything i686-compatible) i686 + mmx (pentium2+, athlon+) i686 + mmx + sse (pentium3+, athlon-xp+) i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+) i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some opteron) i686 + mmx + 3dnow (athlon+) i686 + mmx + 3dnow + sse (athlon-xp+) i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+) i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron) Now, some of those aren't able to be turned on solely via -march. I'm not arguing for or against this, since I haven't bothered to read the entire thread at the moment. I just wanted to point out that we would likely end up with 12 sub-profiles for all of our profiles to accomplish this. Even if we only started this going forward, x86 has a few profiles considered supported by Release Engineering that would need adjustment... x86/2006.1/desktop x86/no-nptl x86/no-nptl/2.4 This means it is now 36 profiles to support, if we dropped support on all profiles except for the new ones. Without having any sort of multiple inheritance available, this is really unmanageable. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
Chris Gianelloni wrote: [snip] This means it is now 36 profiles to support, if we dropped support on all profiles except for the new ones. Without having any sort of multiple inheritance available, this is really unmanageable. This is exactly the same reason why amd64 won't move to a per CPU subprofile. it might be a good idea for ppc, but not for us. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 07 Jul 2006 13:13:09 +0200 Simon Stelling [EMAIL PROTECTED] wrote: Curtis Napier wrote: I could find a million threads in the forums supporting what Ciaran is saying here. We have been told over and over and over until my head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. That's because CFLAGS=-msse currently doesn't do what the user would think it does. Which is the real problem, which we're solving with the change Diego suggested. Huh? What do you assume users think that CFLAGS=-msse does? I know some people get confused by the mmx/sse/whatever use flags, but I've never seen anybody assuming that CFLAGS determine if a patch should be applied/configure switch enabled. (I'm not arguing about the proposal itself here, just this argument is bullshit) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 7 Jul 2006 07:46:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. Since they have no impact on code generation, their presence doesn't impact comparisons with a pure upstream release. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Marius Mauch wrote: That's because CFLAGS=-msse currently doesn't do what the user would think it does. Which is the real problem, which we're solving with the change Diego suggested. Huh? What do you assume users think that CFLAGS=-msse does? I know some people get confused by the mmx/sse/whatever use flags, but I've never seen anybody assuming that CFLAGS determine if a patch should be applied/configure switch enabled. (I'm not arguing about the proposal itself here, just this argument is bullshit) Well, that was the best argument I could think of. I wasn't aware of the breakage in old compilers like gcc-3.3. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 15:53, Martin Schlemmer wrote: Check Chris Gianelloni's mail just now. For some compilers with some -march's on x86 it did not explicitly turn on some features (or maybe not to such a high extend). Uh no, I think he meant that for some borderline processors there's not a -march value, like for Athlon64 Revision D, that has sse3 support. In those cases you have to use -msse3 or whatever else to tell the compiler what to generate. So where say CFLAGS=-march=pentium3 would work, CFLAGS=-march=pentium3 -msse would fail to build, or generate bad code (segfaulting binaries). This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt. What you might incorrectly remember is -mfpmath=sse that is totally another thing, and dies usually on bad code anyway, and it's enabled by default on 64-bit CPUs just because on there the 80-bit limit for doubles is not pertinent anymore. I might seem an idiot, but I have enough experience to know what I'm talking about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse with -mfpmath=sse (or simply remember just what happened with GCC 3.2). A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 series improved, drastically. Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You cannot think that a flag or a support will always be broken because a release had it broken, you have to watch what you're doing to do it correctly. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLOzIWZ4SFL.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 16:03 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 15:53, Martin Schlemmer wrote: Check Chris Gianelloni's mail just now. For some compilers with some -march's on x86 it did not explicitly turn on some features (or maybe not to such a high extend). Uh no, I think he meant that for some borderline processors there's not a -march value, like for Athlon64 Revision D, that has sse3 support. In those cases you have to use -msse3 or whatever else to tell the compiler what to generate. So where say CFLAGS=-march=pentium3 would work, CFLAGS=-march=pentium3 -msse would fail to build, or generate bad code (segfaulting binaries). This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt. What you might incorrectly remember is -mfpmath=sse that is totally another thing, and dies usually on bad code anyway, and it's enabled by default on 64-bit CPUs just because on there the 80-bit limit for doubles is not pertinent anymore. As I pointed out on irc (to clarify), its still an issue even with gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from 4.0.1 I think. I might seem an idiot, but I have enough experience to know what I'm talking about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse with -mfpmath=sse (or simply remember just what happened with GCC 3.2). I did not imply this as far I know, and if it seemed that way, I can only say that I assumed that newer guys had the advantage of most ebuilds filtering or -mno-sse/whatever for known broken stuff (I know xorg was one with a few workarounds, also mozilla, etc at at some stage), so would not have noticed if sse/whatever broke something. That, and not being on the toolchain list you might not be familiar with the extend of the issue, with the fact that its different issues with different versions depending besides that on if its a i586, k6, p2, p3 or p4, etc. A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 series improved, drastically. Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You cannot think that a flag or a support will always be broken because a release had it broken, you have to watch what you're doing to do it correctly. I'd say only 4.0.1 and upwards really solved most of those issues, especially the long comming sse one. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: On Fri, 7 Jul 2006 07:46:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. That's the point. I mentioned being able to test whether your own software compiles with a pure GNU toolchain as a desire. Being able to see whether unofficial compiler options are used is not just a nice extra, but even necessary for that. Since they have no impact on code generation, their presence doesn't impact comparisons with a pure upstream release. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. Yes, but if GCC_SPECS is defined in the environment, I don't know enough about it to be sure that it interacts properly with -specs command-line options. Even if it works perfectly, though, the point remains that it does not belong in a USE=vanilla build. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 17:31, Martin Schlemmer wrote: As I pointed out on irc (to clarify), its still an issue even with gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from 4.0.1 I think. For what I know, the last issue was fixed with 3.3/3.4, so this sounds new to me. That said, I think this is up to now the only point that would make me rethink over this whole idea. For a pure simple and practical problem. I did not imply this as far I know, and if it seemed that way, I can only say that I assumed that newer guys had the advantage of most ebuilds filtering or -mno-sse/whatever for known broken stuff Probably, but never assume that gentoo is the first experience for everyone ;) I had my own share of GCC problems way before, and I remember how much shit GCC 3.2 created, 3.3 compared to it was a different order of magnitude: it worked. I'd say only 4.0.1 and upwards really solved most of those issues, especially the long comming sse one. Maybe because SSE wasn't that widespread in the past, I remember most issues to be related to MMX/3Dnow! extensions mainly, a part a big one with -msse that I thought dead with GCC 3.3, but I might be mistaken on that then, and I beg you pardon in that case. Of course there's the usual -mfpmath=sse that do cause problems on 32-bit systems (although it's the default on 64-bit). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpvc4mXWJpWb.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 7/7/06, Simon Stelling [EMAIL PROTECTED] wrote: That's because CFLAGS=-msse currently doesn't do what the user would think it does. Which is the real problem, which we're solving with the change Diego suggested. Well I certainly do *not* expect it to run configure with --enable-sse. -Richard -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: On Fri, 7 Jul 2006 07:46:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. That's the point. I mentioned being able to test whether your own software compiles with a pure GNU toolchain as a desire. Being able to see whether unofficial compiler options are used is not just a nice extra, but even necessary for that. Since they have no impact on code generation, their presence doesn't impact comparisons with a pure upstream release. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. Yes, but if GCC_SPECS is defined in the environment, I don't know enough about it to be sure that it interacts properly with -specs command-line options. Even if it works perfectly, though, the point remains that it does not belong in a USE=vanilla build. Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 13:22, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 17:31, Martin Schlemmer wrote: As I pointed out on irc (to clarify), its still an issue even with gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from 4.0.1 I think. For what I know, the last issue was fixed with 3.3/3.4, so this sounds new to me. i dont think the segfaults applied to the 3.3 branch as the code was new to the 3.4 branch the issues were worked around in 3.4.5 via specs filtering, 3.4.6 included one fix and i backported the other, 3.4.4 and older i dont know the status of (but i'd be inclined to push people to 3.4.6 anyways and cut 3.4.[0-4]) That said, I think this is up to now the only point that would make me rethink over this whole idea. For a pure simple and practical problem. doesnt seem like a valid roadblocker to me ... but i see the toolchain as something higher up guys shouldnt have to worry/think about; fix the gcc bugs, dont work around them in ebuilds -mike pgprKNDIDEP0b.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. You use the Gentoo modified one. Regardless of what USE= flags you have enabled you are still getting Gentoo behaviors. Think vanilla-sources are pure? They are not. They get patched as well with the minimal amount of patches required. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On 7/7/06, Ned Ludd [EMAIL PROTECTED] wrote: You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. LFS http://www.linuxfromscratch.org/lfs has always been based on a vanilla toolchain. Never ran into issues. Of course, we do apply upstream patches when needed. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Friday 07 July 2006 12:53, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. That's the point. I mentioned being able to test whether your own software compiles with a pure GNU toolchain as a desire. Being able to see whether unofficial compiler options are used is not just a nice extra, but even necessary for that. as i said, this really is a non-issue considering SSP has been integrated into mainline gcc Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. Yes, but if GCC_SPECS is defined in the environment so what's stopping you from undefining it ? -mike pgpduWyurTvdI.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 Option 3: Enlighten me. I have explained why I feel the way I do, so if there's some big flaw in my understanding, please do correct it. You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. You use the Gentoo modified one. Regardless of what USE= flags you have enabled you are still getting Gentoo behaviors. Gentoo isn't the only system I use. I have used vanilla GCC + build fixes, and I have been able to get a working system with it. So I'm still waiting on your explanation of how it is unusable. Think vanilla-sources are pure? They are not. They get patched as well with the minimal amount of patches required. Interesting, and I did not know that, but looking at kernel-2.eclass (which appears to be the only thing doing any modifying), the modifications are all build system fixes, and won't affect the generated kernel. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Friday 07 July 2006 01:46, Harald van Dijk wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. it was not ignored, i told you the answer was no ... i listened to your request and then i evaluated the situation and deemed at the time to go with what we have now. see how your usage of ignored is incorrect here ? as Kevin pointed out, the stubs do not affect code generation so i preferred to keep users from breaking themselves also, at the time, i told you you could easily work around the stub situation by simply deleting them: rm /usr/portage/sys-devel/gcc/files/stubs/* and then add sys-devel/gcc/files/stubs/ to your rsync exclude list once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply the stubs when USE=nossp as the majority of users will no longer be in the situation i referred to earlier since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) you never pointed that patch out to me nor did i notice it, so i dont really see how you could have expected this to be fixed already i'll update cvs when i get a chance -mike pgpC3qwT1Y3nm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 2006.07.07 14:27, Chris Gianelloni wrote: On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote: The more I think about the issue and the more I like the complete profiles for amd64 more than the other solutions. I don't even *want* to think of what this would be for x86. These are what I can think of, so far, with regards to different support on different chips. x86 (everything) i586 (everything i586-compatible) i586 + mmx (pentium-mmx) i686 (everything i686-compatible) i686 + mmx (pentium2+, athlon+) i686 + mmx + sse (pentium3+, athlon-xp+) i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+) i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some opteron) i686 + mmx + 3dnow (athlon+) i686 + mmx + 3dnow + sse (athlon-xp+) i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+) i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron) [snip] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux Chris, Its east to make worse too. There's mmxext and 3dnowext too. Regards, Roy Bamford -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 01:46, Harald van Dijk wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. it was not ignored, i told you the answer was no ... i listened to your request and then i evaluated the situation and deemed at the time to go with what we have now. see how your usage of ignored is incorrect here ? Actually, you did ignore. The below text refers to something older. as Kevin pointed out, the stubs do not affect code generation so i preferred to keep users from breaking themselves also, at the time, i told you you could easily work around the stub situation by simply deleting them: rm /usr/portage/sys-devel/gcc/files/stubs/* and then add sys-devel/gcc/files/stubs/ to your rsync exclude list Yes, you told me this, before USE=vanilla even existed for gcc. When there's no implicit claim that installed GCC is official GCC, it's much less of a problem that it's not. Back then, I never complained that the installed GCC wasn't the official GCC, only that (a manually installed) official GCC wasn't a supported compiler. And I did not ask for an official way to disable the stub patches then, I only asked how I could do it for my own system. once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply the stubs when USE=nossp as the majority of users will no longer be in the situation i referred to earlier Thanks. I hope that if a similar situation comes up, ebuilds will use test-flags instead of assuming the option is valid, though. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) you never pointed that patch out to me nor did i notice it, so i dont really see how you could have expected this to be fixed already I didn't point that out to you, I pointed that out to another of the toolchain guys. I'm not completely sure who, but I think it was Halcy0n. i'll update cvs when i get a chance Thanks again. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Friday 07 July 2006 17:53, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 01:46, Harald van Dijk wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. it was not ignored, i told you the answer was no ... i listened to your request and then i evaluated the situation and deemed at the time to go with what we have now. see how your usage of ignored is incorrect here ? Actually, you did ignore. The below text refers to something older. ignored *what* then ? you requested USE=vanilla control ssp, i said no and i'll add support for USE=nossp ... you requested USE/stub control, i said no, go delete the stubs i dont see what else you're referring to ... be specific, vague claims only lead to wasting of both our times I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) you never pointed that patch out to me nor did i notice it, so i dont really see how you could have expected this to be fixed already I didn't point that out to you, I pointed that out to another of the toolchain guys. I'm not completely sure who, but I think it was Halcy0n. all bets are off now then ... with Halcy0n leaving us, that leaves me as the only person maintaining the toolchain (there are few devs who contribute fixes for their ports and it helps out a ton, but that doesnt really count as being fully responsible for the toolchain packages). no more making retroactive claims when i wasnt involved ;P i trust azarah to help out, but he's been busy in real life so i havent/wont ask him to contribute since i know he cannot (even if he wants to) -mike pgpo5gBd7Gxpr.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote: ignored *what* then ? you requested USE=vanilla control ssp, i said no and i'll add support for USE=nossp ... you requested USE/stub control, i said no, go delete the stubs USE=nossp existed before USE=vanilla did. To be sure I'm remembering right, I checked `cvs log toolchain.eclass`. In order, probably skipping a few steps: 1- No SSP 2- Choice between SSP [USE=-nossp] and stub patches [USE=nossp]. USE=vanilla didn't exist. 3- Choice between SSP [USE=-nossp -vanilla], stub patches [USE=nossp -vanilla], and nothing [USE=vanilla] 4- Choice between SSP [USE=-nossp] and stub patches [USE=nossp] USE=vanilla exists but has no effect on SSP. It was during 2 that I asked for a way to disable stub patches for myself (and not as part of the official ebuild), and you said to delete them. That was good enough for me during 2. We are now in 4. i dont see what else you're referring to ... be specific, vague claims only lead to wasting of both our times I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. all bets are off now then ... with Halcy0n leaving us, that leaves me as the only person maintaining the toolchain (there are few devs who contribute fixes for their ports and it helps out a ton, but that doesnt really count as being fully responsible for the toolchain packages). I'll keep that in mind, I wasn't aware that the other toolchain guys handle specific parts of the toolchain packages only. Even if I disagree with some specific decisions, nice job overall, then. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Friday 07 July 2006 19:04, Harald van Dijk wrote: I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. well i cant answer it if you havent asked it ... me not answering you on irc when i'm not around does not constitute being ignored and anyone who relies on irc in this respect really needs to learn more about irc the log message looks pretty clear to me, i dont see this hidden message you're referring to the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp whereas before you only had the option of: gentoo patches + ssp vanilla + nossp like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... this is also the reason i havent added USE=vanilla to glibc, too many users would simply break their boxes -mike pgpi4ug0sMzuq.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: [Snip] Note that you need to set your CFLAGS corretly or it will, by default, tell you that everything is disabled. Thoughts? Comments? The one advantage of using USE flags for this is that the support can be controlled very easily on a per-package basis. CFLAGS is much more of a system-wide setting. Are there examples where we'd want to have these CPU feature flags enabled for one package, but disabled for another (for performance or stability reasons)? If this is an ability we no longer need, then I like your idea. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Thought: I like it :)
On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
So, I've been drafting this up in my blog[1], and it is a simple way to
replace the CPU feature useflags. Let's try to summarise:
Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
the tree, almost never used to get new dependencies, but usually used to
supply econf switches.
This works as long as the user enable the flags, but for AMD64 the story was,
until now, that we simply enabled them when they worked, because we had some
minimum support available. Unfortunately this became a problem with the
introduction of nocona, because that is an amd64-like system but with no
3dnow. And there is the problem that sse3 is supported only in later versions
of Athlon64 and so on.
To try to clean up this mess, and to make it simpler to work in
cross-compilation, I thought of using the definitions created by the C
Preprocessor (CPP) by default for the given CFLAGS. Basically when
using -march=athlon64, the preprocessor will enable a few definitions that
tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that
around, we can use it to know if it's the case of enabling something or not.
This is customisable by the user by setting the CFLAGS themselves. If one does
not want MMX instructions to be generated, but still want the rest of
Athlon64 optimisations, it's simply the matter of
using -march=athlon64 -mno-mmx.
So, rather than the functions proposed in [1], I've sampled today the
following function:
has_cpuset() {
local def hasfeat
while [[ -n $1 ]]; do
case $1 in
mmx)
def=__MMX__ ;;
3dnow)
def=__3dNOW__ ;;
3dnowex)
def=__3dNOW_A__ ;;
sse)
def=__SSE__ ;;
sse2)
def=__SSE2__ ;;
sse3)
def=__SSE3__ ;;
altivec)
def=__ALTIVEC__ ;;
*)
ewarn Instruction set $1 not supported.
die Instruction set not supported.
esac
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} ||
hasfeat=no
shift
done
if [[ ${hasfeat} == no ]]; then
return 1
else
return 0
fi
}
that can be tested easily with the following code:
yesno() {
if $@; then
echo yes
else
echo no
fi
}
echo Does it have 3dnow mmx sse2?
yesno has_cpuset 3dnow mmx sse2
echo Does it have mmx sse sse3?
yesno has_cpuset mmx sse sse3
echo Does it have altivec?
yesno has_cpuset altivec
Note that you need to set your CFLAGS corretly or it will, by default, tell
you that everything is disabled.
Thoughts? Comments?
SPARC team: I'd like to know if VIS does a similar thing, would make simpler
for instance its handling in xine-lib ebuild.
[1]
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
--
Ioannis Aslanidis
deathwing00[at]gentoo.org 0xB9B11F4E
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 13:40, Donnie Berkholz wrote: How will you handle non-gcc compilers? We don't support any, to start with. But ICC I'm pretty sure behaves like GCC, and whatever else we'd go by supporting should likely do the same. But again, we don't support any, so it's up to whoever wants to support them to find a solution, I'd say. Well, there are enough in the tree that you should at least make sure they don't completely break and error out when passing them invalid flags, even if you fail to auto-enable mmx/sse/whatever. You could do if [[ $(tc-getCC) != *gcc* ]] or something... Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 12:52:29 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags | present in the tree, almost never used to get new dependencies, but | usually used to supply econf switches. | | This works as long as the user enable the flags, but for AMD64 the | story was, until now, that we simply enabled them when they worked, | because we had some minimum support available. Unfortunately this | became a problem with the introduction of nocona, because that is an | amd64-like system but with no 3dnow. And there is the problem that | sse3 is supported only in later versions of Athlon64 and so on. The other option here... Is to rename the x86 flags to x86_mmx, x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not really the same as the x86 flags. There's probably some USE_EXPAND trickery that can be used here... CPU_FEATURE_X86=mmx sse - cpu_feature_x86_mmx etc might be cleaner? | To try to clean up this mess, and to make it simpler to work in | cross-compilation, I thought of using the definitions created by the | C Preprocessor (CPP) by default for the given CFLAGS. Basically when | using -march=athlon64, the preprocessor will enable a few definitions | that tells the availability of MMX, 3dNOW, SSE and so on... if we | wrap that around, we can use it to know if it's the case of enabling | something or not. This is customisable by the user by setting the | CFLAGS themselves. If one does not want MMX instructions to be | generated, but still want the rest of Athlon64 optimisations, it's | simply the matter of using -march=athlon64 -mno-mmx. Sounds rather flaky and unreliable... | SPARC team: I'd like to know if VIS does a similar thing, would make | simpler for instance its handling in xine-lib ebuild. VIS is present on all v9 CPUs. GCC's VIS support, however, sucks. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 12:52:29 +0200
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
So, I've been drafting this up in my blog[1], and it is a simple way
to replace the CPU feature useflags.
[...]
To paraphrase the idea - use the compiler's knowledge of the target
processor to select cpu-specific code.
I like the idea a lot. To my mind, the sse/sse2/3dnow etc should be
derived from the target arch, which is what you're doing with the
compiler's macro definitions. This could easily be done by configure
scripts; perhaps it would be a good idea to look into writing some
autoconf macros.
re. hardened - all we ever need, is to be able to force a package to
fall back to it's portable C implementation when the asm code breaks
PIC (which is independent of whether it uses mmx, sse etc) or
generates code at runtime. I think most packages provide this, as it's
useful to the developer to compare the C implementation with
accelerated asm versions easily.
re. Donnie's point about non-gcc compilers - handling these can be
hidden in the has_cpuset() function. They can always be determined
from the target arch (combination of ARCH and -march or equivalent
CFLAGS). The suggested code already does the worst-case fall-back, as
it responds 'no' if the compiler doesn't support -dM or doesn't define
the relevant macro.
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} ||
hasfeat=no
The '2/dev/null' is the critical element for that.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote: Sounds rather flaky and unreliable... Sounds rather vague and without arguments. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpBJXhfBv3GB.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote: This could easily be done by configure scripts; perhaps it would be a good idea to look into writing some autoconf macros. Actually there's little need, you can simply use the #ifdef in the code, unless you have separated source files for MMX, SSE and so on (that might as well be), but even then, it's really trivial to autoconf. The problem is that many autoconf scripts do it the other way around, by forcing -march or -mcpu (that is deprecated by -mtune too) deduced from /proc/cpuinfo. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwZMttvPvt1.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 14:44:22 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote: This could easily be done by configure scripts; perhaps it would be a good idea to look into writing some autoconf macros. Actually there's little need, you can simply use the #ifdef in the code, unless you have separated source files for MMX, SSE and so on (that might as well be), but even then, it's really trivial to autoconf. Yep; I've seen that several packages do it the #ifdef way, which is ideal as we don't need to do set any configure stuff at all then (I guess those packages don't have configure options/use flags to select between mmx, sse etc anyway). The problem is that many autoconf scripts do it the other way around, by forcing -march or -mcpu (that is deprecated by -mtune too) deduced from /proc/cpuinfo. Ooh; that's nasty. Let me guess - mplayer ... yeah; what a surprise. Presumably we disable such trickery if we see it, as it makes the target code depend on the build system which is obviously wrong - at least for Gentoo. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: Well, you're assuming that a) everyone's using a C compiler, b) that gcc has the slightest clue what it's doing, c) that the user has no problem using nasty hacks to regain control, d) that this information is only needed at compile time, e) that various gcc internal definitions won't change... You're adding a lot of complexity, and thus room for very weird breakages, to something that doesn't need it. as for... b) You kind of have to assume that when running a system that was compiled from ground up with gcc c) This is not about regaining control. Currently, users who want to cross-compile are screwed and need nasty use.mask-hacks to not end up with broken binaries. The inability to provide per-package CFLAGS is a missing feature in portage, it's got nothing to do with this issue. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 16:03:47 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | Well, you're assuming that a) everyone's using a C compiler, b) that | gcc has the slightest clue what it's doing, c) that the user has no | problem using nasty hacks to regain control, d) that this | information is only needed at compile time, e) that various gcc | internal definitions won't change... You're adding a lot of | complexity, and thus room for very weird breakages, to something | that doesn't need it. | | as for... | | b) You kind of have to assume that when running a system that was | compiled from ground up with gcc Not really true. GCC can be quite happily wrong about what your CPU could support, so long as it's not told to use it. This happens with VIS, for example. | c) This is not about regaining control. Currently, users who want | to cross-compile are screwed and need nasty use.mask-hacks to not end | up with broken binaries. The inability to provide per-package CFLAGS | is a missing feature in portage, it's got nothing to do with this | issue. You can do it through bashrc. But then, if this is about working around Portage's annoying lack of sane cross compile handling, why not put a little effort into fixing it properly rather than a lot of effort into making the tree more complicated? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
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
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 17:09:42 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | You can do it through bashrc. But then, if this is about working | around Portage's annoying lack of sane cross compile handling, why | not put a little effort into fixing it properly rather than a lot | of effort into making the tree more complicated? | | Err, I think you're mixing up different things. How should portage be | able to do sane cross compiling if you control the instruction sets | through use flags which are blocked in profiles the build system is | using? That's just it. You shouldn't be using the wrong profile when compiling things. | In fact, moving away from use flags over to the real(TM) | solution is a step towards fixing the issue. Also, it doesn't make | the tree more complicated. It is far more intuitive that supported | instruction sets are used if the user doesn't explicitly wish not to | than having some strange use flags that don't mean what they're named | like. That's like saying well we should just link against whatever's available, it's far more intuitive than letting the user decide. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote: On Thu, 6 Jul 2006 12:52:29 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags | present in the tree, almost never used to get new dependencies, but | usually used to supply econf switches. | | This works as long as the user enable the flags, but for AMD64 the | story was, until now, that we simply enabled them when they worked, | because we had some minimum support available. Unfortunately this | became a problem with the introduction of nocona, because that is an | amd64-like system but with no 3dnow. And there is the problem that | sse3 is supported only in later versions of Athlon64 and so on. The other option here... Is to rename the x86 flags to x86_mmx, x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not really the same as the x86 flags. There's probably some USE_EXPAND trickery that can be used here... CPU_FEATURE_X86=mmx sse - cpu_feature_x86_mmx etc might be cleaner? I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
Ciaran McCreesh wrote:
You can do it through bashrc. But then, if this is about working around
Portage's annoying lack of sane cross compile handling, why not put a
little effort into fixing it properly rather than a lot of effort into
making the tree more complicated?
Err, I think you're mixing up different things.
How should portage be
able to do sane cross compiling if you control the instruction sets
through use flags which are blocked in profiles the build system is
using?
That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES=$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print
$2}' | sort -u)
mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
rm -f make.profile
ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
touch make.conf
ls -ld $(readlink -f make.profile)
emerge --info
done
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ned Ludd wrote:
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Neither has USE=-*, but we don't actively try to break it. =) As long as
this doesn't cause all non-gcc compilers to immediately die, I don't
care if they miss out on auto-mmx or whatever.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: So, I've been drafting this up in my blog[1], and it is a simple way to replace the CPU feature useflags. My counterproposal: - keep the useflags - add an eclass with the guessing logic from gcc - add an useflag to let people decide the priority between gcc decisions or useflag decisions. So: - don't have to wait for per package cflags - have the hopefully best results if you don't really care (gcc guess) - if you care do whatever you want, eg: turn cflags for vector units AND autovectorized and shut down hand vectorized code (yes it could be dump if the handmade stuff isn't wrong) Sounds fair or I'm missing something? -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Had a rough scan through the tree; there are 73 packages that make direct use of mmx, sse*, 3dnow or altivec in IUSE (list below), excluding gcc itself. They also appear in the mythtv-plugin eclass so presumably some of media-plugins/myth* (11 packages) are also affected. I don't know if altivec is as clearly determined from the target arch; perhaps the ppc people could chime in. Clearly most are in media-* categories, so that would be a good place to start :) app-crypt/johntheripper dev-lang/pike dev-lang/squeak dev-libs/DirectFB dev-libs/DirectFB-extra dev-php5/eaccelerator games-emulation/dgen-sdl games-emulation/visualboyadvance games-emulation/xmame games-emulation/xmess games-engines/exult media-gfx/gimp media-gfx/inkscape media-gfx/optipng media-libs/allegro media-libs/flac media-libs/gdk-pixbuf media-libs/imlib2 media-libs/libfame media-libs/libggi media-libs/libmovtar media-libs/libmpeg3 media-libs/libquicktime media-libs/mlt media-libs/sdl-gfx media-libs/smpeg media-libs/speex media-libs/xvid media-plugins/eq-xmms media-plugins/vdr-softdevice media-plugins/xmms-mpg123 media-sound/ardour media-sound/audacious media-sound/fluidsynth media-sound/jack-audio-connection-kit media-sound/mpg123 media-sound/noxmms media-sound/terminatorx media-sound/xmms media-sound/zynaddsubfx media-tv/mythtv media-tv/xawtv media-tv/xdtv media-video/avidemux media-video/cinelerra-cvs media-video/dirac media-video/dxr3player media-video/effectv media-video/fame media-video/ffmpeg media-video/gephex media-video/mjpegtools media-video/mpeg4ip media-video/mplayer media-video/ogle media-video/recmpeg media-video/transcode media-video/vlc media-video/xmovie net-irc/xchat net-irc/xchat-gnome net-misc/asterisk sci-chemistry/gromacs sci-libs/acml sci-libs/fftw x11-base/xorg-x11 x11-libs/evas x11-libs/libast x11-misc/rss-glx x11-terms/eterm x11-themes/polymer x11-wm/afterstep x11-wm/metisse -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
Well, you're assuming that
Properly listing, what an arcane science.
a) everyone's using a C compiler,
No, I assume that everyone is using a compiler. You cannot have a C++ compiler
without a C compiler. The first person I see that sets CXXFLAGS but not
CFLAGS I'm personally going to give him the doesn't have a clue prize.
b) that gcc has the slightest clue what it's doing,
No, I assume that gcc has a big clue about which capabilities are available to
the -march switch. I might be assuming that users have a clue on what they
are doing, but that's an assumption I do have to do, or I shouldn't be
working on Gentoo but on Debian, which seems pretty good at optimising for
i386 still.
c) that the user has no problem using nasty hacks to regain control,
Where regain control is doing something that could have done before but
made actually no sense to do before. And the bashrc thing is not a big nasty
hack, works quite well for me.
d) that this information is only needed at compile time,
Well of course use flags are available at runtime for the packages built to
know, this is perfectly logic of you.
You really was getting out of arguments, don't you?
If I have to enable a configure switch I need it only at buildtime. If it has
to be known at runtime there's the cpuid function!
e) that various gcc internal definitions won't change...
It's like assuming that gcc will always output the correct hello world for
int main() {
printf(Hello, world!\n);
return 0;
}
If it does change those values, it's going to be a killer for way more than
just Portage.
You're adding a lot of complexity, and thus
room for very weird breakages, to something that doesn't need it.
You're not exposing any of such breakages, I find it to reduce complexity to
users that cannot try to enable SSE3 on an Athlon-TBird system.
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpBazG9uNTou.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 17:33, Ned Ludd wrote: I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpiOpxvI3HJS.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:02, Luca Barbato wrote: - if you care do whatever you want, eg: turn cflags for vector units AND autovectorized and shut down hand vectorized code (yes it could be dump if the handmade stuff isn't wrong) In the case you need to shut down the hand vectorised code, it has to be done always, not selected by users. It should be transparent for them, and if the code is wrong, just punt it entirely. Or fix it, your call. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppcbVBjcpSV.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 17:33, Ned Ludd wrote: I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. All together as in across the board? Or simply for the 1 pkg in question? I seriously hope you are not suggesting across the board cuz that would make me laugh at you for a good hour solid. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Kevin F. Quinn wrote: Had a rough scan through the tree; there are 73 packages that make direct use of mmx, sse*, 3dnow or altivec in IUSE (list below), excluding gcc itself. They also appear in the mythtv-plugin eclass so presumably some of media-plugins/myth* (11 packages) are also affected. I don't know if altivec is as clearly determined from the target arch; perhaps the ppc people could chime in. it is Clearly most are in media-* categories, so that would be a good place to start :) yes lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 17:33, Ned Ludd wrote: I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. Depending on who wrote the altivec part of a program you may like to disable it since works just on macosx /me still would rather have both systems in place. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:58, Ned Ludd wrote: All together as in across the board? Or simply for the 1 pkg in question? For the package in question of course. Do you think I'm an idiot? Seriously? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpTaMpZzqze8.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 18:58, Ned Ludd wrote: All together as in across the board? Or simply for the 1 pkg in question? For the package in question of course. Do you think I'm an idiot? Seriously? Well. Sorry but there is very little we can assume these days. Just when you think people know what they are doing along comes some hair brained idea that sound ok on the surface but can cause lots of fun problems. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 18:43:11 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
| Well, you're assuming that
| Properly listing, what an arcane science.
Perhaps I should've written a Java + XML app that automatically formats
messages according to what the reader probably wants to see.
| a) everyone's using a C compiler,
|
| No, I assume that everyone is using a compiler. You cannot have a C++
| compiler without a C compiler. The first person I see that sets
| CXXFLAGS but not CFLAGS I'm personally going to give him the doesn't
| have a clue prize.
And for a single compile?
| b) that gcc has the slightest clue what it's doing,
|
| No, I assume that gcc has a big clue about which capabilities are
| available to the -march switch. I might be assuming that users have a
| clue on what they are doing, but that's an assumption I do have to
| do, or I shouldn't be working on Gentoo but on Debian, which seems
| pretty good at optimising for i386 still.
And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
| c) that the user has no problem using nasty hacks to regain control,
|
| Where regain control is doing something that could have done
| before but made actually no sense to do before. And the bashrc thing
| is not a big nasty hack, works quite well for me.
No no. Where regain control means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.
| d) that this information is only needed at compile time,
|
| Well of course use flags are available at runtime for the packages
| built to know, this is perfectly logic of you.
Uh. USE flags are available at DEPEND time.
| You really was getting out of arguments, don't you?
No, you're just not thinking this through.
| If I have to enable a configure switch I need it only at buildtime.
| If it has to be known at runtime there's the cpuid function!
And at the metadata phase?
| e) that various gcc internal definitions won't change...
| It's like assuming that gcc will always output the correct hello
| world for
|
| int main() {
| printf(Hello, world!\n);
| return 0;
| }
|
| If it does change those values, it's going to be a killer for way
| more than just Portage.
Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
It can and does change with different GCC releases. I know there've been
GCC changes on sparc to those kinds of defines to try to play nice with
certain other compilers...
| You're adding a lot of complexity, and thus
| room for very weird breakages, to something that doesn't need it.
|
| You're not exposing any of such breakages, I find it to reduce
| complexity to users that cannot try to enable SSE3 on an Athlon-TBird
| system.
You're trying to guess what the user wants based upon hairy magic,
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?), and all because you aren't aware
of how to cross compile correctly.
Now, please go back to justifying this thing on any merits it may have,
rather than playing the Go and use Debian!!!! card.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
And for a single compile?
I always leave the two of them in sync, even C++ apps might have parts
building CFLAGS. In case you know you're going to use only C++ is not
difficult to use
CFLAGS=${CXXFLAGS} has_cpuset 3dnow
don't you think?
And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
Okay, maybe VIS handling is broken. But we can rely pretty safely on x86,
amd64 and PPC gcc to know the table of arches and extensions supported.
Remember that I asked to talk with SPARC team for VIS just because I only
know about the other three arches.
No no. Where regain control means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.
Find me a reason to do that, a part for broken MMX code that should be
disabled on the ebuild itself already.
Uh. USE flags are available at DEPEND time.
If you talk about the nasm dependency, then it is rare, most of the MMX
support is inline in C sources anyway.
And at the metadata phase?
Should be already transparent or something is strange. nasm is simpler to add
the dependency for x86, there is really few people not enabling mmx already.
Yes it is a bit of regression, but for a small percentage of users, while
there's more safety for many other people.
Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
This ain't no magic. The magic is in the _CODE_ that GCC creates, but not in
the _DEFINES_ that GCC emits.
You're trying to guess what the user wants based upon hairy magic,
No, about their chosen architecture.
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?)
The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex,
sse, sse2)
The user asks for G3 support? They get G3 (nothing)
The user asks for Pentium4 support? They get what they want (mmx, sse, sse2,
sse3 in case)
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpEMEE1Ith5N.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 20:07:00 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
| And for a single compile?
|
| I always leave the two of them in sync, even C++ apps might have
| parts building CFLAGS. In case you know you're going to use only C++
| is not difficult to use
|
| CFLAGS=${CXXFLAGS} has_cpuset 3dnow
|
| don't you think?
Ah yes, yet more added complexity that's going to be forgotten and that
will lead to weird breakages.
Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
you want your C compiler to work and produce vaguely sane code.
| And your assumption would be wrong. I can assure you that relying
| upon -march doing anything sensible with __MAGIC__ is entirely
| unsafe. Go and look at the VIS handling if you want a perfect
| example.
|
| Okay, maybe VIS handling is broken. But we can rely pretty safely on
| x86, amd64 and PPC gcc to know the table of arches and extensions
| supported. Remember that I asked to talk with SPARC team for VIS just
| because I only know about the other three arches.
Not really. The __MAGIC__ is subject to change whenever any GCC person
feels like it. It also doesn't work in cases where people have one of
those nasty corner case CPUs (such as the 4m, which is not an m and not
really a 4 either, or the USIV, or the r8k) that's best off with a weird
march.
| No no. Where regain control means the user has to screw around
| with nasty hacks and pray, rather than setting a well defined,
| specific variable.
|
| Find me a reason to do that, a part for broken MMX code that should
| be disabled on the ebuild itself already.
Well that's kinda the point. Since ebuild developers don't have access
to every kind of CPU, relying upon the ebuilds getting it right isn't a
very good idea.
| Uh. USE flags are available at DEPEND time.
|
| If you talk about the nasm dependency, then it is rare, most of the
| MMX support is inline in C sources anyway.
'most'?
| And at the metadata phase?
|
| Should be already transparent or something is strange. nasm is
| simpler to add the dependency for x86, there is really few people not
| enabling mmx already. Yes it is a bit of regression, but for a small
| percentage of users, while there's more safety for many other people.
Since when was Gentoo about covering up for idiots who can't get their
ricing correct at the expense of those who know what they're doing?
| Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the
| contrary.
|
| This ain't no magic. The magic is in the _CODE_ that GCC creates, but
| not in the _DEFINES_ that GCC emits.
Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
them around now and again for compatibility with other compilers.
| You're trying to guess what the user wants based upon hairy magic,
| No, about their chosen architecture.
|
| rather than doing what the user says (aren't you always yelling at
| upstreams for doing that?)
|
| The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
| 3dnowex, sse, sse2)
| The user asks for G3 support? They get G3 (nothing)
| The user asks for Pentium4 support? They get what they want (mmx,
| sse, sse2, sse3 in case)
Setting CFLAGS and praying is not asking for something. Setting a
MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 20:42:27 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| Not really. The __MAGIC__ is subject to change whenever any GCC
| person feels like it.
|
| It's not magic. But if you think that going by that trick you can
| magically turn me in agreeing with you, good luck.
They're a bunch of arbitrary somethings that may or may not be defined
based upon whatever upstream feels like doing to the compiler this
week. It's not like the behaviour of your hello world app, which is
defined by international standards.
| It also doesn't work in cases where people have one of
| those nasty corner case CPUs (such as the 4m, which is not an m and
| not really a 4 either, or the USIV, or the r8k) that's best off
| with a weird march.
|
| That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are
| for.
Which is a horrible hack, and far less elegant than just having a
frickin' variable telling ebuilds what to do.
| Well that's kinda the point. Since ebuild developers don't have
| access to every kind of CPU, relying upon the ebuilds getting it
| right isn't a very good idea.
|
| The MMX code either works or don't. Not much to think about different
| CPUs.
And in cases where the choice is an SSE routine or an MMX routine or a
C routine? It's not very likely that all possibilities will get tested
by ebuild devs.
| Since when was Gentoo about covering up for idiots who can't get
| their ricing correct at the expense of those who know what they're
| doing?
|
| Again, I don't see any loss for who knows what he's doing.
Because you carefully snipped it out of your reply. You said yourself
that it's a regression.
| Sure it's magic. The __DEFINES__ aren't reliable. The GCC people
| change them around now and again for compatibility with other
| compilers.
|
| Yeah _some_ of them are unreliable. Not those tho, as they are just
| the same on all the GCC we support. And I doubt that next week GCC
| 4.1.2 changes them around.
Oh, you doubt, do you? Very reassuring.
| Setting CFLAGS and praying is not asking for something. Setting a
| MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
|
| And if you know what your CPU does, is it that difficult to tell the
| compiler to use them?
Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
remembers that for years we've been screaming at users for doing just
that.
CFLAGS is not a variable that should be used to control things. It has
a specific purpose, which is providing flags to the compiler that
should be used when compiling C programs. You're trying to give it a
new unrelated meaning. This is bad even if it were not for all the
nasty side cases and added complexity.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
Well, there are enough in the tree
There are ebuilds for non-gcc compilers. There's no support in using them for
anything like building stuff. Let's think to all the append-flags there are
in the tree.
`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)
This is not going to make the support any less working. There's
no project maintaining support for icc and the like.
When the answer is make icc not suck even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.
that you should at least make sure
they don't completely break and error out when passing them invalid
flags,
Uhm, If you look at the function itself you can see that I drop the stderr
output and I just care about the other part. The flags used are the ones set
by the user with the exclusion of -E -dM that are, afaik, standard unix
compiler options like -c and -o..
-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - /dev/null 21 EOF
#if !($macro)
#error
#endif
EOF` and check $CC's return value. If $macro is not defined, or is
defined to something like 0, preprocessing won't succeed, and $CC will
return nonzero.
if the compiler does not support those,
it's unlikely it can actually do anything useful in Gentoo.
And anyway it cannot break, it will just report that no extensions are
available.
That's sane behaviour regardless. :)
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
--
gentoo-dev@gentoo.org mailing list
Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 21:42:20 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | On Thu, 6 Jul 2006 21:06:18 +0200 | Harald van Dijk [EMAIL PROTECTED] wrote: | The GNU toolchain is not supported by Gentoo, and in fact gets | actively broken with unsupported command-line options. Only the GNU | toolchain as modified by Gentoo's toolchain guys is supported, | unfortunately. | | What exactly is it about the toolchain supplied with Gentoo that | causes you problems? Selective and partial backporting of patches that leads to the C++ standard library code getting broken? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: On Thu, 6 Jul 2006 20:42:27 +0200 Diego 'Flameeyes' Pettenò | Setting CFLAGS and praying is not asking for something. Setting a | MY_X86_CPU_DOES_THIS_MKAY variable is asking for something. | | And if you know what your CPU does, is it that difficult to tell the | compiler to use them? Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one remembers that for years we've been screaming at users for doing just that. I could find a million threads in the forums supporting what Ciaran is saying here. We have been told over and over and over until my head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. To change this behavior now after all this time would be crazy IMHO. signature.asc Description: OpenPGP digital signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Harald van Dijk wrote: On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. Isn't this why gcc et al support the vanilla USE flag? -Steve -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 04:03:26PM -0400, Stephen P. Becker wrote: Harald van Dijk wrote: On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. Isn't this why gcc et al support the vanilla USE flag? Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:02, Curtis Napier wrote: Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. Well it's not totally right. Putting them in CFLAGS, when using -march, is redundant, pure and simple. -march=athlon64 -msse -msse2 -mmmx -m3dnow -m3dnowex would be equivalent of -march=athlon64 If you have a new Athlon64 that supports SSE3, using -march=athlon64 -msse3 is not only legit, but also (in my opinion at least) suggested. GCC can improve heavily if it knows what it has to do. The problem is that people think that using -march=pentium3 -mmmx will bring them more acceleration, while this isn't true. So I would suggest anybody wanting to comment on these issue to know the difference of using mmx in useflag and -mmmx in CFLAGS at the moment. And then evaluate the change in behaviour. Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the times, as it's not an i686 but at the same time it has MMX support. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppXtMqRbnIf.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 20:56:31 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: Selective and partial backporting of patches that leads to the C++ standard library code getting broken? Obviously not an issue. Noone uses C++ anyway. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:13:11 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | So I would suggest anybody wanting to comment on these issue to know | the difference of using mmx in useflag and -mmmx in CFLAGS at the | moment. And then evaluate the change in behaviour. Well, if you're playing that game, I'd suggest that anybody wanting to make proposals on this issue should know what CFLAGS is and understand how it is nothing other than a set of flags that are passed to the compiler when compiling a C program, and then evaluate the impact of subverting such a variable for nefarious purposes. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote: Well, if you're playing that game, I'd suggest that anybody wanting to make proposals on this issue should know what CFLAGS is and understand how it is nothing other than a set of flags that are passed to the compiler when compiling a C program, and then evaluate the impact of subverting such a variable for nefarious purposes. And I suggest that anybody willing to comment on user-side of things would know what an user is and understand how users feel about issues, instead of going on and on and on commenting without having a clue. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZvC5MwKfS1.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:46:31 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote: | Well, if you're playing that game, I'd suggest that anybody wanting | to make proposals on this issue should know what CFLAGS is and | understand how it is nothing other than a set of flags that are | passed to the compiler when compiling a C program, and then | evaluate the impact of subverting such a variable for nefarious | purposes. | | And I suggest that anybody willing to comment on user-side of things | would know what an user is and understand how users feel about | issues, instead of going on and on and on commenting without having a | clue. You're not going to give in gracefully, huh? Ok, I'd like to ask the council to declare that abusing CFLAGS in the manner proposed in this thread is a very bad idea. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:13:11 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the times, as it's not an i686 but at the same time it has MMX support. There's -march=pentium-mmx for this. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:10, Kevin F. Quinn wrote: There's -march=pentium-mmx for this. I forgot about it, thanks for pointing it out :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzOhSWFVsLH.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote: You're not going to give in gracefully, huh? Ok, I'd like to ask the council to declare that abusing CFLAGS in the manner proposed in this thread is a very bad idea. If you finished the proper arguments, the next one will be that it's all a cabal of infra against you, I suppose. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjBAukAFhDn.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 23:12:51 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote: | You're not going to give in gracefully, huh? Ok, I'd like to ask the | council to declare that abusing CFLAGS in the manner proposed in | this thread is a very bad idea. | | If you finished the proper arguments, the next one will be that it's | all a cabal of infra against you, I suppose. No, Diego. The argument is that you're coming up with a horrible and unnecessary hack where there are far cleaner alternatives, and that you're blindly sticking to it and trying to throw off any objections by devious means because you don't want to scrap said hack after all the misguided effort you've spent on it. However, since you seem to be incapable of admitting the gaping flaws in your own work, I'm asking for someone else to point this out to you in a formal manner rather than watch this thread go on for even longer. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. Ciaran I will give you that you are a capable programmer, and had valid arguments in this thread. However, when interacting with people and proving points on merits you seem to go out of your way to not prove anything and throw examples out there without really backing them up. No, Diego. The argument is that you're coming up with a horrible and unnecessary hack where there are far cleaner alternatives, and that you're blindly sticking to it and trying to throw off any objections by devious means because you don't want to scrap said hack after all the misguided effort you've spent on it. However, since you seem to be incapable of admitting the gaping flaws in your own work, I'm asking for someone else to point this out to you in a formal manner rather than watch this thread go on for even longer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErYFLSENan+PfizARAjzzAJwIue9UDtwsANxaaqqnVJVr0jTz6ACglAL6 cO7O0Pw+CGDfFlVdY7z1N3o= =6G6V -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. He already has done. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote: No, Diego. The argument is that you're coming up with a horrible and unnecessary hack where there are far cleaner alternatives, and that you're blindly sticking to it and trying to throw off any objections by devious means because you don't want to scrap said hack after all the misguided effort you've spent on it. However, since you seem to be incapable of admitting the gaping flaws in your own work, I'm asking for someone else to point this out to you in a formal manner rather than watch this thread go on for even longer. Wait, isn't that what _you_ usually do? Like climbing up on mirrors when you misunderstood something and blamed someone for an error that was never made, trying to find another glitch in the procedure to back it up? Yeah that really sounds like you more than me. I'm entirely ready to scrap what I have here if I find _valid reasons to_. All you seem to be able to say is that you don't like this, you point to a control that users have not much for a valid reason than for the simple fact that the useflag was a good way to allow user to choose what it had without forcing it to use support that was not supported on their system. A solution that worked, but that is not the only one, and that I wouldn't consider a great choice that users really need to be able to use Gentoo. The most interesting point shown up until now is the one about non-gcc compatibility, that I actually thought about for a while, but I thought -dM was unix standard option, Harald got me there, and I'll be checking for something in ICC. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpx6QSrOFiRm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: | Or instead of throwing a hissy fit yourself about diego not agreeing | with you..I don't know you could go and show the way that you feel it | should be done and show the technical merit. Ciaran I will give you | that you are a capable programmer, and had valid arguments in this | thread. However, when interacting with people and proving points on | merits you seem to go out of your way to not prove anything and throw | examples out there without really backing them up. No, I go out of my way to avoid posting hundred page essays explaining things that people already know. If there's really anyone reading this discussion who doesn't understand any of the points being discussed, they're more than welcome to ask for clarification. However, given how basic an issue this is, is it really worth wasting everyone's time with huge explanations of what CFLAGS is? Come on, do you really think anyone will benefit from another http://dev.gentoo.org/~blubb/duncan.pdf ? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: | Or instead of throwing a hissy fit yourself about diego not agreeing | with you..I don't know you could go and show the way that you feel it | should be done and show the technical merit. Ciaran I will give you | that you are a capable programmer, and had valid arguments in this | thread. However, when interacting with people and proving points on | merits you seem to go out of your way to not prove anything and throw | examples out there without really backing them up. No, I go out of my way to avoid posting hundred page essays explaining things that people already know. If there's really anyone reading this discussion who doesn't understand any of the points being discussed, they're more than welcome to ask for clarification. However, given how basic an issue this is, is it really worth wasting everyone's time with huge explanations of what CFLAGS is? Come on, do you really think anyone will benefit from another http://dev.gentoo.org/~blubb/duncan.pdf ? Stephen Bennett wrote: On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. He already has done. After reading this thread I can see this is just another one of ciaran's b.s games that Stephen happens to back. My question is just how far up ciaran's ass does stephen go. I am begining to think we will never get to the end if ciaran and his bullshit around gentoo, nor will we ever get rid of stephen's bullshit around gentoo. But the project continues to allow such non-sence and wonders why devs are still walking away. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErYoRo9V4dnAHxYwRAiq7AJ4+kLNig3h0Ra8k9CuLJynDFBuC+QCgiq/W BFKmn9FzOXFhWgBt8rSbUdo= =wTC0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 17:09:22 -0500 Jory A. Pratt [EMAIL PROTECTED] wrote: snip Leaving aside the incoherent ad-hominem attack, could you please point out where the bullshit is? If you were referring to my post, I suggest you re-read Ciaran's first mail to this thread. He outlined at least two possible alternatives, but everyone seems to have ignored this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: [summary:provide a way to enable simd features by extracting them from the ones supported by the cflags selected and the compiler] Pros: - automagic : you just carefully select your cflags and your apps will have all the simd goodness you may dream/want/expect. - less useflags around - simpler life when building stages (given we gut cpuinfo checks in configures) Cons: - assumes gcc - per ebuild cflags feat isn't ready yet - makes less simple to have certain corner case 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. - have simdflags as use_expand to keep them on a single place and improve the description - as before but provide an eclass that uses flameeyes infrastructure to warn about possible mismatch between what the cflags could do and what you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning and disable it - as the one before again but with a var to decide if follow the use or the gcc check. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Jory A. Pratt wrote: Ciaran McCreesh wrote: On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: | Or instead of throwing a hissy fit yourself about diego not agreeing | with you..I don't know you could go and show the way that you feel it | should be done and show the technical merit. Ciaran I will give you | that you are a capable programmer, and had valid arguments in this | thread. However, when interacting with people and proving points on | merits you seem to go out of your way to not prove anything and throw | examples out there without really backing them up. No, I go out of my way to avoid posting hundred page essays explaining things that people already know. If there's really anyone reading this discussion who doesn't understand any of the points being discussed, they're more than welcome to ask for clarification. However, given how basic an issue this is, is it really worth wasting everyone's time with huge explanations of what CFLAGS is? Come on, do you really think anyone will benefit from another http://dev.gentoo.org/~blubb/duncan.pdf ? Stephen Bennett wrote: On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson [EMAIL PROTECTED] wrote: Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. He already has done. After reading this thread I can see this is just another one of ciaran's b.s games that Stephen happens to back. My question is just how far up ciaran's ass does stephen go. I am begining to think we will never get to the end if ciaran and his bullshit around gentoo, nor will we ever get rid of stephen's bullshit around gentoo. But the project continues to allow such non-sence and wonders why devs are still walking away. I'm not sticking up for Ciaran, he already made his bed and now he's laying in it. I'm sticking up for spb who is a damn good dev and doesn't deserve this kind of bullshit dumped on him. spb works his ass off for this project and is */ALWAYS/* very professional. Just look at the past few threads that he has started where he totally changed his approach based on feedback from everyone (hell, look at ANY technical discussion that spb has ever had regarding Gentoo - not just the last few mail threads). He was professional, listened attentively and made changes based on the feedback that satisfied everyone involved while still solving the problem at hand. Sounds like a damn good developer to me. One I would like to see more of in Gentoo. spb != ciarnm Just my two cents for what it's worth. signature.asc Description: OpenPGP digital signature
