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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 14:38 -0700 |
| Message-ID | <ace20aa5-96b1-4550-8014-bc21b7aa5748@googlegroups.com> |
| In reply to | #109545 |
On Monday, May 8, 2017 at 3:46:56 PM UTC-5, David Brown wrote:
> On 08/05/17 22:07, supercat wrote:
> > So how would you write code that needs to efficiently read and write data
> > of arbitrary type on a 32-bit CPU?
>
> I don't read and write data of arbitrary types - I /know/ what types I use.
When writing a functions which are to be used in a manner similar to fread
and fwrite, do you find it cleaner to code separate versions for every type
you'll be using, or write one type-agnostic function which can handle them
all?
> > Would you use memcpy to copy the data
> > to a non-qualified uint32_t[] [hopefully using 32-bit operations] so that
> > you could then copy it from there to a uint32_t volatile[], or would you
> > use a loop to memcpy groups of four bytes to a uint32_t that could be written
> > to a uint32_t volatile[], or what?
>
> There is no answer to a question like that (except perhaps "what"),
> since it will depend on the circumstances. Maybe I will use transfers
> that I know are valid on the compiler in question even if they are not
> guaranteed by the standards. Maybe I will use memcpy. Maybe I will use
> unions. Maybe memcpy, but with extensions (like gcc attributes) to
> ensure the compiler knows the alignments of the pointers involved, and
> can generate more efficient transfers.
Use of memcpy or memmove with a volatile-qualified source or destination
invokes UB.
> In most cases, I won't /care/ - because the reason I am passing such
> data around is because it will be transferred by a UART running at 19200
> baud, and it does not matter if the buffer is available a microsecond
> earlier or later. What matters is that the code is clear and correct.
If a buffer is declared as "volatile", the Standard requires that all
operations done to the buffer via pointers be done with volatile-qualified
pointers. That will in turn require that all non-standard-library functions
that are used to do access with the buffer will need to either use
volatile-qualified pointers (needlessly degrading efficiency when used with
things other than the buffer, in addition to needlessly degrading efficiency
when used with the buffer if no other processes will be accessing it at the
same time as the function) or be written twice--once for use with volatile-
qualified pointers and once for use without. Further, any system library
functions that might be used to assemble the buffer (including memcpy and
sprintf) would have to write their data somewhere else before it is manually
copied to the volatile buffer.
> What part of the word "example" is causing you problems here? And on
> the one hand you are obsessing about irrelevant run-time efficiency,
> while simultaneously extolling the benefits of compilers that will be
> extremely slow and inefficient.
Some real-world compilers like tcc do work that way. As for being slow and
inefficient, how often would forbidding access reordering across volatile
operations have any meaningful impact on the performance *of code that would
work correctly in the presence of such reordering*?
> Your original point was about "multi-core or out-of-order execution CPUs
> with weak memory models" - you /do/ need memory barrier directives
> (which until C11 were outside the scope of C) regardless of the compiler.
My intention was to describe the situation *outside* of such devices.
> > The "volatile" keyword was added to make it possible
> > for compilers to perform optimizations without making the language unsuitable
> > for systems-programming use. If it *wasn't* intended to eliminate the need
> > for compiler-specific directives on the kinds of platforms that existed in
> > the late 1980s (which, incidentally, are very much like low-end platforms
> > today) why bother with it at all?
>
> Again, you equate "I can't think why this is not the case" with "clearly
> it /is/ the case". I wish you would stop doing that - you cannot use
> your ignorance or lack of imagination as "proof" that your ideas are
> correct.
The Standard makes explicit provision for some implementations to offer
stronger "volatile" semantics than others. You seem to be arguing that
no implementations exist that offer any semantics beyond the absolute
minimum required.
> > I would suggest that a compiler which can't perform some task as cleanly
> > and straightforwardly as a 5.1.2.3p9 compiler shouldn't be regarded as
> > particularly suitable for that task.
>
> Perhaps it is not suitable as a compiler for /you/. Let other people
> use tools that work for /them/. In the meantime, I recommend you keep
> your gcc settings on "-fno-strict-alias -fwrapv" and avoid optimisation
> (certainly nothing above -O1), just in case the scary compiler does
> something different from a tool from 40 years ago.
I would suggest that if compiler X makes it possible to perform some task T
more simply and straightforwardly than compiler Y, that would constitute
prima facie evidence that compiler X is more suitable for that task than
compiler Y. I would further suggest that an ability to use code written for
other compilers is a feature that quality compilers should seek to provide
when practical.
> > Is there any reason that code which needs to do something that any compiler
> > which is remotely suitable for systems programming must be capable of doing
> > (flushing all register-cached variables and creating a barrier to load/store
> > re-ordering) in order to handle external function calls, should need to use
> > compiler-specific directives for that purpose?
>
> Yes. (The reasons are too obvious to bother explaining.)
If a compiler given:
void dummy_func(void* p) {};
void (*volatile dummyfunc)(void*) = dummy_func;
...
dummyfunc(pointerToDataThatWillBeAltered);
...code that triggers process that externally stores data to RAM
...code that waits for that process to complete
dummyfunc(0);
...code that uses that data
would have no practical choice but to generate machine code that would
cause code following dummyfunc() to see the effects of the external store,
is there any reason it should not be possible to achieve the same semantics
without forcing the compiler to generate a useless load and indirect
function call?
Such a function call wouldn't offer sufficient semantic barriers on all
hardware platforms, but in cases where they would be adequate why should it
be necessary to use compiler-specific directives to achieve the same effect
without the needless operations?
Note that if between the two calls to dummyfunc() an object whose address
has ever been passed to dummyfunc() is accessed only through external means,
any operation performed upon that object by an external process between
those calls would be indistinguishable from an operation performed on that
object by one of those calls, so a generated code that would be capable of
handling the latter would need to also handle the former.
> >>> Do you consider it plausible that the authors of the Standard intended that
> >>> implementations interpret the Standard so as to require the use of more
> >>> compiler-specific directives than would have been necessary previously?
> >>
> >> Yes.
> >
> > Interesting. I would have thought such an outcome would have been contrary
> > to the whole purpose of trying to write a standard in the first place.
>
> You asked if I considered it plausible. I said yes. You are very fond
> of sophistry, but it is not really a helpful technique in such a discussion.
Let me rephrase the question: if the authors of the Standard were being
truthful about their claimed motives, would that be consistent with an
intention that the Standard be interpreted so as to require the use of
compiler-specific directives in what had previously been compiler-agnostic
code?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-08 21:16 +0000 |
| Message-ID | <Me5QA.53428$rl4.12016@fx35.iad> |
| In reply to | #109536 |
supercat@casperkitty.com writes: >On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: >Before the late 1980s, many compilers simply performed all reads and writes >in the order given. The "volatile" keyword was added to make it possible >for compilers to perform optimizations without making the language unsuitable >for systems-programming use. An accurate characterization _at the time_. Today, with weak memory models, high core counts, out-of-order processor pipelines and the need for speed, volatile is insufficent. Hence the new memory model standards in C11, C++11 which provide additional language features (atomics) to manage memory accesses on modern processors. There are probably fewer than a couple dozen people today who can fully articulate and understand formal memory models for modern processors, I've found very few programmers (outside of the kernel world) who can rationalize clearly how multithreaded shared memory applications function on weak memory models.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 15:09 -0700 |
| Message-ID | <05c29cca-2167-4a74-bce4-6b111415bd5a@googlegroups.com> |
| In reply to | #109549 |
On Monday, May 8, 2017 at 4:16:34 PM UTC-5, Scott Lurndal wrote: > supercat writes: > >On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: > > >Before the late 1980s, many compilers simply performed all reads and writes > >in the order given. The "volatile" keyword was added to make it possible > >for compilers to perform optimizations without making the language unsuitable > >for systems-programming use. > > An accurate characterization _at the time_. Today, with weak memory models, > high core counts, out-of-order processor pipelines and the need for speed, > volatile is insufficent. Someone writing low-level code for a hardware platform should be responsible for doing whatever the hardware requires to ensure memory ordering. In some cases that may mean ensuring that all code that uses certain objects gets run on the same core [rather easy to do on single-core systems]. If the programmer takes care of everything that's needed on the hardware side, what is gained by *not* having "volatile" take care of the software side? > Hence the new memory model standards in C11, C++11 which provide additional > language features (atomics) to manage memory accesses on modern processors. Does the Standard allow a conforming implementation to offer any of the atomics.h features without the ability to perform deadlock-free atomic accesses to a 64-bit value? Is there any means by which a freestanding implementation for e.g. a Cortex-M0+ would be able to meet such a requirement without being dependent upon the processor mode or underlying OS (things to which freestanding code should generally be agnostic)? By my reading, unless I'm missing something, an implementation need not promise any atomics.h features, but if it promises any it must support all. If one is writing code for an implementation that can't support all atomic functions but whose underlying hardware will perform all loads and stores in execution order, how should one indicate that one group of loads and stores needs to be performed before another, but the operations within each group can be reordered and consolidated?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-08 15:14 -0700 |
| Message-ID | <oeqqer$2s8$1@dont-email.me> |
| In reply to | #109552 |
On 5/8/2017 3:09 PM, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 4:16:34 PM UTC-5, Scott Lurndal wrote: >> supercat writes: >>> On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: >> >>> Before the late 1980s, many compilers simply performed all reads and writes >>> in the order given. The "volatile" keyword was added to make it possible >>> for compilers to perform optimizations without making the language unsuitable >>> for systems-programming use. >> >> An accurate characterization _at the time_. Today, with weak memory models, >> high core counts, out-of-order processor pipelines and the need for speed, >> volatile is insufficent. > > Someone writing low-level code for a hardware platform should be responsible > for doing whatever the hardware requires to ensure memory ordering. In some > cases that may mean ensuring that all code that uses certain objects gets run > on the same core [rather easy to do on single-core systems]. If the > programmer takes care of everything that's needed on the hardware side, what > is gained by *not* having "volatile" take care of the software side? > >> Hence the new memory model standards in C11, C++11 which provide additional >> language features (atomics) to manage memory accesses on modern processors. > > Does the Standard allow a conforming implementation to offer any of the > atomics.h features without the ability to perform deadlock-free atomic > accesses to a 64-bit value? The standard allows us to juggle multiple revved up running chainsaws at once. The deadlocks are the programmers fault, not the standards. > Is there any means by which a freestanding > implementation for e.g. a Cortex-M0+ would be able to meet such a > requirement without being dependent upon the processor mode or underlying > OS (things to which freestanding code should generally be agnostic)? What requirement? Writing code that has no deadlocks? Well, yes the std allows us to write deadlock free code. > > By my reading, unless I'm missing something, an implementation need not > promise any atomics.h features, but if it promises any it must support all. > If one is writing code for an implementation that can't support all > atomic functions but whose underlying hardware will perform all loads and > stores in execution order, how should one indicate that one group of loads > and stores needs to be performed before another, but the operations within > each group can be reordered and consolidated? >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 15:43 -0700 |
| Message-ID | <a699f11c-18c0-4f66-8eae-19a7d9ebfec8@googlegroups.com> |
| In reply to | #109553 |
On Monday, May 8, 2017 at 5:15:04 PM UTC-5, Chris M. Thomasson wrote: > > Does the Standard allow a conforming implementation to offer any of the > > atomics.h features without the ability to perform deadlock-free atomic > > accesses to a 64-bit value? > > The standard allows us to juggle multiple revved up running chainsaws at > once. The deadlocks are the programmers fault, not the standards. The Standard allows implementations to use locks to implement atomic data types, but in many freestanding implementations the only thing code could do when trying to acquire a lock that's busy would be to spin in the hope that the lock somehow gets released--something that would never happen if e.g. an interrupt tries to acquire a lock that's held by the main-line. > > Is there any means by which a freestanding > > implementation for e.g. a Cortex-M0+ would be able to meet such a > > requirement without being dependent upon the processor mode or underlying > > OS (things to which freestanding code should generally be agnostic)? > > What requirement? Writing code that has no deadlocks? Well, yes the std > allows us to write deadlock free code. Implementing an atomic 64-bit integer type in a fashion that will work equally well in Privileged and Unprivileged modes, without any reliance upon an underlying OS [bearing in mind that in many cases freestanding implementations are used to *write* the OS], and in such a fashion that an attempt to access an atomic 64-bit int from an interrupt handler will work even if the main-line is trying to access it at the same time.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-08 16:56 -0700 |
| Message-ID | <oer0ce$imo$1@dont-email.me> |
| In reply to | #109554 |
On 5/8/2017 3:43 PM, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 5:15:04 PM UTC-5, Chris M. Thomasson wrote: >>> Does the Standard allow a conforming implementation to offer any of the >>> atomics.h features without the ability to perform deadlock-free atomic >>> accesses to a 64-bit value? >> >> The standard allows us to juggle multiple revved up running chainsaws at >> once. The deadlocks are the programmers fault, not the standards. > > The Standard allows implementations to use locks to implement atomic data > types, but in many freestanding implementations the only thing code could > do when trying to acquire a lock that's busy would be to spin in the hope > that the lock somehow gets released--something that would never happen if > e.g. an interrupt tries to acquire a lock that's held by the main-line. > >>> Is there any means by which a freestanding >>> implementation for e.g. a Cortex-M0+ would be able to meet such a >>> requirement without being dependent upon the processor mode or underlying >>> OS (things to which freestanding code should generally be agnostic)? >> >> What requirement? Writing code that has no deadlocks? Well, yes the std >> allows us to write deadlock free code. > > Implementing an atomic 64-bit integer type in a fashion that will work > equally well in Privileged and Unprivileged modes, without any reliance > upon an underlying OS [bearing in mind that in many cases freestanding > implementations are used to *write* the OS], and in such a fashion that > an attempt to access an atomic 64-bit int from an interrupt handler will > work even if the main-line is trying to access it at the same time. > Good point. If the platform has DWCAS, well so does C11. Take a look at: http://www.cplusplus.com/reference/atomic/atomic/is_lock_free If this returns true, then we are fine.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-08 16:57 -0700 |
| Message-ID | <oer0f5$imo$2@dont-email.me> |
| In reply to | #109555 |
On 5/8/2017 4:56 PM, Chris M. Thomasson wrote: > On 5/8/2017 3:43 PM, supercat@casperkitty.com wrote: >> On Monday, May 8, 2017 at 5:15:04 PM UTC-5, Chris M. Thomasson wrote: >>>> Does the Standard allow a conforming implementation to offer any of the >>>> atomics.h features without the ability to perform deadlock-free atomic >>>> accesses to a 64-bit value? >>> >>> The standard allows us to juggle multiple revved up running chainsaws at >>> once. The deadlocks are the programmers fault, not the standards. >> >> The Standard allows implementations to use locks to implement atomic data >> types, but in many freestanding implementations the only thing code could >> do when trying to acquire a lock that's busy would be to spin in the hope >> that the lock somehow gets released--something that would never happen if >> e.g. an interrupt tries to acquire a lock that's held by the main-line. >> >>>> Is there any means by which a freestanding >>>> implementation for e.g. a Cortex-M0+ would be able to meet such a >>>> requirement without being dependent upon the processor mode or >>>> underlying >>>> OS (things to which freestanding code should generally be agnostic)? >>> >>> What requirement? Writing code that has no deadlocks? Well, yes the std >>> allows us to write deadlock free code. >> >> Implementing an atomic 64-bit integer type in a fashion that will work >> equally well in Privileged and Unprivileged modes, without any reliance >> upon an underlying OS [bearing in mind that in many cases freestanding >> implementations are used to *write* the OS], and in such a fashion that >> an attempt to access an atomic 64-bit int from an interrupt handler will >> work even if the main-line is trying to access it at the same time. >> > > Good point. If the platform has DWCAS, well so does C11. Take a look at: > > http://www.cplusplus.com/reference/atomic/atomic/is_lock_free > > If this returns true, then we are fine. Take a look at: http://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts as well.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 17:27 -0700 |
| Message-ID | <8c378df2-d5d6-430f-a2cc-896b4487aad2@googlegroups.com> |
| In reply to | #109555 |
On Monday, May 8, 2017 at 6:56:10 PM UTC-5, Chris M. Thomasson wrote: > On 5/8/2017 3:43 PM, supercat wrote: > > Implementing an atomic 64-bit integer type in a fashion that will work > > equally well in Privileged and Unprivileged modes, without any reliance > > upon an underlying OS [bearing in mind that in many cases freestanding > > implementations are used to *write* the OS], and in such a fashion that > > an attempt to access an atomic 64-bit int from an interrupt handler will > > work even if the main-line is trying to access it at the same time. > > Good point. If the platform has DWCAS, well so does C11. Take a look at: > > http://www.cplusplus.com/reference/atomic/atomic/is_lock_free > > If this returns true, then we are fine. And if a platform can't support such operations in lock-free fashion, and there is no underlying OS that can support locks, what then?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-08 17:41 -0700 |
| Message-ID | <oer30t$pmj$1@dont-email.me> |
| In reply to | #109557 |
On 5/8/2017 5:27 PM, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 6:56:10 PM UTC-5, Chris M. Thomasson wrote: >> On 5/8/2017 3:43 PM, supercat wrote: >>> Implementing an atomic 64-bit integer type in a fashion that will work >>> equally well in Privileged and Unprivileged modes, without any reliance >>> upon an underlying OS [bearing in mind that in many cases freestanding >>> implementations are used to *write* the OS], and in such a fashion that >>> an attempt to access an atomic 64-bit int from an interrupt handler will >>> work even if the main-line is trying to access it at the same time. >> >> Good point. If the platform has DWCAS, well so does C11. Take a look at: >> >> http://www.cplusplus.com/reference/atomic/atomic/is_lock_free >> >> If this returns true, then we are fine. > > And if a platform can't support such operations in lock-free fashion, and > there is no underlying OS that can support locks, what then? Wrt using C atomics, your screwed. Bust out the assembler.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 06:16 -0700 |
| Message-ID | <4c60fe02-8a0a-44cf-a2aa-b68caa820247@googlegroups.com> |
| In reply to | #109559 |
On Monday, May 8, 2017 at 7:41:14 PM UTC-5, Chris M. Thomasson wrote: > On 5/8/2017 5:27 PM, supercat wrote: > > And if a platform can't support such operations in lock-free fashion, and > > there is no underlying OS that can support locks, what then? > > Wrt using C atomics, your screwed. Bust out the assembler. What if all I want is an ability to guarantee that a compiler won't reorder loads and store instructions across a piece of code? Any implementation should be capable of that (simply refrain from re-ordering load and store instructions across a piece of code) but I see no standard way to demand such behavior on something like a truly-freestanding Cortex M0 implementation that would lack the hardware or OS support required for all the features of atomics.h.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-09 12:11 -0700 |
| Message-ID | <oet427$pnk$1@dont-email.me> |
| In reply to | #109582 |
On 5/9/2017 6:16 AM, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 7:41:14 PM UTC-5, Chris M. Thomasson wrote: >> On 5/8/2017 5:27 PM, supercat wrote: >>> And if a platform can't support such operations in lock-free fashion, and >>> there is no underlying OS that can support locks, what then? >> >> Wrt using C atomics, your screwed. Bust out the assembler. > > What if all I want is an ability to guarantee that a compiler won't reorder > loads and store instructions across a piece of code? Any implementation > should be capable of that (simply refrain from re-ordering load and store > instructions across a piece of code) but I see no standard way to demand > such behavior on something like a truly-freestanding Cortex M0 implementation > that would lack the hardware or OS support required for all the features of > atomics.h. The atomics will make those guarantees wrt code reordering.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-10 09:58 +0000 |
| Message-ID | <5912e399.173796@news.xs4all.nl> |
| In reply to | #109582 |
supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 7:41:14 PM UTC-5, Chris M. Thomasson wrote: > > On 5/8/2017 5:27 PM, supercat wrote: > > > And if a platform can't support such operations in lock-free fashion, and > > > there is no underlying OS that can support locks, what then? > > > > Wrt using C atomics, your screwed. Bust out the assembler. > > What if all I want is an ability to guarantee that a compiler won't reorder > loads and store instructions across a piece of code? Then what you want is an assembler, not a compiler. A compiler is a higher-level concept than "LD A, (HL); ADD A, 4; LD 23609, A" Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-10 09:40 -0700 |
| Message-ID | <4f91cdeb-b7aa-4b12-9aeb-d4b5af3a2c49@googlegroups.com> |
| In reply to | #109646 |
On Wednesday, May 10, 2017 at 4:58:31 AM UTC-5, Richard Bos wrote: > supercat wrote: > > What if all I want is an ability to guarantee that a compiler won't reorder > > loads and store instructions across a piece of code? > > Then what you want is an assembler, not a compiler. A compiler is a > higher-level concept than "LD A, (HL); ADD A, 4; LD 23609, A" Are C# and Java lower-level languages than C? Both have constructs to block compiler re-ordering. I can fully appreciate that an implementation may be unsuitable for low- level programming, while still being useful for other purposes. Thus, an implementation can be conforming without being suitable for low-level programming. If an implementation is suitable for low-level and systems programming, however, it should offer a level of control which is at least as great as that offered by languages like Java and C#.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-10 12:05 -0700 |
| Message-ID | <oevo3a$md7$1@dont-email.me> |
| In reply to | #109687 |
On 5/10/2017 9:40 AM, supercat@casperkitty.com wrote: > On Wednesday, May 10, 2017 at 4:58:31 AM UTC-5, Richard Bos wrote: >> supercat wrote: >>> What if all I want is an ability to guarantee that a compiler won't reorder >>> loads and store instructions across a piece of code? >> >> Then what you want is an assembler, not a compiler. A compiler is a >> higher-level concept than "LD A, (HL); ADD A, 4; LD 23609, A" > > Are C# and Java lower-level languages than C? Both have constructs to > block compiler re-ordering. So does C and C++. http://en.cppreference.com/w/cpp/atomic/atomic_signal_fence > > I can fully appreciate that an implementation may be unsuitable for low- > level programming, while still being useful for other purposes. Thus, > an implementation can be conforming without being suitable for low-level > programming. If an implementation is suitable for low-level and systems > programming, however, it should offer a level of control which is at least > as great as that offered by languages like Java and C#. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-09 13:55 +0000 |
| Message-ID | <VSjQA.28100$9o7.28063@fx12.iad> |
| In reply to | #109553 |
"Chris M. Thomasson" <invalid@invalid.invalid> writes: >On 5/8/2017 3:09 PM, supercat@casperkitty.com wrote: >> Does the Standard allow a conforming implementation to offer any of the >> atomics.h features without the ability to perform deadlock-free atomic >> accesses to a 64-bit value? > >The standard allows us to juggle multiple revved up running chainsaws at >once. The deadlocks are the programmers fault, not the standards. If a particular core design does not provide the capability to generate atomic accesses, then there is not much the compiler can do. A Cortex-M0 is a very light-weight embedded core with a small footprint built on a two-decade old ISA - that's not the target for the standardized C11 atomics. I don't believe the M0 is offered in anything other than a single-core/single-thread configuration, so technically, atomics may not be necessary. Now, even without hardware atomics, most hardware has some form of instruction (e.g. load-exclusive/store-exclusive on ARM or LL/SC on MIPS) that can be used for for multi-threaded application synchronization.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 09:26 -0700 |
| Message-ID | <cc2eedc4-c4a2-42f5-b7bc-f610d1e3590d@googlegroups.com> |
| In reply to | #109587 |
On Tuesday, May 9, 2017 at 8:55:08 AM UTC-5, Scott Lurndal wrote: > If a particular core design does not provide the capability > to generate atomic accesses, then there is not much the compiler > can do. A Cortex-M0 is a very light-weight embedded core with > a small footprint built on a two-decade old ISA - that's not the > target for the standardized C11 atomics. I don't believe the M0 > is offered in anything other than a single-core/single-thread > configuration, so technically, atomics may not be necessary. What is necessary is a means of telling a compiler "execute the instructions that perform all object accesses--volatile or not--that precede this statement, before allowing the execution of any instructions that perform object accesses--volatile or not--that follow it". The <atomics.h> header defines such a feature, and some people seem to think that code needing such semantics should use that header. My objection to that is that many platforms where such semantics would be useful have no standard way of offering them, because they can't implement all of the features in <atomic.h> and the Standard allows no means by which they can implement some without implementing all. On many platforms, a guarantee that "volatile" accesses act as though they are preceded and followed by a barrier as described above would be sufficient to form the basis for everything else that might be needed. It might be better to use a standard-defined intrinsic with such an effect if one existed, but exists that is could be defined on all the platforms where it would be needed. > Now, even without hardware atomics, most hardware has some form > of instruction (e.g. load-exclusive/store-exclusive on ARM or > LL/SC on MIPS) that can be used for for multi-threaded application > synchronization. Indeed; when I initially mentioned 64-bit increment as problematic, I did so because I don't know a practical way to synthesize that using LL/SC without any reliance on processor mode or underlying OS. On the Cortex M0 the situation is more dire, since I don't know any way to synthesize *most* atomics under such constraints.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-09 13:56 -0500 |
| Message-ID | <vi34hclnapq6m836mf4i9l6tr284fs4pnl@4ax.com> |
| In reply to | #109602 |
On Tue, 9 May 2017 09:26:48 -0700 (PDT), supercat@casperkitty.com wrote: >On Tuesday, May 9, 2017 at 8:55:08 AM UTC-5, Scott Lurndal wrote: >> If a particular core design does not provide the capability >> to generate atomic accesses, then there is not much the compiler >> can do. A Cortex-M0 is a very light-weight embedded core with >> a small footprint built on a two-decade old ISA - that's not the >> target for the standardized C11 atomics. I don't believe the M0 >> is offered in anything other than a single-core/single-thread >> configuration, so technically, atomics may not be necessary. > >What is necessary is a means of telling a compiler "execute the instructions >that perform all object accesses--volatile or not--that precede this >statement, before allowing the execution of any instructions that perform >object accesses--volatile or not--that follow it". The <atomics.h> header >defines such a feature, and some people seem to think that code needing such >semantics should use that header. > >My objection to that is that many platforms where such semantics would >be useful have no standard way of offering them, because they can't implement >all of the features in <atomic.h> and the Standard allows no means by which >they can implement some without implementing all. > >On many platforms, a guarantee that "volatile" accesses act as though they >are preceded and followed by a barrier as described above would be >sufficient to form the basis for everything else that might be needed. It >might be better to use a standard-defined intrinsic with such an effect if >one existed, but exists that is could be defined on all the platforms where >it would be needed. > >> Now, even without hardware atomics, most hardware has some form >> of instruction (e.g. load-exclusive/store-exclusive on ARM or >> LL/SC on MIPS) that can be used for for multi-threaded application >> synchronization. > >Indeed; when I initially mentioned 64-bit increment as problematic, I did >so because I don't know a practical way to synthesize that using LL/SC >without any reliance on processor mode or underlying OS. On the Cortex M0 >the situation is more dire, since I don't know any way to synthesize *most* >atomics under such constraints. What exactly would be problematic on a M0? On any single processor system pretty much all of those can be implemented as: disable interrupts perform operation enable interrupts On a multiprocessor M0 (should such a thing exist), you can do that by also acquiring and releasing a spin lock (or a proper mutex). and you can do a spin lock with Dekker's algorithm even if the processor provides no atomic update at all (if you have at least test-and-set, implementing a spin lock is trivial). And while Dekker's is limited to only two processors, there are more complex algorithms which are not (Peterson's, for example). Obviously any atomics implemented that way would not declare the associated types atomic_is_lock_free. As to the rest, the compiler will have to get involved in some things (like code order).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 14:19 -0700 |
| Message-ID | <93b7b49c-a31e-4605-8350-dcfe5589bdbd@googlegroups.com> |
| In reply to | #109615 |
On Tuesday, May 9, 2017 at 1:56:37 PM UTC-5, robert...@yahoo.com wrote: > What exactly would be problematic on a M0? On any single processor > system pretty much all of those can be implemented as: > > disable interrupts > perform operation > enable interrupts A freestanding implementation should avoid presumptions about the context in which code will be run. Any code which tries to disable interrupts on the M0+ will only work if run in Privileged mode, and would thus be unusable from within user tasks under an OS that runs such tasks in Unprivileged mode. While I don't know to what extent controllers based on the M0+ have hardware designs that would make the Privileged/Unprivileged distinction useful, the ARM Cortex-M0+ does recognize it and it would seem presumptuous for a freestanding implementation to impose requirements on the execution context. It might be reasonable for a Cortex-M0 implementation to require the use of a configuration option to specify whether it should generate code that is suitable for use in Unprivileged mode, and support atomics.h only when it isn't going so, but that would still leave the problem of how to tell a compiler not to perform its own reordering of operations across a boundary when generating code suitable for use in Unprivileged mode. > On a multiprocessor M0 (should such a thing exist), you can do that by > also acquiring and releasing a spin lock (or a proper mutex). and you > can do a spin lock with Dekker's algorithm even if the processor > provides no atomic update at all (if you have at least test-and-set, > implementing a spin lock is trivial). And while Dekker's is limited > to only two processors, there are more complex algorithms which are > not (Peterson's, for example). Spinlocks break in the scenario where atomics would most often be needed on cores like the M0--for variables which are accessed by an interrupt and the mainline. If there were a guarantee that all accesses would be done in a single mainline or in nested interrupts, it would be possible to precede each atomic update with an initially-null pointer that would (if non-null) identify a data structure identifying what would have to happen to finish an operation that was in progress. I don't know any way to make such a thing work if nested contexts aren't guaranteed to finish before returning control, however.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-10 14:22 +0200 |
| Message-ID | <oev0g8$vef$1@dont-email.me> |
| In reply to | #109633 |
On 09/05/17 23:19, supercat@casperkitty.com wrote: > On Tuesday, May 9, 2017 at 1:56:37 PM UTC-5, robert...@yahoo.com wrote: >> What exactly would be problematic on a M0? On any single processor >> system pretty much all of those can be implemented as: >> >> disable interrupts >> perform operation >> enable interrupts > > A freestanding implementation should avoid presumptions about the context > in which code will be run. Any code which tries to disable interrupts on > the M0+ will only work if run in Privileged mode, and would thus be unusable > from within user tasks under an OS that runs such tasks in Unprivileged > mode. While I don't know to what extent controllers based on the M0+ have > hardware designs that would make the Privileged/Unprivileged distinction > useful, the ARM Cortex-M0+ does recognize it and it would seem presumptuous > for a freestanding implementation to impose requirements on the execution > context. There are no M0+ implementations with unprivileged modes. There are some M3/M4 devices that have them, but I think you would look long and hard to find a single example of a program for them that does not run in privileged mode all the time. And if you /have/ such a distinction, then you necessarily have an OS of some sort that runs in privileged mode and will provide such services as locks or atomic accesses. Thus your implementation is: perform system call for the appropriate operation The implementation in the OS is: preserve current interrupt status disable interrupts perform operation restore previous interrupt status Problem solved.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-10 09:26 -0700 |
| Message-ID | <55cb8bb2-f209-4000-8f3b-5fd7438c7cc7@googlegroups.com> |
| In reply to | #109656 |
On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: > There are no M0+ implementations with unprivileged modes. There are > some M3/M4 devices that have them, but I think you would look long and > hard to find a single example of a program for them that does not run in > privileged mode all the time. The ARM information page describes the effects of Unprivileged mode on implementations that care to implement it. It does not specify whether any actually do so. Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm not sure how that can effectively be leveraged to implement an atomic 64- bit type in contexts that don't support a spinlock. Do you know of any lock-free algorithms to implement 64-bit atomic operations using 32-bit LL/CS without relying upon any shared global state, heap storage, or other things that might be unavailable to a freestanding implementation? > And if you /have/ such a distinction, then you necessarily have an OS of > some sort that runs in privileged mode and will provide such services as > locks or atomic accesses. Thus your implementation is: > > perform system call for the appropriate operation > > The implementation in the OS is: > > preserve current interrupt status > disable interrupts > perform operation > restore previous interrupt status > > Problem solved. The programmer may know about the underlying OS, but that doesn't mean that the compiler would. Would the Standard allow for an implementation to report that it supports atomics if, when code tries to perform an operation on a 64-bit atomic type, it calls a function with an implementation-defined name that user code would then be required to supply, which would in turn have to perform the operation without help from the compiler? A lot of free- standing implementations handle things like stdio.h in such a fashion, but that's allowable because the Standard doesn't require them to supply such functionality in the first place. Is an implementation allowed to say that it supports atomics.h functionality but then punt all the implementation back to the programmer?
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web