Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #108327 > unrolled thread

gcc failure (optimised/non-optimised)

Back to article view | Back to comp.lang.c

Contents

  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 1 of 13  [1] 2 3 … 13  Next page →

#108327 — gcc failure (optimised/non-optimised)

I saw this posted elsewhere. The gcc optimiser evidently changes the 
behaviour of the code relative to its non-optimised effect.

int main(int argc, char **argv) {
     int i;
     for (i = 0; i < i + 1; i++)
         ;
     return 0;
}


$ cc iter-test.c
$ time ./a.out
real    0m7.314s
user    0m7.304s
sys     0m0.000s

$ cc iter-test.c -O3
$ time ./a.out
(ran until interrupted)

It seems that when compared with the unoptimised code the optimiser (at 
least of gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)) adjusts the 
loop test so that it is always true.

Run times
-O0: 7s (unoptimised)
-O1: 2s
-O2: ran until interrupted
-O3: ran until interrupted

Thoughts?


-- 
James Harris

[toc] | [next] | [standalone]

#108328

On 22/04/2017 09:06, James Harris wrote:
> I saw this posted elsewhere. The gcc optimiser evidently changes the
> behaviour of the code relative to its non-optimised effect.
> 
> int main(int argc, char **argv) {
>     int i;
>     for (i = 0; i < i + 1; i++)
>         ;
>     return 0;
> }
> 
> 
> $ cc iter-test.c
> $ time ./a.out
> real    0m7.314s
> user    0m7.304s
> sys     0m0.000s
> 
> $ cc iter-test.c -O3
> $ time ./a.out
> (ran until interrupted)
> 
> It seems that when compared with the unoptimised code the optimiser (at
> least of gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)) adjusts the
> loop test so that it is always true.
> 
> Run times
> -O0: 7s (unoptimised)
> -O1: 2s
> -O2: ran until interrupted
> -O3: ran until interrupted
> 
> Thoughts?

Overflow of signed integers is UB.  Therefore "i < i + 1" can
legitimately be simplified to true.

Use -fwrapv if you want GCC/Clang to strictly consider signed integer
overflow to have defined twos-compliment behaviour.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html is
an excellent set of articles which everyone should read.

~Andrew

[toc] | [prev] | [next] | [standalone]

#108331

On 22/04/2017 09:49, Andrew Cooper wrote:
> On 22/04/2017 09:06, James Harris wrote:
>> I saw this posted elsewhere. The gcc optimiser evidently changes the
>> behaviour of the code relative to its non-optimised effect.
>>
>> int main(int argc, char **argv) {
>>     int i;
>>     for (i = 0; i < i + 1; i++)
>>         ;
>>     return 0;
>> }
>>
>>
>> $ cc iter-test.c
>> $ time ./a.out
>> real    0m7.314s
>> user    0m7.304s
>> sys     0m0.000s
>>
>> $ cc iter-test.c -O3
>> $ time ./a.out
>> (ran until interrupted)
>>
>> It seems that when compared with the unoptimised code the optimiser (at
>> least of gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)) adjusts the
>> loop test so that it is always true.
>>
>> Run times
>> -O0: 7s (unoptimised)
>> -O1: 2s
>> -O2: ran until interrupted
>> -O3: ran until interrupted
>>
>> Thoughts?
>
> Overflow of signed integers is UB.  Therefore "i < i + 1" can
> legitimately be simplified to true.
>
> Use -fwrapv if you want GCC/Clang to strictly consider signed integer
> overflow to have defined twos-compliment behaviour.
>
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html is
> an excellent set of articles which everyone should read.

Thanks. That's very interesting.

What gets me is that the compiler is (potentially) altering the 
behaviour of the code without issuing a warning. That's true even with 
-Wall -Wextra.

I found that one has to add -Wstrict-overflow=5 to get the compiler to 
warn about the signed-overflow assumption its optimiser is making.

$ cc iter-test.c -Wall -Wextra -Wstrict-overflow=5 -O2
iter-test.c: In function  Ç main Ç :
iter-test.c:3:5: warning: assuming signed overflow does not occur when 
reducing constant in comparison [-Wstrict-overflow]
      for (i = 0; i < i + 1; i++)
      ^

One to add to my list of compiler switches to use. But doing that has 
two problems:

1. How many more similar switches would be needed to catch all the other 
forms of undefined behaviour that the compiler is able to recognise?

2. I think I would rather this and similar warnings were enabled by 
default and needed a conscious decision to disable. Failing that, IMO it 
would be OK to have a switch such as -Wundefined which turned on all 
such checking but still allowed individual checks to be turned off.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#108334

James Harris <james.harris.1@gmail.com> writes:

>> Overflow of signed integers is UB.  Therefore "i < i + 1" can
>> legitimately be simplified to true.
>>
>> Use -fwrapv if you want GCC/Clang to strictly consider signed integer
>> overflow to have defined twos-compliment behaviour.
>>
>> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html is
>> an excellent set of articles which everyone should read.
>
> Thanks. That's very interesting.
>
> What gets me is that the compiler is (potentially) altering the
> behaviour of the code without issuing a warning. That's true even with
> -Wall -Wextra.

The code does not have (defined) behaviour.  Code whose behaviour is not
defined, does not have to consistent modes of misbehaviour.

[toc] | [prev] | [next] | [standalone]

#108387

On 22/04/2017 11:37, Gareth Owen wrote:
> James Harris <james.harris.1@gmail.com> writes:
>
>>> Overflow of signed integers is UB.  Therefore "i < i + 1" can
>>> legitimately be simplified to true.
>>>
>>> Use -fwrapv if you want GCC/Clang to strictly consider signed integer
>>> overflow to have defined twos-compliment behaviour.
>>>
>>> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html is
>>> an excellent set of articles which everyone should read.
>>
>> Thanks. That's very interesting.
>>
>> What gets me is that the compiler is (potentially) altering the
>> behaviour of the code without issuing a warning. That's true even with
>> -Wall -Wextra.
>
> The code does not have (defined) behaviour.  Code whose behaviour is not
> defined, does not have to consistent modes of misbehaviour.

That's the correct "C" position, of course, and I understand it. 
However, I am uncomfortable with a compiler changing the effect of the 
code without warning.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#108407

James Harris <james.harris.1@gmail.com> writes:
> On 22/04/2017 11:37, Gareth Owen wrote:
>> James Harris <james.harris.1@gmail.com> writes:
[...]
>>> What gets me is that the compiler is (potentially) altering the
>>> behaviour of the code without issuing a warning. That's true even with
>>> -Wall -Wextra.
>>
>> The code does not have (defined) behaviour.  Code whose behaviour is not
>> defined, does not have to consistent modes of misbehaviour.
>
> That's the correct "C" position, of course, and I understand it. 
> However, I am uncomfortable with a compiler changing the effect of the 
> code without warning.

Consider this:

    char message[5] = "hello";
    puts(message);

This has undefined behavior because `message` does not contain a
(valid null-terminated) string.  Its actual behavior is likely to
vary depending on optimization level and other compiler options.
Does that make you equally uncomfortable?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#108695

On 24/04/2017 16:33, Keith Thompson wrote:
> James Harris <james.harris.1@gmail.com> writes:
>> On 22/04/2017 11:37, Gareth Owen wrote:
>>> James Harris <james.harris.1@gmail.com> writes:
> [...]
>>>> What gets me is that the compiler is (potentially) altering the
>>>> behaviour of the code without issuing a warning. That's true even with
>>>> -Wall -Wextra.
>>>
>>> The code does not have (defined) behaviour.  Code whose behaviour is not
>>> defined, does not have to consistent modes of misbehaviour.
>>
>> That's the correct "C" position, of course, and I understand it.
>> However, I am uncomfortable with a compiler changing the effect of the
>> code without warning.
>
> Consider this:
>
>     char message[5] = "hello";
>     puts(message);
>
> This has undefined behavior because `message` does not contain a
> (valid null-terminated) string.  Its actual behavior is likely to
> vary depending on optimization level and other compiler options.
> Does that make you equally uncomfortable?

Strangely, no. Perhaps because what will be 'put' will depend on the 
layout of memory rather than the compiler making a different assumption 
for a different optimisation level.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#108698

On Friday, April 28, 2017 at 4:32:10 PM UTC-5, James Harris wrote:
> On 24/04/2017 16:33, Keith Thompson wrote:
> > Consider this:
> >
> >     char message[5] = "hello";
> >     puts(message);
> >
> > This has undefined behavior because `message` does not contain a
> > (valid null-terminated) string.  Its actual behavior is likely to
> > vary depending on optimization level and other compiler options.
> > Does that make you equally uncomfortable?
> 
> Strangely, no. Perhaps because what will be 'put' will depend on the 
> layout of memory rather than the compiler making a different assumption 
> for a different optimisation level.

Given

    #include <stdio.h>

    char message[5] = "Hello";
    char magic = 0;

    int main(void)
    {

      if (message+5 == &magic)
        printf("%d", message[5]);
      return 0;
    }

evaluation of the pointer expression "message+5" is defined behavior,
as is the comparison between that address and the address of magic.  Even
if message+5 == &magic, however, that does not imply anything about the
behavior of evaluating message[5].

Consider the function

    int test(int x)
    {
      if (magic) return magic;
      message[x]++;
      return magic;
    }

In the event that message+5 == magic, should a compiler be required to
generate code which will return 1 if the above function is invoked with
magic==0 and x==5?

[toc] | [prev] | [next] | [standalone]

#108712

supercat@casperkitty.com writes:

>       if (message+5 == &magic)

I think this equality expression may be UB in C11 (S6.5.8.5)
It's merely unspecified in C++.

[toc] | [prev] | [next] | [standalone]

#108714

Gareth Owen <gwowen@gmail.com> writes:

> supercat@casperkitty.com writes:
>
>>       if (message+5 == &magic)
>
> I think this equality expression may be UB in C11 (S6.5.8.5)
> It's merely unspecified in C++.

You are looking at the wrong section.  It's 6.5.9 (p6) that applies.

The take-home result is that you can always test valid pointers for
equality and you may get a positive result from testing the valid "one
past the end of an array" pointer and the address of some other object
that just happens to follow on in memory.  And since non-array objects
are considered to be arrays of length one when constructing pointers,
this applies to ordinary objects too.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#108716

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Gareth Owen <gwowen@gmail.com> writes:
>
>> supercat@casperkitty.com writes:
>>
>>>       if (message+5 == &magic)
>>
>> I think this equality expression may be UB in C11 (S6.5.8.5)
>> It's merely unspecified in C++.
>
> You are looking at the wrong section.  It's 6.5.9 (p6) that applies.

I stand corrected.  Thanks.

[toc] | [prev] | [next] | [standalone]

#108339

On 22/04/2017 11:52, James Harris wrote:

> What gets me is that the compiler is (potentially) altering the 
> behaviour of the code without issuing a warning. That's true even with 
> -Wall -Wextra.

The problem with your logic is that the code has undefined behavior;
in other words, there is no behavior to "alter".

I think you're alluding to the principle of least surprise.
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Since C often closely maps to the underlying HW, it often comes
as a surprise that "int" is slightly more abstract in the abstract
machine.

> I found that one has to add -Wstrict-overflow=5 to get the compiler to 
> warn about the signed-overflow assumption its optimiser is making.

Would the UB sanitizer help here?
https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
-fsanitize=undefined

> One to add to my list of compiler switches to use. But doing that has 
> two problems:
> 
> 1. How many more similar switches would be needed to catch all the other 
> forms of undefined behaviour that the compiler is able to recognise?

I don't think the compiler always keeps enough information around
to be able to precisely pinpoint where the UB originated from, in
the latest optimization stages.

> 2. I think I would rather this and similar warnings were enabled by 
> default and needed a conscious decision to disable. Failing that, IMO it 
> would be OK to have a switch such as -Wundefined which turned on all 
> such checking but still allowed individual checks to be turned off.

Perhaps you should open an issue on bugzilla?

Regards.

[toc] | [prev] | [next] | [standalone]

#108389

On 22/04/2017 15:12, Noob wrote:
> On 22/04/2017 11:52, James Harris wrote:
>
>> What gets me is that the compiler is (potentially) altering the
>> behaviour of the code without issuing a warning. That's true even with
>> -Wall -Wextra.
>
> The problem with your logic is that the code has undefined behavior;
> in other words, there is no behavior to "alter".
>
> I think you're alluding to the principle of least surprise.
> https://en.wikipedia.org/wiki/Principle_of_least_astonishment
>
> Since C often closely maps to the underlying HW, it often comes
> as a surprise that "int" is slightly more abstract in the abstract
> machine.
>
>> I found that one has to add -Wstrict-overflow=5 to get the compiler to
>> warn about the signed-overflow assumption its optimiser is making.
>
> Would the UB sanitizer help here?
> https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
> -fsanitize=undefined

Sadly not, though it is interesting! I upgraded and tried it but 
-fsanitize=undefined produces the report at runtime. The compiler makes 
assumptions at compile time and it's there that I think a compiler 
should produce a warning.

>
>> One to add to my list of compiler switches to use. But doing that has
>> two problems:
>>
>> 1. How many more similar switches would be needed to catch all the other
>> forms of undefined behaviour that the compiler is able to recognise?
>
> I don't think the compiler always keeps enough information around
> to be able to precisely pinpoint where the UB originated from, in
> the latest optimization stages.
>
>> 2. I think I would rather this and similar warnings were enabled by
>> default and needed a conscious decision to disable. Failing that, IMO it
>> would be OK to have a switch such as -Wundefined which turned on all
>> such checking but still allowed individual checks to be turned off.
>
> Perhaps you should open an issue on bugzilla?

Well, it's not a bug, more a feature suggestion. If bugzilla is the 
right place for that them perhaps I should.

I was mainly interested in the question of "what a compiler /should/ do" 
when it makes optimisation assumptions.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#108365

James Harris <james.harris.1@gmail.com> wrote:

> What gets me is that the compiler is (potentially) altering the 
> behaviour of the code without issuing a warning. That's true even with 
> -Wall -Wextra.
> 
> I found that one has to add -Wstrict-overflow=5 to get the compiler to 
> warn about the signed-overflow assumption its optimiser is making.
> 
> $ cc iter-test.c -Wall -Wextra -Wstrict-overflow=5 -O2
> iter-test.c: In function  ? main ? :
> iter-test.c:3:5: warning: assuming signed overflow does not occur when 
> reducing constant in comparison [-Wstrict-overflow]
>      for (i = 0; i < i + 1; i++)
>      ^
> 
> One to add to my list of compiler switches to use. But doing that has 
> two problems:
> 
> 1. How many more similar switches would be needed to catch all the other 
> forms of undefined behaviour that the compiler is able to recognise?

It's impossible at compile time without triggering a lot of false
positives.  It's possible at runtime, but difficult.

> 2. I think I would rather this and similar warnings were enabled by 
> default and needed a conscious decision to disable. Failing that, IMO it 
> would be OK to have a switch such as -Wundefined which turned on all 
> such checking but still allowed individual checks to be turned off.

There would be too much collateral damage.

Consider this:

extern int flonger(int n);
void poo(int m) {
  for (int i = 0; i < m; i += 2)
    flonger(i * 10);
}

Do you want a warning for every such loop?  The compiler doesn't
necessarily keep track of all the places that it assumes signed
overflow does not occur.

Andrew.

[toc] | [prev] | [next] | [standalone]

#108373

On Sunday, April 23, 2017 at 5:41:18 AM UTC-5, Andrew Haley wrote:
> Consider this:
> 
> extern int flonger(int n);
> void poo(int m) {
>   for (int i = 0; i < m; i += 2)
>     flonger(i * 10);
> }
> 
> Do you want a warning for every such loop?  The compiler doesn't
> necessarily keep track of all the places that it assumes signed
> overflow does not occur.

It might be useful to point out why it should matter: if a compiler knew that
flonger would always return, it could replace the loop with: 

   if (m > 0)
   { 
     int __temp = (m-2)*10;
     for (int i=0; i<=__temp; i+=20)
       flonger(i);
   }

I'm not sure how often that would be more efficient than:

   if (m > 0)
   { 
     int __temp1 = 0;
     unsigned __temp2 = m;
     do
     {
       flonger(__temp1);
       __temp1+=20;
     } while(--_temp2);
   }

but the former construct would be prone to exit the loop early if an overflow
would occur later, while the latter construct would behave as "expected"
unless something unusual happens in the __temp1+=20 line.

[toc] | [prev] | [next] | [standalone]

#108393

supercat@casperkitty.com wrote:
> On Sunday, April 23, 2017 at 5:41:18 AM UTC-5, Andrew Haley wrote:
>> Consider this:
>> 
>> extern int flonger(int n);
>> void poo(int m) {
>>   for (int i = 0; i < m; i += 2)
>>     flonger(i * 10);
>> }
>> 
>> Do you want a warning for every such loop?  The compiler doesn't
>> necessarily keep track of all the places that it assumes signed
>> overflow does not occur.
> 
> It might be useful to point out why it should matter

A really perspicaceous reader could run the program through GCC with
and without -fwrapv, look at the generated code, and hopefully become
enlightened.

Andrew.

[toc] | [prev] | [next] | [standalone]

#108390

On 23/04/2017 11:41, Andrew Haley wrote:
> James Harris <james.harris.1@gmail.com> wrote:
>
>> What gets me is that the compiler is (potentially) altering the
>> behaviour of the code without issuing a warning. That's true even with
>> -Wall -Wextra.
>>
>> I found that one has to add -Wstrict-overflow=5 to get the compiler to
>> warn about the signed-overflow assumption its optimiser is making.
>>
>> $ cc iter-test.c -Wall -Wextra -Wstrict-overflow=5 -O2
>> iter-test.c: In function  ? main ? :
>> iter-test.c:3:5: warning: assuming signed overflow does not occur when
>> reducing constant in comparison [-Wstrict-overflow]
>>      for (i = 0; i < i + 1; i++)
>>      ^
>>
>> One to add to my list of compiler switches to use. But doing that has
>> two problems:
>>
>> 1. How many more similar switches would be needed to catch all the other
>> forms of undefined behaviour that the compiler is able to recognise?
>
> It's impossible at compile time without triggering a lot of false
> positives.  It's possible at runtime, but difficult.

Surely a compiler could report that the assumptions it was making at one 
level of optimisation were different from those produced at a different 
optimisation level.


>
>> 2. I think I would rather this and similar warnings were enabled by
>> default and needed a conscious decision to disable. Failing that, IMO it
>> would be OK to have a switch such as -Wundefined which turned on all
>> such checking but still allowed individual checks to be turned off.
>
> There would be too much collateral damage.
>
> Consider this:
>
> extern int flonger(int n);
> void poo(int m) {
>   for (int i = 0; i < m; i += 2)
>     flonger(i * 10);
> }
>
> Do you want a warning for every such loop?  The compiler doesn't
> necessarily keep track of all the places that it assumes signed
> overflow does not occur.

I am not sure what signed-integer optimisation you see a compiler making 
in that. Of course i * 10 may overflow but I don't see where a compiler 
would make different assumptions at different optimisation levels.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#108410

On 04/24/2017 04:22 AM, James Harris wrote:
> On 23/04/2017 11:41, Andrew Haley wrote:
>> James Harris <james.harris.1@gmail.com> wrote:
>>
>>> What gets me is that the compiler is (potentially) altering the
>>> behaviour of the code without issuing a warning. That's true even with
>>> -Wall -Wextra.
>>>
>>> I found that one has to add -Wstrict-overflow=5 to get the compiler to
>>> warn about the signed-overflow assumption its optimiser is making.
>>>
>>> $ cc iter-test.c -Wall -Wextra -Wstrict-overflow=5 -O2
>>> iter-test.c: In function  ? main ? :
>>> iter-test.c:3:5: warning: assuming signed overflow does not occur when
>>> reducing constant in comparison [-Wstrict-overflow]
>>>      for (i = 0; i < i + 1; i++)
>>>      ^
>>>
>>> One to add to my list of compiler switches to use. But doing that has
>>> two problems:
>>>
>>> 1. How many more similar switches would be needed to catch all the other
>>> forms of undefined behaviour that the compiler is able to recognise?
>>
>> It's impossible at compile time without triggering a lot of false
>> positives.  It's possible at runtime, but difficult.
>
> Surely a compiler could report that the assumptions it was making at one
> level of optimisation were different from those produced at a different
> optimisation level.


So, whenever I choose -O3, I should see a message from the compiler 
saying "Selection of -O3 enables several thousand assumptions that are 
not made at -O2. For a complete list, see the following website:"?

Keep in mind that the committee often chooses to make violation of a 
particular rule "undefined behavior" rather than a "constraint 
violation" precisely because it's not always feasible to identify such 
violations. Making it a "constraint violation" would make detection of 
the violation mandatory in all cases. I agree that a good compiler 
should warn about the cases that are easy to detect, but they are not 
required to do so, and you shouldn't rely up violations always being 
detectable.

Furthermore, a compiler does not necessarily collect the information 
needed to identify which assumptions it's relying upon. All it needs to 
do is identify when it's permissible to apply a given optimization. At 
the point where it reaches that conclusion, there's lots of different 
possibilities for the context of that conclusion. To get a little more 
specific, let's assume that, when a particular optimization has been 
determined to be feasible, the possible contexts for that optimization 
can be divided into 16 different categories, with each category having a 
different reason why the optimization is permissible. It might be the 
case that for contexts which fall into categories 5, 7, 8 and 9, the 
optimization is permissible because the behavior is undefined. In 
categories 5 and 8, the optimization might change the observable 
behavior of the code. However, the optimizer doesn't know which of the 
16 categories applies - the designer only knew that it's in a situation 
where those 16 categories are the only ones that could apply. So the 
compiler doesn't know whether or not it's relying upon the assumption 
that the behavior is defined, but it is still justified in performing 
the optimization.

[toc] | [prev] | [next] | [standalone]

#108431 — Re: gcc rules OK (optimised/non-optimised)

On 04/24/2017 04:35 PM, Stefan Ram wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
>> Keep in mind that the committee often chooses to make violation of a
>> particular rule "undefined behavior" rather than a "constraint
>> violation" precisely because it's not always feasible to identify such
>> violations.
>
>   This is also confirmed by the rationale itself:
>
>       »Undefined behavior gives the implementor license not to
>       catch certain program errors that are difficult to diagnose.«.
>
>     Rationale for International Standard
>     - Programming Languages - C, Revision 5.10, April 2003
>
>   (However, when an implementation exploits UB by generating
>   special code, then the implementation should usually /have/
>   identified the UB.)

The point of my message was to remind people that this is NOT 
necessarily the case - you can exploit UB by having a set A of 
conditions that are sufficient to ensure that the optimization is valid, 
and an additional set of conditions B that are consistent with A, and 
render the behavior undefined. When A and B are both true, the 
optimization is legal because the behavior is undefined. When A is true 
and B is not true, the optimization is still legal, for different 
reasons. All the compiler needs to determine is whether A is true, it 
doesn't need to determine whether B applies, and therefore need NOT be 
aware that the behavior is undefined.

In this case "signed_integer_expression < signed_integer_expression + 
positive_constant_expression", where the two signed integer expressions 
are guaranteed to have the same value, is condition A. That condition is 
sufficient to justify the optimization of replacing that comparison 
expression with 1. If signed_integer_expression + 
positive_constant_expression overflows,  that's condition B, and the 
optimization is justified because the behavior is undefined. If it 
doesn't overflow, the optimization is justified by the ordinary rules of 
C arithmetic.

An implementation therefore never needs to check to whether overflow is 
guaranteed to occur (as it is in this case), impossible (as it might be 
with adequate error checking), or indeterminable (as it would be if 
signed_integer has a value that comes from outside the same translation 
unit. But it doesn't need to perform such a check - it's permitted to 
perform the optimization regardless of which of the three applies. 
That's good, because in general, determining which of the three applies 
can be proven equivalent to solving the halting problem.

[toc] | [prev] | [next] | [standalone]

#108437 — Re: gcc rules OK (optimised/non-optimised)

On Monday, April 24, 2017 at 4:07:04 PM UTC-5, James R. Kuyper wrote:
> On 04/24/2017 04:35 PM, Stefan Ram wrote:
> >   (However, when an implementation exploits UB by generating
> >   special code, then the implementation should usually /have/
> >   identified the UB.)
> 
> In this case "signed_integer_expression < signed_integer_expression + 
> positive_constant_expression", where the two signed integer expressions 
> are guaranteed to have the same value, is condition A. That condition is 
> sufficient to justify the optimization of replacing that comparison 
> expression with 1. If signed_integer_expression + 
> positive_constant_expression overflows,  that's condition B, and the 
> optimization is justified because the behavior is undefined. If it 
> doesn't overflow, the optimization is justified by the ordinary rules of 
> C arithmetic.

In this kind of situation, as in many others, most of the optimizations
which would be facilitated by treating some action as UB could be
facilitated just as well by specifying a behavioral model which allows an
implementation broad latitude with regard to behavior, but still keeps it
within certain bounds.  Such a behavioral model would fit well with many
application requirements, which require that a program behave in precisely-
defined fashion when given valid input, and behave in constrained, but not
precisely-defined, fashion when given invalid input.  The C Standard
attempts to define a concept of "analyzability" that distinguishes between
"critical" and non-critical forms of UB.  Unfortunately, it is specified so
loosely as to be practically useless unless implementers can be relied upon
to supplement it with common sense.

[toc] | [prev] | [next] | [standalone]

Page 1 of 13  [1] 2 3 … 13  Next page →

Back to top | Article view | comp.lang.c

csiph-web