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 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-22 21:31 +0000 |
| Message-ID | <58fbcb6e.48519421@news.xs4all.nl> |
| In reply to | #108328 |
Andrew Cooper <amc96@cam.ac.uk> wrote: > Overflow of signed integers is UB. Therefore "i < i + 1" can > legitimately be simplified to true. > > Use -fwrapv if you want GCC/Clang to strictly consider signed integer > overflow to have defined twos-compliment behaviour. Or, by preference, don't, and rather write code which doesn't rely on undefined behaviour in the first place. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-22 09:29 +0000 |
| Message-ID | <58fb2265.5246218@news.xs4all.nl> |
| In reply to | #108327 |
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.
Richard
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-22 10:47 +0100 |
| Message-ID | <EEFKA.484957$fL.133530@fx24.am4> |
| 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.
Nevertheless, it desirable to have consistent behaviour across
optimisation levels.
I changed the code a little to this:
int main(void) {
int i,m;
m=0x7fffffff;
for (i = 0; i < m + 1; i++)
;
return 0;
}
Now, with -O0, it terminates immediately. With -O3, it runs forever.
Those two behaviours couldn't be more contrasting!
It gets worse; change it to:
int main(void) {
int i,m;
m=fn();
for (i = 0; i < m + 1; i++)
;
return 0;
}
where fn() is defined in a separate module so the compiler of this
module can't see it. Now, both -O0 and -O3 compilations terminate
immediately.
The behaviour of the -O3-compiled code has changed dramatically just by
a minor rearrangement of the code, the sort that happens all the time in
a real program.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2017-04-22 11:36 +0100 |
| Message-ID | <odfbi9$b0c$1@dont-email.me> |
| In reply to | #108330 |
On 22/04/2017 10:47, bartc wrote:
> 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.
>
> Nevertheless, it desirable to have consistent behaviour across
> optimisation levels.
>
> I changed the code a little to this:
>
> int main(void) {
> int i,m;
> m=0x7fffffff;
> for (i = 0; i < m + 1; i++)
> ;
> return 0;
> }
>
> Now, with -O0, it terminates immediately. With -O3, it runs forever.
> Those two behaviours couldn't be more contrasting!
>
> It gets worse; change it to:
>
> int main(void) {
> int i,m;
> m=fn();
> for (i = 0; i < m + 1; i++)
> ;
> return 0;
> }
>
> where fn() is defined in a separate module so the compiler of this
> module can't see it. Now, both -O0 and -O3 compilations terminate
> immediately.
>
> The behaviour of the -O3-compiled code has changed dramatically just by
> a minor rearrangement of the code, the sort that happens all the time in
> a real program.
That's my gripe, too. I accept that C specifies cases of UB, understand
why it does so, and welcome the fact that such things are programmer
responsibility. What I find surprising, though, is that the compiler
generates code which behaves differently _without warning_ by default.
IMO disable-able warnings would be better.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-04-22 13:50 +0000 |
| Message-ID | <odfn3h$ap2$2@news.xmission.com> |
| In reply to | #108333 |
In article <odfbi9$b0c$1@dont-email.me>, James Harris <james.harris.1@gmail.com> wrote: ... >That's my gripe, too. I accept that C specifies cases of UB, understand >why it does so, and welcome the fact that such things are programmer >responsibility. What I find surprising, though, is that the compiler >generates code which behaves differently _without warning_ by default. The point here is that it is a "Doctor, it hurts when I do this" sort of thing. By specifying optimization (via -O<anything>), you are telling the compiler to assume that your code is all correct and to optimize accordingly. If you didn't want that, you'd not put in -Ox. Now, here's the thing - and I accept that this is controversial and against the grain of this newsgroup - but the way it *should* work is that when don't specify any optimization (i.e., -O0), the code should be compiled "as is" - i.e., what you see is what you get. Then, if you specify that optimization be done, then you have to accept that the compiler may "distort" your code - as they say, you asked for it, you got it. Unfortunately, the C standards (the Bible of this NG) make no such guarantees. The compiler is free to do whatever it likes with your code, even when compiled with -O0. That's the flaw. P.S. Again, I'm fully aware that the above is controversial and I fully expect a slew of responses telling me I'm wrong. Unless you really like hearing the sound of your own voice, don't bother. -- Trump has normalized hate. The media has normalized Trump.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-22 15:35 +0100 |
| Message-ID | <iTJKA.1142214$Pm3.870876@fx42.am4> |
| In reply to | #108338 |
On 22/04/2017 14:50, Kenny McCormack wrote: > In article <odfbi9$b0c$1@dont-email.me>, > James Harris <james.harris.1@gmail.com> wrote: > ... >> That's my gripe, too. I accept that C specifies cases of UB, understand >> why it does so, and welcome the fact that such things are programmer >> responsibility. What I find surprising, though, is that the compiler >> generates code which behaves differently _without warning_ by default. > > The point here is that it is a "Doctor, it hurts when I do this" sort of > thing. By specifying optimization (via -O<anything>), you are telling the > compiler to assume that your code is all correct and to optimize > accordingly. If you didn't want that, you'd not put in -Ox. > > Now, here's the thing - and I accept that this is controversial and against > the grain of this newsgroup - but the way it *should* work is that when > don't specify any optimization (i.e., -O0), the code should be compiled "as > is" - i.e., what you see is what you get. Then, if you specify that > optimization be done, then you have to accept that the compiler may > "distort" your code - as they say, you asked for it, you got it. I expect it to do the exactly same thing, only faster (assuming this is optimising for speed). I also expect, with gcc, for it not to do something at all, but this is mainly a nuisance when trying to compare performance with another compiler, option, language or algorithm. > Unfortunately, the C standards (the Bible of this NG) make no such > guarantees. The compiler is free to do whatever it likes with your code, > even when compiled with -O0. That's the flaw. C has decided that overflow of signed types is undefined behaviour. In reality, in most sane systems, it is quite predictable: unsigned types just wrap around. The same underlying machine operations are often used for both signed and unsigned. Presumably some rare machines are different, hence the UB, even on machines where overflow behaviour is predictable. But it means the compiler doing unexpected things. If I write: int a,b,c; // file scope non-static .... a < b+c; where b and c may have been set up elsewhere, the compiler can't do much. If b+c does overflow, and the code would have a certain behaviour (which may be desired, maybe not). But as soon as the compiler gets some extra information about the values of b and c, then it will pounce on that, and generate different code when optimising. And with different behaviour, not just faster. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2017-04-24 09:36 +0100 |
| Message-ID | <odkd91$bsj$2@dont-email.me> |
| In reply to | #108340 |
On 22/04/2017 15:35, bartc wrote: > On 22/04/2017 14:50, Kenny McCormack wrote: >> In article <odfbi9$b0c$1@dont-email.me>, >> James Harris <james.harris.1@gmail.com> wrote: >> ... >>> That's my gripe, too. I accept that C specifies cases of UB, understand >>> why it does so, and welcome the fact that such things are programmer >>> responsibility. What I find surprising, though, is that the compiler >>> generates code which behaves differently _without warning_ by default. >> >> The point here is that it is a "Doctor, it hurts when I do this" sort of >> thing. By specifying optimization (via -O<anything>), you are telling >> the >> compiler to assume that your code is all correct and to optimize >> accordingly. If you didn't want that, you'd not put in -Ox. >> >> Now, here's the thing - and I accept that this is controversial and >> against >> the grain of this newsgroup - but the way it *should* work is that when >> don't specify any optimization (i.e., -O0), the code should be >> compiled "as >> is" - i.e., what you see is what you get. Then, if you specify that >> optimization be done, then you have to accept that the compiler may >> "distort" your code - as they say, you asked for it, you got it. > > I expect it to do the exactly same thing, only faster (assuming this is > optimising for speed). My view is similar to yours but not identical. I accept that a compiler can achieve greater speed by making certain assumptions. What I would want, though, is the compiler at least to say that it was doing something which /could/ alter the behaviour. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-24 08:37 -0700 |
| Message-ID | <ln37cxq0ka.fsf@kst-u.example.com> |
| In reply to | #108392 |
James Harris <james.harris.1@gmail.com> writes:
[...]
> My view is similar to yours but not identical. I accept that a compiler
> can achieve greater speed by making certain assumptions. What I would
> want, though, is the compiler at least to say that it was doing
> something which /could/ alter the behaviour.
The problem is that, as I understand it, it's impractical to do that.
I read an article a while ago from the authors of clang and/or llvm
discussing the issue. I'll post a link when/if I find it again.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-25 11:07 +0200 |
| Message-ID | <odn3ek$g0r$1@dont-email.me> |
| In reply to | #108408 |
On 24/04/17 17:37, Keith Thompson wrote: > James Harris <james.harris.1@gmail.com> writes: > [...] >> My view is similar to yours but not identical. I accept that a compiler >> can achieve greater speed by making certain assumptions. What I would >> want, though, is the compiler at least to say that it was doing >> something which /could/ alter the behaviour. > > The problem is that, as I understand it, it's impractical to do that. > > I read an article a while ago from the authors of clang and/or llvm > discussing the issue. I'll post a link when/if I find it again. > Are you referring to these? If I'm right, it will save you a little research effort - and if I'm wrong, these are useful articles anyway. <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-25 11:57 -0700 |
| Message-ID | <lnd1c0nwmw.fsf@kst-u.example.com> |
| In reply to | #108456 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/04/17 17:37, Keith Thompson wrote:
>> James Harris <james.harris.1@gmail.com> writes:
>> [...]
>>> My view is similar to yours but not identical. I accept that a compiler
>>> can achieve greater speed by making certain assumptions. What I would
>>> want, though, is the compiler at least to say that it was doing
>>> something which /could/ alter the behaviour.
>>
>> The problem is that, as I understand it, it's impractical to do that.
>>
>> I read an article a while ago from the authors of clang and/or llvm
>> discussing the issue. I'll post a link when/if I find it again.
>>
>
> Are you referring to these? If I'm right, it will save you a little
> research effort - and if I'm wrong, these are useful articles anyway.
>
>
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html>
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html>
Yes, I think that's it. The third one includes a section "Why can't you
warn when optimizing based on undefined behavior?". Thanks!
--
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 | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2017-04-24 09:34 +0100 |
| Message-ID | <odkd4e$bsj$1@dont-email.me> |
| In reply to | #108338 |
On 22/04/2017 14:50, Kenny McCormack wrote: > In article <odfbi9$b0c$1@dont-email.me>, > James Harris <james.harris.1@gmail.com> wrote: > ... >> That's my gripe, too. I accept that C specifies cases of UB, understand >> why it does so, and welcome the fact that such things are programmer >> responsibility. What I find surprising, though, is that the compiler >> generates code which behaves differently _without warning_ by default. > > The point here is that it is a "Doctor, it hurts when I do this" sort of > thing. By specifying optimization (via -O<anything>), you are telling the > compiler to assume that your code is all correct and to optimize > accordingly. If you didn't want that, you'd not put in -Ox. I see your point: optimisations often involve assumptions. Optimisation can, of course, just make compilation take longer, though. Perhaps the best option would be a single switch to turn on warnings about any assumptions an optimiser was making which were different from those the unoptimised code would make, and to be able to turn such warnings off individually. Then optimised code could be guaranteed to use the same assumptions as unoptimised code unless the programmer got a warning about it. Of course, a simple warning about undefined behaviour could also be useful - and might be better! > > Now, here's the thing - and I accept that this is controversial and against > the grain of this newsgroup - but the way it *should* work is that when > don't specify any optimization (i.e., -O0), the code should be compiled "as > is" - i.e., what you see is what you get. Then, if you specify that > optimization be done, then you have to accept that the compiler may > "distort" your code - as they say, you asked for it, you got it. > > Unfortunately, the C standards (the Bible of this NG) make no such > guarantees. The compiler is free to do whatever it likes with your code, > even when compiled with -O0. That's the flaw. > > P.S. Again, I'm fully aware that the above is controversial and I fully > expect a slew of responses telling me I'm wrong. Unless you really like > hearing the sound of your own voice, don't bother. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-24 11:25 +0200 |
| Message-ID | <odkg4u$lf0$1@dont-email.me> |
| In reply to | #108391 |
On 24/04/17 10:34, James Harris wrote: > On 22/04/2017 14:50, Kenny McCormack wrote: >> In article <odfbi9$b0c$1@dont-email.me>, >> James Harris <james.harris.1@gmail.com> wrote: >> ... >>> That's my gripe, too. I accept that C specifies cases of UB, understand >>> why it does so, and welcome the fact that such things are programmer >>> responsibility. What I find surprising, though, is that the compiler >>> generates code which behaves differently _without warning_ by default. >> >> The point here is that it is a "Doctor, it hurts when I do this" sort of >> thing. By specifying optimization (via -O<anything>), you are telling >> the >> compiler to assume that your code is all correct and to optimize >> accordingly. If you didn't want that, you'd not put in -Ox. > > I see your point: optimisations often involve assumptions. Optimisation > can, of course, just make compilation take longer, though. > > Perhaps the best option would be a single switch to turn on warnings > about any assumptions an optimiser was making which were different from > those the unoptimised code would make, and to be able to turn such > warnings off individually. Then optimised code could be guaranteed to > use the same assumptions as unoptimised code unless the programmer got a > warning about it. You have a fundamental misunderstanding about C here. Yes, compiler optimisations can often be based on assumptions - such as the assumption that signed integer overflow will not occur (or that you don't care what happens if it /does/ occur). But no, these assumptions are /not/ different or "invalid" when optimisation is not enabled. It is /never/ valid in ordinary C to let signed integers overflow. The compiler can /always/ assume that such overflow does not occur, and there is no way to talk about the "expected behaviour" of the program when it has signed overflow - optimised or not. A compiler implements C. It does not have to try to guess what it thinks the programmer might have meant to write - it takes what the programmer /did/ write, and generates code on the assumption that the programmer understands the language, and wrote what he meant to write. When you give a compiler a program containing undefined behaviour, such as signed integer overflow, the compiler can generate any code it wants. Practical realities of compiler design will usually limit the generated code to a few different options - such as giving a specific output, or hanging in an infinite loop. But the compiler is also free to write code that prints "Hello, world!" just because you ran the compiler on a Sunday. Having said that, it is of course always a useful thing when the compiler can warn you about possible or definite mistakes in your code. But remember that while it may be easy for a programmer to spot a mistake in one sample of code, it is not necessarily easy to give clear rules about finding such mistakes - and compiler writers need clear rules to implement warning checks. No one wants a check that produces lots of false positives on perfectly good code. > > Of course, a simple warning about undefined behaviour could also be > useful - and might be better! >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-27 13:57 -0700 |
| Message-ID | <kfna87136wi.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108338 |
gazelle@shell.xmission.com (Kenny McCormack) writes: > In article <odfbi9$b0c$1@dont-email.me>, > James Harris <james.harris.1@gmail.com> wrote: > ... >> That's my gripe, too. I accept that C specifies cases of UB, understand >> why it does so, and welcome the fact that such things are programmer >> responsibility. What I find surprising, though, is that the compiler >> generates code which behaves differently _without warning_ by default. > > The point here is that it is a "Doctor, it hurts when I do this" sort of > thing. By specifying optimization (via -O<anything>), you are telling the > compiler to assume that your code is all correct and to optimize > accordingly. If you didn't want that, you'd not put in -Ox. > > Now, here's the thing - and I accept that this is controversial and against > the grain of this newsgroup - but the way it *should* work is that when > don't specify any optimization (i.e., -O0), the code should be compiled "as > is" - i.e., what you see is what you get. Then, if you specify that > optimization be done, then you have to accept that the compiler may > "distort" your code - as they say, you asked for it, you got it. > > Unfortunately, the C standards (the Bible of this NG) make no such > guarantees. The compiler is free to do whatever it likes with your code, > even when compiled with -O0. That's the flaw. The problem with this idea is not that it's wrong but that it's unworkable. There just isn't a way to write such a specification and have it satisfy all the other constraints that the ISO C standard needs to satisfy. > P.S. Again, I'm fully aware that the above is controversial and I fully > expect a slew of responses telling me I'm wrong. Unless you really like > hearing the sound of your own voice, don't bother. Generally I try to write my newsgroup postings for the benefit of all potentially interested readers, not just the person I'm responding to.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-27 13:38 -0700 |
| Message-ID | <kfnefwd37sy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #108333 |
James Harris <james.harris.1@gmail.com> writes: >> [the presence of undefined behavior causes different results >> when programs are compiled using different optimization levels] > > That's my gripe, too. I accept that C specifies cases of UB, > understand why it does so, and welcome the fact that such things are > programmer responsibility. What I find surprising, though, is that the > compiler generates code which behaves differently _without warning_ by > default. I understand the gripe, and to some extent agree with it. It's important to keep in mind though that the gripe is with the implementation, not with the C language.
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2017-04-28 22:38 +0100 |
| Message-ID | <oe0ci2$b2v$2@dont-email.me> |
| In reply to | #108623 |
On 27/04/2017 21:38, Tim Rentsch wrote: > James Harris <james.harris.1@gmail.com> writes: > >>> [the presence of undefined behavior causes different results >>> when programs are compiled using different optimization levels] >> >> That's my gripe, too. I accept that C specifies cases of UB, >> understand why it does so, and welcome the fact that such things are >> programmer responsibility. What I find surprising, though, is that the >> compiler generates code which behaves differently _without warning_ by >> default. > > I understand the gripe, and to some extent agree with it. > It's important to keep in mind though that the gripe is > with the implementation, not with the C language. Yes, the 'gripe' was about gcc, not C. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-22 08:35 -0700 |
| Message-ID | <lnzif8pi97.fsf@kst-u.example.com> |
| In reply to | #108330 |
bartc <bc@freeuk.com> writes:
[...]
> I changed the code a little to this:
>
> int main(void) {
> int i,m;
> m=0x7fffffff;
> for (i = 0; i < m + 1; i++)
> ;
> return 0;
> }
[...]
Assuming 32-bit int, 0x7fffffff is equal to INT_MAX.
What behavior did you expect when evaluating INT_MAX + 1?
(Any possible expectation is incorrect.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-22 17:16 +0100 |
| Message-ID | <QlLKA.442109$Iy2.238516@fx28.am4> |
| In reply to | #108341 |
On 22/04/2017 16:35, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> I changed the code a little to this:
>>
>> int main(void) {
>> int i,m;
>> m=0x7fffffff;
>> for (i = 0; i < m + 1; i++)
>> ;
>> return 0;
>> }
> [...]
>
> Assuming 32-bit int, 0x7fffffff is equal to INT_MAX.
> What behavior did you expect when evaluating INT_MAX + 1?
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.
This is the behaviour observed with Pelles C, lccwin, DMC and Tiny C,
both optimised and unoptimised, when there is that option. (And with my
compiler...)
It's also the behaviour with gcc -O0 and -O1.
It's the behaviour of gcc with any optimisation setting, when the
assignment to m with 0x7fffffff is hidden from it.
Only with gcc, only with -O2 or -O3, and only when it can /see/ that m
has the value 0x7fffffff, does it play its UB card and generate code
that loops forever.
If something had exactly this code in assembly:
mov [i], 0
mov [m], 0x7FFF_FFFF
load R1, [i]
load R2, [m]
add R2, 1
cmp R1, R2
jmp ge,.... # signed compare
and decided to port it C, then it would not work the same way if they
used gcc -O2 or gcc -O3.
> (Any possible expectation is incorrect.)
Only because the language has said it is incorrect for EVERY possible
implementation, even the ones where it is well-defined. And gcc takes
advantage of that.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-22 18:55 +0100 |
| Message-ID | <qOMKA.433387$QG3.60897@fx17.am4> |
| In reply to | #108342 |
On 22/04/2017 17:16, bartc wrote: > On 22/04/2017 16:35, Keith Thompson wrote: >> What behavior did you expect when evaluating INT_MAX + 1? > > 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. > > This is the behaviour observed with Pelles C, lccwin, DMC and Tiny C, > both optimised and unoptimised, when there is that option. (And with my > compiler...) > > It's also the behaviour with gcc -O0 and -O1. > > It's the behaviour of gcc with any optimisation setting, when the > assignment to m with 0x7fffffff is hidden from it. > > Only with gcc, only with -O2 or -O3, and only when it can /see/ that m > has the value 0x7fffffff, does it play its UB card and generate code > that loops forever. Above was tested with x64 and partly on x86 (32-bit). I've tested now on ARM32 and the same thing: -O3 creates an infinite loop when the initialisation of 'm' is not visible. Be interesting if anyone had examples where the pattern of behaviour was different. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-22 21:04 +0200 |
| Message-ID | <odg9a9$dmj$1@dont-email.me> |
| In reply to | #108342 |
On 22/04/2017 18:16, bartc wrote: > On 22/04/2017 16:35, Keith Thompson wrote: > >> What behavior did you expect when evaluating INT_MAX + 1? > > I expect 0x7fffffff+1 to be equal to 0x80000000. Then use the appropriate flag [diatribe redacted]. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fwrapv
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-22 21:51 +0100 |
| Message-ID | <87tw5gjhd1.fsf@bsb.me.uk> |
| In reply to | #108342 |
bartc <bc@freeuk.com> writes:
> On 22/04/2017 16:35, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> I changed the code a little to this:
>>>
>>> int main(void) {
>>> int i,m;
>>> m=0x7fffffff;
>>> for (i = 0; i < m + 1; i++)
>>> ;
>>> return 0;
>>> }
>> [...]
>>
>> Assuming 32-bit int, 0x7fffffff is equal to INT_MAX.
>
>> What behavior did you expect when evaluating INT_MAX + 1?
>
> 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.
This is not a clear explanation of what you expect because you are using
a C-like notation (0x80000000 etc) with (I think) a non-C meaning. On a
32-bit system, 0x7fffffff is a constant of type int with the value
2147483647. The expression 0x7fffffff+1 is of type int but has a value
(2147483648) that can't be represented in an int. The constant
0x80000000 does not have the same type -- it's an unsigned int -- but
it's value (2147483648) is what many people would expect 2147483647+1 to
be. Furthermore, no one who knows C should expect 0<0x80000000 to be
false.
Know I know what you mean, but that's because of having discussed things
with you before. If you want to discuss your non-C expectations, it
would be much clearer to use a notation that did no carry a meaning you
don't want. For example, I might show fixed-width bit patterns in hex
like this: |7F FF FF FF| + 1 => |80 00 00 00|. Now its clear that I
don't mean what C means by 0x80000000.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web