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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-01 21:52 +0200 |
| Message-ID | <oe83g9$13v$1@dont-email.me> |
| In reply to | #108899 |
On 01/05/17 19:16, David Kleinecke wrote: > On Monday, May 1, 2017 at 7:27:33 AM UTC-7, David Brown wrote: >> On 01/05/17 00:33, David Kleinecke wrote: >>> On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote: >> >>>> >>>> So sometimes you use Int to mean "signed int", and sometimes you use it >>>> to mean "unsigned int". I thought it would be hard to come up with a >>>> worse idea than using "Int" for "unsigned int" - but it seems I >>>> underestimated you! >>>> >>>> If a type has a standard name, use it. If you have some serious >>>> aversion to writing bool, long, etc., then at the very least make sure >>>> that Bool, Long, etc., are defined exactly as the normal lower case >>>> versions. >>> >>> The kind of code I read and write rather rarely has any simple >>> types other than Bool and Void. Most of the types are typedefs >>> of structs. >>> ty >>> >> >> It's fine to give your own types your own names. All I am saying is >> don't give existing standard types new names that are confusing or >> pointless, and don't pick names that are confusingly like existing >> standard types. > > I agree with that in general but we may differ in detail. I > include > typedef signed int Int; That is pointless and confusing - the standard name for that in C is "int", and "Int" gives you no benefits, while making your code much harder to read. It is also different from what you first wrote: > I usually cheat by typedeffing "Int" as "unsigned int". You then wrote that you sometimes use "Int" as "unsigned int", sometimes as "signed int". > typedef unsigned int Unt; > typedef void Void; Also all pointless, unless your aim is to make your code indecipherable to other C programmers. > in order to start all type names with a capital. I find the > convention of starting type name with a capital helpful - I > suspect other people may deplore it. De gustibus. For your own types, make your own choices. For standard types, use the standard names. > > But I am not an admirer of the built-in C type system. I would > prefer something along the lines of > U0 : unsigned char > S0 : signed char > U1 : unsigned 16-bits > S1 : signed 16-bits > U2 : unsigned 32-bits > U3 : unsigned 64-bits > U4 : unsigned 128-bits > etc. > and other names for things like 48-bit types. C has types such as int32_t and uint16_t that let you specific exact sizes (as well as related types with loser specification but greater portability). Again, these are well-known standard names. People have certainly been known to disagree with the particular choice of names here, but I have not seen any that strike me as significantly better. Certainly your suggestions here are not an improvement IMHO. > > I know there are other versions of this stuff. Most of the > others are hideous. > Beauty is a matter of opinion - the standard type names and identifiers are not.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-01 23:16 +0200 |
| Message-ID | <20170501231657.80c1a41cf55d24214fbaca86@gmail.com> |
| In reply to | #108899 |
On Mon, 1 May 2017 10:16:42 -0700 (PDT) David Kleinecke <dkleinecke@gmail.com> wrote: > I agree with that in general but we may differ in detail. I > include > typedef signed int Int; > typedef unsigned int Unt; > typedef void Void; > in order to start all type names with a capital. I find the > convention of starting type name with a capital helpful - I > suspect other people may deplore it. De gustibus. Indeed. I would rather give new names for cumbersome names such as unsigned short as ushrt_t or unsigned long as ulong_t. > But I am not an admirer of the built-in C type system. I would > prefer something along the lines of > U0 : unsigned char > S0 : signed char > U1 : unsigned 16-bits > S1 : signed 16-bits > U2 : unsigned 32-bits > U3 : unsigned 64-bits > U4 : unsigned 128-bits > etc. > and other names for things like 48-bit types. That's short but not very expressive. It can only lead to an unmaintainable code even by its own author. We are humans and we need clarity in expressing what things are.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-02 09:19 +0200 |
| Message-ID | <oe9bn9$37l$1@dont-email.me> |
| In reply to | #108968 |
On 01/05/17 23:16, GOTHIER Nathan wrote: > On Mon, 1 May 2017 10:16:42 -0700 (PDT) > David Kleinecke <dkleinecke@gmail.com> wrote: > >> I agree with that in general but we may differ in detail. I >> include >> typedef signed int Int; >> typedef unsigned int Unt; >> typedef void Void; >> in order to start all type names with a capital. I find the >> convention of starting type name with a capital helpful - I >> suspect other people may deplore it. De gustibus. > > Indeed. I would rather give new names for cumbersome names such as unsigned > short as ushrt_t or unsigned long as ulong_t. > That seems fair enough. It's a matter of taste whether you like these or not - I am not keen on them, but then, I prefer to use the size explicit types in most of my code. If you want to have a short form for "unsigned long int", then "ulong_t" sounds perfectly reasonable to me. Short, but understandable - and more importantly, it will not be mistaken for something else (unlike using "Int" for "unsigned int"). > >> But I am not an admirer of the built-in C type system. I would >> prefer something along the lines of >> U0 : unsigned char >> S0 : signed char >> U1 : unsigned 16-bits >> S1 : signed 16-bits >> U2 : unsigned 32-bits >> U3 : unsigned 64-bits >> U4 : unsigned 128-bits >> etc. >> and other names for things like 48-bit types. > > That's short but not very expressive. It can only lead to an unmaintainable > code even by its own author. We are humans and we need clarity in expressing > what things are. > It is also contrary to the common convention of giving sized types in bit sizes, rather than powers of 8 bits. There is plenty of code written using types like "u32" and "i16" - not good choices, IMHO, but still much better than "U2" or "S1".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-30 17:28 -0700 |
| Message-ID | <2e6d0b33-441d-426d-9dcc-b2eef4921b75@googlegroups.com> |
| In reply to | #108780 |
On Sunday, April 30, 2017 at 11:57:49 AM UTC-5, robert...@yahoo.com wrote:
> While true, that completely misses the point. The OP used a signed
> integer for a reason. It's also different if the function took a
> float (and assuming IEEE math), but again, he didn't do that. This is
> an example of where the compiler taking advantage of undefined
> behavior (signed integer overflow), can remove "undefined" behavior
> when optimization is *enabled*. Leading to even more difficulty about
> warning of such a thing.
Allowing a compiler to substitute longer types for signed integers (as is
commonly done for floating-point types), or behave as though it is doing
so, will enable many useful optimizations. In floating-point types, such
extra precision may be suppressed by the use of explicit casts. Unless
FLT_EVAL_METHOD is defined to promise otherwise, a compiler given:
double d = float1 + float2;
would be allowed to either perform the computation on float values directly
and then convert the result to "double", or convert the operands to a longer
type, add them as that type, and then convert the result to double (if it
isn't already). If an implementation where to extend the freedom offered by
the Standard solely for that purpose and would evaluate all integer
operations other than division/remainder as though it computed the result
using mathematical integers and then truncated to an Unspecified number of
bits at least as large as the result type, that would allow for many useful
optimizations. If the implementation further promised that, as with
floating point values, an explicit cast would discard any precision beyond
that of the indicated type (so that just as e.g.
double d = (float)(float1 + float2);
would yield a value that was precisely representable as "float", the
expression
(int)(x+y) > z
would truncate the result f x+y into the range of "int" and then perform
the comparison, any program which could be written under "precise wrapping"
semantics could be written to be compatible with the optimization without
having to convert operands to unsigned and then back to int.
The purpose of a compiler should, fundamentally, be to produce executable
code that meets a programmer's requirements. If a programmer's requirements
would be met just as well by having a compiler evaluate x+y>z by mod-reducing
the sum before the comparison or by having it behave as though it evaluates
the expression using "extra bits", allowing a compiler to use whichever is
more efficient in any given context may yield a faster executable than would
be possible if the program had to rigidly specify one or the other.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-01 13:12 +0000 |
| Message-ID | <ZuGNA.38961$e61.12380@fx23.iad> |
| In reply to | #108780 |
Robert Wessel <robertwessel2@yahoo.com> writes: >On Sun, 30 Apr 2017 17:35:39 +0100, bartc <bc@freeuk.com> wrote: > >While true, that completely misses the point. The OP used a signed >integer for a reason. Actually, I suspect that the vast majority of C programmers who use 'int' use it out of inertia, not because they've considered carefully the domain. I frequently see int used where the domain of the function is unsigned.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-30 22:23 +0200 |
| Message-ID | <oe5gu1$ljf$1@dont-email.me> |
| In reply to | #108776 |
On 30/04/2017 18:35, bartc wrote:
> On 30/04/2017 15:49, Noob wrote:
>> On 22/04/2017 18:16, bartc wrote:
>>
>>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>>> iterations are performed.
>>
>> Let's consider a slightly different situation.
>>
>> int foo(int n) {
>> return n * 2 / 2;
>> }
>>
>> Does anyone disagree that an optimizing compiler would
>> determine that this is the identity function, and would
>> drop the calls altogether, by replacing foo(x) with x.
>
> Only if it does the same when it's unsigned int.
Of course it doesn't, as you yourself point out below.
> I see the above operation as a left shift followed by a right shift.
> With unsigned, this has would have no effect when the top bit is 0 (as a
> zero will be shifted back in).
> With signed, I think it has no effect when the top two bits are the same.
The foo operation on an unsigned int clears the top bit.
int imul(int n) { return n * 2 / 2; }
int umul(unsigned int n) { return n * 2 / 2; }
imul:
movl %edi, %eax
ret
umul:
movl %edi, %eax
andl $2147483647, %eax
ret
imul is the identity function, umul clears the top bit.
>> Yet, if a non-optimizing compiler (e.g. gcc -O0) compiles the
>> code literally, and the user calls foo with x = 1_500_000_000,
>> then the actual result would be -647483648.
>
> If I do the same with unsigned x=3 billion, and using an unsigned
> version of foo, then the result will be 85251635, whether optimised or not.
My point was showing one type of optimization enabled when
ignoring UB. Dealing with (signed) overflow or (unsigned)
wrap-around is a slightly different issue.
You often mention widening multiply; this is a code
pattern which GCC recognizes on supported platforms:
long long int lmul(int u, int v) { return (long long)u * v; }
lmul:
movslq %edi, %rax
movslq %esi, %rsi
imulq %rsi, %rax
ret
And the same is possible for 64x64 -> 128 multiply.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-30 10:08 -0700 |
| Message-ID | <f20036e1-d8ac-4729-8509-2cab3ec4a62d@googlegroups.com> |
| In reply to | #108770 |
On Sunday, April 30, 2017 at 9:50:09 AM UTC-5, Noob wrote: > Does anyone disagree that an optimizing compiler would > determine that this is the identity function, and would > drop the calls altogether, by replacing foo(x) with x. That would depend upon what, if anything, the compiler documents about the behavior of integer overflow. If the compiler documents that overflow will truncate and sign-extend the result (possibly as a consequence of certain compiler flags), then such behavior would be defective. Likewise if it documents that it will trap on all overflows *without regard for whether they would affect the numerical correctness of the result*. If the compiler documents that integer overflows may, at the compiler's discretion, behave as though performed with arithmetically-correct values and then truncated to any arbitrary size which is at least as large as the types involved, but that it will have no other side-effect (IMHO such a mode would offer the best blend of optimization and safety for most purposes) or that overflows would trap any time they would result in a computation that would differ from using types that could hold arbitrarily-large numbers (the mode that would offer the best safety for most purposes while still allowing many useful optimizations), it could elide the function above since either documented behavior would allow the function to behave as though it used an integer type large enough to hold the result.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-30 22:32 +0200 |
| Message-ID | <oe5hfj$na7$1@dont-email.me> |
| In reply to | #108782 |
On 30/04/2017 19:08, supercat@casperkitty.com wrote: > On Sunday, April 30, 2017 at 9:50:09 AM UTC-5, Noob wrote: >> Does anyone disagree that an optimizing compiler would >> determine that this is the identity function, and would >> drop the calls altogether, by replacing foo(x) with x. > > That would depend upon what, if anything, the compiler documents about the > behavior of integer overflow. Are you confusing IDB and UB? Why would any compiler document the behavior of signed overflow? Are you thinking of some extension? Regards.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-30 13:59 -0700 |
| Message-ID | <lnbmrdk3x0.fsf@kst-u.example.com> |
| In reply to | #108803 |
Noob <root@127.0.0.1> writes:
> On 30/04/2017 19:08, supercat@casperkitty.com wrote:
>> On Sunday, April 30, 2017 at 9:50:09 AM UTC-5, Noob wrote:
>>> Does anyone disagree that an optimizing compiler would
>>> determine that this is the identity function, and would
>>> drop the calls altogether, by replacing foo(x) with x.
>>
>> That would depend upon what, if anything, the compiler documents about the
>> behavior of integer overflow.
>
> Are you confusing IDB and UB?
I obviously can't speak for supercat, but I doubt it.
> Why would any compiler document the behavior of signed overflow?
> Are you thinking of some extension?
A implementation is permitted to document the behavior of constructs
that have undefined behavior according to the C standard.
"gcc -fwrapv" is one implementation that does so for signed
integer overflow ("gcc -fwrapv" can be thought of as a distinct
implementation from gcc without "-fwrapv"). I wouldn't say it's
necessary to think of this as an "extension", since the behavior
is consistent with what the standard requires.
(Nothing in the standard requires an implementation to obey its own
documentation, except arguably for documentation that's required
by the standard, so if "gcc -fwrapv" didn't work as specified it
would be a bug in gcc, but not a conformance violation.)
--
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-30 17:47 -0700 |
| Message-ID | <23117b59-a54f-4879-9da0-b82821766d5b@googlegroups.com> |
| In reply to | #108803 |
On Sunday, April 30, 2017 at 3:32:59 PM UTC-5, Noob wrote: > Why would any compiler document the behavior of signed overflow? > Are you thinking of some extension? Because, among other things, it may sometimes be necessary to perform computations that may or may not be meaningful, before one knows whether they are meaningful or not. It may also sometimes be easier to perform a bunch of computations, some of which will be meaningful and some not, than to avoid performing the meaningless ones. In many cases, even very loose guarantees about overflow behavior--ones which could on many implementations be upheld at zero cost outside of rare or contrived situations--can avoid the need to have expensive code avoid overflows in computations whose results will end up being essentially ignored anyway. Why shouldn't a quality compiler offer up such guarantees?
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-04-30 21:49 -0700 |
| Message-ID | <cf99a8d3-539a-4051-b590-0493e9c66fc8@googlegroups.com> |
| In reply to | #108827 |
On Monday, May 1, 2017 at 9:48:13 AM UTC+9, supe...@casperkitty.com wrote:
> On Sunday, April 30, 2017 at 3:32:59 PM UTC-5, Noob wrote:
> > Why would any compiler document the behavior of signed overflow?
> > Are you thinking of some extension?
>
> Because, among other things, it may sometimes be necessary to perform
> computations that may or may not be meaningful, before one knows whether
> they are meaningful or not. It may also sometimes be easier to perform
> a bunch of computations, some of which will be meaningful and some not,
> than to avoid performing the meaningless ones.
>
> In many cases, even very loose guarantees about overflow behavior--ones
> which could on many implementations be upheld at zero cost outside of rare
> or contrived situations--can avoid the need to have expensive code avoid
> overflows in computations whose results will end up being essentially
> ignored anyway. Why shouldn't a quality compiler offer up such guarantees?
Because C still has the cachet of being an assembler for a virtual portable
run-time.
So to speak.
Which clarifies in my mind the arguments relative to optimization and
undefined behavior (and implementation-defined).
Optimization necessarily transforms a program and induces semantics beyond
what is written.
I'm sure there will be some argument about this, but we have to remember
that the closest thing to a bug-free program that can possibly be written
is a single no-op.
and
#include <stdlib.h>
int main( int argc, char **argv )
{ return EXIT_SUCCESS; }
isn't really quite a no-op in this sense, although it's about as close to
a bug-free program as you can write in C.
This kind of speaks to why I think there should be multiple languages under
the "C" umbrella (separate from C++), and standards for each.
Or, perhaps, the standard could be broken down into modules, and a compiler
could claim support for specific modules of the standard, and maybe even
provide #pragmas to turn specific modules on and off.
Or is this already being done and I am just unaware of it?
--
Joel Rees
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-30 11:24 -0700 |
| Message-ID | <lnshkpkb2o.fsf@kst-u.example.com> |
| In reply to | #108770 |
Noob <root@127.0.0.1> writes:
[...]
> Let's consider a slightly different situation.
>
> int foo(int n) {
> return n * 2 / 2;
> }
>
> Does anyone disagree that an optimizing compiler would
> determine that this is the identity function, and would
> drop the calls altogether, by replacing foo(x) with x.
I agree that an optimizing compiler (actually any compiler) *could*
do that, given that x is of type int. But there is no requirement
to do so.
[...]
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-30 12:45 -0700 |
| Message-ID | <kfnfugp1xyl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108770 |
Noob <root@127.0.0.1> writes:
> On 22/04/2017 18:16, bartc wrote:
>
>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>> iterations are performed.
>
> Let's consider a slightly different situation.
>
> int foo(int n) {
> return n * 2 / 2;
> }
>
> Does anyone disagree that an optimizing compiler would
> determine that this is the identity function, and would
> drop the calls altogether, by replacing foo(x) with x.
Certainly I wouldn't be surprised to see a compiler doing
that, for an argument of type int.
> Yet, if a non-optimizing compiler (e.g. gcc -O0) compiles the
> code literally, and the user calls foo with x = 1_500_000_000,
> then the actual result would be -647483648.
>
> I suppose the compiler could warn: "Assuming n * 2 never overflows",
> but one would get such a warning for *every* multiplication.
I think that's a straw man argument. If a compiler were going to
give some sort of warning along these lines, presumably the
warnings would be given /only/ when the assumption causes a code
transformation that would change the behavior relative to not
making the assumption. Most multiplications don't fall into that
category.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2017-04-23 23:11 -0700 |
| Message-ID | <odk4og$jtv$1@dont-email.me> |
| In reply to | #108330 |
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. But abstract theoretical considerations aside, optimization level would be one obvious down-to-Earth practical factor that always can (and will) "destabilize" manifestations of undefined behavior. After all, this is the very reason we have undefined behavior in language spec. So, no, when it comes to undefined behavior consistency across optimization levels is not even remotely desirable. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-24 10:46 +0100 |
| Message-ID | <4QjLA.892339$fZ.804703@fx41.am4> |
| In reply to | #108386 |
On 24/04/2017 07:11, Andrey Tarasevich wrote: > 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. But abstract theoretical > considerations aside, optimization level would be one obvious > down-to-Earth practical factor that always can (and will) "destabilize" > manifestations of undefined behavior. After all, this is the very reason > we have undefined behavior in language spec. > > So, no, when it comes to undefined behavior consistency across > optimization levels is not even remotely desirable. You write a program P and send it as C source code to someone else to work on a certain platform. You don't want to give instructions as to what compiler to use or what optimisations they should be applying. Maybe it's a module that is to be part of a bigger program, which uses its own uniform set of options. This is why it must not matter what optimisations are applied. Here, signed overflow /may/ be a bug in the program, or it may be by design. If P is designed to run on the vast range of hardware where signed overflows just wrap around, then it doesn't matter; the behaviour will be consistent, for same width of 'int' at least. Until C decides to intervene and decides it should matter, and changes the behaviour. (Take the 8-bit value 01111111 which is +127 when interpreted as signed. Now increment it, which doesn't have signed/unsigned variations on most hardware. You will get 10000000, which is -128 on two's complement hardware (pretty much every machine). It just wraps. Yet C has a problem with this. And ironically, if you start with the 8-bit value 11111111, which is -1 signed, and increment that, you get zero (not unexpectedly), Yet here, the hardware operation /will/ genuinely have overflowed - there will have been a carry bit generated intended for the ninth bit of the result.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-24 13:23 +0200 |
| Message-ID | <odkn2a$bj1$1@dont-email.me> |
| In reply to | #108397 |
On 24/04/17 11:46, bartc wrote: > On 24/04/2017 07:11, Andrey Tarasevich wrote: >> 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. But abstract theoretical >> considerations aside, optimization level would be one obvious >> down-to-Earth practical factor that always can (and will) "destabilize" >> manifestations of undefined behavior. After all, this is the very reason >> we have undefined behavior in language spec. >> >> So, no, when it comes to undefined behavior consistency across >> optimization levels is not even remotely desirable. > > > You write a program P and send it as C source code to someone else to > work on a certain platform. > > You don't want to give instructions as to what compiler to use or what > optimisations they should be applying. Maybe it's a module that is to be > part of a bigger program, which uses its own uniform set of options. > > This is why it must not matter what optimisations are applied. Agreed. (Well, I agree that it generally should not matter what optimisations are applied as far as the correctness of the code is concerned. And the ability to distribute the C source without detailed compilation requirements is one of many reasons for that.) > > Here, signed overflow /may/ be a bug in the program, or it may be by > design. If it is by design, then the designer is buggy :-) In C, signed overflow is /always/ a mistake. There are no circumstances in standard C programming in which it is not an error. You may have reason to program in an extended dialect of C in which you want signed overflow to have a specific behaviour - typically two's complement wraparound, but possibly saturating arithmetic or run-time traps or signals. That's also fine - but then you are not coding in standard C. You are coding in "gcc C with -fwrapv" or something similar. And you need to specify such details with your code, because you are /not/ distributing "C source code" any more. > If P is designed to run on the vast range of hardware where > signed overflows just wrap around, then it doesn't matter; the behaviour > will be consistent, for same width of 'int' at least. 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. Different languages have different ways of defining (or leaving undefined) the behaviour of impossible or meaningless actions. If we assume 16-bit int (because the numbers are easier), and have x = 32767, then what should be the result of adding 1 to x? Standard mathematics says it should be 32768, and anything else is wrong. Typical processors say it should be -32768, because that is the easiest in the hardware design. Some algorithms would much prefer 32767, because saturation is "less wrong" than anything else. Some algorithms would prefer a NaN type indicator, or jumping to some error routine. C says "Adding 1 to x here is meaningless. There is no behaviour which can be called 'correct'. So we don't give it a meaning. The compiler can assume it never happens, if that lets it generate more efficient code for correct cases". > > Until C decides to intervene and decides it should matter, and changes > the behaviour. > You have got that ass-backwards. C decides /not/ to intervene, decides it does /not/ matter, ans says there is no behaviour to change. > (Take the 8-bit value 01111111 which is +127 when interpreted as signed. > Now increment it, which doesn't have signed/unsigned variations on most > hardware. You will get 10000000, which is -128 on two's complement > hardware (pretty much every machine). It just wraps. > > Yet C has a problem with this. No, C has no problem with this - /you/, and a few other equally mistaken programmers, have problems with it. You appear to believe that C is not a programming language, but merely a kind of high level assembly - and you are wrong. C is not, and never has been, a high level assembler or semi-portable assembler. > > And ironically, if you start with the 8-bit value 11111111, which is -1 > signed, and increment that, you get zero (not unexpectedly), Yet here, > the hardware operation /will/ genuinely have overflowed - there will > have been a carry bit generated intended for the ninth bit of the result.) > The hardware details are irrelevant (which is good, because you are wrong to generalise - on some systems, the extra carry bit is never generated as there is no logic for it at all. And on many other processors, it is usually immediately ignored and not available to the programmer).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-24 15:38 +0100 |
| Message-ID | <Y5oLA.897308$fZ.149652@fx41.am4> |
| In reply to | #108398 |
On 24/04/2017 12:23, David Brown wrote: > On 24/04/17 11:46, bartc wrote: > Different languages have different ways of defining (or leaving > undefined) the behaviour of impossible or meaningless actions. If we > assume 16-bit int (because the numbers are easier), and have x = 32767, > then what should be the result of adding 1 to x? Standard mathematics > says it should be 32768, and anything else is wrong. Typical processors > say it should be -32768, because that is the easiest in the hardware > design. Some algorithms would much prefer 32767, because saturation is > "less wrong" than anything else. Some algorithms would prefer a NaN > type indicator, or jumping to some error routine. > > C says "Adding 1 to x here is meaningless. There is no behaviour which > can be called 'correct'. So we don't give it a meaning. The compiler > can assume it never happens, if that lets it generate more efficient > code for correct cases". You can apply the same argument to unsigned. With the same 16 bits, what's the result of adding 1 to 65535? Mathematics says it should be 65536. Typical processors will give 0, as that is simplest. Some algorithms prefer NaN, etc. It's exactly the same issue! The only difference might be that unsigned representation is more widespread than two's complement. Is that the reason why C says it's a no-no? 0.1% of machines don't use two's complement, therefore the other 99.9% aren't allowed to assume it. Furthermore, if they do, then some C compilers will endeavour to break your code. >> Yet C has a problem with this. > > No, C has no problem with this - /you/, and a few other equally mistaken > programmers, have problems with it. You appear to believe that C is not > a programming language, but merely a kind of high level assembly - and > you are wrong. C is not, and never has been, a high level assembler or > semi-portable assembler. That's a problem with C then. Someone writes a program in X where signed overflow has a behaviour consistent with two's complement. And they want to run it on machine Y which uses two's complement. So far, so good. But if they need to pass it through C, in order for X (which might just be pseudo-code in the programmer's mind) to be translated into a form that runs on Y, then the problems start. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-24 17:31 +0200 |
| Message-ID | <odl5hr$trj$1@dont-email.me> |
| In reply to | #108405 |
On 24/04/17 16:38, bartc wrote: > On 24/04/2017 12:23, David Brown wrote: >> On 24/04/17 11:46, bartc wrote: > >> Different languages have different ways of defining (or leaving >> undefined) the behaviour of impossible or meaningless actions. If we >> assume 16-bit int (because the numbers are easier), and have x = 32767, >> then what should be the result of adding 1 to x? Standard mathematics >> says it should be 32768, and anything else is wrong. Typical processors >> say it should be -32768, because that is the easiest in the hardware >> design. Some algorithms would much prefer 32767, because saturation is >> "less wrong" than anything else. Some algorithms would prefer a NaN >> type indicator, or jumping to some error routine. >> >> C says "Adding 1 to x here is meaningless. There is no behaviour which >> can be called 'correct'. So we don't give it a meaning. The compiler >> can assume it never happens, if that lets it generate more efficient >> code for correct cases". > > You can apply the same argument to unsigned. With the same 16 bits, > what's the result of adding 1 to 65535? Mathematics says it should be > 65536. Typical processors will give 0, as that is simplest. Some > algorithms prefer NaN, etc. > > It's exactly the same issue! You certainly could. The C language designers felt it was useful to define unsigned arithmetic as modulo arithmetic. It would be entirely reasonable for a language designer to say that signed integer overflow used two's complement wraparound. But the point is, that the /C/ designers did not do so - they specifically and explicitly made it undefined behaviour. It would be entirely reasonable for a language designer to make unsigned overflow undefined behaviour - again, the /C/ designers did not do so. They could also have made it implementation defined, but chose not to. (Though an implementation is always free to define the behaviour if it wants to.) When designing your own language, you can make the choices /you/ want here. Some languages use the same system as C. Others make different decisions. Given that /any/ behaviour on overflow (signed or unsigned) is going to be wrong in many circumstances, but some behaviours might be useful in some cases, a language designer has plenty of options here. He picks one, documents it, and makes that the behaviour for his language. For different languages, the "best" choice may well be different. So the C language designers decided on undefined behaviour for signed overflow, and wraparound behaviour for unsigned overflow. That gives programmers a useful set of features, it gives compilers opportunities for some good optimisations, and it can be easily implemented on a wide range of hardware (which in the early days of C included some machines that would have a lot of inconvenience with any of the possible choices). I am not trying to say that making signed integer overflow undefined behaviour is the "right" choice (though I agree with the C designers in this case). I am just trying to explain to you that that is how C works. If you want to program in C, or make C tools, then you need to understand the language as it really is - you can't just pretend it is something else or works in a different way, just because you might have preferred some differences. You can make these changes when you are inventing the Bart-C variation of C - but not when you are writing /real/ C. > > The only difference might be that unsigned representation is more > widespread than two's complement. Is that the reason why C says it's a > no-no? That may well have been a major consideration of the original C language designers. > > 0.1% of machines don't use two's complement, therefore the other 99.9% > aren't allowed to assume it. Furthermore, if they do, then some C > compilers will endeavour to break your code. You misunderstand. The compiler will not "break" your code if you assume that signed integers use two's complement wrap-around. Your code is /already/ broken. It is incorrect C code - it is a sequence of letters and symbols without a valid definition in C. The compiler does not "break" it by assuming your signed integers don't overflow - your signed integers are not allowed to overflow in C. The compiler does not produce "correct" or "working" code when the relevant optimisations are disabled - your C code has /no/ defined behaviour, and therefore /no/ generated code can be said to be "correct". It is a case of "garbage in, garbage out" - depending on compiler options, you may get different varieties of garbage out. As the father of computing, Charles Babbage, puts it: On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. > >>> Yet C has a problem with this. >> >> No, C has no problem with this - /you/, and a few other equally mistaken >> programmers, have problems with it. You appear to believe that C is not >> a programming language, but merely a kind of high level assembly - and >> you are wrong. C is not, and never has been, a high level assembler or >> semi-portable assembler. > > That's a problem with C then. No, it is a problem with /you/. You don't understand what C is - that is /your/ problem. You are not alone in having such problems with C - not everyone is able to grasp how C works. But most people either learn C properly in the end, or give up and either use a different programming language, or stop programming. I cannot comprehend why you have such a stubborn resistance to making this choice. > > Someone writes a program in X where signed overflow has a behaviour > consistent with two's complement. And they want to run it on machine Y > which uses two's complement. So far, so good. That is fine, as long as "X" is not the C programming language (or any other language that does not guarantee such overflow behaviour). > > But if they need to pass it through C, in order for X (which might just > be pseudo-code in the programmer's mind) to be translated into a form > that runs on Y, then the problems start. > It is not a problem in the slightest. If you are writing a translator from language X in which signed overflow is defined, into C in which it is not defined, then you have three choices: 1. Make it a requirement that the resulting C is treated as "C with defined signed integer overflow" - insist on compilation with "-fwrapv" flag in gcc and clang, and disallow compilers that do not have /documented guarantees/ of this type of behaviour. 2. Make it a requirement that the resulting C is compiled on machines with two's complement signed integers, and use unions or casts to convert between signed integers and unsigned integers as necessary to get the required behaviour. This will result in ugly C intermediary code, but that should be of no relevance. It is likely that the code will compile optimally on most compilers. 3. Generate the code in a manner that avoids signed integer overflow. This might be a little fiddly, and certainly a bit messy in the generated code - but it is intermediary code, and it is /allowed/ to be messy. What you don't get to do, is moan that C doesn't work the way you think it ought to work, and claim it is C's problem. /You/ are defining language X. /You/ are making the X-to-C compiler. It is /your/ problem.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-24 17:15 +0100 |
| Message-ID | <87pog1zsry.fsf@bsb.me.uk> |
| In reply to | #108406 |
David Brown <david.brown@hesbynett.no> writes: > On 24/04/17 16:38, bartc wrote: >> On 24/04/2017 12:23, David Brown wrote: >>> On 24/04/17 11:46, bartc wrote: >> >>> Different languages have different ways of defining (or leaving >>> undefined) the behaviour of impossible or meaningless actions. If we >>> assume 16-bit int (because the numbers are easier), and have x = 32767, >>> then what should be the result of adding 1 to x? Standard mathematics >>> says it should be 32768, and anything else is wrong. Typical processors >>> say it should be -32768, because that is the easiest in the hardware >>> design. Some algorithms would much prefer 32767, because saturation is >>> "less wrong" than anything else. Some algorithms would prefer a NaN >>> type indicator, or jumping to some error routine. >>> >>> C says "Adding 1 to x here is meaningless. There is no behaviour which >>> can be called 'correct'. So we don't give it a meaning. The compiler >>> can assume it never happens, if that lets it generate more efficient >>> code for correct cases". >> >> You can apply the same argument to unsigned. Not in C. Unsigned arithmetic is defined. I think you meant you *could* make the same argument about unsigned arithmetic by making it, too, undefined on overflow. As things stand in C, you can't make the same argument because the premise fails: there is behaviour that can be called correct. <snip> > It would be entirely reasonable for a language designer to say that > signed integer overflow used two's complement wraparound. But the point > is, that the /C/ designers did not do so - they specifically and > explicitly made it undefined behaviour. It would be entirely reasonable > for a language designer to make unsigned overflow undefined behaviour - > again, the /C/ designers did not do so. They could also have made it > implementation defined, but chose not to. I think it was the committee that made it undefined (who, I suppose, count as language designers too) but if we take K&R1 as the view of the language designers, they chose to make it a slight variation on "implementation defined": "The action taken on overflow or underflow depends on the machine at hand." (K&R 1st ed. page 38) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-24 10:36 -0700 |
| Message-ID | <77cc9c5c-e09a-4551-ba78-6ba10ce4dcaf@googlegroups.com> |
| In reply to | #108411 |
On Monday, April 24, 2017 at 11:15:21 AM UTC-5, Ben Bacarisse wrote: > I think it was the committee that made it undefined (who, I suppose, > count as language designers too) but if we take K&R1 as the view of the > language designers, they chose to make it a slight variation on > "implementation defined": > > "The action taken on overflow or underflow depends on the machine at > hand." (K&R 1st ed. page 38) Note that Undefined Behavior explicitly lists as one of the possible outcomes "behaving during translation or program execution in a documented manner characteristic of the environment". The Standard does not specify in what cases quality implementations *should* behave in a such a fashion, but it would seem curious that the authors would have mentioned it if they did not expect that many implementations would behave in such fashion. The grammatical construction does not indicate whether the sentence should be interpreted as: - behaving in a fashion which an environment documents as a characteristic. - behaving in a fashion which is documented by the implementation and happens to be characteristic of the environment (which may or may not document it). Given the ambiguity, I would suggest that in cases where an environment documents a characteristic behavior, any quality implementation whose behavior would differ should document such difference.
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web