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 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 13:01 +0000 |
| Message-ID | <3N8BA.31840$yo7.25593@fx16.iad> |
| In reply to | #106886 |
BartC <bc@freeuk.com> writes: >On 24/03/2017 10:25, jacobnavia wrote: >> Hi >> >> I am starting to get results with my ARM64 port. lcc-win is compiling >> big programs now, without any problems... >> >> The acid test is to compile the compiler with itself. To do that, I need >> to parse the includes furnished by the linux system/gcc. There is a >> confusing mixture of include files in >> /usr/include, >> /usr/include/aarch64/bits, >> /usr/local/include/aarch64, >> >> and a LONG list of "places" where includes with the same name are stored. >> >> Which one should I use? How could I figure out which ones are used by gcc? You've missed a few locations (gcc has its own directories in addition to the directories provided by the operating system). gcc -H Note that all the headers are in /usr/include, but they may include implementation-dependent headers from other directories. > >As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >yesterday I had to try and compile code - on Windows this time - full of >'__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) #define __builtin_expect(x,y) (1)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 15:50 +0100 |
| Message-ID | <ob3bih$dtk$2@dont-email.me> |
| In reply to | #106901 |
On 24/03/17 14:01, Scott Lurndal wrote: > BartC <bc@freeuk.com> writes: >> On 24/03/2017 10:25, jacobnavia wrote: >>> Hi >>> >>> I am starting to get results with my ARM64 port. lcc-win is compiling >>> big programs now, without any problems... >>> >>> The acid test is to compile the compiler with itself. To do that, I need >>> to parse the includes furnished by the linux system/gcc. There is a >>> confusing mixture of include files in >>> /usr/include, >>> /usr/include/aarch64/bits, >>> /usr/local/include/aarch64, >>> >>> and a LONG list of "places" where includes with the same name are stored. >>> >>> Which one should I use? How could I figure out which ones are used by gcc? > > You've missed a few locations (gcc has its own directories in addition > to the directories provided by the operating system). > > gcc -H > > Note that all the headers are in /usr/include, but they may include > implementation-dependent headers from other directories. > > >> >> As I said elsewhere, it's hard to prise gcc and Linux apart. (Just >> yesterday I had to try and compile code - on Windows this time - full of >> '__builtin_expect(x,y)'. __builtin_expect is a gcc thing.) > > #define __builtin_expect(x,y) (1) > You mean: #define __builtin_expect(x,y) (x)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 13:07 +0100 |
| Message-ID | <ob320q$bn2$1@dont-email.me> |
| In reply to | #106884 |
On 24/03/17 11:25, jacobnavia wrote: > Hi > > I am starting to get results with my ARM64 port. lcc-win is compiling > big programs now, without any problems... > > The acid test is to compile the compiler with itself. To do that, I need > to parse the includes furnished by the linux system/gcc. There is a > confusing mixture of include files in > /usr/include, > /usr/include/aarch64/bits, > /usr/local/include/aarch64, > > and a LONG list of "places" where includes with the same name are stored. > > Which one should I use? How could I figure out which ones are used by gcc? > > To avoid these problems, I decided to move the includes I am using from > windows to linux, but that would mean that I port my standard C library > into linux, not an easy task, specially because the source code is 100% > adapted to lcc and not easily used by other compilers, and that could > introduce a new set of bugs! > > Besides, this produces binary incompatibilities between the generated > code and what the functions in the library expect, even more trouble... > > So, I have no other choice than to parse include files full of "gccisms" > and to make that work, and that starts with figuring out WHICH include > files should I use, hence my question in the subject line. > > The standard is silent on this subject, not even specifying a common > command that all compilers could support, telling the user how the > search paths are built. gcc has a number of command line options which can be useful here. It can print out the list of included headers while processing a file, and also a list of options (built-in defaults, environment variables, command-line options, etc.). Googling for "gcc print out include path" gives this: <http://stackoverflow.com/questions/17939930/finding-out-what-the-gcc-include-path-is>
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-24 15:48 +0100 |
| Message-ID | <ob3bfb$dlp$1@dont-email.me> |
| In reply to | #106896 |
Le 24/03/2017 à 13:07, David Brown a écrit :
> gcc has a number of command line options which can be useful here. It
> can print out the list of included headers while processing a file, and
> also a list of options (built-in defaults, environment variables,
> command-line options, etc.). Googling for "gcc print out include path"
> gives this:
>
> <http://stackoverflow.com/questions/17939930/finding-out-what-the-gcc-include-path-is>
>
>
Thank you. The first person to answer the question asked!
echo | gcc -E -Wp,-v -
Interesting. This gives me the following algorithm for the lcc compiler:
1) Look for ~/.lcc/includes
2) If not found, do
system("echo | gcc -E -Wp, -v -");
and redirect stderr into a file. Then parse that file and write it into
~/.lcc/includes.
3) Read ~/.lcc/includes and set the path for the compiler.
Looks sensible to you?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 16:26 +0100 |
| Message-ID | <ob3dlo$lol$1@dont-email.me> |
| In reply to | #106922 |
On 24/03/17 15:48, jacobnavia wrote:
> Le 24/03/2017 à 13:07, David Brown a écrit :
>
>> gcc has a number of command line options which can be useful here. It
>> can print out the list of included headers while processing a file, and
>> also a list of options (built-in defaults, environment variables,
>> command-line options, etc.). Googling for "gcc print out include path"
>> gives this:
>>
>> <http://stackoverflow.com/questions/17939930/finding-out-what-the-gcc-include-path-is>
>>
>>
>>
>
> Thank you. The first person to answer the question asked!
Sometimes I do try to be helpful :-)
However, note that my answer was the first result of an obvious google
search that would have taken you less time than writing the newsgroup
post. (But then we would miss out on the entertainment.)
>
> echo | gcc -E -Wp,-v -
>
> Interesting. This gives me the following algorithm for the lcc compiler:
>
> 1) Look for ~/.lcc/includes
> 2) If not found, do
> system("echo | gcc -E -Wp, -v -");
>
> and redirect stderr into a file. Then parse that file and write it into
> ~/.lcc/includes.
> 3) Read ~/.lcc/includes and set the path for the compiler.
>
> Looks sensible to you?
Running "echo | gcc -E -Wp,-v -" on my old Linux system I get:
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include
/usr/include
Running it on a newer system I get:
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
Running it on a local installation of a newer gcc:
echo | /usr/local/gcc-7-20170226/bin/gcc -E -Wp,-v -
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-7-20170226/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc-7-20170226/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include
/usr/local/include
/usr/local/gcc-7-20170226/include
/usr/local/gcc-7-20170226/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
So the order seems to be:
1. The compiler's own include directory
2. The machine's local include files (for development libraries
installed independently from the distro's package management)
3. The "include-fixed" headers, which gcc creates during installation to
fix and override a few system headers.
4. The OS include directory
5. The system include directory (where most development library headers
are kept, including normal C library headers).
I would recommend trying to replicate that directly, rather than writing
it into a user configuration file. Users might reasonably expect to be
able to move their lcc configuration file to a different computer and
still have things work correctly.
Additionally, people may have more than one installation of lcc. Now
that you support more than one OS and more than one target, it is
natural to think about cross-compilation - and the header files for
building Windows programs on Linux, or ARM code on x86 hosts, are going
to be in different places.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-03-24 16:32 +0000 |
| Message-ID | <878tnu63f0.fsf@gmail.com> |
| In reply to | #106930 |
David Brown <david.brown@hesbynett.no> writes: >> Thank you. The first person to answer the question asked! > > Sometimes I do try to be helpful :-) Well cut that out. It is c.l.c law that you are first required to state that "comp.lang.c. is just for discussing standard C, and mostly for discussing whether I should cast the return value of malloc()" and then add "questions about specific compilers should be directed to their specific newsgroups, even if those newsgroups have been dead for years".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 12:53 -0400 |
| Message-ID | <ob3ion$8en$1@dont-email.me> |
| In reply to | #106939 |
On 03/24/2017 12:32 PM, Gareth Owen wrote: > David Brown <david.brown@hesbynett.no> writes: > >>> Thank you. The first person to answer the question asked! >> >> Sometimes I do try to be helpful :-) > > Well cut that out. > > It is c.l.c law that you are first required to state that > > "comp.lang.c. is just for discussing standard C, and mostly for > discussing whether I should cast the return value of malloc()" > > and then add > > "questions about specific compilers should be directed to their specific > newsgroups, even if those newsgroups have been dead for years". That should be "an appropriate forum" rather than "their specific newsgroup" - many modern compilers are discussed in places other than newsgroups. Note also - if the most appropriate forum for discussing a specific compiler is dead, then the compiler is probably dead, too. If interest in a compiler has waned so much that you can't reasonably expect to find someone to answer your questions in the appropriate forum, you're even less likely to find someone to answer your question when posting to an inappropriate forum.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-24 18:24 +0100 |
| Message-ID | <ob3kjd$e90$1@dont-email.me> |
| In reply to | #106947 |
Le 24/03/2017 à 17:53, James Kuyper a écrit : > Note also - if the most appropriate forum for discussing a specific > compiler is dead, then the compiler is probably dead, too. The last message posted to gnu.g++.help was on oct 19th 2016. It was someone asking a question. No answer ensued. Is g++ dead then?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 17:29 +0000 |
| Message-ID | <nIcBA.201107$XG2.191647@fx08.iad> |
| In reply to | #106954 |
jacobnavia <jacob@jacob.remcomp.fr> writes: >Le 24/03/2017 à 17:53, James Kuyper a écrit : >> Note also - if the most appropriate forum for discussing a specific >> compiler is dead, then the compiler is probably dead, too. > >The last message posted to gnu.g++.help was on oct 19th 2016. It was >someone asking a question. No answer ensued. > > >Is g++ dead then? > you missed "the most appropriate forum", which for g++ is a mailing list, not the usenet group.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-24 10:55 -0700 |
| Message-ID | <071f154f-54d8-47e9-aef8-911d993349ba@googlegroups.com> |
| In reply to | #106954 |
On Friday, March 24, 2017 at 1:24:53 PM UTC-4, jacobnavia wrote: > Le 24/03/2017 à 17:53, James Kuyper a écrit : > > Note also - if the most appropriate forum for discussing a specific > > compiler is dead, then the compiler is probably dead, too. > > The last message posted to gnu.g++.help was on oct 19th 2016. It was > someone asking a question. No answer ensued. > > > Is g++ dead then? I specified the "most appropriate" forum. How did you reach the conclusion that gnu.g++.help was more appropriate than the mailing list and IRC channels mentioned at <http://www.gnu.org/software/gethelp.html>?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 10:47 -0700 |
| Message-ID | <cd21f8ae-23e3-40e8-b661-2e8e9edc0c92@googlegroups.com> |
| In reply to | #106930 |
On Friday, March 24, 2017 at 10:26:39 AM UTC-5, David Brown wrote:
> So the order seems to be:
>
> 1. The compiler's own include directory
> 2. The machine's local include files (for development libraries
> installed independently from the distro's package management)
> 3. The "include-fixed" headers, which gcc creates during installation to
> fix and override a few system headers.
> 4. The OS include directory
> 5. The system include directory (where most development library headers
> are kept, including normal C library headers).
I find rather sloppy the practice of relying upon include file search paths
to find header files. Such practice can lead to some nasty problems if
two different libraries have almost identical internal-use header files with
the same name. Even if either header would work if used everywhere, code
which is in the same directory as one of the headers will use it while code
which isn't in that same directory will use the other.
I wonder if any compilers would be made less useful by a rule which required
that compilers recognize
#include "this" "that"
as a valid form of include equivalent to
#include "thisthat"
in a fashion analogous to the handling of strings in other contexts? That
would make it practical to say:
#include LIBDIRS
#include LIB1DIR "fileFromLib1.h"
#include LIB2DIR "fileFromLib2.h"
etc. and have "LIBDIRS" be set at the command line to point to a project-wide
file containing the appropriate paths for all the libraries used therein.
It would almost be practical to use
#include LIBDIRS
#include makeHeaderPath(LIB1DIR,fileFromLib1)
#include makeHeaderPath(LIB2DIR,fileFromLib2)
but there would be no way to protect filenames from macro substitution.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-24 09:37 -0700 |
| Message-ID | <ln4lyiaavz.fsf@kst-u.example.com> |
| In reply to | #106884 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> I am starting to get results with my ARM64 port. lcc-win is compiling
> big programs now, without any problems...
>
> The acid test is to compile the compiler with itself. To do that, I need
> to parse the includes furnished by the linux system/gcc. There is a
> confusing mixture of include files in
> /usr/include,
> /usr/include/aarch64/bits,
> /usr/local/include/aarch64,
>
> and a LONG list of "places" where includes with the same name are stored.
>
> Which one should I use? How could I figure out which ones are used by gcc?
By asking gcc. Compile some random source file with "gcc -v". On my
system, I get:
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 15:07 -0500 |
| Message-ID | <ob6i7t$nv$1@dont-email.me> |
| In reply to | #106884 |
jacobnavia wrote: > Hi > > I am starting to get results with my ARM64 port. lcc-win is > compiling big programs now, without any problems... > > The acid test is to compile the compiler with itself. To do that, I > need to parse the includes furnished by the linux system/gcc. There > is a confusing mixture of include files in /usr/include, > /usr/include/aarch64/bits, /usr/local/include/aarch64, > > and a LONG list of "places" where includes with the same name are > stored. > > Which one should I use? How could I figure out which ones are used by > gcc? > You use the one that best fits your architecture. A way to do this is to run the preprocessor on a trivial program and see which directories get included. In effect there are a bunch of hidden #define/--option like things built into the gcc chain that tell it which directories to use. https://gcc.gnu.org/install/configure.html > To avoid these problems, I decided to move the includes I am using > from windows to linux, but that would mean that I port my standard C > library into linux, not an easy task, specially because the source > code is 100% adapted to lcc and not easily used by other compilers, > and that could introduce a new set of bugs! > > Besides, this produces binary incompatibilities between the > generated code and what the functions in the library expect, even > more trouble... > > So, I have no other choice than to parse include files full of > "gccisms" and to make that work, and that starts with figuring out > WHICH include files should I use, hence my question in the subject > line. > > The standard is silent on this subject, not even specifying a common > command that all compilers could support, telling the user how the > search paths are built. That is absolutely correct. It's completely implementation dependent. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-29 09:56 -0700 |
| Message-ID | <9fdaf805-d21a-49f3-ab54-4fa17b91f731@googlegroups.com> |
| In reply to | #106884 |
Am Freitag, 24. März 2017 11:25:27 UTC+1 schrieb jacobnavia:
> Hi
>
> I am starting to get results with my ARM64 port. lcc-win is compiling
> big programs now, without any problems...
>
> The acid test is to compile the compiler with itself.
A compiler that compiles itself is an important milestone, for
sure. But this is not the real acid test. Unknowingly you may
code around all weaknesses of your compiler (In your subconscious
mind you know all weaknesses of the compiler).
The real acid test is to compile big programs that come
from outside. I have such things as the Linux kernel, the X11
library or Firefox in my mind. Compilers like clang and icc
can e.g. claim that they can compile the Linux kernel.
And of cause I see also the compilation of Seed7 as acid test.
A C compiler + run-time library that can support Seed7 is
a good (and correct) C compiler. There are several C compilers
that failed to compile Seed7 correctly:
- Tcc: Compiles, but integer divisions with maximum values
are not correct (see tcc_err2.c). Additionally there
are also floating point issues with the power function
and with Infinity. There seem to be also problems with
comparisons (checks unnecessarily trigger exceptions).
- Dmc: Compiles, but some code is wrong (see testdmc.c)
- Pelles C: Everything must be compiled without optimization
(otherwise severe bugs show up) except for one
file that needs to be compiled with -O2 (otherwise
the register pressure is to high and the compile
fails). Compilation of interpreter and compiler
works. In the tests the Pelles C compiler turns
out to be extremely slow.
- lcc-win32: Compiles after I provided the missing functions
_wchdir, _wgetcwd, _wmkdir, _wrmdir, _wrename,
_wremove, _wchmod, _wcsicmp (Note that this are
windows functions, POSIX does NOT know them).
The interpreter runs, but there are issues
(see testlcc*.c from previous discussions).
- lcc-win64: With several hickups (and the same functions
as above) the compile succeeds. But there are
still missing functions and an error:
fil_win.obj .text: undefined reference to '_open_osfhandle'
fil_win.obj .text: undefined reference to '_close'
fil_win.obj .text: undefined reference to 'fdopen'
Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
Link failed. Removing ..\bin\s7.exe
One question: Do you have a test suite for your compiler?
This time no test programs for lcc-win:
========== begin tcc_err2.c ==========
#include "stdio.h"
#if ULONG_MAX > 4294967295U
typedef long intType;
#define INT_SUFFIX(num) num ## L
#define SUFFIX "L"
#define INTTYPE_FORMAT "l"
#define MESSAGE "Using long.\n"
#else
typedef long long intType;
#define INT_SUFFIX(num) num ## LL
#define SUFFIX "LL"
#define INTTYPE_FORMAT "ll"
#define MESSAGE "Using long long.\n"
#endif
#define F_D(width) "%" #width INTTYPE_FORMAT "d"
#if 0
/* Allow the compiler to compute the division. */
#define intExpr(num) (num)
#else
/* The division will (probably) be done at runtime. */
intType intExpr (intType number) { return number; }
#endif
int main (int argc, char **argv)
{
printf("sizeof(long): %lu\n", sizeof(long));
printf("sizeof(long long): %lu\n", sizeof(long long));
printf(MESSAGE);
printf("-9223372036854775808" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: 4294967294\n",
intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483649));
printf("-9223372036854775808" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: 4294967296\n",
intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483648));
printf(" 9223372036854775807" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: -4294967294\n",
intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483649));
printf(" 9223372036854775807" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: -4294967295\n",
intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483648));
printf("-9223372036854775808" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: -2\n",
intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483649));
printf("-9223372036854775808" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 0\n",
intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483648));
printf(" 9223372036854775807" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: 1\n",
intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483649));
printf(" 9223372036854775807" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 2147483647\n",
intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483648));
return 0;
}
========== end tcc_err2.c ==========
========== begin testdmc.c ==========
#include "stdio.h"
typedef long long intType;
typedef unsigned long long uintType;
typedef _Bool boolType;
typedef const unsigned char *const_ustriType;
#define INTTYPE_MAX ((intType) 9223372036854775807)
#define MAX_DIV_10 ((intType) (INTTYPE_MAX / 10))
#define MAX_REM_10 ((intType) (INTTYPE_MAX % 10))
#define FMT_U "%llu"
void check1 (void)
{
uintType uintValue = 5;
if (((uintType) 10) * uintValue != 50) {
printf(" ***** Error: ((uintType) 10) * uintValue != 50"
" for uintValue: %llu\n", uintValue);
}
}
int main (int argc, char *argv[])
{
check1();
return 0;
}
========== end testdmc.c ==========
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-29 10:39 -0700 |
| Message-ID | <f262c893-8718-4fda-a4c7-8ffc9842c71c@googlegroups.com> |
| In reply to | #107408 |
On Wednesday, March 29, 2017 at 11:56:39 AM UTC-5, mertes...@gmail.com wrote: > A compiler that compiles itself is an important milestone, for > sure. But this is not the real acid test. Unknowingly you may > code around all weaknesses of your compiler (In your subconscious > mind you know all weaknesses of the compiler). > > The real acid test is to compile big programs that come > from outside. I have such things as the Linux kernel, the X11 > library or Firefox in my mind. Compilers like clang and icc > can e.g. claim that they can compile the Linux kernel. There are two ways to measure the quality of an implementation: 1. How well it works with code that is written to do things in the way that particular implementation handles best. 2. How well it works with code written for other implementations. If compiler X produces a certain quality of code almost no matter how an operation is expressed, and compiler Y will produce crummy code if the operation is expressed some ways, but can generate better code than X if the operation is expressed other ways, which should be viewed as a better compiler?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-29 12:22 -0700 |
| Message-ID | <lnfuhv51nn.fsf@kst-u.example.com> |
| In reply to | #107408 |
mertesthomas@gmail.com writes:
[...]
> - Tcc: Compiles, but integer divisions with maximum values
> are not correct (see tcc_err2.c).
[...]
> ========== begin tcc_err2.c ==========
> #include "stdio.h"
>
> #if ULONG_MAX > 4294967295U
> typedef long intType;
> #define INT_SUFFIX(num) num ## L
> #define SUFFIX "L"
> #define INTTYPE_FORMAT "l"
> #define MESSAGE "Using long.\n"
> #else
> typedef long long intType;
> #define INT_SUFFIX(num) num ## LL
> #define SUFFIX "LL"
> #define INTTYPE_FORMAT "ll"
> #define MESSAGE "Using long long.\n"
> #endif
>
> #define F_D(width) "%" #width INTTYPE_FORMAT "d"
>
> #if 0
> /* Allow the compiler to compute the division. */
> #define intExpr(num) (num)
> #else
> /* The division will (probably) be done at runtime. */
> intType intExpr (intType number) { return number; }
> #endif
>
>
> int main (int argc, char **argv)
> {
> printf("sizeof(long): %lu\n", sizeof(long));
> printf("sizeof(long long): %lu\n", sizeof(long long));
> printf(MESSAGE);
> printf("-9223372036854775808" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: 4294967294\n",
> intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483649));
> printf("-9223372036854775808" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: 4294967296\n",
> intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483648));
> printf(" 9223372036854775807" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: -4294967294\n",
> intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483649));
> printf(" 9223372036854775807" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: -4294967295\n",
> intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483648));
> printf("-9223372036854775808" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: -2\n",
> intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483649));
> printf("-9223372036854775808" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 0\n",
> intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483648));
> printf(" 9223372036854775807" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: 1\n",
> intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483649));
> printf(" 9223372036854775807" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 2147483647\n",
> intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483648));
> return 0;
> }
> ========== end tcc_err2.c ==========
I compiled and ran your program using tcc, and it appeared to pass.
I'm using tcc 0.9.26 on x86_64 Linux (Ubuntu 16.10).
It would be handy if it would explicitly report an error if a value
doesn't match. Also, the correct format for size_t is "%zu", not
"%lu".
--
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 | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-29 15:10 -0700 |
| Message-ID | <df1f4ef2-edc0-43c6-8870-abbc521a777c@googlegroups.com> |
| In reply to | #107413 |
Am Mittwoch, 29. März 2017 21:22:12 UTC+2 schrieb Keith Thompson:
> mertesthomas writes:
> [...]
> > - Tcc: Compiles, but integer divisions with maximum values
> > are not correct (see tcc_err2.c).
> [...]
> > ========== begin tcc_err2.c ==========
> > #include "stdio.h"
> >
> > #if ULONG_MAX > 4294967295U
> > typedef long intType;
> > #define INT_SUFFIX(num) num ## L
> > #define SUFFIX "L"
> > #define INTTYPE_FORMAT "l"
> > #define MESSAGE "Using long.\n"
> > #else
> > typedef long long intType;
> > #define INT_SUFFIX(num) num ## LL
> > #define SUFFIX "LL"
> > #define INTTYPE_FORMAT "ll"
> > #define MESSAGE "Using long long.\n"
> > #endif
> >
> > #define F_D(width) "%" #width INTTYPE_FORMAT "d"
> >
> > #if 0
> > /* Allow the compiler to compute the division. */
> > #define intExpr(num) (num)
> > #else
> > /* The division will (probably) be done at runtime. */
> > intType intExpr (intType number) { return number; }
> > #endif
> >
> >
> > int main (int argc, char **argv)
> > {
> > printf("sizeof(long): %lu\n", sizeof(long));
> > printf("sizeof(long long): %lu\n", sizeof(long long));
> > printf(MESSAGE);
> > printf("-9223372036854775808" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: 4294967294\n",
> > intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483649));
> > printf("-9223372036854775808" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: 4294967296\n",
> > intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483648));
> > printf(" 9223372036854775807" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: -4294967294\n",
> > intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483649));
> > printf(" 9223372036854775807" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: -4294967295\n",
> > intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483648));
> > printf("-9223372036854775808" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: -2\n",
> > intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483649));
> > printf("-9223372036854775808" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 0\n",
> > intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483648));
> > printf(" 9223372036854775807" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: 1\n",
> > intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483649));
> > printf(" 9223372036854775807" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 2147483647\n",
> > intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483648));
> > return 0;
> > }
> > ========== end tcc_err2.c ==========
>
> I compiled and ran your program using tcc, and it appeared to pass.
> I'm using tcc 0.9.26 on x86_64 Linux (Ubuntu 16.10).
Ok. I use tcc 0.9.25 and running tcc_err2 under Linux gives:
sizeof(long): 8
sizeof(long long): 8
Using long long.
-9223372036854775808LL / -2147483649LL = 0 expected: 4294967294
-9223372036854775808LL / -2147483648LL = 0 expected: 4294967296
9223372036854775807LL / -2147483649LL = 0 expected: -4294967294
9223372036854775807LL / -2147483648LL = 0 expected: -4294967295
-9223372036854775808LL % -2147483649LL = -9223372036854775808 expected: -2
-9223372036854775808LL % -2147483648LL = -9223372036854775808 expected: 0
9223372036854775807LL % -2147483649LL = 9223372036854775807 expected: 1
9223372036854775807LL % -2147483648LL = 9223372036854775807 expected: 2147483647
> It would be handy if it would explicitly report an error if a value
> doesn't match.
Maybe I already reported the error. :-)
It is some time ago when I wrote tcc_err2.c and I cannot remember
what I did with it.
I will look for tcc 0.9.26 and do the tests again.
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-29 16:58 -0700 |
| Message-ID | <lnbmsj4ovn.fsf@kst-u.example.com> |
| In reply to | #107427 |
mertesthomas@gmail.com writes:
> Am Mittwoch, 29. März 2017 21:22:12 UTC+2 schrieb Keith Thompson:
>> mertesthomas writes:
>> [...]
>> > - Tcc: Compiles, but integer divisions with maximum values
>> > are not correct (see tcc_err2.c).
>> [...]
>> > ========== begin tcc_err2.c ==========
>> > #include "stdio.h"
>> >
>> > #if ULONG_MAX > 4294967295U
>> > typedef long intType;
>> > #define INT_SUFFIX(num) num ## L
>> > #define SUFFIX "L"
>> > #define INTTYPE_FORMAT "l"
>> > #define MESSAGE "Using long.\n"
>> > #else
>> > typedef long long intType;
>> > #define INT_SUFFIX(num) num ## LL
>> > #define SUFFIX "LL"
>> > #define INTTYPE_FORMAT "ll"
>> > #define MESSAGE "Using long long.\n"
>> > #endif
>> >
>> > #define F_D(width) "%" #width INTTYPE_FORMAT "d"
>> >
>> > #if 0
>> > /* Allow the compiler to compute the division. */
>> > #define intExpr(num) (num)
>> > #else
>> > /* The division will (probably) be done at runtime. */
>> > intType intExpr (intType number) { return number; }
>> > #endif
>> >
>> >
>> > int main (int argc, char **argv)
>> > {
>> > printf("sizeof(long): %lu\n", sizeof(long));
>> > printf("sizeof(long long): %lu\n", sizeof(long long));
>> > printf(MESSAGE);
>> > printf("-9223372036854775808" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: 4294967294\n",
>> > intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483649));
>> > printf("-9223372036854775808" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: 4294967296\n",
>> > intExpr(INT_SUFFIX(-9223372036854775807)-1) / INT_SUFFIX(-2147483648));
>> > printf(" 9223372036854775807" SUFFIX " / -2147483649" SUFFIX " = " F_D(20) " expected: -4294967294\n",
>> > intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483649));
>> > printf(" 9223372036854775807" SUFFIX " / -2147483648" SUFFIX " = " F_D(20) " expected: -4294967295\n",
>> > intExpr(INT_SUFFIX( 9223372036854775807)) / INT_SUFFIX(-2147483648));
>> > printf("-9223372036854775808" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: -2\n",
>> > intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483649));
>> > printf("-9223372036854775808" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 0\n",
>> > intExpr(INT_SUFFIX(-9223372036854775807)-1) % INT_SUFFIX(-2147483648));
>> > printf(" 9223372036854775807" SUFFIX " %% -2147483649" SUFFIX " = " F_D(20) " expected: 1\n",
>> > intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483649));
>> > printf(" 9223372036854775807" SUFFIX " %% -2147483648" SUFFIX " = " F_D(20) " expected: 2147483647\n",
>> > intExpr(INT_SUFFIX( 9223372036854775807)) % INT_SUFFIX(-2147483648));
>> > return 0;
>> > }
>> > ========== end tcc_err2.c ==========
>>
>> I compiled and ran your program using tcc, and it appeared to pass.
>> I'm using tcc 0.9.26 on x86_64 Linux (Ubuntu 16.10).
>
> Ok. I use tcc 0.9.25 and running tcc_err2 under Linux gives:
>
> sizeof(long): 8
> sizeof(long long): 8
> Using long long.
> -9223372036854775808LL / -2147483649LL = 0 expected: 4294967294
> -9223372036854775808LL / -2147483648LL = 0 expected: 4294967296
> 9223372036854775807LL / -2147483649LL = 0 expected: -4294967294
> 9223372036854775807LL / -2147483648LL = 0 expected: -4294967295
> -9223372036854775808LL % -2147483649LL = -9223372036854775808 expected: -2
> -9223372036854775808LL % -2147483648LL = -9223372036854775808 expected: 0
> 9223372036854775807LL % -2147483649LL = 9223372036854775807 expected: 1
> 9223372036854775807LL % -2147483648LL = 9223372036854775807 expected: 2147483647
>
>> It would be handy if it would explicitly report an error if a value
>> doesn't match.
>
> Maybe I already reported the error. :-)
> It is some time ago when I wrote tcc_err2.c and I cannot remember
> what I did with it.
What I meant, in case it wasn't clear, is that the program should print
a PASS/FAIL result, either a summary or for each sub-test, rather than
requiring the reader to visually compare the actual vs. the expected
value.
> I will look for tcc 0.9.26 and do the tests again.
--
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 | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-30 01:02 +0200 |
| Subject | Re: Even more problems with Seed7 |
| Message-ID | <obhe7q$4qm$1@dont-email.me> |
| In reply to | #107408 |
Le 29/03/2017 à 18:56, mertesthomas@gmail.com a écrit :
> Am Freitag, 24. März 2017 11:25:27 UTC+1 schrieb jacobnavia:
>> Hi
>>
>> I am starting to get results with my ARM64 port. lcc-win is compiling
>> big programs now, without any problems...
>>
>> The acid test is to compile the compiler with itself.
>
> A compiler that compiles itself is an important milestone, for
> sure. But this is not the real acid test. Unknowingly you may
> code around all weaknesses of your compiler (In your subconscious
> mind you know all weaknesses of the compiler).
>
And very consciously too. For instance the feature of passing structs by
value gave me a lot of headaches. So I coded around it, and then saw if
I could isolate the bug somewhere else, in smaller programs than the
compiler, or in a better part of the compiler for debugging.
At the end I erased all the changes and fixed all known problems. But
being able to work around made me advance. Obviously compiling the
compiler code with itself is just a milestone, a compiler needs time to
debug, a lot of time. I haven't even released this version yet.
> The real acid test is to compile big programs that come
> from outside.
I compiled gcc with the 32 bit version. and I had an asm file with the
output of the gcc compiled with lcc. The current gcc, and the gcc
compiled with lcc should produce exactly the same assembler output. And
they did. But in that time it was feasible to do that, gcc was much
smaller. Today is bloated beyond recognition.
I have such things as the Linux kernel, the X11
> library or Firefox in my mind.
The linux kernel is written for gcc. I do not feel (nor would I be able)
to compile that, excuse me. I would have to reproduce all non standard
behavior that is assumed in that code, an OS kernel.
Compilers like clang and icc
> can e.g. claim that they can compile the Linux kernel.
>
Great. I do not claim that, and I do not think I will ever attempt that.
For what reason?
Gcc exists. C language usage and applications other than os kernels are
feasible... Applications that could be served with a little c compiler.
Not a monster compiler, not the linux kernel, but a code generator you
can hack around as you wish.
> And of cause I see also the compilation of Seed7 as acid test.
Obviously.
> A C compiler + run-time library that can support Seed7 is
> a good (and correct) C compiler.
Probably. You do not test the whole language however, and any compiler
is bound to have problems. The set all possible C programs is quite
infinite.
There are several C compilers
> that failed to compile Seed7 correctly:
>
{snip}
> - lcc-win32: Compiles after I provided the missing functions
> _wchdir, _wgetcwd, _wmkdir, _wrmdir, _wrename,
> _wremove, _wchmod, _wcsicmp (Note that this are
> windows functions, POSIX does NOT know them).
> The interpreter runs, but there are issues
> (see testlcc*.c from previous discussions).
You say you "provided", but not to me, as far as I remember. For your
application you wrote the missing stuff and added it to your software.
OK.
I provided the C compiler for free. Modulo the few bugs reported, the
thing is running.
> - lcc-win64: With several hickups (and the same functions
> as above) the compile succeeds. But there are
> still missing functions and an error:
> fil_win.obj .text: undefined reference to '_open_osfhandle'
That's a windows function. I think microsoft deprecated it in 64 bits,
in any case it is not a bug in lcc-win.
> fil_win.obj .text: undefined reference to '_close'
Those are deprecated. All files are buffered or unbuffer with setvbuf,
but no small integer ids any more. The C standard doesn't mention them,
and in windows they aren't as popular as in Unix. So they aren't there.
> fil_win.obj .text: undefined reference to 'fdopen'
I wrote that in 64 bits as far as I remember. Which version are you
using by the way? Last time we spoke about this I told you to reload.
Did you reload?
> Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
That's your error. Your program did not provide the
__declspec(dllimport) for that function, and the code generated supposes
it is a library function, not inside a dll. The generated code will not
work and linking fails.
This is not a bug, it is a feature. No crashes at run time. The linker
stops.
> Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
> Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
> Error: call to __WSAFDIsSet missing __declspec(dllimport). Fix impossible
> Link failed. Removing ..\bin\s7.exe
>
> One question: Do you have a test suite for your compiler?
>
Of course not. That's a bad compiler done by an amateur that doesn't
have a clue. You found 3 bugs that you think are important. May I remind
you that there is no obligation for my part to have the same priorities
like you?
>
> This time no test programs for lcc-win:
>
Thank you.
It would be nice if you did not feel like taking that offended tone. If
you think that the author of lcc-win has no test suite because you
discover some bugs somewhere in obscure situations, you are entitled to
get your money back.
:-)
I do what I can OK?
And I do have bugs.
And I do fix them when I find time for it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-30 01:05 -0500 |
| Subject | Re: Even more problems with Seed7 |
| Message-ID | <937pdct5m127ru28j3godm6ijtc59vkgfl@4ax.com> |
| In reply to | #107436 |
On Thu, 30 Mar 2017 01:02:05 +0200, jacobnavia <jacob@jacob.remcomp.fr> wrote: >> - lcc-win32: Compiles after I provided the missing functions >> _wchdir, _wgetcwd, _wmkdir, _wrmdir, _wrename, >> _wremove, _wchmod, _wcsicmp (Note that this are >> windows functions, POSIX does NOT know them). >> The interpreter runs, but there are issues >> (see testlcc*.c from previous discussions). > >You say you "provided", but not to me, as far as I remember. For your >application you wrote the missing stuff and added it to your software. > >OK. > >I provided the C compiler for free. Modulo the few bugs reported, the >thing is running. > > >> - lcc-win64: With several hickups (and the same functions >> as above) the compile succeeds. But there are >> still missing functions and an error: >> fil_win.obj .text: undefined reference to '_open_osfhandle' > >That's a windows function. I think microsoft deprecated it in 64 bits, >in any case it is not a bug in lcc-win. To be picky, it's a CRT/CLib function, not part of Windows API. It's still supported in 64-bit code. The POSIX equivalent is fileno. In POSIX, the opposite translation is done by fdopen. The Windows version of that, _fdopen, does something a bit different, it turns an fd from _open into a FILE. Going from a system HANDLE to a CRT FILE is done with _open_ofshandle. I *think* there was some way to do that before _open_ofshandle existed (I seem to recall creating an fd from a HANDLE, then _fdopen'ing that), but that was a long time ago. Both pairs of those functions need to be in the CRT, since the OS doesn't know how to create a FILE structure.
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web