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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-10 10:07 +0000 |
| Message-ID | <5912e49d.433656@news.xs4all.nl> |
| In reply to | #108883 |
Keith Thompson <kst-u@mib.org> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > [...] > > (Note also that the reason for the difference in treatment of signed and > > unsigned integers is obvious: there is no equivalent for unsigned > > representations of the distinction between 2'C, 1'C and S/M. The only > > different kind of unsigned representation you _can_ reasonably have is > > saturation; and that is unnatural and massively expensive to every kind > > of machine representation, including even mechanical odometers.) > > Saturation is not a representation. Representation is about what bits > represent what values. Saturation vs. wraparound is about the result of > operations. You are right, of course; and also, there are good reasons why saturaion is not an allowable option in the C Standard. Nevertheless they are related concepts, when you consider that the difference in sign representation is one of the reasons why signed overflow does differ when unsigned does not. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 08:44 -0700 |
| Message-ID | <1ee729a1-8887-4f78-b601-79357178c1ff@googlegroups.com> |
| In reply to | #108849 |
On Monday, May 1, 2017 at 4:08:44 AM UTC-5, Richard Bos wrote:
> (Note also that the reason for the difference in treatment of signed and
> unsigned integers is obvious: there is no equivalent for unsigned
> representations of the distinction between 2'C, 1'C and S/M. The only
> different kind of unsigned representation you _can_ reasonably have is
> saturation; and that is unnatural and massively expensive to every kind
> of machine representation, including even mechanical odometers.)
The vast majority of C implementations run on hardware that treats signed
integers as the *same* abstract algebraic ring as unsigned integers. Both
types supplement the operations defined by the ring (to wit, addition,
multiplication, and equality testing) with some additional operations that
work the same way on both (bitwise operators and left-shift), and some that
work differently (conversion to larger types, division, remainder, and
relational comparisons).
For *any* numeric type, there are two things that can happen when a result
would be outside the range of a type; depending upon the target hardware and
purpose, there are three things an implementation might sensibly do, possibly
chosen in Unspecified fashion, if a computed value would be outside the range
of a type:
1. Yield a value of some kind (possibly non-deterministic in the CS sense of
the word)(*).
2. Indicate an error via some Implementation-Defined means without returning
a value (e.g. raise a signal, terminate the program, etc.)
3. Indicate an error via some Implementation-Defined means in addition to
returning a value (e.g. set a testable overflow-error flag).
The Standard doesn't really have any concept for "Select in Unspecified
fashion among a list of specified behaviors", nor does it define any category
of values that behave in specified, though non-deterministic, fashion.
(*) From a CS standpoint, a non-determinstic value would effectively
represent a set of possibilities. From an implementation standpoint,
values would not typically be kept as sets, but might be tracked by
the compiler as sequences of operations that compute them. If an
implementation specifies that an Indeterminate Value of any signed
integer type will behave non-deterministically any mathematical integer,
and f() has no side effects but returns such a value, then given:
int x = f();
int y1 = x & 5;
int y2 = x & 9;
volatile int z1 = y1+y2;
volatile int z2 = y1+y2;
Essentially, because f() has no side-effects, a compiler would be able
to at its leisure replace the code with:
volatile int z1 = (f() & 5)+(f() & 9);
volatile int z2 = (f() & 5)+(f() & 9);
which could store any value from the set {0,1,2,4,5,6,8,9,10,12,13,14}
into z1, and could store any value (same or different) from that set
into z2.
The Standard has no terminology to describe non-deterministic values beyond
characterizing as UB all actions that could create them. On the other hand,
a non-deterministic execution model like the above, combined with ways of
forcing a compiler to convert a non-deterministic value into a number
arbitrarily chosen from its set of possibilities, would allow programmers to
allow compilers a lot more flexibility in optimization than would otherwise
be possible.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-01 09:03 -0700 |
| Message-ID | <ln7f20imy1.fsf@kst-u.example.com> |
| In reply to | #108884 |
supercat@casperkitty.com writes:
[...]
> The Standard doesn't really have any concept for "Select in Unspecified
> fashion among a list of specified behaviors",
[...]
N1570 3.4.4:
unspecified behavior
use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities
and imposes no further requirements on which is chosen in
any instance
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 09:51 -0700 |
| Message-ID | <a472984b-6ec1-4ef9-8d6d-672f032f1a81@googlegroups.com> |
| In reply to | #108889 |
On Monday, May 1, 2017 at 11:03:41 AM UTC-5, Keith Thompson wrote: > supercat writes: > [...] > > The Standard doesn't really have any concept for "Select in Unspecified > > fashion among a list of specified behaviors", > [...] > > N1570 3.4.4: > > unspecified behavior > > use of an unspecified value, or other behavior where this > International Standard provides two or more possibilities > and imposes no further requirements on which is chosen in > any instance I have only noticed that term used in the Standard in cases where the Standard itself specifies all of the allowable behaviors, e.g. the Standard allows the expression f(x(),y()) to behave as though it computes x() and then y(), or y() and then x(), but those are the only two allowable behaviors. Are there any cases where the Standard uses the term Unspecified Behavior to allow an implementation to select among choices that are not described within the Standard itself? The phrase "Unspecified Behavior" appears a total of 6 times; I haven't looked at Annex J1 in detail, but anything there should also be described elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-01 11:30 -0700 |
| Message-ID | <lnziewh1l4.fsf@kst-u.example.com> |
| In reply to | #108893 |
supercat@casperkitty.com writes:
> On Monday, May 1, 2017 at 11:03:41 AM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> [...]
>> > The Standard doesn't really have any concept for "Select in Unspecified
>> > fashion among a list of specified behaviors",
>> [...]
>>
>> N1570 3.4.4:
>>
>> unspecified behavior
>>
>> use of an unspecified value, or other behavior where this
>> International Standard provides two or more possibilities
>> and imposes no further requirements on which is chosen in
>> any instance
>
> I have only noticed that term used in the Standard in cases where the
> Standard itself specifies all of the allowable behaviors, e.g. the Standard
> allows the expression f(x(),y()) to behave as though it computes x() and
> then y(), or y() and then x(), but those are the only two allowable
> behaviors.
Look up about 20 lines. You'll see a paragraph you wrote:
The Standard doesn't really have any concept for "Select in
Unspecified fashion among a list of specified behaviors",
> Are there any cases where the Standard uses the term Unspecified Behavior
> to allow an implementation to select among choices that are not described
> within the Standard itself?
I hope not, since that would contradict the definition of "unspecified
behavior", which requires a list of two or more possibilities.
> The phrase "Unspecified Behavior" appears a
> total of 6 times; I haven't looked at Annex J1 in detail, but anything there
> should also be described elsewhere.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 11:41 -0700 |
| Message-ID | <f9e8afd7-323d-4f50-a612-deb2ee15d001@googlegroups.com> |
| In reply to | #108919 |
On Monday, May 1, 2017 at 1:30:22 PM UTC-5, Keith Thompson wrote: > supercat writes: > > On Monday, May 1, 2017 at 11:03:41 AM UTC-5, Keith Thompson wrote: > >> supercat writes: > >> [...] > >> > The Standard doesn't really have any concept for "Select in Unspecified > >> > fashion among a list of specified behaviors", > >> [...] > >> > >> N1570 3.4.4: > >> > >> unspecified behavior > >> > >> use of an unspecified value, or other behavior where this > >> International Standard provides two or more possibilities > >> and imposes no further requirements on which is chosen in > >> any instance > > > > I have only noticed that term used in the Standard in cases where the > > Standard itself specifies all of the allowable behaviors, e.g. the Standard > > allows the expression f(x(),y()) to behave as though it computes x() and > > then y(), or y() and then x(), but those are the only two allowable > > behaviors. > > Look up about 20 lines. You'll see a paragraph you wrote: > > The Standard doesn't really have any concept for "Select in > Unspecified fashion among a list of specified behaviors", Sorry--I meant "Select in possibly-unspecified fashion from a list of possible behaviors *specified by the implementation*. In general, when the Standard uses the term "Implementation-Defined", the apparent intention is that implementations specify a *precise* behavior. If the authors of the Standard had wanted to e.g. allow an implementation to specify that integer overflow might yield a truncated result or might raise a signal, without it having to indicate when it would do one versus the other, would there have been any term other than "Undefined Behavior" that they could have used to describe that? Categorizing the behavior as Implementation-Defined would suggest that a conforming implementation would be required to specify cases where overflow would raise a signal, rather than leaving such choice of behaviors Unspecified.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-01 11:51 -0700 |
| Message-ID | <lnr308h0l4.fsf@kst-u.example.com> |
| In reply to | #108924 |
supercat@casperkitty.com writes:
> On Monday, May 1, 2017 at 1:30:22 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > On Monday, May 1, 2017 at 11:03:41 AM UTC-5, Keith Thompson wrote:
>> >> supercat writes:
>> >> [...]
>> >> > The Standard doesn't really have any concept for "Select in Unspecified
>> >> > fashion among a list of specified behaviors",
[SNIP]
> Sorry--I meant "Select in possibly-unspecified fashion from a list of
> possible behaviors *specified by the implementation*.
I don't think the standard has a term for that.
> In general, when the Standard uses the term "Implementation-Defined", the
> apparent intention is that implementations specify a *precise* behavior.
> If the authors of the Standard had wanted to e.g. allow an implementation
> to specify that integer overflow might yield a truncated result or might
> raise a signal, without it having to indicate when it would do one versus
> the other, would there have been any term other than "Undefined Behavior"
> that they could have used to describe that?
That would be unspecified behavior, assuming that the options of a
truncated result and a signal are specified by the standard. If you want
the list of options to be specified by the implementation rather than by
the standard, see above.
[...]
You ask long-winded questions with obvious answers. If the questions
are rhetorical, please make your point more directly.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-24 08:51 -0700 |
| Message-ID | <a32cd411-8d09-4c0e-b16a-8d509af3fb45@googlegroups.com> |
| In reply to | #108398 |
On Monday, April 24, 2017 at 6:24:01 AM UTC-5, David Brown wrote: > In C, signed overflow is /always/ a mistake. There are no circumstances > in standard C programming in which it is not an error. Was it a mistake when Dennis Ritchie exploited it in the printf routine given in the 1974 C Reference Manual? > That argument would have merit if you were talking about a language that > defines signed integer arithmetic in terms of the underlying hardware. > C does not do that. The C Standard *allows*, but does not require, implementations to define things in terms of underlying platform behavior except when that would be inconsistent with other requirements in the Standard. Implementations that are designed for low-level programming will often do so. When the Standard was written, there existed code that relied upon certain behaviors like two's-complement wraparound, and there existed platforms where guaranteeing that behavior would be expensive. The authors of the Standard didn't say that implementations that do something other than two's- complement are "broken", but nor did they say that there is anything "broken" about programs that rely upon it, beyond the fact that such code will not be portable to implementations that do something else. The Standard uses the phrase "non-portable or erroneous" to describe UB. The use of the conjunction "OR" allows for the possibility that the behavior may be non-portable without being erroneous. The rationale given for making short unsigned values makes explicit mention of the fact that the majority of then-current implementations used silent wraparound two's-complement semantics and mentions situations in which this is useful. I find it curious that they would mention such situations if they would regard as "broken" any code that would exploit them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-24 12:13 -0700 |
| Message-ID | <lntw5dobzr.fsf@kst-u.example.com> |
| In reply to | #108409 |
supercat@casperkitty.com writes:
> On Monday, April 24, 2017 at 6:24:01 AM UTC-5, David Brown wrote:
>> In C, signed overflow is /always/ a mistake. There are no circumstances
>> in standard C programming in which it is not an error.
>
> Was it a mistake when Dennis Ritchie exploited it in the printf routine
> given in the 1974 C Reference Manual?
No. C as it existed at that time did not have the concept of undefined
behavior. It was not what we now call "standard C".
For a modern implementation, it would not be a mistake if the author
knows how the implementation happens to behave; since printf is part of
the implementation, the only requirement is that it works as specified.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-01 09:11 +0000 |
| Message-ID | <5906fb7f.7434578@news.xs4all.nl> |
| In reply to | #108409 |
supercat@casperkitty.com wrote: > On Monday, April 24, 2017 at 6:24:01 AM UTC-5, David Brown wrote: > > In C, signed overflow is /always/ a mistake. There are no circumstances > > in standard C programming in which it is not an error. > > Was it a mistake when Dennis Ritchie exploited it in the printf routine > given in the 1974 C Reference Manual? No, because printf() is an implementation library function, and the implementation itself need not be written in Standard C in the first place. Much of it cannot. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-27 14:04 -0700 |
| Message-ID | <kfn60hp36kw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108386 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > On 4/22/2017 2:47 AM, bartc wrote: > >>> That's not a compiler failure - the code is broken. Signed integer >>> overflow has undefined behaviour, and therefore, gcc is allowed to >>> assume that it doesn't ever happen. It's allowed to do so because, when >>> it _does_ happen, any result is allowed, including pretending that it >>> didn't happen. >> >> Nevertheless, it desirable to have consistent behaviour across >> optimisation levels. >> ... > > That makes no sense whatsoever. > > Undefined behavior is unstable by definition. [...] That isn't right. You might say undefined behavior has the _potential_ to be unstable by definition, but that's not the same thing. Kind of like weather: there can be a 10% chance that it /will/ rain, but the chance that it /might/ rain is always 100% (or maybe 0% on one of the outer planets, but you get the idea).
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2017-04-22 10:57 +0100 |
| Message-ID | <odf99b$406$1@dont-email.me> |
| In reply to | #108329 |
On 22/04/2017 10:29, Richard Bos wrote:
> James Harris <james.harris.1@gmail.com> wrote:
>
>> I saw this posted elsewhere. The gcc optimiser evidently changes the
>> behaviour of the code relative to its non-optimised effect.
>>
>> int main(int argc, char **argv) {
>> int i;
>> for (i = 0; i < i + 1; i++)
>> ;
>> return 0;
>> }
>
> That's not a compiler failure - the code is broken. Signed integer
> overflow has undefined behaviour, and therefore, gcc is allowed to
> assume that it doesn't ever happen. It's allowed to do so because, when
> it _does_ happen, any result is allowed, including pretending that it
> didn't happen.
>
> Try changing the int to an unsigned int and run your tests again. If it
> optimises the check into non-existence again, _then_ gcc is at fault.
Tried that and the non-optimised and optimised do work the same way.
IMO gcc is still at fault (and I use the term for a preference, not a
technical failure) for not reporting, by default, that the optimiser was
making an assumption. It doesn't seem even to have a way to turn on
warnings for all assumptions that the optimiser is making. Maybe there
is and I've just not found it yet. But ATM it seems there are loads of
individual switches which must be supplied on the command line if you
want to catch all recognisable cases of the optimiser making assumptions
that could change code behaviour.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-22 11:38 +0100 |
| Message-ID | <87o9voengz.fsf@gmail.com> |
| In reply to | #108332 |
James Harris <james.harris.1@gmail.com> writes: > IMO gcc is still at fault (and I use the term for a preference, not a > technical failure) for not reporting, by default, that the optimiser > was making an assumption. It's not an optimiser assumption, its a contract the programmer willingly enters into when they chose to write (correct) C.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-04-22 13:43 +0000 |
| Message-ID | <odfmmu$ap2$1@news.xmission.com> |
| In reply to | #108335 |
In article <87o9voengz.fsf@gmail.com>, Gareth Owen <gwowen@gmail.com> wrote: >James Harris <james.harris.1@gmail.com> writes: > >> IMO gcc is still at fault (and I use the term for a preference, not a >> technical failure) for not reporting, by default, that the optimiser >> was making an assumption. > >It's not an optimiser assumption, its a contract the programmer >willingly enters into when they chose to write (correct) C. That is a stupid thing to say. Quite in keeping with this newsgroup, but utterly useless and insulting to the OP. Congrats. -- Rich people pay Fox people to convince middle class people to blame poor people. (John Fugelsang)
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-22 18:22 +0100 |
| Message-ID | <87mvb84asy.fsf@gmail.com> |
| In reply to | #108337 |
gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <87o9voengz.fsf@gmail.com>, Gareth Owen <gwowen@gmail.com> wrote:
>>James Harris <james.harris.1@gmail.com> writes:
>>
>>> IMO gcc is still at fault (and I use the term for a preference, not a
>>> technical failure) for not reporting, by default, that the optimiser
>>> was making an assumption.
>>
>>It's not an optimiser assumption, its a contract the programmer
>>willingly enters into when they chose to write (correct) C.
>
> That is a stupid thing to say
No it isn't. The assumption is that there's some integer for which
(i < i + 1)
is not true.
And in C, as in actual mathematics, that's a **wrong** assumption.
And UB is UB for the entire program. If you're unprepared to deal with
the consequences of that, then you're going to get confused.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-04-22 17:48 +0000 |
| Message-ID | <odg50j$imo$1@news.xmission.com> |
| In reply to | #108343 |
In article <87mvb84asy.fsf@gmail.com>, Gareth Owen <gwowen@gmail.com> wrote: >gazelle@shell.xmission.com (Kenny McCormack) writes: > >> In article <87o9voengz.fsf@gmail.com>, Gareth Owen <gwowen@gmail.com> wrote: >>>James Harris <james.harris.1@gmail.com> writes: >>> >>>> IMO gcc is still at fault (and I use the term for a preference, not a >>>> technical failure) for not reporting, by default, that the optimiser >>>> was making an assumption. >>> >>>It's not an optimiser assumption, its a contract the programmer >>>willingly enters into when they chose to write (correct) C. >> >> That is a stupid thing to say > >No it isn't. It is. You're just too stupid to realize it. It's like telling a Trump voter he's stupid. He won't agree with you. -- A 70 year old man who watches 6 hours of TV a day, plays a lot of golf and seems to always be in Florida is a retiree, not a president.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-22 14:24 -0700 |
| Message-ID | <af97df0e-61e2-4efa-a603-e2a5016df196@googlegroups.com> |
| In reply to | #108335 |
On Saturday, April 22, 2017 at 5:38:43 AM UTC-5, gwowen wrote: > It's not an optimiser assumption, its a contract the programmer > willingly enters into when they chose to write (correct) C. Unlike most "standards", the C Standard does not define conformance of C programs in a fashion that is useful for most purposes. It defines a category of "strictly conforming" programs which can't do many of the tasks required of many practical C programs, or "conforming" programs, a term which is so broad as to be almost meaningless. If the above code were targeted at a particular implementation that specified that automatic variables will initially hold whatever bit pattern was in their stack slot when the function was called, and that adding +1 to INT_MAX would yield INT_MIN, then the code would be non-portable but not "erroneous". For some reason, compiler writers seem to assume that when the Standard says "non-portable or erroneous", it means "broken". The above code makes assumptions about signed integer behavior which would limit its use to compilers that perform integer operations in very "literal" fashion. In many cases, compilers will be able to generate more efficient code if they are allowed to behave as though integer expressions may be evaluated with excess range and then truncated to the specified size (or not) at the compiler's convenience. There are three levels of behavioral guarantees typical compilers without documented overflow traps may offer with regard to integer overflow: 1. They may guarantee that all integer expressions will be immediately truncated to a value of the appropriate type, in a fashion analogous to unsigned types. 2. They may guarantee that the expressions will behave like numbers whose lower (type size) bits are correct, but which may behave as though they have additional upper bits that might be kept or dropped at any point at the compiler's leisure. 3. They may reserve the right to behave in any manner whatsoever, including corrupting unrelated parts of the program. The code as written requires a compiler that upholds guarantee #1. If the expression were rewritten (int)(i+1) > i, and if a system guaranteed that casting a to "int" an integer value beyond the range of that type will chop off and sign extend the lower (int-size) bits, then it would work with compilers that uphold either #1 or #2; it would also be more visually obvious that the programmer is wanting the program to do something which behaves differently from the normal rules of arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-04-27 03:03 -0700 |
| Message-ID | <93c95feb-be70-4f23-ac2e-a30eeace0656@googlegroups.com> |
| In reply to | #108335 |
On Saturday, April 22, 2017 at 7:38:43 PM UTC+9, gwowen wrote: > James Harris <> writes: > > > IMO gcc is still at fault (and I use the term for a preference, not a > > technical failure) for not reporting, by default, that the optimiser > > was making an assumption. > > It's not an optimiser assumption, its a contract the programmer > willingly enters into when they chose to write (correct) C. I never signed it, and I've been programming in C for a pretty long time. There is a difference between implementation defined and undefined. -- Joel Rees
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-27 10:12 -0400 |
| Message-ID | <odsu1k$cdl$1@dont-email.me> |
| In reply to | #108588 |
On 04/27/2017 06:03 AM, joel.rees@gmail.com wrote: > On Saturday, April 22, 2017 at 7:38:43 PM UTC+9, gwowen wrote: >> James Harris <> writes: >> >>> IMO gcc is still at fault (and I use the term for a preference, not a >>> technical failure) for not reporting, by default, that the optimiser >>> was making an assumption. >> >> It's not an optimiser assumption, its a contract the programmer >> willingly enters into when they chose to write (correct) C. > > I never signed it, and I've been programming in C for a pretty long time. You don't have to sign it, and you're therefore not legally bound by it. Calling it a contract is just a metaphor. If you provide code that obeys the rules imposed by the C standard, a conforming implementation of C must produce behavior consistent with the requirements imposed by that standard for the code. There's no requirement that you actually obey those rules (and this code doesn't), nor is there any requirement that any particular implementation of C conform to the standard.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-22 21:48 +0000 |
| Message-ID | <58fbcf02.49434953@news.xs4all.nl> |
| In reply to | #108332 |
James Harris <james.harris.1@gmail.com> wrote: > IMO gcc is still at fault (and I use the term for a preference, not a > technical failure) for not reporting, by default, that the optimiser was > making an assumption. It doesn't seem even to have a way to turn on > warnings for all assumptions that the optimiser is making. Have you read the third part of the article Andrew Cooper posted? It explains this quite clearly: it is often not even possible to do this because so many of those assumptions interact, and where it _is_ possible, it almost certainly does not give you the clear messages you expect. It really is much more complicated than you presume it to be. Maybe in such simple demonstration code as you posted you can force a meaning, but certainly in any realistic code base, you're trying to combat the tide. Richard
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web