Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106884 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-03-24 11:25 +0100 |
| Last post | 2017-03-30 00:50 -0700 |
| Articles | 20 on this page of 287 — 34 participants |
Back to article view | Back to comp.lang.c
Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 11:25 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 11:04 +0000
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 11:44 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 12:59 +0100
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:01 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 12:39 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:17 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 13:38 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:50 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 14:20 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:49 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:35 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:51 +0000
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-03-24 23:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:43 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 17:57 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 18:13 +0000
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:32 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 12:11 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 19:56 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 13:48 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:17 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 22:40 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:56 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:19 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:30 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-25 12:46 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:10 +0000
Re: Even more problems with lcc-win gordonb.l3ybu@burditt.org (Gordon Burditt) - 2017-03-27 03:34 -0500
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 11:41 +0100
Re: Even more problems with lcc-win gordonb.15yss@burditt.org (Gordon Burditt) - 2017-03-27 14:48 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 13:31 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 22:22 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 15:05 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 23:22 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 00:35 +0200
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:09 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:01 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 12:33 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:44 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:37 -0700
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:03 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 13:15 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:35 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 15:30 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-21 18:44 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:08 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 10:26 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-23 19:08 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 14:26 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:52 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:31 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 20:42 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 22:32 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:37 +0000
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 07:13 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-27 07:54 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-27 18:20 -0500
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:23 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-30 18:18 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:12 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-05-01 11:14 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:29 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 16:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-28 13:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 15:20 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 16:50 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 09:28 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 19:45 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 12:06 -0700
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 20:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:33 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 13:10 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:15 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:23 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:29 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:47 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:46 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 23:46 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 00:53 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 02:00 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:05 -0700
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-29 10:57 -0400
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 17:06 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 08:39 -0700
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:29 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 23:44 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 12:33 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 08:54 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 17:38 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 16:42 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:28 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 20:09 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 13:29 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:18 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-30 08:22 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 00:20 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:38 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:19 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:29 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 01:36 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 22:36 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 23:50 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 10:57 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 11:15 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-30 09:22 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 18:50 +0200
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-31 09:31 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 10:26 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:23 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:01 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:51 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-02 23:04 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-03 22:09 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:24 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:52 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 12:26 +1300
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 12:00 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:43 +0200
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 13:38 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 14:21 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-31 04:30 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-31 09:39 +0200
Re: Even more problems with lcc-win jadill33@gmail.com - 2017-03-30 07:12 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:10 -0500
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:25 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 14:55 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 16:11 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 16:40 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 18:14 +0200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:32 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:53 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-21 00:36 +0100
Re: Even more problems with lcc-win Thiago Adams <thiago.adams@gmail.com> - 2017-04-24 05:41 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-24 15:14 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-04-26 14:02 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-26 16:04 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 12:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 14:43 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 23:21 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:58 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 11:10 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 00:09 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 01:51 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 01:58 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 12:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:29 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:23 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 11:59 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 14:41 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 11:08 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 12:02 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 14:32 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 14:40 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 16:47 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 16:56 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 18:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 20:02 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:49 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 13:26 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 13:33 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 22:28 +0100
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-09 13:54 +1200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-09 07:55 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:45 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:53 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-09 14:03 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-10 16:17 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-14 10:24 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-14 12:29 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:04 +0000
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-08 14:13 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 14:33 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-08 07:36 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 10:22 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:11 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:28 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:44 -0700
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-04-08 08:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 12:29 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 13:46 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 14:10 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 21:59 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-31 00:19 +0100
Re: Even more problems with lcc-win me <crisdunbar@gmail.com> - 2017-03-30 17:53 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-31 11:34 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:35 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 04:38 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:14 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:38 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-31 08:52 +1300
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:58 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-02 17:02 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:50 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 23:10 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 07:20 +1200
Optimized? (Was: Even more problems with lcc-win) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-02 19:39 +0000
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-02 15:59 -0400
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-02 14:11 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 17:08 +1200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:42 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:58 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 16:57 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 14:31 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:54 -0500
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 08:07 -0700
Re: Even more problems with lcc-win gordonb.uls6t@burditt.org (Gordon Burditt) - 2017-03-29 18:17 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 19:20 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 18:49 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:07 +0100
Re: Even more problems with lcc-win gordonb.b709o@burditt.org (Gordon Burditt) - 2017-04-16 03:45 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-16 16:34 +0100
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-04-16 20:27 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-16 12:16 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-17 02:29 -0500
Re: Even more problems with lcc-win Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-27 19:01 -0400
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 23:19 +0100
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 19:10 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-26 00:54 +0100
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-25 19:48 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-26 05:12 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:00 -0700
Re: Even more problems with lcc-win gordonb.zdxct@burditt.org (Gordon Burditt) - 2017-03-27 02:03 -0500
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:39 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 09:13 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 11:24 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 08:42 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 19:51 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 09:10 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:24 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-25 13:43 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 10:30 +1300
Re: Even more problems with lcc-win Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-26 10:23 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:08 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 22:43 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:55 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 16:27 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:17 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:18 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 15:06 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 16:37 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 16:25 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:57 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 19:12 +0100
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 14:19 -0500
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 19:25 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:10 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:01 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:07 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 15:48 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 16:26 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:32 +0000
Re: Even more problems with lcc-win James Kuyper <jameskuyper@verizon.net> - 2017-03-24 12:53 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 18:24 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 17:29 +0000
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-24 10:55 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 10:47 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 09:37 -0700
Re: Even more problems with lcc-win Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:07 -0500
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 09:56 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:39 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 12:22 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 16:58 -0700
Re: Even more problems with Seed7 jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 01:02 +0200
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:05 -0500
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:19 -0500
Re: Even more problems with Seed7 mertesthomas@gmail.com - 2017-04-02 04:19 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:34 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 13:05 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-31 00:00 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-04-02 00:28 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:50 -0700
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-08 14:13 +0100 |
| Message-ID | <87pognm48m.fsf@gmail.com> |
| In reply to | #107857 |
David Brown <david.brown@hesbynett.no> writes: >> And by striving to be so ambitious, the end result is that there is no >> viable linker at all. Or if there is, I've no idea how it's supposed to >> work. >> > > As always, other people seem to manage fine. Yes, but they're not morons.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-08 14:33 +0100 |
| Message-ID | <qE5GA.285580$o87.196824@fx21.am4> |
| In reply to | #107865 |
On 08/04/2017 14:13, Gareth Owen wrote: > David Brown <david.brown@hesbynett.no> writes: > >>> And by striving to be so ambitious, the end result is that there is no >>> viable linker at all. Or if there is, I've no idea how it's supposed to >>> work. >>> >> >> As always, other people seem to manage fine. > > Yes, but they're not morons. > Fuck off.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-08 07:36 +0200 |
| Message-ID | <oc9smv$qqq$1@dont-email.me> |
| In reply to | #107829 |
Le 07/04/2017 à 20:02, David Brown a écrit : > Compilers will often provide /some/ include files. The C standard > library (and the standard C++ library) will also provide include files. > I don't imagine LLVM provides them, but I am sure clang has a few. But > those will be specific to the compiler, rather than host system include > files like windows.h. In the "requirements" section of their official web page, clang lists visual studio as a REQUIREMENT clang will not work without visual studio. It is explicitely stated in their docs. http://llvm.org/docs/GettingStarted.html#requirements If you disagree with that, or think like Bart apparently does, that that is not justified, then the solution is simple: Do not use clang. If you do, you should buy visual studio and you will have another 64 bit compiler. Surely they integrate OK in the IDE,
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-08 10:22 +0100 |
| Message-ID | <cZ1GA.331278$iJ3.228427@fx15.am4> |
| In reply to | #107845 |
On 08/04/2017 06:36, jacobnavia wrote: > Le 07/04/2017 à 20:02, David Brown a écrit : >> Compilers will often provide /some/ include files. The C standard >> library (and the standard C++ library) will also provide include files. >> I don't imagine LLVM provides them, but I am sure clang has a few. But >> those will be specific to the compiler, rather than host system include >> files like windows.h. > > In the "requirements" section of their official web page, clang lists > visual studio as a > > REQUIREMENT > > clang will not work without visual studio. It is explicitely stated in > their docs. > > http://llvm.org/docs/GettingStarted.html#requirements I'm not sure that's what it says. First, that page is about LLVM, not about Clang. Also it seems to be about /building/ LLVM, rather than using it. The Requirements table that I assume you are referring too, lists Visual Studio as a needed compiler for Windows x64. But on other platforms, it requires Clang. How can Clang require itself? A few sections further on, it talks about the Host C++ Toolchain, and again mentions the three compilers in the Requirements table: GCC, Clang and Visual Studio. (It also says, below the table, that Debug builds require a lot of time and a lot of disk space: 1-3GB for LLVM-only, and 15-20GB for LLVM /and/ Clang. Forget the size needed - it is now making a confusing distinction between LLVM and Clang.) So I don't think this is about running Clang.exe on Windows at all. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-07 11:11 -0700 |
| Message-ID | <lnpogoxf3f.fsf@kst-u.example.com> |
| In reply to | #107819 |
bartc <bc@freeuk.com> writes:
> On 03/04/2017 15:47, David Brown wrote:
>> On 03/04/17 15:40, bartc wrote:
> [About clang on Windows]
>
>>> (1) By itself, it can't compile Hello World. Because it piggybacks onto
>>> another compiler. (I think this used to be gcc, and now it might be
>>> MSVC. The fact is I couldn't get a recent download working)
>>
>> It is a compiler, not a full C implementation.
>
> What does a compiler do, and what should be its output?
>
>> A C compiler does not
>> have a library or a assembler or a linker.
>
> Does it have a set of standard include files? If not, where do they come
> from? Wikipedia tells me clang is a front-end to LLVM. So, does LLVM
> provided the includes files? If not, where are they?
In a clang installation, LLVM is part of the compiler. As I
understand it, the clang/LLVM distinction is about the internal
organization of the compiler itself. It has nothing to do
with headers or the library. (I don't entirely understand the
organization myself.) If you want a description of what LLVM is,
Google it; the first paragraph of the Wikipedia article has what
I presume to be a decent summary.
[...]
> If I reduce the program to just:
>
> extern int printf(char*,...);
>
> int main(void) {
> printf("Hello World!\n");
> }
>
> it complains about a incompatible declaration of printf warning.
Declaring printf correctly might have helped -- and clang's warning
tells you what the problem is ("char*" should be "const char*").
Actually it should be
extern int printf(const char * restrict, ...);
but clang doesn't seem to complain if the "restrict" is missing.
[...]
> It's even easier to just install those and use them; why bother with
> clang at all? And where would we all be if the developers of MSVC, mingw
> and other compilers took the same approach, requiring people to download
> another compiler to provide the missing bits?!
Your complaint is about the difficulty of installing clang on Windows.
This is not a C language issue; it's a software packaging issue. I
suggest you go the web site where you downloaded clang, look for a
contact link, and describe your problem to them. Perhaps they can help.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 19:28 +0100 |
| Message-ID | <kTQFA.825984$qK5.74893@fx45.am4> |
| In reply to | #107830 |
On 07/04/2017 19:11, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> It's even easier to just install those and use them; why bother with >> clang at all? And where would we all be if the developers of MSVC, mingw >> and other compilers took the same approach, requiring people to download >> another compiler to provide the missing bits?! > > Your complaint is about the difficulty of installing clang on Windows. > This is not a C language issue; it's a software packaging issue. It's a QoI issue. I complained at the top of the subthread about the fact that a 0.2MB program managed to compile hello.c (in terms of getting the expected output), while the (now) 67MB clang couldn't. The first obstacle being the lack of any standard headers of its own, even though it's 300 times the size. (5000 times the size if you consider the entire download.) I wouldn't mind running clang as an alternative to gcc if the choice was there, but if the developers are going to make that difficult, then forget it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-07 11:44 -0700 |
| Message-ID | <lnlgrcxdk0.fsf@kst-u.example.com> |
| In reply to | #107831 |
bartc <bc@freeuk.com> writes:
[...]
> I wouldn't mind running clang as an alternative to gcc if the choice was
> there, but if the developers are going to make that difficult, then
> forget it.
Either ask the developers for help, or forget it. Whining about it here
will not help.
--
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 | jameskuyper@verizon.net |
|---|---|
| Date | 2017-04-08 08:00 -0700 |
| Message-ID | <e4283382-ba9a-41ce-8411-151b5c09a73d@googlegroups.com> |
| In reply to | #107831 |
On Friday, April 7, 2017 at 2:28:40 PM UTC-4, Bart wrote: > On 07/04/2017 19:11, Keith Thompson wrote: > > bartc <bc@freeuk.com> writes: > > >> It's even easier to just install those and use them; why bother with > >> clang at all? And where would we all be if the developers of MSVC, mingw > >> and other compilers took the same approach, requiring people to download > >> another compiler to provide the missing bits?! > > > > Your complaint is about the difficulty of installing clang on Windows. > > This is not a C language issue; it's a software packaging issue. > > It's a QoI issue. I complained at the top of the subthread about the > fact that a 0.2MB program managed to compile hello.c (in terms of > getting the expected output), while the (now) 67MB clang couldn't. So, why are you bringing that up here? What good do you expect to achieve by complaining about that here? No one here is either willing or able to do anything about that. The clang people could do something about it, if they were willing to do so. It seems unlikely that they would be willing - providing only the compiler, and not the corresponding C standard library, seems to have been a carefully thought out decision on their part, one they're unlikely to change just because you don't like it. However, they're the only ones who can change that decision - so complaining to them about it is the only thing that has any chance (however remote) of resulting in a change.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 12:29 +0100 |
| Message-ID | <OJKFA.782917$F83.48804@fx38.am4> |
| In reply to | #107667 |
On 03/04/2017 13:32, David Brown wrote: > On 03/04/17 13:02, bartc wrote: > If building a program is fast enough for /me/, then it does not matter > to /me/. I am quite happy to accept that other people find compilation > speed more of an issue. However, I don't believe that the speed of C > compilation is as much an issue as you seem to believe - not by a long > way. And I don't believe you have a realistic view about what is > relevant to the compilation speed of actual programs and real compilers. I've been using a laptop the last few days. It's not particularly slow (half the CPU speed of my PC?) but it runs off slow SD storage or something because working with C takes ages. I had to use Tiny C, and even that has an annoying lag. And linking my 20-module project took 3 seconds. It was horrible. (That doesn't sound much, but imagine you're doing a good lick down the motorway but are forced to keep stopping, then counting slowly to three, before proceeding. You lose momentum, and in my case, concentration. I couldn't use my own compiler because that relies on using 'ld' directly and that gives a problem under Windows 10. All good reasons why I'm keen to dump the lot and just use my own streamlined tools.) >> Imagine compiling gcc from source every time you invoke 'gcc'. Would it >> still take only 36msec to compile a bunch of headers? > > Imagine making a computer with lego-style connections so that every time > you want to turn it on, you can re-build it. > > Tell me, what use would that be? There are advantages to running things from source. I mean, isn't that what Python does, and a bunch of other scripting languages? Wouldn't it be great to eliminate the concept of a 'compiler' and 'linker' and just say 'run'? And without some elaborate process working furiously behind the scenes to make that practical using existing and cumbersome compilers and linkers. However, many require precompilation to byte-code, which might give enough lag that caching schemes might need to be used. With my [interpreter] system, there is virtually no lag. > What use is a compiler that needs to be compiled every time it is > invoked? (Ignoring chicken-and-egg issues for the moment.) /Why/ would > I possibly want to compile the compiler before every use? You're not thinking the right way. Why would you want to explicitly 'compile' anything at all? Here's the source code, now just run it! > I is nice that it is /possible/ to compile the compiler, and > occasionally it can be essential. But mostly I, like almost everyone > else, get ready-made binaries for my compilers. Because, as things are now, it's a usually a nightmare. But if the compiler was a single source file and it could be compiled in a tenth of a second, then it wouldn't appear to be such a big deal. And the compilation stage would be transparent in that case. >> This is the difference between you and me: I have misgivings about a >> computer doing the same pointless work over and over, when it could be >> done once and for all, and you don't provided it's still fast enough. >> > > You want to compile the compiler before every use, but don't like > pointless repetition? Something is wrong somewhere... Compare with gcc compiling the same tens of thousands of lines of headers repeatedly, even though they haven't changed for a year. Even though it might take only a few tens of milliseconds, it doesn't sound right to me. Just like compiling my compiler before use didn't seem right although it was fast enough to be quite practical. So a solution that involved recording the results of a compilation was used (like turning C source files into an executable). And similar solutions can be found to avoid recompiling C headers even if, by themselves, they are not significantly slow. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-07 13:46 +0200 |
| Message-ID | <oc7u1p$1q5$1@dont-email.me> |
| In reply to | #107809 |
On 07/04/17 13:29, bartc wrote: > On 03/04/2017 13:32, David Brown wrote: >> On 03/04/17 13:02, bartc wrote: > >>> Imagine compiling gcc from source every time you invoke 'gcc'. Would it >>> still take only 36msec to compile a bunch of headers? >> >> Imagine making a computer with lego-style connections so that every time >> you want to turn it on, you can re-build it. >> >> Tell me, what use would that be? > > There are advantages to running things from source. I mean, isn't that > what Python does, and a bunch of other scripting languages? Wouldn't it > be great to eliminate the concept of a 'compiler' and 'linker' and just > say 'run'? And without some elaborate process working furiously behind > the scenes to make that practical using existing and cumbersome > compilers and linkers. There are plenty of advantages in scripting languages - or having an interpreted version of C. But you were suggesting compiling the compiler every time you want to use it - that's another step backwards. (And compiling is very different from interpreting - it would make sense to use an interpreted high-level language like Python for writing a small C compiler. It would run slower than one written in C or C++, but be much easier to write.) > > However, many require precompilation to byte-code, which might give > enough lag that caching schemes might need to be used. With my > [interpreter] system, there is virtually no lag. > >> What use is a compiler that needs to be compiled every time it is >> invoked? (Ignoring chicken-and-egg issues for the moment.) /Why/ would >> I possibly want to compile the compiler before every use? > > You're not thinking the right way. Why would you want to explicitly > 'compile' anything at all? Here's the source code, now just run it! Again, that's fine - for the /user/ code. But you have suggested compiling the /compiler/ for every use. It makes sense for Python code to be interpreted each run, and run on a virtual machine. But it does /not/ make sense for the Python interpreter, or the Python virtual machine, to be re-compiled for every run of a Python script! > >> I is nice that it is /possible/ to compile the compiler, and >> occasionally it can be essential. But mostly I, like almost everyone >> else, get ready-made binaries for my compilers. > > Because, as things are now, it's a usually a nightmare. Not in my experience - either on Linux or Windows. Installation of gcc from binaries tends to be painless - I have quite a number of such packages (different versions, different target devices) on both systems. > But if the > compiler was a single source file and it could be compiled in a tenth of > a second, then it wouldn't appear to be such a big deal. And the > compilation stage would be transparent in that case. Except, of course, for Windows - where there is no system C compiler to compile your new compiler. You have a chicken-and-egg problem. > >>> This is the difference between you and me: I have misgivings about a >>> computer doing the same pointless work over and over, when it could be >>> done once and for all, and you don't provided it's still fast enough. >>> >> >> You want to compile the compiler before every use, but don't like >> pointless repetition? Something is wrong somewhere... > > Compare with gcc compiling the same tens of thousands of lines of > headers repeatedly, even though they haven't changed for a year. > > Even though it might take only a few tens of milliseconds, it doesn't > sound right to me. Just like compiling my compiler before use didn't > seem right although it was fast enough to be quite practical. > > So a solution that involved recording the results of a compilation was > used (like turning C source files into an executable). And similar > solutions can be found to avoid recompiling C headers even if, by > themselves, they are not significantly slow. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 14:10 +0100 |
| Message-ID | <GcMFA.347518$UY3.346722@fx11.am4> |
| In reply to | #107812 |
On 07/04/2017 12:46, David Brown wrote:
> On 07/04/17 13:29, bartc wrote:
>> There are advantages to running things from source. I mean, isn't that
>> what Python does, and a bunch of other scripting languages? Wouldn't it
>> be great to eliminate the concept of a 'compiler' and 'linker' and just
>> say 'run'? And without some elaborate process working furiously behind
>> the scenes to make that practical using existing and cumbersome
>> compilers and linkers.
>
> There are plenty of advantages in scripting languages - or having an
> interpreted version of C.
A purely interpreted C would be difficult I think without a precompile
pass, which is most of what a C compiler is anyway.
(I did think of interpreting C - executing some generated virtual code -
as it's quite an intriguing project. But generating real native code had
more advantages.)
> But you were suggesting compiling the
> compiler every time you want to use it - that's another step backwards.
A compiler is just an application like any other. If it was written in
Python (forgetting about .pyc files for a minute), then you /would/ be
byte-code compiling the C compiler each time it was run.
> (And compiling is very different from interpreting - it would make
> sense to use an interpreted high-level language like Python for writing
> a small C compiler. It would run slower than one written in C or C++,
> but be much easier to write.)
I'm currently using my interpreted language to run my current compiler,
and it's actually faster than gcc, which is written in C or C++. I can
see now C that might be quicker to process than my own language, so a C
compiler in [my] interpreted code would run even faster in comparison.
> Again, that's fine - for the /user/ code. But you have suggested
> compiling the /compiler/ for every use.
And, again, scripting languages - the ones using precompilation to
internal form - do this every time they run application A. The rules
don't change when A happens to be a compiler.
> It makes sense for Python code to be interpreted each run, and run on a
> virtual machine. But it does /not/ make sense for the Python
> interpreter, or the Python virtual machine, to be re-compiled for every
> run of a Python script!
That's exactly what would become practical. At least, with the smaller
interpreters I write (it would add less than 50msec to start-up time).
However, CPython source was something over 200Kloc last time I looked (a
long time back); that would still need half a second to compile on a PC,
with the speeds I'm looking at. In that case, caching can be used (what
is called generating an executable in the classic model).
Such a fast compiler won't produce the best performance either, but
there's no reason why JIT techniques can't be applied so that frequent
execution paths can be optimised. (Although, for a complex app like
this, the difference between poor and good generated code isn't dramatic.)
>> But if the
>> compiler was a single source file and it could be compiled in a tenth of
>> a second, then it wouldn't appear to be such a big deal. And the
>> compilation stage would be transparent in that case.
>
> Except, of course, for Windows - where there is no system C compiler to
> compile your new compiler. You have a chicken-and-egg problem.
A C compiler would be a requisite anyway, for anything supplied as C
source. And that step is done once, to get the fast compiler.
(Actually my compiler isn't written in C and there are other paths to
get an executable.)
All I'm saying is that by moving away from the traditional compile-link
model, and using faster techniques, interesting possibilities arise.
-----------------------
(This is what I really want to do. Suppose my C compiler's C source is a
file called bcc.c, and that is processed - by any means - to get an
executable called 'bcc'. It would be invoked like this:
> bcc hello
to compile /and run/ hello.c (it uses a default .c extension). But this
should also work:
> bcc bcc: hello
That will compile bcc.c, and run that as a new version of the compiler,
which will then process the following arguments. (The ':' is a necessary
artefact at the moment to separate the command parameters.)
I'm interested in finding out how long this takes to execute:
> bcc bcc: bcc: bcc: bcc: bcc: hello
That is, the first bcc is precompiled; then five successive generations
of the compiler are compiled and run, and last one is used to compile
and run Hello World.
If this takes anything under a second on my PC, then I'll be satisfied.
(Remember that only the first bcc might be compiled with gcc -O3; the
others have to run under their own steam. The unknown factor at the
minute is how long it takes to do external fix-ups (equivalent of
'linking').
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-30 21:59 +0000 |
| Message-ID | <objv4i$j39$1@z-news.wcss.wroc.pl> |
| In reply to | #107468 |
bartc <bc@freeuk.com> wrote:
> On 30/03/2017 02:58, antispam@math.uni.wroc.pl wrote:
> > bartc <bc@freeuk.com> wrote:
>
> >> The following sets of includes take 700ms to compile with gcc -O0 on
> >> Windows.
> >
> > On my machine (as above) after removing windows.h (not present on
> > Linux) I get 61-89 ms (7 succesive trials give: 86, 87, 87, 86, 85, 87,
> > 62, one of earlier trials gave 61 another earlier trial gave 89).
>
> Which C compiler, gcc?
Yes. The details are the same as previous test that you snipped.
> If I remove windows.h, my gcc still gives nearly 300ms. (This is
> gcc/tdm/mingw 5.1. Maybe they forgot to specify -O3 when building it! Or
> maybe, I don't know, perhaps the port from Linux involves emulating
> POSIX on top of Windows calls or something, so that file ops are
> inefficient.)
>
> > I also tried on Orange Pi (1.2 GHz ARM), first run was 418ms,
> > second 362ms.
>
> On my 700MHz Pi, 'time' gives me 1.5/1.2 seconds (real/user; I don't
> know what the difference is.)
Real time is "real": that is what independent clock would tell
you. I think this is what you care. And for short tasks is
more accurate than others. User time is CPU utilization in
user mode. There is also system time, that is CPU untilization
by the kernel. As I wrote real time is pretty accurate.
User and system time are estimated and you can expect error
of order 10ms or more.
>
> (I used also my program, but on a smaller set of headers (still no
> windows.h) borrowed from lccwin32.
>
> The program tells me it took 40-70ms, but 'time' reports 0.25/0.05
> seconds. However my program also displays some stats, and writing to the
> screen affects timings when only tens of msec are involved.
time measurs time from start to end. Real time includes time spent
by your program waiting for screen drivers to show the printouts.
BTW: For benchmarking I always redirect results to files to
avoid articats of this sort.
> If I add in <windows.h>, I get 250ms.
>
> But, stop and I think about that: I just said I compiled windows.h on
> Linux, and on a Pi. That was easy because in lccwin32 versions of
> windows.h, only 3 files I think are involved: windows.h, win.h, and
> basetsd.h.
>
> This shows another advantage of keeping things simple. For MSVC headers
> I would need to disentangle 80 files out of hundreds that pertain to
> windows.h. On gcc/mingw, there are 147 files, but some of those are
> standard headers, *and* they are split across multiple directory levels.
>
> Not quite so simple.)
Not so simple for you. But you still ignore fact that gcc folks
write things so that they are simple _to them_. People who
want to pick parts of headers are not their target. More
precisely, headers on real Linux system contain parts
from various sources:
- distributors (Debian, Gentoo,...)
- libraries included in given distribution
- Linux kernel
- gcc
Both Linux kernel and gcc headers are further divided into
platform independent and platform dependend parts. Similarly
for libc. So you have 6 semi-independent parts which are
written by different people. Natural organization is to
split this into separate file. From point of view of
developers ideally the files would be disjoint, that
would be the simplest way. But there are interactions,
so some file appear just as a glue. Sure, this does
not fit your goals. But moaning that other people
do things differently than you would like is not
effective. If you have a lot of money you can try
to bribe them, should work much better. Or you may
try to impose some community law, so that people
do things in certain way because this is how
community is doing things. But community laws
work beacuse they are good for community. You
need first to understand constraints and motives
to propose a good law. And you need to spend
a lot of time explaining benefits of your law
to gain acceptance. You spend a lot of time
posting to comp.lang.c, but even here you have
trouble to convince anybody. And you do not
address relevant fora, namly fora for developers
of systems affecting you.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-31 00:19 +0100 |
| Message-ID | <6ogDA.260059$UY3.108871@fx11.am4> |
| In reply to | #107524 |
On 30/03/2017 22:59, antispam@math.uni.wroc.pl wrote: > bartc <bc@freeuk.com> wrote: >> Not quite so simple.) > > Not so simple for you. But you still ignore fact that gcc folks > write things so that they are simple _to them_. People who > want to pick parts of headers are not their target. No, but the end result is that tools become too elaborate to run on less powerful hardware. It's the equivalent of cars becoming so big and heavy that we all need 5000 BHP engines instead of 50 just to drive to the shops. And it's not just me versus gcc and others creating unwieldy software; many could benefit if only things could be kept smaller and simpler. But there do appear to be at least a few other people thinking along the same lines. Some are also working on their own projects. > You spend a lot of time > posting to comp.lang.c, but even here you have > trouble to convince anybody. That's the trouble, nobody agrees! (BTW I notice the line lengths on your posts tend to get shorter towards the end. Is there a technical reason for that, or is it just style?) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | me <crisdunbar@gmail.com> |
|---|---|
| Date | 2017-03-30 17:53 -0700 |
| Message-ID | <a101067d-ba58-4dc9-85b0-a63566e8251f@googlegroups.com> |
| In reply to | #107527 |
On Thursday, March 30, 2017 at 4:19:37 PM UTC-7, Bart wrote: > On 30/03/2017 22:59, antispam@math.uni.wroc.pl wrote: > > bartc <bc@freeuk.com> wrote: > > >> Not quite so simple.) > > > > Not so simple for you. But you still ignore fact that gcc folks > > write things so that they are simple _to them_. People who > > want to pick parts of headers are not their target. > > No, but the end result is that tools become too elaborate to run on less > powerful hardware. > > It's the equivalent of cars becoming so big and heavy that we all need > 5000 BHP engines instead of 50 just to drive to the shops. > No, it's more like someone designing a 5000BHP diesel locomotive capable of hauling stuff all over the country, and then you whinging that it's a pain in the buttocks to repurpose one of its wheels to help you get to the shops.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-31 11:34 +0200 |
| Message-ID | <20170331113422.b239887dac43ddbbf4d26d06@gmail.com> |
| In reply to | #107527 |
On Fri, 31 Mar 2017 00:19:44 +0100 bartc <bc@freeuk.com> wrote: > That's the trouble, nobody agrees! Not really, only old men on wheelchair way over 50. :o)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 12:35 +0200 |
| Message-ID | <obimsa$5q5$1@dont-email.me> |
| In reply to | #107446 |
On 30/03/17 02:51, bartc wrote:
> On 30/03/2017 01:09, antispam@math.uni.wroc.pl wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>> Just to test, I took this C file:
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <linux/fuse.h>
>>>
>>> int main(void) {
>>> return 0;
>>> }
>>>
>>> "fuse.h" is just a randomly picked Linux header that brings in a good
>>> deal more header files. 46 headers in total, including duplicates - 38
>>> without duplicates. The total is 10.6 K lines, or 336 KB of include
>>> files.
>>>
>>> The compile time for this file was about 20 - 25 ms on my machine.
>>>
>>> I removed the include files, so /no/ pre-processing or includes are
>>> needed.
>>>
>>> The compile time for /this/ file was about 20 - 25 ms on my machine.
>>
>> On may machine (2.4 GHz Core 2, Debian gcc 4.9.2-10) version with
>> headers gave 44-46 ms. Without headers 29-31 ms. gcc -E reports
>> 50 kB for version with headers. So cost of headers is measurable
>> on my machine (OTOH small enough that without measurement I would
>> not notice the difference).
>
> The following sets of includes take 700ms to compile with gcc -O0 on
> Windows.
>
> (Precompiling (when the following was placed in a containing header)
> didn't work or didn't make any difference. If the latter, that would be
> due to the overheads of reading the pch file.)
>
> Other compilers all take less time: 570ms, 220ms, while lccwin was
> around 100ms. But all are using different headers, all different sizes.
> Tiny C was too small to measure.
>
> If you multiply these figures by N modules then it can add up. And there
> are user headers, and other libraries' headers to factor in.
>
> (David Brown will now try and blame Windows OS for being so inefficient;
> it's a never an inefficient compiler or a sprawling set of header files.)
>
> #include <assert.h>
> #include <complex.h>
> #include <ctype.h>
> #include <errno.h>
> #include <fenv.h>
> #include <float.h>
> #include <inttypes.h>
> #include <iso646.h>
> #include <limits.h>
> #include <locale.h>
> #include <math.h>
> #include <setjmp.h>
> #include <signal.h>
> #include <stdarg.h>
> #include <stdbool.h>
> #include <stddef.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <time.h>
> #include <wchar.h>
> #include <wctype.h>
> #include <windows.h>
>
I don't have "windows.h" on my Linux machine (obviously).
Compilation (with "-c", and no linking) took 4-7 milliseconds on this
machine (a slower PC than the other one I tested with). When I include
a minimal main and generate an executable, it was 100 ms the first run,
60-75 ms thereafter.
Yes, at least part of this is the inefficiency of Windows for such
tasks. I know you don't like to hear that, but it is true. You can say
that this is because the design of gcc (with separate binaries and
processes) is better suited to *nix than Windows, but the result is that
compilation is typically faster in Linux than Windows.
In previous tests with compiling a project using a non-gcc
cross-compiler, moving from a Windows machine to a Linux machine
resulted in a factor of about 4 speed improvement despite a slightly
slower cpu. The reason is better file I/O, better caching, much more
efficient process handling, and better SMP support.
On my Windows system (with a slightly faster cpu and an ssd),
compilation only and no "windows.h" took 42 milliseconds - much slower
than Linux, but much faster than your machine.
Adding a minimal main and linking brought it up to 72 milliseconds.
Adding in windows.h and compiling only, 372 milliseconds.
What can we conclude from this quick test? We can see that Linux is
significantly faster than Windows for pre-processing lots of include
files with gcc, but that when there is real work to be done (such as for
linking a final executable), the tests here show no difference. And we
can see that including <windows.h> takes a lot of time, at least on
Windows - it appears to include a large amount of the Windows API.
I have no idea whether it is normal to include <windows.h> in many files
in a Windows C (or C++) project, or only in a few files, or if it is
possible and common to use individual headers for the bits of the
Windows API that you actually need. The answers here will show whether
even a 700 ms extra compile time is relevant to the big picture.
Or perhaps if you want to develop for Windows, it is most efficient to
use Linux with cross-compiling...
[toc] | [prev] | [next] | [standalone]
| From | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-30 04:38 -0700 |
| Message-ID | <532e2bd1-1d25-458e-bbf3-fe0ad15f8b10@googlegroups.com> |
| In reply to | #107465 |
Am Donnerstag, 30. März 2017 12:35:47 UTC+2 schrieb David Brown:
> On 30/03/17 02:51, bartc wrote:
> > On 30/03/2017 01:09, antispam wrote:
> >> David Brown <david.brown> wrote:
> >>>
> >>> Just to test, I took this C file:
> >>>
> >>> #include <stdio.h>
> >>> #include <stdlib.h>
> >>> #include <linux/fuse.h>
> >>>
> >>> int main(void) {
> >>> return 0;
> >>> }
> >>>
> >>> "fuse.h" is just a randomly picked Linux header that brings in a good
> >>> deal more header files. 46 headers in total, including duplicates - 38
> >>> without duplicates. The total is 10.6 K lines, or 336 KB of include
> >>> files.
> >>>
> >>> The compile time for this file was about 20 - 25 ms on my machine.
> >>>
> >>> I removed the include files, so /no/ pre-processing or includes are
> >>> needed.
> >>>
> >>> The compile time for /this/ file was about 20 - 25 ms on my machine.
> >>
> >> On may machine (2.4 GHz Core 2, Debian gcc 4.9.2-10) version with
> >> headers gave 44-46 ms. Without headers 29-31 ms. gcc -E reports
> >> 50 kB for version with headers. So cost of headers is measurable
> >> on my machine (OTOH small enough that without measurement I would
> >> not notice the difference).
> >
> > The following sets of includes take 700ms to compile with gcc -O0 on
> > Windows.
> >
> > (Precompiling (when the following was placed in a containing header)
> > didn't work or didn't make any difference. If the latter, that would be
> > due to the overheads of reading the pch file.)
> >
> > Other compilers all take less time: 570ms, 220ms, while lccwin was
> > around 100ms. But all are using different headers, all different sizes.
> > Tiny C was too small to measure.
> >
> > If you multiply these figures by N modules then it can add up. And there
> > are user headers, and other libraries' headers to factor in.
> >
> > (David Brown will now try and blame Windows OS for being so inefficient;
> > it's a never an inefficient compiler or a sprawling set of header files.)
> >
> > #include <assert.h>
> > #include <complex.h>
> > #include <ctype.h>
> > #include <errno.h>
> > #include <fenv.h>
> > #include <float.h>
> > #include <inttypes.h>
> > #include <iso646.h>
> > #include <limits.h>
> > #include <locale.h>
> > #include <math.h>
> > #include <setjmp.h>
> > #include <signal.h>
> > #include <stdarg.h>
> > #include <stdbool.h>
> > #include <stddef.h>
> > #include <stdint.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <time.h>
> > #include <wchar.h>
> > #include <wctype.h>
> > #include <windows.h>
> >
>
> I don't have "windows.h" on my Linux machine (obviously).
>
> Compilation (with "-c", and no linking) took 4-7 milliseconds on this
> machine (a slower PC than the other one I tested with). When I include
> a minimal main and generate an executable, it was 100 ms the first run,
> 60-75 ms thereafter.
>
> Yes, at least part of this is the inefficiency of Windows for such
> tasks. I know you don't like to hear that, but it is true.
I can confirm this.
I use gcc on Linux and Windows. Both computers use an i5 processor
and none of them has a SSD disk. The compilation with gcc under
Linux is lightning fast and under windows it is slow as a snail.
Linux simply caches much much better than Windows. All this
complaints about gcc being slow are definitely because people use
Windows. Gcc is just designed for a good (performance optimized) OS.
This performance difference between Linux and Windows has to
do with the developers. Many Linux developers are amateurs,
who try to squeeze out maximum performance, while others are
from hardware companies who are also interested in maximum
performance. Windows developers who want to increase the
performance of existing functionality are hindered by the
management. I have heard internal stories from MS that only
new features are important for them. This is similar to the
approach used by many other software companies. Featuritis
everywhere.
Regards,
Thomas Mertes
--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 13:14 +0100 |
| Message-ID | <RE6DA.263276$y83.33828@fx30.am4> |
| In reply to | #107469 |
On 30/03/2017 12:38, mertesthomas@gmail.com wrote: > I use gcc on Linux and Windows. Both computers use an i5 processor > and none of them has a SSD disk. The compilation with gcc under > Linux is lightning fast and under windows it is slow as a snail. > Linux simply caches much much better than Windows. All this > complaints about gcc being slow are definitely because people use > Windows. Gcc is just designed for a good (performance optimized) OS. Yet, Tiny C also running under the same Windows OS as gcc, is lightning fast by comparison /compiling the same source files/. There must be another explanation; maybe (as I think David Brown suggested once) that gcc's mode of operation somehow cripples it when working under Windows. (Note that one reason for slowness under Windows might be anti-virus software, although that has been taken care of in my case.) -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 14:38 +0200 |
| Message-ID | <obiu2a$sg1$1@dont-email.me> |
| In reply to | #107472 |
On 30/03/17 14:14, bartc wrote: > On 30/03/2017 12:38, mertesthomas@gmail.com wrote: > >> I use gcc on Linux and Windows. Both computers use an i5 processor >> and none of them has a SSD disk. The compilation with gcc under >> Linux is lightning fast and under windows it is slow as a snail. >> Linux simply caches much much better than Windows. All this >> complaints about gcc being slow are definitely because people use >> Windows. Gcc is just designed for a good (performance optimized) OS. > > Yet, Tiny C also running under the same Windows OS as gcc, is lightning > fast by comparison /compiling the same source files/. > > There must be another explanation; maybe (as I think David Brown > suggested once) that gcc's mode of operation somehow cripples it when > working under Windows. There are some things that Linux does a great deal faster than Windows. One is process creation (and termination) - it is orders of magnitude faster. Another is file I/O, especially for accessing and reading small files multiple times. When gcc compiles a file, it will run multiple programs - the driver program, the pre-processor, the compiler itself, the assembler (at least). It will also read a number of files or libraries along with way, as well as the include files in the program being compiled. On Windows, this all means significant overhead. On Linux (and other *nix), it means the compiler is split in manageable sections that may be written by different groups or swapped out with alternatives, and it means it scales well on multiple processors, especially when you do parallel builds. Note that gcc is not alone in this kind of design - it is a common one for compilers, and I have seen it on many, even on Windows-only compilers (for embedded targets). So yes, gcc's design is optimised for the strengths of Linux. A compiler designed to work efficiently on Windows should be made in a Windows way - a monolithic block that does everything itself. > > (Note that one reason for slowness under Windows might be anti-virus > software, although that has been taken care of in my case.) > I don't run viruses, so I don't have on-demand anti-virus software on my Windows machine. But certainly that would be relevant to some people, and it may also be that the Windows hooks and facilities to support anti-virus software make file I/O slower.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-31 08:52 +1300 |
| Message-ID | <ek560aFt3siU5@mid.individual.net> |
| In reply to | #107478 |
On 03/31/17 01:38 AM, David Brown wrote: > > So yes, gcc's design is optimised for the strengths of Linux. s/Linux/Unix/ :) -- Ian
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web