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 263 — 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) supercat@casperkitty.com - 2017-05-15 08:28 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 19:21 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-16 08:24 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 11:25 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-17 10:14 -0700
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) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-15 17:44 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-15 17:47 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-16 12:07 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-16 15:28 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-16 15:52 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-17 15:49 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-17 16:36 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-19 14:53 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-18 06:17 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-18 07:51 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-18 22:28 -0500
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-19 00:30 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 14:51 -0500
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:33 -0500
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:51 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:14 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:07 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:30 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:44 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:42 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-05 14:10 +0000
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 17:12 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 15:08 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:24 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:29 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 18:07 +0000
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 20:15 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 15:47 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 01:22 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 18:57 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 09:30 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:25 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 10:33 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 10:10 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 12:49 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-05 18:31 -0700
Re: gcc failure (optimised/non-optimised) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-05 22:18 -0600
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-07 23:58 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:33 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:04 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:51 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-08 19:01 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:39 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 06:42 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:53 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-05 00:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:54 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:27 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:10 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:56 -0500
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:00 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:15 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:06 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:43 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 21:52 +0200
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-01 23:16 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-02 09:19 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:28 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 13:12 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:23 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 10:08 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:32 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 13:59 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:47 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-30 21:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 11:24 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:45 -0700
Re: gcc failure (optimised/non-optimised) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-04-23 23:11 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:46 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:23 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 15:38 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 17:31 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-24 17:15 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:36 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:06 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 14:03 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:25 -0700
Re: gcc failure (optimised/non-optimised) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-27 05:51 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:08 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-01 10:48 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 11:39 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-05-01 13:54 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:55 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:18 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:03 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:13 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 19:47 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 18:51 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 14:06 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 21:05 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 16:06 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 14:19 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 08:41 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:07 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:44 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 09:03 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 09:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:41 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:51 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 08:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:13 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:11 +0000
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:04 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:57 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:38 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:43 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 18:22 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 17:48 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:24 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-27 03:03 -0700
Re: gcc failure (optimised/non-optimised) James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:12 -0400
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:48 +0000
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 10:14 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:32 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:47 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-26 08:53 +0200
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-14 13:14 -0700 |
| Message-ID | <ofadk9$9tt$1@dont-email.me> |
| In reply to | #109835 |
On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: > On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >> On 11/05/17 23:43, Chris M. Thomasson wrote: >>> On 5/11/2017 1:45 AM, David Brown wrote: >>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: [...] > And we get spinlocks, whose very name indicates what's wrong with > them, instead of proper primitives for managing threads of > execution. Why do you think we need spinlocks on Intel processors? We can code a diverse array of non-blocking algorithms on Intel cpus.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-14 16:04 -0500 |
| Message-ID | <udhhhc910cbfqjhbh8migkdverspv3crc4@4ax.com> |
| In reply to | #109974 |
On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" <invalid@invalid.invalid> wrote: >On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >>> On 11/05/17 23:43, Chris M. Thomasson wrote: >>>> On 5/11/2017 1:45 AM, David Brown wrote: >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >[...] > > > And we get spinlocks, whose very name indicates what's wrong with > > them, instead of proper primitives for managing threads of > > execution. > >Why do you think we need spinlocks on Intel processors? We can code a >diverse array of non-blocking algorithms on Intel cpus. The only reason I brought up spinlocks is that they're a sufficient primitive to allow the building of all the atomic functions in C. That many processors provide better ways to implement many of those atomics is nice, but not really pertinent to the original point.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-15 17:44 -0700 |
| Message-ID | <ofdhqv$v3n$2@dont-email.me> |
| In reply to | #109982 |
On 5/14/2017 2:04 PM, Robert Wessel wrote: > On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" > <invalid@invalid.invalid> wrote: > >> On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: >>> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >>>> On 11/05/17 23:43, Chris M. Thomasson wrote: >>>>> On 5/11/2017 1:45 AM, David Brown wrote: >>>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >> [...] >> >>> And we get spinlocks, whose very name indicates what's wrong with >>> them, instead of proper primitives for managing threads of >>> execution. >> >> Why do you think we need spinlocks on Intel processors? We can code a >> diverse array of non-blocking algorithms on Intel cpus. > > > The only reason I brought up spinlocks is that they're a sufficient > primitive to allow the building of all the atomic functions in C. That > many processors provide better ways to implement many of those atomics > is nice, but not really pertinent to the original point. > Using spinlocks to implement the atomics is totally legit, as long as the macro tests tell the user that its not lock-free.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-15 17:47 -0700 |
| Message-ID | <ofdi1i$v3n$3@dont-email.me> |
| In reply to | #110115 |
On 5/15/2017 5:44 PM, Chris M. Thomasson wrote: > On 5/14/2017 2:04 PM, Robert Wessel wrote: >> On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" >> <invalid@invalid.invalid> wrote: >> >>> On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: >>>> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >>>>> On 11/05/17 23:43, Chris M. Thomasson wrote: >>>>>> On 5/11/2017 1:45 AM, David Brown wrote: >>>>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >>> [...] >>> >>>> And we get spinlocks, whose very name indicates what's wrong with >>>> them, instead of proper primitives for managing threads of >>>> execution. >>> >>> Why do you think we need spinlocks on Intel processors? We can code a >>> diverse array of non-blocking algorithms on Intel cpus. >> >> >> The only reason I brought up spinlocks is that they're a sufficient >> primitive to allow the building of all the atomic functions in C. That >> many processors provide better ways to implement many of those atomics >> is nice, but not really pertinent to the original point. >> > > Using spinlocks to implement the atomics is totally legit, as long as > the macro tests tell the user that its not lock-free. One point, one can use obstruction free techniques to implement the atomics. Humm. I guess that would be lock-free in a sense. Obstruction free is prone to live lock conditions. It has weaker guarantees than lock-free.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-16 12:07 -0700 |
| Message-ID | <ac6ea971-30fa-44c4-ac01-edae26d0b350@googlegroups.com> |
| In reply to | #110116 |
On Monday, May 15, 2017 at 7:48:02 PM UTC-5, Chris M. Thomasson wrote: > One point, one can use obstruction free techniques to implement the > atomics. Humm. I guess that would be lock-free in a sense. Obstruction > free is prone to live lock conditions. It has weaker guarantees than > lock-free. What primitives are required to implement the required operations in an obstruction-free fashion? Is a 32-bit LL/SC sufficient to implement an 64-bit LL/SC if one is allowed extra storage next to the LL/SC, and is allowed to assume that threads have read-only access to other threads' local variables while those other threads are still in contention, but but attempted reads may yield arbitrary data if performed after other threads exit their update routines?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-16 15:28 -0700 |
| Message-ID | <offu7a$qj9$1@dont-email.me> |
| In reply to | #110170 |
On 5/16/2017 12:07 PM, supercat@casperkitty.com wrote: > On Monday, May 15, 2017 at 7:48:02 PM UTC-5, Chris M. Thomasson wrote: >> One point, one can use obstruction free techniques to implement the >> atomics. Humm. I guess that would be lock-free in a sense. Obstruction >> free is prone to live lock conditions. It has weaker guarantees than >> lock-free. > > What primitives are required to implement the required operations in an > obstruction-free fashion? Is a 32-bit LL/SC sufficient to implement an > 64-bit LL/SC if one is allowed extra storage next to the LL/SC, and is > allowed to assume that threads have read-only access to other threads' > local variables while those other threads are still in contention, but > but attempted reads may yield arbitrary data if performed after other > threads exit their update routines? It has been a while since I have implemented such things, however iirc, Atomic fetch-and-add and CAS works. We can use 32-bit atomic ops in an obstruction free transactional memory to mimic multiple atomic multi word ops. However, I even if we use obstruction free in an impl, we simply have to tell the user that it is NOT lock-free. C/C++ has a means for just that. http://people.csail.mit.edu/shanir/publications/DISC2005.pdf
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-16 15:52 -0700 |
| Message-ID | <6e169aaa-016a-4f13-8a0f-2f2e3f6ece94@googlegroups.com> |
| In reply to | #110188 |
On Tuesday, May 16, 2017 at 5:28:11 PM UTC-5, Chris M. Thomasson wrote: > We can use 32-bit atomic ops in an obstruction free transactional memory > to mimic multiple atomic multi word ops. However, I even if we use > obstruction free in an impl, we simply have to tell the user that it is > NOT lock-free. C/C++ has a means for just that. Unfortunately, that only works if an implementation has a means of saying "Let some other code run in such a way that whoever holds this lock will eventually give it up, and then get back to me". If no such means exists, as would be the case on a system where interrupts share the same stack as the mainline (common in the embedded world) lock-based solutions won't work. If something is impossible, the fact that the Standard would grant permission to do it won't change that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-17 15:49 -0700 |
| Message-ID | <ofijs5$kgs$2@dont-email.me> |
| In reply to | #110190 |
On 5/16/2017 3:52 PM, supercat@casperkitty.com wrote: > On Tuesday, May 16, 2017 at 5:28:11 PM UTC-5, Chris M. Thomasson wrote: >> We can use 32-bit atomic ops in an obstruction free transactional memory >> to mimic multiple atomic multi word ops. However, I even if we use >> obstruction free in an impl, we simply have to tell the user that it is >> NOT lock-free. C/C++ has a means for just that. > > Unfortunately, that only works if an implementation has a means of saying > "Let some other code run in such a way that whoever holds this lock will > eventually give it up, and then get back to me". If no such means exists, > as would be the case on a system where interrupts share the same stack as > the mainline (common in the embedded world) lock-based solutions won't > work. If something is impossible, the fact that the Standard would grant > permission to do it won't change that. > Obstruction free is not lock-based at all. However, its not lock-free either. So, we have to tell the user that the impl is not lock-free.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 16:36 -0700 |
| Message-ID | <2ac5df8f-9b63-471c-9f17-55bb323cbdd4@googlegroups.com> |
| In reply to | #110244 |
On Wednesday, May 17, 2017 at 5:49:59 PM UTC-5, Chris M. Thomasson wrote: > Obstruction free is not lock-based at all. However, its not lock-free > either. So, we have to tell the user that the impl is not lock-free. I don't see any definition of the term "lock-free" in N1570. Judging from the definitions at https://en.wikipedia.org/wiki/Non-blocking_algorithm an algorithm cannot be considered lock free if there would exist some possible sequence of execution wherein all threads would be live-locked indefinitely, but from a practical standpoint there are often ways of ensuring that any live-lock situation will get broken within some finite period of time, which would satisfy what most programs would need.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-19 14:53 -0700 |
| Message-ID | <ofnp9p$qab$1@dont-email.me> |
| In reply to | #110246 |
On 5/17/2017 4:36 PM, supercat@casperkitty.com wrote: > On Wednesday, May 17, 2017 at 5:49:59 PM UTC-5, Chris M. Thomasson wrote: >> Obstruction free is not lock-based at all. However, its not lock-free >> either. So, we have to tell the user that the impl is not lock-free. > > I don't see any definition of the term "lock-free" in N1570. Judging from > the definitions at https://en.wikipedia.org/wiki/Non-blocking_algorithm > an algorithm cannot be considered lock free if there would exist some > possible sequence of execution wherein all threads would be live-locked > indefinitely, but from a practical standpoint there are often ways of > ensuring that any live-lock situation will get broken within some finite > period of time, which would satisfy what most programs would need. > Look at the name here: http://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-18 06:17 -0700 |
| Message-ID | <a4177340-0bad-4fb6-995f-885c295c39c8@googlegroups.com> |
| In reply to | #109982 |
On Monday, May 15, 2017 at 6:05:02 AM UTC+9, robert...@somewhere wrote: > On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" > <invalid@invalid.invalid> wrote: > > >On 5/12/2017 7:30 AM, joel.rees@somewhere wrote: > >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: > >>> On 11/05/17 23:43, Chris M. Thomasson wrote: > >>>> On 5/11/2017 1:45 AM, David Brown wrote: > >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: > >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: > >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: > >[...] > > > > > And we get spinlocks, whose very name indicates what's wrong with > > > them, instead of proper primitives for managing threads of > > > execution. > > > >Why do you think we need spinlocks on Intel processors? We can code a > >diverse array of non-blocking algorithms on Intel cpus. Because Intel's CPUs make it so hard to build a proper atomic ... all in the name of hyperthreading. > The only reason I brought up spinlocks is that they're a sufficient > primitive to allow the building of all the atomic functions in C. That > many processors provide better ways to implement many of those atomics > is nice, but not really pertinent to the original point. Oh, yes, they are sufficient for building all the atomic functions in C. If you ignore the time domain. -- Joel Rees Randomly reinventing the industry: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-18 07:51 -0700 |
| Message-ID | <94831b4d-b885-4a21-9aef-ea48f70f1ad3@googlegroups.com> |
| In reply to | #110274 |
On Thursday, May 18, 2017 at 8:17:32 AM UTC-5, joel...@gmail.com wrote:
> On Monday, May 15, 2017 at 6:05:02 AM UTC+9, robert...@somewhere wrote:
> > The only reason I brought up spinlocks is that they're a sufficient
> > primitive to allow the building of all the atomic functions in C. That
> > many processors provide better ways to implement many of those atomics
> > is nice, but not really pertinent to the original point.
>
> Oh, yes, they are sufficient for building all the atomic functions in C.
>
> If you ignore the time domain.
When discussing code for Intel processors, the term "spinlock" is often used
for a pattern something like:
int n=SOME_NUMBER;
do
{
if (!atomic_read_and_set(&lock_is_busy,1))
break;
} while(--n);
if (!n)
acquire_lock_via_os(&lock_is_busy);
... use lock
if (notify_os_of_lock_release == 1)
release_lock_via_os(&lock_is_busy);
else
lock_is_busy = 0;
used for some of an operating system's *internal* locks (rather than those
exposed to the programmer) which are never deliberately held for very long.
Note that cores only spend time spinning on locks in cases where the time
spent waiting for them to become available is expected to be less than the
time required for a context switch.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-18 22:28 -0500 |
| Message-ID | <mgpshc16hk6u5v8p1h9neq74tb4d0iqrgf@4ax.com> |
| In reply to | #110274 |
On Thu, 18 May 2017 06:17:22 -0700 (PDT), joel.rees@gmail.com wrote: >On Monday, May 15, 2017 at 6:05:02 AM UTC+9, robert...@somewhere wrote: >> On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" >> <invalid@invalid.invalid> wrote: >> >> >On 5/12/2017 7:30 AM, joel.rees@somewhere wrote: >> >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >> >>> On 11/05/17 23:43, Chris M. Thomasson wrote: >> >>>> On 5/11/2017 1:45 AM, David Brown wrote: >> >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >> >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >> >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >> >[...] >> > >> > > And we get spinlocks, whose very name indicates what's wrong with >> > > them, instead of proper primitives for managing threads of >> > > execution. >> > >> >Why do you think we need spinlocks on Intel processors? We can code a >> >diverse array of non-blocking algorithms on Intel cpus. > >Because Intel's CPUs make it so hard to build a proper atomic > >... all in the name of hyperthreading. How is it harder than a "real" multi-core situation with x86? >> The only reason I brought up spinlocks is that they're a sufficient >> primitive to allow the building of all the atomic functions in C. That >> many processors provide better ways to implement many of those atomics >> is nice, but not really pertinent to the original point. > >Oh, yes, they are sufficient for building all the atomic functions in C. > >If you ignore the time domain. The standard more-or-less ignores the time domain as regards the atomics.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-19 00:30 -0700 |
| Message-ID | <08edccbb-aa66-4533-a666-e06659d672c2@googlegroups.com> |
| In reply to | #110355 |
On Friday, May 19, 2017 at 12:28:52 PM UTC+9, robert...@yahoo.com wrote: > On Thu, 18 May 2017 06:17:22 -0700 (PDT), joel.rees@somewhere wrote: > > >On Monday, May 15, 2017 at 6:05:02 AM UTC+9, robert...@somewhere wrote: > >> On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" > >> <invalid@invalid.invalid> wrote: > >> > >> >On 5/12/2017 7:30 AM, joel.rees@somewhere wrote: > >> >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: > >> >>> On 11/05/17 23:43, Chris M. Thomasson wrote: > >> >>>> On 5/11/2017 1:45 AM, David Brown wrote: > >> >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: > >> >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: > >> >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: > >> >[...] > >> > > >> > > And we get spinlocks, whose very name indicates what's wrong with > >> > > them, instead of proper primitives for managing threads of > >> > > execution. > >> > > >> >Why do you think we need spinlocks on Intel processors? We can code a > >> >diverse array of non-blocking algorithms on Intel cpus. > > > >Because Intel's CPUs make it so hard to build a proper atomic > > > >... all in the name of hyperthreading. > > > How is it harder than a "real" multi-core situation with x86? It's the focus on trying to keep the CPU from stalling, really. Optimizing the wrong things. > >> The only reason I brought up spinlocks is that they're a sufficient > >> primitive to allow the building of all the atomic functions in C. That > >> many processors provide better ways to implement many of those atomics > >> is nice, but not really pertinent to the original point. > > > >Oh, yes, they are sufficient for building all the atomic functions in C. > > > >If you ignore the time domain. > > > The standard more-or-less ignores the time domain as regards the > atomics. Which is a problem. -- Joel Rees Delusions of being a novelist: http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-24 14:51 -0500 |
| Message-ID | <80pbiclia7p09gga84uc9i2eetsrl3h0ef@4ax.com> |
| In reply to | #110362 |
On Fri, 19 May 2017 00:30:56 -0700 (PDT), joel.rees@gmail.com wrote: >On Friday, May 19, 2017 at 12:28:52 PM UTC+9, robert...@yahoo.com wrote: >> On Thu, 18 May 2017 06:17:22 -0700 (PDT), joel.rees@somewhere wrote: >> >> >On Monday, May 15, 2017 at 6:05:02 AM UTC+9, robert...@somewhere wrote: >> >> On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" >> >> <invalid@invalid.invalid> wrote: >> >> >> >> >On 5/12/2017 7:30 AM, joel.rees@somewhere wrote: >> >> >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >> >> >>> On 11/05/17 23:43, Chris M. Thomasson wrote: >> >> >>>> On 5/11/2017 1:45 AM, David Brown wrote: >> >> >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >> >> >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >> >> >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >> >> >[...] >> >> > >> >> > > And we get spinlocks, whose very name indicates what's wrong with >> >> > > them, instead of proper primitives for managing threads of >> >> > > execution. >> >> > >> >> >Why do you think we need spinlocks on Intel processors? We can code a >> >> >diverse array of non-blocking algorithms on Intel cpus. >> > >> >Because Intel's CPUs make it so hard to build a proper atomic >> > >> >... all in the name of hyperthreading. >> >> >> How is it harder than a "real" multi-core situation with x86? > >It's the focus on trying to keep the CPU from stalling, really. > >Optimizing the wrong things. Which really doesn't answer the question. >> >> The only reason I brought up spinlocks is that they're a sufficient >> >> primitive to allow the building of all the atomic functions in C. That >> >> many processors provide better ways to implement many of those atomics >> >> is nice, but not really pertinent to the original point. >> > >> >Oh, yes, they are sufficient for building all the atomic functions in C. >> > >> >If you ignore the time domain. >> >> >> The standard more-or-less ignores the time domain as regards the >> atomics. > >Which is a problem. Perhaps, but not, as near as I can tell, the one being discussed.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-10 17:33 -0500 |
| Message-ID | <jo47hc1aggo4ir7953c3rjqvtikrnq9nqk@4ax.com> |
| In reply to | #109633 |
On Tue, 9 May 2017 14:19:25 -0700 (PDT), 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. Hard to avoid as soon as you start implementing anything that might interact with the OS (or anything OS-like on a small system). >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. If you're going to want to implement stdatomic, you'll have to interact with the OS on almost all systems. >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. Spinlocks need to be used *with* the interrupt disable. The sequence is along the lines of: spin: cli tas flag jset doit sti jmp spin doit: ...perform atomic op... mov flag,0 sti The spinlock is only required in the multi-processor case. On a single processor, the interrupt disable is sufficient. If there's an OS that's preventing access to the interrupt disable flag, it should probably be providing either a proper mutex, or the atomic functions itself. > 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-09 13:51 +0000 |
| Message-ID | <pPjQA.28099$9o7.7307@fx12.iad> |
| In reply to | #109552 |
supercat@casperkitty.com writes: >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]. Even that doesn't work with an out-of-order core, where the processor itself can hoist a load ahead of a store unless special barrier instructions are emitted by the compiler and/or programmer to prevent such reordering.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 09:14 -0700 |
| Message-ID | <b37d3d4f-72dc-4c3b-a9f8-c28ff24171d4@googlegroups.com> |
| In reply to | #109586 |
On Tuesday, May 9, 2017 at 8:51:31 AM UTC-5, Scott Lurndal wrote: > Even that doesn't work with an out-of-order core, where the processor itself > can hoist a load ahead of a store unless special barrier instructions are > emitted by the compiler and/or programmer to prevent such reordering. Naturally. Someone writing low-level code needs to know the target hardware. My point is that if a platform makes it possible to achieve required ordering through a certain sequence of loads and stores (e.g. by including at least one dummy I/O read before any I/O operation that would trigger a DMA write, and after any I/O operation that would trigger a DMA read, or by programming the bus management unit to disable certain kinds of overlapping) an implementation which is is designed to be compatible with low-level code on that platform shouldn't require compiler-specific gymnastics to prevent compiler reordering from messing things up. I'm curious how often reordering non-volatile operations across volatile ones really improves performance. Given a choice between compatibility with code that doesn't use compiler-specific directives or an occasional slight performance boost, I would think it would be better to favor compatibility by default.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-08 21:07 +0000 |
| Message-ID | <465QA.53427$rl4.5902@fx35.iad> |
| In reply to | #109532 |
David Brown <david.brown@hesbynett.no> writes: >On 08/05/17 18:16, supercat@casperkitty.com wrote: > >> >> In the days before "volatile", such code would simply work but compilers >> had to do all memory accesses in order. > >I don't know when "volatile" came into use, but it is in the C89 >standard. K&R Second Edition (1988 - ANSI C) documents the 'volatile' keyword, so one can assume it entered the language sometime during the 1983-1988 period when X3J11 was working. >> I am fully aware that there are some hardware platforms where loads and >> stores may be cached or reordered at the hardware level. On many systems, >> however, a programmer will know of all such hardware issues that exist (if >> any). The question is whether compilers should require the use of compiler- >> specific directives to prevent them from creating problems of their own. Most modern programmers are ill-equiped to deal with weak memory models vis-a-vis concurrent programming. C and C++ standards have both added language features to help programmers deal with weak memory models without necessarily being able to articulate the ordering characteristics of the model, for example when a load is reordered ahead of a store that the programmer naively expects to happen in program order with respect to external visibility of the store (e.g when writing to a memory mapped I/O register).
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-09 18:30 +0100 |
| Message-ID | <8760hadjjt.fsf@gmail.com> |
| In reply to | #109532 |
David Brown <david.brown@hesbynett.no> writes: > On 08/05/17 18:16, supercat@casperkitty.com wrote: >> On Monday, May 8, 2017 at 9:21:09 AM UTC-5, David Brown wrote: >>> "some_value" is not volatile, and the compiler can see it is never >>> changed. Why should it reload it? Is the compiler to guess what you >>> meant to write? I suppose /I/ should have been able to guess what you >>> meant, but I often find it hard with your examples. >> >> On many systems, data is read or written by giving some outside process the >> address if the data and performing a write to a volatile location to trigger >> that process. It is not unusual for the act of writing to a volatile location >> to affect other aspects of system state. > > Yes, it is unusual. The code is wrong - it is incorrect C. Maybe you > are used to writing such code, but /I/ certainly am not. Now we get to the nub. Supercat has been writing that incorrect code for decades, and it used to kind-of-mostly-work and he is /pissed/ that everyone else refuses to be constrained by his ingrained misconceptions.
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web