Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108327 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2017-04-22 09:06 +0100 |
| Last post | 2017-04-26 08:53 +0200 |
| Articles | 20 on this page of 245 — 25 participants |
Back to article view | Back to comp.lang.c
gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 09:06 +0100
Re: gcc failure (optimised/non-optimised) Andrew Cooper <amc96@cam.ac.uk> - 2017-04-22 09:49 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:52 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:37 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:07 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:33 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:32 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-28 14:53 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 07:00 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:19 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 11:30 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 16:12 +0200
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:16 +0100
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-23 05:41 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-23 14:14 -0700
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-24 04:04 -0500
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:22 +0100
Re: gcc failure (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 12:05 -0400
Re: gcc rules OK (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 17:06 -0400
Re: gcc rules OK (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 15:06 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:31 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 09:29 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 10:47 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 11:36 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:50 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 15:35 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:36 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:37 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:07 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-25 11:57 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:34 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 11:25 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:57 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:38 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:38 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-22 08:35 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 17:16 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 18:55 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 21:04 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-22 21:51 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:56 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 16:49 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-30 16:02 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:51 -0500
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 21:42 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 17:35 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:57 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 18:44 +0100
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:34 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 12:03 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:30 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-30 21:18 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:33 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 16:27 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:16 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:34 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:43 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 12:54 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 17:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 18:05 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 20:37 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 10:22 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:01 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 12:18 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:55 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:14 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 09:34 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 10:09 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:25 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 11:28 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 11:53 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 13:07 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 14:19 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 16:44 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:09 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:17 +1200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:26 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:38 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:49 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 19:58 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:32 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:53 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:51 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:58 +1200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:45 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-05 06:41 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-05 10:40 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 13:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-06 11:26 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 22:52 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:01 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:48 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:17 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 06:36 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 16:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 09:16 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 21:20 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 13:07 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 22:46 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 14:38 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:16 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:09 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 15:14 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:43 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:56 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:57 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 17:27 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 17:41 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:16 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-09 12:11 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 09:58 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:40 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 12:05 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:55 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-09 13:56 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 14:19 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-10 14:22 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:36 -0500
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 01:12 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 21:15 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:41 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-11 15:32 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 01:54 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 07:45 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 23:52 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:57 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 21:56 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:45 +0200
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-11 14:43 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-12 10:55 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-12 07:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 09:02 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-14 13:14 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 16:04 -0500
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:33 -0500
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:51 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:14 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:07 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:30 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:44 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:42 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-05 14:10 +0000
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 17:12 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 15:08 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:24 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:29 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 18:07 +0000
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 20:15 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 15:47 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 01:22 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 18:57 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 09:30 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:25 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 10:33 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 10:10 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 12:49 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-05 18:31 -0700
Re: gcc failure (optimised/non-optimised) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-05 22:18 -0600
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-07 23:58 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:33 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:04 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:51 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-08 19:01 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:39 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 06:42 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:53 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-05 00:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:54 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:27 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:10 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:56 -0500
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:00 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:15 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:06 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:43 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 21:52 +0200
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-01 23:16 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-02 09:19 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:28 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 13:12 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:23 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 10:08 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:32 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 13:59 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:47 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-30 21:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 11:24 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:45 -0700
Re: gcc failure (optimised/non-optimised) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-04-23 23:11 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:46 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:23 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 15:38 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 17:31 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-24 17:15 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:36 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:06 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 14:03 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:25 -0700
Re: gcc failure (optimised/non-optimised) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-27 05:51 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:08 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-01 10:48 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 11:39 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-05-01 13:54 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:55 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:18 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:03 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:13 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 19:47 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 18:51 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 14:06 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 21:05 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 16:06 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 14:19 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 08:41 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:07 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:44 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 09:03 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 09:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:41 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:51 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 08:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:13 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:11 +0000
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:04 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:57 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:38 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:43 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 18:22 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 17:48 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:24 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-27 03:03 -0700
Re: gcc failure (optimised/non-optimised) James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:12 -0400
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:48 +0000
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 10:14 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:32 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:47 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-26 08:53 +0200
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-08 21:07 +0000 |
| Message-ID | <465QA.53427$rl4.5902@fx35.iad> |
| In reply to | #109532 |
David Brown <david.brown@hesbynett.no> writes: >On 08/05/17 18:16, supercat@casperkitty.com wrote: > >> >> In the days before "volatile", such code would simply work but compilers >> had to do all memory accesses in order. > >I don't know when "volatile" came into use, but it is in the C89 >standard. K&R Second Edition (1988 - ANSI C) documents the 'volatile' keyword, so one can assume it entered the language sometime during the 1983-1988 period when X3J11 was working. >> I am fully aware that there are some hardware platforms where loads and >> stores may be cached or reordered at the hardware level. On many systems, >> however, a programmer will know of all such hardware issues that exist (if >> any). The question is whether compilers should require the use of compiler- >> specific directives to prevent them from creating problems of their own. Most modern programmers are ill-equiped to deal with weak memory models vis-a-vis concurrent programming. C and C++ standards have both added language features to help programmers deal with weak memory models without necessarily being able to articulate the ordering characteristics of the model, for example when a load is reordered ahead of a store that the programmer naively expects to happen in program order with respect to external visibility of the store (e.g when writing to a memory mapped I/O register).
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-09 18:30 +0100 |
| Message-ID | <8760hadjjt.fsf@gmail.com> |
| In reply to | #109532 |
David Brown <david.brown@hesbynett.no> writes: > On 08/05/17 18:16, supercat@casperkitty.com wrote: >> On Monday, May 8, 2017 at 9:21:09 AM UTC-5, David Brown wrote: >>> "some_value" is not volatile, and the compiler can see it is never >>> changed. Why should it reload it? Is the compiler to guess what you >>> meant to write? I suppose /I/ should have been able to guess what you >>> meant, but I often find it hard with your examples. >> >> On many systems, data is read or written by giving some outside process the >> address if the data and performing a write to a volatile location to trigger >> that process. It is not unusual for the act of writing to a volatile location >> to affect other aspects of system state. > > Yes, it is unusual. The code is wrong - it is incorrect C. Maybe you > are used to writing such code, but /I/ certainly am not. Now we get to the nub. Supercat has been writing that incorrect code for decades, and it used to kind-of-mostly-work and he is /pissed/ that everyone else refuses to be constrained by his ingrained misconceptions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 10:44 +0200 |
| Message-ID | <oehdqj$pc5$2@dont-email.me> |
| In reply to | #109275 |
On 04/05/17 23:45, supercat@casperkitty.com wrote: > On Thursday, May 4, 2017 at 3:58:30 PM UTC-5, Ian Collins wrote: >> When? in the 80s? > > In the world of small embedded controllers, such things are still common. No, they are not. They /were/ common, but not now. > When designing a system, it's often important to be able to test the > performance of software mockups on proposed hardware designs to see if they > will be able to achieve adequate performance before committing time to > getting production software working on hardware that may need to be abandoned. > Having a compiler apply a massive speedup to mockup/benchmarking code that > won't actually be available in production will be decidedly unhelpful. > > Again, different implementations are intended for different purposes. I > don't object to compilers that apply certain loop optimizations when it > makes sense for them to do so, but I tend to be of the opinion that if > one doesn't want a low-level compiler to include something in the machine > code, one shouldn't write it in the source. > I don't think C is the language you are looking for.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 10:42 +0200 |
| Message-ID | <oehdng$pc5$1@dont-email.me> |
| In reply to | #109270 |
On 04/05/17 22:51, supercat@casperkitty.com wrote:
> On Thursday, May 4, 2017 at 3:27:05 PM UTC-5, David Brown wrote:
>> There are lots of ways a for loop like the one above can be re-written
>> using while. The point is, why? It will almost certainly not result in
>> clearer code (Ian gave some reasons for that). It will almost certainly
>> not result in more efficient object code.
>
> I've seen plenty of compilers where a count-toward-zero loop will generate
> more efficient object code.
I too have seen such compilers - and written "hand optimised" C code to
suit. Fortunately, such tools are mostly a thing of the past, even in
the world of small microcontrollers. There was a time where users of
small microcontrollers had a choice between expensive but good
compilers, or cheap but poor compilers (and also expensive but poor
compilers). Now, for the most part, you get cheap or free /good/
compilers. Expensive compilers need added value to compete, and the
market for poor quality compilers is mostly gone. (Vendors can still
provide cheap tools, but these will mostly use the open source compilers
and add libraries, support, etc.)
That is why I wrote "it will almost certainly not result in more
efficient code" - there are exceptions, but they are fortunately rare.
> Some people may consider that horrible, but I
> believe the quality of a compiler intended for low-level programming on a
> platform should be evaluated based upon the efficiency of code *it can be
> coaxed into generating by someone familiar with the platform*. Compilers
> intended for other purposes should be judged by other criteria.
>
There are many criteria by which to judge a compiler. To me, the main
point is how easy it makes it to write clear, correct code, and how well
it helps you find errors in your code. Efficient object code generation
is also very important, but code size and speed is utterly irrelevant if
the code is not correct. This applies to /all/ compilers - embedded
tools and low-level tools are no different.
> If `size` is a global variable that won't change during a loop, a compiler
> given
>
> for (unsigned i=0; i<size; i++)
> {
> .. doSomething
> }
>
> won't be able to optimize away the comparison unless it can *prove* that
> size won't change within the loop. While one could write code that uses
> an automatic variable to hold a copy of the size and another to hold the
> current count, I would regard:
>
> unsigned n=size;
> if (n) do
> {
> ...someAction...
> } while(--n);
>
> to be nicer than declaring an extra variable and hoping the optimizer gets
> rid of it.
>
Just write:
const unsigned limit = size;
for (unsigned i = 0; i < limit; i++) {
...
}
Usually, of course, if the compiler is unable to prove that "size" does
not change in the loop, it is because the loop body is complicated
enough that re-reading the size variable would be a negligible effect.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-05 14:10 +0000 |
| Message-ID | <EJ%OA.1300$BW5.217@fx28.iad> |
| In reply to | #109307 |
David Brown <david.brown@hesbynett.no> writes:
>> unsigned n=size;
>> if (n) do
>> {
>> ...someAction...
>> } while(--n);
>>
>> to be nicer than declaring an extra variable and hoping the optimizer gets
>> rid of it.
>>
>
>Just write:
>
> const unsigned limit = size;
> for (unsigned i = 0; i < limit; i++) {
> ...
> }
>
>Usually, of course, if the compiler is unable to prove that "size" does
>not change in the loop, it is because the loop body is complicated
>enough that re-reading the size variable would be a negligible effect.
>
And it's quite likely on x86_64/arm64 that size will remain
in a register for the entire loop, avoiding even a relatively
cheap load (3-4 cycles) from first level cache.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 17:12 +0200 |
| Message-ID | <oei4jh$8v5$1@dont-email.me> |
| In reply to | #109325 |
On 05/05/17 16:10, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>>> unsigned n=size;
>>> if (n) do
>>> {
>>> ...someAction...
>>> } while(--n);
>>>
>>> to be nicer than declaring an extra variable and hoping the optimizer gets
>>> rid of it.
>>>
>>
>> Just write:
>>
>> const unsigned limit = size;
>> for (unsigned i = 0; i < limit; i++) {
>> ...
>> }
>>
>> Usually, of course, if the compiler is unable to prove that "size" does
>> not change in the loop, it is because the loop body is complicated
>> enough that re-reading the size variable would be a negligible effect.
>>
>
> And it's quite likely on x86_64/arm64 that size will remain
> in a register for the entire loop, avoiding even a relatively
> cheap load (3-4 cycles) from first level cache.
>
I think his point was how to deal with things if the compiler could not
prove that it is safe to keep "size" in a register. For example, if
"size" has extern linkage and "someAction()" in the loop is an external
function call, then the compiler cannot be sure that someAction() will
not change "size" - thus it /must/ re-read size every loop.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-04 15:08 +0000 |
| Message-ID | <ZtHOA.447$3S4.381@fx17.iad> |
| In reply to | #109193 |
bartc <bc@freeuk.com> writes: >On 04/05/2017 12:07, David Brown wrote: > >>> U followed by a number n which is the [byte] width as 2**n is >>> rather perverse. >> >> The poster here seems to think that perverse is a good thing. He has >> also decided that the "for" syntax in C does not look like C, and so >> when working with other people's code he first goes through it to >> replace all for-loops with while-loops. > >That's not that unreasonable. It's a completely unreasonable habit that leads to constant code churn when the next programmer who is capable of understanding the c "for" construct changes it back from while to for.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-04 12:24 -0500 |
| Message-ID | <kromgc5meo3pvm7vr7i5qms24ncnfitgpp@4ax.com> |
| In reply to | #109215 |
On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >bartc <bc@freeuk.com> writes: >>On 04/05/2017 12:07, David Brown wrote: >> >>>> U followed by a number n which is the [byte] width as 2**n is >>>> rather perverse. >>> >>> The poster here seems to think that perverse is a good thing. He has >>> also decided that the "for" syntax in C does not look like C, and so >>> when working with other people's code he first goes through it to >>> replace all for-loops with while-loops. >> >>That's not that unreasonable. > > It's a completely unreasonable habit that leads to constant >code churn when the next programmer who is capable of understanding >the c "for" construct changes it back from while to for. One might hope that the next programmer is more reticent to change working code mere because he doesn't like the style.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-04 18:29 +0100 |
| Message-ID | <7yJOA.33714$ZL.4818@fx35.am4> |
| In reply to | #109231 |
On 04/05/2017 18:24, Robert Wessel wrote:
> On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal)
>> It's a completely unreasonable habit that leads to constant
>> code churn when the next programmer who is capable of understanding
>> the c "for" construct changes it back from while to for.
>
>
> One might hope that the next programmer is more reticent to change
> working code mere because he doesn't like the style.
It's less likely that someone would want to change 'while (cond) {}' to
'for (;cond;) {}' than the other way around. You'd hope.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-04 18:07 +0000 |
| Message-ID | <O5KOA.20866$J16.2132@fx05.iad> |
| In reply to | #109234 |
bartc <bc@freeuk.com> writes:
>On 04/05/2017 18:24, Robert Wessel wrote:
>> On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal)
>
>>> It's a completely unreasonable habit that leads to constant
>>> code churn when the next programmer who is capable of understanding
>>> the c "for" construct changes it back from while to for.
>>
>>
>> One might hope that the next programmer is more reticent to change
>> working code mere because he doesn't like the style.
>
>It's less likely that someone would want to change 'while (cond) {}' to
>'for (;cond;) {}' than the other way around. You'd hope.
For you, perhaps. For all other programmers, how do you know?
The pattern, 'for (;cond;) {}' is highly usual in my experience,
and the OP (and you) said _all_ 'for' -> 'while'.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-04 20:15 +0200 |
| Message-ID | <20170504201520.266c7f682b95e46990c0e8e7@gmail.com> |
| In reply to | #109237 |
On Thu, 04 May 2017 18:07:42 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> For you, perhaps. For all other programmers, how do you know?
>
> The pattern, 'for (;cond;) {}' is highly usual in my experience,
> and the OP (and you) said _all_ 'for' -> 'while'.
It is only a bad hack from bad programmers.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-04 15:47 -0700 |
| Message-ID | <652597df-cedf-4f3c-bb02-f5215f691dba@googlegroups.com> |
| In reply to | #109240 |
On Friday, May 5, 2017 at 3:18:28 AM UTC+9, GOTHIER Nathan wrote:
> On Thu, 04 May 2017 18:07:42 GMT
> scott@somewhere (Scott Lurndal) wrote:
>
> > For you, perhaps. For all other programmers, how do you know?
> >
> > The pattern, 'for (;cond;) {}' is highly usual in my experience,
> > and the OP (and you) said _all_ 'for' -> 'while'.
>
> It is only a bad hack from bad programmers.
Just out of curiosity, what do you think is the best way to specify a loop whose only terminating condition is most efficiently tested somewhere between the entry point and the loop point?
Do you like the vernacular:
for (;;)
{
/* stuff */
if ( condition ) break;
/* stuff */
}
?
--
Joel Rees
Re-inventing the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-05 01:22 +0200 |
| Message-ID | <20170505012240.7362326e9670ddf5b9530a92@gmail.com> |
| In reply to | #109279 |
On Thu, 4 May 2017 15:47:21 -0700 (PDT)
joel.rees@gmail.com wrote:
> Just out of curiosity, what do you think is the best way to specify a loop
> whose only terminating condition is most efficiently tested somewhere between
> the entry point and the loop point?
loop_start:
{
/* stuff */
if (condition)
{
goto loop_end;
}
/* stuff */
goto loop_start;
}
loop_end:
Actually I like very much basic loops with label/goto and I think programmers
should write first a loop with this skeleton before using any loop structure
when the code needs to be clearer.
> Do you like the vernacular:
>
> for (;;)
> {
> /* stuff */
> if ( condition ) break;
> /* stuff */
> }
>
> ?
I don't like much the broken for structure.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-04 18:57 -0700 |
| Message-ID | <2cb34410-64af-49cc-94d4-cabeaf676c27@googlegroups.com> |
| In reply to | #109280 |
On Friday, May 5, 2017 at 8:25:40 AM UTC+9, GOTHIER Nathan wrote:
> On Thu, 4 May 2017 15:47:21 -0700 (PDT)
> joel rees@somewhere wrote:
>
> > Just out of curiosity, what do you think is the best way to specify a loop
> > whose only terminating condition is most efficiently tested somewhere between
> > the entry point and the loop point?
>
> loop_start:
> {
> /* stuff */
>
> if (condition)
> {
> goto loop_end;
> }
>
> /* stuff */
>
> goto loop_start;
> }
> loop_end:
I assume that was somewhat tongue-in-cheek?
> Actually I like very much basic loops with label/goto and I think programmers
> should write first a loop with this skeleton before using any loop structure
> when the code needs to be clearer.
I assumed wrong.
Well, shoot, I think that every introductory programming
course should consist of a guided implementation of a Forth
interpreter in M6809 assembly language.
(Sometimes. When I'm really frustrated at, for example,
someone's inability to understand how high-level instructions
have to eventually map to some sort of real machine language
code. But not really. ;)
> > Do you like the vernacular:
> >
> > for (;;)
> > {
> > /* stuff */
> > if ( condition ) break;
> > /* stuff */
> > }
> >
> > ?
>
> I don't like much the broken for structure.
At one time, at least, it was the recommended form for
indeterminant loops because the elided condition is specified
to always be true.
while( 1 )
{
/* stuff */
if ( condition ) break;
/* more stuff */
}
on the other hand, is hard to distinguish from optimization
that resulting from unintentionally writing a constant
expression, and should be flagged with a warning when
compiling with warnings enabled.
Or so the reasoning went.
I assume you are familiar with that bit of history?
If C allowed bare blocks to be used as loops the way perl
does, would you still perceive the labels to be useful?
--
Joel Rees
Imagining I'm a novelist:
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-05 09:30 +0200 |
| Message-ID | <20170505093052.aa0385dac4caf67336be2ca9@gmail.com> |
| In reply to | #109283 |
On Thu, 4 May 2017 18:57:39 -0700 (PDT)
joel.rees@gmail.com wrote:
> At one time, at least, it was the recommended form for
> indeterminant loops because the elided condition is specified
> to always be true.
>
> while( 1 )
> {
> /* stuff */
> if ( condition ) break;
> /* more stuff */
> }
>
>
> on the other hand, is hard to distinguish from optimization
> that resulting from unintentionally writing a constant
> expression, and should be flagged with a warning when
> compiling with warnings enabled.
>
> Or so the reasoning went.
>
> I assume you are familiar with that bit of history?
I know this kind of tricks exist that's why I prefer to use label/goto for
exotic loops or as a starting point.
> If C allowed bare blocks to be used as loops the way perl
> does, would you still perceive the labels to be useful?
I have to confess I am not a Perl expert at all. I tried once to learn Perl to
write CGI but realized that I could write a better code in standard C. What
kind of magic loop structure does Perl offer?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-05 01:25 -0700 |
| Message-ID | <kfn37cjyal9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109279 |
joel.rees@gmail.com writes: > [.. on uses of for() and while() ..] > > Just out of curiosity, what do you think is the best way to specify a > loop whose only terminating condition is most efficiently tested > somewhere between the entry point and the loop point? It depends a lot on what is done before and after the exit test. Usually I see the presence of a "loop and a half" as an indicator that the code needs to be re-thought or re-written, or both.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-05 10:33 +0200 |
| Message-ID | <20170505103359.7e872cdd6ba4ac8c1345aa37@gmail.com> |
| In reply to | #109302 |
On Fri, 05 May 2017 01:25:06 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > It depends a lot on what is done before and after the exit test. > Usually I see the presence of a "loop and a half" as an indicator > that the code needs to be re-thought or re-written, or both. Indeed. This kind of loop logic looks broken. It's better to rearrange the code in a more common pattern to make it clearer for everyone.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-05 10:10 -0700 |
| Message-ID | <kfnzierut49.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109306 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes: > On Fri, 05 May 2017 01:25:06 -0700 > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> It depends a lot on what is done before and after the exit test. >> Usually I see the presence of a "loop and a half" as an indicator >> that the code needs to be re-thought or re-written, or both. > > Indeed. This kind of loop logic looks broken. It's better to > rearrange the code in a more common pattern to make it clearer for > everyone. I would say usually better. Sometimes using a loop-and-a-half is the least awkward expression for what needs to be done. Not often, but sometimes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 12:49 +0200 |
| Message-ID | <oehl51$ijc$1@dont-email.me> |
| In reply to | #109302 |
On 05/05/17 10:25, Tim Rentsch wrote: > joel.rees@gmail.com writes: > >> [.. on uses of for() and while() ..] >> >> Just out of curiosity, what do you think is the best way to specify a >> loop whose only terminating condition is most efficiently tested >> somewhere between the entry point and the loop point? > > It depends a lot on what is done before and after the exit test. > Usually I see the presence of a "loop and a half" as an indicator > that the code needs to be re-thought or re-written, or both. > I think what is important is that the terminating condition of a loop be clear in the code. You should be able to see quickly what will cause a termination, and where it terminates. It is usually easiest to see that when the condition is at the start of the loop - but not always. Sometimes it is clearer to put a break (or even a return) in the middle of the loop, especially if the alternative would be a somewhat complex "while" condition. It can quickly become difficult to follow the logic if you have a terminating condition in the while/for clause, /and/ break statements. With "while (true)" then you know the termination is in the middle of the loop somewhere, if the program is not intended to run indefinitely.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-05 18:31 -0700 |
| Message-ID | <7824a9f1-7b2e-4102-a8df-f73ba8358ea0@googlegroups.com> |
| In reply to | #109302 |
On Friday, May 5, 2017 at 5:25:12 PM UTC+9, Tim Rentsch wrote: > joel.rees@somewhere writes: > > > [.. on uses of for() and while() ..] > > > > Just out of curiosity, what do you think is the best way to specify a > > loop whose only terminating condition is most efficiently tested > > somewhere between the entry point and the loop point? > > It depends a lot on what is done before and after the exit test. > Usually I see the presence of a "loop and a half" as an indicator > that the code needs to be re-thought or re-written, or both. I've wasted an awful lot of time re-thinking code so I can move the test to the top or bottom, and trying to decide whether the loop is more clearly expressed as a counted or enumerated loop, or as a general loop. The exit point often moves as my understanding of the loop improves, but not always to one end or the other. I shouldn't say, "wasted", although my bosses generally did. It helped write bug-free, maintainable code. I've found that no clear rule exists to claim a good common form. In particular, exit flags can get in the way as easily as clarify. Well, one rule -- keep the expressed loop short. Use macros when it helps, use subroutines if you have to. But it strikes me as ironic that the once-recommended idiom for an indeterminate loop (My vocabulary memory yesterday was off, wasn't it?) is now looked upon with such disdain. (And the dialectic idiom for a mask is practically standard. Go figure.) -- Joel Rees Ranting randomly: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web