On Thu, Apr 06, 2006 at 09:05:12AM -0700, Michael Miller wrote: > > what? "all 64-bit compiling gotchas are fixed in GCC"? please > > tell, what "64-bit compiling gotchas" are in gcc? I've been using > > gcc on an amd64, in 64-bit mode, for over a year. I haven't > > seen any "gotchas". > > Did I say amd64 for Intel 64 or X86_64? No I did not. If you would > look in the gcc bug database you will find a hole list of bugs for > 64bit issues on all architecture sets (Chips). > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24879
SSE3 intrinsics for gcc 4.1. might matter if you are trying to be ultra-bleeding edge and build everything with -O3, but otherwise ... > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16541 "missed optimization", and this is for 64-bit data x86, not x86_64. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 "Small targets without 64 bit long long support are can't bootstrap GCC". this has nothing to do with 64-bit processors (actually, it looks like this is _not_ a problem on 64-bit targets), AFAICS. > When I said "gotchas" my meaning was when most everyone has been > writing 32bit software for the last I don't know 20+ years. Going to > 64bit and trying to unlearn all the bad hacks you have had to use for > 32bit and the fact that not everyone writes perfect bug free code the > first time. There are going to be problems; It may be you write bad > code or you have a compiler issue. you specifically said, "all 64-bit compiling gotchas are fixed in GCC". > > now, if you are talking about _libtool_ issues with /usr/lib and > > /usr/lib64 (or /usr/lib32), that is a whole other problem that has > > nothing to do with gcc. these could be elimitated by ditching > > 32-bit support and going 64-bit all the way. > > Not all of the Linux distributions have compiled every software > package on a 64bit processor. There are still 32bit packages out > there that case issues like the one you have stated above. I think I > would call that a "gotchas" unless you are running Gentoo and you > compile everything and not use pre-compiled packages. I use OpenBSD, and yes, everything is compiled 64-bit. and I mostly use prebuilt binaries except for new ports I'm working on. > > and then of course, there is software that makes 32-bit assumptions, > > or only has assembly code for x86. again these have nothing to do > > with "64-bit compiling gotchas" in gcc. the software, not gcc, has > > "64-bit compiling gotchas". > > That is very true. I would call that a move to 64bit "gotchas" > instead of a compiling "gotchas". > > > now, for "any 64-bit kernel security issues are fixed." you think > > there are no 32-bit kernel security issues? if anything, going 64-bit > > will buy you a small bit of security by obscurity (granted, worth > > only maybe the $0.02 you put into this thread), as script kiddies > > try their 32-bit `sploits. > > How can you make a statement like that? I just don't see how you > could say that. That is like saying Oracle is "unbreakable" or > "Unhackable" or Windows has no security issues and is more secure > than Linux or OpenBSD. huh? please explain how "if anything ... will buy a small bit" to "unbreakable". and just how is Windows more obscure than Linux or OpenBSD? > Yes there are 32-bit kernel security issues known and unknown. You > know what I'm sure there are 64-bit kernel security issues that are > not known yet or discovered. so, why wait until "any 64-bit kernel security issues are fixed", if there are also issues with 32-bit? what is the difference? and if people aren't using 64-bit platforms, how are these bugs going to be found? > Security by obscurity never works and > always fails over time. not _always_. please be careful when making absolute statements! > It might work until some one figures out what > you are using and then you will get owned. maybe. most script kiddies use prebuilt software though. of course, the people creating the sploits know what they are doing, but the kiddies out there using them are usually fairly clueless in all reality. but as I said, security by obscurity is worth maybe $0.02. why you have to try to make it sound like I said anything different is beyond me. > When I give my $0.02. I say that because it is free advice and I'm > not telling people what to do. I am only sharing information or > knowledge. Then you can use that to do your own research. After you > do your own research then and only then I think you can make a > informed dissension. I did my research. I have been using amd64 for almost 2 years. yeah, there was some pain at first, but these days it's pretty smooth sailing. how much real experience do you have with modern 64-bit platforms? > Then again you can take my advice for what it's > worth because no one is paying me. If you then get into trouble and > or screw things up you don't have to take my input anymore. fwiw, you have made my list of people whose advice I should ignore. -- <[EMAIL PROTECTED]> _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
