Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140702
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Compiler stress test |
| Date | 2019-02-07 08:32 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <q3gmvb$36n$1@dont-email.me> (permalink) |
| References | (1 earlier) <gbt4iiFfhg9U4@mid.individual.net> <gc0qq9FgcocU4@mid.individual.net> <q3fii7$p18$1@dont-email.me> <q3fqut$c3k$1@dont-email.me> <q3gib7$fae$1@dont-email.me> |
On 07/02/2019 07:13, jacobnavia wrote: > Le 07/02/2019 à 00:34, David Brown a écrit : > >> There is no particular reason why a compiler for a 64-bit target >> should itself be a 64-bit program. > > Rule 1: > > GCC is always right even if it fails. If you say so. No one will agree with you, but whatever makes you happy. And it is, of course, irrelevant to my point - the host system and bit size of a compiler does not need any correlation with the target processor and bit size. > >> It is only in very odd cases (like this stress test) where the memory >> limitations of a 32-bit program would be relevant in compilation. > > RULE 2: > > If GCC fails, RULE 1 applies. > If you are doing a compile that takes more than 2 GB ram (within one compile), or hits other 32-bit limits, you are doing something very odd. You /might/ be doing something useful, but it is certainly unusual. The /huge/ majority of C programmers will get through their entire programming lives without ever having an issue with this. If you are doing C++ programming with huge code bases, or you are doing large link-time optimisation builds, then you are going to need a lot of ram when compiling. But not for compiling any realistic C file. > >> And on Windows, 32-bit programs are typically faster than 64-bit >> versions. > > Sure, but all 32 bit processes under windows can use up to 4GB of RAM if > they turn on the LARGEADDRESSAWARE flag in the executable header. > > gcc does NOT turn ON that flag, and doesn't even use the 2GB available > to it but... So what? Why would anyone care? > > RULE 3 > Technical resons do not count, because RULE 1 always applies. > Pull your head out your backside, switch off your rampant paranoia, and read what I wrote.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-05 10:30 +0100
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:50 +1300
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:56 +1300
strict aliasing rule on buffers slacked.misha@gmail.com - 2019-02-05 13:33 +0100
Re: strict aliasing rule on buffers Richard Damon <Richard@Damon-Family.org> - 2019-02-05 08:13 -0500
Re: strict aliasing rule on buffers Barry Schwarz <schwarzb@dqel.com> - 2019-02-05 06:00 -0800
Re: strict aliasing rule on buffers David Brown <david.brown@hesbynett.no> - 2019-02-05 15:33 +0100
Re: strict aliasing rule on buffers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-05 14:36 +0000
Re: strict aliasing rule on buffers James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-05 07:27 -0800
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-07 08:28 +1300
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 19:48 +0000
Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-06 22:11 +0100
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 00:34 +0100
Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 07:13 +0100
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 08:32 +0100
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 12:06 +0000
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 14:08 +0100
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 13:49 +0000
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 17:01 +0100
Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 22:26 +0100
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 23:24 +0100
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 23:20 +0000
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 10:42 +0100
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:37 +1300
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 12:30 +0100
Re: Compiler stress test Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 08:18 -0800
Re: Compiler stress test scott@slp53.sl.home (Scott Lurndal) - 2019-02-08 16:04 +0000
Re: Compiler stress test Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-11 20:34 +0000
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:30 +1300
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 12:20 +0000
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:59 +1300
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 21:57 +0000
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 00:29 +0100
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 23:58 +0000
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:10 +1300
Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 01:16 +0000
Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:21 +1300
Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-06 01:28 -0500
Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-08 03:51 -0500
Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 08:13 +0100
Re: Compiler stress test BGB <cr88192@hotmail.com> - 2019-02-06 13:13 -0600
csiph-web