Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90795 > unrolled thread
| Started by | The Doctor <doctor@doctor.nl2k.ab.ca> |
|---|---|
| First post | 2016-07-22 17:29 +0000 |
| Last post | 2016-07-23 12:35 -0700 |
| Articles | 20 on this page of 219 — 33 participants |
Back to article view | Back to comp.lang.c
GCC vs Clang The Doctor <doctor@doctor.nl2k.ab.ca> - 2016-07-22 17:29 +0000
Re: GCC vs Clang Luuk <luuk@invalid.lan> - 2016-07-22 20:17 +0200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 21:09 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 12:22 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 23:20 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 14:56 -0700
Re: GCC vs Clang jameskuyper@verizon.net - 2016-07-22 15:27 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 00:59 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 20:33 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 12:18 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 12:54 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 13:48 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:54 +0200
Killfiles: Learn how they work. They are your friend! (Was: GCC vs Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-23 21:14 +0000
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:10 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 05:20 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 15:43 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 07:09 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-23 22:08 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:21 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 14:38 +0100
Re: GCC vs Clang Mark Storkamp <mstorkamp@yahoo.com> - 2016-07-25 09:30 -0500
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 15:41 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 16:33 +0200
Re: GCC vs Clang Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 07:46 -0700
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 11:02 -0400
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:00 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:25 -0700
Re: GCC vs Clang Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2016-07-22 20:42 +0000
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 23:09 +0200
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 10:50 -0400
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:53 +0100
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:50 +0000
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 11:07 -0400
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:16 +0100
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-27 07:27 +0000
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 08:29 +0100
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-27 12:29 -0400
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:44 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-22 22:18 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-22 14:43 -0700
Re: GCC vs Clang Melzzzzz <mel@zzzzz.com> - 2016-07-23 00:02 +0200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-09 17:20 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 10:34 +0200
Re: GCC vs Clang Siri Cruise <chine.bleu@yahoo.com> - 2016-08-10 02:18 -0700
Re: GCC vs Clang cross@spitfire.i.gajendra.net (Dan Cross) - 2016-08-10 15:31 +0000
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 13:31 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 15:14 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-25 16:57 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 17:24 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-25 15:29 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 16:00 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-25 16:31 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 17:06 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-26 07:52 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 08:20 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-26 16:23 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 07:17 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 00:56 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:17 +0000
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-27 09:36 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-27 10:04 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-07-27 20:42 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 20:29 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-27 12:08 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:43 +0000
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 07:32 +1200
Re: GCC vs Clang supercat@casperkitty.com - 2016-07-27 13:23 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 17:13 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 07:10 +0200
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-26 17:19 +1200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-26 08:28 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-26 00:53 -0700
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 02:04 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 08:41 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-25 17:37 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-25 12:07 -0700
Re: GCC vs Clang? jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-25 22:57 +0200
Re: GCC vs Clang? David Brown <david.brown@hesbynett.no> - 2016-07-26 14:08 +0200
Re: GCC vs Clang? raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:18 +0000
Re: GCC vs Clang? jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-27 22:01 +0200
Re: GCC vs Clang? raltbos@xs4all.nl (Richard Bos) - 2016-07-28 09:56 +0000
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-27 12:38 -0400
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 07:38 +1200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 20:54 +0100
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 08:16 +1200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-07-27 23:55 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 07:20 +0100
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 19:35 +1200
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:47 +0000
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-07-28 19:35 +1200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-09 17:00 -0700
Re: GCC vs Clang eva galois <eva.galois@yandex.ru> - 2016-08-09 21:15 -0400
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 10:42 +0200
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:52 +0000
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-10 06:59 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 16:52 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 11:22 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-10 11:31 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 14:01 +0100
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-10 07:12 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 17:09 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 09:40 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-10 09:55 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-10 22:51 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 09:36 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 17:52 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 11:49 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-10 20:28 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-10 13:06 -0700
Re: GCC vs Clang Tim Prince <tprince@computer.org> - 2016-08-10 18:14 -0400
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-10 21:53 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 10:35 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 11:00 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 09:36 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 18:54 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 12:11 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 20:42 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 19:53 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 12:41 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 20:21 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 13:11 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 21:46 +0200
Re: GCC vs Clang Gareth Owen <gwowen@gmail.com> - 2016-08-11 20:49 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 13:57 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-11 23:10 +0200
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 09:07 +0100
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 10:50 +0200
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 13:47 -0700
Re: GCC vs Clang "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-14 16:29 -0400
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 23:00 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 14:04 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 14:11 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 15:29 -0700
Re: GCC vs Clang "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-14 18:13 -0400
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-15 00:14 -0700
Keith's subtle use of the word "vendor" (Was: GCC vs Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-15 08:04 +0000
Re: Keith's subtle use of the word "vendor" (Was: GCC vs Clang) fir <profesor.fir@gmail.com> - 2016-08-15 01:15 -0700
Re: Keith's subtle use of the word "vendor" (Was: GCC vs Clang) jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-17 16:50 +0200
Re: Keith's subtle use of the word "vendor" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-15 07:27 -0600
Re: Keith's subtle use of the word "vendor" Richard Heathfield <rjh@cpax.org.uk> - 2016-08-15 15:00 +0100
Re: Keith's subtle use of the word "vendor" James Kuyper <jameskuyper@verizon.net> - 2016-08-15 10:29 -0400
Re: Keith's subtle use of the word "vendor" Mark Storkamp <mstorkamp@yahoo.com> - 2016-08-15 10:22 -0500
Re: Keith's subtle use of the word "vendor" jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-15 17:46 +0200
Re: Keith's subtle use of the word "vendor" Richard Heathfield <rjh@cpax.org.uk> - 2016-08-15 17:41 +0100
Re: Keith's subtle use of the word "vendor" jameskuyper@verizon.net - 2016-08-15 09:47 -0700
Re: Keith's subtle use of the word "vendor" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-15 11:11 -0600
Re: Keith's subtle use of the word "vendor" "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-15 13:28 -0400
Re: Keith's subtle use of the word "vendor" fir <profesor.fir@gmail.com> - 2016-08-15 10:05 -0700
Re: GCC vs Clang (was Re: Keith's subtle use of the word "vendor") Keith Thompson <kst-u@mib.org> - 2016-08-15 11:52 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-15 18:00 +0000
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:34 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:48 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 11:56 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 12:10 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") fir <profesor.fir@gmail.com> - 2016-08-15 12:18 -0700
Re: Trolling (was Re: Keith's subtle use of the word "vendor") mark.bluemel@gmail.com - 2016-08-17 08:44 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-15 09:38 -0700
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-08-17 08:24 +0000
Re: GCC vs Clang Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 17:44 +0200
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-08-15 17:25 +1200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:09 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:16 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 23:28 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 10:50 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:30 -0700
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 14:16 +0100
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 07:28 -0700
Re: GCC vs Clang Ike Naar <ike@iceland.freeshell.org> - 2016-08-14 18:05 +0000
Re: GCC vs Clang Melzzzzz <mel@zzzzz.com> - 2016-08-14 20:18 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 11:54 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 12:05 -0700
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-14 21:16 +0200
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 12:37 -0700
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 20:59 +0100
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 13:48 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 13:58 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-14 02:53 -0700
Re: GCC vs Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-14 11:34 +0100
Re: GCC vs Clang Richard Heathfield <rjh@cpax.org.uk> - 2016-08-14 14:07 +0100
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-14 12:36 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-14 14:03 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-15 09:48 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-15 11:46 -0700
Re: GCC vs Clang fir <profesor.fir@gmail.com> - 2016-08-15 10:45 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:11 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:06 -0700
Re: GCC vs Clang James Kuyper <jameskuyper@verizon.net> - 2016-08-11 15:16 -0400
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 14:02 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 22:20 +0100
Re: GCC vs Clang Gareth Owen <gwowen@gmail.com> - 2016-08-12 16:58 +0100
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 17:05 +0100
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-11 23:24 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-11 22:58 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 16:08 -0700
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 00:21 +0100
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-11 17:29 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 12:23 +0200
Re: GCC vs Clang BartC <bc@freeuk.com> - 2016-08-12 11:43 +0100
Re: GCC vs Clang jameskuyper@verizon.net - 2016-08-13 08:37 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-11 13:58 -0700
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-11 16:28 -0700
Re: GCC vs Clang Geoff <geoff@invalid.invalid> - 2016-08-12 01:12 -0700
Re: GCC vs Clang Ian Collins <ian-news@hotmail.com> - 2016-08-12 20:15 +1200
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 12:29 +0200
Re: GCC vs Clang jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-12 12:45 +0200
Re: GCC vs Clang Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 04:30 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 08:09 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 14:49 +0200
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-12 05:00 -0700
Re: GCC vs Clang David Brown <david.brown@hesbynett.no> - 2016-08-12 15:03 +0200
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 08:22 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-12 09:14 -0700
Re: GCC vs Clang supercat@casperkitty.com - 2016-08-12 10:23 -0700
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-08-12 11:29 -0700
Re: GCC vs Clang already5chosen@yahoo.com - 2016-08-12 05:19 -0700
Re: GCC vs Clang Ken Brody <kenbrody@spamcop.net> - 2016-07-25 10:53 -0400
Re: GCC vs Clang raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:55 +0000
Re: GCC vs Clang Keith Thompson <kst-u@mib.org> - 2016-07-23 12:35 -0700
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-22 14:43 -0700 |
| Message-ID | <lnpoq5gxgv.fsf@kst-u.example.com> |
| In reply to | #90819 |
BartC <bc@freeuk.com> writes:
> On 22/07/2016 18:29, The Doctor wrote:
>> Which is the better compiler?
>
> My experience of using Clang is that it is not complete: it assumes a
> gcc installation (so that it can make use of gcc's header files and
> possibly libraries too).
>
> So if you could only install one, gcc would make more sense...
I don't believe that clang depends on gcc.
If you install it on Windows, it may depend on things that are
installed by another package that might include gcc. Installing some
package that includes both gcc and some set of libraries and headers
might well be the easiest way to get the prerequisites that clang
depends on. It would be nice to have a Windows installer that just
installs clang and whatever it depends on. I don't know whether
such an installer exists. (I haven't used Windows recently, so I
can't confirm any of this.)
On Linux, you can probably just install a package called "clang",
perhaps with an appended version number. (And gcc, and the
associated library packages that both gcc and clang depend on,
are likely preinstalled anyway.)
MacOSX, as I recall, has clang but not gcc preinstalled, and
configures the "gcc" command to invoke the clang compiler (because
so many build scripts assume the C compiler is called "gcc").
I have no opinion on whether gcc or clang is better. I generally use
gcc myself, just because it's the path of least resistance on the
systems I use.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-07-23 00:02 +0200 |
| Message-ID | <20160723000254.08841ec9@maxa-pc> |
| In reply to | #90822 |
On Fri, 22 Jul 2016 14:43:44 -0700 Keith Thompson <kst-u@mib.org> wrote: > BartC <bc@freeuk.com> writes: > > On 22/07/2016 18:29, The Doctor wrote: > >> Which is the better compiler? > > > > My experience of using Clang is that it is not complete: it assumes > > a gcc installation (so that it can make use of gcc's header files > > and possibly libraries too). > > > > So if you could only install one, gcc would make more sense... > > I don't believe that clang depends on gcc. > > If you install it on Windows, it may depend on things that are > installed by another package that might include gcc. Installing some > package that includes both gcc and some set of libraries and headers > might well be the easiest way to get the prerequisites that clang > depends on. It would be nice to have a Windows installer that just > installs clang and whatever it depends on. I don't know whether > such an installer exists. (I haven't used Windows recently, so I > can't confirm any of this.) I believe that clang depends on gcc c++ stdlib , but can be used with own lib. There are some other gcc dependencies as well but can be also replaced by alternatives. > > On Linux, you can probably just install a package called "clang", > perhaps with an appended version number. (And gcc, and the > associated library packages that both gcc and clang depend on, > are likely preinstalled anyway.) > > MacOSX, as I recall, has clang but not gcc preinstalled, and > configures the "gcc" command to invoke the clang compiler (because > so many build scripts assume the C compiler is called "gcc"). > > I have no opinion on whether gcc or clang is better. I generally use > gcc myself, just because it's the path of least resistance on the > systems I use. gcc produce faster code while clang compiles faster, that is my experience.... It may change if not already... >
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-09 17:20 -0700 |
| Message-ID | <1f1e86c4-da51-4e6d-a7ce-016263af2c89@googlegroups.com> |
| In reply to | #90824 |
On Saturday, July 23, 2016 at 1:03:02 AM UTC+3, Melzzzzz wrote: > gcc produce faster code while clang compiles faster, that is my > experience.... > It may change if not already... > Sounds correct on both accounts, at least for numeric codes on x86-64 targets. clang used to compile faster than gcc. but it already changed. By now, clang -O2 and gcc -O2 compile at approximately the same speed, sometimes gcc is even a little faster. gcc still produces faster code. So, by now, as far as I am concerned, the only advantage clang holds over gcc is clearer error diagnostics. Also some people can prefer clang license over gcc's either for pragmatic or for ideological reasons. Some other people can prefer gcc license over clang's for ideological or for pragmatic reasons, although I personally can not think of any of the later. Me? I don't care. Supposedly llvm/clang is ALOT better than gcc as compiler back end for IDEs. But it seems that OP was asking about their comparative merits as stand-alone command line tools.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-10 10:34 +0200 |
| Message-ID | <noeou3$no3$1@dont-email.me> |
| In reply to | #92038 |
On 10/08/16 02:20, already5chosen@yahoo.com wrote: > On Saturday, July 23, 2016 at 1:03:02 AM UTC+3, Melzzzzz wrote: > >> gcc produce faster code while clang compiles faster, that is my >> experience.... It may change if not already... >> > > Sounds correct on both accounts, at least for numeric codes on x86-64 > targets. clang used to compile faster than gcc. but it already > changed. By now, clang -O2 and gcc -O2 compile at approximately the > same speed, sometimes gcc is even a little faster. gcc still produces > faster code. So, by now, as far as I am concerned, the only advantage > clang holds over gcc is clearer error diagnostics. Since clang started to become popular, and people realised that clang generates good code with faster compilation and better diagnostics, the gcc team took the comparison as a challenge and an inspiration. In recent versions, gcc has got somewhat faster (especially where it /really/ matters, such as compilation of massive C++ projects with link-time optimisation), and much better and clearer diagnostics (again, especially obvious for C++ where diagnostics could easily be unintelligible). On the other side, as clang has adopted more and more optimisations, it has generated faster code but taken longer to do so. And the two projects have cooperated on new ideas and features, especially for the "sanitize" debugging aids. They also cooperate to keep new implementation-specific features (such as new "attributes") compatible between the two compilers. The mixture between cooperation and competition has been good for both projects, and good for users. > > Also some people can prefer clang license over gcc's either for > pragmatic or for ideological reasons. Some other people can prefer > gcc license over clang's for ideological or for pragmatic reasons, > although I personally can not think of any of the later. Me? I don't > care. > > Supposedly llvm/clang is ALOT better than gcc as compiler back end > for IDEs. But it seems that OP was asking about their comparative > merits as stand-alone command line tools. >
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2016-08-10 02:18 -0700 |
| Message-ID | <chine.bleu-5B7411.02180610082016@news.eternal-september.org> |
| In reply to | #92048 |
In article <noeou3$no3$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: > The mixture between cooperation and competition has been good for both > projects, and good for users. To be honest as a MacOSX programmer, my attitude is Apple giveth and Apple taketh away; mysterious are the ways of the Forbidden Fruit. As long as they provide a cc that works and handles the gnuisms I use, I'm happy. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' If you assume the final scene is a dying delusion as Tom Cruise drowns below the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2016-08-10 15:31 +0000 |
| Message-ID | <nofhdb$gii$1@reader2.panix.com> |
| In reply to | #92038 |
In article <1f1e86c4-da51-4e6d-a7ce-016263af2c89@googlegroups.com>,
<already5chosen@yahoo.com> wrote:
>On Saturday, July 23, 2016 at 1:03:02 AM UTC+3, Melzzzzz wrote:
>> gcc produce faster code while clang compiles faster, that is my
>> experience....
>> It may change if not already...
>
>[snip]
>
>Supposedly llvm/clang is ALOT better than gcc as compiler back end
>for IDEs.
Indeed. GCC does things like trivial constant folding in the frontend
of the compiler (e.g., expressions like 'a+0' are translated to 'a').
This means that the parse tree that would be used by something like an
IDE is not a bijection with the actual program source. See, for
example, this presentation:
https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
>But it seems that OP was asking about their comparative
>merits as stand-alone command line tools.
For C under Linux, I would say that they are largely equivalent as far
as the vast majority of programmers are concerned.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-25 13:31 +0200 |
| Message-ID | <nn4tao$4hi$1@dont-email.me> |
| In reply to | #90819 |
On 22/07/16 23:18, BartC wrote: > On 22/07/2016 18:29, The Doctor wrote: >> Which is the better compiler? > > My experience of using Clang is that it is not complete: it assumes a > gcc installation (so that it can make use of gcc's header files and > possibly libraries too). > > So if you could only install one, gcc would make more sense... > If you are using an OS that does not include basic OS headers and libraries, then you will need to install those along with your compiler. Neither clang nor gcc provide these. There are /packages/ for Windows that include gcc, headers, libraries, an assembler, linker, and other useful utilities. If there are no such pre-made packages for clang for Windows, then perhaps installing a gcc package first is a convenient way to handle installation of clang on Windows. Remember, gcc and clang are compilers - they are only /part/ of a C (or C++) implementation. However, the OP is posting from a *nix system - FreeBSD, according to the post's headers. He will therefore have all the headers and libraries he needs, either installed already or just a "pkg install" away.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 15:14 +0100 |
| Message-ID | <nn56rt$542$1@dont-email.me> |
| In reply to | #90964 |
On 25/07/2016 12:31, David Brown wrote: > On 22/07/16 23:18, BartC wrote: >> On 22/07/2016 18:29, The Doctor wrote: >>> Which is the better compiler? >> >> My experience of using Clang is that it is not complete: it assumes a >> gcc installation (so that it can make use of gcc's header files and >> possibly libraries too). >> >> So if you could only install one, gcc would make more sense... >> > > If you are using an OS that does not include basic OS headers and > libraries, then you will need to install those along with your compiler. Huh? How is a beginner supposed to know anything about that? They will expect a C compiler to come with everything needed to compile C programs into something that can be run. Pelles C includes everything. lccwin32 includes everything. Digital Mars C includes everything. Tiny C includes everything. The MSVC I bought years ago including everything. Until you come to gcc which just has to be different, just to make life simpler for everyone!. But even there, if you've chosen the right download package, everything needed is also there. And then you come to Clang (for Windows, as are all my examples). Which, for a start, gives no indication whatsoever that it does have a dependency. Nor that that dependency is on anything other than specifically gcc. Very puzzling after you've completed a 400MB installation; surely that lot must have included everything /including/ the kitchen sink! If I 'hide' my gcc installation, then Clang stops working. Despite there being four other C compilers around. > Neither clang nor gcc provide these. There are /packages/ for Windows > that include gcc, headers, libraries, an assembler, linker, and other > useful utilities. If there are no such pre-made packages for clang for > Windows, then perhaps installing a gcc package first is a convenient way > to handle installation of clang on Windows. Remember, gcc and clang are > compilers - they are only /part/ of a C (or C++) implementation. Blah blah ... No beginner wants to know about this stuff. They want something that Just Works. They are not interested in the fine distinctions between a compiler, includes, libraries and utilities. Even a non-beginner who has spent years using integrated packages would be surprised that some compilers are split up into separate parts. (Like buying a new car but having to source the engine and the wheels separately. And not actually being told that so being surprised because you're used to cars having those included.) > However, the OP is posting from a *nix system - FreeBSD, according to > the post's headers. He will therefore have all the headers and > libraries he needs, either installed already or just a "pkg install" away. In that case he's got no problems because Unix users like to have their hands held (the opposite to what is usually claimed). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-25 16:57 +0200 |
| Message-ID | <nn59cg$e28$1@dont-email.me> |
| In reply to | #90993 |
On 25/07/16 16:14, BartC wrote: > On 25/07/2016 12:31, David Brown wrote: >> On 22/07/16 23:18, BartC wrote: >>> On 22/07/2016 18:29, The Doctor wrote: >>>> Which is the better compiler? >>> >>> My experience of using Clang is that it is not complete: it assumes a >>> gcc installation (so that it can make use of gcc's header files and >>> possibly libraries too). >>> >>> So if you could only install one, gcc would make more sense... >>> >> >> If you are using an OS that does not include basic OS headers and >> libraries, then you will need to install those along with your compiler. > > Huh? How is a beginner supposed to know anything about that? They will > expect a C compiler to come with everything needed to compile C programs > into something that can be run. I have no idea what /you/ are supposed to know about. I /do/ know that most OS's include assemblers, linkers, libraries, and headers (and usually compilers too) as part of their basic packaging - Windows is fairly unique in not doing so. I also know that some compiler manufacturers - gcc and clang being prime examples - make compilers, not development suites or even complete C implementations. It is such a long time since I was a beginner with C that it is hard to be sure how someone might approach the issue. But I would imagine that someone starting with a bare Windows system who wants to use clang for C compilation would first start out by googling. It should not take long to see that clang is distributed as part of modern MS Visual Studio, and that would seem like the easiest way to get the compiler along with an IDE, headers, libraries, etc. Other suggestions that come up quite quickly are instructions for compiling llvm and clang (presumably your scared newbie would skip those), and projects like msys2 (which will include all the other bits and pieces needed). Newbies with any most other OS's would simply look up clang with their distribution's package manager, and that would install any missing files or programs automatically. > > Pelles C includes everything. lccwin32 includes everything. Digital Mars > C includes everything. Tiny C includes everything. The MSVC I bought > years ago including everything. Those are not compilers - they are development suites of which a compiler is one part. Now, it is an understandable mistake to think that clang or gcc are the same sort of thing as these tools - but it is a mistake. Their websites, or at least their "getting started" information could no doubt be more helpful here. > > Until you come to gcc which just has to be different, just to make life > simpler for everyone!. But even there, if you've chosen the right > download package, everything needed is also there. > > And then you come to Clang (for Windows, as are all my examples). Which, > for a start, gives no indication whatsoever that it does have a dependency. > > Nor that that dependency is on anything other than specifically gcc. > Very puzzling after you've completed a 400MB installation; surely that > lot must have included everything /including/ the kitchen sink! > > If I 'hide' my gcc installation, then Clang stops working. Despite there > being four other C compilers around. > >> Neither clang nor gcc provide these. There are /packages/ for Windows >> that include gcc, headers, libraries, an assembler, linker, and other >> useful utilities. If there are no such pre-made packages for clang for >> Windows, then perhaps installing a gcc package first is a convenient way >> to handle installation of clang on Windows. Remember, gcc and clang are >> compilers - they are only /part/ of a C (or C++) implementation. > > Blah blah ... No beginner wants to know about this stuff. They want > something that Just Works. They are not interested in the fine > distinctions between a compiler, includes, libraries and utilities. I am not trying to sell you anything here - I am just telling you the facts. If you want to campaign on behalf of all these "beginners" who want to program in C on Windows, specifically using gcc or clang, and want something that "just works", then feel free to do so. I should expect you could put together binary packages for clang and gcc, along with libraries, include files, a debugger, and an IDE, all within a single installer file. I don't even think it would be a huge effort (though testing it all on different versions of Windows might be a pain). But please stop making it look as though this is the fault of gcc, or the fault of clang, or fault of people in this newsgroup. > > Even a non-beginner who has spent years using integrated packages would > be surprised that some compilers are split up into separate parts. (Like > buying a new car but having to source the engine and the wheels > separately. And not actually being told that so being surprised because > you're used to cars having those included.) > >> However, the OP is posting from a *nix system - FreeBSD, according to >> the post's headers. He will therefore have all the headers and >> libraries he needs, either installed already or just a "pkg install" >> away. > > In that case he's got no problems because Unix users like to have their > hands held (the opposite to what is usually claimed). > *nix users usually like convenience as much as any other users. I /have/ compiled gcc from source (for a number of different target processors), as well as finding, building and installing the appropriate libraries and headers. But it is a lot faster and easier to use ready-made packages when they are available.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 17:24 +0100 |
| Message-ID | <nn5efn$v7$1@dont-email.me> |
| In reply to | #91004 |
On 25/07/2016 15:57, David Brown wrote: > On 25/07/16 16:14, BartC wrote: >> Pelles C includes everything. lccwin32 includes everything. Digital Mars >> C includes everything. Tiny C includes everything. The MSVC I bought >> years ago including everything. > > Those are not compilers - they are development suites of which a > compiler is one part. > > Now, it is an understandable mistake to think that clang or gcc are the > same sort of thing as these tools - but it is a mistake. On whose part? The mistake I think is for those products not to make it absolutely clear what they are, what they do and what they need. Their > websites, or at least their "getting started" information could no doubt > be more helpful here. Clang's getting started page is about building it from sources. The download page is simply a list of links. For Windows pre-built binaries, it's just a link to an exe file. If there is any useful information of the kind I've had to discover the hard way, then I haven't found it yet. A lot of the info is also to do with LLVM, an aspect that is unlikely to be of interest, or be meaningful, to either beginners or those wanting to try a new compiler. If you suggest using Visual Studio in order to use clang, then it might be worth bearing in mind that VS is a behemoth that can be 100 to 200 times the size of the Clang download, not itself lightweight. >> No beginner wants to know about this stuff. They want >> something that Just Works. They are not interested in the fine >> distinctions between a compiler, includes, libraries and utilities. > > I am not trying to sell you anything here - I am just telling you the > facts. If you want to campaign on behalf of all these "beginners" who > want to program in C on Windows, specifically using gcc or clang, and > want something that "just works", then feel free to do so. I should > expect you could put together binary packages for clang and gcc, along > with libraries, include files, a debugger, and an IDE, all within a > single installer file. I don't even think it would be a huge effort > (though testing it all on different versions of Windows might be a > pain). But please stop making it look as though this is the fault of > gcc, or the fault of clang, or fault of people in this newsgroup. The problem is those packages are very large and complex. If I was in charge, I would want to eliminate 99% of them just to get started. That is not going to happen. >> In that case he's got no problems because Unix users like to have their >> hands held (the opposite to what is usually claimed). > *nix users usually like convenience as much as any other users. I > /have/ compiled gcc from source (for a number of different target > processors), as well as finding, building and installing the appropriate > libraries and headers. My own compiler (static source code to native code), can be fully re-compiled (source to bytecode) in about 0.03 seconds (it was 2 seconds last time this was discussed; I've been busy). How long does gcc take to compile again? See, I /know/ how to keep things small, simple, fast and very easy for users. Many seem to have forgotten. BTW to get that 0.03 seconds involved targeting C (for the bytecode compiler project source) and running gcc -03 on it. If I relied only on my toy language, it would take 0.04 seconds. So as far as I'm concerned, the difference between gcc and my project is 0.01 seconds less runtime; 33% extra performance. gcc however is a considerably more massive project. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-25 15:29 -0700 |
| Message-ID | <d8203c30-aff8-414b-aa0d-7da127b5c069@googlegroups.com> |
| In reply to | #91004 |
On Monday, July 25, 2016 at 9:57:28 AM UTC-5, David Brown wrote: > I have no idea what /you/ are supposed to know about. I /do/ know that > most OS's include assemblers, linkers, libraries, and headers (and > usually compilers too) as part of their basic packaging - Windows is > fairly unique in not doing so. I also know that some compiler > manufacturers - gcc and clang being prime examples - make compilers, not > development suites or even complete C implementations. What other non-Unix microcomputer operating systems have you looked at? I would consider Unix the oddball in that regard rather than Windows, at least in the microcomputer arena. I'm also puzzled by why people don't think the runtime library should bundled with the compiler; for things like file I/O, a compiler that targets a particular OS should supply a library that interfaces to the underlying I/O mechanisms of the underlying platform in language-agnostic fashion. There should be no problem using the same OS to run some C source programs that expect "long" to be 32 bits and others that expect it to be 64 bits, provided that each program is processed using a bundled compiler and library configured for its requirements. Having programs invoke the OS "printf" functions rather than one that's bundled at build time requires that all programs using that function must use the same size of "long"; in the days when a 64K machine was considered "big", having a compiled program share the OS printf routine may have been advantageous, but such advantages have dwindled to nothing as machines have gotten larger.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-25 16:00 -0700 |
| Message-ID | <ln37mxcohv.fsf@kst-u.example.com> |
| In reply to | #91067 |
supercat@casperkitty.com writes:
> On Monday, July 25, 2016 at 9:57:28 AM UTC-5, David Brown wrote:
>> I have no idea what /you/ are supposed to know about. I /do/ know that
>> most OS's include assemblers, linkers, libraries, and headers (and
>> usually compilers too) as part of their basic packaging - Windows is
>> fairly unique in not doing so. I also know that some compiler
>> manufacturers - gcc and clang being prime examples - make compilers, not
>> development suites or even complete C implementations.
>
> What other non-Unix microcomputer operating systems have you looked at?
> I would consider Unix the oddball in that regard rather than Windows, at
> least in the microcomputer arena.
What other non-Unix microcomputer operating systems are there?
I know there are a few non-Unix non-Windows operating systems,
but none of them are particularly common.
> I'm also puzzled by why people don't think the runtime library should
> bundled with the compiler; for things like file I/O, a compiler that
> targets a particular OS should supply a library that interfaces to the
> underlying I/O mechanisms of the underlying platform in language-agnostic
> fashion. There should be no problem using the same OS to run some C
> source programs that expect "long" to be 32 bits and others that expect
> it to be 64 bits, provided that each program is processed using a bundled
> compiler and library configured for its requirements. Having programs
> invoke the OS "printf" functions rather than one that's bundled at build
> time requires that all programs using that function must use the same size
> of "long"; in the days when a 64K machine was considered "big", having a
> compiled program share the OS printf routine may have been advantageous,
> but such advantages have dwindled to nothing as machines have gotten larger.
There's nothing fundamentally wrong with bundling a runtime library with
a compiler, but there are advantages to distributing them separately.
For example, even if I didn't have a compiler installed on my system,
I'd still be able to run dynamically linked executables that were built
elsewhere. Someone who distributes an *application* doesn't have to
distribute the C runtime library along with it, they can just assume
that it's present, whether the user has a compiler or not. (The Linux
distribution I use has gcc preinstalled, but others might not.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-25 16:31 -0700 |
| Message-ID | <acfa3004-b897-4e0e-a0cc-c4340de5f1fd@googlegroups.com> |
| In reply to | #91068 |
On Monday, July 25, 2016 at 6:00:20 PM UTC-5, Keith Thompson wrote: > supercat writes: > > What other non-Unix microcomputer operating systems have you looked at? > > I would consider Unix the oddball in that regard rather than Windows, at > > least in the microcomputer arena. > > What other non-Unix microcomputer operating systems are there? > I know there are a few non-Unix non-Windows operating systems, > but none of them are particularly common. Windows and Unix have together displaced almost everything else, but there used to be lots of microcomputer operating systems. GEM, AmigaDos, Geos, MS-DOS, Apple DOS 3.3, Apple ProDOS, CP/M, classic MacOS, etc. I don't think any but Unix were bundled with C compilers. > There's nothing fundamentally wrong with bundling a runtime library with > a compiler, but there are advantages to distributing them separately. > For example, even if I didn't have a compiler installed on my system, > I'd still be able to run dynamically linked executables that were built > elsewhere. If the compiler statically links in parts of the library that are used within a DLL, it can substitute simplified versions in cases where it can make inferences about the arguments. For example, if a piece of code never passes anything other than a literal format string to sprintf, a compiler could replace sprintf with a collection of small functions that are customized to support the formatting options the program actually uses. Separating the library from the compiler makes it unclear what a compiler is or is not allowed to assume about the way the library is used. For example, in what cases would a compiler be allowed or not allowed to replace a matched pair of malloc/free calls with a stack allocation? If the compiler was supplying malloc/free, it would know of any and all guarantees and features the get/free might offer beyond what the Standard requires, but if the compiler links with an external one, it may have no way of knowing what guarantees the external version might offer and a programmer may have no way of knowing what guarantees offered by a malloc/free implementation will be passed through by the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-25 17:06 -0700 |
| Message-ID | <lny44pb6v7.fsf@kst-u.example.com> |
| In reply to | #91069 |
supercat@casperkitty.com writes:
> On Monday, July 25, 2016 at 6:00:20 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > What other non-Unix microcomputer operating systems have you looked at?
>> > I would consider Unix the oddball in that regard rather than Windows, at
>> > least in the microcomputer arena.
>>
>> What other non-Unix microcomputer operating systems are there?
>> I know there are a few non-Unix non-Windows operating systems,
>> but none of them are particularly common.
>
> Windows and Unix have together displaced almost everything else, but there
> used to be lots of microcomputer operating systems. GEM, AmigaDos, Geos,
> MS-DOS, Apple DOS 3.3, Apple ProDOS, CP/M, classic MacOS, etc. I don't
> think any but Unix were bundled with C compilers.
>
>> There's nothing fundamentally wrong with bundling a runtime library with
>> a compiler, but there are advantages to distributing them separately.
>> For example, even if I didn't have a compiler installed on my system,
>> I'd still be able to run dynamically linked executables that were built
>> elsewhere.
>
> If the compiler statically links in parts of the library that are used
> within a DLL, it can substitute simplified versions in cases where it can
> make inferences about the arguments. For example, if a piece of code
> never passes anything other than a literal format string to sprintf, a
> compiler could replace sprintf with a collection of small functions that
> are customized to support the formatting options the program actually
> uses.
A compiler can typically do that anyway. For example, gcc can replace
printf("hello\n") by puts("hello").
> Separating the library from the compiler makes it unclear what a compiler
> is or is not allowed to assume about the way the library is used. For
> example, in what cases would a compiler be allowed or not allowed to replace
> a matched pair of malloc/free calls with a stack allocation? If the
> compiler was supplying malloc/free, it would know of any and all guarantees
> and features the get/free might offer beyond what the Standard requires, but
> if the compiler links with an external one, it may have no way of knowing
> what guarantees the external version might offer and a programmer may have
> no way of knowing what guarantees offered by a malloc/free implementation
> will be passed through by the compiler.
A compiler can assume that sprintf, malloc, and free meet the
requirements specified by the standard. I can imagine that a
particular implementation might make more guarantees, but I wouldn't
expect such guarantees to be massively useful.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-26 07:52 -0700 |
| Message-ID | <8eb73c92-0153-4763-87aa-3b1540738e5e@googlegroups.com> |
| In reply to | #91071 |
On Monday, July 25, 2016 at 9:33:14 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > If the compiler statically links in parts of the library that are used
> > within a DLL, it can substitute simplified versions in cases where it can
> > make inferences about the arguments. For example, if a piece of code
> > never passes anything other than a literal format string to sprintf, a
> > compiler could replace sprintf with a collection of small functions that
> > are customized to support the formatting options the program actually
> > uses.
>
> A compiler can typically do that anyway. For example, gcc can replace
> printf("hello\n") by puts("hello").
It can only do that because there's a standard library routine that's a
direct replacement. If a program uses the %08X format specifier a lot
and no other, a compiler that's responsible for supplying the RTL could
bundle a "__sprintfHex8" function and replace printf("%08X", value)" with
a call to __sprintfHex8, but a compiler couldn't expect to find that
function in an externally-supplied library.
> A compiler can assume that sprintf, malloc, and free meet the
> requirements specified by the standard. I can imagine that a
> particular implementation might make more guarantees, but I wouldn't
> expect such guarantees to be massively useful.
How should that behave if the externally-supplied library includes
inline size_t get_alloc_size(void *x) { return (((uint32_t*)(x))[-1]); }
to retrieve the size of an allocated region? If the library ensures
that the 32 bits before each allocation hold the size thereof, the
above function should work, but if a compiler substituted its own
malloc() function in some cases the code could fail very badly.
The Standard doesn't mandate that compilers must interact nicely with
external libraries in such cases, but that doesn't meant that quality
compilers shouldn't provide a means of making such things work.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-26 08:20 -0700 |
| Message-ID | <lnlh0obf3f.fsf@kst-u.example.com> |
| In reply to | #91087 |
supercat@casperkitty.com writes:
> On Monday, July 25, 2016 at 9:33:14 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > If the compiler statically links in parts of the library that are used
>> > within a DLL, it can substitute simplified versions in cases where it can
>> > make inferences about the arguments. For example, if a piece of code
>> > never passes anything other than a literal format string to sprintf, a
>> > compiler could replace sprintf with a collection of small functions that
>> > are customized to support the formatting options the program actually
>> > uses.
>>
>> A compiler can typically do that anyway. For example, gcc can replace
>> printf("hello\n") by puts("hello").
>
> It can only do that because there's a standard library routine that's a
> direct replacement. If a program uses the %08X format specifier a lot
> and no other, a compiler that's responsible for supplying the RTL could
> bundle a "__sprintfHex8" function and replace printf("%08X", value)" with
> a call to __sprintfHex8, but a compiler couldn't expect to find that
> function in an externally-supplied library.
A compiler can provide, as part of its installation package, its own
library to supplement the one provided by the system or by another
package (assuming, in this case, that optimizing "%08X" is worthwhile).
Sure, there are some advantages to packaging a runtime library with a
compiler. There are also advantages to managing them separately.
One such advantage is that I can use gcc on systems that don't have
glibc.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-26 16:23 +1200 |
| Message-ID | <dvo6tdFfb5cU4@mid.individual.net> |
| In reply to | #91069 |
On 07/26/16 11:31 AM, supercat@casperkitty.com wrote: > > Separating the library from the compiler makes it unclear what a compiler > is or is not allowed to assume about the way the library is used. For > example, in what cases would a compiler be allowed or not allowed to replace > a matched pair of malloc/free calls with a stack allocation? If the > compiler was supplying malloc/free, it would know of any and all guarantees > and features the get/free might offer beyond what the Standard requires, but > if the compiler links with an external one, it may have no way of knowing > what guarantees the external version might offer and a programmer may have > no way of knowing what guarantees offered by a malloc/free implementation > will be passed through by the compiler. malloc/free is a particularly bad example to use. The behaviour is specified in the standard and typical Unix and Unix like platforms provide specialised implementations along with their standard allocator. If the malloc and free where statically linked, the platform couldn't do this. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-26 07:17 +0200 |
| Message-ID | <nn6ron$bd5$2@dont-email.me> |
| In reply to | #91069 |
Le 26/07/2016 à 01:31, supercat@casperkitty.com a écrit : > Separating the library from the compiler makes it unclear what a compiler > is or is not allowed to assume about the way the library is used. To give a popular example: The gcc compiler under the "mingw" version (windows) recognizes long double and generates code for 80 bits longs double. But mingw uses the Microsoft C library, and that printf doesn't recognize long doubles, since Microsoft doesn't support them. We have answered MANY times questions here from people that ask why their printf "wasn't working". Separating the library from the compiler is just NONSENSE!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-26 00:56 -0700 |
| Message-ID | <lnpoq0bzo3.fsf@kst-u.example.com> |
| In reply to | #91076 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 26/07/2016 à 01:31, supercat@casperkitty.com a écrit :
>> Separating the library from the compiler makes it unclear what a compiler
>> is or is not allowed to assume about the way the library is used.
>
> To give a popular example: The gcc compiler under the "mingw" version
> (windows) recognizes long double and generates code for 80 bits longs
> double. But mingw uses the Microsoft C library, and that printf doesn't
> recognize long doubles, since Microsoft doesn't support them. We have
> answered MANY times questions here from people that ask why their printf
> "wasn't working".
>
> Separating the library from the compiler is just NONSENSE!
Separating the library from the compiler is what made MinGW possible in
the first place.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-27 15:17 +0000 |
| Message-ID | <5798ceed.3489562@news.xs4all.nl> |
| In reply to | #91080 |
Keith Thompson <kst-u@mib.org> wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > > Le 26/07/2016 à 01:31, supercat@casperkitty.com a écrit : > >> Separating the library from the compiler makes it unclear what a compiler > >> is or is not allowed to assume about the way the library is used. > > > > To give a popular example: The gcc compiler under the "mingw" version > > (windows) recognizes long double and generates code for 80 bits longs > > double. But mingw uses the Microsoft C library, and that printf doesn't > > recognize long doubles, since Microsoft doesn't support them. We have > > answered MANY times questions here from people that ask why their printf > > "wasn't working". > > > > Separating the library from the compiler is just NONSENSE! > > Separating the library from the compiler is what made MinGW possible in > the first place. Well, that explains why there were no ports of GCC to Microsoft platforms before MinGW. Good thing DJ Delorie never gave up his day job as a shrimp fisherman, then. Sorry, Keith, but in this case, supercat and jacob are mostly(!) right and you are mostly(!) wrong. There _are_ reasons for separating the compiler from the library, and a few of them are good, but the main one does appear to be the ability to pass the buck around when the two don't work together. The reasons for keeping the development of the implementation in one hand are more important to me. I prefer a complete implementation, not a bunch of parts sourced from incestuous-but-legally-separate parties. I don't buy my car as a DIY kit, either. I'll assemble my own furniture, because that only has to stay up, but as soon as something has to do work, like a car or a C implementation, I want it built by the vendor, not by me. Richard
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web